「去年、社内の在庫データをAIから見られるように連携を組んでもらいました。あれ、規格が変わったら作り直しになるんでしょうか」——AI 活用に一歩踏み出した会社ほど、こういう不安を抱えることになります。動いているものが、自分たちの知らないところで決まった仕様変更によって止まるかもしれない。しかも中身は分からない。
2026年7月28日、AI と外部システムをつなぐ共通規格 MCP（Model Context Protocol） の新しい仕様が確定しました。変更の中心は「ステートレス化」と呼ばれる設計の転換で、規格としてはかなり大きな刷新です。技術の詳細を追う必要はありませんが、発注した側として何を確認すべきかは押さえておく価値があります。
MCPのステートレス化を、たとえ話で言うと
これまでの MCP は、AI 側とシステム側が「今つないでいる状態」を互いに覚えている前提で動いていました。電話に近い仕組みです。まず接続の挨拶を交わし、通話中であることを示す番号（セッション ID）を共有し、そのやり取りが続く間ずっと回線をつないでおく。
今回の仕様では、この「通話」をやめました。一回ごとに完結する、手紙のようなやり取りに変わります。挨拶も、通話中の番号管理も要りません。あわせて、問い合わせ結果を一定時間手元に置いて使い回せる仕組みや、認可（誰が何にアクセスしてよいか）の扱いの強化、正式な拡張の枠組みなども入りました（Model Context Protocol Blog: The 2026-07-28 Specification）。
なぜこうしたのかというと、運用のしやすさが主な理由です。通話をつなぎっぱなしにする方式では、サーバーを複数台に増やして負荷を分散させようとしたときに「この通話はどのサーバーが覚えているのか」を管理する手間が生じます。一回完結型にすれば、どのサーバーが受けても構わなくなる。利用が増えたときに素直に増やせる形になった、というのが実務上の意味です。
| 観点 | これまでの MCP | 2026-07-28 仕様 |
|---|---|---|
| つなぎ方 | 接続の挨拶とセッション管理が必要 | 一回ごとに完結 |
| サーバーの増やし方 | どのサーバーが状態を持つかの管理が要る | どの台が受けても同じ |
| 主に効く場面 | 小規模・単一サーバーの構成 | 利用が増えて負荷分散が要る構成 |
既存のMCP連携が「明日から壊れる」わけではない
不安の核心に答えます。仕様が確定したからといって、既存の連携が翌日に一斉停止するわけではありません。MCP の仕様はバージョンが日付で管理されていて、古いバージョンで作られた連携は、対応する実装が動き続ける限り引き続き機能します。GitHub の MCP サーバーのように、新仕様への対応を早々に表明したものもありますが、これは「対応した」のであって「古いものを切った」とは別の話です（Publickey）。
とはいえ、「当面動く」と「放っておいてよい」は違います。規格が更新されると、周辺のライブラリや SDK、接続先のサービス側が徐々に新仕様へ寄っていきます。半年後・1年後に「接続先が新仕様しか受け付けなくなった」という形で影響が届くのが、この種の変更の典型的な現れ方です。慌てる必要はないが、予定には入れておく——それが正しい距離感だと考えています。
MCP そのものの仕組みを一度整理しておきたい場合は、MCP完全ガイドから読むと以降の話がつながります。
保守ベンダーに投げる3つの質問
技術の中身が分からなくても、確認すべきことは3つに絞れます。次回の定例やメールで、そのまま聞いてしまうのが早いはずです。
- いま動いている連携は、MCP のどのバージョンの仕様で作られていますか。 これが分からないと、影響があるかどうかの判断も立ちません。答えられない場合は、まずそこを調べてもらうことが最初の作業になります。
- 新仕様に対応するとしたら、どのくらいの規模の作業になりますか。 使っている SDK を上げるだけで済むのか、設計から見直しが要るのか。金額を出してもらう前に、規模感だけでも把握しておくと予算計画が立てられます。
- 接続先のサービス側が新仕様に移行した場合、こちらはいつまでに動く必要がありますか。 自社の都合だけでなく、つないでいる相手の都合で期限が決まる可能性があります。この期限を握っているかどうかが、慌てるかどうかの分かれ目です。
3つとも、技術的な正解を問う質問ではありません。「把握できているか」を確認する質問です。即答できる相手なら安心してよく、調べる時間をくださいと言われるなら、それはそれで健全な反応です。答えが曖昧なまま流れるようなら、そこが保守体制の弱いところだと分かります。
新しく作るなら、確認する順番を変える
これから社内システムと AI をつなぐ開発を発注するのであれば、要件を詰める前に「どのバージョンの仕様で作るか」を明示的に決めておくべきです。当たり前に聞こえますが、実際には言及されないまま進むことが多い項目でもあります。
既存の社内APIをAIから使える形にする設計そのものについては既存APIをMCPサーバー化する設計パターンで整理しています。あわせて確認したいのが、認可の設計です。今回の仕様では認可まわりが強化されています。社内データを AI から参照できるようにするということは、「誰が」「どのデータまで」触れてよいかを決めるということでもある。ここを曖昧にしたまま接続を優先すると、後から権限を締め直す作業が発生します。社内システムへの AI アクセスをどう統制するかはエンタープライズでの MCP 認可管理で詳しく扱っています。
そしてもう一つ、この手の規格はこれからも更新されます。今回が最後ではありません。だからこそ、個別の仕様変更に一喜一憂するより、「規格が変わったときに誰がどう判断するのか」を保守契約の中に位置づけておくほうが効きます。仕様が変わるたびに毎回ゼロから相談するのでは、判断も対応も遅れます。
まず「どのバージョンか」から
今日やるべきことは一つです。AI と社内システムをつないでもらっている先に、「いまの連携は MCP のどのバージョン仕様ですか」と一行のメールを送る。それだけで、慌てる必要があるのかないのかが分かります。多くの場合、答えは「当面問題ありません」でしょう。その一言をもらうために動くのが、いちばん安く済む備えです。
社内システムと AI の連携をこれから設計したい、既存の連携が今の仕様に照らして妥当か第三者に見てほしい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談窓口で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- The 2026-07-28 Specification — Model Context Protocol Blog
- The 2026-07-28 MCP Specification Release Candidate — Model Context Protocol Blog
- MCP仕様が明日アップデート、7月28日版MCPからはステートレスな接続が正式仕様に — Publickey
- MCP 2026-07-28 RC解説：ステートレス化がもたらすAIエージェント実装 — 豆蔵デベロッパーサイト
- 2026-07-28 MCP 仕様ではステートレスファーストになる — azukiazusa.dev
