AIエージェントのGWS権限管理設計ガイド

MCPサーバーやClaude Agent SDKなどのAIエージェントがGoogle Workspaceに接続するケースが企業環境でも増えつつある。どのリソースにどこまでのアクセスを許可するかの設計基準が、権限管理の起点になる。

この記事を読んだほうが良い人

• MCP（Model Context Protocol）サーバーやClaude Agent SDKを使ってAIにGWS操作をさせている情シス担当者
• GAS（Google Apps Script）にAI機能を組み込み、DriveやGmailを自動処理させている方
• AIエージェント Google Workspace 権限管理の社内設計基準をこれから整えたい方
• CAA（Context-Aware Access：コンテキストアウェアアクセス）がAIエージェントに対してどう機能するかを確認したい方

「誰として動くか」が設計の分岐点

AIエージェントのGWSアクセス設計は、接続方式の選択から始める。方式は大きく2種類に分かれ、この選択が以降の権限設計全体の前提になる。

ユーザー委任型（3-legged OAuth：ユーザー・クライアント・認可サーバーの三者が関与するOAuth 2.0フロー）: 特定のユーザーがアプリにOAuthの権限を付与し、そのユーザーの代理としてエージェントが動く。MCPサーバーにユーザーがGoogleアカウントでサインインして権限を渡すケースがこれにあたる。エージェントの動作は「そのユーザーとして」になり、ユーザーが持つ権限の範囲内に収まる。

サービスアカウント型: 人間のユーザーを介さず、Google CloudのサービスアカウントというID（機械専用のアカウント）でAPIを呼び出す。Admin SDKでGWS管理操作を自動化したり、GASをDomain-Wide Delegation（ドメイン全体の委任、以下DWD）で動かすケースが該当する。

具体例で考えると整理しやすい。「社員がチャットで話しかけると、そのユーザーのGmailを参照して返答するMCPベースのAIアシスタント」はユーザー委任型が自然な設計だ。ユーザー自身が認可するため、そのユーザーが読めるメールだけにアクセスが限定される。一方、「夜間バッチで全社員のカレンダーを集計してSheetsに書き出す自動化スクリプト」は、誰かのログインセッションに依存させるべきでなく、サービスアカウント型が適切になる。

ユーザー委任型はアクセス可能なリソースが実行ユーザーの権限に縛られる一方、サービスアカウント型はDWDと組み合わせることで管理者レベルの広範な操作が可能になる。広域操作が可能になる分、設計の緻密さが求められる。

この2種類は使える制御手段が根本的に異なる。設計の最初に「どちらとして動かすか」を決めることが、以降の判断を整理する鍵だ。

AI エージェント Google Workspace 権限管理の設計マトリクス

MCP・GAS・SDKのそれぞれについて、認証方式とCAA（Context-Aware Access）の効果、推奨する主な制御手段を整理した。

エージェントタイプ	認証方式	CAAポリシーの効果	主な制御手段
MCPサーバー（ユーザー認可）	ユーザー委任OAuth	◎ 認可フローに適用される	OAuthスコープ制限 + CAA
GAS（ユーザー実行コンテキスト）	ユーザーOAuthセッション	◎ 実行ユーザーのCAAが効く	スコープ定義 + 実行権限設計
GAS（DWDあり）	サービスアカウント + DWD	△ 直接適用なし	DWD委任範囲の限定 + API制御
Claude Agent SDK / Admin SDK	サービスアカウント	△ 直接適用なし	専用SA作成 + スコープ制限 + 監査ログ確認

CAAが機能するのは、人間ユーザーの認証フローにエージェントが乗っているときに限られる。サービスアカウント経由のAPIコールにはユーザーの認証フローが介在しないため、CAAポリシーの直接適用対象ではない。設計の出発点として、この区別を明確にしておく。

このマトリクスの実務的な使い方は、「新しいAIエージェントを社内で使い始めるとき、まずこの4行のどこに当てはまるかを確認する」ことだ。当てはまる行が決まれば、その行の「主な制御手段」から設計の着手点が見える。既存エージェントのOAuthスコープ棚卸しや、DWD設定の見直し優先度付けにも活用できる。

社内にすでに複数のAIエージェントが走っている場合、各エージェントがどの行に属するかを一覧化することを勧める。ユーザー委任型とサービスアカウント型が混在しているケースでは、CAAが効いている範囲と効いていない範囲を可視化するだけで、次に手を打つべき箇所が明確になる。

BeyondCorp/CAAをユーザー委任型エージェントに組み込む

ユーザー委任型のエージェントに対してCAA（Google WorkspaceのBeyondCorp実装）を適用する場合、設計の軸は「どの状態のデバイス・ネットワークからOAuth認可を完了できるか」を絞り込むことになる。

たとえば、管理対象外デバイスからGmailの読み取りスコープを持つMCPサーバーへの権限付与をブロックする制御が、CAAのアクセスレベル設定で実現できる。これはAIエージェント専用の機能ではなく、既存のCAAポリシー設計の延長線上にある。

CAAのアクセスレベルには、デバイス管理状態・OSバージョン・企業VPNへのネットワーク接続・Endpoint Verificationの証跡など、複数の条件を組み合わせられる。AIエージェント向けに特別な設定項目があるわけではなく、「OAuth認可を行うユーザーのデバイスとネットワーク状態」を条件として使う設計になる。実際には「管理対象デバイスからのみOAuth認可を許可する」アクセスレベルを作り、MCPサーバー等のアプリに対してそのアクセスレベルを要件として設定する形が典型的だ。

設計上の注意点として、一度発行されたOAuthアクセストークンはトークンのライフタイム内で有効なため、CAAポリシーは認可の入口を制御するものであり、動作中の処理をリアルタイムで止めるツールではない。「入口を絞る制御」と「継続的な動作監視」は別の仕組みとして設計する必要がある。

また、CAAポリシーを適用できるアプリはGoogle Workspaceのコアアプリ（Gmail・Drive・Calendar等）と、Cloud Identity Premium経由でオンボードしたSAML/OIDCアプリが中心となる。MCPサーバー自体をCAAポリシーの直接ターゲットに指定するUI設定は現時点では存在しない。実際の仕組みは、MCPサーバーがGmailやDriveへのOAuth認可を要求するタイミングで、それらのコアアプリ側に設定されたCAAポリシーが評価されるという形になる。なお、アプリ単位でのCAA設定は現時点では未対応で、適用は組織単位が前提となる。

CAAは「ゼロトラストの入口ゲート」として有効だが、それ単体でAIエージェントのリスクをすべてカバーできるわけではない。特に、正当な権限を持つユーザーが意図せず過剰なスコープをAIエージェントに付与してしまうリスクはCAAでは防げない。OAuthスコープの審査・制限（管理コンソールのAPI制御から特定スコープを持つアプリを承認制にする設定）と組み合わせることで、多層防御の構成になる。

サービスアカウント型エージェントのゼロトラスト設計

CAAが直接かからないサービスアカウント型のエージェントには、ゼロトラストの考え方を3つの原則で実装する。

原則1：ワークロード単位でサービスアカウントを分ける

GASのDWD用SAとAdmin SDK操作用SAを同一アカウントで兼用しない。1エージェント1サービスアカウントを原則にすると、不審な動作が発生したとき影響範囲を特定しやすくなる。複数の業務フローで1つのSAを共用する構成では、1箇所の過剰スコープが全フローのリスクになる。

実際の分離方針として、エージェントの「目的」単位でサービスアカウントを作成することが起点になる。「Sheetsへの週次レポート書き込み用」「カレンダー空き時間照会用」「Gmailドラフト作成用」のように目的を名称に含めたSAを用意すると、スコープのレビュー時に意図の確認が容易になる。名前の付け方ひとつで、半年後の棚卸し工数が変わる。

原則2：DWDの委任範囲を最小スコープに絞る

DWDを設定する際、付与するOAuthスコープはそのエージェントが実際に必要とする操作だけに限定する。Sheetsへの書き込みだけで完結するフローなら、GmailやDriveのスコープは付与しない。広域スコープ（ドライブ全体の読み書きやGmail全操作など）を使う前に、操作単位の細かいスコープで実現できないかを先に検討する。

スコープが「現状で何かに使われているかどうか不明」という状態が最もリスクが高い。DWD設定時にその場で「このスコープで何をするか」をスプレッドシート等に記録しておくと、後の確認コストを下げられる。設定した意図が残っていない構成は、棚卸し時に削除可否を判断できず、結果として過剰権限が放置される原因になる。

原則3：OAuthログイベントで定期的に棚卸しする

Google Workspaceの監査と調査機能から確認できるOAuthログイベントには、サービスアカウントや外部アプリがどのスコープをいつ使ったかの記録が残る。長期間使われていないスコープを持つアプリや、予期しないリソースへのアクセスが記録されている場合は、即時の棚卸しと権限削除が必要になる。管理コンソールのAPI制御セクションで委任済みのサービスアカウントとスコープを定期確認する運用を組み込む。

棚卸しの頻度は、AIエージェントの数と変化の速さに合わせて決める。月次で確認する運用が現実的なラインだが、新しいエージェントを本番環境に追加したタイミングには都度確認を行うようにしておく。特に確認すべきポイントは2点だ。

• 目安として過去90日間でアクセスのなかったスコープがないか
• 申請時の用途説明と実際の使用スコープに乖離がないか

この2点を定期的に確認するだけで、権限の肥大化を早期に検知できる。

GASをAIエージェント化するときの追加注意

GASはGWSに密着した実行環境のため、権限設計のコストが低く見えやすい。しかし「Gemini API + GAS」構成でAIエージェント化が進むと、スクリプトが参照・更新するリソース範囲も広がる。

GASのOAuthスコープはプロジェクトのマニフェストファイル（appsscript.json）で明示的に宣言できる。宣言しない場合はGASエディタが自動推測したスコープが使われるが、AIを組み込んだスクリプトでは処理の経路が動的になりやすいため、自動推測スコープが必要以上に広くなる可能性がある。スコープは明示宣言し、実際に使う範囲に絞って管理する方針を推奨する。

DWDを使わずユーザー実行コンテキストで動かす場合でも、マニフェストに不要なスコープが混入していないか確認する。AIの処理フローが拡張されるたびに、スコープの棚卸しを合わせて行う習慣が継続的な権限管理の土台になる。

また、GASを定期実行トリガで自動化する場合、実行ユーザーのアカウント状態（停止・削除等）によって動作が変わる点も設計時に考慮する。特定ユーザーのアカウントに紐づく実行コンテキストで全社データを処理しているケースは、そのユーザーが退職・異動した際に動作が止まるリスクがある。継続性が重要なバッチ処理には、サービスアカウント型とユーザー実行コンテキスト型の使い分けを、可用性の観点からも整理しておく。

さらに、Gemini APIをGASから呼び出す場合、GASスクリプトがGoogle Cloudプロジェクトに紐づいていると、GWSの権限管理とGCP側のIAM管理が交差する。両側の権限構成を別々に把握しておくことが、設計ドキュメントとして記録すべき最低ラインになる。GASの実行ログとGCPの監査ログを両方追う体制を、エージェントの本番投入前に準備しておくと後から楽になる。

まとめ：設計の判断軸と次のステップ

AIエージェントのGWS権限管理は、接続方式（ユーザー委任かサービスアカウントか）の選択から始まる。ユーザー委任型にはCAAによる入口制御が有効で、サービスアカウント型にはOAuth API制御とDWD委任範囲の絞り込みが主軸になる。

判断に迷ったときは、次の3問を自問するところから始めるといい。

• そのエージェントは「誰のアカウントとして動くか」を言語化できるか
• 付与するスコープは「この操作だけに必要か」と問い直せているか
• 3ヵ月後に「なぜこのスコープがあるか」を説明できる記録があるか

この3問に答えられない構成は、見直しが必要なサインだ。特にAIエージェントは接続先やデータ参照の範囲が人間の手動操作より広がりやすく、「動いているから問題ない」という判断は通じにくい。

どちらの方式を選ぶにしても、スコープの最小化・アカウントの専用化・定期棚卸しの3点は共通して必要になる。AIエージェントの数が増えるほど、見落とした過剰権限のリスクは積み重なる。

Admin SDKによるプロビジョニング設計（静的な権限付与）が整っている組織でも、ランタイムの動的制御設計は別の課題として残る。本記事の判断軸を、社内のAIエージェント管理ポリシーに組み込む第一歩として活用してほしい。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。