2026-07-28 版の MCP 仕様は、プロトコルレベルのセッションを廃止し、Tasks と MCP Apps を正式な拡張フレームワークに移し、OAuth のルールを厳格化し、Dynamic Client Registration を非推奨にして Client ID Metadata Documents に置き換えます。PaidSync は、14 のプラットフォームにわたる 630+ の広告ツールを備えたリモート MCP サーバーを、Claude と ChatGPT のクライアント向けに本番運用しており、これは各変更をその立場から見たときの作業メモです。初日に壊れるものはありません。非推奨の機能には、最低十二か月の期間があります。
以下のプロトコルに関する記述はすべて、公式リリース記事と 2026-07-28 のチェンジログに基づいており、どちらも 2026年8月1日の執筆時に確認しました。意見は私たち自身のものです。リリース記事は、このリビジョンが重要である理由を規模の数字で示しています。主要な SDK 全体で月間約五億回に近いダウンロード、TypeScript と Python の SDK はそれぞれ累計十億回を超え、Honeycomb は月間のインタラクティブなクエリの 20% 近くがエージェントからのものになっていると報告しています。The Register の報道は、メンテナーがリモート MCP の開始以来で最も重要なリリースだと語ったことを伝えています。私たちの立場から見ても、それはおおむね正しく、重要性の大半は派手さではなく運用面にあります。
7月28日に何が変わったか
| 変更点 | 内容 | 運用者の立場から見ると |
|---|---|---|
| ステートレスなコア | initialize ハンドシェイクと Mcp-Session-Id を削除。リクエストごとの _meta がバージョンと機能を運ぶ | 通常のロードバランシングで済み、スティッキーセッションは不要 |
| 再開機能の廃止 | 壊れたストリームでは実行中のリクエストが失われ、クライアントが再発行する | ミューテーションツールには冪等性キーが必要 |
| Tasks 拡張 | 公式の io.modelcontextprotocol/tasks、ポーリング方式、実行中の入力に対応 | 長時間の広告操作がゲートウェイのタイムアウトと戦わずに済む |
| MRTR | サーバーはクライアントを呼び出す代わりに input_required を返す | 呼び出し中の質問が、再開可能な状態になる |
| 認可の強化 | RFC 9207 の iss 検証、発行元に紐付けられた認証情報 | トークンフローに対するミックスアップ攻撃が塞がれる |
| DCR の非推奨化 | Client ID Metadata Documents が RFC 7591 の登録に置き換わる | クライアントのアイデンティティがドメインで裏付けられる |
| MCP Apps | インラインのインタラクティブ UI のための公式拡張 | チャットの画面でのグラフと承認フォーム |
| ヘッダーとキャッシュ | Mcp-Method/Mcp-Name が必須、リスト結果に ttlMs | ボディを解析せずにツールごとのエッジポリシーを適用 |
| 非推奨化 | Roots、Sampling、Logging、HTTP+SSE、最低十二か月の期間 | 予測できる時間軸でのクリーンアップ |
ステートレスなコアと再試行の問題
最大の変更点は次のとおりです。initialize/notifications/initialized のハンドシェイクがなくなり、Mcp-Session-Id ヘッダーもなくなりました。すべてのリクエストが、プロトコルバージョン、クライアントの機能、クライアントのアイデンティティを _meta に含め、新たに必須となった server/discover RPC により、クライアントは事前に機能を確認できます。サーバーからクライアントへの変更通知は、オプトイン方式のひとつの subscriptions/listen ストリームにまとめられます。メンテナーが狙う実際の効果は、The Register も強調しているとおり、共有のセッションストアなしで、通常の Kubernetes ツールを使った通常のロードバランサーの背後で、どのリクエストもどのサーバーインスタンスにも到達できることです。
運用者としての率直な見方は次のとおりです。プロトコルセッションは、私たちの重要な状態が置かれていた場所では一度もありませんでした。広告サーバーにとって重要な状態は、OAuth の許可、有効な広告アカウントの選択、支出ガードレール、プラットフォームごとのレート予算です。この状態は、接続が切れても維持される必要があるため、認証済みユーザーに紐付いたデータベースに置かれます。旧ハンドシェイクが加えていたのは、本物のセッションとは独立して切れる、もうひとつの壊れやすいセッションでした。デプロイやバランサーの再起動はプロトコルセッションを切断しますが、認証セッションは無事です。この層を削除すれば、わかりにくい障害の一群がなくなります。正当な呼び出し間の状態に対する仕様の代替案は、サーバーが発行するハンドルを通常のツール引数として渡す方法で、広告のフローはもともとそう読めます。アカウントを選び、ハンドルを受け取り、先に渡す。どのインスタンスもそれをコールドで受け取りうるため、署名して有効期限を付けてください。
落とし穴はリトライの挙動
ステートレス化の話に隠れていますが、実際のお金のインシデントを最も起こしやすい変更があります。SSE ストリームの再開機能とメッセージの再配信が削除されたことです。2026-07-28 版では、応答ストリームが途切れると処理中のリクエストは失われ、クライアントは新しいリクエスト ID で新しいリクエストとして再送する必要があります。get_campaign_performance なら、再試行しても何も失いません。しかしキャンペーンの作成や予算の更新で盲目的に再試行すると、エージェントは二重に支出してしまいます。サーバーがお金を動かすなら、ツールの契約に冪等性キーが必要で、バックエンドには重複排除が必要です。トランスポートが元の結果を再配信することはもう保証されないからです。PaidSync の書き込み系ツールは dry_run と confirm_destructive フラグで保護されており、影響範囲は狭まりますが、ゲートは重複排除ではありません。二つを別々の対策として、両方とも実装してください。
Tasks がようやく広告運用の実態に合う
Tasks は実験的なコアから外れ、公式の拡張機能 io.modelcontextprotocol/tasks になります。再設計では、ブロッキングの tasks/result 呼び出しが tasks/get によるポーリングに置き換わり、タスクの途中でクライアントからサーバーへ入力できる tasks/update が加わり、サーバーはリクエストごとのオプトインなしでタスクハンドルを自発的に返せるようになります。The Register の記事は耐久性の点を強調しています。タスクは安定したハンドルで指定されるため、クライアントはタスク ID を保存しておき、クラッシュや再起動の後でもポーリングを再開できます。
広告運用は本質的に長時間かかる作業です。200 キャンペーンを持つ MCC の監査。一シーズン分の広告セットの一括停止(Meta 一括操作のドキュメントはこうした作業のためにあります)。90 日間のクロスプラットフォームレポートの取得。現状では、これらすべてがサーバー手前のプロキシの制限時間内に終わる必要があり、本番環境にはどれもそうしたプロキシがあります。ポーリング型のタスクは地味な HTTP インフラと相性が良く、見守るべき接続を保持し続ける必要も、エッジのタイムアウトで途中で切られることもありません。
tasks/update は、特に広告運用にとってひそかに重要な部分です。途中で入力を受け付けるタスクは、破壊的な処理の前に一時停止して確認できるタスクです。今の承認ゲートは二つのタスクで、まずドライラン、次に明示的な確認です。Tasks なら、同じ安全パターンを人間の確認を挟んだ一つの永続的な操作にでき、複数ステップの作業を計画するエージェントに向いた形です。注意点は構造的なもので、拡張機能はデフォルトで無効であり、双方の明示的なオプトインが必要です。そのため、効果が出るのは Claude と ChatGPT がクライアント対応を出してからで、それより前ではありません。
MRTR がサーバー起点の要求に代わる
サーバー起点のリクエスト(roots/list、sampling/createMessage、elicitation/create)は、Multi Round-Trip Requests パターンに置き換わります。追加情報が必要なサーバーは、質問を載せた resultType: "input_required" の結果を返し、クライアントは回答を inputResponses に付けて元のリクエストを再送します。すべての結果に必須の resultType が付くようになり、これを省略する旧プロトコルのサーバーからの結果は完了済みとして扱う必要があるため、バージョンが混在する環境でも整合性が保てます。
エリシテーションは、サーバーが呼び出しの途中で「14 件の広告アカウントのうち、どれのことですか?」と尋ねる仕組みでした。MRTR は質問を残したまま、仕組みを逆にします。再試行が別のインスタンスに届く可能性があるため、サーバーは保留中の質問をプロセスのメモリに置いておけません。質問に必要な文脈は requestState に入れます。後から組み込むのは面倒ですが、設計としては正しい変更です。また、リモートの広告サーバーが早い段階で学ぶ教訓も正式なものになります。チャットクライアントは会話の途中でしょっちゅう消えるので、再開できない操作途中の質問は、操作を宙に浮かせてしまいます。途中で止まったフローを数多く見てきた私たちにとって、これは仕様が現実に追いついたものです。
PaidSync は広告運用向けのリモート MCP サーバーです。14 プラットフォームにまたがる 630+ のツールを、一つのエンドポイントから Claude や ChatGPT で使えます。
MCP サーバーを見る 無料で始める認可の設定ミスが起きにくくなる
三つの厳格化があり、いずれも変更履歴に基づきます。認可サーバーは、RFC 9207 に従って認可レスポンスに iss パラメータを含めるべきで、クライアントはコードを引き換える前に、記録済みの発行者と照合して検証しなければなりません。クライアント認証情報は、発行元の認可サーバーに明示的に紐づけられます。発行者ごとに管理し、別の発行者で使い回さず、発行者が変わったら再登録します。さらにクライアントは登録時に application_type を宣言する必要があり、CLI やデスクトップのエージェントで長く続いていた localhost リダイレクト拒否の問題が解消されます。Enterprise-Managed Authorization も正式な拡張機能として加わり、組織はエージェントが使える MCP サーバーを一元的に管理できます。
これが広告サーバーにとって特に重要な理由は、リモートの広告 MCP サーバーへの一つのベアラートークンが、Google、Meta、LinkedIn の実際の広告アカウントとその実際の予算の入り口になるからです。OAuth のなりすまし攻撃がまさに狙う対象であり、iss の検証は標準的な対策です。新しい義務の大半はクライアント側のコードに課されますが、検証の基準となる正確な認可メタデータをサーバーが公開していなければ機能しません。参考までに、現在 PaidSync が提供している基本構成は、well-known パスでの RFC 8414 認可サーバーメタデータと RFC 9728 保護リソースメタデータ、公開された security.txt、MCP サーバーカードとエージェント認証マニフェスト、そしてユーザーがいつでも接続済みクライアントを切断できるセッション失効です。これは現行の安定版を丁寧に実装したものであり、2026-07-28 版の実装ではありません。仕様を読むことと提供することは別だからこそ、はっきり述べています。
DCR は終了、CIMD へ
Dynamic Client Registration(RFC 7591)は、MCP のクライアント登録方式としては正式に非推奨となり、Client ID Metadata Documents に移行します。まだ移行していない認可サーバー向けに、後方互換のために引き続き利用できます。CIMD では、client_id はクライアント運営者が管理する HTTPS URL で、認可サーバーはその URL からクライアントのメタデータを取得します。
これには私たちなら二回投票します。DCR では、未知のエージェントがすべて認可サーバーに自己登録していました。匿名の行、自己申告の名前、評判ゼロ、そして誰にも使われなかった登録を消す定期的なクリーンアップ作業です。CIMD は入口での問いを「これは登録したか?」から「このドメインの持ち主は誰か?」に変えます。広告費を扱うサーバーにとって、この違いはポリシーのレベルで効きます。既知のエージェントプラットフォームの許可リストが作れるようになり、同意画面も正直になります。ユーザーが承認するクライアント名は、クライアント自身が入力したものではなく、ドメインに裏づけられたものになるからです。移行の方針は自然に決まります。非推奨期間中は DCR を動かし続け、CIMD を提示するクライアントには CIMD を優先し、信頼ポリシーの策定を今から始めてください。難しいのはパースではなくポリシーだからです。
MCP Apps と基盤まわりの変更
MCP Apps
MCP Apps は、新しい拡張機能フレームワークの公式拡張として登場します。拡張機能のドキュメントによると、サーバーはグラフ、フォーム、動画プレーヤーなどのインタラクティブな UI 要素を、会話の中にそのまま表示できます。広告運用での使い道は明らかです。ASCII の表ではなく実際のグラフで見る支出推移、公開前のキャンペーンプレビュー、キャンペーンごとにチェックボックスが付いた一括変更の承認フォーム。表示された承認フォームは、自由記述の「はい、確認します」よりずっと安全な画面です。注意点は Tasks と同じで、双方のオプトインが必要なため、クライアントの対応状況が時期を決めます。
ヘッダーとキャッシュ
Streamable HTTP の POST には Mcp-Method と Mcp-Name ヘッダーが必須になり、ゲートウェイは JSON の本文を解析せずにルーティングやレート制限ができます。当社のサーバーでは 438 の稼働中ツールがあり、エッジでのツール単位のポリシー、変更系ツールへのより厳しい制限、本文に触れない WAF ルールは、手軽に使える機能なので取り入れる予定です。一覧の結果(tools/list など)には ttlMs と cacheScope が必須になり、クライアントは大きなツールカタログを毎ターン取得し直さずに済むようになります。仕様はまた、LLM のプロンプトキャッシュのヒット率を上げるため、ツールを決まった順序で返すようサーバーに促しています。当社規模のカタログでは、トークンコストを直接左右する要素です。カタログの規模をめぐるトレードオフはツール数が強みである理由で書いています。
期限のある非推奨化
Roots、Sampling、Logging は、レガシーな HTTP+SSE トランスポートとともに非推奨となります。新しい機能ライフサイクルにより、最低でも十二か月の移行期間が保証されます。当社には影響がありません。サーバー側の Sampling は、ツールサーバーが他人のモデルトークンを使うことになり、課金の境界ではそもそも筋が悪いものでした。ログは stderr か OpenTelemetry に移りますが、本番サーバーはもともとそうしています。ライフサイクルポリシー自体が成果です。廃止は不意打ちではなく、計画できるスケジュールとともに行われるようになりました。
変わらないこと
このページを読み過ぎないための、率直な説明
PaidSync は 2026-07-28 版をまだ提供していません。当社の本番サーバーは、Claude や ChatGPT のクライアントが現在話している現行の安定版プロトコルで動いており、対応はそれらに合わせて進めます。片方しか話さない仕様は、誰も話さない仕様だからです。クライアントの対応時期はクライアントのベンダーが決めることで、当社が推測して書くことはしません。Tasks や MCP Apps を含む拡張機能はデフォルトで無効で、双方のオプトインが必要です。初日に削除されるものはなく、非推奨の機能には最低でも十二か月の期間があり、DCR も後方互換のために動き続けます。そして、この仕様が直すのはプロトコルの状態であり、広告の判断ではありません。無駄な広告費、壊れたコンバージョン計測、不適切なオーディエンス選びは、どのプロトコル改訂でもそのまま残ります。その層についてはAI で無駄な広告費を見つける方法で扱っています。
開発者の初週チェックリスト
リモート MCP サーバーを運用中、または構築中の方へ。本番運用の経験から、次の順番で進めることをおすすめします。
1. すべての変更系ツールについて、再試行しても安全か監査する。再開機能はなくなり、クライアントは失われたリクエストを再送します。お金のかかるものを作成または変更するツールには、冪等性キーを追加してください。
2. 呼び出しをまたぐ状態を、サーバー発行のハンドルに移す。プロトコルセッションに紐づいてプロセスメモリにある情報は、この改訂で使えなくなります。ハンドルは、署名付きで有効期限のあるツール引数にします。
3. OAuth メタデータを確認する。クライアント側の新しい iss 検証と発行者の紐づけは、正確な RFC 8414 と RFC 9728 の well-known ドキュメントがあって初めて機能します。公開して、内容を正しく保ってください。
4. CIMD の信頼ポリシーを作る。許可するクライアントのドメインと、移行期間中の匿名 DCR のフォールバックをどうするかを決めます。まずポリシー、コードはその次です。
5. 長時間かかるツールを Tasks に対応づける。ゲートウェイの制限時間を超えうるツールをすべて挙げ、そのうち途中での入力が必要なものに印を付けます。それらは tasks/update のもとで承認の一時停止になります。
6. tools/list を決定的にし、現実的な TTL を設定する。安定した順序と ttlMs は、プロンプトキャッシュを持つすべてのクライアントにとって、手間なく得られるトークン節約になります。
ChatGPT に追加：ChatGPT のプラグインディレクトリで PaidSync.ai を開き、インストールしてからサインインします。
Claude に追加：Claude のコネクタディレクトリで PaidSync.ai を開き、「接続」をクリックしてからサインインします。
よくある質問
2026-07-28 版の MCP 仕様では何が変わりましたか？
この改訂で MCP はステートレスになります。initialize ハンドシェイクと Mcp-Session-Id ヘッダーは削除され、すべてのリクエストがプロトコルバージョンとクライアントの機能を _meta に含め、新しい server/discover RPC がサーバーの機能を通知します。SSE ストリームの再開は削除されるため、ストリームが途切れるとリクエストが再送されます。Tasks は実験的なコアから公式の拡張機能に移り、ポーリング型の tasks/get と、tasks/update による途中入力を備えます。Multi Round-Trip Requests は、サーバー起点のエリシテーション、サンプリング、roots の呼び出しに置き換わります。認可は RFC 9207 の iss 検証と発行者に紐づく認証情報で強化されます。Dynamic Client Registration は非推奨となり、Client ID Metadata Documents に移行します。Roots、Sampling、Logging、HTTP+SSE は最低でも十二か月の期間をもって非推奨となります。出典は公式の変更履歴で、2026年8月1日に確認しました。
2026-07-28 版の仕様は既存の MCP サーバーを壊しますか？
初日からではありません。このリリースでは、最低でも十二か月の非推奨期間を持つ正式な機能ライフサイクルが採用され、DCR は後方互換のために引き続き動作し、クライアントは新しい resultType フィールドを省略する旧プロトコルのサーバーからの結果を完了済みとして扱う必要があります。すぐに注意すべき変更はリトライの挙動です。再開機能とメッセージ再配信が削除されるため、応答ストリームを失ったクライアントはリクエストを再送します。キャンペーン作成や予算変更のような変更系ツールを公開するサーバーは、再送された書き込みが二重に適用されないよう、冪等性キーを追加してください。
MCP の Dynamic Client Registration に代わるものは何ですか？
Client ID Metadata Documents(CIMD)。クライアントは、RFC 7591 に基づいてすべての認可サーバーに自己登録する代わりに、自分で管理する HTTPS URL を client_id として使い、認可サーバーはその URL からクライアントのメタデータを取得します。身元がドメインに裏づけられて検証可能になるため、サーバー運営者は既知のエージェントプラットフォームの許可リストを作り、自己申告の名前ではなくドメインに裏づけられた同意画面を表示できます。DCR は非推奨ですが、まだ CIMD に対応していない認可サーバー向けに引き続き利用できます。
PaidSync はすでに 2026-07-28 版の MCP 仕様を実装していますか？
いいえ。PaidSync の本番 MCP サーバーは、Claude や ChatGPT のクライアントが現在話している現行の安定版プロトコルで動作しています。提供済みの基本構成は、well-known エンドポイントでの RFC 8414 認可サーバーメタデータと RFC 9728 保護リソースメタデータ、公開された security.txt と MCP サーバーカード、セッション失効、そして dry_run と confirm_destructive フラグによる書き込みの保護です。新しい改訂への対応は、Claude と ChatGPT のクライアント対応に合わせて進めます。