TL;DR
- MCP権限の本丸は「allowlistの粒度」と「scope命名」の2つ。
- 粒度は「事故時損害 × 申請頻度」のバランスで決める。
- 組織導入では命名規約と棚卸し運用をセットで作る。
はじめに
この記事はシリーズ「AIコーディング導入のセキュリティ設計」の L1 権限層 の深掘りです。 👉 AIコーディング導入のセキュリティ設計 4層モデルで攻撃面を整理する
MCPの「分離アーキ（運転席と作業者）」は別記事 MCPで"運転席と作業者"を分離して事故率を下げる に譲り、本記事は判断軸と組織導入に絞ります。
1. allowlistの粒度
選択肢は実質3段階です。
| 粒度 | 例 | 強み | 弱み |
|---|---|---|---|
| 粗 | github.* 全許可 | 運用が楽 | 事故影響が広い |
| 中 | github.read.* と github.write.repo.<name> を分離 | 用途別に制御 | 命名・棚卸しが必要 |
| 細 | github.write.repo.<name>.branch.<b> | 影響最小 | 申請が爆発、運用破綻 |
粒度選択の判断軸
「事故時損害 × 発生確率」と「申請の手間 × 頻度」を見比べ、損害が大きい領域だけ細粒度に。全部細粒度にすると申請地獄になり、結果「面倒だから全許可」が始まって最悪化します。
実務の落とし所は 中粒度を基本、本番系のみ細粒度。github.read.* は包括、github.write.* は repo 単位、github.write.repo.production-* のみブランチ単位、という3段階の使い分けが多い印象です。
2. scope命名の規約
中粒度を採ると命名が生命線になります。ブレると棚卸しと例外申請レビューが両方破綻。推奨規約:
<provider>.<action>.<resource>[.<qualifier>]
github.read.repo
github.write.repo.notionnext-blog
github.write.repo.notionnext-blog.branch.main
ルール: (1) provider名は固定、(2) action は read / write / delete / admin の3〜4種に絞る、(3) resource は単数形で統一、(4) qualifier は必要箇所だけ。最初に2〜3週間かけてでも合意を取る価値があります（後から直すコストが大きい）。
3. 組織導入時のセット
技術だけでなく運用3点をセットで設計します。関連する観測基盤は AIエージェントの観測基盤 eBPFで実行時の挙動を追う も参照。
- 例外申請フロー: Slack申請 → レビュー → 期限付き付与 → 自動失効。深夜休日の詰みを避けるため自動化必須
- 監査ログ: 全tool呼び出しをSIEMへ。90日保持、5分以内に経路を辿れる状態
- 四半期棚卸し: 過去90日未使用のscopeを洗い出し、所有者レビューで削除。命名が揃えばスクリプト50行以下
ここまで設計しても引数依存の動的判定（git push は可、--force は不可等）は残ります。これは L3（実行時制御層）の hooks に委ねます。
👉 Claude Code hooks の実践パターン集 品質担保・監査・安全制御の3用途
まとめ
粒度・命名・運用の3点が揃って初めてMCP権限設計は機能します。最初に時間をかけて合意するのが結局速い。
権限の使い手が決まったら、次は MCP サーバー実装側の設計 が問題になります。tool 粒度の決め方、resource / prompt の選び分け、エラー設計、OAuth 2.1 認証、transport 選定の 5 軸は MCPサーバー設計パターン集 で整理しています（2025-06-18 spec 基準、最新 2025-11-25 との差分注記あり）。
全体像に戻る: 親記事はこちら
参考・一次資料
権限粒度・scope 命名・最小権限の判断は、MCP 仕様と確立されたセキュリティ標準を一次情報として参照すると組織合意が取りやすくなります。
- Model Context Protocol 仕様（modelcontextprotocol.io） — tool/resource/prompt と認可モデルの正本
- MCP Authorization 仕様 — OAuth 2.1 ベースの認可フロー
- NIST SP 800-53 AC-6 Least Privilege — 最小権限原則の標準定義
- OAuth 2.0 Scopes（RFC 6749 §3.3） — scope 命名・粒度設計の規範
