サンプリング・通知・ルート：サーバーとクライアントが行き来する仕組み

ここまでの3つの土台は、どれもクライアントがサーバーに尋ね、サーバーが応じるという一直線のやり取りでした。ここから扱う3つの機構は、向きが逆になる場面を含みます。サーバーがクライアントに何かを頼む、という流れです。

サンプリング：サーバーがクライアントにLLMを呼んでもらう

MCPサーバーを作るとき、サーバー自身の中でもう一度AIに何か考えさせたい場面が出てきます。集めた情報を要約させる、翻訳させる、といった処理です。

ここで選択肢が2つに分かれます。サーバー自身がAIのAPIキーを持ち、自分で呼び出す方法と、接続しているクライアント側に「代わりに呼んでほしい」と頼む方法です。MCPが用意しているのは後者で、サンプリングと呼びます。

公式仕様は、サンプリングにも人間が止められる機会を求めています。サーバーから来た依頼をそのままAIに投げるのではなく、送る内容をユーザーが確認・編集でき、返ってきた結果もユーザーが確認してから使う。この一往復が前提です。

通知：進んでいることを伝える

時間のかかる処理を頼んだとき、何も反応がないと「動いているのか、止まっているのか」が分かりません。これに応えるのが通知です。

長く続く処理の途中で、サーバーは進み具合をクライアントに送ることができます。今どこまで進んだか、全体のどれくらいかという値です。

通知を送るかどうか、どれくらいの頻度で送るかは、サーバー側が自由に選べます。一切送らないサーバーがあってもかまいません。受け取る側も、表示するかどうかを自由に決められます。

ルート：どこを触っていいかを伝える

3つ目はルートです。サーバーがローカルのファイルを扱う必要があるとき、「どこまでなら触っていいか」を先に知っておく必要があります。ルートは、クライアントがその境界をサーバーに伝える仕組みです。

境界となるのは、実在するフォルダやファイルを指すfile://形式のURIです。ユーザーが選んだプロジェクトフォルダの範囲だけをサーバーに見せる、という使い方をします。

この「自動では守られない」という一点は、次のレッスンで扱う安全の話の出発点になります。

この行き来は、通信のやり方に支えられている

サンプリング・通知・ルートのように、サーバーからクライアントへ話しかける動きは、実際にはどう通信で実現されているのでしょうか。MCPは通信のやり方（トランスポート）を2種類定めています。

どちらの上でも、ここまで見てきたツール・リソース・プロンプト・サンプリング・通知・ルートという機構そのものは変わりません。変わるのは、その行き来がどう配線されているかだけです。通信方式の細部まで踏み込むのは、実装に入ってからで十分です。

やってみよう

演習1：サンプリングが役立つ場面を考える

自分が使いたい、または作りたいMCPサーバーを思い浮かべてください。そのサーバーが、集めた情報を要約する・翻訳する・言い換えるといった処理を挟みたくなる場面はありますか。あるなら、それがサンプリングの候補です。

演習2：進捗通知がないと不安になる処理を挙げる

自分の業務で、実行に時間がかかり、何の反応もないと不安になる処理を1つ挙げてください。その処理をMCPサーバー化するなら、通知をどのタイミングで送るとよいか考えてみてください。

今日のまとめ

3行で振り返ります。

• サンプリングは、サーバーが自分でAIの鍵を持つ代わりに、クライアントに呼び出しを頼む仕組み
• 通知は、時間のかかる処理の進み具合をサーバーからクライアントへ伝える、任意の仕組み
• ルートはアクセスしてよい範囲を伝えるだけで、守る処理は実装側が自分で書く必要がある

次のレッスンでは、この「自分で書く必要がある」という一点を軸に、MCPの安全性が誰の責任なのかをまとめます。