MCPの選び方｜権限と提供元で見る判断軸5つ

MCPの選び方を誤ると、権限が広すぎるサーバーを社内に接続してしまうか、逆に安全なサーバーまで導入を見送ることになります。本記事は、公式ドキュメントとClaude Codeの実装から、権限範囲・提供元・更新頻度・障害時の影響・代替手段という5つの判断軸を示します。確認日は2026年7月28日です。

01結論：MCPの選び方は、5つの判断軸で決まる

MCP（Model Context Protocol）は、AIアプリケーションを外部のツールやデータへつなぐためのオープンな標準規格です（出典: MCP公式）。規格自体はオープンでも、個々のMCPサーバーの作り・運営元・保守状況は千差万別です。同じ「MCPサーバー」という言葉で呼ばれていても、社内利用に向くものと向かないものが混在しています。

5軸の一覧は次のとおりです。詳しくは軸ごとに後述します。

02MCPが解決する仕組み｜選定基準の前提になる考え方

MCP公式サイトは、この規格をAIアプリ向けのUSB-Cポートにたとえています。USB-Cが電子機器同士をつなぐ規格を統一したように、MCPはAIアプリケーションと外部システムをつなぐ方法を統一します（出典: MCP公式）。

MCPが登場する前は、AIアプリごと・外部サービスごとに専用の接続コードを書く必要がありました。サービスがN個、AIアプリがM個あれば、最悪N×M通りの接続コードが要ります。MCPは、AIアプリ側（クライアント）と外部サービス側（サーバー）の両方が同じ規格に従うことで、この組み合わせ爆発を1つの標準に置き換えます。

公式ドキュメントは、MCPで実現できることの例をいくつか挙げています（出典: MCP公式）。カレンダーやドキュメントへの接続、デザインファイルからのアプリ生成、社内複数データベースをまたぐチャット分析などです。目標を受け取り手順を自分で決めて動く仕組みそのものは『AIエージェントとは｜そう呼べる3条件と、呼べない境界』で扱った条件と同じです。MCPは、そのAIエージェントが実際に触れる対象を増やす接続層にあたります。

03権限範囲と提供元｜最初に見る2つの選ぶ基準

権限範囲：何を渡すかをスコープで決める

ローカルで動くstdio型のMCPサーバーは、クライアントと同じ権限で動きます。公式のセキュリティ文書は、悪意あるローカルサーバーの起動コマンド例を挙げています。SSH鍵を外部へ送信する処理や sudo rm -rf です（出典: MCP公式セキュリティ文書）。つまりMCPサーバーを1つ追加することは、そのサーバーの作者にクライアントと同じ権限を渡すことに近い判断です。

リモートのHTTP型サーバーはOAuth認可を使いますが、ここにも罠があります。公式文書は「スコープの最小化」を明記しています。* や admin:* のような包括スコープを最初から要求するサーバーは避けるよう求めています（出典: MCP公式セキュリティ文書）。必要な操作に応じて段階的にスコープを広げる設計が望ましいとされています。

Claude Codeでは、MCPサーバーのツールも mcp__サーバー名__ツール名 という形式で権限ルールの対象にできます。詳しい配分の考え方は『Claude Codeの権限設定｜allow・ask・denyの配分と設定例』で扱ったdeny・ask・allowの3列がそのまま使えます。

{
  "permissions": {
    "deny": [
      "mcp__stripe__create_payment",
      "mcp__slack__delete_channel"
    ],
    "ask": [
      "mcp__slack__send_message"
    ]
  }
}

MCPサーバー自体を追加する場所も権限範囲に関わります。Claude Codeにはlocal・project・userの3スコープがあります（出典: Claude Code公式ドキュメント）。localは自分専用、projectは .mcp.json でチーム共有、userは全プロジェクト共通です。project scopeはGit管理下に置けますが、接続の承認自体は各メンバーの手元で個別に必要です。

チーム共有を前提とするなら、project scopeで追加してGit管理下に置きます。

# チームで共有するMCPサーバーを追加する例
claude mcp add --transport http notion https://mcp.notion.com/mcp --scope project

# 追加したサーバーの一覧と承認状態を確認する
claude mcp list

.mcp.json にサーバーが増えても、各メンバーは自分の端末で1回は承認操作をします。承認前は「pending approval」と表示され、勝手に接続は始まりません（出典: Claude Code公式ドキュメント）。

提供元：3つの信頼レベルを混同しない

MCPサーバーの提供元は、少なくとも3つの層に分かれます。

ここで見落としやすいのが、「verified」ラベルの意味です。Anthropicの公式文書は、審査は掲載基準への適合を見るものだと説明しています。そして、Anthropic自身はMCPサーバーのセキュリティ監査や管理を行わないと明記しています（出典: Anthropic公式）。ラベルは機能が動くことの目安であり、安全性を保証する印ではありません。

04更新頻度は選ぶ基準としてどこまで見るべきか

MCPの仕様は動いています。2026年7月28日には認可仕様を強化するリリース候補が公開されました（出典: MCP公式ブログ）。認可レスポンスの iss パラメータ検証など、OAuth 2.0の実運用に合わせた変更が含まれています。仕様側が半年〜1年単位で更新され続けている以上、サーバー側もそれに追随しているかが選ぶ基準になります。

確認する項目は難しくありません。GitHubリポジトリの最終コミット日、直近のリリースノートに新しい仕様への言及があるか、Issueへの応答があるかの3点です。ローカルstdioサーバーは前述のとおりクライアントと同じ権限で動くため、更新が止まったサーバーは、依存ライブラリの脆弱性が見つかっても直らないまま放置されるリスクを抱えます。

Claude Code自体も細かい仕様変更を重ねています。たとえば roots/list リクエストへの応答仕様は、あるバージョンから変わりました。起動ディレクトリに加えて、追加の作業ディレクトリも返すようになっています（出典: Claude Code公式ドキュメント）。

クライアント側の挙動が変わっても、サーバー側が古いままだと新しい機能を活かせません。更新頻度は「壊れないため」だけでなく「使える機能を取りこぼさないため」の基準でもあります。

05障害時の影響と代替手段｜残り2つの選定基準

障害時の影響：落ちたときと乗っ取られたときを分けて考える

MCPの障害時の影響は、単純な「止まる」だけではありません。公式セキュリティ文書は、少なくとも次の4種類の攻撃パターンを挙げています。

出典はMCP公式セキュリティ文書です。いずれも、権限範囲の軸で確認した「クライアントと同じ権限」という前提が、そのまま被害範囲になる点で共通しています。

Claude Code側にも、単発の障害が会話全体を止めないための仕組みがあります。HTTP・SSEサーバーが切断されると、最大5回まで指数バックオフで自動再接続します（出典: Claude Code公式ドキュメント）。stdioサーバーはローカルプロセスのため、この自動再接続の対象外です。

アイドルタイムアウトはHTTP・SSE・WebSocketが5分、stdioが30分です。応答が無いまま時間切れになった呼び出しは、エラーとして打ち切られます。1つのサーバーの不調がセッション全体を巻き込まない設計にはなっていますが、そのサーバーに依存していた作業自体は止まります。

代替手段：使えなくなったときに乗り換えられるか

5つ目の軸は、そのMCPサーバーが唯一の経路かどうかです。たとえばPostgreSQL用のMCPサーバーが使えなくなっても、直接SQLクライアントで接続する経路は残ります。一方、ベンダー独自の遠隔HTTPサーバーしか公式に提供されていないSaaSでは、MCPが止まった瞬間に自動化の経路も断たれます。

自前でホストし直せるオープンソースのstdioサーバーか、ベンダー管理の遠隔サーバーのみかを、導入前に確認します。前者は障害時に自分たちで直せる余地がありますが、後者はベンダーの復旧を待つしかありません。法人審査の観点では、この「乗り換えコスト」を可用性要件の一部として扱う価値があります。

06避けるべきものの見分け方｜5軸でNGになる条件

5軸を踏まえると、避けるべきMCPサーバーにはいくつか共通する見分け方があります。

• 資金や暗号資産の移動をうたっている：Anthropicの掲載基準は、金銭・暗号資産等の移動を行うコネクタを受け付けないと明記しています（出典: Anthropic公式）。同種の機能を掲げるMCPサーバーは、公式ディレクトリの外にある時点で審査の目が届いていません
• OAuthスコープが包括指定のみ：* や full-access のようなスコープしか用意されていない
• 読み取りと書き込みが同じツール1本にまとまっている：安全な操作と危険な操作の区別がクライアント側でつけられない
• 運営元のドメインとサーバーのドメインが一致しない：掲載基準は「自社の一次APIを呼ぶこと」を求めており、一致しないサーバーはなりすましAPIを経由している疑いがあります
• 公開ドキュメントやGitHubリポジトリが存在しない：中身を検証する手段がない
• 最終更新が長期間止まっている：③の更新頻度の軸でNGサイン
• トークンをそのまま下流へ転送する実装：仕様で明確に禁止されているアンチパターン

07選び方でつまずきやすい3つの点

1. 「verified」ラベルを安全審査済みだと思い込む。Anthropicの掲載基準は機能テストの合否を見るものです。Anthropic自身はMCPサーバーのセキュリティ監査や運用管理を行わないと明記されています（出典: Anthropic公式）。ラベルを見た時点で判断を止めず、権限範囲と障害時の影響は別途自分たちで確認します。

2. ローカルstdioサーバーを、起動コマンドを読まずに追加する。npx パッケージ名 の形で追加するとき、そのパッケージが何を実行するかを確認しないまま進めると、クライアントと同じ権限で任意のコマンドが動く状態を許可することになります。追加前に -- 以降のコマンドと引数を確認する習慣が要ります。

3. 一度承認したスコープを、その後見直さない。段階的にスコープが広がっていくサーバーもあります。/mcp パネルやスコープの一覧を定期的に見返し、業務で使っていない権限が残っていないかを確認します。

08MCPの選び方チェックリスト

• 権限範囲：スコープが包括指定（* 等）になっていないか確認した
• 権限範囲：mcp__サーバー名__ツール名 単位でdeny・ask・allowを設計した
• 提供元：公式ディレクトリのverified／communityどちらのラベルか確認した
• 提供元：運営元のドメインとサーバーのドメインが一致するか確認した
• 更新頻度：直近のコミット・リリースノートを確認した
• 障害時の影響：ローカルstdioかリモートHTTPかを確認し、起動コマンドを読んだ
• 代替手段：このMCPサーバーが止まったときの乗り換え先を用意した
• 導入後：/mcp で承認済みスコープを定期的に見直す運用を決めた

09FAQ