--- title: ツールインターフェースと MCP url: https://doc.liz6.com/ja/ai/03-agent-systems/02-tools-and-mcp locale: ja area: ai tags: - 大規模モデルと Agent - Agent 実行システム date: 2026-06-30 modified: 2026-09-10 description: 関数を呼べる実行器に複数の外部サービスをどう接続するでしょうか。MCP が能力交換を標準化しても、Host はモデルの形式と各 Server を対応付け、識別・版・結果を管理します。ここでは呼び出し契約、次の記事では Skills による手順の再利用を扱います。 --- # ツールインターフェースと MCP 関数を呼べる実行器に複数の外部サービスをどう接続するでしょうか。MCP が能力交換を標準化しても、Host はモデルの形式と各 Server を対応付け、識別・版・結果を管理します。ここでは呼び出し契約、次の記事では Skills による手順の再利用を扱います。 ## Host、Client と Server MCP（Model Context Protocol）は、アプリケーションとサービスがコンテキストと能力を交換するためのプロトコルを定義します。Host はモデルを使用するアプリケーションであり、Client は Host 内で特定の Server に接続するコンポーネント、Server はツール、リソース、またはプロンプトテンプレートを提供します。1つの Host は複数の Server に接続でき、それらは同じビジネス API を使用する必要はなく、同じマシン上にデプロイされている必要もありません。[MCP アーキテクチャ](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) モデルベンダーのツール呼び出し形式と MCP メッセージは同一のプロトコルではありません。Host は通常、MCP ツールの記述をモデルが認識できるツールにマッピングし、モデルの呼び出しを MCP リクエストに変換し、サービスの結果を本轮の観察に戻します。このアダプテーション層は、名前マッピング、パラメータ、結果型、エラー、呼び出し関連処理を処理する必要があり、Server のリストをそのまますべてのモデルが理解できる入力として使用することはできません。一般的な「M×N が M+N になる」というのは、インターフェースの再利用による恩恵を説明するものです。M 個のアプリケーションがそれぞれ N 個のシステムに接続する場合、多くのアダプテーション処理が重複して実装されます。標準プロトコルにより、アプリケーション側とサービス側の一部の作業を再利用可能にします。ただし、認証、ビジネスセマンティクス、能力の互換性、ユーザー体験については依然として接続が必要であり、実際の統合コストは厳密に M+N にはならず、自動的に消滅することもありません。 ### 伝送と実行場所ローカルの stdio は通常、サブプロセスの標準入出力を通じてプロトコルメッセージを交換します。ログはプロトコルの出力ストリームに混入させてはいけません。Streamable HTTP は HTTP を介してリクエストとオプションのストリーミング機能を提供します。前者はローカルプロセスでよく使用され、後者はサービス化された接続に適していますが、伝送方式自体はビジネス権限の分離を提供しません。[MCP 伝送概要](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) 例えば、ローカルファイル Server がユーザーの広範なファイル権限を継承している場合、モデルがそれを選択するとこれらのファイルにアクセスできる可能性があります。「ローカル」だからといって、アクセス範囲が小さいわけではありません。リモート Server も、リクエスト主体、許可範囲、資格情報の有効性を把握する必要があります。「接続が確立された」だけでは、通信層が成立しただけであることを意味します。 ## 3種類のサーバー側能力 | 能力 | 提供内容 | チケットレポートでの例 | |---|---|---| | tools | 実行可能な操作 | 条件に一致するチケットの照会 | | resources | 読み取り可能なコンテキスト資料 | チームのフィールド定義、レポートの元資料 | | prompts | 再利用可能な対話テンプレート | 時間範囲を選択するためのレポートプロンプト | これらは意図によって区別されますが、実際のインターフェースは異なる場合があります。あるリソースがツールによって読み取られることもあれば、ツールがデータのみを読み取ることもあります。重要なのは、呼び出し元が「これはアクションである」「これは資料である」「これはオプションの対話テンプレートである」ことを理解することであり、すべての返却テキストをタスクインストラクションに昇格させないことです。[MCP 原語](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) ## 発見から呼び出しまでの境界 ### プロトコルバージョンはサンプルコードより優先プロトコルは進化します。今回確認した **2026-07-28** バージョンでは、`server/discover` を使用してサポートされているバージョンと能力を発見し、リクエストメタデータにプロトコルバージョンなどの情報を付与します。古いバージョンのステートフル初期化プロセスと、このバージョンのリクエストを混在して送信しないでください。古いクライアントを維持する場合は、実際にサポートされているバージョンに基づいて仕様を確認し、SDK をアップグレードする際にも相手側の互換性を検証する必要があります。[バージョン管理されたアーキテクチャの説明](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) プロトコル層が無状態であっても、サービスがショッピングカート、ブラウザページ、または長時間のタスクを維持できないわけではありません。ビジネスステートは存在し続けることができますが、明示的なリソースハンドルなど、明確なアイデンティティとステート位置決めが必要です。TCP 接続がまだ存在しているからといって、次のツール呼び出しが前のビジネスオブジェクトに自動的にバインドされると想定してはいけません。 ### 発見はすべてをコンテキストに読み込むことを意味しない Host はツールディレクトリを取得でき、現在のタスクに基づいて露出範囲を選択できます。MCP の能力発見と Host のセマンティックツール検索は別の問題です。MCP に接続したからといって、すべてのツールスキーマがオンデマンドで読み込まれることが自動的に保証されるわけではありません。ツールの選択、キャッシュ、コンテキスト予算は Host の設計に属します。 2つのサービスがどちらも `search` を提供していると仮定します。Host は、サービスソースを正確に特定できるマッピングを維持する必要があります。同名のツールだけを表示して、呼び出しが誤ったバックエンドに到達することを許してはいけません。また、サービスが自らの名前を名乗ることを信頼して、それが信頼できる元のサービスであると認定してはいけません。マッピングは、Host がすでに設定し確認済みの接続アイデンティティに依存すべきです。以下は、外側のプロトコルメッセージを省略した MCP ツール定義オブジェクトです。`inputSchema` を使用していることに注意してください。これは一部のモデル API の `input_schema` フィールドとは異なります。 ```json { "name": "search_tickets", "description": "指定されたプロジェクト内のチケットを参照専用で照会します。エントリと次のページネーション位置を返します。", "inputSchema": { "type": "object", "properties": { "project": {"type": "string"}, "query": {"type": "string"} }, "required": ["project", "query"], "additionalProperties": false } } ``` MCP ツールは発見、呼び出し、構造化記述をサポートしています。結果には複数のコンテンツタイプが含まれる可能性があり、実行エラーは `isError` によって示されます。スキーマや注釈はセキュリティ証明ではありません。サーバー側は依然としてパラメータとアクセス権限を検証する必要があり、Host も信頼できないサービスが参照専用であると自称することを盲目的に信じてはいけません。[MCP Tools 仕様](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) ### 接続成功後も複数の失敗箇所が存在する | 現象 | 優先して確認すべき箇所 | すぐに非難すべきでないこと | |---|---|---| | サービスプロセスが起動しない | 実行ファイル、作業ディレクトリ、依存関係、設定 | モデルがツールを使用しない | | 接続は成功したが発見に失敗する | バージョン、伝送、アイデンティティと能力発見 | ツール記述が短すぎる | | ツールはリストされているがモデルが選択しない | Host の露出範囲、記述、現在のタスク | MCP プロトコルが必ず壊れている | | リクエストが拒否される | パラメータ、権限、レート制限と相手側のエラー | 推論の努力を増やせば解決する | | ツールは結果を返すが、回答が正しくない | 型マッピング、切り捨て、証拠とタスクの理解 | Server が必ずエラーを返す | この階層型のトラブルシューティングにより、伝送が確立されていない場合にプロンプトを繰り返し修正することを避け、モデルが「より多くのツールを見る」ためにビジネス権限を無条件に拡大することを避けることができます。 ### 2 つの search、どちらを呼ぶか 2サーバーを接続しても、各サーバー内の一意性は全体の一意性になりません。接続を識別してモデル向けの名前を実ツールへ対応付けます。名前解決と JSON-RPC の関連付けは別の責務です。 **2 つの search、どちらを呼ぶか** ツール名は各サーバー内で一意です。Host は提供元の識別情報を保持し、応答を要求に対応付けます。 ## タスク手順との接続ツール一覧は呼べる能力を示し、Host が選択と対応付けを担います。報告手順・項目定義・テンプレートは [Skills とタスク手順の再利用](/ai/03-agent-systems/03-skills-and-task-context) で扱います。名前・引数・結果構造でつなぎ、インターフェース更新後に依存する呼び出しの存在と意味を再確認します。次に読む：[Skills とタスク手順の再利用](/ai/03-agent-systems/03-skills-and-task-context)。