Google Workspace 公式の MCP (Model Context Protocol) サーバーが 2026 年 5 月にパブリックデベロッパープレビューとして公開され、AI エージェントが Workspace データにアクセスする際の OAuth スコープ設計が情シスの実務課題になっています。この記事では、MCP OAuth スコープの最小権限判定基準と、Admin SDK Reports API を活用した監査ポリシーの制度化手順を整理します。
この記事を読んだほうが良い人
- Claude や GPT などの AI エージェントを MCP 経由で社内 Google Workspace に接続している情シス担当者
- 付与している OAuth スコープが最小権限になっているか確認したい方
- AI エージェントのトークン利用状況を定期的に監査する仕組みを整備したい方
- MCP サーバー導入後の運用ポリシーを社内文書として整備したい方
MCP と OAuth スコープ最小権限の基本を確認する
MCP (Model Context Protocol) は、AI エージェントと外部ツール・サービスを標準インターフェースで接続するプロトコルです。Anthropic が 2024 年末に仕様を策定し、2025 年以降に主要 AI エージェントへの採用が進みました。
Google Workspace との連携では、エージェントは OAuth 2.0 (Open Authorization 2.0) でユーザーの代わりにトークンを取得し、Gmail・Drive・Calendar などの API にアクセスします。MCP 仕様（OAuth 2.1 を参照）では、クライアントが操作に必要な最小限のスコープのみを要求することを推奨しています。
スコープが過大な状態で運用を続けると、2 つのリスクが高まります。
- エージェント側でインシデントが発生した際に、意図しない範囲のデータが操作される
- 誰がどのスコープを使っているか追跡できず、セキュリティ監査で説明責任を果たせない
「動作確認時に広めのスコープを使って、そのまま本番環境に持ち込む」パターンは MCP 導入初期に特に起きやすい問題です。
MCP サーバーの設計段階での権限モデル全体については、DRASENAS の記事「Google Workspace MCPサーバーのガバナンス設計」で解説しています。本記事はその続きとして、スコープの粒度選定と監査の仕組みに絞って掘り下げます。
Google Workspace サービス別スコープ比較表
Google Workspace 公式の MCP サーバー設定ドキュメントおよび各サービスの API リファレンスをもとに整理しました。スコープ末尾は https://www.googleapis.com/auth/ を省略しています（mail.google.com/ のみ異なる形式）。
Gmail スコープ
| スコープ（末尾部分） | アクセス範囲 | MCP エージェントへの推奨 |
|---|---|---|
gmail.metadata |
件名・送受信者などメタデータのみ（本文なし） | ◎ 最も限定的 |
gmail.readonly |
全メール読み取り | ○ 読み取り専用で十分な場合 |
gmail.compose |
下書き作成＋送信（読み取り不可） | ◎ MCP エージェントの標準書き込みスコープ |
gmail.send |
送信のみ（読み取り不可・下書き保存不可） | △ gmail.compose が使えない用途限定 |
gmail.modify |
読み取り・作成・送信・ラベル変更（恒久削除不可） | △ 書き込みが不可避の場合のみ |
mail.google.com/ |
完全アクセス（削除含む） | ✕ AI エージェントへの付与禁止 |
Google Drive スコープ
| スコープ（末尾部分） | アクセス範囲 | MCP エージェントへの推奨 |
|---|---|---|
drive.metadata.readonly |
ファイルのメタデータのみ（内容なし） | ◎ 最も限定的 |
drive.file |
アプリが開いたファイルのみ（per-file アクセス） | ◎ ファイル操作が必要な場合の第一選択 |
drive.readonly |
全ファイルの読み取り | △ 全体参照が必要な場合のみ |
drive |
全ファイルへの完全アクセス | ✕ AI エージェントへの付与禁止 |
Google Calendar スコープ
公式の Google Workspace MCP サーバーが採用しているスコープ（calendar.events.freebusy・calendar.events.readonly・calendar.calendarlist.readonly）を基準として整理しています。
| スコープ（末尾部分） | アクセス範囲 | MCP エージェントへの推奨 |
|---|---|---|
calendar.events.freebusy |
空き時間の照会のみ（予定詳細なし） | ◎ スケジュール調整専用に |
calendar.events.readonly |
全カレンダーのイベント閲覧 | ○ 閲覧のみで十分な場合 |
calendar.calendarlist.readonly |
カレンダー一覧の読み取り | ○ カレンダー選択が必要な場合 |
calendar.events |
全カレンダーのイベント編集 | △ 書き込みが不可避の場合のみ |
calendar |
完全アクセス（共有設定変更含む） | ✕ AI エージェントへの付与禁止 |
スコープ選定の判断フロー
比較表だけでは実際に何を付与するか迷うことがあります。次の 3 ステップで判定を進めます。
ステップ 1：タスクを動詞で書き出す
エージェントが行う操作を「読む」「送る」「作成する」「削除する」で分解します。「削除」が不要なら modify ではなく readonly と send の組み合わせに留められます。「本文は不要でメタデータのみ」なら gmail.metadata で十分です。動詞リストを作ることで、過大スコープを付与する理由がなくなります。
ステップ 2：最も制限されたスコープから試す
readonly や metadata を付与して動作確認し、不足した部分だけを後から追加する順序を取ります。最初から modify や drive を付与して「動いた」で終わりにしない運用を社内ルールとして明文化します。
ステップ 3：✕ スコープは情シスマネージャーの承認を必須にする
mail.google.com/・drive・calendar のフルアクセス系は、情シスマネージャーの明示的な承認なしに付与しないルールを設けます。開発者が「とりあえず広めに」付与するケースを制度的に防ぐのが目的です。
Admin SDK Reports API で OAuth 利用状況を監査する
付与したスコープが実際にどう使われているか、または予期しないスコープ要求が発生していないかは、Admin SDK (Software Development Kit) の Reports API で確認できます。Reports API の token アプリケーションログには、OAuth トークンの発行・承認・失効といったイベントが記録されます。
公式ドキュメントで確認できる主なトークンイベントの種類は次のとおりです。
authorize：アプリへのアクセス権が認可された（付与スコープが記録される）revoke：アクセス権が失効したactivity：実際に API が呼び出された（api_name・method_name が記録される）deny：アクセスが拒否された
以下は GAS (Google Apps Script) から直近 30 日間の OAuth 認可イベントを取得するサンプルです。Admin SDK の拡張サービス（AdminReports）をプロジェクトで有効にした上で実行します。GAS エディタの「拡張機能 > Advanced Google Services」から Admin SDK API をオンにすると利用可能になります。
function auditMcpOAuthTokens() {
// 集計期間を設定（直近 30 日）
const now = new Date();
const start = new Date(now.getTime() - 30 * 24 * 60 * 60 * 1000);
const params = {
startTime: start.toISOString(),
endTime: now.toISOString(),
eventName: 'authorize', // 認可イベントのみに絞る
maxResults: 200
};
const result = AdminReports.Activities.list('all', 'token', params);
if (!result.items || result.items.length === 0) {
Logger.log('直近 30 日間に OAuth 認可イベントなし');
return;
}
result.items.forEach(function(item) {
const evts = item.events || [];
evts.forEach(function(evt) {
const p = {};
(evt.parameters || []).forEach(function(param) {
p[param.name] = param.value || (param.multiValue || []).join(', ');
});
Logger.log(JSON.stringify({
time: item.id.time, // イベント発生時刻
actor: item.actor.email, // 認可したユーザー
app_name: p.app_name, // アプリ（エージェント）名
client_id: p.client_id, // OAuth クライアント ID
scope: p.scope // 付与されたスコープ
}));
});
});
}
このコードで取得できる主な情報は 3 点です。
actor.email：誰がトークンを認可したかapp_name/client_id：どの MCP エージェントが認可されたかscope：実際に付与されたスコープの文字列
scope フィールドに drive（フルアクセス）や mail.google.com/ が含まれるものをフラグ立てする処理を追加すると、禁止スコープの早期検知につながります。出力をスプレッドシートに蓄積するだけでも、四半期レビューの監査証跡として機能します。
なお、app_name・client_id・scope のパラメータ名は Admin SDK Reports API 公式リファレンスの Token イベント付録が一次ソースです。
監査の着眼点
ログを見るときに確認すべきポイントは 3 点です。
まず申請スコープとの照合です。情シスが承認したスコープと scope フィールドの値が一致しているかを突き合わせます。未申請スコープが検出された場合は即調査の対象になります。
次に不活性トークンの洗い出しです。authorize イベントはあるのに activity イベントが 90 日以上発生していないアプリは、失効候補として扱います。使われていないスコープを残しておくと、将来の侵害時に不必要な被害範囲が生じます。
そしてセッション存続時間の確認です。OAuth トークンの有効期間は Workspace 管理コンソールのセッション制御設定で上限を変更できます。AI エージェント向けには短いセッション（1〜8 時間程度）を推奨します。長期トークンを放置するとインシデント発生時の被害範囲が広がるため、トークン有効期間の設定は最小権限スコープと並んで管理すべき項目です。
社内ポリシー文書化のための例文テンプレート
スコープ設計と監査の仕組みが整ったら、社内ルールとして文書化します。明文化することで「情シスに確認せずに広いスコープを付与した」という事後対応を制度的に防げます。以下のテンプレートをそのままコピーして使ってください。
MCPエージェント OAuth スコープ管理ポリシー（テンプレート）
制定日: YYYY 年 MM 月 DD 日 版: 1.0
1. 付与の原則
AI エージェント（MCP サーバーを介するものを含む）への OAuth スコープ付与は最小権限を原則とし、業務遂行に不可欠な最小スコープのみを付与する。
2. 禁止スコープ（情シスマネージャー承認なしに付与してはならない）
https://mail.google.com/（Gmail 完全アクセス）https://www.googleapis.com/auth/drive（Drive 完全アクセス）https://www.googleapis.com/auth/calendar（Calendar 完全アクセス）
3. 申請・承認フロー
| 変更種別 | 承認権者 |
|---|---|
| 新規スコープ付与（推奨スコープ範囲内） | 情シス担当者の判断で可 |
| 新規スコープ付与（禁止スコープ含む） | 情シスマネージャーの承認必須 |
| 既存スコープの拡張 | 情シスマネージャー＋事業責任者の連署 |
| インシデント対応時の即時遮断 | 先に遮断し事後に報告・申請 |
4. 定期監査
- 月次：GAS + Admin SDK Reports API による
tokenログの自動収集・禁止スコープの検知 - 四半期：スコープ台帳（スプレッドシート）と管理コンソール上の承認済みアプリとの突合せ
- 年次：ポリシー全体の見直しと禁止スコープリストの更新
承認フローを Google フォームや Slack ワークフローと連携させると、申請漏れを減らせます。「スコープの変更は情シスに通知する」仕組みを先に作っておくことで、エージェントが増えてからの管理コストが大きく下がります。
まとめと情シスの次のアクション
この記事で整理した内容を 3 つのアクションに落とし込みます。
最初のステップは棚卸しです。現在稼働している MCP エージェントが使っているスコープを Reports API で列挙します。「何があるかわからない」状態のまま運用を続けると、インシデント発生時の調査コストが跳ね上がります。棚卸しなしに最小権限の議論は始まりません。
次のステップはスコープの絞り込みです。本記事の比較表を参照しながら、drive や gmail.modify がそのまま使われているケースを優先的に特定して、最小スコープに切り替えます。切り替え後は一定期間 Reports API のログを監視し、エージェントの動作に支障がないことを確認してから本番定着とするのが安全な進め方です。
最後は制度化です。テンプレートをベースにした社内ポリシー文書を作成し、四半期レビューのスケジュールをカレンダーに入れます。MCP を使う AI エージェントは今後さらに増えるため、「スコープは情シスが管理する」という仕組みを今のうちに回せる状態にしておくことが、長期的な権限肥大化の予防になります。スコープ台帳をスプレッドシートで管理し始めるだけでも、次の四半期レビューで「誰が何を許可したか」を追跡できる状態になります。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。