第4章 — クライアントプリミティブ: エージェント的な振る舞いと制御

LLM Primer IV: MCPで設計するAI認知 のウォークスルー第4回です。サーバープリミティブはサーバーが提供できるものを公開しますが、クライアントプリミティブはホストが貸し戻すものを公開します — 一つひとつの貸し出しが、ユーザーが許可する能力であり、ホストが代理で受け入れるリスクです。

なぜこの章があるのか

Resources、Prompts、Tools だけを公開するサーバーは、ホストについて何も知りません。どのモデルが走っているか、どのファイルが見えているか、そもそもユーザーがキーボードの前にいるかどうかも。多くの統合では、その壁は意図的なものです。一方で、有用な振る舞いの広いカテゴリにとっては、壁が高すぎます。長い文書を要約するサーバーが、自前のLLMを持ち運ぶ必要はない。プロジェクト上で作業したいサーバーは、どのプロジェクトかを知るべきです。破壊的な操作のためにユーザーの許可がいるサーバーは、それを問えるべきです。クライアントプリミティブは、MCPが小さくて制御された穴を壁に穿つ方法です。

3つのプリミティブ — Sampling、Roots、Elicitation — はそれぞれ、サーバーの届く範囲をホストの領分へ、明確に交渉された形で伸ばします。それぞれが、ホストがユーザーの代わりに受け入れるセキュリティ面でもあり、3つを組み合わせると、部分の和より「エージェント的」な振る舞いが生まれます。

4.1 Sampling: ホストの「脳」を借りる

Samplingが有効だと、サーバーはホストに推論呼び出しを実行させ、結果を受け取れます。サーバーはモデルを持ち歩かず、APIキーも持たず、ホストが実際にどのモデルを使ったかすら知りません — メッセージと、ソフトな選好(コスト、速度、知能)を送り、ホストが呼び出しを行う。サーバーから見ると、ホストは汎用LLMエンドポイントになっています。

レバレッジは本物です。文書ストアのサーバーは、ドメイン知識をホストへ漏らさず、推論自体を持ち歩かずに、自分のロジックの中で小さな推論ステップ — 取得、ランク付け、比較 — を回せます。リスクも同じくらい本物です。悪意あるサーバーは、ホストのモデル — そしてユーザーの予算 — を、ユーザーが承認しなかった作業に使えます。古典的な攻撃は、ユーザー指示を装ったSamplingペイロード。ホストが唯一の防衛線で、だから成熟したホストは、特定のサーバーに対してユーザーがオプトインしない限りSamplingを拒否するのを既定にし、各呼び出しのプロンプトを検査可能に表示し、セッションあたりの呼び出し回数を上限し、コストはサーバー側ではなくユーザーのウォレットへメーターします。

もうひとつの繊細な懸念: Samplingは内部にエージェント・ループを内包できます。ホストから見れば1回のSampling呼び出しに見えますが、サーバーの中では一つのサブ・エージェントがまるごと走っている、というケース。名付ける価値のあるパターンは 束縛されたサブ・エージェント — ユーザーがN回の呼び出し、T秒、X円の予算を与え、サーバーはその封筒の中で好きにやり、結果か上品な部分結果を返す。Samplingは会話そのものへのアクセスをサーバーに与えません。サーバーが見えるのは自分が送ったものだけ。会話のコンテキストをSamplingペイロードへ密輸するホストは、意図にかかわらず信頼境界を弱めています。

4.2 Roots: ファイルシステムの境界とプロジェクトスコープ

Rootは、ホストが「スコープ内」と宣言したURIです — 通常は file:// ですが、仕様は一般的です。サーバーは roots/list を呼んで「私は何を相手にしますか」と尋ねます。ホストは初期化時に roots 能力を広告し、ユーザーがプロジェクトを切り替えたら notifications/roots/list_changed を発します。リストはただのリストで、入れ子の権限言語も、globパターンも、include/excludeルールもありません。

粗さは意図的で、MCP全体に通底する設計選択を反映しています。プロトコル層で細かな権限言語を作ると、安全の偽物の感覚が生まれます — ユーザーは長いスコープリストを読んで「プロトコルが強制している」と思い込みますが、実際にはプロトコルは、その言語が想定しなかった形でサーバーが行儀悪く動くのを防げません。外部の隔離 — プロセス境界、コンテナのマウント、OSレベルのアクセス制御 — に裏付けられた粗いプリミティブのほうが、強制がどこに住んでいるかについて正直です。Roots はプロトコル層では名誉制度、サンドボックスがある場面ではランタイム層で強制可能になります。

実務上の含意が2つ。第一に、Rootsが変わると、行儀の良いサーバーは古いRootに紐づくキャッシュ状態 — インデックス、パースしたAST、見張っていたファイルのサブスクリプション — を破棄します。さもなければプロジェクト境界をまたいで状態が漏れます。第二に、Rootsは サーバーが何を見るべきか を縛り、何をしてよいか を縛りません。許可されたRoot内の機密ファイル — 認証情報のダンプ、envファイル、私信 — は依然として機密で、行儀の良いサーバーは何を表に出すかについて判断を働かせます。

4.3 Elicitation: サーバーから問い返させる

Elicitationは3つの中で最も新しく、第一波のエージェント配備から設計者が学んだことを反映しています。サーバーは elicitation/create をメッセージ(質問)と requestedSchema(期待する答えの形)とともに発します。ホストは質問を自分のUIで描画し、答えを集め、検証し、返します。サーバーは答えを手にして作業を再開します。

スキーマが Elicitation を自由記述プロンプトより安全にする要素です。booleanには散文で答えられません。enumには4つ目の選択肢で答えられません。ホストは「これはYes/Noを求められている」とユーザーに明確なUIで示せ、それ以外を拒否できます。仕様は意図的にスキーマを「プリミティブのフラットなオブジェクト」に制限します — 本物のフォームなら、引数スキーマがそのフォーム自体になるToolを使い、起動前にユーザーがモデルの埋めた値をレビューできるようにします。Elicitationは1つか2つのフィールドの場合のためのものです。

リスクの形はフィッシング型です: 「続行にはAWSアクセスキーが必要です」と表面化するサーバーは、ユーザーに秘密情報を間違った場所で打たせようとしている。ホストはこれを、明示的な帰属表示 — 各Elicitationプロンプトに発信元サーバーをアシスタントの声と分けてラベルする — と、認証情報っぽいスキーマを拒否することで緩和します。正のひっくり返しは、破壊的ツールの確認パターン: Toolの最初の仕事はElicitationで「本当に?」と聞き、確認があってはじめて動く。これは本番MCPの堅牢化実務として、最も効くものの一つです。

4.4 3つを組み合わせる

プリミティブは組み合わせるよう設計されています。3つを全部持つサーバーは、事実上、完全なエージェント・ランタイムをホストに委ねている: スコープ(Roots)を読み、推論(Sampling)し、明確化(Elicitation)を求め、自分のToolsを通じて動く。組み合わせ方が大事です。Sampling + Roots は自律的なエージェント・サーバー。Sampling + Elicitation はファイルシステムに届かない会話サーバー。Roots + Elicitation は決定的な助手。単独ではそれぞれ束縛されていますが、合わせると掛け算になり、ホストの同意UIは、各能力を孤立して許可するより、組み合わせを名指して許可できるときに最も良くなります。

この章を踏まえて

サーバープリミティブとクライアントプリミティブで、ホストとサーバーが相互にできることは出そろいました。まだ扱っていないのは、これらがどうやってワイヤを渡るか、です。tools/list も sampling/createMessage も抽象的なメッセージではなく、トランスポートに乗ります。トランスポートの選択は、MCP統合の運用特性をほぼすべて静かに決めます。サーバーも見つけられる必要があります — 使いたいホストは、サーバーが存在し、どこに住み、その主張を信じるべきかを知らねばなりません。第5章は両方を扱います。

次回 — 第5章: トランスポートとディスカバリ。 MCPがサポートする3つのトランスポート — stdio、SSE、Streamable HTTP — の正直な比較と、点と点の統合をエコシステムに近づける .well-known/mcp.json とServer Cardの層。