MCPの選び方｜AIエージェントに任せる範囲から見る5軸

「このMCP、入れて大丈夫ですか」。社内でそう聞かれて、判断の物差しを持っていないことに気づいた。そういう状態でこの記事にたどり着いた方が、多いのではないかと思います。

MCPサーバーは、つなぐほど便利になります。ただ、1本つなぐたびに、AIエージェントの手が届く先と、事故が起きたときの被害範囲が一緒に広がります。同じ方向へ伸びるので、勢いで足していくと、あとから絞れなくなります。

この記事は、MCPの選び方を権限範囲・提供元・更新頻度・障害時の影響・代替手段の5軸で整理します。根拠は公式ドキュメントとClaude Codeの実装です。確認日は2026年7月28日です。

01MCPの選び方は、AIエージェントに任せる範囲とどう関係するんですか？

高梨課長

高梨課長の発言

MCPを増やせば、AIエージェントに任せられる仕事も増えますよね。まずは使えそうなものから入れていこうと思っていて。

鈴木さん

鈴木さんの発言

増えるのは、手が届く先ですね。任せてよい範囲のほうは、別に決めます。差込口を足すことと、家の鍵を渡すことのあいだには、それくらいの距離があります。

高梨課長

高梨課長の発言

では、つなぐ前に何を見ればいいんでしょう。

鈴木さん

鈴木さんの発言

5つです。渡す権限、作った相手、手入れの状況、壊れた日の影響、そして代わりの道。この順で見ていきます。

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

だから、規格を信頼することと、そのサーバーを信頼することを分けます。分けたうえで、サーバーを1本ずつ次の5軸にかけます。

公式サイトは、この規格をAIアプリ向けのUSB-Cポートにたとえています（出典: MCP公式）。以前はAIアプリごと・外部サービスごとに専用の接続コードが要り、サービスがN個・AIアプリがM個あれば最悪N×M通りでした。

目標を受け取って手順を自分で決めて動く仕組みそのものは、別記事『AIエージェントとは｜3条件で見分け、任せる前に決める3つ』の条件と同じです。MCPは、そのAIエージェントが触れる対象を増やす接続層にあたります。

02生成AIに社内のデータを触らせるMCPは、権限のどこを見て選ぶんですか？

手元で起動するstdio型のMCPサーバーは、それを起動したクライアントと同じ権限で動きます。公式のセキュリティ文書には、悪意あるローカルサーバーが仕込む起動コマンドの例が載っています。挙がっているのは、SSH鍵を外部へ送信する処理や sudo rm -rf です（出典: MCP公式セキュリティ文書）。

つまりstdio型を1本追加することは、そのサーバーの作者に、自分と同じ権限を渡すことに近い判断です。生成AIに社内のデータを触らせるとき、実際に触っているのは手元で起動したそのプロセスだ、と読み替えてください。

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

03つないだMCPで、AIエージェントに触らせる範囲はどこで絞るんですか？

型の違いが分かったら、次は絞り方です。絞る場所は、クライアント側の権限ルールと、追加するスコープの2か所にあります。

Claude Codeでは、MCPサーバーのツールも mcp__サーバー名__ツール名 の形で権限ルールに書けます。配分の考え方は、別記事『Claude Codeの権限設定｜AIエージェントに任せる範囲と3列の配分』で扱ったdeny・ask・allowの3列がそのまま使えます。

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

denyに置いたものは呼ばれません。askに置いたものは、実行の直前で人に戻ります。ここに何を並べるかが、そのMCP越しにAIエージェントへ任せる範囲の実体です。

追加する場所も権限範囲に関わります。Claude Codeが用意しているのは、local・project・userの3スコープです（出典: Claude Code公式ドキュメント）。自分専用がlocal、.mcp.json でチームに配るのがproject、全案件で共通に使うのがuserです。

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

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

project scopeはGit管理下に置けます。ただし接続の承認そのものは、各メンバーの手元で1回ずつ要ります。承認するまでは「pending approval」と表示され、接続が勝手に始まることはありません（出典: Claude Code公式ドキュメント）。

04MCPの提供元は、AI導入の稟議でどこまで説明できればいいんですか？

大森部長

大森部長の発言

稟議に上げるとき、「これは審査済みです」で通せるものなんでしょうか。

鈴木さん

鈴木さんの発言

審査という言葉が何を指しているかで変わります。掲載の基準に合っているかを見た審査と、安全かどうかを見た審査は別ものなんです。

大森部長

大森部長の発言

では、うちは何を確かめたと書けばいいんですか。

鈴木さん

鈴木さんの発言

誰が作ったか、誰が中身を見たか。その2つを分けて書くところまでですね。安全の確認は、こちら側の仕事として残ります。

MCPサーバーの提供元は、いくつかの層に分かれます。層ごとに、中身を見ている人が違います。

見落としやすいのが、「verified」ラベルの意味です。公式文書の説明では、審査が見ているのは掲載基準への適合です。そのうえで、AnthropicがMCPサーバーのセキュリティ監査や管理を行うことはない、とも明記されています（出典: Anthropic公式）。

ラベルは、機能が動くことの目安です。安全性を保証する印ではありません。この違いを稟議の文面で分けて書けると、あとから「審査済みだったのに」と言われる展開を避けられます。

05更新が止まったMCPを、AIエージェントに使わせ続けると何が起きますか？

MCPの仕様は動いています。2026年7月28日には、認可仕様を強化するリリース候補が公開されました（出典: MCP公式ブログ）。含まれているのは、認可レスポンスの iss パラメータ検証など、OAuth 2.0の実運用に合わせた変更です。

仕様側が半年〜1年単位で更新され続けている以上、サーバー側がそれに追随しているかが、選ぶ基準になります。

高梨課長

高梨課長の発言

手入れが続いているかどうかは、どこを見れば分かるんでしょう。

鈴木さん

鈴木さんの発言

見るのは3点です。GitHubリポジトリの最終コミット日、直近のリリースノートに新しい仕様への言及があるか、Issueへの応答があるか。ここが動いていれば、まず追随できています。

高梨課長

高梨課長の発言

思ったより軽い確認で済むんですね。

鈴木さん

鈴木さんの発言

ええ。重いのは、止まっていることに気づかないまま使い続けるほうです。

更新が止まると、困りごとが2方向から出ます。1つは、壊れる側です。ローカルstdioサーバーは前述のとおりクライアントと同じ権限で動くため、依存ライブラリの脆弱性が見つかっても、直らないまま残ります。

もう1つは、取りこぼす側です。呼ぶ側のClaude Codeも、細かい仕様変更を重ねています。たとえば roots/list リクエストへ何を返すかは、あるバージョンから変わりました。いまは起動ディレクトリだけでなく、追加した作業ディレクトリも返します（出典: Claude Code公式ドキュメント）。

呼ぶ側の挙動が変わっても、呼ばれる側が古いままだと、増えた機能は使えないままです。AIエージェントに毎日使わせているぶん、この取りこぼしは静かに積もります。

06MCPが乗っ取られたとき、AI社員に渡した権限はどこまで悪用されますか？

大森部長

大森部長の発言

落ちるのは仕方ないとして、乗っ取られたときはどこまで広がるものなんですか。

鈴木さん

鈴木さんの発言

渡した権限の範囲が、そのまま被害の範囲になります。だから①の権限範囲と、この④は続きものなんですよ。

大森部長

大森部長の発言

逆に言えば、渡す範囲を絞っておけば、被害の上限も決まると。

鈴木さん

鈴木さんの発言

そうなります。ここが、稟議で説明できる数少ない歯止めですね。

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

出典はMCP公式セキュリティ文書です。4つに共通しているのは、①で見た「クライアントと同じ権限」という前提が、そのまま被害の広さになる点です。

07MCPが落ちただけのとき、エージェントに任せた作業はどこで止まるんですか？

乗っ取りに比べると、単に落ちただけの障害は軽く見えます。ただ、任せていた作業が止まる点は同じです。

止まるほうの備えは、クライアント側にもあります。Claude Codeは、HTTP・SSEサーバーが切断されると、最大5回まで指数バックオフで自動再接続します（出典: Claude Code公式ドキュメント）。手元のプロセスとして動くstdioサーバーは、この自動再接続の対象になりません。

アイドルタイムアウトは、HTTP・SSE・WebSocketが5分、stdioが30分です。時間切れになった呼び出しは、応答を待たずエラーとして打ち切られます。

1つのサーバーの不調が、セッション全体を巻き込まない設計にはなっています。ただ、そのサーバーに任せていた作業自体は止まります。AI社員に定型業務を任せているなら、止まった日に誰がその業務を引き取るかまで決めておきます。

08乗り換え先の無いMCPを、AI社員の常用ツールにしていいんですか？

最後の軸で見るのは、そのMCPサーバーが唯一の経路になっていないかです。

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

導入前に確認するのは、自前でホストし直せるオープンソースのstdioサーバーか、ベンダー管理の遠隔サーバーのみか、です。前者は障害時に自分たちで直せる余地があります。後者はベンダーの復旧を待つことになります。

法人審査では、この「乗り換えコスト」を可用性要件の一部として扱う価値があります。AI社員の常用ツールに組み込むなら、止まった日の代役まで含めて決めておくほうが、あとで慌てずに済みます。

09避けるべきMCPは、AI活用を止める前のどこで見分けられるんですか？

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

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

サインを見つけたあとの動きも、軸ごとに決めておきます。

見分けるタイミングは、AI活用を止めたあとではありません。つなぐ前です。

10MCPの選び方でつまずく3つの点は、AIエージェント運用のどこに効くんですか？

1つ目は、「verified」ラベルを安全審査済みだと思い込むことです。掲載基準が見ているのは機能テストの合否で、Anthropic自身はセキュリティ監査や運用管理を行わないと明記されています（出典: Anthropic公式）。ラベルを見た時点で判断を止めないでください。

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

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

3つとも、AIエージェント運用の同じ場所に効いてきます。任せる範囲が、知らないうちに広がっていないかどうかです。

11MCPの選び方を、AI社員に任せる前のチェックリストにどう落とすんですか？

5軸を、つなぐ前に手を動かす項目へ落とします。「いいえ」が残っているうちは、AI社員の常用ツールに組み込まないでください。

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

最後の項目だけ、つなぐ前ではなく運用中の話です。ここを決めずに始めると、②提供元と③更新頻度の評価が、時間とともに静かに古くなります。

12よくある質問

13まとめ｜今日やる3つのこと

MCPの選び方は、機能の比べ合いではありません。渡す権限と、壊れた日の面倒の見方を選ぶ作業です。どの軸も、そのMCP越しにAIエージェントへ何を任せるかへ戻ってきます。