MCPとは、AIと外部のツールやデータをつなぐための共通の取り決めのことです。

AIと会計ソフトや文書管理システムをつなぐ仕組みが、2026年7月28日版の仕様で大きく変わりました。接続の状態をサーバ側に持たない設計へ切り替わり、認可まわりと通知の仕組みも入れ替わっています。この記事では、開発の話ではなく、事務所が導入判断とベンダー確認に使う観点として7項目に整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。

セッションが消えたことが事務所に意味すること

結論から書きます。今回の変更で事務所に効いてくるのは、接続のたびに誰の権限で呼び出されているかが毎回明示される構造になった点です。裏を返せば、これまで接続の途中経過に依存して動いていた仕組みは、作り直しになります。

仕様の変更点一覧によれば、2026-07-28版ではStreamable HTTPトランスポートからプロトコルレベルのセッションとMcp-Session-Idヘッダが削除されました。tools/list、resources/list、prompts/listといった一覧取得の結果は接続ごとに変わらなくなり、呼び出しをまたいで状態を持ちたいサーバは、サーバが発行する明示的なハンドルを通常のツール引数として受け渡す形に変わっています（出典: Model Context Protocol Key Changes 2026-07-28）。

あわせて、initializeとnotifications/initializedのハンドシェイクも削除されました。代わりに、すべてのリクエストが自分のプロトコル版とクライアントの能力を_metaに載せて運ぶ形になります。クライアントは各リクエストで自身を名乗ることが推奨され、サーバも各結果で自身を名乗ることが推奨されています（出典: Model Context Protocol Key Changes 2026-07-28）。

技術的な話に見えますが、士業事務所の関心に引き直すと意味が変わります。従来は、最初に一度つないだ後の状態がサーバ側に残り、その状態の上で後続の操作が流れていました。ステートレス化された後は、一回ごとの呼び出しが独立し、そのつど誰が何を要求しているかが明示されます。監査のしやすさという観点では、後者のほうが追いやすい構造です。一方で、途中で切れたときの扱いは厳しくなりました。

仕様変更の一覧には、Streamable HTTPトランスポートからSSEストリームの再開機能とメッセージ再送が削除されたことも記載されています。応答ストリームが切れた場合、処理中のリクエストは失われ、クライアントは新しいリクエストIDで出し直すことになります（出典: Model Context Protocol Key Changes 2026-07-28）。長時間かかる処理を外部サーバに投げている事務所は、途中で切れたときに同じ処理が二重に走らないかを確認しておく価値があります。

士業のチカラではMCPのセキュリティが実装側の責任である点を整理しましたが、今回の改定はその前提をさらに押し進めた形です。仕様が定めるのは共通の作法であって、事務所のデータを守るのは接続先の実装と、事務所側の設定です。

接続前に確かめる7項目

先に結論です。確認の相手は自分の事務所ではなく、接続しようとしているサービスの提供元です。以下の7つを質問リストとして持っておくと、判断材料が揃います。

第一項目は、対応している仕様のバージョンです。2026-07-28版では、サーバがserver/discoverというRPCを実装して、対応するプロトコル版と能力と識別情報を提示することが求められています。クライアントは他のリクエストの前にこれを呼んで版を選ぶことができます（出典: Model Context Protocol Key Changes 2026-07-28）。事務所としては、提供元が新旧どちらの版で動いているか、移行の予定があるかを聞けば足ります。

第二項目は、認可のつなぎ方です。今回の改定では認可まわりに複数の変更が入りました。認可サーバはRFC 9207に沿って認可応答にissパラメータを含めることが推奨され、クライアントは存在するissを記録済みの発行者と照合してから認可コードを引き換えることが求められます（出典: Model Context Protocol Key Changes 2026-07-28）。さらに、クライアントの資格情報は発行した認可サーバに紐づくものとされ、別の認可サーバで使い回さないこと、認可サーバが変わったら登録し直すことが明記されました（出典: Model Context Protocol Key Changes 2026-07-28）。事務所が確認するのは、接続に使う認証情報が誰の権限で、どこに保管され、退職時にどう失効するかです。

第三項目は、クライアント登録の方式です。仕様変更の一覧では、OAuth 2.0の動的クライアント登録（RFC 7591）がクライアント登録の手段として非推奨とされ、Client ID Metadata Documentsが推奨される形に変わりました。動的クライアント登録は、これに対応していない認可サーバとの後方互換のために残されています（出典: Model Context Protocol Key Changes 2026-07-28）。提供元がどちらで動いているかは、将来の移行コストに直結します。

第四項目は、権限の粒度です。ここは仕様ではなく実装の問題になります。ひとつの接続で顧問先の全データに触れる設計か、業務や顧問先の単位で分けられる設計かを聞きます。分けられない場合、事務所側でできる対策は接続そのものを業務単位に分けることくらいです。AIエージェントの実行制御の設計で整理したとおり、権限は配る前に区切るほうが後が楽です。

第五項目は、記録の取り方です。今回の改定では、pingとlogging/setLevel、notifications/roots/list_changedが削除され、ログのレベルはリクエストごとに_metaで指定する形になりました。この指定を含まないリクエストについては、サーバはnotifications/messageを出してはならないとされています（出典: Model Context Protocol Key Changes 2026-07-28）。ログの出方が変わるということは、事務所が後から追いたい記録の残り方も変わるということです。誰がいつ何を呼び出したかを、提供元の管理画面で確認できるかを聞いておきます。

第六項目は、長時間処理の扱いです。実験的だったタスク機能は中核の仕様から外れ、公式の拡張として再設計されました。応答を待ち続ける方式から、tasks/getで問い合わせる方式に変わり、クライアントから追加の入力を渡すtasks/updateが加わっています（出典: Model Context Protocol Key Changes 2026-07-28）。大量の文書を読ませる処理を外部に投げている事務所は、途中の状態をどう確認するかを提供元に聞く必要があります。

第七項目は、廃止予定の機能を使っていないかです。仕様には機能のライフサイクルと廃止方針が導入され、Active、Deprecated、Removedの三状態と、最低12か月の廃止猶予期間が定められました（出典: Model Context Protocol Key Changes 2026-07-28）。同じ一覧では、Roots、Sampling、Loggingの各機能が非推奨とされ、HTTP+SSEトランスポートも廃止対象として再分類されています（出典: Model Context Protocol Key Changes 2026-07-28）。提供元がこれらに依存している場合、猶予期間のうちに移行が入ります。

提供元への質問状をまとめるためのプロンプト例を挙げます。技術に明るくない担当者でも、抜けのない質問リストを作れます。

あなたは士業事務所のシステム導入担当を補助する役割です。
以下のサービス概要をもとに、提供元へ送る確認事項の一覧を作成してください。

必ず含める確認項目:
1. 対応しているMCPの仕様バージョンと、移行予定の有無
2. 認証情報の保管場所と、利用者ごとの失効手順
3. 顧問先や業務の単位で接続権限を分けられるか
4. 呼び出し履歴を事務所側で確認できるか（画面・出力形式・保存期間）
5. 長時間処理が中断した場合の再実行の扱い（二重実行の防止策）
6. 非推奨とされた機能に依存していないか
7. 入力データを学習に利用しない旨の明記があるか

各項目は、相手がそのまま回答できる疑問文の形にしてください。
専門用語には1行の補足を添えてください。

サービス概要: {ここに貼る}

もう1本、回答が返ってきた後に使うプロンプトです。回答の抜けを機械的に洗い出します。

あなたは士業事務所の導入判断を補助する役割です。
以下は提供元からの回答です。確認事項の一覧と突き合わせてください。

出力する項目:
1. 明確に回答された項目
2. 回答はあるが条件付き・あいまいな項目（どこがあいまいかを具体的に）
3. 回答が無い項目
4. 追加で聞くべき質問（3つまで）

回答内容を好意的に補完しないでください。
書かれていないことは書かれていないものとして扱ってください。

確認事項の一覧: {ここに貼る}
提供元の回答: {ここに貼る}

顧問先データをまたぐ接続で固めておく論点

結論を先に置きます。ステートレス化そのものは守秘義務の話ではありませんが、接続の粒度と記録の残り方は直接そこに効きます。

MCPで外部システムをつなぐと、AIが自分で情報を取りに行く経路ができます。人が画面に貼り付ける操作を経ないため、どの範囲のデータが処理経路に乗るのかは、接続設定を見ないと分かりません。個人情報保護法第23条は安全管理措置を定め、取り扱う個人データの漏えい等の防止その他の安全管理のために必要かつ適切な措置を講じることを求めています。個人情報保護委員会は生成AIサービスの利用について注意喚起を公表しており、入力が利用目的の達成に必要な範囲に収まっているかという観点が示されています（出典: 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等）。

職種ごとの守秘義務の根拠も確認しておきます。弁護士は弁護士法第23条、税理士は税理士法第38条、公認会計士は公認会計士法第27条、司法書士は司法書士法第24条、社会保険労務士は社会保険労務士法第21条に規定が置かれています。いずれも漏示や盗用を禁じる形であり、接続の技術的な形式を規律するものではありません。個別の事案への当てはめは有資格者の判断に属します。

外部サーバへの接続が第三者提供にあたるかという論点は、委託の形をとるか否かで整理が分かれます。個人情報保護法第27条は第三者提供の制限を定めたうえで、利用目的の達成に必要な範囲内で取扱いを委託する場合について、提供を受ける者を第三者に該当しないものとする規定を置いています。どちらの整理で運用するかは、提供元との契約内容と実際のデータの流れを見て、有資格者が判断する領域です。

事務所規程に落とすなら、MCP接続に固有の項目として4つが候補になります。ひとつは、接続してよい外部サーバの一覧と、その承認者。ひとつは、接続単位を顧問先または業務で区切る原則。ひとつは、認証情報の保管場所と失効手順。もうひとつは、提供元が仕様バージョンを更新したときに接続設定を点検する旨です。仕様が年単位で動く以上、点検のきっかけを規程に書いておかないと、更新に気づかないまま運用が続きます。

顧問先への説明も先に設計しておきます。事務所のシステムに外部のAIが接続していること自体を、どこまで伝えるか。業務委託の覚書に、AIを利用する範囲と、有資格者が最終確認を行うこと、外部サービスへのデータ提供の有無を書き添える運用を採る事務所があります。

移行期に起きやすい3つの失敗

ひとつめは、古い版と新しい版が混在することに気づかない型です。仕様は変わりますが、接続先がすぐに追随するとは限りません。事務所が使っているツールのうち、どれが新しい版で、どれが旧版のままかを一覧にしておかないと、挙動の違いを個別の不具合と誤認します。server/discoverで版を確認できる設計になった分、提供元に聞けば答えは返ってきます。

ふたつめは、途中で切れた処理の二重実行です。再送と再開の仕組みが外れたため、切れたら出し直すという運用になります。ここで、同じ申請データを二度送る、同じメールを二通出すといった事故が起こり得ます。回避策は、外部への送信や登録を伴う処理について、重複を検知する仕組みを提供元が持っているかを導入前に確認することです。

みっつめは、ログが取れていないことに後から気づく型です。ログの出方が変わったため、これまで見えていた記録が出なくなっている可能性があります。事故が起きてから記録を探すのでは遅く、導入直後に一度、実際の呼び出し履歴を画面で確認しておく手順を挟んでおくと取りこぼしが減ります。MCPの仕様は誰がどう決めるのかで触れたとおり、仕様の決定過程は公開されていますので、変更の予告を追う手段はあります。

費用と工数、誰が担当を持つのか

費用面では、MCPの仕様変更そのものに事務所が払う費用は発生しません。発生するのは、提供元が移行に伴って料金体系やプランを変えた場合と、事務所側で業務システムに組み込んでいる部分を作り直す場合です。後者は外部のベンダーに委託していることが多く、見積もりを取る前に、どの機能が非推奨に該当するかを整理しておくと話が早くなります。

工数面では、確認作業そのものは重くありません。前述の7項目を質問状にまとめる作業が半日、提供元からの回答を待つ期間が1、2週間、回答を読んで接続設定を見直す作業が半日というのが目安です。重いのは、接続の粒度を業務単位に分け直す作業のほうで、こちらは接続先の数に比例します。

体制面では、外部接続の担当を決めます。事務所の規模にかかわらず、接続先の一覧を持つ人がひとり要ります。接続の追加申請を受け、提供元への確認を回し、認証情報の失効を管理する役割です。この役割が空席のまま接続だけが増えると、退職時や契約終了時に止め忘れが出ます。

仕様が動き続ける前提で何を固めるか

今後の焦点は、仕様の更新頻度に対して事務所側の点検をどう自動化するかに移ります。最低12か月の廃止猶予が定められたことで、突然使えなくなる事態は起きにくくなりました（出典: Model Context Protocol Key Changes 2026-07-28）。裏を返せば、猶予期間のうちに気づく仕組みを持っているかどうかで差が出ます。

もうひとつは、エージェント同士の連携との関係です。士業のチカラではA2Aによるエージェント連携と委任範囲を整理しましたが、MCPが道具とのつなぎ方を、A2Aがエージェント同士のつなぎ方を担う構図になりつつあります。事務所が確認すべき観点は両方で共通していて、権限の粒度と記録の残り方に帰着します。

最後に、顧問先への助言という観点です。顧問先企業も同じ仕様の上でツールを選ぶことになります。事務所が自分の接続で通した質問状は、そのまま顧問先への助言の型になります。技術の中身を語る必要はなく、何を提供元に確かめるべきかを示せれば、士業としての付加価値になります。

よくある質問

MCPがステートレスになると何が変わりますか

接続のたびに状態を作らず、一回ごとの呼び出しが独立します。仕様変更の一覧によれば、プロトコルレベルのセッションとMcp-Session-Idヘッダが削除され、initializeのハンドシェイクも取り除かれました（出典: Model Context Protocol Key Changes 2026-07-28）。

事務所側で何か作業が必要ですか

多くの事務所では、提供元への確認が作業の中心です。自前でサーバを実装している場合を除き、仕様への追随は提供元の作業になります。確認すべき観点は本文の7項目にまとめています。

処理が途中で止まったらどうなりますか

出し直しになります。仕様変更の一覧では、SSEストリームの再開とメッセージ再送が削除され、応答ストリームが切れたリクエストは新しいリクエストIDで再送する形になると記載されています（出典: Model Context Protocol Key Changes 2026-07-28）。

認証の方式は変わりましたか

認可まわりに複数の変更が入りました。認可応答へのissの付与と検証、資格情報を発行元の認可サーバに紐づける義務、動的クライアント登録の非推奨化などが含まれます（出典: Model Context Protocol Key Changes 2026-07-28）。

使っているツールが古い仕様のままだと問題がありますか

直ちに使えなくなるわけではありません。仕様には最低12か月の廃止猶予期間を含むライフサイクル方針が導入されています（出典: Model Context Protocol Key Changes 2026-07-28）。猶予のあるうちに移行計画を確認しておく進め方があります。

顧問先データを外部サーバにつなぐのは守秘義務に反しますか

法的な評価は個別の事情によるため、記事として結論は出しません。確認の順序としては、提供元のデータ取扱いを公式文書で確かめ、接続の粒度と記録の残り方を把握し、顧問先への説明と同意の設計を固めたうえで、根拠条文に照らして有資格者が判断する流れになります。

小規模な事務所でもここまで確認が必要ですか

接続する外部サーバの数が少なければ、確認の量もその分少なくなります。項目を減らすより、接続先が少ないうちに全部確認しておくほうが、後から遡るより負担が軽くなります。

参考文献

• Model Context Protocol Key Changes 2026-07-28
• Model Context Protocol Streamable HTTP トランスポート仕様
• 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等
• e-Gov法令検索 個人情報の保護に関する法律第23条
• e-Gov法令検索 弁護士法第23条

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