Google Workspace の Admin SDK Reports API と MCP (Model Context Protocol) を組み合わせることで、月次の監査ログを Claude（Anthropic 製の AI アシスタント）エージェントが直接参照・解釈し、インシデントサマリを自動生成する設計が実現できます。この記事では、Reports API → MCP サーバー → Claude Agent というフローの設計判断軸を情シス担当者の視点で整理します。

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

GWS の監査ログ確認やレポート作成を月末に手動でまとめており、自動化を検討している情シス担当者
MCP や Claude Agent を業務に活用したいが、具体的な設計イメージが掴めていない人
GAS によるスクリプト実行ではなく、AI エージェントが状況を判断するアプローチを試したい人
MCP サーバーの権限設計やセキュリティリスクを事前に整理しておきたい人

Google Workspace 監査ログ MCP 自動化の設計フロー

本記事で扱う設計は、大きく4段階に分かれます。

Reports API でログを取得: Admin SDK の Reports API を使い、GWS (Google Workspace) ドメインの監査ログをプログラマティックに取得します
MCP サーバーで公開: 取得したログを MCP (Model Context Protocol) サーバーのツールとして Claude から呼び出せる形に変換します
Claude Agent が解釈: Claude Agent が MCP サーバー経由でログを取得し、異常イベントを判断してサマリを生成します
月次サマリとして記録・配信: 生成されたサマリを担当者に通知するか、スプレッドシートに記録します

従来の「GAS スクリプトが API を叩いてスプレッドシートに書き込む」方式と根本的に異なるのはステップ3です。ルールベースの集計ではなく、Claude が判断ロジックを担うため、「このログイン試行の件数は正常範囲か」「このファイル共有操作は許容できるか」といった定性的な解釈もサマリに含められます。

このフローを実現するうえで、情シスが判断すべき設計上の問いは主に3つに集約されます。「どのログを Claude に渡すか」「MCP サーバーをどう安全に設計するか」「Claude にどんな指示を与えるか」——以降のセクションで順番に整理します。

設計判断1：Reports API の取得スコープをどう絞るか

Reports API が提供するログは、ログインイベント・ドライブ操作・管理者操作・OAuth 認可変更など多岐にわたります。公式リファレンスで applicationName として指定できるカテゴリには login / drive / admin / token など複数が用意されています。

月次サマリを目的とする場合、最初から全ログを Claude に渡すのは現実的ではありません。理由は2つあります。

まずコンテキスト量の問題です。1か月分のドライブ操作ログをそのまま渡すと、Claude のコンテキストウィンドウに収まらないケースが出てきます。重要度の高いイベント（外部共有・権限昇格・ログイン失敗など）に絞り込んで渡す設計が重要です。

次にAPI のログ保持期間です。Reports API のログ保持期間は最大 180 日（公式仕様）です。月次という時間軸なら問題ありませんが、四半期・半期での傾向比較を後から行いたい場合は、ログを BigQuery などへ別途転送する設計と組み合わせてください。

月次サマリ用途で最初に取り組む優先度の整理は、以下の通りです。

ログ種別	主なイベント例	月次サマリでの重要度
ログインイベント	ログイン失敗の集中・新規デバイスからのアクセス・組織外ネットワーク	高
管理者操作	ユーザー作成/削除・権限変更・ポリシー変更	高
OAuth 認可	外部アプリへのスコープ付与・高リスクスコープの認可	中
ドライブ操作	組織外ドメインへのファイル共有・オーナー移転	中（量が多いため絞り込み必須）
Gmail 操作	転送ルール設定・フィルター変更	低（特定条件下のみ）

Reports API のアクセスに必要な OAuth スコープは、公式リファレンスで読み取り専用のものが定義されています。MCP サーバーから呼び出す際はこの読み取り専用スコープのみを付与する設計が原則です。書き込みスコープは不要で、付与してはいけません。

絞り込みのもう一つの実践的な方法は、Claude に渡す前に MCP サーバー側でフィルタリングすることです。たとえばログイン失敗については「同一アカウントで10回以上連続した場合のみ」、ドライブ共有については「組織外ドメインへの共有のみ」という前処理を MCP サーバー側に持たせると、Claude が受け取るデータ量を大幅に削減できます。ドライブ操作ログは特に量が多く、全件を渡すとコンテキストを圧迫しやすいため、フィルタリングの設計を最初から組み込んでおくことを強く推奨します。

設計判断2：MCP サーバーの役割とセキュリティ境界

MCP (Model Context Protocol) は、AI エージェントと外部ツール・データソースをつなぐオープンプロトコルです。MCP サーバーは OAuth 2.1 ベースのリソースサーバーとして動作し、Claude などの MCP クライアントからリクエストを受け取って結果を返します（公式仕様）。

今回の設計では、MCP サーバーの役割をログ取得の仲介に限定します。Claude が「先月の管理者操作ログを返して」と呼び出せるツールを定義し、MCP サーバーが Reports API へのリクエストを代行して結果を返す構造です。

ツール設計の概念的なイメージとして、MCP サーバーが公開するツールは以下のような構造になります。あくまで設計イメージであり、実際の実装では MCP SDK（TypeScript / Python 版が Tier 1 として公開されています）を用いて同様のスキーマを定義します。

{
  "name": "get_audit_log_summary",
  "description": "指定した期間のGWS監査ログイベントを取得し、フィルタリング済みのリストを返す",
  "inputSchema": {
    "type": "object",
    "properties": {
      "application": {
        "description": "ログ種別（login / admin / token など）"
      },
      "start_date": {
        "description": "取得開始日（ISO 8601 形式）"
      },
      "end_date": {
        "description": "取得終了日（ISO 8601 形式）"
      }
    },
    "required": ["application", "start_date", "end_date"]
  }
}

このスキーマで重要なのは description フィールドの質です。Claude はここに書かれた説明を読んでツールを呼び出します。曖昧な説明だと不適切なタイミングで呼ばれたり、正しいパラメータが渡らなかったりします。「いつ、どんな目的で使うツールか」を具体的に書いておくことが、Claude Agent の精度に直結します。

情シスが設計判断を迫られるのは、主に3点です。

認証トークンの管理場所：Reports API を呼び出すためのサービスアカウントキーや OAuth トークンを MCP サーバー内でどう管理するかを決める必要があります。Secret Manager などの専用サービスに格納し、コードに直書きしない設計を徹底することが前提です。

ツールの粒度：「全ログを1つのツールで返す」のか「ログ種別ごとに別のツールにする」のかを決めます。粒度を細かくすると Claude が状況に応じて必要なログだけを取得できるため、コンテキスト効率が上がります。一方で MCP サーバーの実装・保守コストは増えます。シンプルに始めるなら「優先度高の2種（ログイン・管理者操作）だけを返す1つのツール」から始めるのが現実的です。

MCP サーバー自体の監査：MCP サーバーが誰からの呼び出しを受け付けるかを制限する仕組みが必要です。Claude Agent 以外のクライアントから呼び出されるリスクを考えると、クライアント認証と呼び出しログの記録は最低限実装しておくべき要件です。

設計判断3：Claude Agent への月次サマリ指示設計

Claude Agent がログを参照して月次サマリを生成するには、「何を見て、何を判断するか」という指示（プロンプト構成）を設計する必要があります。ここがスクリプト実行方式と最も大きく異なるポイントです。

プロンプト設計で重要なのは、判断の委任範囲を明確にすることです。Claude に全権を委ねるのではなく、「この種のイベントが閾値を超えたら要確認フラグを立てる」「外部共有ファイルのリストは別途列挙する」というように、Claude の判断粒度を指示の中で定義します。

以下に、月次サマリ生成を目的としたプロンプト構成のサンプルを示します。実際の運用では組織のポリシーや規模に合わせて調整してください。

あなたは Google Workspace のセキュリティ監査担当アシスタントです。
提供された監査ログデータを分析し、以下の形式で月次セキュリティサマリを作成してください。

【分析対象ログ】
- ログインイベント（期間: {start_date} 〜 {end_date}）
- 管理者操作ログ（期間: {start_date} 〜 {end_date}）

【確認すべき観点】
1. 同一アカウントで 10 回以上のログイン失敗が発生した事象はあるか
2. 管理者権限を付与された／剥奪されたアカウントはあるか
3. 通常稼働時間外（深夜・休日）に実施された管理者操作はあるか
4. 新規に作成されたサービスアカウントや外部アプリ連携はあるか

【出力フォーマット】
## {YYYY}年{M}月 セキュリティサマリ

### 要対応（緊急度：高）
（該当事象を箇条書きで。なければ「なし」と記載）

### 要確認（緊急度：中）
（通常と異なるが緊急ではない事象。なければ「なし」と記載）

### 通常範囲内の記録
（ログイン成功件数・管理者操作件数などの概況を 2〜3 文で）

### 今月の特記事項
（傾向や推奨アクションがあれば）

【注意事項】
不確かな判断については「要確認」に分類し、確定情報のみ「要対応」に含めてください。

このサンプルでポイントになるのは「出力フォーマット」の定義です。Claude は確率的な言語モデルのため、同じログを渡しても毎回まったく同一のサマリが生成されるとは限りません。フォーマットをテンプレート化し Claude に埋める形式を指定することで、出力の安定性を大きく高められます。異常検知の判断は Claude に任せ、出力の型はプロンプトで固定する——この役割分担が、AI を使いながら運用を安定させる鍵です。

また、Claude が生成したサマリを確認なしでそのまま経営層に報告する運用は避けてください。担当者が内容をレビューしてから送付するフロー（human-in-the-loop）の設計が、セキュリティ関連の自動化では特に重要です。

運用上の注意点

このフローを実際に運用するうえで、見落とされがちな注意点を3つ挙げます。

MCP サーバーの権限を定期的に監査する：MCP サーバーが Reports API を呼び出すために付与しているサービスアカウント権限を定期的に棚卸しします。推奨は四半期に1回のレビューです。不使用期間が続く場合は権限を停止する運用が望ましく、「使っていないが権限だけが残っている」状態を作らないことが重要です。この MCP サーバー自体の権限管理は、GWS の管理コンソールのレポート機能からサービスアカウントのアクセス状況として追跡できます。また、MCP サーバーが呼び出している読み取り専用スコープの範囲が変わっていないかも定期的に確認してください。スコープのクリープ（意図せず広がること）はリスクの温床です。

ログ保持期間との整合を取る：Reports API の最大保持期間は 180 日です。月次サマリを生成するだけなら問題ありませんが、「過去3か月の傾向を比較したい」という要件が後から出てきた場合に対応できるよう、長期保存の仕組みを別途検討しておくと安心です。BigQuery への転送と組み合わせる設計は、180 日を超えた分析ニーズが生まれたタイミングで検討することを推奨します。最初から BigQuery 転送を組み込む必要はなく、「必要になったら追加できる設計にしておく」という判断で十分です。

Claude Agent のアクセス情報の管理：Claude Agent が MCP サーバーにアクセスするために使うトークンも秘密情報として扱います。環境変数や Secret Manager 経由で渡す設計にし、ソースコードやログに露出しないよう注意が必要です。特に MCP サーバーをサーバーレス環境で動かす場合は、環境変数の注入方法とランタイムでの秘密情報の扱いについて事前に設計を固めてください。トークンのローテーション頻度についても、組織のポリシーに従って定期更新のスケジュールを設定することを推奨します。

GAS スクリプト方式との使い分け

既存の GAS スクリプト + スプレッドシートによるログ収集を置き換えるかどうかは、用途によって判断が変わります。両者の特性を整理すると以下の通りです。

観点	GAS スクリプト方式	MCP × Claude Agent 方式
向いている用途	固定ルールの集計・アラート通知	定性的な解釈・傾向の言語化
判断ロジック	コードに明示的に記述	プロンプトで Claude に委任
出力の安定性	高い（決定論的）	中程度（プロンプト設計に依存）
導入・保守コスト	低い	中〜高（MCP サーバー構築が必要）
対応できる状況	想定パターン内に限る	想定外のパターンにも対応できる可能性あり
向いていない状況	「正常範囲か否か」の定性判断	毎分・毎時トリガーの高頻度処理

GAS 方式が向いているのは、「ログイン失敗が N 件以上でアラートを送る」のような判断ロジックが固定のケースです。実装・保守のコストが低く動作も予測しやすいため、定型の集計・通知には引き続き有効です。

MCP × Claude Agent 方式が向いているのは、「ログを横断的に読んで月次の傾向やリスクを言語化してほしい」という定性的な解釈が求められるケースです。固定ルールでは捉えにくい設定ミスや異常なアクセスパターンを発見できる可能性があります。

初期段階では両者を並走させる設計が堅実です。GAS で通知アラートをカバーしつつ、MCP × Claude Agent で月次のサマリレポートを追加する役割分担からスタートすると、移行リスクを最小限に抑えながら効果を測定できます。

まとめ

Reports API → MCP サーバー → Claude Agent という設計フローの核心は、「ログ取得」と「ログ解釈」を分離することにあります。

MCP サーバーはログの取得・変換・権限制御に専念し、解釈と判断を Claude Agent に委ねる構造にすることで、定性的な監査サマリの自動化が実現します。設計上の3つの判断軸——取得スコープの絞り込み・MCP サーバーのセキュリティ境界・Claude Agent への指示設計——を整理してから実装に入ることが、運用開始後のトラブルを防ぐ近道です。

次のアクションとして、まずはログイン + 管理者操作の2種類に絞った月次サマリを動かしてみることを推奨します。GAS で動いている既存の集計スクリプトは残したまま、月次レポートの生成だけを Claude Agent に担わせる形で並走させると、移行リスクを最小限に抑えながら効果を測定できます。

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

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

※ この記事は DRASENAS Blog の転載です。オリジナルではコードや設定手順が随時アップデートされています。