自社のGoogle Workspaceにアクセスできる AIツールを確認する方法

Google Workspaceへのアクセス権を持つすべてのAIツールは、管理コンソールの [セキュリティ] → [アクセスとデータ制御] → [API制御] → [アプリへのアクセス制御] から確認できます。ここには、AIアシスタント、ブラウザ拡張機能、会議の議事録作成ボットを含め、ドメイン内で認可されたすべてのサードパーティアプリと、各アプリに付与されているGoogleデータへのアクセス範囲が一覧表示されます。

このガイドでは、その手順、コンソールが実際に表示する内容、その限界、そして一覧を最新の状態に保つ方法について説明します。

Google管理コンソールでサードパーティアプリのアクセス状況はどこで確認できますか?

1. スーパー管理者、または「サービス」権限を持つ管理者としてadmin.google.comにサインインします。
2. [メニュー] → [セキュリティ] → [アクセスとデータ制御] → [API制御] に移動します。
3. [アプリのアクセスを管理](コンソールのバージョンによっては [アプリへのアクセス制御] と表示される場合もあります)をクリックします。

表示される一覧は、設定済みのアプリ(組織が明示的にアクセスレベルを設定したアプリ)とアクセスされたアプリ(設定の有無にかかわらず、現在利用されているすべてのアプリ)に分かれています。各アプリについて、以下の情報を確認できます。

• アプリ名、発行元、OAuthクライアントID
• Googleのアプリ確認済みバッジを取得しているかどうか
• Drive、Gmail、カレンダー、Admin Directoryなど、リクエストされている個別のGoogleサービスのスコープ(アプリごとに展開可能)
• ドメイン内で何人のユーザーがこのアプリを認可しているか
• 設定可能なアクセスレベル: 信頼、制限付き、特定のGoogleデータ、ブロック

一覧全体をCSVとしてエクスポートすることも、ドメイン全体ではなく組織部門ごとに異なるアクセスレベルを適用することも可能です。

これらのアプリのうち、どれがAIツールかはどう見分けますか?

Googleのコンソールは、何かを「AI」として明示的にタグ付けすることはありません。表計算ソフトのアドオンであっても大規模言語モデルのアシスタントであっても、OAuthで接続されたすべてのアプリを同じ形式で一覧表示します。実際には、AIツールはAIベンダー名がそのまま表示される場合(OpenAI、Anthropic、Perplexityなど)、会議の議事録ボット(Otter.ai、Fireflies、Fathomなど)、文章作成アシスタント(Grammarly、Jasperなど)、あるいは発行元名からは用途が判断しにくい、より限定的なアドオン(「GPT for Sheets and Docs」「AI Email Writer」など)として表示されます。これらを見分けるには手作業でのパターン認識が必要です。アプリ名と発行元名にざっと目を通し、リクエストされているスコープを確認してください。見覚えのない名前のアプリが drive.readonly や gmail.readonly を要求している場合は、カテゴリを問わず詳しく確認する価値があります。

特定の人物がどのAIツールを認可したかは、どうすれば確認できますか?

上記のドメイン全体のビューでは、あるアプリに利用者がいることは分かりますが、*誰が*、*いつ*それを認可したかは分かりません。それを確認するには、以下の手順を行います。

1. [メニュー] → [ディレクトリ] → [ユーザー] に移動し、該当する人物のアカウントを開きます。
2. [セキュリティ] タブを開きます。
3. [連携しているアプリケーション] までスクロールします。

このセクションには、その特定のユーザーが認可したすべてのサードパーティアプリ、そのアクセスレベル(利用可能なスコープ)、そして認可日が一覧表示されます。ユーザーセキュリティ管理の権限を持つ管理者であれば、このページから直接、これらの許可を取り消すことができます。アプリが*いつ*認可されたかをコンソールが示すのは、この画面だけです。ただし、これは一人ずつ確認する必要があり、一括エクスポート機能もなければ「AIツールのみ」で絞り込む方法もありません。

この作業を手作業で行う場合、実際にはどのような限界がありますか?

ドメイン全体の「アプリへのアクセス制御」画面は件数を集計しますが、ユーザー単位の詳細情報は表示されません。一方、ユーザー単位の「連携しているアプリケーション」画面には詳細情報がありますが、一括表示機能がありません。どちらの画面でも、以下の点は分かりません。

• そのアクセス権が現在も使用されているのか、それとも一度付与されたきり忘れられているのか。
• そのアプリがアクセス可能なデータに対して実際に何を行ったか。コンソールが示すのは*アクセスできる*範囲であって、*実際にアクセスした*内容ではありません。
• 時間の経過とともに状況がどう変化したか。付与されたアクセス権や拡大されたスコープの履歴を追う機能はありません。
• 一覧に表示されたアプリのうち、どれがAIツールかを、自分自身がすべてのベンダー名を認識していない限り判別できません。

連携アプリが数個程度のWorkspaceであれば、両方の画面を手作業で確認していくことも現実的です。しかし、アプリが数十個、ユーザーが数百人を超えると、一覧を最新の状態に保つ作業は一度きりのタスクではなく、繰り返し行う必要のある作業になります。同じ情報を、際限なく再確認し続けることになります。さらに、両方の画面とも適切な権限を持つ管理者ロールが必要です(ドメイン全体のビューには「サービス」権限、ユーザー単位のビューには「ユーザーセキュリティ管理」権限)。複数の管理者を抱えるWorkspaceであっても、誰か一人が定期的に両方を確認する必要があり、たまたま気づいた誰かに自然と任される類の作業ではありません。

手作業による確認では分からないことは何ですか。8200.devはそれにどう答えますか?

手作業による確認で分かるのは、*何がそのデータにアクセスできるか*だけです。*誰がそれを使用したか、いつ使用したか、そして今もそれが必要かどうか*は分かりません。しかし、これらこそが、あるアプリにアクセス権を持たせ続けるべきかどうかを実際に左右する問いです。8200.devのAgent Guardは、接続されているすべてのソースにわたるAIエージェントとOAuth連携アプリを一つの継続的に更新されるビューに一覧化し、それぞれをリスクに応じてスコアリングし、スコープ文字列ではなく分かりやすい言葉でその判定結果を説明します。検出プロセスは読み取り専用です。Google Workspaceへの接続には読み取り専用のDriveメタデータスコープが使用され、上記のより詳細なOAuthアプリの一覧は、組織がOAuthアプリ監査を有効にした場合に利用可能になります。この監査機能は、その特定のビューにGoogleが要求する追加の読み取り専用Admin SDKスコープで再認可を行うものです。ここで説明した内容は、それ自体でアクセス権を変更することはありません。いかなる操作も、組織がそれを実行することに同意するまでは推奨事項にとどまります。

Google Workspace以外にMicrosoft 365、Slack、GitHub、そしてAIベンダー自体にまでこの仕組みがどのように拡張されるかについては、コネクタ一覧をご覧ください。