MCPのステートレス化とは、AI連携の通信で接続状態を保持しない設計のことです。

事務所で使っている会計ソフトや文書管理ツールをAIとつないでいるなら、その裏側の規格が2026年に組み替えられました。この記事は、変更点そのものの解説ではなく、事務所側で何を確認し、ベンダーに何を聞き、いつ動くかという判断材料を扱います。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、仕様の内容は開発元の公表資料で確認しています。仕様のKey Changesには、前の版である2025-11-25からの主要変更が9項目、細かな変更が12項目挙げられています。

ステートレス化が事務所の運用に効いてくる3つの経路

事務所にとっての要点は、AIとツールの間の通信が「つなぎっぱなし」から「毎回言い切る」形に変わったことです。技術の話に見えて、実際には可用性・ログ・認可という3つの運用面に効いてきます。

第一の経路は、可用性です。MCP公式のKey Changesによれば、Streamable HTTPトランスポートからプロトコルレベルのセッションとMcp-Session-Idヘッダが取り除かれました。あわせて、接続の最初に交わしていたinitializeとnotifications/initializedのやり取りも廃止され、各リクエストが自分でプロトコルバージョンとクライアント能力を持ち回る形になっています。同じ資料は、サーバーがserver/discoverというRPCを実装して、対応するプロトコルバージョンと能力を知らせる仕組みも定めています。事務所目線では、どのサーバーが応答しても同じ結果になる設計に寄ったため、ベンダー側のサービスが落ちにくくなる方向の変更だと読めます。

第二の経路は、ログと通知です。同じKey Changesでは、pingとlogging/setLevel、notifications/roots/list_changedが削除されました。ログの水準は各リクエストの_metaにio.modelcontextprotocol/logLevelとして指定する形になり、この指定が無いリクエストについてサーバーがnotifications/messageを出してはならないと書かれています。加えて、SSEストリームの再開性とメッセージ再送（Last-Event-IDヘッダとSSEイベントID）も取り除かれ、応答ストリームが切れた場合、クライアントは新しいリクエストIDで出し直す形になりました。事務所で、AIがいつ何にアクセスしたかを追う運用をしているなら、記録の取り方がベンダー側の実装に依存する度合いが上がります。

第三の経路は、認可です。同資料の細かな変更として、認可サーバーがRFC 9207に沿ってissパラメータを認可応答に含めることが推奨され、MCPクライアントはissが存在する場合、認可コードを引き換える前に記録済みの発行者と照合することが求められています。さらに、OAuth 2.0の動的クライアント登録（RFC 7591）が非推奨とされ、Client ID Metadata Documentsへの移行が示されました。事務所が独自のID基盤を持たず、各サービスのアカウントで運用している場合でも、ベンダーが認可の作り替えを進める時期に一時的な再認証が発生する可能性があります。

もうひとつ、事務所の担当者が気づきにくい変更があります。Key Changesでは、Roots・Sampling・Loggingの3機能が非推奨に位置づけられました。非推奨になった機能は仕様の中では動き続けますが、新しい実装では採用しない扱いになります。同じ資料は、機能ライフサイクルと非推奨方針として、最低12か月の非推奨期間を定めたとも述べています。この12か月という期間が、事務所側の移行計画を立てるときの時間軸になります。

もう一点、事務所の画面上の体感に関わる変更があります。同じKey Changesでは、サーバー側から追加情報を求める方式が、Multi Round-Trip Requestsという形に置き換えられました。サーバーは追加で必要な情報をInputRequiredResultとして返し、クライアントは元のリクエストを再送する際にその回答を添える、という往復の作りです。あわせて、すべての結果にresultTypeという項目が必須になり、通常の結果はcomplete、追加入力を求める途中の結果はinput_requiredで区別されます。AIが処理の途中で確認を挟んでくる場面の作りが変わったということなので、ツールによっては操作の見え方が変わる可能性があります。

エラーの扱いも整理されました。Key Changesはエラーコードの割り当て方針を定め、JSON-RPCのサーバーエラー領域のうち一定範囲を仕様側で予約したと述べています。事務所の実務で直接触る部分ではありませんが、ベンダーのサポートに問い合わせる際、エラー番号が以前と違う値で表示されることがある、という程度は知っておくと混乱が減ります。

事務所がベンダーに投げる6項目の質問と、AIに任せてよい下ごしらえ

ここからが実務です。事務所側でMCPの実装を書き換えることはまずありません。やるのは、使っているサービスのベンダーに正しい質問を投げて、答えを記録に残すことです。以下の6項目が最小構成です。

第1項目は、対応バージョンの確認です。使っているサービスが2026-07-28に対応済みか、対応予定か、対応しない方針かを聞きます。ここが「未定」で返ってくる場合、その回答自体を記録に残しておくと、後で移行時期を判断する材料になります。

第2項目は、旧トランスポートの扱いです。Key ChangesではHTTP+SSEトランスポートが非推奨として再分類され、Streamable HTTPへの移行が示されています。旧方式のまま運用しているサービスがあるなら、いつまで使えるのかを確認する対象になります。

第3項目は、監査ログの取得方法です。ログの仕組みが変わったため、どの操作が誰の権限で実行されたかを、どの画面でどこまで遡って確認できるのかを聞きます。事務所として答えを持っておきたいのは、顧問先から自分の資料にAIがアクセスしたかと聞かれた場合の返し方です。

第4項目は、再認証のタイミングです。認可の作り替えに伴って再ログインが必要になる時期があるなら、繁忙期を避けたい旨を先に伝えておくと、事務所側の段取りが立てやすくなります。

第5項目は、キャッシュの扱いです。Key Changesでは、tools/listやresources/readなどの結果にttlMsとcacheScopeを持たせるCacheableResultが導入されました。cacheScopeはpublicかprivateかで、共有される中間装置がその応答をキャッシュしてよいかどうかを制御します。顧問先の情報を扱う経路でprivateが選ばれているかは、確認する価値のある項目です。

第6項目は、拡張機能の採用状況です。時間のかかる処理を扱うTasksが公式拡張として整理され、結果にresultTypeという項目が必須になりました。長時間の処理を挟むツール（大量の帳票変換など）を使っている場合、挙動が変わる可能性があります。

この6項目の質問状づくりは、生成AIに下書きさせられる作業です。事務所の使用ツール一覧と、上記の論点を渡して整形させます。

あなたは士業事務所のIT担当者を補助するアシスタントです。
以下の【確認したい論点】をもとに、ベンダー宛の問い合わせメール本文を作成してください。

【当事務所が使っているサービス】
・会計ソフトA（AI連携機能あり）
・文書管理サービスB（AI連携機能あり）
※いずれも架空の名称です。実名は入れないでください

【確認したい論点】
1. MCP仕様 2026-07-28 への対応状況（対応済み／対応予定／対応しない）
2. HTTP+SSEトランスポートを利用している場合の提供終了時期
3. AIからのアクセス履歴を管理画面で確認できる範囲と保存期間
4. 認可方式の変更に伴う再認証の予定時期
5. キャッシュ範囲の設定（公開／非公開）の既定値
6. 長時間処理の扱いに関する仕様変更の有無

【制約】
・ですます調。1通あたり600字以内
・専門用語は括弧書きで一言補足する
・回答期限を押し付ける表現は使わないこと
・当方の環境を特定できる情報（顧問先名・件数）は書かないこと

出力形式：件名／本文

回答が返ってきたら、税理士・弁護士など有資格者本人が目を通す工程を挟みます。ベンダーの回答には「対応予定」「順次」といった幅のある表現が混ざるため、事務所として何を確定情報として扱うかの線引きは、人が決める部分になります。回答の整理そのものは生成AIに任せられます。

あなたは士業事務所の記録係です。
以下のベンダー回答を、事務所の管理台帳に載せる形式へ整理してください。

【入力】
（ここにベンダーからの回答本文を貼り付ける）

【出力する項目】
・サービス名
・MCP仕様2026-07-28への対応状況（確定／予定／未定 のいずれかで分類）
・旧トランスポートの提供終了時期（記載が無ければ「記載なし」）
・アクセス履歴の確認範囲（記載が無ければ「記載なし」）
・再認証の予定時期（記載が無ければ「記載なし」）
・回答日
・確認者欄（空欄のまま出力）

【制約】
・入力に書かれていない内容を補わないこと。推測は禁止
・曖昧な表現（順次、随時、検討中）は原文のまま残し、分類は「未定」にすること
・出力は箇条書きのみ。所感や評価は書かないこと

MCPを事務所のシステム連携にどう位置づけるかという全体像は、MCPで士業事務所のシステム連携を設計する記事で扱っています。仕様公開時点での概要はMCP新仕様2026-07-28の記事にまとめてあり、本記事はその後の実務対応にあたります。

通信の作りが変わっても、守秘義務の見方は変わらない

ステートレス化は通信の設計の話であって、事務所が負っている守秘義務の内容を変えるものではありません。ここを取り違えると、規程の見直しが的外れになります。

守秘義務の根拠は職種ごとに置かれています。弁護士法第23条は秘密保持の権利及び義務の見出しで、弁護士又は弁護士であつた者は、その職務上知り得た秘密を保持する権利を有し、義務を負うと定め、法律に別段の定めがある場合を除く旨を続けています。税理士法第38条は、税理士は正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、又は窃用してはならないと定めています。司法書士法第24条は、司法書士又は司法書士であつた者は、正当な事由がある場合でなければ、業務上取り扱つた事件について知ることのできた秘密を他に漏らしてはならないとしています。社会保険労務士法第21条にも同趣旨の規定があります。条文はいずれもe-Gov法令検索の原文で確認しています。

これらの条文は、どのような通信方式でデータが運ばれるかを問題にしていません。問われているのは、事務所の外へ何が出ていくかです。したがってMCPの仕様変更で見直すのは、規程の本文ではなく、規程が前提としている技術的な確認事項のほうになります。具体的には3点です。

ひとつは、アクセス履歴の記録範囲です。ログの仕組みが変わったことで、これまで取れていた記録が同じ粒度で残るとは限りません。事務所の規程にAIの操作履歴を保存すると書いてあるなら、その実現方法がベンダー側でどう変わったかを確認する必要が出てきます。権限と履歴の設計はAIエージェントの権限管理の記事で整理しています。

ふたつめは、キャッシュ範囲です。共有される中間装置が応答を保持してよいかどうかが仕様上の設定項目になったため、顧問先の情報が通る経路でどちらが選ばれているかは、確認しておきたい項目に上がりました。

みっつめは、認可の主体です。動的クライアント登録が非推奨になったことで、どのアカウントがどのサービスに紐づくかの管理方法が変わる可能性があります。事務所として誰の権限でAIが動いているかを説明できる状態を保つのが、規程の趣旨に沿った運用になります。

規程を書き換えるかどうかの判断も、この整理から出てきます。規程の文言が、事務所が承認したサービス以外に顧客情報を入力しない、といった水準で書かれているなら、通信規格の変更で手を入れる箇所はありません。一方、特定の製品名や特定の認証方式を名指しで書き込んでいる規程は、記述が実態とずれる場面が出てきます。規程は製品名ではなく、承認の手続きと責任者で書いておくほうが長持ちします。

顧問先への説明としては、通信規格の名前を出す必要はほとんどありません。伝えるのは、アクセスできる範囲と、記録が残る範囲と、いつでも止められることの3点です。この3点で説明が成り立てば、規格の版が上がるたびに説明をやり直さずに済みます。

移行対応でつまずきやすい3つの型

ひとつ目は、事務所側が対応を迫られていると誤解する型です。MCPは開発者向けの規格であり、事務所が自前でサーバーを実装していない限り、コードを書き換える場面はありません。にもかかわらず、対応が遅れていると焦って、必要のない設定変更に手を出すと、動いていた連携を壊すことになります。事務所がやるのは、確認と記録です。

ふたつ目は、非推奨と使用不可を混同する型です。Roots・Sampling・Loggingは非推奨に位置づけられましたが、仕様の中では動き続けます。Key Changesは最低12か月の非推奨期間を定めたと述べており、明日から止まるという話ではありません。ここを取り違えると、まだ移行先が固まっていない段階でツールの乗り換えを決めてしまい、かえって業務が止まります。

みっつ目は、確認をした事実が事務所に残らない型です。担当者がベンダーに電話で聞いて、口頭で納得して終わる、というパターンです。半年後に顧問先から質問が来たとき、誰も答えられません。回答をメールで受け取り、台帳に日付付きで残すところまでを1セットにする運用が現実的です。この記録の残し方は、私物端末の利用管理と同じ考え方で、事務所のシャドーAI対策の記事でも扱っています。

対応にかかる工数と、誰が持つか

新たに発生する費用は、事務所側にはほぼありません。MCPの仕様は公開されており、対応するのはサービスを提供するベンダー側だからです。事務所で費用が動くとすれば、既存サービスが対応しない方針を出した場合の乗り換え検討であって、仕様変更そのものへの支出ではありません。

工数として見込むのは、確認と記録の作業です。使っているAI連携サービスが3つ程度の事務所であれば、質問状の作成に1時間、送信と回答待ち、回答の台帳化に1時間、有資格者の確認に30分、という配分に収まることが多いはずです（参考値。サービス数と回答の速さで変わります）。生成AIを質問状の作成と回答の整理に使えば、このうち文章を書く部分が短くなります。

体制としては、IT担当を1名決めて、その人が台帳を持つ形が最小になります（参考。事務所規模により兼務が前提です）。一人事務所の場合は、確認した日付とベンダーの回答をメールフォルダに残しておくだけでも足ります。後から誰が見ても、いつ何を確認したかが分かる状態を作れるかどうかが分かれ目になります。

次の版で論点になりそうなこと

仕様の側に非推奨方針と機能ライフサイクルが定められた点は、事務所にとって扱いやすい変化だと見ています。何がいつまで使えるかが、その場の判断ではなく方針として示されるようになったためです。

一方で、事務所側の運用に残る論点もあります。ログの取り方がベンダー実装に寄ったことで、AI連携の記録をどこまで自前で持つかという設計判断が、各事務所に返ってきました。ベンダーの管理画面で足りるのか、事務所側でも操作記録を残すのか。ここは規模と顧問先の性質で答えが分かれる部分です。

もうひとつは、拡張機能の広がりです。中核の仕様に手を入れずに機能を足せる枠組みが整ったため、今後は、どの拡張に対応しているかがサービス選定の比較軸に加わる可能性があります。会計事務所での連携設計はfreee MCPでAIエージェントを会計事務所に入れる記事で扱っており、拡張の採否が実装の選択肢を左右する場面が出てくると考えられます。

よくある質問

MCPの仕様変更で、事務所側の作業は発生しますか

多くの事務所では発生しません。MCPは開発者向けの規格であり、事務所が自前でMCPサーバーを実装していない限り、コードを書き換える場面はないためです。事務所側の作業は、使っているサービスの対応状況をベンダーに確認して記録に残すところまでになります。

ステートレス化とは何が変わったのですか

通信で接続状態を保持しない設計に変わりました。MCP公式のKey Changesによれば、Streamable HTTPからプロトコルレベルのセッションとMcp-Session-Idヘッダが削除され、initializeのやり取りも廃止されて、各リクエストがプロトコルバージョンとクライアント能力を持つ形になりました。

使っているソフトが旧仕様のままだと、いつまで使えますか

ベンダーに確認する項目です。仕様の側ではHTTP+SSEトランスポートが非推奨として再分類され、Streamable HTTPへの移行が示されています（出典は前掲のKey Changes）。実際にいつまで提供されるかは各サービスの方針によるため、公開情報からは判断できません。

非推奨になった機能はすぐ使えなくなりますか

すぐには止まりません。Key Changesは機能ライフサイクルと非推奨方針を採用し、最低12か月の非推奨期間を定めたと述べています（出典は前掲のKey Changes）。非推奨の機能は仕様の中では動き続け、新しい実装で採用しない扱いになります。

守秘義務の観点で新しく見直す点はありますか

規程の本文ではなく、規程が前提としている確認事項です。アクセス履歴が同じ粒度で残るか、キャッシュ範囲が非公開に設定されているか、どのアカウントの権限でAIが動くか、の3点が確認対象になります。守秘義務の根拠条文そのものは、通信方式を問題にしていません。

顧問先にはどう説明すればよいですか

規格の名前を出さずに説明できます。伝えるのは、AIがアクセスできる範囲、記録が残る範囲、いつでも停止できることの3点です。この形で説明しておけば、規格の版が上がるたびに説明をやり直さずに済みます。

事務所の規程は書き換えが要りますか

書き方によります。承認したサービス以外に顧客情報を入力しない、という水準で書かれている規程なら、通信規格の変更で手を入れる箇所はありません。特定の製品名や認証方式を名指しで書き込んでいる規程は、記述が実態とずれる場面が出てくるため、承認の手続きと責任者を軸にした書き方へ寄せる余地があります。

ベンダーからの回答が「対応予定」だった場合はどうしますか

回答日とともに未定として台帳に残す運用があります。曖昧な表現をそのまま確定情報として扱うと、後で移行時期の判断を誤ります。原文を残しつつ分類だけを未定に倒しておくと、次に確認するタイミングも判断しやすくなります。

参考文献

• Model Context Protocol 2026-07-28 Key Changes
• e-Gov法令検索 弁護士法
• e-Gov法令検索 税理士法
• e-Gov法令検索 司法書士法
• e-Gov法令検索 社会保険労務士法

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/