AI コーディングエージェント（Claude Code や Cursor などの、コード生成・実行を自律的に行う開発支援ツール）に MCP サーバーを追加している開発チームに向けた内容です。MCP とは Model Context Protocol（AI モデルと外部ツール・データソースをつなぐ標準プロトコル）の略称です。便利さの裏でアクセス権限の設計を見落とすケースが増えています。
2026年時点で Context7 や GitHub MCP Server、Playwright MCP といった MCP サーバーは、GitHub のスター数が数万件、npm の月間ダウンロード数が数百万件規模まで普及しています。GitHub 公式の github-mcp-server はバージョン 1.11.0 が公開され、リポジトリの検索・Issue 操作・プルリクエスト作成・ワークフロー確認まで一括でこなせます。この利便性こそが、非機能要件の観点では新たなリスク面になります。
何が起きるか：権限スコープの見えない拡大
MCP サーバーを1つ導入するたびに、エージェントが操作できる範囲が段階的に広がります。
たとえば GitHub MCP Server は「リポジトリとワークフローへの書き込み」権限を持ちます。Supabase MCP は「スキーマ変更・マイグレーション・データ変更」まで踏み込みます。AWS MCP Server に至っては、呼び出し元の IAM（Identity and Access Management、AWS のアクセス権限管理サービス）権限をそのまま引き継ぎます。
これらを個別に見れば妥当な設計に見えます。しかし複数の MCP サーバーを同時に有効化すると、エージェント1つが「コード変更 + DB スキーマ変更 + クラウドリソース操作」を横断的に実行できる状態になります。これは従来のマイクロサービス間通信で最小権限の原則を積み重ねてきた設計思想と、正反対の方向に進みかねません。
影響範囲は「コードレビュー前の誤った変更が本番ブランチに混入する」レベルから、「本番データベースのマイグレーションが意図せず実行される」レベルまで幅があります。Cloudflare API MCP のように Workers・R2・D1・DNS まで含む「アカウント全体への広いAPI アクセス」を持つサーバーもあり、影響範囲の見積もりを誤ると被害が跨サービスに及びます。
なぜ起きるか：権限設計を三段階に分解する
原因を1つずつ分解すると、構造的な問題が見えてきます。
第一に、MCP サーバーの多くはエージェントの利便性を優先して設計されています。ドキュメント検索用の Context7 のようにアクセス範囲が狭いサーバーもありますが、GitHub MCP Server や Supabase MCP のように「読み書き両方をまとめて提供する」設計が主流です。開発者が個別に権限を絞る手間を省く代わりに、初期状態のアクセス範囲が広くなりがちです。
第二に、複数の MCP サーバーを同時に接続した場合の「権限の合算」を可視化する仕組みが、エディタ側にまだ十分整っていません。Claude Code や Cursor、VS Code はそれぞれ MCP 接続をサポートしていますが、接続済みサーバー一覧はあっても「このエージェントセッションで実行可能な操作の総和」を一目で確認できる機能は限定的です。
第三に、レビュー体制が人間のコードレビューを前提にしたまま更新されていないケースがあります。エージェントが提案した変更を「とりあえず承認」する運用が続くと、権限の広さがそのままインシデントの発生確率に直結します。
自分のプロジェクトが該当するか確認する方法
以下の手順で、現状の MCP 接続がどの程度のアクセス権限を持っているか棚卸しできます。
# Claude Code の場合、接続中の MCP サーバー一覧を確認
claude mcp list
# 個別サーバーの詳細設定を確認
claude mcp get <server-name>設定ファイルを直接見る方法もあります。プロジェクトルートや ~/.config 配下にある .mcp.json（または各クライアント固有の設定ファイル）を開き、以下の観点でチェックしてください。
- 接続先サーバーが何個あり、それぞれ読み取り専用か書き込み可能かを分類する
- GitHub や Supabase、AWS など認証トークンを渡しているサーバーの、そのトークン自体のスコープを確認する（例：GitHub のPersonal Access Token が全リポジトリの write 権限になっていないか）
- 本番環境の認証情報とローカル開発用の認証情報が、同じ MCP 接続設定内で混在していないか
- サーバーのバージョンが最新か（
npm view @upstash/context7-mcp versionのようにパッケージのバージョンを確認し、既知の脆弱性修正が反映されているか）
GitHub MCP Server であれば、GitHub 側の Fine-grained Personal Access Token（リポジトリ単位で権限を細かく指定できるトークン）を使っているかどうかも重要な判断材料です。旧来のクラシックトークンは全リポジトリに対する広い権限を持ちやすく、MCP 経由での事故が起きた際の影響範囲が読みにくくなります。
対策の手順
棚卸しが終わったら、以下の順序で権限設計を見直します。
1. 最小権限のトークンに切り替える：GitHub なら Fine-grained token で対象リポジトリを限定し、Supabase なら開発用プロジェクトと本番プロジェクトの認証情報を分離します。
2. 本番操作を伴う MCP サーバーは承認フローを挟む：Supabase のスキーマ変更や AWS のリソース操作は、エージェントが提案した差分を人間が明示的に承認するステップを必須にします。CI/CD パイプラインでいう「本番デプロイ前の承認ゲート」と同じ考え方です。
3. 非本番環境でまず検証する：新しい MCP サーバーを追加する際は、ステージング環境やサンドボックスのリポジトリで先に動作確認します。書き込み系の操作を含むサーバーほどこの手順を省略しないようにします。
4. エージェントの実行ログを残す：どの MCP サーバー経由でどんな操作が実行されたか、後から追跡できるようにします。GitHub Actions のワークフロー実行履歴や、Supabase のマイグレーション履歴と突き合わせられる状態を作っておくと、インシデント発生時の原因切り分けが早くなります。
5. 定期的な棚卸しを運用に組み込む：MCP サーバーは活発にアップデートされており、Context7 やChrome DevTools MCP のようにひと月単位でバージョンが上がるものもあります。権限モデルが変わることもあるため、四半期に一度は接続一覧と権限スコープを見直すサイクルを作ります。
まとめ
MCP サーバーはドキュメント検索からクラウド操作まで、開発フロー全体をエージェントに橋渡しできる便利な仕組みです。
ただし便利さは、そのままアクセス権限の広さと表裏一体です。GitHub の書き込み権限、Supabase のスキーマ変更権限、AWS の IAM 権限継承は、単体では妥当でも組み合わせると想定以上の操作範囲になります。
まず claude mcp list や設定ファイルの確認から始めて、現状接続しているサーバーの権限を棚卸ししてみてください。そのうえで、本番操作を伴うサーバーには承認フローを挟み、トークンは最小権限のものに切り替える。この2点だけでも、MCP 導入後のリスクは大きく変わってきます。