連携ガイド
Google Workspace管理をAIエージェントに安全に連携する｜権限・承認・監査の設計
Google Workspaceの管理をAIエージェントにつなぐと、ユーザーの棚卸し、グループ構成の点検、入退社に伴う整合チェックを自動化できます。便利な一方で、ユーザーの作成・削除や組織部門の変更は、組織全体に効く極めて影響の大きい操作です。連携の前に権限設計を厳格に決めておくべきです。
Google Workspace（管理）連携でまず起きる問題
Google Workspace（管理）をそのままAIエージェントに渡すと、典型的に次の問題が起きます。
- OAuthトークンの散在：プロンプトやローカルのMCP設定に置いた認証情報は、漏れたときにGoogle Workspace（管理）の操作が丸ごと露出します。
- 読み取りと書き込みが同じ扱い：参照も更新も、エージェントから見れば同じ「ツール呼び出し」です。区別がなければ、AIは同じ気軽さで実行します。
- 組織全体に効く操作：ユーザー削除や組織部門の変更は、社員のアクセスを一斉に止めうる操作です。
読み取りは自由に、書き込みは承認制に
実務的な原則はシンプルです。参照系は自由に、更新系は人間の承認を経てから。Google Workspace（管理）の操作をこの2種類に仕分けます。
- 自由に実行してよい（読み取り）：ユーザー・グループ・組織部門・メンバーの参照と一覧。棚卸しや整合チェックはここで完結します。
- 承認を挟む（書き込み）：ユーザーの作成・更新・削除、グループの作成・削除・更新、組織部門の作成・削除、メンバーの追加・変更。いずれも高リスクです。
こうしておけば、AIエージェントは分析や下書きまで一人で走り切り、外部や本番に効く操作の直前だけ担当者が確認する、という運用になります。
生のOAuthトークンをエージェントに渡さない
もう一つの要点は認証情報の置き場所です。Google Workspace（管理）のOAuthトークンをエージェントのランタイムやプロンプトに置くのは避けます。 認証情報はサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡す。 こうすれば、あるワーカーのトークンが漏れても、失効はそのワーカーの範囲に限定でき、Google Workspace（管理）本体の認証情報を作り直す必要はありません。
すべての操作を監査ログに残す
管理操作を扱う以上、「どのワーカーが・どのユーザー/グループに・何をしたか」を後から追えることは必須です。 承認された操作もブロックされた操作も、ワーカー・ロール・ツール・接続・リクエスト・結果まで記録しておけば、 後からの調査や説明責任にそのまま使えます。
Grantryでの実現方法
Grantryは、AIエージェントと業務ツールの間に入る権限レイヤーです。 Google Workspace（管理）を含むMCP対応のサービスに対して、ワーカーごとにスコープ付きトークンを1つ発行し、 読み取りは自由に、ユーザー作成・削除などの書き込みは承認ゲート越しに、そして全コールを監査ログに残します。 Claude CodeやCodexなどのMCPクライアントを、ワーカートークン付きでGrantryのエンドポイントに向けるだけで、 エージェント側のコード変更なしに始められます。
よくある質問
AIエージェントにGoogle Workspace（管理）のOAuthトークンを直接渡しても大丈夫ですか？
推奨しません。プロンプトやローカルのMCP設定に置いたOAuthトークンは、Google Workspace（管理）でできる操作すべて（例：ユーザーの作成・削除）を許す常時オファーになります。OAuthトークンはサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡す設計が安全です。
Google Workspace（管理）のユーザーの作成・削除をAIに自動実行させても問題ないですか？
ユーザーの作成・削除は影響が大きい、または戻せない書き込みです。ユーザーの参照などの読み取り・分析は自由に実行させ、ユーザーの作成・削除は人間の承認を経てから実行する承認ゲートを挟むのが実務的です。
管理APIをAIに開放するのは危険では？
だからこそ権限レイヤーが要ります。参照系（棚卸し・整合チェック）はAIに任せ、ユーザーやグループの作成・削除・変更は必ず承認ゲートに載せます。全操作を監査ログに残すことで、影響の大きい管理操作でも統制下で自動化できます。