Claude×MCP でOAuthスコープ監査を自動化する設計

Google Workspace の Admin SDK Reports API は、組織内での OAuth (Open Authorization) 認可イベント（アプリ承認・スコープ付与・取り消しなど）をプログラムから取得できる仕組みを提供しています。この記事では、その API を MCP (Model Context Protocol) サーバー経由で Claude に接続し、月次の OAuth スコープ棚卸しを自動化する設計フローと判断軸を整理します。

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

• NotebookLM・Claude・ChatGPT などの AI ツールが社員の GWS (Google Workspace) アカウントに OAuth 接続しているが、スコープの棚卸しが追いつかない情シス担当者
• 月次の OAuth 監査を手動でこなしているが、件数増加に限界を感じている方
• MCP と Claude を使った自動化フローの設計イメージを掴みたい方
• AI ツールのシャドー利用（情シスが把握していない状態での OAuth 接続）を早期に検知したい方

手動チェックの限界と自動化への移行判断

AI ツールの組織利用が広がるほど、管理コンソールのアプリアクセス制御に登録されるサードパーティアプリの数が増えていきます。一覧の確認は画面から行えますが、「先月と比べて何が変わったか」「どのスコープが新たに付与されたか」を継続的に把握するには、目視確認を繰り返すしかありません。

これがいわゆるシャドーAI検知の難しさです。シャドーAIとは、情シスが承認フローを経ずに社員が個別に OAuth 接続した AI ツールを指します。接続された時点では何も警告が出ないため、気づかないまま数か月が経過するケースがあります。

自動化への移行タイミングを判断する目安として、筆者は「OAuth 接続済みアプリが 20 件を超えた時点」を一つの基準として持っています。これ以上になると、前月比較を手動で行うことが現実的でなくなるためです。頻度についても「月次以上の定期チェックが必要か」という観点で判断するとよいです。件数が少なく四半期に 1 回程度確認すれば十分な組織であれば、自動化の設計コストをかけるより手動で回す方が合理的です。

OAuthスコープ監査 自動化フローの全体設計

自動化フローは大きく 4 つのコンポーネントで構成されます。

[Admin SDK Reports API]
        ↓  token アクティビティ取得（Authorize / Revoke / Activity イベント）
[MCP サーバー（Reports API ラッパー）]
        ↓  ツールとして公開
[Claude Agent（スコープ異常判定）]
        ↓  判定結果のサマリ
[Slack 通知 / スプレッドシート記録]

各コンポーネントの役割を整理します。

Reports API: Admin SDK Reports API の token アプリケーションで、組織ドメイン内の OAuth 関連イベントを取得します。イベント種別は Authorize（認可）、Revoke（取り消し）、Request（要求）、Deny（拒否）、Activity（API アクセス）の 5 種類で、いずれもアプリ名・クライアント ID・クライアント種別を含みます。Authorize・Revoke・Request・Deny の 4 種類にはさらに付与スコープの情報（scope / scope_data）が含まれます（公式リファレンスより）。取得に必要な権限は監査レポートへの読み取りアクセスのみで、書き込み権限は不要です。

MCP サーバー: Reports API を Claude から呼び出せるツールとして公開するレイヤーです。Claude が直接 Google API を叩くのではなく、MCP サーバーを経由してデータを受け取ります。このレイヤーを挟むことで、Claude に渡すデータの範囲と粒度を設計段階でコントロールできます。

Claude Agent: 取得したアプリ一覧とスコープ一覧を受け取り、異常の判定とサマリ生成を担います。ルールベースの条件分岐ではなく、「このスコープは用途と比較して過大ではないか」という定性的な判断もできる点が特徴です。

通知・記録: Claude の出力を Slack の Webhook 経由で担当者に通知するか、スプレッドシートに月次記録として蓄積します。監査ログ全般を Claude で分析する汎用フローについては、DRASENAS の記事「GWS監査ログをMCPで自動分析：Claude月次レポート設計」で詳しく扱っています。

MCP サーバーに付与するスコープの設計

MCP サーバーが Reports API にアクセスするためには、OAuth クライアントに適切なスコープを付与する必要があります。

token アクティビティ取得に必要なのは監査レポートへの読み取りアクセスのみです（公式リファレンスより確認済み）。他の監査ログ（ドライブ操作やログインイベントなど）を取得する予定がなければ、このスコープだけで足ります。

スコープ設計で意識しておきたい原則は 3 つです。

• 読み取り専用を原則とする: 棚卸し自動化に必要なのはデータ取得のみです。アプリの承認・取り消し操作はスコープに含めず、人の判断が入るフローとして別に設計します
• 将来の拡張に備えて事前にスコープを広げない: 必要になった時点でスコープを追加する運用にします。拡張見込みを理由に広めに取るのは最小権限の原則に反します
• MCP サーバー自体も監査対象に含める: 棚卸し自動化を担う MCP サーバーが過大スコープを持つのは本末転倒です。月次棚卸しのリストに MCP サーバーの OAuth クライアントを明示的に含めてください

MCP サーバー側の権限設計の全体については、DRASENAS の記事「MCPサーバーOAuthスコープの最小権限設計と監査ポリシー」を参考にしてください。

Claudeによるスコープ異常判定の設計

Claude にどんな判断をさせるかが、このフローの品質を左右します。

スコープ過大検知の判断フロー

以下は、Claude に渡す判定ロジックの設計フローです。

判定順序	判定条件	Claude の判定内容
1	アプリ名が承認済みリストに含まれるか	未知アプリ → 新規接続として優先アラート
2	スコープに書き込み系（modify / delete / insert 等）が含まれるか	含まれる場合 → 次の判定に進む
3	アプリの用途と書き込みスコープが一致するか	不一致 → 過大スコープとしてフラグ
4	前月比較でスコープが拡大しているか	拡大あり → 変化検知としてフラグ
5	管理者以外のユーザーが広いスコープを認可しているか	該当あり → 承認フロー外の認可としてフラグ

Claude への指示は「アプリ名と付与スコープのリストを渡し、情シス担当者が要確認すべきアプリを優先度高・中・低で分類してサマリを返せ」という形が基本です。ルールを細かく列挙するより、「情シスが気にするのはどういうケースか」を文脈で説明する方が判定精度は高くなります。

承認済みリストの管理

スコープ異常判定の基準となる「承認済みアプリリスト」は、どこかに管理する必要があります。実務的な選択肢は次の 2 つです。

• スプレッドシート管理: 承認済みアプリ名とスコープを Google スプレッドシートで管理し、MCP サーバーからも参照できる形にします。変更履歴の追跡が容易で、情シス以外のメンバーも内容を確認しやすいのが利点です
• プロンプト内に直接記載: 件数が少ない段階では、承認済みアプリ一覧を Claude への指示プロンプトに直接含める方法もあります。シンプルですが、件数が増えると管理が難しくなります

100 名規模の組織では承認済みアプリが数十件になることも珍しくないため、スプレッドシート管理の方が長期運用に向きます。

手動 vs 自動：使い分け基準

自動化が常に最善とは限りません。組織の規模や運用頻度に応じた使い分けの基準を整理します。

状況	推奨アプローチ	理由
組織規模 15 名以下	手動（四半期ごと）	件数が少なく、設計コストの方が高い
新規 AI ツールの導入承認フロー	手動（都度確認）	承認判断には人の目が必要
月次定期棚卸し（30 名以上）	自動化	繰り返しの集計・比較は自動化が適切
シャドーAI の早期検知	自動化（週次も可）	新規接続アプリを即時に検知する必要がある
スコープ変化の継続監視	自動化	差分を毎回人が確認するのは現実的でない
全社 AI ガバナンス整備	自動 + 手動の組み合わせ	自動で拾い上げ、判断は人が行うフローにする

Google Workspace OAuth棚卸しを月次で回すための注意点

自動化フローを月次運用に乗せる際に、事前に押さえておくべき点を 3 つ挙げます。

ログ保持期間の確認

Admin SDK Reports API のログ保持期間は最大 180 日です（公式仕様）。月次で回す限り問題なく取得できますが、四半期・半期での傾向比較を後から行いたい場合は、BigQuery などへの転送設計を別途検討してください。

管理者権限の範囲

token アクティビティの取得にはドメイン管理者の権限が必要です。MCP サーバーに付与するサービスアカウントが適切な管理者ロールを持っているか、最小権限の原則に沿っているかを事前に確認してください。

自動化の目的を「補助」に絞る

Claude の判定は「優先度付きの候補提示」にとどまります。最終的な承認・取り消しの判断は情シス担当者が行います。月次レポートを Slack に流すだけでなく、担当者がレビューして結果を記録する運用ルールをセットで設計することを推奨します。自動化の目的は「確認漏れをなくす」ことです。人の判断を排除する仕組みにするのは、特に認可・取り消しのオペレーションでは避けてください。

まとめ：設計に着手するための 3 つの判断軸

本記事で整理した内容を振り返ります。

まず「自動化が本当に必要か」を見極める判断軸として、「OAuth 接続済みアプリが 20 件超か」「月次以上の頻度でチェックが必要か」の 2 点が基準になります。

自動化に進む場合、フローは Reports API → MCP サーバー → Claude Agent → Slack の 4 段階で構成します。MCP サーバーのスコープは監査レポートへの読み取りに絞り、MCP サーバー自体も棚卸し対象に含めます。

Claude の判定設計は「承認済みリストとの差分確認」「書き込みスコープの用途適合確認」「新規アプリの即時検知」の 3 軸が基本形です。精緻なルール設定よりも、情シスが気にするポイントをコンテキストで説明する書き方の方が実用上は機能します。

AI ツールとの OAuth 接続は今後も増え続けます。件数が管理可能な今のうちに設計の土台を作っておくと、将来のガバナンス整備の工数を大きく抑えられます。

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

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