AI・DX

MCP新仕様2026-07-28リリース予定｜旧仕様前提のAIエージェント納品物が1年で負債化する発注前チェック

2026年7月23日25分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

5分で自社の状況を診断する

GXO COLUMN

AI・DX

結論：発注書に「どの仕様版で作るか」を書かないと、1年で保守負債になる

MCP(Model Context Protocol)は、AIエージェントを社内システムや外部サービスへ接続するための共通規格です。その新しい仕様バージョン 2026-07-28 が、2026年7月28日に正式リリースされる予定であることが、公式ブログ（Model Context Protocol Blog）で告知されています。本記事執筆時点（2026年7月23日）では正式版はまだ公開されておらず、公開されているのはリリース候補（release candidate、2026年5月21日に確定）の内容です。したがって、以下の記述は「予定・候補段階の情報」であり、最終版で細部が変わり得る点を前提に読んでください。

経営者として押さえるべき核心は一つです。今回の改訂は、これまでプロトコル（規格そのもの）が肩代わりしていた安全のしくみの一部を取り払い、その責任を「作る側」つまり開発ベンダーとプラットフォーム運用者へ移す方向にあります。つまり、同じ「AIエージェントを作りました」という納品物でも、どの仕様版に沿って、認可（誰が何をしてよいか）をどう設計したかによって、1年後に安全で保守しやすいものになるか、作り直しが必要な負債になるかが分かれます。

だからこそ、発注前に確認すべきは「機能が動くか」ではなく、「どの仕様版で作るのか」「廃止予定の機能に依存していないか」「認可の設計を誰がどう担うのか」の3点です。この記事は、この3点を非エンジニアでも判断できるチェックの形に落とし込みます。

AI ASSESSMENT

PoC の前に「そもそも使えるか」を30分で見極めませんか？

対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。

30分壁打ちを予約

3行サマリー（先に結論）

MCP新仕様 2026-07-28 はリリース候補が確定済みで、7月28日に正式版が出る予定。旧版は 2025-11-25。
主な変更は、セッションID廃止による「ステートレス化」、OAuth 2.0／OpenID Connect整合の認可強化、Roots・Sampling・Loggingの段階的廃止（annotation-only＝当面は動くが将来削除の予告）。
安全の担い手がプロトコルから開発者側へ移るため、旧仕様前提で発注した納品物は1年前後で保守負債化するリスクがある。発注書で仕様版と認可設計を明記させることが最初の防波堤になる。

要点表：新仕様2026-07-28の主要ポイント

横にスクロールして確認できます

項目	リリース候補で示されている内容	経営判断への含意
バージョン	`2026-07-28`（旧 `2025-11-25` からの更新）	発注書・仕様書にどちらで作るか明記が必要
リリース候補確定	2026年5月21日	仕様の骨格は固まっている
正式リリース予定	2026年7月28日	執筆時点では未公開。断定は避ける
検証期間	約10週間（SDK保守者・クライアント実装者向け）	ベンダーの検証状況を確認できる
ステートレス化	`initialize`/`initialized` ハンドシェイクと `Mcp-Session-Id` を削除	状態管理の責任がアプリ側へ移る
認可強化	6件のSEPでOAuth／OIDC整合を厳格化（`iss` 検証を RFC 9207 準拠で要求など）	認可設計の巧拙が安全性を左右する
段階的廃止	Roots・Sampling・Logging（annotation-only、最低12ヶ月の猶予）	廃止機能への依存は将来の作り直しリスク

数値・日付・機能名は公式ブログのリリース候補告知に基づきます。正式版で変更され得るため、契約前には最終版の仕様を一次で再確認してください。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

誰が読むべきか

複数部署で「AIエージェントを試したい」という声が上がり始めたが、全体像を説明できない経営者・事業責任者。
情シスが0〜1名で、ベンダー提案の技術的な当否を自分で検証しきれない中堅企業のCEO・役員。
すでにMCPを使ったAIエージェントやツール連携をPoC・開発発注しており、「このまま本番に上げてよいか」を迷っている担当者。
見積書に「MCP対応」とだけ書かれ、どの仕様版・どの認可方式なのかが読み取れないと感じている発注側。

技術者向けの移行手順書ではありません。経営としてどこにお金と責任の線を引くか、ベンダーに何を問うかを判断するための記事です。

そもそもMCPと今回の改訂を一言で

MCPは、生成AIやAIエージェントが「社内の在庫システム」「顧客管理」「経費精算」などの外部機能を、共通の作法で呼び出すための規格です。これまでは、AIとサーバーが会話を始めるときに握手（ハンドシェイク）をして、その会話に「セッションID」という札を付け、以降のやり取りを同じ札で結び付けていました。この札の管理はプロトコルの役目でした。

新仕様では、この握手とセッションIDを取り払います。公式は「initialize/initialized ハンドシェイクを削除し、Mcp-Session-Id ヘッダとそれに伴うプロトコルレベルのセッションも削除する」と説明しています。代わりに、状態が必要な場合は、サーバーが「ハンドル（handle）」と呼ばれる識別子（たとえば買い物カゴのID）を返し、AIがそれを次の呼び出しで引数として渡し直す方式を取ります。会話の連続性を、規格ではなくアプリケーションの作りで担保する、という発想の転換です。

運用面の利点として、公式は「どのMCPリクエストもどのサーバーインスタンスに届いてよくなり、水平展開で必要だったスティッキールーティングや共有セッションストアがプロトコル層では不要になる」と述べています。負荷分散や多重化がしやすくなり、インフラのコストが下がる方向です。この「安くなる・スケールしやすくなる」という利点は本物です。ただし利点の裏側に、責任の移転という論点が隠れています。

新旧仕様の差分（発注判断に効く違いだけ）

横にスクロールして確認できます

観点	旧仕様（`2025-11-25` まで）	新仕様（`2026-07-28` 予定）	発注側が気にすべき点
会話の状態管理	プロトコルがセッションIDで管理	ハンドシェイク・セッションID廃止。アプリ側でハンドルを設計	状態を誰がどう安全に設計するか
スケール前提	スティッキールーティング等が必要	どのインスタンスでも受けられる	インフラは簡素化＝コスト減の余地
認可（OAuth/OIDC）	実装差が大きかった	`iss` 検証（RFC 9207）等を明確に要求、DCRで `application_type` 宣言など	認可設計の質が安全性を決める
Roots	利用可能	段階的廃止（ツール引数・リソースURI・サーバー設定へ）	依存していると将来作り直し
Sampling	利用可能	段階的廃止（LLMプロバイダAPIへの直接統合へ）	同上
Logging	利用可能	段階的廃止（stdioはstderr、構造化はOpenTelemetryへ）	監視・ログ設計の見直しが要る
Tasks（非同期タスク）	実験的	正式化。`tasks/list` は削除（セッションなしで安全に絞れないため）	非同期処理の作り方が変わる
状態の安全性	プロトコルが一定担保	開発者・運用者の実装責任が増える	責任分界の合意が必須

差分の要点は「便利になった」ではなく「安全の作り込みが発注側の設計要件に昇格した」ことです。とくにハンドルやタスクの識別子が推測しやすい作りだと、他人のワークフローに割り込む、別エージェントのデータに触れる、といった新しい攻撃面が生まれ得ます。この点は後述の二次情報（Akamai）でも指摘されています。

ステートレス化を非エンジニア経営者向けに翻訳する

セッションIDの廃止を、店舗のたとえで言い換えます。旧仕様は、来店客に整理番号札を配る役割を「店（プロトコル）」が担っていました。新仕様では、その札を配る・照合する仕事を「各カウンター（アプリ／ベンダーの実装）」が自前でやることになります。うまく設計すれば、どのカウンターでも同じ客を捌けて回転が上がります。逆に、札の採番がいい加減で他人の札と被れば、注文の取り違えや、他人の会計に紛れ込む事故が起きます。

経営として重要なのは、この「札の設計」が今後は納品物の品質そのものだという点です。従来なら「規格が面倒を見てくれる」で済んだ部分が、これからは「どんなハンドルを、どう推測されにくく、どう権限と結び付けて発行するか」という設計判断になります。ここを安く早く済ませたベンダーの成果物は、動いてはいても、後から穴が見つかりやすくなります。見た目の完成度と、安全の作り込みは別物だという前提で受け入れ検査を設計してください。

OAuth／OIDC整合の認可強化が意味すること

今回の改訂では、6件のSEP（仕様提案）で認可のしくみがOAuth 2.0／OpenID Connectの実運用に近づく形に厳格化されます。公式が挙げる具体例には、認可レスポンスの iss（発行者）パラメータを RFC 9207 に沿って検証すること、動的クライアント登録（DCR）でクライアントが application_type を宣言すること、登録した資格情報を発行元認可サーバーの issuer に結び付けること、ステップアップ時のスコープ蓄積の扱いを明確化すること、などが含まれます。将来版では、iss を欠くレスポンスをクライアント側が拒否することが期待される、とも予告されています。

平たく言えば、「このアクセスは本当に正しい発行元から来たのか」「このAIエージェントは誰の権限で、どこまでの範囲を触ってよいのか」を、今まで以上に厳密に確かめる作りが求められます。これは安全性の底上げですが、裏返せば、認可設計を軽く見た実装は仕様の意図から外れ、監査で指摘される余地が増えるということです。認可は後付けが最も難しい領域なので、発注時点で設計思想を確認しておく価値が高い部分です。認可・権限・ログの全体設計を第三者の視点で点検したい場合は、AIエージェントの権限・認可設計を発注前に点検する相談窓口を起点にすると論点を整理しやすくなります。

段階的に廃止される3機能とタイムライン

公式は Roots・Sampling・Logging の3機能を、新しいライフサイクル方針のもとで廃止（deprecate）対象にすると説明しています。重要なのは、これが「annotation-only（注記のみ）の廃止」である点です。公式の言葉では「メソッド・型・機能フラグは、本リリースおよびその公開から1年以内に出る各仕様版で引き続き動作する」とされています。つまり、いきなり動かなくなるわけではなく、最低12ヶ月の猶予をもって将来削除される予告、という位置づけです。

横にスクロールして確認できます

廃止対象	公式が示す代替	猶予	発注側の含意
Roots	ツール引数・リソースURI・サーバー設定	最低12ヶ月	依存箇所は棚卸しし、代替へ移行計画を
Sampling	LLMプロバイダAPIへの直接統合	最低12ヶ月	AI呼び出しの経路が変わる。設計見直し
Logging	stdioはstderr、構造化観測はOpenTelemetry	最低12ヶ月	監視・監査ログの土台を作り直す前提

「12ヶ月動く」を「まだ考えなくていい」と読むと危険です。今から発注・開発するAIエージェントがこれらの廃止予定機能に依存していれば、リリース直後から「1年以内に作り直しが必要な負債」を抱えて本番に上げることになります。とくにLoggingは、監査・インシデント対応・内部統制の土台に関わるため、廃止方針に沿った観測基盤（OpenTelemetry等）を最初から前提に置けるかがベンダーの力量の見極めどころです。

セキュリティ境界の責任が開発者側へ移る、という論点（二次情報）

安全のしくみがプロトコルからアプリへ移ることの影響について、複数のセキュリティ媒体が分析を出しています。セキュリティ企業のAkamaiは、新仕様が過去のリスク（プロトコルレベルのセッション乗っ取り、想定外のサーバー側プロンプト、弱い認証方式など）を消す一方で、永続セッションの代わりに導入される「サーバーがクライアントへ渡す識別子・状態オブジェクト」が新たな攻撃面になり得ると指摘していると報じられています（Akamaiブログ、およびSecurityWeek、SiliconANGLE等の報道）。具体的には、識別子が推測可能だと、(1)進行中のワークフローの乗っ取り、(2)別エージェントに属するデータへのアクセス、(3)テナントをまたぐ不正な操作、の3つが懸念点として挙げられています。

SecurityWeek等の報道は、これらを「プロトコルが担保していたセキュリティ判断が、MCPサーバー開発者・プラットフォーム運用者へますます委ねられる」という文脈で整理しています。これは本記事の結論と一致します。ここで示した懸念点は一次仕様そのものではなく二次分析であり、媒体名を明記しています。実際の自社影響は、使うライブラリ・実装・運用によって変わるため、断定せず、自社の構成に当てはめて確認してください。セキュリティ境界の再点検を独立した視点で行いたい場合は、生成AI時代のセキュリティ設計・境界の見直しの観点から論点を洗い出すのが有効です。

旧仕様前提の納品物が「1年で負債化」する具体的な道筋

なぜ「1年で負債」という表現になるのかを、段階で示します。

発注時：仕様版を指定しないまま「MCP対応」で発注する。ベンダーは手慣れた旧仕様（2025-11-25）や、廃止予定のRoots・Sampling・Loggingで実装する。
納品時：機能は動く。受け入れ検査は「動くか」を見るため合格する。安全の作り込みや仕様版は検査項目に入っていない。
数ヶ月後：新仕様に沿ったクライアント・SDK・周辺ツールが主流化し、旧前提の実装が周辺と噛み合わなくなる。認可の厳格化（iss 検証等）に対応していない部分が監査やベンダーセキュリティ評価で指摘される。
1年前後：廃止予定機能の削除時期が近づき、監視・ログ・認可の作り直しが必要になる。当初の見積もりに入っていない追加費用として跳ね返る。

この道筋の分岐点はすべて「発注時」にあります。仕様版・認可設計・廃止機能への依存を発注前に固定できていれば、多くは避けられます。逆に、ここを曖昧にしたまま安さや速さで選ぶと、負債化は構造的に起こります。発注準備そのものを点検したい場合は、AI導入・要件整理の第三者セカンドオピニオンを挟むと、提案書の抜けを早期に見つけやすくなります。

発注前チェックリスト（コピーして使える）

このチェックは「技術の正解」を発注側が判定するためのものではありません。ベンダーがこれらに即答できるか、資料で示せるかを見ることで、力量と誠実さを間接的に測るためのものです。答えに詰まる、はぐらかす、という反応そのものが判断材料になります。

ベンダーへの質問テンプレート

そのまま提案依頼や面談で使える質問です。

「今回作るAIエージェント／MCPサーバーは、どの仕様版（2026-07-28 か旧版か）に準拠しますか。理由も含めて教えてください。」
「Roots・Sampling・Loggingのいずれかに依存していますか。依存している場合、廃止時の移行計画と費用は誰が負担しますか。」
「状態管理はステートレス前提ですか。ハンドル（識別子）はどう発行し、推測や乗っ取りをどう防ぎますか。」
「認可はOAuth／OpenID Connectのどの要件に対応していますか。iss 検証など新仕様の認可強化に追随する計画はありますか。」
「監査・インシデント時に、どのログでAIエージェントの操作を追跡できますか。廃止予定のLoggingに頼っていませんか。」
「正式版が7月28日に公開された後、差分への追随はどの範囲まで無償で、どこから追加費用ですか。」
「本番で問題が起きたとき、誰が・どの手順で停止し、どの鍵を失効しますか。」

これらは正解を暗記しているかを問うのではなく、設計思想と責任分界を言語化できるかを見る質問です。

見積もりの読み方：MCP案件で見るべき欄

「MCP対応」とだけ書かれた行：どの仕様版・どの認可方式か不明なら、内訳を必ず問い直す。一括りの一行見積もりは後の追加費用の温床。
認可・権限設計の工数：ここが極端に小さい見積もりは、安全の作り込みを省いている可能性。安さの理由がここにあることが多い。
仕様追随・保守の欄：正式版公開後の追随や、廃止機能対応が「別途」なのか「含む」のかで、1年後の総額が大きく変わる。
ログ・監視の項目：観測基盤（OpenTelemetry等）が計上されているか。無ければ監査・障害対応の土台が薄い。
停止・復旧・鍵管理：運用の安全網が見積もりに存在するか。見えないなら運用フェーズで跳ねる。

金額の高低よりも、「何が含まれ、何が別途か」の線引きを読むことが、この種の案件では効きます。第三者の目で見積もりの前提を点検したいときは、見積もりのセカンドオピニオン相談を早い段階で挟むと、後戻りの費用を抑えやすくなります。

FAQ

Q1. 新仕様2026-07-28はもう使えますか。 A. 執筆時点（2026年7月23日）では正式版は未公開で、確定しているのはリリース候補です。7月28日に正式リリース予定と告知されていますが、最終版で細部が変わり得るため、契約前に一次で最終確認してください。

Q2. 旧仕様で作ったMCP実装はすぐ動かなくなりますか。 A. すぐには動かなくなりません。廃止対象のRoots・Sampling・Loggingは「注記のみの廃止」で、最低12ヶ月は動作するとされています。ただし将来削除の予告なので、依存していれば移行計画は必要です。

Q3. ステートレス化で何が良くなりますか。 A. どのサーバーインスタンスでもリクエストを受けられるため、負荷分散や多重化がしやすく、インフラを簡素化できる利点が公式に示されています。一方で状態管理の安全設計はアプリ側の責任になります。

Q4. 認可の強化で発注側がやることは増えますか。 A. 直接コードを書くわけではありませんが、「認可がOAuth／OIDCに整合しているか」を発注要件として指定し、受け入れ検査に含める判断は発注側の役割です。ここを空欄にすると品質のばらつきが出ます。

Q5. 「MCP対応」と書かれた提案は信用してよいですか。 A. その一言だけでは判断できません。仕様版・認可方式・廃止機能への依存・ログ設計を確認して初めて中身が分かります。本記事の質問テンプレートで具体化してください。

Q6. セキュリティの懸念は誇張ではないですか。 A. 一次仕様は安全性を高める改訂です。ただしAkamai等の二次分析は、識別子の作りによっては新たな攻撃面が生まれ得ると指摘しています。自社の実装・運用に当てはめて確認する姿勢が現実的です。

Q7. 今あるPoCは作り直しになりますか。 A. 一概には言えません。廃止機能への依存度、認可設計、状態管理の作りによります。まず現状の棚卸しを行い、負債化する箇所だけを特定するのが費用対効果の高い進め方です。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、本番投入や追加発注の前に、第三者の点検を挟む価値があります。

ベンダー提案に「MCP対応」とあるが、仕様版・認可・廃止機能への依存を自社で判定できない。
すでにMCPを使ったPoC・開発を発注済みで、新仕様で負債化しないか不安がある。
認可・ログ・停止手順といった「安全の作り込み」が見積もりに含まれているか読み取れない。
情シスが手薄で、技術的な当否を社内だけで検証する自信がない。

GXOは、特定ベンダーの製品を売り込む立場ではなく、発注側の判断を整理する第三者として、要件・認可設計・見積もりの前提を点検します。AIエージェント発注前の論点整理はAIエージェントの発注前チェック・権限設計相談、導入判断そのものの棚卸しはAI導入の第三者セカンドオピニオン、セキュリティ境界の見直しはセキュリティ設計の点検を起点にしてください。具体的な案件について相談したい場合は発注前相談・お問い合わせからご連絡ください。

新仕様は正式版がこれから公開される段階です。だからこそ、まだ発注書に線を引ける今が、1年後の負債を避ける最も安いタイミングです。