この記事の音声は準備中です。
音声の一覧・再生リストへツール接続標準(MCP とエコシステム)
この記事の目的
MCPツールやデータソースを LLM アプリケーションに接続するための標準プロトコル。概要は ツール使用、接続の実務は ツール接続標準(MCP とエコシステム)(Model Context Protocol)がどんな問題を解決する標準なのかを理解し、「自前でツールを実装するか、既存の MCP サーバーに接続するか」を判断できるようになります。外部ツールサーバーを使うことのセキュリティ上の含意も把握します。
対象読者
- Agent に外部サービス(コード管理・チケット管理・DB 等)を接続したいエンジニア
- 自前ツールと MCP サーバーの使い分け基準を持ちたいテックリード
前提知識
本文
概要: N × M 問題を解く標準
MCP(Model Context Protocol)は、ツールやデータソースを LLM アプリケーションに接続するためのオープンな標準プロトコルです。解決する問題はシンプルで、N 個のアプリケーション × M 個のサービスの接続を、それぞれ個別に実装しなくて済むようにすることです。サービス側が MCP サーバーを提供すれば、対応する仕様版・トランスポート・機能を持つ複数のアプリケーション(ホスト)から再利用できます。
概念上は ツール使用 と同じく、ツール定義を受け取ったモデルが呼び出しを要求し、アプリケーションが実行結果を返します。MCP はこの接続部分に、機能の発見、要求・応答の形式、仕様版への対応を加えます。モデルのツール選択や、業務上の認可を自動的に正しくする仕組みではありません。
詳細: 構成要素
| 要素 | 役割 |
|---|---|
| MCP ホスト | LLM アプリケーション全体。利用者との対話、モデルへのツール提示、実行承認を管理する |
| MCP クライアント | ホスト内で、接続先サーバーとのプロトコル処理を担当する |
| MCP サーバー | ツール・リソースを提供する側。サービス公式のものと、コミュニティ製がある |
| ツール / リソース / プロンプト | サーバーが公開するプリミティブ。ツール(実行できる操作)が中心 |
仕様版と SDK の版を分けて選ぶ
2026-09-10 確認時点の仕様は 2026-07-28、このライブラリの Python サンプルは mcp==2.2.0 です。SDK の版番号と、相手が使うプロトコルの版は別に記録します。v2 サーバーは新旧両方の接続方式を扱いますが、利用できる機能は要求に適用される仕様版によって変わります。
| 観点 | 2025-11-25 までの方式 | 2026-07-28 の方式 |
|---|---|---|
| 接続の開始 | initialize による初期化と機能の合意 | server/discover による発見。各要求の _meta に仕様版とクライアント機能を含める |
| HTTP の状態 | ステートフルな運用ではセッションと接続先の維持を考慮する | 通常の要求をセッションに依存せず別のレプリカで処理できる |
| サーバーが追加情報を必要とする場合 | クライアントへ要求を送り返す方式 | 複数往復要求(multi-round-trip request、MRTR)で必要な入力を返し、クライアントが回答付きで再要求する |
Python SDK の Client は既定の mode="auto" で server/discover を試し、旧サーバーでは initialize に戻ります。mode="legacy" は旧方式を明示します。この違いは stdio にも適用されます。新仕様の接続ではサーバー起点の sampling・roots・push elicitation をそのまま使えないため、移行時は MRTR に対応したリゾルバーへ変更するか、必要な接続を旧方式に限定します。仕様公開記事 と Python SDK の移行ガイド に基づく整理です(アクセス日: 2026-09-10)。
トランスポートは、同じ端末の子プロセスへ接続する 標準入出力(stdio) と、リモート接続に使う Streamable HTTP を基本に選びます。HTTP の認可は接続方式とは別の設計です。stdio サンプルを HTTP で公開するだけでは利用者別の認証・認可は付きません。また、新仕様でセッションが不要になっても、MRTR の封印済み request_state を複数レプリカで検証する鍵や、通知の共有は必要です。旧方式のクライアントのセッション管理も残ります。詳細は 認証・認可 と SDK の配置・スケール手順 を参照してください(アクセス日: 2026-09-10)。
Python サンプルで確認する境界
最小 MCP サーバー は MCPServer に読み取り・申請の 2 ツールを登録します。v1 の FastMCP と import パスを置き換え、クライアントは Client、Python のエラー判定は result.is_error を使います。通信上の JSON フィールドは引き続き isError です。業務エラーをモデルに伝えるときは ToolError を使い、プロトコルエラーを表す MCPError と区別します。
サンプルの回帰テストプロンプト・ツール・モデルの変更で既存の品質が壊れていないかを、評価データセットの再実行と前回比較で検知するテスト。は、同じ v2 サーバーを別プロセスで起動し、新方式(2026-07-28)と旧方式(2025-11-25)でツール一覧・呼び出し・不正金額・承認が必要な金額を検証します。自己テストの --mock はツール関数を直接呼ぶだけなので、stdio 接続の検証とは別です。どちらも経費 API や実際の承認フローへは接続しません。
SDK v2 への更新は新仕様の全機能への対応を意味しません。2.2.0 では SEP-2663 の Tasks 拡張、DPoP、JWT bearer grant は未実装です。既存システムが移行できない場合、v1 系は重大な不具合・セキュリティ修正を受ける保守系として残ります。<2 の上限と対応プロトコルを明記し、その系統の最新修正版を追います。SDK 2.2.0 と サポート方針 を確認してください(アクセス日: 2026-09-10)。
設計判断: 自前ツールか、MCP サーバーか
| 状況 | 推奨 |
|---|---|
| 自社固有のビジネスロジック・社内 API | 自前ツール(ツール定義の設計) |
| 汎用サービスへの接続(コード管理・チケット・チャット・DB 等) | 公式の MCP サーバーがあればそれを使う |
| 汎用サービスだが、操作を強く絞りたい | 自前ツールでラップする(MCP サーバーの全ツールを渡さない)という選択も有効 |
| 社内ツールを複数の Agent アプリから使いたい | 社内 MCP サーバーとして実装する価値が出てくる |
判断の軸は「そのツールの語彙を自分で設計する必要があるか」です。MCP サーバーのツール定義(名前・説明文・粒度)はサーバー提供者の設計であり、自分のタスクに最適とは限りません。ツール数が多すぎる・説明が曖昧といった問題があれば、必要なものだけ自前でラップする方が品質が安定します。
詳細: セキュリティ — 外部サーバーはサプライチェーン
外部の MCP サーバーを接続することは、第三者のコードとプロンプト(ツール説明文)を自分の Agent に組み込むことです。次のリスクを認識してください。
- ツール説明文の汚染(tool poisoning) — ツールの説明文はモデルへのプロンプトの一部です。悪意ある(または改ざんされた)サーバーは、説明文経由でモデルの挙動を操作しえます
- 過剰な権限 — サーバーに渡す認証情報のスコープが広いと、Agent の誤動作・乗っ取り時の被害がそのまま広がります
- 結果経由の間接プロンプトインジェクションモデルへの入力に紛れ込ませた指示で、開発者の意図した挙動を上書きする攻撃。ユーザー入力による直接型と、Agent が読む外部コンテンツ経由の間接型がある。 — ツールが返す内容(外部サイトの本文など)に埋め込まれた指示をモデルが実行してしまう構造的リスク(プロンプトインジェクション)
基本対策は、信頼できる提供元に限定し、固定できるローカル配布物は版・ハッシュを固定し、固定できないリモートのツール定義変更は再審査まで無効化することです。認証情報のスコープを最小にし、危険な操作には承認を挟みます(Human-in-the-Loop 設計)。実行時の隔離・送信経路も含む詳細は ツール権限設計とサンドボックス で扱います。
外部 MCP サーバーの信頼条件は ツール権限設計とサンドボックスが正本です。ローカル stdio の版・ハッシュ固定と起動時の隔離、リモートの版を固定できない場合のツール定義差分検知・再審査までの無効化を区別します。バージョン固定だけで接続先の振る舞いは保証できません。
実務での注意点
アンチパターン
- 見つけた MCP サーバーを無検証で接続する → 第三者のコードとプロンプトを本番 Agent に注入することと同義 → 提供元の信頼性・権限スコープ・ツール一覧を確認してから接続する
- サーバーの全ツールをそのまま渡す → 数十ツールがコンテキストを圧迫し、選択ミスが増える → 必要なツールだけに絞る(絞る機構がなければ自前ラップを検討)
- MCP か自前かを二者択一で考える → 実務は混成が普通 → 汎用接続は MCP、コアロジックは自前、と役割で分ける
チェックリスト
- MCP の版を固定できない場合は、正本の差分検知・再審査までの無効化を実施し、stdio は隔離して起動する
- 接続する MCP サーバーの提供元・メンテナンス状況を確認した
- サーバーに渡す認証情報のスコープが必要最小限になっている
- モデルに渡るツール一覧を実際に確認した(数・説明文の品質)
- 副作用のあるツールに承認・権限制御がかかっている
- 固定可能な配布物の版・ハッシュと、固定できないリモートの変更検知・再審査手順が決まっている
- SDK とプロトコルの版を記録し、接続先のトランスポート・機能・新旧方式を検証した
- 業務エラーとプロトコルエラーを区別し、SDK 更新後も失敗を成功扱いしないことを確認した
関連トピック
- ツール使用 — 共通の基盤となる仕組み
- ツール定義の設計 — 自前実装側の設計
- Human-in-the-Loop 設計 — 危険な操作への承認
- ツール権限設計とサンドボックス — 権限設計とサンドボックスモデルが生成したコードの実行やコンピュータ操作を、本番システムから隔離された使い捨て環境(ネットワーク・資源制限付き)で行う仕組み。の詳細
- フレームワーク選定ガイド — MCP 対応はフレームワーク選定の観点の 1 つ
- 先端応用の概観(科学研究・シミュレーション・エージェント経済) — 通信標準(MCP・A2A)がエージェント経済エージェント同士が人の監督を超える規模・速度で取引・交渉・決済を行う経済という構想。2026 年時点では、エージェント間の通信・決済の標準(MCP・A2A・各種決済プロトコル)は稼働し始めた一方、自律取引の経済そのものは概念段階にとどまる。「配管(標準)」と「経済(自律取引)」を段階として区別して読む。の土台になる位置づけ
- examples/python/mcp-server/ — ツール 2 つの最小 MCP サーバー(権限強制の考え方・自己テスト可)
- エージェント間連携プロトコル — 「ツールを呼ぶ(MCP)」の先、「相手エージェントに任せる(A2A組織・システムの境界を越えてエージェント同士が発見・通信・タスク委譲を行うための標準プロトコル。Google 発で Linux Foundation へ移管され、エージェントカードによる発見・タスク委譲・長時間タスクを定める。MCP(ツールを呼ぶ)とは層が違い相補的で、相手を「部品」でなく自律主体として扱う。)」連携の設計
参考資料
- Model Context Protocol 2026-07-28 — 対象とする仕様版(アクセス日: 2026-09-10)
- The 2026-07-28 Specification — 要求単位の設計と MRTR(アクセス日: 2026-09-10)
- MCP Python SDK: Migration Guide — v1 から v2 の API・通信・認可変更(アクセス日: 2026-09-10)
- MCP Python SDK 2.2.0 — サンプルで固定する版(アクセス日: 2026-09-10)
- MCP Python SDK: Versioning — v1/v2 の保守方針(アクセス日: 2026-09-10)