1. Google MCPを接続したときに起きること
たとえば、来週のチーム進捗会議のアジェンダを AI に作ってもらおうとして、「最近の社内ドキュメントから議題を整理して」と頼んだとします。返ってきたアジェンダの中に、なぜか「来月から A さんが家庭の事情で退職予定」という項目が紛れ込んでいる👉AI は、自分のドライブに置いてあったメンバーとの 1on1 メモまで読みに行っていた——という事故が、方法論として成立し得ます。
AIエージェントを Google Workspace に接続するとき、ユーザの見れる範囲をAIにそのまま見せるというのは一見適切なように見えて、こういった不慮の事故を発生させてしまいます。
Google Driveにはエンジニアにとっての.envファイルのように、ビジネスやチームにとっての機密情報が転がっていることに十分注意しなければいけません。
ナウキャストで LLM エンジニアをしている中目です。
この記事は、Finatext の MCP ゲートウェイ基盤「MCPass」を紹介した前回記事の続編です。前回は AgentCore Gateway・Interceptor Lambda・Credential Broker・監査ログ基盤から成る MCPass の全体構成をお話しし、「外部サービスごとの認証設計は別記事で」という宿題を残していました。
本記事で紹介する Google 連携認証の方式は、MCPass の標準機能として実装されており、Finatext グループでも実際に運用中です。以降、Interceptor Lambda や Credential Broker といった用語は MCPass のアーキテクチャを前提に使っていきます。未読の方はざっと見てから戻ってくると読みやすいと思います。
今回はその宿題のうち、Google Workspace との連携認証を取り上げます。私たちが「AIに渡す権限」をどう切り分け、どう追跡可能にしたか、設計の背景から実装まで掘り下げていきます。
2. 何が起きているのか — AI に渡すコンテキストの取り方
AI を Google Workspace に繋ぐときの設計の論点は、「AI にどのコンテキスト（リソースの集合）を渡すか」 に尽きます。素直に取れる選択肢は 3 つ：
| コンテキスト | 実装手段 | 困りどころ |
|---|---|---|
| ユーザコンテキスト（現在の標準） | ユーザートークン直渡し / DWD impersonate | 本人が見られるものは AI も全部見られる。冒頭の 1on1 メモのように人間に向けて開けた共有まで、AI 経由で意図せず引き出される |
| 全社のみのコンテキスト | DWD で全社公開のみに限定 | 漏洩リスクは下がるが、PRJ 固有フォルダや個人のメモを AI に渡せず、業務利用には限界 |
| 絞り込み済みのユーザコンテキスト（本記事の方式） | AI 専用 SA + Google 共有設定 | 本人が AI に共有したものだけが届く。コンテキスト境界を Google の共有設定そのもので決められる |
加えて、ユーザコンテキスト方式は 監査ログ上で「人間の操作」と「AI の操作」が区別できない という運用課題も残ります（Google 側には「ユーザー A が編集」としか記録されない）。
また、上の 3 つから少しずらして MCP サーバー自身に Google Drive の独自権限を持たせる構成にすると、「本人が Google Drive を開いても見えないはずのフォルダが、MCP 経由なら覗けてしまう」 という古典的な confused deputy に陥ります。AI 側の権限は常に「本人が見えるもの以下」に保つのが大前提です。
3. 方針: 個々人にAI用のアカウントを持たせる
ユーザコンテキスト方式の根本原因は、「AIに見せるもの」をユーザーが選べていないことです。「ユーザーが見られるもの」と「AIに見せていいもの」は本来別物なのに、トークンを共有した瞬間にその境界が消えてしまいます。
なので方針はシンプルです。ユーザーひとりにつき、AI専用のGoogleアカウントを1つ払い出し、ユーザーが明示的に共有したものだけをAIに見せる。 Google Workspaceの世界でこれをやる素直な選択肢が、サービスアカウント（SA）です。
SAはメールアドレスを持ち、Driveやカレンダーの「共有」設定の受け手になれます。ユーザーは普段の共有操作だけで、AIの視界を能動的に決められます。 人事評価フォルダをAI用SAに共有しなければ、AIには永久に見えません。
MCPass ではこの払い出しがボタン 1 つで完結します
ユーザーが GCP コンソールを触って SA を手作業で作る必要はありません。管理画面で有効化すれば、その場で自分専用の SA が自動発行され、表示されたメールアドレスを Google の共有設定に貼るだけで使い始められます。
4. なぜSAなのか — 認可と監査を Google に任せられる
ユーザー本人のトークンを使う構成だと、「このフォルダは AI に見せていいか」を自前で判定する羽目になります。パスに「機密」が含まれていたら弾く、外部公開なら弾く——DLP を再発明することになり、Drive/Docs/Sheets/Calendar と対象が増えるたびに破綻します。SA 方式では SA に共有されているか否か だけが判定基準になり、Google 側の認可にそのまま乗れます。
監査面でも、SA 名義のアクセスは Google ログ上で完全に分離されるので、何か起きたときに「誰の AI が何をしたか」までログから追跡できます。
なお、「AI 用に普通のユーザーアカウントを一人ひとつ発行する」案でも共有単位での絞り込みは同じですが、Google Workspace のライセンス料が社員数 × AI 専用アカウント分かかります。SA は作成・運用ともに無料なのでコスト面でも優位です。
5. 設計 — ユーザーごとに1SA、MCPごとにスコープ
ユーザー単位とMCP単位、二段階で権限を絞る。
- 1ユーザー = 1 SA: 共通SAを使い回すと結局権限が広がってしまうので、ユーザーごとに払い出しています。
- MCPごとにスコープを絞る: 管理画面でMCPサーバーごとに「許可するスコープ」を定義できます。同じユーザーのSAでも、カレンダーMCPに渡すトークンとDrive読み取りMCPに渡すトークンは別物です。
- 管理用SAの権限は最小: ユーザーSAを「作る」権限だけを持たせています。impersonation権限は個別ユーザーSAへのbindingで発生するので、管理用SAにも過剰な権限は集めません。
6. SA のレイヤー構成 — 発行者と実行者を分ける
SA を 2 階層に分けています：
- 管理用 SA（発行者）: ユーザー SA を impersonate する権限だけを持ちます。Google API を直接叩くことはありません
- ユーザー個別 SA（実行者）: Google API を実際に叩く ID。1 ユーザー = 1 SA で払い出し、ユーザーが Google の共有設定で AI に渡したリソースだけにアクセスできます
発行者と実行者を分けることで、管理用 SA の権限が肥大化するのを防ぎ、漏洩時の影響範囲を最小化できます。
7. Google Cloud のクォータ対策
GCPのSAは1プロジェクトあたり初期値100個。設計で正面から対処しています。
- クォータ上限申請で上限を引き上げます。
- マルチプロジェクト構成を初期から組み込み、SA Pool を複数持って分散収容します。
MCPass では、管理画面から複数の GCP プロジェクト（SA Pool）を登録・切り替えできるようにしています。
8. 実装 — トークン発行を Interceptor に閉じ込める
トークン発行は Interceptor 層に集約し、Lambda → WIF → 管理用 SA → ユーザー SA の委任チェーンで鍵レスに発行する。
「ユーザー個別の Google トークンを発行できる能力」をシステムのどこに置くかも、認可の絞り込みと同じくらい大事です。MCP サーバーに Cognito トークンとメールアドレスを渡してしまうと MCP 自身が Google トークンを発行できる状態になり、MCP が侵害されたときに攻撃者がテナント全ユーザー分のトークンを発行できてしまいます。
そこで トークン発行は Interceptor 層に閉じ込めて、MCP サーバーには「スコープを絞った短命のアウトバウンドトークンだけ」を渡す 設計にしました。MCP に流してよい情報はホワイトリスト方式で管理し、Cognito JWT やユーザー情報は届きません。MCP は「来たトークンで動くだけ」のステートレスな存在に保ちます。
加えて、鍵管理を間違えると本末転倒なので SA 鍵ファイルを一切持たない 構成にしています。Interceptor 内の Credential Broker が、前章の 2 階層 SA に対し Lambda → WIF → 管理用 SA → ユーザー SA の委任チェーンで都度短命トークンを発行します。
ランタイムのリクエストフローはこうなります。
ポイント：
- 鍵を持たない: Lambda から WIF 経由で GCP にフェデレーションします。SA鍵JSON はどこにも保存しません。
- WIF は特定 Lambda ARN 限定: Lambda 外からはトークン交換ができない仕組みです。攻撃面をとても小さく抑えられます。
- トークンは短命: 仮に MCP が侵害されても、漏れたトークンの寿命が短ければ被害窓は狭く済みます。鍵ローテーションが運用なしで常時回っているような状態です。
- AgentCore Token Vault も検討しましたが、固定トークンの保管庫としては優秀な一方、今回のように一時トークンを動的発行するユースケースには合わず、採用は見送りました。
9. まとめ
AIを業務に組み込むとき、「人間の権限をそのまま貸す」のは楽ですが、セキュリティ・監査・DLPの全面で持続しません。AIにはAI用の身分証を持たせる。ただしその身分証を発行できる権限は、特定の場所に閉じ込める。 これを Google Workspace 上で素直に実装すると、ユーザーごとにSAを払い出し、トークン発行はインターセプター層に閉じ込め、MCPは「来たトークンで動くだけ」に保つ構成に落ち着きました。運用面でも、SA を無効化するだけで AI の視界をゼロにできるので、剥奪のオペレーションも単純です。
MCPass における外部サービス連携の、Google Workspace に特化した具体例として読んでもらえれば嬉しいです。他のサービス（Snowflake、Atlassian 等）の連携認証についても、追って紹介していく予定です。
Discussion