こんにちは。クラウドエース株式会社で Google Cloud 認定トレーナーをしている廣瀬隆博です。メタルという音楽はさまざまなサブジャンルに分かれており、私はメロディックデスメタルやメタルコアといったジャンルを好んでいます。一方、フェスなどで他のジャンルに触れることで自身の興味が広がり、今ではパワーメタルやメロスピなども大好きになりました。

何の話かって？もちろん Google のお話です。

私は Google Cloud を得意とする企業に所属していますが、システムインテグレーション業務において Google Workspace と連携することもあります。そういった経験から Google Workspace に多少詳しくなり、認定資格を取得することができました。

今回は、普段の業務で直接扱うことが多くはないサービスでも、触れてみると意外と楽しいよ！ ということをお伝えすべく、Professional Google Workspace Administrator 認定試験について解説してまいります。

前回も Google Cloud とは直接関係のない ChromeOS の記事だったじゃないか！ って思ったあなたは私のファンですね。いつもありがとうございます 🤘

試験範囲の概要

解説を始める前に、そもそもどんな試験なんだ？ ということに少し触れておきましょう。

公式サイトには色々書かれているのですが、私なりに要約してみると Google Workspace の管理者として、Gmail、カレンダー、ドライブ、Meet などのサービスを利用者に適切な状態で提供し、セキュリティを保ち、トラブルに対応する能力を求められる試験でしょうか。

特にメール周りは要注意ですね。Gmail の使い方だけではなく、迷惑メール対策などのセキュリティ要素もあり、他システムからの移行といった導入における課題も問われます。企業のドメイン名が付いたメールアドレスにすることが多いので、対策が不十分なために送付先の迷惑メールフォルダへ振り分けられる のは避けたいところです。

ドライブについても、企業内のデータを多く保持するため、管理ミスからデータが漏洩したり紛失することは避けなければなりません。 そのためには適切な権限設計が必要となりますし、要件によってはアクセスを許可するデバイスの制限なども必要でしょう。

試験範囲の解説

さて、本題の解説に入りましょう。試験ガイドは以下の URL にて公開されています。

ディレクトリサービス

Google Workspace は ディレクトリサービス としての機能を備えています。では、ディレクトリサービスとは何か、Google の生成 AI である Gemini に聞いてみました。

ディレクトリサービスとは、ネットワーク上の資源（サーバー、プリンター、ユーザーアカウントなど）に関する情報を一元的に管理し、提供するサービスです。

つまり、ユーザーアカウントだけではなく、デバイスなども管理できる わけですね。具体的にはパソコンやスマートフォンです。しかも、ChromeOS や Android といった Google 製品だけではなく、Windows や macOS、iOS といった 著名な他社製品も管理対象とすることができます。 いわゆる Mobile Device Management（以下、MDM） としても使用することができますね。

ドメイン

Google Workspace をフル活用するためには、ドメイン が必要となります。このブログを例にすると、zenn.dev の部分ですね。

ドメインがなくてもドライブや Meet を使うことはできるのですが、やはり メールやカレンダーといったサービスを使ってこその Google Workspace なので、ぜひともドメインを準備しましょう。

ドメインの所有権証明

Google Workspace へドメインを登録するためには、ドメインの所有権を証明 する必要があります。管理コンソールから証明用の Domain Name System（以下、DNS）レコードを取得し、ドメインの DNS サーバーに TXT レコードとして追加することで所有権を証明することができます。

Google「このランダム文字列を登録してね」 → 利用者「登録したよ」 → Google「登録してあるね！ドメインを所有していることが確認できたよ！」といった感じのフローですね。

ユーザーアカウント

ドメインの所有権を証明したので、さっそく ユーザーアカウント を追加してみましょう。

管理コンソールからユーザーを作成する

管理コンソール と呼ばれる Google Workspace 管理画面の URL は https://admin.google.com/ です。初めて見た人でも簡単に登録できると思います。

私の所属するクラウドエース株式会社の兄弟会社である吉積情報株式会社（以下、吉積情報）が管理コンソールに関する記事を公開していますので、画面イメージを確認されたい方はご参照ください。

CSV ファイルからユーザーを一括作成する

管理コンソールは簡単な操作でユーザーを追加することができます。しかし、大量にユーザーを登録することには向いていません。例えば 100 人のユーザーを追加する場合、100 回も同じ操作をすることは少々骨が折れるでしょう。これが 1000 人ともなれば、少なくとも私は画面操作以外の方法を考えます。

そういった場合、CSV ファイルを用いたユーザーの一括作成 が可能です。手順はそれほど難しくなく、下記の公式サイトからテンプレートファイルをダウンロードし、ユーザー情報を入力してアップロードするだけです。表計算ソフトに慣れている方であれば、それほど苦労せずデータを用意することが可能です。

既存のディレクトリサービスと同期してユーザーを作成する

例えば、社内で Active Directory が稼働しており、同じユーザーを Google Workspace にも作成したいといった要件があります。そういった場合、Google Cloud Directory Sync を用いることでユーザーを同期することができます。これは試験で問われる事が比較的多い印象もありますので、是非覚えておきましょう。

また、最近では Directory Sync が追加されたようですね。本記事執筆時点ではベータ版ですが、Microsoft Entra ID（旧称 Azure Active Directory）からの同期に対応しているようです。

グループ

グループ とは、ユーザーを 1 つのまとまりとして扱う機能です。読んで字のごとくですね。グループの使用例を解説していきます。

メーリングリスト

グループはメールアドレスと同じ形式で作成されます。このアドレス宛に送信されたメールは、グループに参加しているユーザー全員へ配信 されます。例えば部署ごとのメールアドレスが必要な場合に便利ですね。

共同トレイ

グループに送られてきたメールを複数人で対応するような場面で便利な機能が 共同トレイ です。例えば顧客からの問い合わせ用としてグループを作成している場合、問い合わせごとに担当者を割り当てたり、担当者が休暇の場合は上司が変わりに対応するようなことが考えられます。

共同トレイについても吉積情報が画面イメージ付きの分かりやすい記事を公開していますので、操作画面を確認してみたい方はご参照ください。

会議案内

後ほど出てくるカレンダーでは、予定を管理することができます。グループを用いることで、参加しているユーザー全員の予定を登録することが可能 です。前述の例では、部の全員が参加する会議の案内などに活用することができるでしょう。

ドライブ権限管理

冒頭で少し出てきたドライブですが、データへのアクセス権を管理する必要があります。会議案内と同様に、個人ではなくグループへアクセス権を付与することで、参加しているユーザー全員にアクセス権を付与することができる ようになります。

また、部署の異動などによって権限をはく奪する必要がある場合も、グループのメンテナンスだけで対応が可能となるので便利ですね。これが個別のユーザーであった場合、ファイルを 1 つずつチェックして権限をはく奪しなくてはならず手間がかかってしまいます。

Google Cloud 権限管理

認定トレーナーとして、Google Cloud の権限管理について説明しないわけにはいきませんね。Google Cloud のベストプラクティスとして、ユーザーへの権限付与はグループを使用することが推奨 されています。これもドライブ権限管理と同じ理由ですが、ユーザーの役割が変わって権限を変更したい場合に便利なためです。

デバイス管理

冒頭で MDM としての機能も備えていると説明しました。組織としてシステムを使用させる場合、支給したデバイスに限定したいというのはよくある要件だと思います。それだけではなく、デバイスの設定やアプリケーションについても制御することが可能です。

対応デバイス

個人的な所感も含まれていますが、公式サイトではデバイスとエンドポイントという 2 つの言葉が同様の意味合いで使われているようです。一方で、操作画面ではパソコンとスマートホームデバイスを対象としてエンドポイントと表記しているようですね。ちょっとややこしいですが、各デバイスについて簡単に見ていきましょう。

デバイス画面

モバイルデバイス

Android、iPhone、iPad がサポート されています。一般的なスマートフォンとタブレットを網羅しており、大変便利ですね。Android と iPhone および iPad では、機能が異なるものもあります。全てを覚えるのは大変ですが、興味があればそれぞれ実機を用意して制御してみると理解の助けになると思います。

エンドポイント

Microsoft Windows、Apple Mac、Linux、およびスマートホームデバイス がサポートされています。モバイルデバイスと同様に、それぞれ使用できる機能が異なります。特に Microsoft Windows は組織で使われることも多いためか、多彩な機能が提供されているようですね。

Chrome デバイス

冒頭でも記載しましたが、ChromeOS に特化した資格対策記事を公開していますので、そちらをご確認ください。Google の製品であるため、Google Workspace とも親和性が高く、かなり便利な機能が提供されています。

ライセンス

デバイスの管理は 基本のエンドポイント管理、高度なエンドポイント管理、およびエンタープライズエンドポイント管理の 3 種類 があります。ライセンスの種類はもっと多く暗記するのは辛いので、3 種類あることだけでも覚えておきましょう。

デバイスの承認とブロック

Google Workspace が管理する各種データへのアクセス要否を制御することができます。要は管理者が承認したデバイスだけを許可するための機能 ですね。ブロックについてはデバイスの紛失時にも役立つ機能ですね。

ワイプ

デバイスから Google Workspace のデータを削除する操作が ワイプ です。主にデバイスの紛失やユーザーの離職に対応するための機能ですね。管理コンソールから遠隔でワイプする操作を リモートワイプ と呼び、デバイス管理において一般的に使用される言葉ですので覚えておきましょう。

ポリシー

ポリシー を日本語に翻訳すると方針でしょうか。Google Workspace では、ユーザーに様々な設定を実装する際に用いられます。サービスや機能の利用可否であったり、パスワードのルール策定など、さまざまな設定が提供されています。

組織部門

Active Directory における Organizational Unit（OU）と同等の機能です。 Google Cloud であれば、リソース階層におけるフォルダですね。組織部門 と呼ばれるフォルダのようなものでユーザーやデバイスをグループ化し、階層構造の上から下へポリシーを継承することで組織内を一元管理するための仕組みとなります。

設計のコツとして、ユーザー用とグループ用の組織構造は分けておきましょう。Active Directory での経験ですが、過去に以下のような設計がありました。

同じユーザーであってもファットクライアントとシンクライアントで異なるポリシーを設定したい
交代制勤務のため複数人でデバイスを共用するが、役職ごとにポリシーを設定したい

メール

様々なテキストコミュニケーションツールが使われるようになった昨今、特に組織内では以前ほどメールが使われなくなったかもしれません。しかし、対外的には今でも主流であるメールは、セキュリティがとても重要です。フィッシングなどの攻撃手段に用いられることもあり、組織のドメイン名が付与されたメールアドレスが悪用されてしまえば信用の損失にも繋がる でしょう。

そうならないように、Google Workspace におけるメールの仕組みやセキュリティはしっかり押さえておきましょう。

組織名でメールを使用する

前述のドメインの所有権証明が終わっていれば、組織名のメールアドレスを作成できるようになります。しかし、実際にメールが Google Workspace へ届くようにするためには、DNS に対して設定が必要 です。

MX レコード

Mail Exchanger（以下、MX）レコード とは、DNS のリソースレコードの一種で、特定のドメイン宛ての電子メールをどのメールサーバーに転送すればいいかを指定するレコードです。つまり、この設定を Google Workspace のものに変更すれば良いわけですね。

メールセキュリティ

MX レコードを指定すると Google Workspace のメールが使えるようになりますが、それだけではセキュリティに懸念があります。

メールセキュリティが強固なものの例として、携帯電話会社のメールが挙げられます。携帯電話会社の迷惑メールフィルター設定が強い状態でもメールが届くように設定するのは一苦労でした。逆に言えば、そういった送信先に対しても迷惑メールとして振り分けられないような設定が実装されていれば、一定のセキュリティが保たれていると言えるでしょう。

では、各設定について簡単に触れていきましょう。

なりすまし対策

メールにおけるなりすましとは、差出人を詐称することです。

例えば、悪意を持った第 3 者が金融機関になりすまして「パスワードが漏洩したので、次の URL から新しいパスワードを設定してください」と送ってきたとします。騙されたユーザーは金融機関を語る偽の Web サイトで認証情報を入力してしまい、アカウントが乗っ取られることに繋がります。

こういった攻撃を防ぐために なりすましメールではないことを証明する 必要があり、これらを正しく実装することで迷惑メールフィルターを回避することができるようになるわけです。言い換えると、これらの設定が不十分であれば疑わしいメールと判断され、組織の信用を損なう可能性があるので注意しましょう。

全ての対策を実装し、チェックが PASS になっていると良いですね。

なりすまし対策

SPF

Sender Policy Framework（以下、SPF） とは、ドメインから送付する際の IP アドレスを SPF レコードとして DNS に定義しておくことで、第 3 者がなりすまして送信したメールを疑わしいと判断する仕組みです。要は ウチの組織からメールを送るのはこの IP アドレスだから！他は偽物だからね！ と宣言するような感じです。

Google Workspace のみを用いる場合、SPF レコードは以下となります。

v=spf1 include:_spf.google.com ~all

他の例は公式サイトに記載されていますので、ざっと目を通しておきましょう。説明動画も公開されているので、理解の助けとなります。

DKIM

DomainKeys Identified Mail（以下、DKIM） とは、電子署名を用いた認証方式です。ウチのメールはこの鍵で開くからね！ と DNS サーバーに公開鍵を登録しておくことでなりすましを防ぎます。

SPF と同様に DKIM についても説明動画が公開されていますので、是非見ておきましょう。

DMARC

Domain-based Message Authentication, Reporting and Conformance（以下、DMARC） とは、SPF や DKIM の検証に失敗した場合の処理方法を指定するものです。受信側が以下のポリシーを設定することで、疑わしいメールの処理方法を決定します。

「none」に設定された場合、通常どおりにメールが配信される
「quarantine」に設定された場合、受信者の迷惑メールフォルダに送信される
「reject」に設定された場合、受信者に配信されません。

ARC

Authenticated Received Chain（以下、ARC） とは、メール転送によって SPF や DKIM の認証に失敗し、DMARC によって迷惑メールとして扱われることを防ぐ仕組みです。メール転送時にヘッダーへ ARC 署名を追加し、受信者が検証することで DMARC 認証に失敗したメールでも正常として処理されます。

ここでは、これ以上の説明は避けることにします。理由は簡単で、Google Workspace では特にユーザーが設定を加えることなく動作する仕組みであるためです。

BIMI

Brand Indicators for Message Identification（以下、BIMI） とは、メールにロゴを表示する機能です。これまでの設定とは少し異なりブランディングが主目的ですが、DMARCが必須であることから、本項目で合わせて解説します。

色々準備が必要で時間を要する仕組みであり、ロゴを配布するために BIMI をサポートした Web サーバーが必要となります。また、DMARC ポリシーを none 以外に設定しましょう。DNS サーバーでの対応も必要となります。

詳細は公式サイトをご参照ください。

改ざん対策

世の中に登場した当時のメールは暗号化されていませんでした。Web サイトもそうでしたが、通信を盗聴すると内容が筒抜けになってしまいますね。対策としても Web サイトと同じで、何かしらの仕組みで暗号化してしまえば良い わけです。また、メールの中身が読めないようになることで改ざん対策にもなりますね。

改ざん対策

STARTTLS

Google Workspace は 既定で TLS 接続を試みる ため、特に設定を意識する必要はありません。この際に送信側メールサーバーから受信側メールサーバーに STARTTLS とメッセージを送付して暗号化の要否を決定するため、仕組みの名称としても広く知られています。Gmail の GUI では、灰色の鍵アイコンが表示されます。

MTA-STS

STARTTLS は、受信側メールサーバーが TLS 接続に対応していれば暗号化して送信するという仕組みになっています。つまり、受信側次第では暗号化せずにメールが送られてしまいます。これを防ぐために MTA-STS を用いることで、TLS 接続を強制 することができます。

BIMI と同じように、MTA-STS にも Web サーバーと DNS サーバーが必要となります。Web サーバー上にポリシーを公開し、DNS サーバーに MTA-STS を使用していると宣言します。送信側メールサーバーは Web サーバー上のポリシーを確認し、定義された要件に従って TLS 接続を確立、メールを送信します。

公開されたポリシーに対応していない場合、メールが送信されないことで TLS 接続を強制する仕組みですね。

S/MIME

STARTTLS や MTA-STS 以前より存在する仕組みが S/MIME です。組織が個別に用意した証明書でメールを暗号化することで盗聴を防ぎ、署名することで改ざんを防ぎます。証明書の購入・維持にコストは発生しますが、より信頼性が高いと言えるでしょう。Gmail の GUI では、緑色の鍵アイコンが表示されます。

メールルーティング

メールルーティング とは、メールを送信してから受信者のメールボックスへ届くまでの経路のことです。また、経路には各種セキュリティ対策が実装されていることが一般的ですね。

ここでは、一般的なルーティングについて記載します。

分割配信

受信メールをルールに基づいて 分割配信 することができます。例えばメールシステムの変更を計画している場合、一斉に全員を切り替えることはリスクがあるでしょう。そういった際に、一部のユーザーだけ新しいシステムを試す といった使い方が可能です。

二重配信

複数の宛先にメールを配信することができます。これもメールシステム変更が良い例であり、移行期間内に新システムを使い始めてね、期間が終わったら旧システムにはメールが届かないよ といった使い方ができます。

キャッチオール

存在しなかったり、正しくないメールアドレスへのメールを、特定のメールボックスで受け取ることができる機能が キャッチオール です。これを使っていない場合、送信元に そのメールアドレスは存在しません といった自動返信がされます。

退職して削除されたメールアドレスに送られたメールを受け取るような使い方もできますが、一方でキャッチオールメールボックスの管理・運用が必要になりますので、要件次第といったところでしょう。キャッチオールに入ったメールを放置すると、送信者からすれば 送ったメールにいつまでも返信がない といった不信感を与えてしまいかねません。

別のユーザーに転送

こちらのほうが退職者のメール対応には向いています。退職者に届いたメールを後任や上司に転送するような使い方ですね。とはいえ、いつまで転送し続けるべきか悩ましい ところもあるので、個人的には退職者のアドレスに向けて送られたメールは送信エラーになって良いのではないかと感じています。（個人の感想です）

スパムメール対策

メール運用と言えば スパムメール対策 です。日本語にすると迷惑メール対策ですね。思わず言い切ってしまうくらい、スパムメールは数多く飛び交っています。総務省によると、2023 年現在でも全体の 4 割はスパムメール だそうですので、しっかり対策しましょう。

Gmail は既定の状態でもかなり優秀であり、露骨なスパムメールが届くことはあまり多くありません。しかし、世間には標的型攻撃メールのような、特定の組織を狙い撃ちにするものもあります。そういったものが既定の対策を潜り抜けて届いた場合、さまざまな方法で対応することができます。

特定のメールアドレスやドメインからのメールをブロックする

迷惑メールだと分かっている送信者や送信元を対象に、メールをブロック することができます。標的型攻撃メールが届いた場合、積極的に使いたい機能ですね。

カスタム迷惑メールフィルタ

様々なルールに従って迷惑メールをコントロールするのが カスタムメールフィルタ です。誤って迷惑メールに分類されてしまっているものを通常通り受信するような設定が可能です。

ドライブ

ドライブ とは、ファイル共有プラットフォームです。ファイルサーバーとお伝えした方が伝わりやすい方もいるかもしれません。

ドライブの種類

ドライブにアクセスすると、似たような名前がいくつか表示されます。まずはこれらの違いを理解しましょう。

ドライブの種類

マイドライブ

マイドライブ とは個人向けのファイル保管場所であり、アクセス権を設定しない限りは非公開です。

共有アイテム

他者のマイドライブから共有されたものが 共有アイテム に表示されます。

共有ドライブ

マイドライブとは異なり、共有ドライブ のファイルは組織が保有します。そのため、ユーザーアカウントの削除によってデータが失われません。

権限管理

ドライブの権限管理はディレクトリサービスとそれほど変わりません。フォルダをツリー上に作成し、上位から下位へ権限を継承することで権限を管理します。ユーザーだけではなく、グループで権限を付与できる点も同様ですね。

権限は比較的シンプルで、以下から選択することができます。読んで字のごとくな権限を持っているので、詳細は本記事では省略します。

オーナー
編集者
閲覧者
閲覧者（コメント可）

削除ユーザーのデータ移管

マイドライブは個人向けのファイル保管場所ですが、ユーザーの離職等によって アカウントが削除される場合にはデータを移管することが可能 です。移管操作には管理権限が必要であり、移管先は同じ組織内に限られるので、マイドライブとはいえ組織内のデータが組織外へ移管されることはありません。

削除済みのファイルを復元する

ユーザーがファイルを削除してゴミ箱を空にした後、25 日以内であれば管理者が復元 することができます。

パソコン版ドライブ

ドライブは便利ですが、Web ブラウザからの利用に手間を感じる方もいるでしょう。そういった場合、パソコン版のドライブ を使用することができます。ただし、管理者から許可された場合のみ使用可能ですのでご注意ください。

DLP

Data Loss Prevention（以下、DLP） とは、クレジットカード番号などの機密性が高い情報を検出・保護する仕組みです。

DLP のルール

DLP は必ず有効というわけではなく、必要に応じて設定する機能 です。保護すべき情報などをルールとして定義し、ルールに反する外部共有などが発生した際にアラートを通知することができます。ただし、ファイル形式などに制限があるため、公式サイトの情報に軽く目を通しておきましょう。

カレンダー

名称通りであり、スケジュール管理に用いることが多い カレンダー です。ただ、ちょっとした使い方のコツがあり、会議室や車など、組織における共用リソースの管理にも活用することができます。

グループカレンダー

個人のカレンダーではなく、共用の グループカレンダー を作成することも可能です。私の所属する会社では勉強会のカレンダーが存在しており、興味のあるユーザーはこのカレンダーを参照することで社内の勉強会を把握することができるようになっています。

共用リソース管理

組織の建物を登録し、そこに紐づける形で 共用リソース を登録します。あとは他人のカレンダーを予約するのと同じ要領で共用リソースを予約することができます。

共用リソース権限設定

共用リソースには権限を設定することができますので、ユーザーによる予約の可否や予定変更の可否を要件に応じて設定しましょう。

その他のセキュリティ

これまでの解説にもセキュリティに関する内容は含まれていました。しかし、他にも Google Workspace には多数のセキュリティ機能が存在します。いくつか解説していきましょう。

Vault

各種データの監視や監査に用いるのが Vault です。メール、ドライブ、カレンダーなど、これまでに解説したサービスに対して、データの保持や破棄、開示に必要な情報の収集などが可能です。主に法的な要件に対応するための機能ですね。

データ保持・破棄

Vault で 保持期間 を設定した場合、ユーザーがメールやファイルを削除、ごみ箱を空にしてもデータは保持されます。逆に、破棄すべき日数に到達した場合、ユーザーが削除操作をしていなくても削除されます のでご注意ください。

データ検索・書き出し

案件と呼ばれるワークスペースを作成し、条件を指定することで データを検索・書き出すことが可能 です。ユーザーが消しちゃったメールを見たいという要件でも使えなくはないですが、そういった目的の機能ではないのでおススメはできません。

セキュリティ調査ツール

上位のエディションでは、セキュリティ調査ツール が提供されています。例えば以下のような用途に適していますので、ざっと見ておくと試験対策に役立つでしょう。

フィッシングといった悪意あるメールの調査
ファイル共有状況の調査
オーナーが不明なドライブファイルを移管
Chat のメッセージを調査

まとめ

Professional Workspace Administrator の試験ガイドを元に、試験範囲の概要を説明してきました。Google Workspace は非常に多岐にわたる機能を搭載 しており、私自身も把握し切れていないのが実情です。とはいえ、ここまでに解説した内容で基本的な使い方はお伝えできたかと思っています。公式サイトには模擬試験も掲載されていますので、そういった教材を活用してぜひとも試験にチャレンジしてみてください。

クラウドエース株式会社 Google Cloud 認定トレーナーの廣瀬隆博がお届けしました。また次の記事でお会いしましょう。

Discussion