MCPの仕組み — AIアプリが道具を見つけて使うまで
- ホスト/クライアント/サーバーの役割を説明できる
- データなしとツール失敗を営業と取り違えない
休業日の道具を使う
役割と道具の見つけ方
MCP:道具へ依頼して、結果を受け取る
モデルの要求と通信
権限と結果を確かめる
休業日の検索で流れを追ってみよう
ここでは、架空のお店のデータを検索する読み取り専用の道具を考えます。実サービスへ接続する手順や、実際の通信結果ではありません。
- 利用者がお店の休業日を質問する。
- ホストのMCPクライアントが、サーバーの道具一覧を取得する。
- モデルの要求とホストの制御に従い、検索ツールに対象の日付を渡す。
- サーバーがデータを検索し、結果を返す。
- ホストが結果を扱い、モデルが回答に利用する。
「2026-10-20は休業」というデータなら、その日付と結果が回答に保たれるかが確認点です。結果が見つからない場合は「不明」であり、「営業」に置き換えてはいけません。
次の挑戦:返答が来た後も結果を確かめる
休業日ツールが返す内容を、次の3通りで考えます。架空の結果を読む練習で、実サーバーの通信ログではありません。
| ツールの結果 | 利用者へ伝えること |
|---|---|
| 指定日の休業データが見つかった | 根拠の日付と休業を伝える |
| 呼び出しは完了したが、指定日のデータがない | 営業とは決めず、資料では不明と伝える |
| データ元の取得に失敗した | 確認できなかったことを伝える |
MCPのツール実行中の失敗は、結果の isError: true で報告される場合があります。未対応のメソッドや未知の道具などのプロトコル上のエラーとは区別します。返答が届いたこと・ツールが成功したこと・必要なデータが得られたことを別々に確かめましょう。
3つの役割を区別する
| 役割 | お店の例 |
|---|---|
| ホスト | 利用者が質問するAIアプリ全体 |
| クライアント | アプリ内でMCPのやり取りをする部分 |
| サーバー | 休業日を検索する道具やデータを提供するプログラム |
MCPではツールだけでなく、参考データを渡すResourcesや、指示の雛形であるPromptsも扱います。これらは同じものではありません。対応する機能・仕様の版・通信方式が合うかも確認が必要です。
道具の呼び出しと、モデルの判断は別
tools/list は道具を見つける操作、tools/call は道具を呼ぶ操作です。MCP自体が、どのモデルを選ぶかや、回答の正しさを保証するわけではありません。Function Callingなどのモデル側の機能とMCPを組み合わせ、ホストが実際の接続と結果の受け渡しを担当できます。
標準化は連携を再利用しやすくしますが、全てのAIと全ての道具が無条件につながるわけではありません。認証・必要な機能・ホストの対応範囲を確認します。
通信と権限を見る
stdioはホストが起動したプロセスと標準入出力で通信します。Streamable HTTPはMCPのエンドポイントへHTTPでやり取りします。HTTP向けの認可仕様と、ローカルでの資格情報の扱いを混同しないようにしましょう。
接続先、道具の説明、読み取れる範囲、変更できる範囲を確認します。検索結果や文書の中の文章は、ホストへの操作命令として無条件に従うものではありません。最初は架空のデータと読み取り専用の道具に絞ると、何が起きたかを追いやすくなります。
次に学ぶなら
AIエージェントの仕組みで、モデルとツールの繰り返しを確認できます。資料の検索と回答をつなぐところはRAGの仕組みへ進みましょう。
参考資料
-
MCP Architecture — ホスト・クライアント・ローカル/リモートサーバー
-
MCP Server concepts — Tools・Resources・Promptsとtools/list・tools/call
-
MCP Transports — stdioとStreamable HTTP
-
MCP Authorization — HTTP向け認可と任意実装・stdioの区別
-
OpenAI Function calling — モデルの要求とアプリ側での関数実行
-
MCP Tools仕様 — ツール結果とプロトコル/実行時のエラー