投稿者 投稿日: カテゴリー EC×AI活用
MCP 2026-07-28とは、AI連携をステートレス化した新仕様のことです。
2026年7月28日に公開されたこの仕様で、initializeとinitializedのやり取りとMcp-Session-Idヘッダーが正式に廃止されました。セッションIDを前提に組んだ社内連携は、そのままでは新しいSDKに乗り換えられません。在庫数の取得、受注データの読み出し、商品マスタの更新をAIエージェント経由で回している店舗にとっては、動いている仕組みが止まるかどうかの分岐点です。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、何が壊れるのか、いつまでに何を確認すべきかを7項目のチェックリストに落として解説します。
移行の締め切り感覚を先に共有します。旧仕様がいきなり動かなくなるわけではありません。今回の仕様には12か月の最低猶予を定めた正式な廃止方針が入ったため、Roots、Sampling、Logging、そして従来のHTTP+SSEトランスポートは少なくとも1年は動きます。ただしSDKを更新した瞬間に壊れる箇所があるので、更新前の棚卸しが必要です。
セッションが消えたことで何が変わったのか
今回の変更の中心は、双方向で状態を保つプロトコルから、リクエストとレスポンスで完結するステートレスなプロトコルへの転換です。Model Context Protocol公式ブログによると、Tier 1のSDKは月間で5億回近いダウンロードがあり、TypeScriptとPythonのSDKは累計10億ダウンロードを超えました。それだけの規模で使われている土台の、接続の作り方そのものが変わったことになります。
具体的には、リクエストが1本ずつ自己完結する形になりました。プロトコルのバージョン、クライアントの識別情報、クライアントの機能宣言は、すべて各リクエストの_metaに入って運ばれます。サーバーの機能を先に知りたいクライアント向けにはserver/discoverという新しいRPCが用意されましたが、これは必須ではありません。結果として、ラウンドロビン方式のロードバランサーの背後にある、どのサーバーインスタンスにリクエストが着地しても処理が通ります。共有ストレージでセッションを持ち回る必要がなくなったわけです。
サーバーからクライアントへ問い返す仕組みも作り直されました。従来のelicitation/create、sampling/createMessage、roots/listは、ストリームを開いたままにしておく前提でした。新仕様ではMulti Round-Trip Requests（MRTR）が代わりに使われます。サーバーはresultType: "input_required"と必要な問い合わせを返し、クライアントは回答をinputResponsesに添えて元の呼び出しをやり直します。ユーザーへの確認が必要な処理、たとえば「この在庫更新を本当に実行しますか」という確認を、ストリームを維持せずに実現できる形です。
ルーティングの層も具体的に変わりました。Streamable HTTPのリクエストにはMcp-MethodとMcp-Nameのヘッダーが必須になりました。ゲートウェイやレート制限装置、WAFは、JSONの本文を解析せずにヘッダーだけでルーティングと認可の判断ができます。加えてtools/list、prompts/list、resources/list、resources/readの応答にはttlMsとcacheScopeが付き、順序も決定的になりました。ツールのカタログをクライアント側でキャッシュでき、再接続をまたいでも上流のプロンプトキャッシュが崩れにくくなります。
認可の作り込みも進みました。認可サーバーはRFC 9207に沿ってissパラメータを返すべきとされ、クライアントは認可コードを引き換える前にこれを検証しなければなりません。認可サーバーの取り違えを突く穴が閉じます。動的クライアント登録（DCR）は正式に非推奨となり、Client ID Metadata Documents（CIMD）へ寄せる方針が示されました。DCRは後方互換のために動きますが、将来の版で削除されます。EntraやOktaのような社内の認証基盤とつなぐ際の回り道が減る変更です。
日本のEC事業者の現場で何が止まりうるか
止まるリスクが最も高いのは、セッションIDを前提に設計した自社ラッパーです。楽天RMSやAmazonセラーセントラルのAPIを叩く社内MCPサーバーを内製し、Mcp-Session-Idで認証済み状態を保持していた場合、そのヘッダーは新仕様に存在しません。SDKを更新するとセッション管理のコードは軒並み書き換え対象になります。公式ブログも、セッション識別子に依存していた開発者には移行コストが発生すると明記しています。
対処の方向は仕様側で示されています。アプリケーションが呼び出しをまたいで状態を持ちたい場合は、ツールから明示的なハンドル（識別子）を発行し、モデルにそれを引数として渡し戻させる設計にします。トランスポートの裏に隠れたセッション状態より、モデルが見える形でハンドルを引き回すほうがうまく機能する、という判断です。受注データの読み出しからCSV生成、アップロードまでを数ステップで回す業務では、「作業ID」を最初のツールで発行して以降の呼び出しに渡す形が素直です。
第二の影響は、ホスティングの選択肢が広がることです。MCPサーバーが普通のHTTPワークロードになったため、サーバーレスやエッジ環境に置けます。CloudflareのAgents SDKは初日から対応し、Workers上でMCPサーバーを動かせるとしています。Amazon Bedrock AgentCoreでもステートレスなコアが使えるようになりました。常時起動のサーバーを1台維持していた社内連携を、リクエスト課金の環境へ寄せる余地が出てきます。月額数千円のVPSを1台立てていた規模なら、費用そのものは大きく変わりませんが、深夜のバッチ時だけ負荷が跳ねる構成では従量課金のほうが総額を抑えやすい設計になります。
第三は、ツールカタログのキャッシュが効くことによる応答改善です。商品マスタ更新のような定型作業でツール一覧を毎回取り直していた構成では、ttlMsを尊重するクライアントに切り替えるだけで往復が減ります。数値の改善幅は環境依存なので、自社で計測するのが前提です。参考として、mcp-useを提供するManufactは新しいSDK v2でパッケージサイズを約83%削減し、25%高速化したと述べています。これは同社の事例であり、自社構成での再現性は要確認です。
第四に、承認フローを組み込みやすくなりました。Supabaseは、ステートレス運用ゆえに見送っていた確認ダイアログをMRTRで実装できるようになったとしています。データを消すクエリや新規プロジェクト作成のコストを、実行前にユーザーへ確認する用途です。EC業務に置き換えると、価格の一括更新や在庫のゼロ設定といった、間違えると売上に直撃する操作の前に人の承認を挟む仕組みが標準的に書けます。権限設計の考え方はAIエージェントの権限設計と封じ込めアーキテクチャの当てはめ方で整理しています。あわせて読むと、どこに承認を置くかの線引きが決めやすくなります。
現場で繰り返し見るのは、連携の本数が3本を超えたあたりから「誰がいつ作ったか分からないスクリプト」が混ざり始める現象です。今回の仕様更新は、その棚卸しを強制的にやる口実として使えます。
自社でサーバーを持っていない店舗にも、間接的な影響があります。使っているAIツール側がMCP対応を進めていれば、その裏側の仕様が入れ替わるためです。たとえば商品説明文の生成を外部SaaSに任せていて、そのSaaSが在庫データを読み取るためにMCPを使っている場合、SaaS側の移行タイミングで一時的に連携が不安定になることがあります。契約中のツールが今回の仕様に対応するのはいつか、旧仕様のまま据え置くのか、サポート窓口に1行で聞いておくと、原因不明の不調に振り回されずに済みます。Anthropic側では、社内ネットワーク内のMCPサーバーを公開せずにClaudeへつなぐMCPトンネルがリサーチプレビューとして案内されており、社外に穴を開けずに社内ツールを渡す選択肢も増えました。受信用のファイアウォール設定や公開エンドポイント、送信元IPの許可リストを用意しなくてよいという設計です。
もう一つ実務で見ておきたいのは、監視の粒度が上がることです。Mcp-MethodとMcp-Nameがヘッダーに出るため、どのツールがどれだけ呼ばれたかをアクセスログの集計だけで把握できます。honeycomb.ioは月間の対話型クエリのうち約20%がエージェント経由になったと述べており、呼び出し元がAIかどうかを分けて数えられる状態は、費用の按分や異常検知の前提になります。EC運営に置き換えると、「在庫参照ツールが深夜に想定の10倍呼ばれている」といった異常を、コードを読まずに気付ける状態です。
移行チェックリスト7項目と検証プロンプト5本
先に結論を書くと、確認すべきは7項目です。順番どおりに潰していけば、SDK更新でつまずく箇所はほぼ洗い出せます。
第1項目は、社内で動いているMCPサーバーとクライアントの一覧化です。誰が作り、どのAPIを叩き、どの業務に使っているかを1行ずつ書き出します。第2項目は、Mcp-Session-Idやinitializeへの依存箇所の特定です。コード検索で該当する文字列を洗い、ヒット数を記録します。第3項目は、elicitationとsamplingとrootsの利用有無の確認です。使っていればMRTRへの書き換え、または非推奨のまま12か月以内に置き換える計画が必要です。
第4項目は、認可周りの点検です。DCRを使っているならCIMDへの移行計画を立て、issの検証が入っているかを確認します。第5項目は、ゲートウェイやWAFの設定でMcp-MethodとMcp-Nameのヘッダーが通るかの確認です。社内プロキシがヘッダーを落とす設定になっていると通信そのものが失敗します。第6項目は、ttlMsとcacheScopeに対応したキャッシュ方針の決定です。第7項目は、旧HTTP+SSEトランスポートの利用箇所と、その置き換え期限の記録です。
以下のプロンプトは、この7項目を進める際に使えるものを5本用意しました。ChatGPT、Claude、Geminiのいずれでも動きます。2026年7月時点の主要モデルは、ClaudeがOpus 5とFable 5、ChatGPTがGPT-5.6のSol・Terra・Luna、Geminiが3.6 Flashです。コードの読み解きは長いコンテキストを扱えるモデルのほうが安定します。
（用途：連携棚卸しの雛形づくり）
プロンプト1：社内MCP連携の棚卸し表を作る
あなたは日本のEC事業者の社内システムを整理するテクニカルディレクターです。
以下の情報から、MCP連携の棚卸しリストを作ってください。
出力する項目：
1. 連携名
2. 接続先（楽天RMS / Amazon SP-API / Shopify Admin API / 自社DB など）
3. 使っている業務（在庫更新・受注取込・商品登録・レポート生成など）
4. 想定される停止時の業務影響（大・中・小と理由を1行）
5. セッション依存の可能性（高・中・低）
前提情報：
- 連携の概要：{箇条書きで貼る}
- 使用SDK：{TypeScript / Python / Go / C#}
- 稼働環境：{VPS / クラウド / 社内サーバー}
影響度が大のものから並べ、最後に「最初に着手すべき3本」を理由付きで示してください。
（用途：コードのセッション依存箇所を洗う）
プロンプト2：セッション依存コードの検出と書き換え方針
あなたはMCPサーバーの実装レビュアーです。
以下のコードについて、MCP 2026-07-28 仕様への移行で修正が必要な箇所を指摘してください。
チェック観点：
1. initialize / initialized のやり取りへの依存
2. Mcp-Session-Id ヘッダーの生成・保存・参照
3. サーバー側で保持している接続単位の状態
4. elicitation / sampling / roots の利用
5. HTTP+SSE トランスポートの利用
出力形式：
- 該当行の引用（3行以内）
- なぜ問題になるか（1〜2文）
- 書き換え方針（ツールから明示的ハンドルを発行する形に寄せる案を優先）
コード：
{ここに貼る}
（用途：状態の持ち回りを再設計する）
プロンプト3：セッションを使わない状態設計に置き換える
あなたはEC業務の自動化を設計するアーキテクトです。
セッションを使わずに、複数ツール呼び出しをまたいで状態を引き回す設計案を出してください。
業務の流れ：
{例）受注CSVを取得 → 出荷可否を判定 → 出荷指示CSVを生成 → アップロード}
条件：
1. 最初のツールで作業ハンドル（作業ID）を発行する
2. 以降の各ツールはハンドルを引数で受け取る
3. ハンドルの有効期限と失効時の挙動を決める
4. 途中で失敗した場合のリトライ方針を書く
出力：ツール名・入出力・ハンドルの受け渡し順を、番号付きの手順として提示してください。
（用途：承認を挟む箇所を決める）
プロンプト4：MRTRで人の承認を挟む箇所を設計する
あなたはEC運営のリスク管理担当です。
以下の自動化処理のうち、実行前に人の確認を挟むべき操作を選び、確認文の文面まで作ってください。
処理一覧：
{例）価格一括更新、在庫ゼロ設定、商品削除、レビュー返信の一括送信、クーポン発行}
出力する項目：
1. 確認を挟むべきか（挟む・挟まない）と判断理由
2. 挟む場合の確認文（80字以内、影響範囲と件数が分かる文面）
3. 誤って実行された場合の復旧手順の有無
判断基準：売上への直接影響、取り消しの可否、影響件数の3点で評価してください。
（用途：移行計画を日付に落とす）
プロンプト5：12か月の猶予を前提に移行計画を作る
あなたはEC事業者のプロジェクトマネージャーです。
MCP 2026-07-28 への移行計画を、月単位のスケジュールに落としてください。
前提：
- 非推奨機能（Roots / Sampling / Logging / HTTP+SSE）は最低12か月は動く
- 現在の連携本数：{本}
- 対応できる工数：月{時間}
- 繁忙期：{月}
出力：
1. 月ごとの作業内容（着手・検証・本番切替を分ける）
2. 繁忙期に本番切替を置かない配置
3. 各月の完了判定条件（何をもって終わったとするか）
4. 最後に「今週やること」を3つ
つまずきやすい3つのパターンと回避策
1つ目は、SDKを先に更新してしまうパターンです。棚卸しの前に依存を上げると、動かない箇所と原因の切り分けに時間を取られます。検証環境で新SDKを入れ、本番は据え置いたまま差分を洗うのが順序として安全です。
2つ目は、非推奨と廃止を混同するパターンです。RootsやSamplingは非推奨になりましたが、少なくとも12か月は動きます。逆にinitializeとMcp-Session-Idは今回で退役しています。「非推奨だから今すぐ全部書き換える」と決めると工数が跳ねますし、「まだ動くから何もしない」と決めるとセッション依存で足元が崩れます。区別して扱うことが必要です。
3つ目は、ゲートウェイ設定の見落としです。社内プロキシやWAFが未知のヘッダーを落とす設定になっていると、Mcp-MethodとMcp-Nameが届かず、原因の分かりにくい失敗になります。ネットワーク担当と一緒に、ヘッダーの通過を先に確認しておくと後戻りが減ります。
4つ目として、承認の入れ方を間違えるパターンも挙げておきます。MRTRで確認を挟めるようになったからといって、すべての操作に確認を付けると担当者が確認ボタンを押すだけの作業に変わり、内容を読まずに承認する習慣ができます。アパレル系の単一店舗で試したケースでは、1日20件を超える確認が飛ぶ設計にしたところ、3日目には全件即時承認になっていました。承認を挟むのは、取り消しが効かない操作と、影響件数が一定数を超える操作の2種類に絞るのが実務的です。件数のしきい値は、価格更新なら10件、在庫更新なら50件あたりから調整を始めるとおさまりが良くなります。
工数とコストの目安
工数は連携の本数と実装の素直さで決まります。店舗運営の現場感覚では、社内MCP連携が3本以内でセッション状態を持たない素直な実装なら、棚卸しから検証までで10〜16時間程度が目安です。セッションIDで認証状態を持ち回している実装が混ざると、1本あたり8時間前後の追加を見込むほうが安全です。いずれも自社構成に依存する概算値であり、確定にはコードの実査が必要です。
工数の見積もりで抜けやすいのが、検証のための業務データの準備です。受注や在庫を扱う連携は、本番データをそのまま検証環境に流せないケースが多く、匿名化したサンプルを用意する手間が別途かかります。直近の支援案件で観測したのは、コードの書き換えより検証データづくりに時間を取られる構図でした。件数を絞った検証用CSVを作業の最初に用意しておくと、以降の確認が数分単位で回ります。
外部費用の面では、サーバーレスへの移し替えを同時に行う場合の試算が必要です。常時起動のVPSを1台（月1,000〜3,000円程度）維持している構成をエッジ環境へ寄せる場合、リクエスト数が少ない社内利用では月数百円規模まで下がるケースもあります。逆に大量のツール呼び出しが走る構成では従量課金が不利になるため、移行前に1か月分の呼び出し回数を数えておくのが判断材料になります。AIモデル側の費用は、GPT-5.6のTerraが入力100万トークンあたり2.50ドル、出力15ドル、Solが入力5ドル、出力30ドルという公開価格です。
この先1年で効いてくる論点
ステートレス化は、AI連携が社内の実験からインフラへ移る節目だと見ています。セッションを持たないHTTPワークロードになったことで、既存のWeb運用の作法がそのまま適用できます。ロードバランサー、レート制限、監視、認証基盤の連携は、いずれもインフラ担当が扱ってきた領域です。AI連携の運用が情報システム部門の日常業務に吸収されていく流れになります。
EC事業者にとっての実利は、外部サービスのMCP対応が広がることにあります。SentryやLinearが初日から新仕様に乗ったように、SaaS側の対応が進めば、自社で作り込む範囲は減ります。国内のカートシステムや在庫管理サービスがMCPサーバーを公式提供するようになれば、自社ラッパーの保守から手を引ける部分が出てきます。現時点で国内主要サービスの対応予定は公表されていないため、この見通しは要確認です。
もう一つの論点は、承認フローの標準化です。MRTRで人の確認を挟む形が一般化すると、「AIに任せる範囲」を仕様として書けるようになります。価格変更は人の承認、レポート生成は全自動、といった線引きをコードの外側に置けるため、担当者が変わっても運用が崩れません。この整理は、UCPへの対応のような外部プロトコル対応と同じ考え方で進められます。
よくある質問
何もしないと自社の連携は止まりますか
セッションIDやinitializeに依存していない実装で、SDKも更新しないなら、すぐには止まりません。旧トランスポートには12か月以上の猶予があります。ただしSDKの更新を止め続けるとセキュリティ修正も受け取れなくなるため、猶予期間内の移行計画は必要です。
移行は自社で対応できますか、外注が必要ですか
社内でMCPサーバーを内製した担当者がいるなら自社対応が現実的です。判断の分かれ目は、セッション状態を持ち回る実装があるかどうかです。該当する場合は状態設計の作り直しになるため、設計レビューだけ外部に頼む形が費用対効果に見合うケースが多く見られます。
新仕様に対応したSDKはどれですか
TypeScript、Python、Go、C#の4つのTier 1 SDKが2026年7月28日時点で新仕様に対応しています。RustのSDKはベータでの対応です。移行時の破壊的変更については、各SDKの移行ノートが用意されています。
Roots、Sampling、Loggingはいつまで使えますか
正式な廃止方針で最低12か月の猶予が定められたため、2027年7月ごろまでは動く見込みです。新規実装で採用すべきではないとされているので、これから作る連携では最初から使わない設計にしてください。
DCRからCIMDへの移行は急ぐべきですか
急ぐ必要はありませんが、計画は立てておくべきです。DCRは後方互換のために動き続けますが、将来の版で削除されます。EntraやOktaのような社内認証基盤とつなぐ予定があるなら、その設計時点でCIMDを前提にするほうが手戻りが少なくなります。
ステートレス化でAIの応答品質は変わりますか
プロトコルの変更なので、モデルの出力品質そのものは変わりません。ただしツール一覧のキャッシュが安定することで、上流のプロンプトキャッシュが崩れにくくなり、同じ作業を繰り返す業務ではトークン消費が下がる可能性があります。改善幅は構成依存のため、自社で計測してください。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Model Context Protocol Blog｜The 2026-07-28 Specification
- Model Context Protocol｜Specification 2026-07-28
- Model Context Protocol｜Full changelog
- Claude｜MCP 2026-07-28 spec: stateless core, coming to Claude
- RFC 9207｜OAuth 2.0 Authorization Server Issuer Identification
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
