2026年7月改訂のMCP仕様｜ステートレス化と機能申告の必須化を読み解く

• Facebook
• X(旧:Twitter)
• はてブ
• LINE

2026年7月28日のMCP仕様改訂で、自院の既存サービスについて先に確かめたいのは、対応する版と通信の作り直しが及ぶ範囲です。要求ごとに必要な情報を渡す形への変更と、提供側による機能申告の必須化が判断の軸になります。

改訂の発表だけを理由に、医院のホームページ全体を作り直す判断はできません。月額で保守を依頼しているなら、現在の仕組みが何に依存し、改訂対応がどの作業に当たるのかを制作会社から書面でもらう順番です。

この記事では、MCPの2026年7月改訂が運用に与える影響と、既存サービスの更新前に確認する項目をまとめています。

MCPの仕様改訂は、まず対応版の確認から

確認の出発点は「MCP対応」という表示ではなく、実際に利用している仕様の版です。今回の版を示す文字列は2026-07-28で、直前の版は2025-11-25です。

更新日と仕様の版を分けて読む

サービスのお知らせが2026年7月以降に更新されていても、それだけで2026-07-28版への対応を示すわけではありません。案内文を直した日と、通信の約束を切り替えた日は別々に確認する必要があります。

制作会社への質問では「今回の改訂に対応していますか」に加えて、稼働中の版の文字列を回答に含めてもらうと対象が定まります。更新予定の説明なら、現在利用中の版と切り替え先の版を分けた回答が判断材料です。

変更の中心は要求の独立と機能申告

ステートレスとは、前のやりとりで作った通信上の状態に頼らず、個々の要求が必要な情報を持っている形です。今回の改訂では接続開始時の初期化の往復を廃止し、要求ごとに版や利用側の機能を渡す形へ変更されました。

機能申告では、提供側が対応版や機能などを返すための問い合わせ口を備える義務が加わっています。通信の続け方が変わる点と、対応内容を問い合わせられる点を分けると、更新に必要な作業と確認に使える情報を整理できます。

技術更新と投資判断の順序

今回の改訂対応に見積もりが出たら、最初に確認するのは、既存のどの処理を新しい通信方式へ合わせる作業なのかです。「AI経由の集患に必要」という説明だけでは、今回の変更との対応関係が分かりません。

追加の支払いが気になるのは自然です。作業対象と完了条件が示されれば、契約中の保守で扱う更新なのか、個別に依頼する改修なのかを具体的に相談できます。

来院数を増やす投資として検討する際も、仕様への適合を確かめる資料と、期待する成果の説明は分けて受け取るのが適切です。

ステートレス化でMCPの運用はどう変わる？

要求を毎回独立して処理できるため、同じ接続先が前のやりとりを覚えている前提が減ります。運用上の変化は、複数の処理先への振り分けと、途中で切れた要求の扱いに表れます。

同じ処理先へ戻る前提が減る

従来の通信上のセッション、つまり一連のやりとりをまとめて扱う状態は、今回の版で削除されました。要求を処理する側が前回と変わっても、その要求に含まれる情報で対応できる形へ寄せられています。

たとえば、複数の処理先へ順番に要求を振り分ける運用でも、通信上の状態を共有する保存場所に頼らず扱える設計です。運用を委託している医院では、現在の振り分け方が旧来のセッションに依存しているかを担当会社へ確かめる意味があります。

ただし、これは改訂が許す設計の説明です。利用中のサービスが既にその設計へ移行したかは、個別の対応状況で判断します。

業務上の続きは引き継ぎ用の情報で渡す

ステートレス化は、複数回の要求を通して続く処理まで一律に捨てるという意味ではありません。処理をまたいで状態が必要なら、提供側が発行した引き継ぎ用の識別情報を、操作に渡す通常の引数として受け渡す形になります。

引数は、操作を依頼するときに一緒に渡す指定内容です。既存の処理が「前回の続き」を接続状態だけで判断していたなら、新方式でその続きがどう指定されるのかが改修の確認点になります。

保存済みの情報が消えるかどうかを、ステートレスという言葉だけで推測せず、変更される保存対象を担当会社に明示してもらいましょう。

応答が途切れた後は新しい要求になる

応答を連続して受け取る途中で通信が切れた際に、以前の位置から再開する仕組みとメッセージの再送は削除されました。途切れた要求は失われ、新しい要求ID、つまり要求を区別する番号を付けて出し直す扱いです。

そのため、改修の説明には正常に応答した場面だけでなく、途中で切れた後の動作も含める必要があります。旧来の再開を前提とする処理が残っていないかと、出し直しをどの部分が担うかを確認できます。

業務上の操作を含むサービスなら、同じ操作を出し直した際の扱いも合わせて尋ねると、利用時の混乱を減らす確認につながります。これは新仕様に適合したという回答だけでは決まらない運用上の確認事項です。

MCPの機能申告で確かめられる範囲

提供側には、対応する仕様の版と機能、身元を申告する問い合わせ口の実装が必須になりました。問い合わせへの応答を確認すれば、広告や説明資料とは別に、その接続先が申告している内容を受け取れます。

必須なのは提供側の問い合わせ口

新設された機能問い合わせは、提供側の対応内容を取得する要求です。提供側はこの要求に応じる仕組みを実装しなければならず、今回の「必須」はこの義務を指しています。

一方、利用側がほかの要求より前に問い合わせるかどうかは任意です。接続のたびに必ず自動確認が走るという説明や、すべての利用側に事前照会が義務付けられたという説明とは区別する必要があります。

医院側が確認を依頼するときは、問い合わせ口への対応の有無と、実際の利用環境でその照会を行っているかを別々に質問できます。

対応版・機能・身元が照会の対象

申告される内容は、どの仕様の版でやりとりできるか、どの機能に対応するか、どの提供元の実装かを確かめる材料になります。制作会社からは、接続先に照会した結果を医院側でも読める説明にして受け取ると検討しやすくなります。

ただし、申告は接続先が返す情報であり、それを受け取るだけで医院の利用目的を満たしたと判断するのは早計です。申告された機能を使った動作の確認まで示されれば、説明と実際の利用場面を結び付けられます。

中核以外の拡張も申告の対象へ

提供側と利用側の機能情報には、中核の仕様以外に対応する拡張を宣言する欄が追加されました。拡張は標準の中核部分に加える機能なので、何を追加しているのかを分けて確認するのが実用的です。

独自の拡張を使う提案なら、相手側もその拡張に対応しているかを含め、必要な組み合わせを説明してもらいます。中核部分だけで動く処理と追加の対応が要る処理を分けると、更新後に確認すべき対象が絞れます。

機能申告の義務化から直接読み取れるのは、提供側が対応内容を返す窓口を持つという点までです。実際に採用する拡張や照会の使い方は、サービスの説明で補う部分になります。

既存サービスの改修は依存箇所で決まります

「対応済み」のサービスでも、旧仕様に依存する部分があれば今回の版への移行で改修が生じます。医院ごとの作り直しの範囲は、以前の通信方式や接続の管理をどこで使っているかによって変わります。

接続開始の初期化が残っている部分

旧版の接続開始時に行っていた初期化の要求と完了通知は、新しい版では廃止されています。最初にまとめて取り決めた内容を後続のやりとりが参照する作りなら、各要求に必要な情報を載せる作りへの変更が対象です。

要求ごとに載せる情報には仕様の版と利用側の機能が含まれ、相手が扱えない版なら非対応を示すエラーを返します。更新後に接続できない場面を調べるには、どちらがどの版を指定し、どちらが受け付けたかを確認する必要があります。

画面を変更する作業と通信部分の変更を同じ項目にまとめず、旧方式のどの依存を解消する見積もりなのかを記してもらうと範囲が明確です。

削除済みと非推奨の区別

削除された仕組みは今回の版の移行先として残せる機能ではなく、非推奨は仕様に残っていても新規実装で採用しない扱いです。両者を一括して「古い機能」と説明すると、すぐ置き換える部分と移行を計画する部分が混ざります。

非推奨の方針では、機能の状態を有効・非推奨・削除済みの3段階とし、非推奨の期間を最低12か月設けています。この期間を、今回すでに削除された仕組みを新しい版でも使い続けられる猶予と読まないよう注意が必要です。

非推奨の一覧には Roots・Sampling・Logging などが含まれます。

開発用の部品更新だけで完了かを確かめる

SDKは、接続機能を開発する際に使う部品をまとめたものです。今回の移行には以前の作りと互換性を保てない変更が含まれるため、部品の対応状況と、自院が使うサービス全体の移行完了を分けて判断します。

制作会社が「部品は対応済み」と回答したら、自院向けの処理も変更済みなのか、検証用の環境で確認した段階なのかを補ってもらいます。部品の更新に伴って直した場所が示されれば、個別の作り込みが改修対象に含まれているかも分かります。

また、接続する相手との組み合わせで動作を確認した結果があれば、単体で動いたという説明より、医院が利用する状況に近い判断材料になります。

一覧情報と中継の変更も運用確認に含める

接続開始の廃止だけで改訂対応を終えたと判断せず、一覧情報の保持と通信を中継する部分も確認対象に含めます。利用できる機能を表示する処理や、要求を処理先へ振り分ける部分に関わる変更です。

一覧を保持する時間と範囲

一覧系の結果には、保持できる時間と保持の適用範囲を示す情報が必須になりました。利用側はその情報を使って一覧を手元に保持できるため、取得した一覧をいつまで使う設計かが運用の確認点になります。

保持時間はミリ秒単位の値で示され、適用範囲は公開扱いか個別扱いかに分けられます。医院側は数値の細かな決め方よりも、機能の構成を更新した際に古い一覧がどの扱いになるかを説明してもらう方が判断に結び付きます。

この情報は一覧を保持するための指定です。院内で扱うあらゆる情報の保存期間を一括して定めたものと解釈すると、確認対象がずれてしまいます。

接続ごとの一覧変更を前提にしない

プロトコル、つまり通信の約束の階層からセッションが削除され、操作などの一覧は接続ごとに変わらない形になりました。旧方式で接続の状態に応じて一覧を変えていた部分があれば、その前提を見直す対象です。

利用できる機能の選択画面を備えるサービスなら、更新前後で何を取得し、その結果をいつ表示へ反映するのかを確認します。医院向けに提供する機能を変更したときの扱いを具体例にすれば、一覧取得と画面表示の関係が伝わりやすくなります。

一覧の取得に成功したという結果だけで終えず、保持された一覧を使ったときにも意図した機能を選べるかが確認の焦点です。

中継部分への追加項目

HTTPを使うストリーミング方式では、要求に処理の種類と対象名を示すヘッダーが必要になりました。ヘッダーは通信本文に添える情報で、中継する仕組みが本文のデータを読み解かずに要求を振り分けるために使えます。

自院の構成に中継が含まれるなら、追加項目を受け渡す変更が必要かを担当会社へ確認する対象になります。通信の送り手だけを更新しても、中継部分を含めて必要な情報が届いているかという確認は別に残ります。

個別の構成が不明な段階で中継の作り直しを断定せず、見積もりでは影響の有無と、その判断理由を分けて受け取ると過不足を判断しやすくなります。

改訂対応の発注前に必要な回答は何ですか？

発注前に必要なのは、対応版、変更対象、移行完了を確かめる条件が結び付いた回答です。改訂項目の名称だけを並べた説明より、現在の構成に対してどの作業が生じるのかが判断に役立ちます。

現在と移行先を同じ書面に残す

制作会社への確認は、現状と変更後を同じ書面に置く形にすると説明の食い違いを減らせます。版が不明なまま更新日だけを決めず、現在使っている仕組みと移行先の仕様を対応させるところから始めましょう。

• 対応版 … 稼働中の版と移行先の版
• 依存箇所 … 初期化やセッションに頼る既存処理
• 変更対象 … 通信部分・個別処理・中継部分の改修範囲
• 申告内容 … 対応版と機能を問い合わせた結果

回答に未確認の項目が残るなら、推定で埋めるより、確認担当と回答予定を付けてもらう方が実務的です。新仕様の説明と自院の調査結果を分けて記載すれば、どこまで確認済みかが書面に残ります。

完了条件を正常時と中断時で分ける

改修の完了条件は、正常な応答だけでなく、版が合わない場面や応答が途切れる場面にも割り当てます。今回の変更で動作の前提が変わる箇所を確認対象にすれば、一般的な「動作確認済み」より具体的な報告を受け取れます。

• 通常の要求 … 指定した版と機能の情報を伴う応答
• 非対応の版 … 版が合わない旨を返す動作
• 応答の中断 … 新しい要求として出し直す扱い
• 一覧の保持 … 保持時間と適用範囲を踏まえた利用

検証結果は、実施した条件と確認した結果を対にして受け取るのが基本です。医院の利用対象に含まれない機能まで一律に試すのではなく、既存処理の依存箇所と今回の追加要件に対応させます。

保守の対象と個別改修を照合

見積もりを確認する際は、仕様への追従として扱う作業と、導入先ごとの処理を書き換える個別改修を分けて確認します。一般的な費用構成では、保守契約に含まれる作業と追加費用が生じる作業の範囲が確認点となり、改訂があったという理由だけでは追加費用の対象を決められません。

そのため、着手前の書面には作業対象に加え、切り替えの予定と移行完了の条件を含めると判断しやすくなります。「全面更新が必要」という提案には、残せない既存部分と、その根拠になる削除・変更項目を対応させた説明を求められます。

まず現状の版を確定し、依存箇所の調査から改修範囲を絞り、動作を確かめる条件がそろってから発注を判断する順序です。

よくある質問

• Facebook
• X(旧:Twitter)
• はてブ
• LINE