AIに案内ノートを探してもらいたい。次は予定表も読んでほしい。そのたびに接続先の仕組みが違うと、AIアプリと道具の組合せごとに対応を作る手間が増えます。MCPは、この接続の共通部分をそろえるための仕組みです。
MCPとは、AIアプリと外部の機能・情報をつなぐ共通の取り決め
MCPはModel Context Protocolの略で、AIアプリが外部の機能や情報を利用するための共通の通信ルールです。 使える機能を伝える、実行を頼む、結果を返す、といったやり取りの形式を定めます。
たとえるなら、違う道具でも同じ形の差し込み口でつなげるようにする考え方です。ただし本物のケーブルではありません。対象はソフトウェア同士のやり取りで、ノート検索も予定表も同じ仕事をするようになる、という意味ではありません。
ユイ
つなぎ方がそろったら、どの道具にも同じお願いができるの?
ピコ
ノートを探す道具と予定を保存する道具は、できることが違うよ。共通になるのは、その違いを伝えたり、仕事を頼んだりするためのやり取りなんだ
MCPがAIモデルそのものになるわけでもありません。得た情報をどのようにモデルへ渡し、回答に使うかは、AIアプリ側の設計に残ります。
共通のやり取りは、どことどこの間で行われるのでしょうか。
ホスト・クライアント・サーバーは何を担当する?
利用者が触るAIアプリをホスト、その中で接続先とのやり取りを担う部品をクライアント、外部の機能や情報を提供するプログラムをサーバーと呼びます。
利用者の質問を受け、モデルや道具を使う
接続先とのやり取りを担当
案内ノートを検索する機能を提供
ラボの案内ノートを検索する例なら、ホストが質問を受け、クライアントを通して検索機能へ依頼します。MCPサーバー側はその機能を提供し、検索結果を返します。図では、ノートを調べる役を右側に、質問への回答に使う役を左側に置きました。
「サーバー」といっても、必ず遠くの大型コンピューターを指すわけではありません。自分のパソコンで動くMCPサーバーも、ネットワークの先で動くMCPサーバーもあります。ここでは置き場所より、何を提供するプログラムかを見ます。
接続先が増えれば、ホストはそれぞれとのやり取りを管理します。その前に必要なのが、接続先に何ができるかを知ることです。
使える機能を知り、呼び出して結果を受け取る
架空のラボ案内ノートに「土曜日の開館は10時」と書かれているとします。AIアプリからその情報を読むには、単に「MCPに接続した」で終わりにはなりません。
- 接続先が提供する機能と、その説明を取得する。
- 「案内ノートを検索する」機能が利用できると分かる。
- AIアプリが、検索語を指定してその機能の実行を依頼する。
- MCPサーバー側が検索し、見つかったノートの情報を返す。
- AIアプリが結果を回答に使い、必要なら出典のノートも示す。
見つけた資料をモデルへ渡して回答に使う構成は、RAGとも関係します。MCPが資料や検索機能への接続方法を扱うのに対し、RAGは取得した情報を回答生成へ使う仕組みです。RAGにMCPが必須というわけではありません。
この例の「案内ノートを検索する」は**Tools(ツール)**の一つです。MCPサーバーは、ほかの形で情報やひな型を提供することもできます。
| 種類 | 何を提供する? | このノート検索に添えるなら |
|---|---|---|
| Tools | 実行できる機能 | 指定した言葉でノートを検索する |
| Resources | 文脈として参照できるデータ | 案内ノートの内容を取得できる入口 |
| Prompts | 再利用できる指示文のひな型 | 案内ノートを要約するときの問いのひな型 |
三つをすべて備えるサーバーだけがMCPサーバーなのではありません。何を提供し、アプリが何に対応するかは組合せによって違います。
「接続できた」のにノートを検索できないのはなぜ?
たとえば接続先が提供しているのが予定表の機能だけなら、案内ノート検索はできません。まず、目的の機能が提供されているか、アプリ側が対応しているかを確かめます。提供されていても、読む権限がない場合や実行時のエラーは別に残ります。接続、機能の有無、実行結果を分けると、確かめる場所を絞れます。
「機能へ依頼して結果を受け取る」という流れは、APIやFunction Callingでも登場します。名前が違うのは、扱っている範囲が違うからです。
MCPとAPI、Function Callingはどう違う?
| 用語 | 主に見る範囲 |
|---|---|
| API | プログラムから別の機能やデータを利用する接点 |
| Function Calling | モデルがツール名・引数を出し、実行結果を受け取る仕組み |
| MCP | AIアプリと提供側の間で、機能・情報を伝えて利用する共通の取り決め |
たとえば、モデルがノート検索の呼び出しを出し、アプリがMCP経由で検索サーバーへ依頼し、そのサーバーが内部で別サービスのAPIを使う構成も考えられます。三つを組み合わせられるので、「MCPを使えばAPIは不要」とは限りません。
一回の呼び出しで何を渡すかはAIのツール呼び出し、プログラム間の接点はAPIとはで、それぞれ詳しく扱います。
共通の形式で使える機能が分かっても、最後にもう一つ区別が必要です。道具が見えることと、その操作を任されていることは同じでしょうか。
MCPでつながっても、利用できる権限は別に決まる
案内を読むだけならよくても、予定の書き換えや外部への送信まで許可しているとは限りません。接続先が何を提供するか、アプリにどの権限を与えるか、今回の依頼で何をしてよいかを分けて確認します。
使い始める場面では、提供元、扱うデータ、読み取りか書き込みかを確かめ、必要な範囲だけを許可します。MCP対応という表示だけで、接続先の内容や実行結果が安全・正確だと保証されるわけではありません。
ラボの例でも、「開館時刻を教えて」という依頼に対して、案内ノートを書き換える必要はありません。読む機能だけで目的を果たせるなら、余分な変更機能を使わない設計にできます。
つながった道具を、どの順に使う?
MCPを見るときは、AIアプリ、やり取りを担うクライアント、機能を提供するサーバーを分けてみてください。ノートを検索できるか知りたいなら、接続の成功だけでなく、提供される機能と使える範囲まで見る必要があります。
道具がそろった後には、「次にどれを使うか」「答えがそろったらいつ止めるか」という別の問いが残ります。AIエージェントの仕組みでは、作業の結果を見ながら次の一手を選ぶ流れを確かめられます。
この記事について
LAB WHITEBOARD
自分の言葉で説明してみよう
「ホスト・クライアント・サーバーを分け、共通接続と機能・権限の違いを説明できる。」を、いまの自分の言葉で一文にしてみてください。途中の説明でも大丈夫です。




