MCPは「ノートPCの前に座った人間」を前提に作られた。2026年のロードマップは、その人間を外す作業です
By Surya Pratap
2026年8月24日
12分で読めます
AI・テクノロジー
2026年8月24日
12分で読めます
4つの前提と、4つの置き換えHover to exploreModel Context Protocolのロードマップが2026年8月22日に更新されました。3番目の重点領域のなかに、今年エージェント基盤について書かれたもっとも本質を突く一文が埋まっています。
MCPの認可は、同意の瞬間にブラウザを開いた人間がいることを前提にしている。
この一文を読んだあとで残り4つの重点領域を読むと、機能一覧には見えなくなります。5つの戦線をもつ1つのプロジェクトです。つまり、このプロトコルはノートPCの前に座った人間を想定して設計されており、本番環境はそこに誰もいないことを繰り返し発見している、ということです。
この捉え直しには半日を割く価値があります。ロードマップのどの項目も、いま皆さんが手作業で解決している問題だからです。たいていは雑に、そしてたいていは「自分が判断を下した」と気づかないままに。
ロードマップは、これがリリース計画ではなく優先順位の文書であることを明言しています。これらの領域に入るSEP——Specification Enhancement Proposals——は「レビューが優先され、受理される見込みがもっとも高い」とされます。それ以外は待ち行列です。
5つの領域と、それぞれが取り除く「人間の前提」
2026年ロードマップの重点領域
stdioはstdin/stdout上で話されるHTTPになります。tools/callの戻り値の形を前提にしていました。どちらも成り立ちませんでした。最初の4つはアーキテクチャの話です。5つ目は、その4つがどう皆さんの手元に届くかの話であり、聞こえ以上に重要です。仕様変更がSDKに届くまでが数週間か数か月かを分けるからです。
ロードマップの前にリリースがありました。2026-07-28仕様がプロトコルのコアをステートレス化しており、これが今日動かしているシステムにもっとも影響しうる変更です。
具体的には、initialize/initializedのハンドシェイクとMcp-Session-Idヘッダーが廃止されました。各リクエストが自分のプロトコルバージョン、クライアントID、ケイパビリティを_metaに載せて運びます。仕様自身の言い方を借りれば、共有ストレージなしで、ごく普通のラウンドロビン・ロードバランサーの背後にあるどのサーバーインスタンスにも、どのリクエストも着地できるということです。
ハンドシェイクの廃止を創業者が気にすべき理由
ステートフルなセッションはロードバランサーと相性が悪いものです。リモートMCPサーバーを複数インスタンスで動かしていたなら、セッションを固定するか、Redisで状態を共有するか、あるいは黙って1台で運用して祈るかのいずれかだったはずです。3つとも、いまやプロトコルから取り除かれた前提に対する回避策です。そうした回避策を作っていたのなら、それは必要な複雑さではなく余分な重りに変わりました。次に作るものへ惰性で持ち込むより、意図して削除する価値があります。
同じリリースには、見落としやすく、それでいてすぐ役立つものが他に3つ入っています。
resultType: "input_required"を返し、クライアントはinputResponsesに回答を入れて元の呼び出しを再送します。接続が状態を保持することなく、人間による承認が実現します。Mcp-MethodとMcp-NameというHTTPヘッダーを持つようになり、ゲートウェイ、レートリミッター、WAFがJSONを展開せずヘッダーでルーティングと計測を行えます。ツール単位のレート制限をエッジで掛けたかったなら、欠けていたのはこの取っ掛かりです。ttlMsとcacheScopeが付きました。小さなフィールドですが請求額には大きく効きます。ツールカタログを毎セッション取り直すか、変わったときだけ取り直すかの差です。ロードマップのなかで、創業者が最初に体感するのはこの項目であり、そして「あれば便利な話」として片づけられやすいのもこの項目です。
ロードマップの言い分は、サーバーには「大量のツール群のなかをクライアントに案内するための選択肢がもっと必要」であり、クライアントは「カタログ全体を先に飲み込むのではなく、必要になった時点でサーバーのツールとリソースを知る」べきだ、というものです。
なぜこれが請求書の一行になるのか。いまはセッション開始時にツールカタログがコンテキストウィンドウへ入ります。すべてのツール、すべての説明文、すべてのパラメータスキーマが、タスクごとに入ります。それなりの規模のMCPサーバーを4つも5つも接続すれば、モデルがユーザーの最初の一文を読む前に数千トークンを消費し、次のタスクでも、そのまた次でも同じ額を払い直すことになります。
これは、詳しすぎるAGENTS.mdと同じ失敗が別の入口から入ってきたものです。タスクが必要とするかどうかに関わらず、無条件に読み込まれる内容という点で同じです。対処法もどちらも同じで、読み込みを条件付きにすることです。そして、その仕組みを代わりに作ってくれるワーキンググループがあるのは、2つのうち一方だけです。
ここから2つのことが導かれます。progressive discoveryが存在しないあいだは、接続するMCPサーバーの数は能力の判断ではなく、その場で効くコストの判断であり、既定値としては「ツールを絞ったサーバーを少数だけ」が正解です。そして実装が出たとき恩恵を受けるのは、ツールがクライアントに辿れる形へ整理されているサーバーです。これは仕組みの出荷を待たずに、ツールのまとめ方と命名という形で、いまから下せる設計判断です。
ロードマップはさらに、progressive discoveryがキャッシュ関連の作業と「定義されたかたちで連携する」と書いています。つまり、discoveryとTTLベースのキャッシュは衝突ではなく協調するよう設計されています。機能が初年度から使えるか3年目まで使えないかを分けるのは、こうした細部です。
3番目の重点領域は、問題を声に出して名指ししています。現状についてのロードマップ自身の記述です。
既存のMCPサーバーは、貼り付けられたAPIキーと長命なリフレッシュトークンに依存している。
これは、いま本番で動いているほぼすべてのエージェントシステムの正確な描写です。自分たちは安全だと考えている少なからぬシステムも含みます。これに対して優先される作業は次のとおりです。
何が標準化され、何を置き換えるのか
エージェントIDワーキンググループ（本期間中に発足予定）
委譲の側は強調しておく価値があります。実在のアーキテクチャ上の誤りに対応するからです。いまエージェントがサブエージェントを起動すると、そのサブエージェントはほぼ必ず親の認証情報で動きます。権限を狭めるには、誰も作らなかった仕組みが要るからです。つまり、チェーンのなかでもっとも信頼できない一段の影響範囲が、チェーン全体の影響範囲になります。これは仮定ではなく機構であり、AIエージェントに必要なのは、よりよいプロンプトではなく権限システムですで反対側から辿り着いたのと同じ結論です。
ひとつ注意があります。先週扱ったプロトコルの集約と同じ注意です。IDが答えるのは誰が呼んでいるかです。その要求が妥当かどうかには答えません。完璧に認証されたエージェントでも、Webページから悪意ある指示を読み込んでいれば、非の打ちどころのない資格情報で悪意ある呼び出しを行います。モデルから見える内容を信頼しないというエージェントのセキュリティガイドの内容は、これらすべてを経てもそのまま有効です。
ロードマップは納期ではありません。文書自身が「確約ではなく現時点の考え」と述べており、想定は6〜12か月先です。5領域のうち2つは、ワーキンググループがまだ発足途中です。
ですから有用な問いは「何を待つべきか」ではありません。「継ぎ目をどこに置くべきか、この文書は何を教えてくれるか」です。
tools/callの戻り値の形は、contentとstructuredContentが実装の分岐を生んだため再設計中です。変更予定リストに載っている形に対して、凝った処理を作り込まないでください。重いのは真ん中のカードです。最初の4領域にある項目はどれも、いま出荷しているチームが場当たり的に解決しているものです。創業者にとってのロードマップの価値は、自分の場当たり的な解決策のうちどれが設計上の暫定措置なのかを教えてくれる点にあります。そしてそれらこそ、コード中に散らばらせるのではなくインターフェースを与えるべきものです。
具体的に言えば、今四半期にエージェント製品を作るチームなら、認証情報の扱い、長時間タスクの扱い、ツールカタログの組み立てがそれぞれ1か所に小さな面積で収まっていれば、標準がSDKに届いたときの採用は何事もなく済みます。呼び出し箇所じゅうに塗り広げられていれば採用はされず、そしてそれは「優先順位の判断」と説明されることになります。
はっきり書いておくべきことが3つあります。よく書かれたロードマップは、網羅されているという軽い錯覚を生むからです。
エージェントを信頼できるものにはしません。 ここにあるのはすべてトランスポート、ID、discoveryの話です。モデルが正しいツールを選んだか、結果を正しく読んだか、止まるべきだったかには何も触れません。それは評価の問題であり続け、皆さんの問題であり続けます。
依存の連鎖は短くなりません。 ステートレスなコアと統一されたトランスポートは、サーバーを増やすことを容易にします。容易は無料ではありません。接続した各サーバーは、コンテキストのコストであり、障害の経路であり、信頼境界です。プロトコルが接続に強くなったことは、接続を増やす理由にはなりません。
計画を立てられる日程では来ません。 ワーキンググループの2つはまだ発足途中です。Tasksは依然として拡張であり、「いずれコアプロトコルへ取り込む」方向にあります。健全な計画とは、どの項目も「来年SDKに届くかもしれない」程度に扱い、届かない前提で作ることです。
8月22日に更新されたMCPのロードマップは、多くの企業が自社について書く文書よりも優れた戦略文書です。自らの誤った前提を、修正を革新として売り込むのではなく、平易な言葉で名指ししているからです。このプロトコルは、ブラウザを持つ人間が、ノートPCの前で、ひと握りのツールからの応答を数秒待つ、という想定で作られました。その4つの条件はいずれも本番環境ではすでに成り立たず、ロードマップはそれを解きほぐす作業です。
創業者にとっての実用的な中身は、機能一覧ではありません。いま自分が回避策で凌いでいる4つのこと——不在のユーザーのための認証情報、リクエストより長生きする処理、読み込むには大きすぎるカタログ、ノートPCとクラスタで挙動が違うトランスポート——が、設計上の暫定措置であり、名前のある人々が取り組んでおり、いまインターフェースの裏に置く価値がある、という確認です。
粗い版を作る。継ぎ目を残す。すでに標準があるものは、回避策を削除する。
出典: Model Context Protocol — ロードマップ、2026-08-22更新 · 2026-07-28仕様、MCPブログ · SEP-2575、ステートレスMCP · SEP-2549、リスト結果のTTL · SEP-2663、Tasks拡張 · ワーキンググループと関心グループ
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
