
MCPステートレス化とは?セッション廃止をやさしく解説
家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん(@passion_tanaka)です。
7月28日、AIのニュースで「MCPがステートレス化」「セッション廃止」という見出しが流れたよ。
正直、この言葉だけ見せられても何も浮かばないよね。
私も最初に見たときは頭が真っ白だった。
ざっくり言うと、AIが道具を使うときの手続きが1つ減った——ただそれだけの話。
でね、お店の注文にたとえながら、順番に見ていくね。
3行でわかるポイント
- 変わったのはAIの賢さじゃない。AIと道具の「つなぎ方の作法」が変わった
- 予約席のレストランが、フードコートになった。「いつもの席で」が通じる代わりに担当がいないと詰む店から、券を出せば誰でも作ってくれる店へ。この券に全部書いてある状態がステートレスで、番号札をやめたのがセッション廃止
- あなたが今日やることは、たぶんゼロ。私も自分のパソコンを11か所ぜんぶ点検したけど、直すところは1つもなかった
今日の最新LIVEや最新情報はGPTs研究会Facebookグループにも投稿してるから、そっちもチェックしてね。
そもそもMCPって、何のこと?

MCPは「Model Context Protocol(モデル・コンテキスト・プロトコル)」の略——名前は長いけど中身は単純。
ざっくり言うとAIに道具を持たせるための、差し込み口の規格だよ。
AIって、そのままだと頭だけの存在なんだよね。
賢いことは言えるけど、あなたのカレンダーは見られないし、資料も開けない。手がないから。
そこに「カレンダーを見る手」「資料を読む手」をくっつけるための決まりごとが、MCP。
だから「AI界のUSB-C」なんて呼ばれてる。
AIは腕のいい料理人。MCPは厨房のコンセントの形だよ。
ミキサーもオーブンも差し込み口の形がバラバラだったら、道具を1つ増やすたびに配線をやり直すことになる。
形をそろえておけば、道具を足すのも入れ替えるのも一瞬で済むよね。
その「形をそろえる約束」が、MCP。
で、今回のニュースはコンセントの形(作法)が変わったという話。
料理人の腕の話じゃないんだ。ここを押さえておくと、あとが全部つながるよ。
「セッション廃止」で何が変わった?予約席からフードコートへ

ひとつ前の決まりごと(2025年11月25日版)には、ちょっと変わったルールがあった。
AIが道具を使いたいとき、いきなり用件を言えなかったんだ。
まず「これから話しかけます」と挨拶して(これを initialize と呼ぶ)、相手から番号札をもらう。この番号札が Mcp-Session-Id。そのあと用件を言うたびに、毎回この番号札をそえる決まりだった。
この一連の仕組みがセッション。
そして今回、挨拶も番号札も、まるごと廃止された。これが「セッション廃止」だよ。
これまで=予約席のある常連レストラン。
「あ、いつものひろくんね。奥の席どうぞ」で通じるのは気持ちいい。
でも困るのは、担当の人が休んだ日。
「私の席、わかりますよね?」「……どなたでしたっけ」で止まっちゃう。
お客さんが増えたから席を増やそう、としても、誰がどの席かを全員が把握してないと成立しない。
これから=フードコートの食券制。
券に「カレー・大盛り・注文したのは私」まで全部書いてある。
だからどのカウンターに出しても作ってもらえる。担当が休みでも関係ない。
行列ができたら、カウンターをもう1つ開けるだけ。
この「券に全部書いてある状態」をステートレス(stateless)と言うんだ。
そのまま訳すと「状態を持たない」。
でも実際の意味は「相手が覚えていなくても困らないようにした」が正解だよ。
相手が自分のことを覚えてなくても、券に全部書いてあるから成立する。
毎回はじめて会う人として扱われても、ちゃんと注文が通る。それだけの話だね。
ニュースに出てくる言葉の早見表
他のニュースを読むときは、この言葉が並んでるはず。
意味だけ押さえておけば、どこで見ても迷わないよ。
ステートレス化を、お店のやりとりで見てみる

AIがあなたの資料を1つ探す、という場面で見てみるね。
AI「すみません、これから注文したいんですけど」
店「はい、ではあなたは7番です。この番号を覚えておいてください」
AI「7番です。資料を1つ探してください」
店「7番さんですね、承知しました」
──ここで、店が混んできて2つ目のカウンターが開く。
AI「7番です。もう1つ探してください」
店(2つ目のカウンター)「……7番? そんな番号、うちは知りませんが」
POST /mcp
method: initialize
↑ ① これが「最初の挨拶」
(返事)Mcp-Session-Id: 7番…
↑ ② これが「番号札」7番
POST /mcp
Mcp-Session-Id: 7番…
↑ ③ 毎回この番号札をそえる
method: tools/call name: search_docs
↑ ④ やっと用件(資料を探して)
3往復目でやっと用件が言えてるのが分かるかな。
そして②の番号を発行したのは1台だけ。だからお店側は「同じお客さんは必ず同じカウンターへ」と交通整理をして、さらに番号の台帳をしまう倉庫を別に用意して全カウンターで共有してた。手間だよね。
AI「この券です。“資料を1つ探す・頼んだのは私・今の決まりごとの版は7月28日版”。全部書いてあります」
店(どのカウンターでも)「はい、承知しました」
──混んできて3つ目のカウンターが開いても、
AI「この券です」
店(3つ目のカウンター)「はい、承知しました」
POST /mcp
Mcp-Method: tools/call
Mcp-Name: search_docs
↑ 封筒の表に書く「用事の欄」(新しく必須に)
protocolVersion: 2026-07-28
↑ 券の「決まりごとの版」
clientInfo: (誰が頼んだか)
↑ 券の「注文したのは私」
method: tools/call name: search_docs
↑ 用件
initialize の行と、Mcp-Session-Id の行が、まるごと消えてる。
これが「セッション廃止」。1回で全部書いてある状態が「ステートレス」だよ。
そのぶん券に書くことは増えたけど、誰が受け取っても通るようになった。
これがどれくらい効くかというと、GitHubは自分たちの受付を新しいやり方に変えたとき、番号を書いたり読んだりするためのデータベース操作が、まるごとなくなったと発表してる。
もう誰も台帳を見ないから、台帳そのものがいらなくなったんだね。
あなたに関係あるのは3つだけ。残りは名前だけ知っておけばOK

今回の変更、数えると10個以上ある。
でも道具を「使う側」に効いてくるのは、この3つだと思う。
これまでAIは、道具のリストを毎回聞き直してた。
「あなたのお店、何ができますか?」「カレーと定食とうどんです」を注文のたびに繰り返してたんだよね。
今回、返事にttlMs(=メニュー表の賞味期限。何分取っておいていいか)とcacheScope(=他の人と使い回していいかの印)がつくようになった。
同じことを聞き直す往復が消えるから、待ち時間もAIの利用料も少し軽くなる方向だよ。
AIに作業を任せてると、途中で確認してほしい場面があるよね。「このメール、本当に送っていい?」みたいなところ。
これまでは、確認のあいだ電話をつなぎっぱなしにしておく必要があった。
今回入った MRTR(Multi Round-Trip Requests) は、いったん切って、返事が来たら続きから再開できる仕組み。
私はAIに任せる範囲を広げてるところだから、この変更はいちばんうれしかったな。
いくつかの古いやり方が非推奨(=そろそろやめようね)の扱いになった。名前を出すと Roots / Sampling / Logging、それと古い接続方式(HTTP+SSE)。
ただしいきなり切られるんじゃなくて、最低12ヶ月の猶予つき。今回から「引退させるなら12ヶ月前に予告する」が公式ルールになったんだ。
しかもこれ、道具を作った人が直す話。使うだけの私たちは、提供元が直してくれるのを待てばいい。
ほかにもいくつか変わってる。
使う側が手を動かす話じゃないから、ひとことの意味だけにしておくね。
ここが会社の情報システム部門が喜ぶところ。
大事なんだけど、あなたが今日手を動かす話じゃないから、名前だけで十分だよ。
ビフォー・アフター:同じことを頼んだのに、ここが変わる

ここまでの話を、実際の場面で前と後に並べてみるね。
むずかしい言葉は出てこないよ。
場面① 「この資料、探して」と1つ頼む
BEFORE
「これから話しかけます」と挨拶する → 番号札をもらう → やっと用件を言う。
3往復してから、ようやく探しはじめる。
AFTER
券1枚に用件まで全部書いてあるので、1回目からいきなり探しはじめる。
場面② 同じ時間に、使う人がどっと増えた
BEFORE
番号札を知っているのは、それを渡した1台だけ。別の台に届いた瞬間「そんな番号は知りません」で止まる。
だから同じ人は必ず同じ台へという交通整理と、番号の台帳を置く場所が要った。
AFTER
どの台に出しても通るので、混んだら台を増やすだけ。台帳もいらない。
GitHubは実際に、番号を書いたり読んだりするデータベース操作をまるごとなくしたと発表してる。
場面③ 途中で「これ送っていい?」と確認したい
BEFORE
あなたの返事を待っているあいだ、電話をつなぎっぱなしにしておく必要があった。
AFTER
いったん切って、返事が来たら続きから。待たせっぱなしにしなくていい。
場面④ 受付を作る人の手間
使うだけの人は読み飛ばしてOK。
BEFORE
番号の台帳を置く場所、同じ台へ振り分ける設定、切れた通信を途中から復旧する仕掛け。この3つを用意しないと成立しなかった。
AFTER
3つとも、いらない。切れたら同じお願いをもう1回出すだけ。
そのかわり「何の用事か」を封筒の表に書く手間が増えた。差し引きでうんと軽い。
待ち時間が少し軽くなって、混んでいる時間帯に止まりにくくなる。
派手な変化じゃないけど、毎日AIに何か頼んでいる人には、ここがいちばん効くよ。
なぜ今、こうなったのか

私はこの業界に30年いるんだけど、こういう「土台の作り替え」が起きるときって、理由はだいたい同じなんだ。
使われる場所が変わったからだよ。
MCPは最初、自分のパソコンの隣で動く道具だった。
1人が使うだけなら、番号札方式でも何も困らない。担当が休むこともないしね。
でも今は、会社が仕事に使いはじめてる。
そうなると話が変わる。同じ時間に何百人が使う。止まったら困る。誰が何に触ったか記録がほしい。情報システム部門は入口に門番を置きたがる。
家の台所から、フードコートに引っ越したということ。
家の台所なら、器具の置き場所は自分だけが分かってればいい。
でもフードコートは、店員が入れ替わっても、行列が伸びても回らないといけない。
だから作法そのものを作り替えた。壁紙を替えたんじゃなくて、基礎を打ち直した工事だね。
ローンチ以来いちばん大きい変更と言われてるのは、機能が派手だからじゃない。
いちばん最初の前提(番号札があること)をひっくり返したからなんだ。
私が自分のパソコンを点検したら、直すところは0だった

ここまで読んで、いちばん気になるのはこれだよね。
「で、私が使ってるやつは壊れるの?」
調べたら分かることを推測で答えたくなかったから、自分のパソコンを全部ひらいて数えてみた。
AIに道具をつないでる箇所は、全部で11か所。うち1か所は前から止めてあるので、生きているのは10か所だった。
結果は直すところゼロ。
拍子抜けしたけど、理由がおもしろかったんだ。
今回のルール変更は「電話で注文するときの作法」(Streamable HTTP)の話だった。
ところが生きている10か所のうち7か所は「同じ部屋にいる相手に、直接声をかける」やり方(stdio)だったんだよね。
番号札を廃止しますと言われても、そもそも電話してない。だから無関係。
電話しているのは残りの3か所だけ。でもその3つは全部、よその会社のお店にかけてるんだ。
お店の作法が変わったなら、それはお店側の工事。私はお客さんだから待ってればいい。しかも土台の部品(SDK)が古いやり方も受け付けてくれる。
そして決め手がこれ。
私が自分で作った受付(MCPサーバー)は、1つもなかった。
「作った覚えはないけど、昔なにか作ったかも」と思って探したんだけど、見つかったのは全部むかしのバックアップの中だった。今動いてるものは1つもない。
つまり直す対象がそもそも存在しない。これが「ゼロ」のいちばん大きな理由だね。
むずかしいことはしなくていいよ。この2つに「いいえ」なら、今日は何もしなくて大丈夫。
① AIとつなぐ受付(MCPサーバー)を、自分で、または誰かに頼んで作ったことがある?
→ ないなら、ほぼ関係なし。使うだけの人は、提供元が直してくれるのを待てばいい
② 手が止まって困ってる連携が、今ある?
→ あるなら、それは今回の変更とは別の原因かもしれない。ついでに見ておくと得だよ(私はこれで拾った。次の話につながる)
じつはこの点検のついでに、まったく関係ないゴミが3つ見つかったんだ。
だいぶ前に打ち間違えた住所(フォルダの場所)に、設定がぶら下がったまま残ってた。
しかもそこに、ブラウザを動かすための道具が2つ入ってた。つまり入れたつもりで、ずっと使えてなかったってこと。
「なんか動かないな」と何度か思った記憶が、ここでやっとつながったよ。
これ、点検しなきゃ一生気づかなかったやつだよね。
「悪いことこそ宝物」って私はよく言うんだけど、こういう小さいのが本当にそれ。
他人のニュースが、うちの埋もれた不具合を掘り出してくれた。
よくある質問
- Q. 「ステートレス」って、結局どういう意味ですか?
- A. 「相手が自分を覚えてなくても困らない形」という意味だよ。1回のやりとりに必要なことを全部書いておくから、受け取る人が誰でも成立する。フードコートの食券を思い浮かべると早いかな。反対に、これまでのように番号札で本人確認していた状態が「ステートフル」だよ。
- Q. 「セッション廃止」で、具体的に何がなくなったの?
- A. 2つだよ。①最初の挨拶(initialize)②毎回そえていた番号札(Mcp-Session-Id)。この2つがまるごと消えて、1回目からいきなり用件を言えるようになった。
- Q. 私が今使っているAIツールは壊れますか?
- A. 壊れないよ。土台の部品(SDK)はTypeScript・Python・Go・C#が新しい版に対応済みで、Rustはベータ版。どれも古いやり方のままでも動くように作られてるから、今のままで使い続けられる。古いやり方の引退にも最低12ヶ月の猶予があるしね。
- Q. 番号札がなくなると、会話の続きができなくなりませんか?
- A. できるよ。券を持つ人が「お店」から「お客さん」に変わっただけ。お店が渡した札をAI側が持ち歩いて、次のお願いのときに一緒に出す。だから店員が誰でも続きが分かるんだ。
- Q. 今日、何かしたほうがいい?
- A. たぶん何もしなくていいよ。私も自分のパソコンを11か所ぜんぶ点検して0件だった。むしろおすすめは、ついでに「前から動かなくて放置してる連携」を1つ見に行くこと。そっちで宝物が出ることがある。
今日のまとめ

MCPの7月28日版は、予約席のレストランをフードコートに作り替えたアップデートだった。
最初の挨拶(initialize)と番号札(Mcp-Session-Id)をやめて、券に全部書く。これが「セッション廃止」と「ステートレス化」。
それだけで、混んでもカウンターを増やすだけで回るようになる。
そして使う側の私たちは、今日あわてて何かする話じゃない。
私も自分のパソコンを11か所ぜんぶ点検して0件だったし、古いやり方の引退にも最低12ヶ月の猶予がある。
でもね。ニュースを読んで「ふーん」で終わらせるのと、5分だけ自分の足元を見るのとでは、残るものが全然ちがう。
私は点検したおかげで、ずっと使えてなかった連携を3つ拾えた。
ニュースは他人の話。でも点検は、自分の話になるんだよね。
一緒に、足元から整えていこう。
COLUMN
「たぶん大丈夫」で止めなかった10分が、いちばん得だった

点検を始める前の私は「たぶん大丈夫だろう」と思ってた。
自分で受付を作った記憶はないし、壊れたら気づくだろう、と。
でも、その「たぶん」で止めなかったのが良かった。
実際にひらいてみたら、打ち間違えた住所に設定が3つぶら下がってた。しかもブラウザを動かす道具が2つ、そこに入ってた。
入れたつもりで、ずっと使えてなかったってこと。「なんか動かないな」と思ってた記憶が、ここでつながったよ。
AIに仕事を任せるようになってから、この「確かめる10分」の価値がすごく上がったと感じてる。
任せる量が増えるほど、自分が見てない配線が増えるからね。分身AI.comでも「信じるな、確かめろ」をAIの引き継ぎルールにした話を書いたんだけど、疑うんじゃなくて確かめる工程を仕組みに埋めるという考え方だよ。
もうひとつ気をつけてるのは、点検が目的にすり替わらないこと。
自動化を増やすほど時間が消えていく逆説について90日ぶん監査した話も書いたけど、点検も自動化も、増やすほど良いってものじゃない。
今回みたいに「やらなくていい」と分かるための点検が、いちばん得なんだよね。何もしない、という判断を根拠つきで持てるから。
抱え込みOSで全部を自分で確かめようとすると潰れる。
委ねるOSに切り替えて、確かめる場所だけ自分で決める。
今日の10分は、その練習にちょうどよかったな。
👉 分身AIについてもっと知りたい方は分身AI.comもチェックしてね!
あわせて読みたい関連記事
この変更が発表された当日のニュースまとめ。他のAIニュースとあわせて流れをつかみたい人はこちらから。
道具をつなぐ前に決めておきたい「任せる順番」の話。配線より先に順番だよ、という記事。
同じ週のAIニュース。AIそのものの動きもあわせて追いたい人向け。
参考リンク
🎁 無料プレゼント
Aiport(ClaudeCode AIエージェント実践会)
ClaudeCodeでAI秘書+分身AI+AIカンパニーが無料で作れるキット&解説動画をプレゼント!
🤖 AI生成コンテンツについて
この記事はAIツール(Claude Code)を活用して制作しています。構成・文章生成・画像制作にAIを使用し、最終的な内容の確認・編集・公開判断はひろくん(田中啓之)本人が行っています。「分身AIひろくん」(bunshin-ai.com)とは別のコンテンツです。