Model Context Protocol（MCP）に、2026年7月28日付の新しい仕様が公開されました。これまでの安定版からの変更が大きく、MCPの土台となる考え方が一部作り直されています。
この記事は、MCPの基本をひととおり理解した方が「何がどう変わったのか」をつかむための解説です。まだMCPそのものが初めての場合は、先にマーケターのためのMCP入門を読むと、ここからの話が理解しやすくなります。専門用語はできるだけ日常の例えに置き換えて進めます。
30秒でMCPをおさらい
まず前提を短く確認します。MCPは、AIエージェントが外部のツールやデータに接続するための共通規格です。AIにとってのUSBポートのようなもの、と考えると分かりやすいです。差し込む相手が変わっても、同じ形の口でつながります。
登場人物は3つでした。指示を出すAIエージェント本体の「ホスト」、ツール側の窓口になる「MCPサーバー」、そしてBigQueryやSlackといった「ツール」の実体です。この3層の間で、決められた形式のメッセージをやりとりします。
| 用語 | ざっくりした意味 |
|---|---|
| ホスト | 指示を出すAIエージェント本体（Claude Code など） |
| MCPサーバー | ツールをAIから使える形に変換する窓口 |
| ツール | BigQueryやSlackなど、実際に動かす道具 |
| クライアント | ホストの中でサーバーと1対1で通信する部分 |
今回の変更は、この「メッセージのやりとりの作法」を整理し直したもの、と考えてください。配線でつなぐという役割そのものは変わっていません。
2026年7月版は何が大きく変わったのか
いちばんの変化を一言でいうと、「つなぎっぱなしをやめて、毎回その場で完結させる方式に変えた」ことです。公式の変更履歴でも、この点が中心の変更として挙げられています。
これまでは、通信を始めるときに最初のあいさつ（initialize）を交わし、そのつながりを保ったままやりとりを続けていました。新仕様では、この「最初のあいさつ」と「つながりを保つ」考え方をやめ、リクエストの1回1回が独立して完結する形になりました。
なぜこう変えたのでしょうか。つなぎっぱなしの方式は、途中でつながりが切れると面倒が起きやすく、複数の窓口を経由するような構成とも相性が悪い、という弱点がありました。毎回完結する方式にすると、通信の途中経過を覚えておく負担が減り、間に別のサーバーをはさむような構成にも耐えやすくなります。
ここから先は、この「毎回完結」への変更が具体的にどんな形で表れているかを、4つに分けて見ていきます。
変更1：接続しっぱなしをやめる「ステートレス化」
1つ目は、いちばん根っこの変更です。旧来の「最初のあいさつ」を廃止し、すべてのリクエストが自分だけで完結する形になりました。これを難しい言葉でステートレス（状態を持ち越さない）と呼びます。
会員制のお店と、都度チケットのお店にたとえると分かりやすいです。旧方式は、入店時に会員証を作り、その会員証で滞在中ずっと通す形でした。新方式は、来るたびに「私はこういう者で、これがしたい」というチケットを毎回見せる形です。
具体的には、各リクエストの中に「対応するプロトコルのバージョン」と「クライアントができることの一覧」を毎回添える形になりました。あわせて、通信経路（Streamable HTTP）から、やりとりをひとまとめに縛っていた識別子（セッションID）も取り除かれています。
「では、買い物カゴのように途中の状態を保ちたいときはどうするのか」という疑問が湧きます。その場合は、サーバーが発行する明確な合言葉（カートIDのようなもの）を受け取り、それを次のリクエストに添えて渡します。状態を持ち越すのをやめる代わりに、必要なときは合言葉を明示的に手渡す、という整理です。
変更2：はじめの窓口になる「server/discover」
2つ目は、新しく用意された最初の窓口です。server/discover という問い合わせの口が加わり、MCPサーバーはこれに必ず応えられるようにすることが求められます。
これは名刺交換にあたります。クライアントは本題に入る前に、この窓口へ「あなたは何ができて、どのバージョンに対応していますか」と尋ねられます。相手の対応範囲を先に確認してから、無理のないやりとりを始められる、という仕組みです。
この問い合わせ自体は、クライアントにとっては任意です。必要なら先に確認できる、という位置づけで、毎回必ず呼ぶ決まりではありません。ただしサーバー側は「聞かれたら答えられる」状態にしておくことが必須になりました。ステートレス化で最初のあいさつがなくなった分、対応範囲を知る手段としてこの窓口が用意された、と捉えると流れがつながります。
変更3：補助機能を思いきって整理
3つ目は、機能の断捨離です。MCPには、ツール・リソース・プロンプトという主役級の機能のほかに、補助的な機能がいくつかありました。今回、そのうち使われ方の限られていたものが非推奨に整理されました。
ここで大切なのは、非推奨は「今すぐ使えなくなる」ではない点です。今回の仕様から「非推奨にしてから最低12か月は残す」というルールが明文化されました。つまり非推奨は、廃止に向けた予告と移行のお願い、という意味合いです。
| 補助機能 | ざっくりした役割 | 2026-07-28での扱い |
|---|---|---|
| Sampling（サンプリング） | サーバーがクライアント経由でAIに文章生成を頼む | 非推奨（各AIのAPIを直接使う方式へ） |
| Roots（ルート） | クライアントが「この範囲を見て」と伝える | 非推奨（ツールの引数などで範囲を渡す方式へ） |
| Logging（ロギング） | サーバーの動作ログを送る | 非推奨（標準エラー出力などへ） |
| Elicitation（追加入力の要求） | 処理中に不足情報をユーザーへ聞く | 存続（引き続き使える） |
もう1つ、これらの機能の呼び出し方も整理されました。以前はサーバー側から割り込むように要求を送る方式でしたが、新仕様では「いったん『追加の入力が必要です』と返し、クライアントがそれに答えて再度リクエストする」という往復のやりとりに統一されています。割り込みをやめて、行って戻る形にそろえた、と考えてください。
なお、これまでコア（土台）に含まれていた「時間のかかる処理を扱う仕組み（Tasks）」は、土台から公式の拡張機能へと移されました。土台をできるだけ小さく保ち、追加の機能は拡張として足す、という整理の方向がここにも表れています。
変更4：通信の通り道を一本化
4つ目は、通信経路（トランスポート）の整理です。MCPには複数の通り道がありましたが、古い方式が正式に非推奨となり、推奨経路がはっきりしました。
具体的には、以前使われていた「HTTP＋SSE」という経路が正式に非推奨へ格下げされ、より新しい「Streamable HTTP」への移行が推奨されています。手元のパソコンでAIと道具を直接つなぐ「stdio」は引き続き現役です。
| 通信経路 | どんな場面で使うか | 現在の位置づけ |
|---|---|---|
| stdio | 手元のパソコン内で直接つなぐ | 現役 |
| Streamable HTTP | ネットワーク越しにつなぐ | 推奨 |
| HTTP＋SSE | 以前のネットワーク越しの方式 | 非推奨（Streamable HTTPへ） |
利用者の立場では、この経路の違いを意識する場面は多くありません。多くは、使っているMCPサーバーやエージェントが対応経路を選んでくれるためです。ただし、少し古いMCPサーバーを使う場合は、非推奨経路に依存していないかを頭の片隅に置いておくと安心です。
認可とセキュリティはどう整理されたか
土台の作法だけでなく、安全面のルールも見直されました。ここは作る側の話が中心ですが、AIに道具を渡す以上、使う側も考え方を知っておくと判断の助けになります。
認可（誰にどこまで許すか）は、Web業界で標準的なOAuth 2.1という仕組みをベースにしています。今回は、事前に手作業で登録する方式から、より安全に自動で身元を示す方式を推奨する、といった細かな整理も入りました。
| 論点 | 仕様が求めていること |
|---|---|
| 認可の土台 | OAuth 2.1をベースにする |
| トークンの取り違え | 自分宛でないアクセス許可証を受け取って使い回さない |
| 権限の広さ | 最小限から始め、必要に応じて段階的に広げる |
| 状態の合言葉 | 予測できない値にし、利用者と結びつけて検証する |
考え方の芯は、入門記事で触れた「読み取り専用で小さく始める」と同じです。仕組みが安全になっても、渡す権限を最小限にする姿勢は、いちばん確実な守りであり続けます。
運用者・マーケターは何を気にすればいい
最後に、広告運用やマーケティングの実務でMCPを「使う側」に立つ人が、今回の変更で気にすべき点を整理します。結論をいえば、多くの人はすぐに手を動かす必要はありません。ステートレス化やserver/discoverは、作る側が内部で対応する話だからです。
とはいえ、まったくの無関係でもありません。次のチェックリストの範囲を、頭の片隅に置いておけば十分です。
- 使っているMCPサーバー・エージェントが新仕様に更新されたら、案内に沿って設定を見直す
- 非推奨になった補助機能に依存した使い方をしていないか、更新時に確認する
- 古いMCPサーバーは、非推奨の通信経路に依存していないかを気に留める
- 認可や権限の設定は、これまでどおり読み取り専用・最小権限から始める
- 組み合わせて使うツールは、両側が対応済みのバージョンかを公式情報で確かめる
大きな流れとしては、MCPが「その場かぎりで完結する、身軽な作法」へ寄せてきた、と捉えておけば十分です。細部の作法は変わっても、AIと道具をつなぐ配線という役割と、安全に小さく始めるという構え方は変わりません。
まとめ
2026年7月版のMCP仕様で変わった点を、やさしく整理しました。要点を振り返ります。
| 変更点 | 何が変わったか |
|---|---|
| ステートレス化 | 最初のあいさつを廃止し、リクエストごとに完結する方式へ |
| server/discover | 本題の前に対応範囲を確認できる窓口を新設 |
| 補助機能の整理 | Sampling・Roots・Loggingを非推奨に、Elicitationは存続 |
| 通信経路の一本化 | HTTP＋SSEを非推奨に、Streamable HTTPを推奨 |
| 安全ルールの見直し | OAuth 2.1ベース、トークンの取り違えを禁止、最小権限を徹底 |
今回の変更は、MCPを「つなぎっぱなし」から「毎回その場で完結」へと組み替えた、土台の模様替えです。使う側にとっての本質は変わらず、ツールやエージェントの更新に合わせて設定を見直していけば問題ありません。
MCPそのものの基礎を固め直したい場合はマーケターのためのMCP入門へ、実際に手を動かして接続を試したい場合はBigQueryをAIエージェントに接続する実装編へ進むのがおすすめです。