MCPの​新仕様​（2026-07-28版）とは​何か​ ──AIと​社内システムの​つなぎ方が​変わった​点を​解説

2026年7月28日、MCP（Model Context Protocol）の新しい仕様が公開されました。MCPは、AIが社内のツールやSaaSを操作するための共通規格です。AIが「メールを読む」「顧客データを引く」「ファイルを書き出す」といった動きをするときの、AIと外部システムをつなぐ差込口にあたります。

主要な変更が9件、細かい変更が12件、非推奨（将来なくなる）になった機能が4件^[1]。なかでも大きいのは、2024年11月の初版から一貫して存在した「接続時の挨拶」が、まるごと廃止されたことです^[5]。MCPの仕様はこれで5つ目の版になります。

結論から書きます。いま動いている連携が、いきなり止まることはありません。 新旧の仕様は併存できるよう設計されていて、仕様書のなかで公式に「Modern（新）」「Legacy（旧）」「Dual-era（両対応）」という言葉まで定義されています^[2]。

ただし、AIとシステムの連携をこれから発注する会社にも、すでに動かしている会社にも、宿題が2つ出ました。①これから作る連携は新しい方式で作るべき（設計思想が根本から変わったため）、②いま使っている機能のうち3つは、最低12か月の猶予つきで作り直しが必要（公式に非推奨化された）。この記事では、この2つの中身を順番に見ていきます。

01 何が​公開されたのか ──​「発表記事」が​ない​ニュース

MCPがないと、AIに社内システムを触らせるたびに、AIごと・ツールごとの個別配線を書くことになります。共通の差込口を決めておけば、一度作った接続をどのAIからでも使える——というのがMCPの狙いです。

今回公開されたのは 2026-07-28 というバージョンです。MCPのバージョン名は日付そのもので、前の版は 2025-11-25 でした。

少し変わっているのは、この改定には「発表ブログ記事」が存在しないことです。公式サイトを探しても、記者発表もローンチ告知もありません。仕様書と変更履歴（changelog）が、その日付で静かに置かれるだけ。ニュースとして流れにくい理由でもあります。

運営体制も確認しておきます。MCPは現在、Linux Foundation傘下の「LF Projects, LLC」のプロジェクトとして運営されていて、ガバナンス文書の変更にもLF Projects側の承認が要ると明記されています^[3]。特定の一社が握っている規格ではない、ということです。

関連記事 ｜ MCPそのものの解説MCPは「便利な拡張機能」ではなく、AIに何を触らせるかの"権限レイヤー"だ ──GitHubが企業研修にした日、AI導入は"統制の設計"になった →

02 最大の​変更 ──​「つな​ぎっぱなしの​会話」を​やめた

今回の中心はここです。専門用語を使わずに言うと、AIと外部システムの通信が「電話」から「手紙」に変わりました。

これまでのMCPは、まず initialize という挨拶をして接続を確立し、以後はその接続の上で会話を続ける方式でした。電話をかけて、切らずに話し続けるイメージです。接続ごとに Mcp-Session-Id という識別子が振られ、サーバー側は「誰と話しているか」を覚えていました。

新しい仕様では、この挨拶とセッションがまるごと廃止されました^[1]。代わりに、1回1回のリクエストが、自分のバージョンと能力の情報を毎回持ち歩きます。手紙に毎回、差出人と使用言語を書いておくようなものです。仕様書はこう書いています。

交渉のためのハンドシェイクは存在しない。すべてのリクエストが自身のプロトコルバージョンを宣言し、サーバーはリクエストごとに個別に受理または拒否する^[2]

代わりに追加されたのが server/discover です。サーバーは「自分がどのバージョンに対応しているか」を答える窓口の実装が必須になりました。クライアントは事前に聞いてもいいし、いきなり本題を送って、対応していなければ返ってくるエラーで判断してもいい^[2]。

なぜこうしたのか

一言でいえば、現代のサーバー構成に合わせるためです。「つなぎっぱなし」の設計は、サーバーが常に同じ1台であることを前提にします。ところが今のクラウドは、リクエストのたびに別の実行単位が立ち上がる作り（サーバーレス）が主流です。この上で「さっきの会話の続き」を成立させるには、裏側で状態を共有する仕組みを別に用意しなければならない。ステートレス化は、その手間をなくします。

副次的な効果も明記されています。一覧を返す処理（tools/list など）が接続ごとに変わらなくなったため、結果をキャッシュできるようになりました。新仕様では一覧系の応答に ttlMs（何ミリ秒キャッシュしてよいか）と cacheScope（共有してよいか）を付けることが必須です^[1]。AIが同じ問い合わせを何度も繰り返す無駄が、規格のレベルで減ります。

03 既存の​連携は​壊れるのか ──答えは​「壊れない。​ただし両対応が​要る」

いちばん気になるところです。結論は壊れません。仕様書は、実装を3つの世代に分けて呼び分けています^[2]。

呼び方	意味
Modern（新）	バージョンと能力をリクエストごとに載せる方式（2026-07-28 以降）
Legacy（旧）	initialize で挨拶してセッションを張る方式（2025-11-25 以前）
Dual-era（両対応）	新旧どちらの相手とも話せる実装

サーバー側は、旧方式の挨拶と新方式の両方を実装してよい（MAY）と明記されています。クライアント側も、相手がどちらの世代かを検出する手順が通信方式ごとに定義されています。

つまり実務的には、「明日から動かない」ではなく「両対応にしておく期間がしばらく続く」という話です。

04 12か月で​作り直しが​要る​もの​ ──非推奨に​なった​4つ

こちらは実際に宿題が出ている部分です。今回、4つの機能が非推奨（Deprecated）になりました^[1]。非推奨とは「まだ動くが、将来なくなる。新しく作るものには使うな」という状態です。

非推奨になったもの	どういう機能か	公式が示す移行先
Roots	AIに「このフォルダを見ていい」と渡す仕組み	ツールの引数・リソースURI・サーバー設定で渡す
Sampling	サーバー側からAIに文章生成を頼む仕組み	AI提供元のAPIを直接使う
Logging	MCP経由でログを送る仕組み	標準エラー出力、またはOpenTelemetry
HTTP+SSE通信	旧式の通信方式	Streamable HTTP へ移行

加えて、認証まわりでOAuthの動的クライアント登録も非推奨になり、「Client ID Metadata Documents」という別方式が推奨になりました^[1]。

猶予期間も規格として決まっています。非推奨になってから最低12か月は仕様に残り、その後の版で初めて削除できる。起点は「その機能が非推奨と記された仕様が公開された日」で、短縮が許されるのは実際に攻撃が確認されている脆弱性の場合だけ（それもコアメンテナの承認が必要）です^[4]。

05 実務に​効く、​細かいけれど​大きい改善 ──途中で​人に​聞ける​形が​標準に​なった

残りの主要変更から、実務に効くものを3つ拾います。

① 処理の途中で確認を取る流れが、規格の標準パターンになった

これまでサーバーからAI側へ問い合わせる仕組みは個別の方式でしたが、新仕様では多段リクエスト（MRTR）という形にまとまりました。処理の途中で追加情報が必要になったら、サーバーは結果に resultType: "input_required" を付けて「これを教えてほしい」と返す。クライアントは情報を添えて、同じ依頼を送り直す^[1]。

私たちが案件で必ず入れているHITL（人間による最終確認）を、プロトコル側が受け止めてくれる形になりました。これまでは実装ごとの工夫だった部分です。

② 長時間かかる作業は、拡張機能に分離された

数分から数時間かかる処理を扱う「Tasks」は、コア仕様から公式拡張（io.modelcontextprotocol/tasks）に移りました。待たされ続ける方式をやめて、こちらから状況を聞きに行く方式に再設計されています^[1]。AIエージェントに長い仕事を任せる使い方が増えた結果です。

③ 認証のなりすまし対策が厳しくなった

認可の応答に発行元（iss）を含めることが推奨になり、クライアントは記録済みの発行元と一致するか検証しなければならない（MUST）。認証情報は発行元ごとに紐付けて保存し、別の認証サーバーで使い回してはならないとも明記されました^[1]。AIに社内システムの権限を渡す以上、当然きつくなる方向です。

06 発注側の​チェックリスト ──今日確認できる​5つ

• これから作る連携は 2026-07-28 準拠か。設計思想が変わったので、旧方式で新規に作ると寿命が短い
• 既存の連携で Roots / Sampling / Logging を使っていないか。使っていれば移行計画を（期限は最短で2027年7月28日）
• 通信方式が HTTP+SSE のままになっていないか。Streamable HTTP への移行対象
• 認証が動的クライアント登録のままか。発行元（iss）の検証が入っているか
• 一覧のキャッシュ（ttlMs）に対応しているか。無駄な問い合わせは、そのままAPI費用になる

私たち自身も、案件のシステムと社内のナレッジ基盤をMCPでつないで日常的に運用しています。今回の改定で作業が増えるのは事実ですが、方向としては歓迎しています。「つなぎっぱなしの会話」を前提にした設計は、AIが同時に何十本も仕事を持つ使い方と相性が悪かったからです。1回ごとに完結する形は、動かす側にとっては素直です。

旧仕様（〜2025-11-25） vs 新仕様（2026-07-28）

	旧仕様	新仕様
接続の考え方	initialize で挨拶しセッションを張る	挨拶なし。1回ごとに完結
バージョンの伝え方	接続時に一度だけ交渉	リクエストごとに宣言
対応状況の確認	接続してみるまで不明	server/discover（実装必須）
一覧のキャッシュ	接続ごとに変わりうるため困難	ttlMs ／ cacheScope で明示
途中の追加確認	サーバー発の個別リクエスト	多段リクエスト（MRTR）に統一
長時間処理	コア仕様の実験的機能	公式拡張に分離・問い合わせ方式
通信が切れたとき	再送で復帰を試みる	復帰は廃止。新しい依頼として出し直す