社内MCPを素早く安全に増やす共通基盤 — 認証・認可・監査ログ

作成日: 2026-06-26 出典 / きっかけ: obiyuta（CTO, TRIBEAU inc.）「社内MCPを『素早く安全に』増やすために、ちゃんとしておきたい共通基盤（認証・認可・ログの話）」 https://zenn.dev/tribeau/articles/0d03b4c9fdf360 関連: ai駆動開発ループ_interview-dev-loop_整理 / llm_product_clean_architecture_設計

---

0. 要点（3行）

• MCP を1個ずつ作り捨てるのをやめ、認証・認可・監査ログ・CI/CD を共通化した土台を先に作る。新規MCPは「ツール本体＋数行の設定」で足せる状態にするのが狙い。
• 設計の核は 認可サーバ(AS)とリソースサーバ(RS)の分離（署名鍵は AS だけが持ち、各MCPはトークン検証のみ）＋ Google Workspace グループを権限の拠り所にして組織図と一本化（退職・異動が即反映、二重管理を排除）。
• 標準準拠（OAuth 2.1 / PKCE / RFC 9728・8707・8414・7591 / JWT+JWKS）で将来性を確保し、ログは Datadog（短期・異常検知）と BigQuery（長期・分析）に分岐させる。

1. 背景 — なぜ共通基盤を先に作るか

• 全社AI利用が進み、MCP別・ツール別の利用権限制御が必要に。
• 今後MCPが増える前提で、認証・認可・監査・CI/CD を共有化し「安全に素早く追加できる」体制を先行整備する（後付けは保守負荷が高い）。

2. 全体構成 — AS と RS の分離

MCPクライアント（Claude / Notion AI 等）
        │
   Cloud Load Balancer
        ├──────────────► 認可サーバ AS
        │                 ・「誰か」「何を使えるか」を判定
        │                 ・トークン発行（署名鍵を単独保有）
        └──────────────► リソースサーバ RS（各MCP）
                          ・トークン検証のみ
                          ・ツール本体を実装

役割	担当	持つもの
AS（Authorization Server）	SRE	署名鍵・認可ロジック・グループ判定
RS（Resource Server＝各MCP）	ツール実装者	公開鍵での検証のみ（秘密は持たない）

秘密鍵を AS に集約し、RS は JWKS の公開鍵で検証するだけ。これで「MCPが増えても秘密が分散しない」。

3. 認証・認可

3-1. 準拠した標準仕様

仕様	役割
OAuth 2.1 + PKCE（RFC 7636）	認可フローの土台
DCR（RFC 7591, Dynamic Client Registration）	事前共有なしでクライアント接続
AS メタデータ（RFC 8414）	認可サーバ設定の自動発見
Protected Resource Metadata（RFC 9728）	RS が /.well-known/oauth-protected-resource で要件を公開（2025-04 RFC化）
Resource Indicator（RFC 8707）	トークンの宛先MCPを resource で指定し aud に焼き込む
JWT + JWKS	公開鍵で署名検証
MCP Streamable HTTP	MCP の通信方式

補足（一次資料で確認）: MCP 公式仕様は RS に RFC 9728 の Protected Resource Metadata 公開を要求し、各MCPは「アクセストークンの aud に自分のURLが含まれるか」を検証する義務がある（RFC 8707 準拠）。他MCP宛てのトークン使い回しを防ぐ仕組み。

3-2. 独自の設計判断

判断	理由
Google Workspace グループを認可の拠り所にする	独自のメンバー管理を回避。退職・異動が組織図側で即反映
トークンに提供MCPを焼き込む（Resource Indicator）	複数MCP提供前提で、トークンの使い回しを遮断
各MCPはトークン検証のみ	認可を AS に集約し、秘密鍵を AS 単独保有に
グループ単位でツールを出し分け	同一MCP内でも最小権限制御（例: 分析ツールの全データ vs 部分アクセス）

3-3. Workspace グループ認可の実務

• メンバー管理の二重化を排除＝組織図（Workspace）を Single Source of Truth に。
• Workspace API は2種類を使い分け:
• searchTransitiveGroups — Enterprise系エディション限定
• groups.hasMember — 全エディション対応
• 同一MCP内でも所属グループで露出ツールを制御。

3-4. トークン寿命と失効

種別	有効期限	保持方法
アクセストークン	1時間	ステートレス JWT（署名・期限で検証）
リフレッシュトークン	最長30日	Firestore 保存・TTL 自動失効
認可コード	10分	Firestore 保存・TTL 自動失効
グループ判定キャッシュ	数分	メモリ

• リフレッシュ時に所属グループを再確認し、「快適性」と「失効の即時性」を両立。
• Workspace 不調時の備え: グループ確認を一時的に切れる緊急スイッチを用意。

4. 監査と観測 — ログ設計

4-1. 全MCP共通フォーマット

共通必須フィールド＋ツール別任意フィールドで統一。success / rejected / error を同形で記録する。

{
  // 共通必須
  "at": "2026-06-18T19:00:00+09:00",
  "code": "TOOL_INVOKED",
  "mcp_service": "mcp-b",
  "tool": "run_query",
  "user_email": "...",
  "group_email": "...",
  "outcome": "success",   // success / rejected / error
  "duration_ms": 318,
  // ツール別任意
  "bytes_billed": 1048576,
  "row_count": 1240
}

拒否・エラーも同形なので、拒否率の急増やエラー頻発に即気づける。

4-2. ログの分岐（短期 / 長期）

宛先	用途	保持・特徴
Datadog	短期・異常検知	直近2週間。拒否率・エラー・レイテンシ監視＋アラート
BigQuery	長期・分析	監査・利用傾向・コホート分析・BI連携。月数セント程度

5. アプリ構成 — 新規MCP追加を簡素化

新しいMCPを足すのに必要な作業はこれだけ:

1. ツール本体を書く
2. ロードバランサーに経路を追加
3. 自MCPのURLを audience として1行登録
4. 利用許可グループを指定

トークン検証のコード例（TypeScript）

const verifier = new RemoteJwksVerifier({
  jwksUri: AS_JWKS_URI,   // AS の公開鍵
  issuer: AS_ISSUER,      // 発行者を検証
  audience: THIS_MCP_URL, // 自MCP宛てのトークンのみ受理（RFC 8707）
});
registerMcpRouter(app, { verifier });

リポジトリ構成（モノレポ）

mcp/
├── src/
│   ├── mcp-auth/          # AS（SRE 担当）
│   ├── mcp-a/, mcp-b/...  # 各 RS（ツール実装者）
├── terraform/
│   ├── modules/           # 共通化部分
│   └── mcp-a/, mcp-b/...
└── .github/workflows/     # MCP別デプロイ

• インフラ変更は SRE + オーナーの二重レビュー必須。
• 署名鍵は AS のみ保有（RS は検証のみ）。

6. 落とし穴と対策

落とし穴	対策
リフレッシュトークン長期化（30日）による遅延失効	リフレッシュ時に所属再確認＋緊急スイッチ
Notion AI の独自仕様・バグ	標準外対応を局所化
Workspace API のエディション依存	searchTransitiveGroups(Enterprise) と groups.hasMember(全対応) を使い分け
Cloud Run のコールドスタート	アクセス不定期でも数秒遅延は許容、通常運用で問題化せず

7. まとめ — いつ・どう使うか

状況	推奨アプローチ
MCP を今後いくつも増やす予定	認証・認可・監査・CI/CD を先に共通基盤化（後付けは高くつく）
MCP ごとに権限制御したい	AS/RS 分離＋トークンに宛先MCPを焼き込み（RFC 8707）
メンバー権限の管理が二重化している	Workspace グループを SoT にして組織図と一本化
認可を自前実装したくなった	RFC 準拠（OAuth 2.1 / 9728 / 8707 / 7591）で組む。独自カスタムは避ける
監査と異常検知の両立	ログを短期(Datadog)/長期(BigQuery)に分岐、フォーマット統一

一言で: MCP は「ツールの数だけ作るもの」ではなく「共通の認可・監査レールの上に1行で足すもの」にする。レールを先に敷くほど、増設が安く・安全になる。

---

参考リンク

• obiyuta（TRIBEAU）「社内MCPを『素早く安全に』増やすために…（認証・認可・ログの話）」 https://zenn.dev/tribeau/articles/0d03b4c9fdf360
• MCP 公式 Authorization 仕様 https://modelcontextprotocol.io/specification/draft/basic/authorization
• RFC 9728 OAuth 2.0 Protected Resource Metadata https://datatracker.ietf.org/doc/html/rfc9728
• RFC 8707 Resource Indicators for OAuth 2.0 https://datatracker.ietf.org/doc/html/rfc8707
• RFC 8414 OAuth 2.0 Authorization Server Metadata https://datatracker.ietf.org/doc/html/rfc8414
• RFC 7591 OAuth 2.0 Dynamic Client Registration https://datatracker.ietf.org/doc/html/rfc7591

---

作成: 2026-06-26 ／ 最終更新: 2026-06-26