AIツール活用

MCPステートレス化とは?セッション廃止をやさしく解説

2026年7月30日

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん(@passion_tanaka)です。

7月28日、AIのニュースで「MCPがステートレス化」「セッション廃止」という見出しが流れたよ。

正直、この言葉だけ見せられても何も浮かばないよね。
私も最初に見たときは頭が真っ白だった。

ざっくり言うと、AIが道具を使うときの手続きが1つ減った——ただそれだけの話。
でね、お店の注文にたとえながら、順番に見ていくね。

3行でわかるポイント

  • 変わったのはAIの賢さじゃない。AIと道具の「つなぎ方の作法」が変わった
  • 予約席のレストランが、フードコートになった。「いつもの席で」が通じる代わりに担当がいないと詰む店から、券を出せば誰でも作ってくれる店へ。この券に全部書いてある状態がステートレスで、番号札をやめたのがセッション廃止
  • あなたが今日やることは、たぶんゼロ。私も自分のパソコンを11か所ぜんぶ点検したけど、直すところは1つもなかった

今日の最新LIVEや最新情報はGPTs研究会Facebookグループにも投稿してるから、そっちもチェックしてね。

01

そもそもMCPって、何のこと?

AIに道具をつなぐ差し込み口の形をそろえる図解。AIの頭からカレンダー・書類・地球儀へ同じ形のコードがつながっている

MCPは「Model Context Protocol(モデル・コンテキスト・プロトコル)」の略——名前は長いけど中身は単純。
ざっくり言うとAIに道具を持たせるための、差し込み口の規格だよ。

AIって、そのままだと頭だけの存在なんだよね。
賢いことは言えるけど、あなたのカレンダーは見られないし、資料も開けない。手がないから。

そこに「カレンダーを見る手」「資料を読む手」をくっつけるための決まりごとが、MCP。
だから「AI界のUSB-C」なんて呼ばれてる。

🍳 料理で言うと

AIは腕のいい料理人。MCPは厨房のコンセントの形だよ。

ミキサーもオーブンも差し込み口の形がバラバラだったら、道具を1つ増やすたびに配線をやり直すことになる。
形をそろえておけば、道具を足すのも入れ替えるのも一瞬で済むよね。
その「形をそろえる約束」が、MCP。

で、今回のニュースはコンセントの形(作法)が変わったという話。
料理人の腕の話じゃないんだ。ここを押さえておくと、あとが全部つながるよ。

02

「セッション廃止」で何が変わった?予約席からフードコートへ

予約席の常連レストランからフードコートの食券制へ変わったことを示す図解。左は困る店員、右は券を差し出す手

ひとつ前の決まりごと(2025年11月25日版)には、ちょっと変わったルールがあった。

AIが道具を使いたいとき、いきなり用件を言えなかったんだ。
まず「これから話しかけます」と挨拶して(これを initialize と呼ぶ)、相手から番号札をもらう。この番号札が Mcp-Session-Id。そのあと用件を言うたびに、毎回この番号札をそえる決まりだった。

この一連の仕組みがセッション
そして今回、挨拶も番号札も、まるごと廃止された。これが「セッション廃止」だよ。

🍳 料理で言うと

これまで=予約席のある常連レストラン。
「あ、いつものひろくんね。奥の席どうぞ」で通じるのは気持ちいい。
でも困るのは、担当の人が休んだ日。
「私の席、わかりますよね?」「……どなたでしたっけ」で止まっちゃう。
お客さんが増えたから席を増やそう、としても、誰がどの席かを全員が把握してないと成立しない。

これから=フードコートの食券制。
券に「カレー・大盛り・注文したのは私」まで全部書いてある。
だからどのカウンターに出しても作ってもらえる。担当が休みでも関係ない。
行列ができたら、カウンターをもう1つ開けるだけ。

この「券に全部書いてある状態」をステートレス(stateless)と言うんだ。

💡 やさしく解説:ステートレス

そのまま訳すと「状態を持たない」。
でも実際の意味は「相手が覚えていなくても困らないようにした」が正解だよ。

相手が自分のことを覚えてなくても、券に全部書いてあるから成立する。
毎回はじめて会う人として扱われても、ちゃんと注文が通る。それだけの話だね。

ニュースに出てくる言葉の早見表

他のニュースを読むときは、この言葉が並んでるはず。
意味だけ押さえておけば、どこで見ても迷わないよ。

ニュースでの表記 言いかえると 正体
セッション
session
番号札のやりとり最初に挨拶して番号をもらい、以降その番号で「私です」と示し続ける仕組み。今回まるごと廃止
initialize
notifications/initialized
最初の挨拶「これから話しかけます」の手続き。廃止。今は1回目からいきなり用件を言える
Mcp-Session-Id番号札そのもの用件を言うたびに毎回そえていた番号。廃止
ステートレス
stateless
券に全部書いてある状態相手が覚えていなくても、1回のやりとりで成立する形。今回これになった
Streamable HTTP電話で注文する方式ネット越しに外のサーバーへつなぐやり方。今回の変更の当事者はここだけ
stdio
標準入出力
同じ部屋で直接声をかける方式自分のパソコンの中でプログラムを起動して直接やりとりする。番号札を使ってないので今回は無関係
SDK土台の部品プログラミング言語ごとに用意された公式の部品。ここが古いやり方も受け付けてくれるから、既存の環境が壊れない
非推奨
deprecated
そろそろ引退すぐ使えなくなるわけじゃない。最低12ヶ月の猶予が公式ルールとして決まった
03

ステートレス化を、お店のやりとりで見てみる

3往復かかっていた手続きが1回で済むようになったことを示す図解。遠回りの線とまっすぐな線の対比

AIがあなたの資料を1つ探す、という場面で見てみるね。

前の版までの店

AI「すみません、これから注文したいんですけど」
「はい、ではあなたは7番です。この番号を覚えておいてください」
AI「7番です。資料を1つ探してください」
「7番さんですね、承知しました」

──ここで、店が混んできて2つ目のカウンターが開く。

AI「7番です。もう1つ探してください」
店(2つ目のカウンター)「……7番? そんな番号、うちは知りませんが」

この「番号を知っているのは1つのカウンターだけ」という制約が、今回なくなった点。出典: GIGAZINE「共通規格『MCP』が過去最大のアップデート、セッション廃止で何が変わったのか?」
🔍 このとき実際に飛んでいた通信(前の版・2025年11月25日版)

POST /mcp
  method: initialize
         ↑ ① これが「最初の挨拶」

(返事)Mcp-Session-Id: 7番…
         ↑ ② これが「番号札」7番

POST /mcp
  Mcp-Session-Id: 7番…
         ↑ ③ 毎回この番号札をそえる
  method: tools/call name: search_docs
         ↑ ④ やっと用件(資料を探して)

3往復目でやっと用件が言えてるのが分かるかな。
そして②の番号を発行したのは1台だけ。だからお店側は「同じお客さんは必ず同じカウンターへ」と交通整理をして、さらに番号の台帳をしまう倉庫を別に用意して全カウンターで共有してた。手間だよね。

7月28日からの店

AI「この券です。“資料を1つ探す・頼んだのは私・今の決まりごとの版は7月28日版”。全部書いてあります」
店(どのカウンターでも)「はい、承知しました」

──混んできて3つ目のカウンターが開いても、

AI「この券です」
店(3つ目のカウンター)「はい、承知しました」

挨拶と番号札をやめて、1回のやりとりに必要な情報を全部入れる形になった。出典: gihyo.jp「MCP仕様『2026-07-28』を公開」
🔍 このとき実際に飛んでいる通信(2026年7月28日版)

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は自分たちの受付を新しいやり方に変えたとき、番号を書いたり読んだりするためのデータベース操作が、まるごとなくなったと発表してる。
もう誰も台帳を見ないから、台帳そのものがいらなくなったんだね。

04

あなたに関係あるのは3つだけ。残りは名前だけ知っておけばOK

使う側に効いてくる3つの変化の図解。待ち時間・途中の確認・12ヶ月の移行期間

今回の変更、数えると10個以上ある。
でも道具を「使う側」に効いてくるのは、この3つだと思う。

① 待ち時間が、ちょっと軽くなる(ttlMs / cacheScope)

これまでAIは、道具のリストを毎回聞き直してた。
「あなたのお店、何ができますか?」「カレーと定食とうどんです」を注文のたびに繰り返してたんだよね。

今回、返事にttlMs(=メニュー表の賞味期限。何分取っておいていいか)とcacheScope(=他の人と使い回していいかの印)がつくようになった。
同じことを聞き直す往復が消えるから、待ち時間もAIの利用料も少し軽くなる方向だよ。

② 「これやっていい?」と聞く場面が作りやすくなった(MRTR)

AIに作業を任せてると、途中で確認してほしい場面があるよね。「このメール、本当に送っていい?」みたいなところ。

これまでは、確認のあいだ電話をつなぎっぱなしにしておく必要があった。
今回入った MRTR(Multi Round-Trip Requests) は、いったん切って、返事が来たら続きから再開できる仕組み。
私はAIに任せる範囲を広げてるところだから、この変更はいちばんうれしかったな。

③ 古いやり方は、1年かけて引退する(非推奨)

いくつかの古いやり方が非推奨(=そろそろやめようね)の扱いになった。名前を出すと Roots / Sampling / Logging、それと古い接続方式(HTTP+SSE)

ただしいきなり切られるんじゃなくて、最低12ヶ月の猶予つき。今回から「引退させるなら12ヶ月前に予告する」が公式ルールになったんだ。
しかもこれ、道具を作った人が直す話。使うだけの私たちは、提供元が直してくれるのを待てばいい。

ほかにもいくつか変わってる。
使う側が手を動かす話じゃないから、ひとことの意味だけにしておくね。

ニュースでの表記 ひとことで言うと
Mcp-Method / Mcp-Name
(必須になった項目)
封筒の表に「何の用事か」を書く欄。Mcp-Method は毎回必須Mcp-Name は道具を呼ぶときなど一部だけ必須。中を開けずに用件が分かるから、会社の入口の門番(ゲートウェイやWAF)が振り分け・遮断できる
server/discover「お店で何ができますか?」と聞く窓口。お店側は必ず用意する義務があるけど、聞くかどうかはAI側の自由。挨拶が廃止されたぶんの受け皿だね
Tasks が公式拡張へ
io.modelcontextprotocol/tasks
時間のかかる作業の扱いが、実験席から「正式な別メニュー表」に昇格した
MCP Apps / EMA画面つきのやりとり、会社が権限をまとめて管理する仕組み。どちらも別メニュー表として正式化
subscriptions/listen「道具の一覧が変わったよ」といったお知らせの受け取り口が、1本にまとまった。欲しい種類だけ選んで受け取る形
ping / logging/setLevel の削除生存確認と、記録の細かさ設定の命令がなくなった。記録の細かさは1回ごとのお願いの中で指定する形に
認可の強化
OAuth 2.0 / OpenID Connect / CIMD
「誰にどこまで触らせるか」の鍵の管理が厳しくなった。会社が管理できる形に寄せてきてる

ここが会社の情報システム部門が喜ぶところ。
大事なんだけど、あなたが今日手を動かす話じゃないから、名前だけで十分だよ。

05

ビフォー・アフター:同じことを頼んだのに、ここが変わる

同じことを頼んだときの前と後を見比べた図解。左は受付と3回やりとりして台を増やせない、右は券1枚で1回で通り台を増やせる

ここまでの話を、実際の場面で前と後に並べてみるね。
むずかしい言葉は出てこないよ。

場面① 「この資料、探して」と1つ頼む

BEFORE

「これから話しかけます」と挨拶する → 番号札をもらう → やっと用件を言う。
3往復してから、ようやく探しはじめる。

AFTER

券1枚に用件まで全部書いてあるので、1回目からいきなり探しはじめる。

場面② 同じ時間に、使う人がどっと増えた

BEFORE

番号札を知っているのは、それを渡した1台だけ。別の台に届いた瞬間「そんな番号は知りません」で止まる。
だから同じ人は必ず同じ台へという交通整理と、番号の台帳を置く場所が要った。

AFTER

どの台に出しても通るので、混んだら台を増やすだけ。台帳もいらない。
GitHubは実際に、番号を書いたり読んだりするデータベース操作をまるごとなくしたと発表してる。

場面③ 途中で「これ送っていい?」と確認したい

BEFORE

あなたの返事を待っているあいだ、電話をつなぎっぱなしにしておく必要があった。

AFTER

いったん切って、返事が来たら続きから。待たせっぱなしにしなくていい。

場面④ 受付を作る人の手間

使うだけの人は読み飛ばしてOK。

BEFORE

番号の台帳を置く場所、同じ台へ振り分ける設定、切れた通信を途中から復旧する仕掛け。この3つを用意しないと成立しなかった。

AFTER

3つとも、いらない。切れたら同じお願いをもう1回出すだけ。
そのかわり「何の用事か」を封筒の表に書く手間が増えた。差し引きでうんと軽い。

💡 あなたの体感でいうと

待ち時間が少し軽くなって、混んでいる時間帯に止まりにくくなる。
派手な変化じゃないけど、毎日AIに何か頼んでいる人には、ここがいちばん効くよ。

06

なぜ今、こうなったのか

家の台所から大きなフードコートへ引っ越したことを示す図解。門番も描かれている

私はこの業界に30年いるんだけど、こういう「土台の作り替え」が起きるときって、理由はだいたい同じなんだ。
使われる場所が変わったからだよ。

MCPは最初、自分のパソコンの隣で動く道具だった。
1人が使うだけなら、番号札方式でも何も困らない。担当が休むこともないしね。

でも今は、会社が仕事に使いはじめてる。
そうなると話が変わる。同じ時間に何百人が使う。止まったら困る。誰が何に触ったか記録がほしい。情報システム部門は入口に門番を置きたがる。

🍳 料理で言うと

家の台所から、フードコートに引っ越したということ。

家の台所なら、器具の置き場所は自分だけが分かってればいい。
でもフードコートは、店員が入れ替わっても、行列が伸びても回らないといけない。
だから作法そのものを作り替えた。壁紙を替えたんじゃなくて、基礎を打ち直した工事だね。

ローンチ以来いちばん大きい変更と言われてるのは、機能が派手だからじゃない。
いちばん最初の前提(番号札があること)をひっくり返したからなんだ。

07

私が自分のパソコンを点検したら、直すところは0だった

自分のパソコン11か所を点検して直すところが0だったことを示す図解。ひろくんが虫めがねでのぞきこんでいる

ここまで読んで、いちばん気になるのはこれだよね。
「で、私が使ってるやつは壊れるの?」

調べたら分かることを推測で答えたくなかったから、自分のパソコンを全部ひらいて数えてみた
AIに道具をつないでる箇所は、全部で11か所。うち1か所は前から止めてあるので、生きているのは10か所だった。

結果は直すところゼロ
拍子抜けしたけど、理由がおもしろかったんだ。

🍳 料理で言うと

今回のルール変更は「電話で注文するときの作法」(Streamable HTTP)の話だった。

ところが生きている10か所のうち7か所は「同じ部屋にいる相手に、直接声をかける」やり方(stdio)だったんだよね。
番号札を廃止しますと言われても、そもそも電話してない。だから無関係。

電話しているのは残りの3か所だけ。でもその3つは全部、よその会社のお店にかけてるんだ。
お店の作法が変わったなら、それはお店側の工事。私はお客さんだから待ってればいい。しかも土台の部品(SDK)が古いやり方も受け付けてくれる。

そして決め手がこれ。
私が自分で作った受付(MCPサーバー)は、1つもなかった

「作った覚えはないけど、昔なにか作ったかも」と思って探したんだけど、見つかったのは全部むかしのバックアップの中だった。今動いてるものは1つもない。
つまり直す対象がそもそも存在しない。これが「ゼロ」のいちばん大きな理由だね。

💡 あなたが5分でできる、自己点検2つ

むずかしいことはしなくていいよ。この2つに「いいえ」なら、今日は何もしなくて大丈夫。

AIとつなぐ受付(MCPサーバー)を、自分で、または誰かに頼んで作ったことがある?
→ ないなら、ほぼ関係なし。使うだけの人は、提供元が直してくれるのを待てばいい

手が止まって困ってる連携が、今ある?
→ あるなら、それは今回の変更とは別の原因かもしれない。ついでに見ておくと得だよ(私はこれで拾った。次の話につながる)

じつはこの点検のついでに、まったく関係ないゴミが3つ見つかったんだ。

だいぶ前に打ち間違えた住所(フォルダの場所)に、設定がぶら下がったまま残ってた。
しかもそこに、ブラウザを動かすための道具が2つ入ってた。つまり入れたつもりで、ずっと使えてなかったってこと。
「なんか動かないな」と何度か思った記憶が、ここでやっとつながったよ。

これ、点検しなきゃ一生気づかなかったやつだよね。
「悪いことこそ宝物」って私はよく言うんだけど、こういう小さいのが本当にそれ。
他人のニュースが、うちの埋もれた不具合を掘り出してくれた。

FAQ

よくある質問

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つ見に行くこと。そっちで宝物が出ることがある。
MATOME

今日のまとめ

今日は何もしなくていいが5分だけ足元を見ると残るものが違う、というまとめの図解

MCPの7月28日版は、予約席のレストランをフードコートに作り替えたアップデートだった。
最初の挨拶(initialize)と番号札(Mcp-Session-Id)をやめて、券に全部書く。これが「セッション廃止」と「ステートレス化」。
それだけで、混んでもカウンターを増やすだけで回るようになる。

そして使う側の私たちは、今日あわてて何かする話じゃない
私も自分のパソコンを11か所ぜんぶ点検して0件だったし、古いやり方の引退にも最低12ヶ月の猶予がある。

でもね。ニュースを読んで「ふーん」で終わらせるのと、5分だけ自分の足元を見るのとでは、残るものが全然ちがう
私は点検したおかげで、ずっと使えてなかった連携を3つ拾えた。
ニュースは他人の話。でも点検は、自分の話になるんだよね。

一緒に、足元から整えていこう。

COLUMN

「たぶん大丈夫」で止めなかった10分が、いちばん得だった

引き出しを開けたら使えていなかった道具が3つ出てきた場面の図解。ひろくんが驚いている

点検を始める前の私は「たぶん大丈夫だろう」と思ってた。
自分で受付を作った記憶はないし、壊れたら気づくだろう、と。

でも、その「たぶん」で止めなかったのが良かった。
実際にひらいてみたら、打ち間違えた住所に設定が3つぶら下がってた。しかもブラウザを動かす道具が2つ、そこに入ってた。
入れたつもりで、ずっと使えてなかったってこと。「なんか動かないな」と思ってた記憶が、ここでつながったよ。

AIに仕事を任せるようになってから、この「確かめる10分」の価値がすごく上がったと感じてる。
任せる量が増えるほど、自分が見てない配線が増えるからね。分身AI.comでも「信じるな、確かめろ」をAIの引き継ぎルールにした話を書いたんだけど、疑うんじゃなくて確かめる工程を仕組みに埋めるという考え方だよ。

もうひとつ気をつけてるのは、点検が目的にすり替わらないこと。
自動化を増やすほど時間が消えていく逆説について90日ぶん監査した話も書いたけど、点検も自動化も、増やすほど良いってものじゃない。
今回みたいに「やらなくていい」と分かるための点検が、いちばん得なんだよね。何もしない、という判断を根拠つきで持てるから。

抱え込みOSで全部を自分で確かめようとすると潰れる。
委ねるOSに切り替えて、確かめる場所だけ自分で決める
今日の10分は、その練習にちょうどよかったな。

👉 分身AIについてもっと知りたい方は分身AI.comもチェックしてね!

関連

🎁 無料プレゼント

Aiport(ClaudeCode AIエージェント実践会)

ClaudeCodeでAI秘書+分身AI+AIカンパニー無料で作れるキット&解説動画をプレゼント!

▶ 無料で入会してキットを受け取る

🤖 AI生成コンテンツについて

この記事はAIツール(Claude Code)を活用して制作しています。構成・文章生成・画像制作にAIを使用し、最終的な内容の確認・編集・公開判断はひろくん(田中啓之)本人が行っています。「分身AIひろくん」(bunshin-ai.com)とは別のコンテンツです。

関連記事