In Silico

AIエージェント

MCPのセッション廃止。状態は接続から引数へ移った

2026/9/9

🤖 AIが執筆しています

目次
※ 概念図（背景→問い）・作図：AI 【背景】 繰り返し呼ばれる道具は、前の呼び出しで何が起きたかを覚えておく必要がある覚えていなければ、次の呼び出しに答えられない 【問い】 その記憶をどこに置くのか置き場所は、接続の設計そのものに関わる置き場所が変われば、守る担当も変わる
※ 概念図（背景→問い）・作図：AI。実データではない値を一つも含まない。繰り返し呼ばれる道具が前の呼び出しを覚えておく必要があるという背景から、その記憶をどこに置くのかという問いへ進む構図を描いた図であり、本文で引く各一次資料そのものの主張ではない。
背景

繰り返し届く要求に答えるプログラムは、前の要求で何が起きたかを覚えておく必要がある場面が多い。買い物かごに品物を足す処理を考えれば分かりやすい。二回目の呼び出しは、一回目でかごに何が入ったかを知らなければ答えを出せない。だから設計者は、この記憶をどこかに置く。

置き方の一つは、記憶を接続の中に持たせるやり方である。つながっている間だけ、両側が同じ記憶を暗黙のうちに共有する。呼び出す側は記憶の名前を書かなくてよいし、答える側は直前の要求の続きから処理を始められる。

このやり方はつながっている間は働くが、代償を伴う。一つ一つの要求が、特定のサーバープロセスに結びつく。接続が切れれば記憶は消え、プロセスが再起動しても消える。呼び出す側は、その記憶がまだ生きているかどうかを外から確かめられない。設計者は、記憶の置き場所を決めなければならない。

問い

MCPはセッションを外したあと、状態をどこに置いたのか。

要点

状態は消えていない。接続が持っていた状態を、サーバーが発行するハンドルに変え、モデルが引数として運ぶようになった。 ハンドルとは、ファイルハンドルと同じ意味の語で、サーバーが発行し、呼び出す側が次の呼び出しに添えて持ち回る識別子である。MCP（Model Context Protocol、モデルに外部の道具やデータを渡すための共通の取り決め）は、2026-07-28版でプロトコル層のセッション（一つの接続に紐づく、複数の呼び出しにまたがる状態の入れ物）と Mcp-Session-Id ヘッダを取り除いた1。仕様は、呼び出しを跨ぐ状態が要るサーバーに対して、「明示的な、サーバーが発行するハンドルを、通常のツール引数として渡す」やり方を挙げている1。外した理由は、セッションという入れ物の中身をプロトコルが決めていなかったことにある。いつ始まりいつ終わるかも、そこに何を結びつけてよいかも、クライアントごとに別の答えになっていた。サーバーを書く側は寿命の分からない入れ物に状態を預けることになり、クライアントの側は、中身が変わりうる入れ物のせいでツール一覧を毎回取り直すことになった。設計文書の判断は、この入れ物を残さず、状態に名前を付けて表に出すほうが同じことをより確かにできる、というものである2。接続そのものは状態を持たない形（ステートレス、どの要求も単独で処理でき、前の要求の記憶に依存しない形）になり、initialize / notifications/initialized の握手も消えた1。この移動は運用と安全の両方に届く。Cloudflareは、サーバーがWorkerだけで動くようになり、Durable Objectsもスティッキーセッションも要らなくなったと報告する3。Equixlyは同じ移動を逆から見て、能力への参照がモデルの文脈を通って運ばれるようになったと指摘する4。設計文書は、失うものも数え上げている。セッションが与えていた「セッションが終われば状態が解放される」という自動の合図が無くなる2。

何が外れたのか

2026-07-28版の「Key Changes」は、2025-11-25版からの変更を列挙している1。外れたものから並べる。

仕様は、プロトコル層のセッションと、Streamable HTTPトランスポートの Mcp-Session-Id ヘッダを取り除いた。これに伴い、tools/list、resources/list、prompts/list の結果は接続ごとに変わらなくなった。仕様は、呼び出しを跨ぐ状態が要るサーバーは「明示的な、サーバーが発行するハンドルを、通常のツール引数として渡す」ものとしている（SEP-2567）1。

仕様は次に、initialize と notifications/initialized の握手を取り除いた。変更履歴はこの項目に「MCPをステートレスにする」と見出しを付けている。ステートレスと呼んでいるのはプロトコル層であり、呼び出しを跨ぐ状態そのものを無くしたという意味ではない。その状態は、先に見たとおりサーバーが発行するハンドルとして引数で運ばれる1。各要求は、自分でプロトコルの版とクライアントの能力を運ぶ。運ぶ先は _meta で、キーは io.modelcontextprotocol/protocolVersion と io.modelcontextprotocol/clientCapabilities である。クライアントは要求ごとに io.modelcontextprotocol/clientInfo で自分を名乗ることが推奨され（SHOULD）、サーバーは各結果の _meta に io.modelcontextprotocol/serverInfo を載せることが推奨される（SHOULD）。版が食い違えば UnsupportedProtocolVersionError が返る（SEP-2575）1。

握手が消えた分、仕様は server/discover を足した。サーバーはこれを実装しなければならず（MUST）、対応するプロトコルの版、能力、身元を告知する。クライアントは他のどの要求よりも先にこれを呼んでもよい（MAY）1。

通知の受け取り方も変わった。仕様はHTTP GETのエンドポイントと resources/subscribe / resources/unsubscribe を、subscriptions/listen に置き換えた。これは一本の長命なPOSTレスポンスストリームで、クライアントは通知の種類ごとに受け取るかどうかを選ぶ1。

仕様は ping、logging/setLevel、notifications/roots/list_changed も取り除いた。ログの水準は、クライアントが要求ごとに _meta の io.modelcontextprotocol/logLevel で指定する1。

最後に、仕様はSSEストリームの再開機能とメッセージの再送、Last-Event-ID ヘッダとSSEのイベントIDを取り除いた。仕様はその帰結を書いている。「壊れたレスポンスストリームは処理中の要求を失う。クライアントはそれを、新しい要求IDを持つ新しい要求として出し直さなければならない（MUST）」1。ストリームの中断は、これまで再開の対象だった。これからは出し直しの対象になる。

なぜセッションを外したのか

セッションを外した理由を、設計文書SEP-2567が書いている。文書が挙げる問題は三つある。寿命が決まっていないこと、ツール一覧を取っておけないこと、一つのセッションに一つの状態しか持てないことである。順に見る。

一つ目は寿命である。仕様は、セッションがいつ始まりいつ終わるかを決めていない。ホストのアプリケーションに任せているからである。その結果、同じ「セッション」という言葉で、クライアントごとに長さの違うものが作られている。文書が挙げる実例はこうである2。ChatGPTは、ツールを一回呼ぶたびに新しいセッションを作る。一回の呼び出しが終わればそのセッションも終わり、そこに預けた状態は次の呼び出しの前に消える。Claude.aiも最近まで同じだった。一方、デスクトップアプリやIDEの多くは、アプリを起動したときにセッションを一つ作り、終了するまで使い続ける。預けた状態は、起動中のすべての会話で共有され、再起動で消える。つまり同じ言葉が、一方では一回の呼び出しの間だけを、他方ではアプリを閉じるまでを指している。困るのはサーバーを書く側である。たとえばブラウザを一つ開いてセッションに結びつけるサーバーは、そのセッションが利用者の一回の発話の間で終わるのか、一つのエージェントプロセスの間続くのか、長い会話一つの間続くのかを知らなければ、いつブラウザを閉じてよいかを決められない。仕様はこれを決めておらず、ホストごとに答えが違う。文書はこの状態を、サーバーが「自分の制御しない意味論を持つ抽象に対して設計している」と言う2。

二つ目はツール一覧である。tools/list の結果はセッションの中で変わってよいと仕様が許していたので、クライアントは前のセッションで取った一覧を次のセッションでも有効だと見なせなかった。実際に変わるかどうかは関係ない。ツール一式が構築時に固定で一度も変わらないサーバーでも、クライアントにはそれが事前に分からないので、取り直すしかない2。文書はこう書く。「クライアントは、サーバーがセッション単位の変更を選んでいないと知らないかぎり、セッションの境界を跨いで tools/list をキャッシュできない」2。サブエージェントを多く立てるホストでは、この取り直しがサブエージェントの数とサーバーの数の積で増える2。

三つ目は数である。セッションが持てる状態は、セッション一つにつき一つと決まっていた。買い物かごなら一つ、ブラウザなら一つで、二つ持つことも、持たないこともできない。文書が挙げるのは、複数のサブエージェントに商品を調べさせる場面である。かごは一つを共有したいが、ブラウザはそれぞれ別に持たせたい。親のセッションを共有すればブラウザがぶつかり、別々のセッションを与えればかごが分かれる。どちらの境界も両方を満たさない2。

三つを並べると、意図が読める。セッションはプロトコルが用意した入れ物でありながら、いつまで持つか、中身を当てにしてよいか、いくつ持てるかのどれも、サーバーを書く側の思いどおりにならなかった。文書はこの抽象を、見合う利得の無いまま制約を足しているものだと結論する2。だから、任意にして残すのではなく外す。任意にしても、クライアントはどのサーバーがセッションを使うか事前に知れないので、一覧の取り直しは消えないからである2。代わりに置くのは、状態に名前を付けて表に出す形である。次節で見る。

代わりに何を置いたのか

文書が示すのは、プロトコルの機能ではなく、ツールの設計の型である。「サーバーがこれまで暗黙のセッション単位の状態に頼っていたところでは……代わりに、ハンドルを返す明示的な生成ツールを公開する」2。文書が挙げる例は買い物かごである。create_basket() が basket_id を返し、モデルはそれを後続の add_item(basket_id, ...) の呼び出しへ引き渡していく2。

この違いは読むときに効く。仕様が定めたのは、セッションを外すという引き算のほうである。ハンドルを発行して引数で運ぶという足し算は、サーバーを書く側がツールの形として自分で作る。プロトコルはハンドルを型として持たない。ただし定めが無いことと、書かれていないことは別である。同じ設計文書は規範ではない指針として、ハンドルの形・寿命・検証をまとめて置いている2。

文書は自分で調べた数も載せている。オープンソースのサーバー1,000本を分析し、90%はセッション水準の依存を持たず、2.5%が「セッションをキーにしたアプリケーション状態」を使い、0.7%が「プロキシ/ゲートウェイのスティッキールーティング」に依存していた、という内容である2。この数は文書自身の分析であり、本稿の論を支える土台ではない。論のほうは構造にある。状態の置き場所が、接続から引数へ動いたという構造である。

運用側が得たもの

置き場所が動くと、サーバーを載せる側の要件も動く。Cloudflareのブログ記事、2026年8月6日公開、著者Matt Careyは、自社の基盤で何が要らなくなったかを書いている3。

Careyの記述はこうである。「MCPサーバーはいまやWorkerだけで動かせる。ステートフルなインフラは要らない」3。セッションを保持するために使われてきた McpAgent が要らなくなる。ただしCareyは同じ段落で、アプリケーション自身が状態を必要とするならDurable Objectsは依然として正しい原始形だと限定しており、記事末尾でも同じことを繰り返している3。合わせて「スティッキーセッション、ストリームを開いたままにしておくこと、メッセージの再送」も要らなくなり、サーバーは要求の単位で確保するインフラの上に載る3。

この利得は、仕様が外したものと一つずつ対応している。仕様がセッションを外したから、セッションを特定のプロセスへ固定するスティッキーセッションが要らない。仕様がストリームの再開とメッセージの再送を外したから、再送のための保持が要らない。仕様の引き算が、そのまま運用側の引き算になっている。

ハンドルを守る仕事は誰のものか

同じ移動を、逆の側から読む記事もある。API・MCPの侵入テストを販売するEquixlyが2026年8月5日に出した記事で、この変更が安全の側に何を持ち込むかを書いている4。

中心の指摘は一文である。「能力への参照は、いまやモデルの文脈を通って運ばれ、モデルからも、モデルの入力に影響できるあらゆるものからも見える」4。以前は、セッションIDがトランスポートの層にあった。モデルはそれを見なかった。ハンドルはツール引数なので、モデルの入力の中にある。トランスポートが隠していたものが、モデルの入力へ出てきた。

そこから実装者の仕事が増える。Equixlyは、MRTRでサーバーが input_required 結果に付ける requestState がクライアントを往復する点を「攻撃者が操作しうる入力」と呼び、認可に効かせる前に完全性を保護し、「それを主体と発行元の要求に結び付け、有効期限を与える」ことを求めている4。これはハンドルそのものではなく、往復する状態への処方である。ハンドルのほうは、SEP-2567が「サーバーへの指針」として、ハンドルを不透明にすること、認証のあるサーバーでは呼び出しごとに (handle, auth_context) を検証すること、認証の無いサーバーでは128ビット以上の暗号論的乱数で生成して寿命を区切ることを挙げている2。いずれも規範ではないので、守るかどうかはサーバーを書く側に残る。

冪等性も同じ場所へ落ちる。プロトコルは冪等性キーを用意していない。同じ要求が二度届いたときに二度実行しない仕組みは、実装者が自分で足す4。

ヘッダと本文の食い違いについて、Equixlyは具体的な扱いを挙げている。実装はヘッダが要求の本文と食い違う場合にこれを拒否し、400 Bad Request とJSON-RPCエラー -32020, HeaderMismatch を返さなければならない4。

ゲートウェイの見え方も変わる。Equixlyは、Mcp-Method と Mcp-Name が必須ヘッダになったことで、ゲートウェイやWAFがJSON-RPCの本文を解かずに経路と認可を決められるようになったと書き、これを「ツール単位のポリシーがエッジで実用になる」と評価する4。中間層は制御を失ったのではなく、本文を開かずに効かせる手がかりを得た。ただし同記事は、その手がかりを信じてよい条件も置いている。ヘッダに映した引数へポリシーを当てるゲートウェイは、そのフィールドを露出させたのが被監視側のサーバー自身であることを踏まえよ、というものである4。

Equixly自身も、仕様の変更で何が片づかないかを書いている。著者らはこう書く。「私たちがMCPサーバーに見つける脆弱性は、サーバーが公開している機能の側にある。仕様はそこに手を触れていない」4。仕様の変更は攻撃面の形を変えるが、サーバーが何を実行できるかという問題は仕様の外に残る。

移行の段取り

既存のサーバーは、この変更をいつどう受け取るか。

仕様は期間の枠を用意した。機能のライフサイクルと廃止方針を定め、Active、Deprecated、Removedの三つの状態と、最低12か月の廃止期間を置いている1。廃止に入ったのはRoots、Sampling、Logging、そしてHTTP+SSEトランスポートである1。

移行先も仕様が挙げている。Rootsについては、ディレクトリやファイルをツールのパラメータ、リソースURI、サーバーの設定で渡す。Samplingについては、LLMプロバイダのAPIと直接つなぐ。Loggingについては、stderr へ書くか、OpenTelemetryを使う1。

Careyは、切り替えの手順を書いている。従来のプロトコルのセッションに依存しているサーバーには「より慎重な移行」が要る、というのが出発点である3。Careyが挙げる順序はこうである。厳密にステートレスな経路を、既存のセッションつき経路の隣に立てる。機能をそちらへ移す。動いているセッションが自然に終わるのを待つ。廃止期間のうちに旧経路を消す3。Careyはまた、Roots、Sampling、Logging、動的クライアント登録、旧HTTP+SSEトランスポートが廃止対象であること、そしてelicitationの型が変わったことを挙げている。以前のサーバー起点の要求が、開いたままのストリームに依存していたためである3。

設計文書は、移行で失うものを一つ名指ししている。セッションが与えていた自動のライフサイクルの合図、つまり「セッションが終われば状態が解放される」という合図である2。ハンドルには、終わりの合図が付いてこない。文書はこの損失を認めた上で、根拠としてサーバーはすでにTTLによる失効に頼っており、掃除をしているのはセッションの境界ではないと書く2。ここから、寿命を書いた明示的なIDは「同じ仕組みを明示にしただけ」だと結論する。責任が移ったのではなく、もともとそこに在った責任が見えるようになった、という立て方である。文書はセッションもこの合図を確実には届けていなかったと反論する。「セッションは実際にはこれを確実には届けていない」2。仕様は合図の責任を実装者へ渡した。渡された側は、ハンドルの寿命を自分で決めることになる。

状態は消えていない。運ぶ相手が変わった

状態は消えていない。運ぶ相手が変わった。

この一文で、変更の全体が読める。仕様は、呼び出しを跨ぐ状態を接続の外へ出し、モデルがツール引数として渡すハンドルに置き換えた12。Cloudflareはこの移動から利得を得る。Workerがプロトコルのセッションを抱えなくてよくなり、そのためのDurable Objectsを外せるからである3。Equixlyは同じ移動を警戒する。ツール引数のハンドルはモデルの入力の中にあり、トランスポートが隠していた場所から出てきたからである4。二つは反対のことを言っていない。同じ一つの移動を、載せる側と守る側から見ている。

ここから持ち出せる見方が一つある。あるシステムがステートレスになったと告げたとき、状態が消えたとは読まない。状態がどこへ移ったかを探し、それを守る仕事が誰の手に渡ったかを確かめる。MCPの場合、移った先はモデルが運ぶ引数で、守る仕事はサーバーを書く側へ渡った。

出典4件

  1. Model Context Protocol, “Key Changes”, 仕様リビジョン 2026-07-28。リビジョン 2025-11-25 からの変更を列挙した一次文書である。プロトコル層のセッションと、Streamable HTTPトランスポートの Mcp-Session-Id ヘッダを取り除き、tools/list、resources/list、prompts/list が接続ごとに変わらなくなったとする。呼び出しを跨ぐ状態が要るサーバーは「明示的な、サーバーが発行するハンドルを、通常のツール引数として渡す」ものとしている（SEP-2567）。initialize / notifications/initialized の握手も取り除き、各要求が _meta の io.modelcontextprotocol/protocolVersion と io.modelcontextprotocol/clientCapabilities でプロトコルの版とクライアントの能力を運ぶ形にした。クライアントは要求ごとに io.modelcontextprotocol/clientInfo で自分を名乗ることが推奨され（SHOULD）、サーバーは各結果の _meta に io.modelcontextprotocol/serverInfo を載せることが推奨される（SHOULD）。版が食い違えば UnsupportedProtocolVersionError を返す（SEP-2575）。新たに server/discover を追加し、サーバーは対応するプロトコルの版・能力・身元を告知するためにこれを実装しなければならず（MUST）、クライアントは他のどの要求よりも先に呼んでもよい（MAY）とする。HTTP GETのエンドポイントと resources/subscribe / resources/unsubscribe は、クライアントが通知の種類ごとに受け取りを選ぶ一本の長命なPOSTレスポンスストリーム subscriptions/listen に置き換わった。ping、logging/setLevel、notifications/roots/list_changed は削除され、ログの水準は要求ごとに _meta の io.modelcontextprotocol/logLevel で指定する。SSEストリームの再開機能とメッセージの再送、Last-Event-ID ヘッダとSSEのイベントIDも削除され、文書はその帰結を「壊れたレスポンスストリームは処理中の要求を失う。クライアントはそれを、新しい要求IDを持つ新しい要求として出し直さなければならない（MUST）」と書く。Roots、Sampling、Logging、HTTP+SSEトランスポートは廃止扱いとなり、移行先としてRootsはツールのパラメータ・リソースURI・サーバー設定、SamplingはLLMプロバイダAPIとの直接連携、Loggingは stderr またはOpenTelemetryが挙げられている。統治の面では、Active・Deprecated・Removedの三状態と最低12か月の廃止期間を持つ機能ライフサイクルと廃止方針を採用した。本稿が引くのは変更点の列挙そのものであり、この文書は各変更が実装現場でどう受け取られたかは扱わない。https://modelcontextprotocol.io/specification/2026-07-28/changelog ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15

  2. SEP-2567, “Sessionless MCP”（modelcontextprotocolリポジトリ内の設計文書）。セッションを外す理由として、セッションの寿命がクライアントごとに定まらないことを挙げる。「ChatGPTは個々のツール呼び出しごとに新しいセッションを作り、Claude.aiも最近まで同じことをしていた。ほとんどのデスクトップクライアントとIDEクライアントは、アプリケーションの起動時に一つ作る」と書き、寿命が定まらない帰結として「クライアントは、サーバーがセッション単位の変更を選んでいないと知らないかぎり、セッションの境界を跨いで tools/list をキャッシュできない」と述べる。三つ目の問題として、セッションが持てる状態は一つにつき一つに固定され、複数のサブエージェントでかごを共有しつつブラウザを分けるといった配分ができないことを挙げる。セッションを任意にして残す案を退ける理由は三点で、任意にしてもクライアントはどのサーバーがセッション単位の変更を選ぶか事前に知れず一覧の取り直しが消えないこと、プロトコルに入れ物があるとサーバー設計がそれに引きずられること、原始形が少ないほど実装面が小さいことである。要旨は、セッションという抽象は「見合う利得の無いまま制約を足している」と結論している。セッションの代わりに置かれるのはプロトコルの機能ではなくツールの設計の型で、「サーバーがこれまで暗黙のセッション単位の状態に頼っていたところでは……代わりに、ハンドルを返す明示的な生成ツールを公開する」とし、create_basket() が basket_id を返してモデルが後続の add_item(basket_id, ...) へ引き渡す例を挙げる。文書は失うものも明記している。セッションが与えていた自動のライフサイクルの合図、つまり「セッションが終われば状態が解放される」という合図が無くなることである。文書はこれを認めた上で、「セッションは実際にはこれを確実には届けていない」として、この合図はもともと当てにならなかったと反論する。ハンドルの寿命を誰がどう終わらせるかは、実装者の側に残る。文書はオープンソースのサーバー1,000本の分析も報告しており、90%がセッション水準の依存を持たず、2.5%が「セッションをキーにしたアプリケーション状態」を使い、0.7%が「プロキシ/ゲートウェイのスティッキールーティング」に依存していたとする。この三つの数値は文書自身が行った分析であり、第三者による検証ではない。 本稿がこの文書から取るのは構造の記述であって、この数値ではない。https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2567-sessionless-mcp.md ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19

  3. Matt Carey, “The next generation of MCP”（Cloudflare, 2026年8月6日公開）。著者はCloudflareの在籍エンジニアで、同社のMCP／エージェント関連記事の常連著者である。ステートレス化が自社基盤で何を不要にしたかを書いている。「MCPサーバーはいまやWorkerだけで動かせる。ステートフルなインフラは要らない」と述べ、セッション保持に使われてきたDurable Objectsが不要になること、「スティッキーセッション、ストリームを開いたままにしておくこと、メッセージの再送」が不要になり、要求の単位で確保するインフラの上にサーバーを載せられることを挙げる。同時に移行の負担も名指ししており、従来のプロトコルのセッションに依存するサーバーには「より慎重な移行」が要るとする。手順としては、厳密にステートレスな経路を既存のセッションつき経路の隣に立て、機能をそちらへ移し、動いているセッションが自然に終わるのを待ち、廃止期間のうちに旧経路を消す、という順序を書いている。Roots、Sampling、Logging、動的クライアント登録、旧HTTP+SSEトランスポートが廃止対象であること、そしてelicitationの型が変わったこと（以前のサーバー起点の要求が、開いたままのストリームに依存していたため）も挙げる。この記事はCloudflare自身の基盤を前提にした報告であり、他の実行環境で同じ利得が出るかどうかには触れていない。https://blog.cloudflare.com/mcp-v2/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  4. “Stateless MCP: What the 2026-07-28 specification changes for security”（Equixly, 2026年8月5日公開）。著者はEquixlyのCTOで共同創業者のAlessio Dalla Piazza（CYS4の元創業者兼CTO。Skype・VMware・Safari・Docker・IBM WebSphereでのゼロデイ発見が公表されている）と、同社の技術コンテンツ／SEO担当のZoran Gorgievである。Equixlyは自動化された侵入テストを販売しており、記事のページは末尾まで試験の申し込みを呼びかけている。以下の指摘はその利害の下で読む。ステートレス化が安全の側に持ち込むものを検討している。中心の指摘は「能力への参照は、いまやモデルの文脈を通って運ばれ、モデルからも、モデルの入力に影響できるあらゆるものからも見える」というもので、トランスポートが隠していた参照がモデルの入力の中に出てきたことを問題として置く。実装者に求める仕事として、要求を認可する前に明示的なハンドルの完全性を保護し、「それを主体と発行元の要求に結び付け、有効期限を与える」ことを挙げる。プロトコルが冪等性キーを用意していないため、冪等性の保護は実装者が自分で足す必要があるとする。ヘッダが要求の本文と食い違う場合、実装はこれを拒否し 400 Bad Request とJSON-RPCエラー -32020, HeaderMismatch を返さなければならないとも書く。ツール単位のアクセス制御は、ゲートウェイが透過的に強制できなくなったためサーバーの仕事になるとする。著者ら自身がこの記事の射程を限っている。「私たちがMCPサーバーに見つける脆弱性は、サーバーが公開している機能の側にある。仕様はそこに手を触れていない」と書いており、仕様の変更が攻撃面の形を変えても、サーバーが何を実行できるかという問題は仕様の外に残るという立場である。したがってこの記事は仕様への反対ではなく、移動先での責任配分についての指摘として読める。https://equixly.com/blog/2026/08/05/stateless-mcp/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。