MCPの新ロードマップとは、次期仕様の優先領域を示した公式方針のことです。

事務所の顧客管理や会計データにAIをつないでいるなら、その土台の設計方針が更新されたことを知っておく価値があります。この記事では、公開されたMCPの新しいロードマップを、士業事務所の連携基盤という視点から読み解きます。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。Model Context Protocolの公式ブログThe New MCP Roadmapは、2026年8月22日付で新しいロードマップを公開し、5つの優先領域を示しています。

5つの優先領域が示したMCPの次の一手

MCPは、生成AIと外部のデータやツールをつなぐための共通の約束事です。事務所側から見れば、AIに顧客管理システムや会計データを読ませるときの接続規格にあたります。この規格の方向性が、公式ブログThe New MCP Roadmapで更新されました。同記事によれば、新しいロードマップはエージェント向けメッセージング基本要素、HTTPネイティブなトランスポートの統一と堅牢化、エージェントのアイデンティティとエンタープライズ対応のセキュリティ、基本要素の改善、SDKの開発者体験の改善という5つの優先領域で構成されています。

前のロードマップとの比較も押さえておきたい部分です。同じ記事は、3月に公開された前版がトランスポートの進化とスケーラビリティ、エージェント間通信、ガバナンスの成熟、エンタープライズ対応という4つの優先領域を掲げていたと説明しています。今回はそこから、サーバー起点のイベント、結果型の改善、エージェントのアイデンティティといった、前版で将来の課題とされていた項目が独立した優先領域に格上げされた形です。事務所の立場では、将来の話だったものが具体的な作業予定に変わったと読むのが素直です。

直近の変更点の整理も、同じ記事にあります。変更の大半は2026年7月28日の仕様リリースに含まれており、プロトコルレベルのセッションと初期化ハンドシェイクが廃止されたことで、サーバーが状態を保持せずに水平スケールできるようになったと説明されています。あわせて、クライアントがサーバーの対応バージョンと機能を接続前に取得する仕組みや、一覧結果をキャッシュできる仕組みも入りました。この7月の改訂が事務所のシステム連携にどう効くかは、MCPが2026年7月に大改訂された際の実務影響で整理しています。

エージェント間通信の側では、長時間実行の扱いが変わりました。公式ブログThe New MCP Roadmapは、初期導入者からの反応を受けてTasksが再設計され、公式の拡張へ移されたこと、サーバー起点のリクエストに代わる新しい複数往復のリクエストのパターンが導入されたことを説明しています。士業の業務に引き寄せると、大量の書類をまとめて処理させるような、数分から数十分かかる作業を投げっぱなしにして後で結果を受け取る形が、規格として整いつつあるということです。

ガバナンスの整備も進んでいます。同記事は、貢献者の段階を定めた仕組みが正式に採用され、ワーキンググループが自分の領域の提案を仕分けるようになったこと、仕様に機能のライフサイクルと非推奨化の方針が備わったことを挙げています。外部のMCPサーバーを事務所に入れるかどうかを判断するとき、その規格が場当たり的に変わるのか、非推奨化の手順を踏むのかは、導入判断の材料になります。審査の観点は外部MCPサーバーの安全性をどう審査するかにまとめています。

事務所の連携基盤に効く3つの変化と、いま組む5手順

5つの優先領域のうち、士業事務所の実務に近いところから効いてくるのは3つです。順に見ていきます。

1つ目は、エージェントのアイデンティティです。公式ブログThe New MCP Roadmapは、現在のMCPの認可が、人がブラウザでアクセスを承認する前提で組まれていると説明しています。そのうえで、呼び出す側がクラウド上で動くエージェント自身のアイデンティティを持つ場合や、その場にいない利用者に代わって動く場合、下位のエージェントにより狭い権限を委譲する場合が増えていると指摘し、貼り付けたAPIキーや長寿命のトークンに頼らない標準的な仕組みを目指すとしています。事務所にとっては、誰の権限でどのデータに触れたのかを後から説明できるかどうかに直結する話です。

2つ目は、基本要素の改善のうち、段階的な探索の取り組みです。同記事は、ツールを100個持つサーバーに接続すると、利用者が何も尋ねないうちからその全体をモデルが読み込むことになり、ツールの選択精度も一覧が長くなるほど落ちる傾向があると説明しています。そのうえで、サーバーが小さな入口を提示し、会話が絞り込まれるにつれてカタログを開示していく方向を示しています。会計、顧客管理、電子申請、文書管理と複数のシステムをつないでいる事務所ほど、この変更の恩恵は大きくなります。

3つ目は、トランスポートの統一です。同記事は、7月の仕様リリースによってリモートのMCPサーバーが他のHTTPワークロードと変わらなくなり、既存のインフラで運用しやすくなったと説明したうえで、ローカルで動くサーバーについても同じ方式に寄せていく方向を示しています。事務所内のサーバーと外部のクラウドサービスで運用方法が分かれている状態は、管理の手間としても、権限設計の抜けとしても負担でした。ここが揃うと、事務所の標準的な構成を1つに絞れます。

これを踏まえて、いま事務所が組める手順を5つに整理します。

第1手順は、接続しているMCPサーバーの棚卸しです。事務所が現在つないでいるサーバーを、提供元、扱うデータの区分、認証方式、最終確認日という列で一覧にします。自作したものと、ベンダーが提供するものを分けて並べるのが要点です。自作分は改修の主体が事務所側にあり、ベンダー提供分は先方の対応待ちになるため、対応の性質がまったく違います。

第2手順は、認証方式の確認です。棚卸しした一覧のうち、長寿命のAPIキーを貼り付けて動かしているものに印をつけます。ロードマップが向かう先は、この形からの脱却です。すぐに切り替える必要はありませんが、どこに何本残っているかを把握しておかないと、移行の時期に慌てます。

第3手順は、権限の粒度の見直しです。1つのAPIキーで顧客管理システムの全データが読める状態になっていないかを確認します。エージェントごとに権限を分ける設計が標準化されていく前提に立てば、いま粗い粒度で動いているところが将来の改修点になります。

第4手順は、長時間処理の切り分けです。大量の書類処理や一括の突合など、時間のかかる処理をMCP経由で動かしているなら、それが同期的な待ち受けで組まれているかを確認します。Tasksの拡張が仕様に取り込まれていく流れの中で、この部分は書き換えの候補になります。

第5手順は、確認体制の明文化です。ここまでの4手順は技術的な整理ですが、出力物を誰が確認するかという運用は別途要ります。AIが顧客データを読んで出した結果は、有資格者が確認したうえで顧問先に渡すという線引きを、手順書に書いておきます。自作サーバーの構築から運用までの流れは士業事務所のMCPサーバー構築手順で扱っています。

棚卸しと影響範囲の整理には、生成AIを使えます。以下は、事務所の構成を匿名化して渡す前提のプロンプト例です。

あなたは士業事務所の情報システム担当のアシスタントです。
以下は架空のA事務所のMCP接続構成です。実名は含まれていません。

接続先1 / 自作 / 顧客管理DBの読み取り / 長寿命APIキー / 最終確認 半年前
接続先2 / ベンダー提供 / 会計データの読み取りと書き込み / OAuth / 最終確認 先月
接続先3 / 自作 / 文書管理フォルダの読み取り / 長寿命APIキー / 未確認

MCPの新しいロードマップでは、エージェント固有のアイデンティティ、
段階的なツール探索、トランスポートの統一が優先領域とされています。

次の3点を箇条書きで出力してください。
1. 各接続先について、将来の改修が必要になりうる箇所と、その理由
2. 改修の優先順位（データの機微度と認証方式の観点から）
3. いますぐ実施できる暫定的な措置

断定的な法的評価は書かないでください。
不明な点は必ず「要確認」と明示してください。

あなたは士業事務所のアシスタントです。
外部のMCPサーバーを事務所に導入するかどうかを判断するための
確認項目リストを作成してください。

前提として、次の観点を含めてください。
- 提供元の素性と、仕様の非推奨化ポリシーの有無
- 認証方式（長寿命キーか、標準的な認可フローか）
- 取得できるデータの範囲と、権限を絞れるかどうか
- ログの保存場所と保存期間
- 障害時と規約変更時の通知の有無

出力は確認項目とその確認方法をセットにした箇条書きにしてください。
結論を断定せず、判断材料として提示してください。

2本目のプロンプトのように、判断そのものをAIに求めず確認項目の網羅に使うと、出力の検証が容易になります。出てきた項目は、事務所の導入基準として1枚にまとめ、担当者が変わっても同じ観点で審査できる形にしておきます。

顧客データをMCP経由でAIに渡すときの守秘義務の設計

MCPは接続の規格であって、守秘義務の免責を与えるものではありません。事務所のデータをAIに読ませる以上、根拠となる守秘義務の条文に立ち返る必要があります。弁護士については弁護士法第23条が、税理士については税理士法第38条が、社会保険労務士については社会保険労務士法第21条が、それぞれ業務上知り得た秘密の取り扱いについて定めています。MCPで自動的にデータが流れる構成は、人が都度判断して貼り付ける運用より、この点で注意が要ります。

論点になりやすいのは、接続の設計が権限を絞れているかです。顧客管理システム全体を読める接続を1本つくると、AIが必要としない範囲のデータまで到達できる状態になります。ロードマップが示すエージェント固有のアイデンティティと権限の委譲は、まさにこの粒度の問題に対する規格側の答えです。規格が整うのを待つ間も、事務所側でできることはあります。読み取り専用の接続にする、対象を特定のフォルダやテーブルに限定する、書き込みは人の操作を挟む、といった設計です。

個人情報の取り扱いの観点も併走します。顧問先から預かった従業員や取引先の情報を外部サービスへ渡す構成では、個人情報保護法第27条が定める第三者提供の枠組みとの関係が論点になります。クラウド事業者が当該データを取り扱わないと整理できる場合の考え方については、個人情報保護委員会が公表している資料を確認したうえで、自事務所の構成に当てはめる作業が要ります。ここは事務所ごとに構成が違うため、一般論だけで済ませず、実際の接続先と設定を見て判断する部分です。

ログの設計も、守秘義務と直結します。MCP経由の呼び出しは、どのツールが何を取得したかが記録に残せる構造です。この記録を残していれば、後日の照会に対して事実で答えられます。逆に、記録がないまま自動でデータが流れる構成は、何が起きたかを説明できません。ロードマップがエージェントのアイデンティティを優先領域に据えたことは、この説明可能性を規格側で支える動きとしても読めます。

事務所規程に落とすなら、次の4点を書く形が考えられます。接続を認めるMCPサーバーの一覧と、追加するときの承認者。接続ごとに許可するデータの範囲と、読み取り専用か書き込みを含むかの区分。呼び出しログの保存場所と保存期間。障害や規約変更が起きたときの報告先と初動の手順です。この4点は、規格の更新があっても書き換えずに済む粒度で書いておくと長持ちします。

MCP連携でつまずく3つの場面と回避策

1つ目は、ベンダー提供のMCPサーバーが仕様変更に追随せず、ある日つながらなくなる場面です。回避策は、導入時に非推奨化のポリシーと通知手段を確認しておくことに尽きます。公式ブログThe New MCP Roadmapは、仕様に機能のライフサイクルと非推奨化の方針が備わり、7月の非推奨化がその最初の適用例だったと説明しています。規格側に手順ができたということは、それに従うベンダーとそうでないベンダーを見分けられるということでもあります。

2つ目は、ツールを増やしすぎてAIの応答が鈍る場面です。接続先を増やすほど便利になるという直感は、実際には裏切られます。前述のとおり、公式ブログはツールの一覧が長くなるほど選択精度が落ちる傾向を指摘しています。回避策は、業務の種類ごとに接続の組み合わせを分けることです。税務の作業のときは会計と顧客管理だけ、書面作成のときは文書管理だけ、という形で切り替えます。

3つ目は、自作サーバーの担当者が事務所を離れ、誰も中身を把握していない状態になる場面です。これは規格の問題ではなく体制の問題ですが、実務上はいちばん起きやすい失敗です。回避策は、接続先の一覧に構築者と最終確認日を漏れなく書き、半年に一度は棚卸しの時間を取ることです。棚卸しの実施記録そのものが、後日の説明材料になります。

改修に向けた費用・工数・担当の置き方

費用面では、規格の更新それ自体に料金は発生しません。かかるのは、既存の接続を書き換える工数と、ベンダー提供のサービスを新しい方式に対応した上位プランへ切り替える場合の差額です。参考として、自作サーバーを複数持っている事務所ほど、外部に払う費用より内部の工数のほうが重くなります。

工数の見積もりは、接続の本数と自作の割合で決まります。参考までに、ベンダー提供のサービスだけで組んでいる事務所は、先方の対応を待って設定を見直す程度で済みます。自作サーバーを持つ事務所は、認証方式の切り替えと権限の分割に手が要ります。ロードマップは方向性を示すもので即座の対応を求めるものではないため、次の仕様リリースの内容が固まってから着手する判断も成り立ちます。

担当の置き方は、技術的な作業を担当者または外部のパートナーが持ち、どのデータをどこまでAIに触らせるかの線引きを有資格者が持つ形が素直です。この線引きは技術の問題ではなく守秘義務の問題なので、技術担当だけで決めてしまうと、後から見直しになります。接続を1本追加するたびに、扱うデータの区分を有資格者が確認する運用にしておくと、粒度の管理が崩れません。

費用の見立てで見落とされがちなのが、切り替え期間中の二重運用です。既存の接続を止めずに新しい方式を並走させる期間が発生すると、その間だけサービスの契約が重なります。参考として、切り替えの計画を立てるときは、作業そのものの工数だけでなく、並走期間の長さも見積もりに入れておくと、後から予算の話でもめずに済みます。

もう1点、外部のパートナーに作業を委託する場合の情報の扱いにも触れておきます。接続の改修作業では、顧客データそのものを見せなくても、どのテーブルにどんな項目があるかという構造情報が相手に渡ります。この構造情報も事務所の管理下に置くべき情報として扱い、委託契約に守秘の条項を置いておくのが実務的です。作業の記録を事務所側にも残しておくと、担当者が変わったときの引き継ぎが軽くなります。

次の仕様リリースまでに整理しておきたい論点

ロードマップは、次の仕様リリースとその先の方向を示すものです。したがって、いま慌てて全部を作り直す必要はありません。むしろ重要なのは、方向が分かった状態で棚卸しを済ませ、いざ仕様が固まったときに何本を直せばよいかを即答できるようにしておくことです。

もう1つの論点は、事務所の外にあるMCPサーバーをどこまで信頼するかという判断軸です。段階的な探索やサーバーの自己記述の仕組みが整うと、接続前に相手の素性を機械的に確認できる幅が広がります。これは審査の自動化につながる一方で、機械的な確認が通ったことをもって安全とみなす運用に流れる危険もあります。最終的に事務所の名前で顧問先に説明するのは有資格者であるという構図は変わりません。

3つ目は、行政手続との接続です。電子申請の周辺がオンライン化されていく流れの中で、事務所の内部システムと外部の申請系をどうつなぐかは、今後の論点になります。この領域の現状は行政手続のオンライン化率と士業のMCP活用で扱っています。

4つ目に、事務所の内部にどこまで作るかという判断も残ります。規格が安定して扱いやすくなるほど、自作の敷居は下がります。一方で、自作した接続は事務所が保守の責任を持ち続けることになります。ロードマップが示す方向は自作を容易にするものですが、容易になったことと、自事務所で持つべきかどうかは別の問いです。保守の担い手がひとりに集中する構成は、その担当者が離れた瞬間に止まります。この観点は、規格の話とは独立して事務所ごとに答えを出す部分です。

よくある質問

新しいロードマップが出たら、いますぐ改修が必要になりますか

必要とは限りません。公式ブログThe New MCP Roadmapは、今後の仕様リリースに向けた優先領域を示すものと位置づけています。示された5つの領域は、次の仕様に何が入る見込みかを知るための材料です。事務所としては、いま何本の接続をどう組んでいるかを棚卸ししておき、仕様が確定した段階で改修の要否を判断する流れが現実的です。

MCPを使っていない事務所にも関係がありますか

関係が生じる可能性があります。会計ソフトや顧客管理サービスがAI機能を提供する際、その裏側でMCPが使われている場合があるためです。事務所が直接サーバーを立てていなくても、利用しているサービスがどの方式でAIとつながっているかは、データの流れを把握するうえで確認しておく価値があります。

エージェント固有のアイデンティティとは何を指しますか

人ではなくAIエージェント自身に与えられる識別情報のことです。公式ブログThe New MCP Roadmapは、現在の認可が人のブラウザ承認を前提としている一方で、クラウド上で動くエージェントが自身のアイデンティティを持って呼び出す場面が増えていると説明しています。事務所の観点では、記録に残るのが人の名前だけなのか、どのエージェントがどの権限で動いたかまで残るのかという違いになります。

顧客データをMCP経由でAIに渡すことは守秘義務との関係でどうなりますか

論点になります。弁護士法第23条、税理士法第38条、社会保険労務士法第21条は、いずれも業務上知り得た秘密の取り扱いについて定めています。実務では、接続の権限を必要な範囲に絞る、呼び出しログを残す、顧問契約に外部サービスの利用を明記するという3点を整えたうえで判断する事務所が多く見られます。構成は事務所ごとに異なるため、一般論ではなく実際の接続設定を見て検討する部分です。

外部のMCPサーバーを導入するとき、何を確認すればよいですか

提供元、認証方式、取得できるデータの範囲、ログの保存、非推奨化のポリシーの5点が出発点になります。公式ブログThe New MCP Roadmapによれば、仕様に機能のライフサイクルと非推奨化の方針が備わったため、その手順に従うかどうかが提供元を見分ける材料になります。事務所として同じ観点で審査できるよう、確認項目を1枚のリストにしておくと運用が安定します。

接続するツールは多いほうがよいのでしょうか

多ければよいというものではありません。公式ブログは、多数のツールを持つサーバーに接続するとその全体を先に読み込むことになり、ツールの選択精度も一覧が長くなるほど落ちる傾向があると説明しています。業務の種類ごとに接続の組み合わせを分け、必要なものだけをつなぐ構成のほうが、応答の質と費用の両面で扱いやすくなります。

7月の仕様改訂と今回のロードマップは何が違いますか

7月のものは確定した仕様、今回のものは今後の方針です。公式ブログThe New MCP Roadmapは、変更の大半が2026年7月28日の仕様リリースに含まれており、今回のロードマップはそこから先を示すものだと説明しています。すでに動いている接続への影響は7月の改訂に起因するもので、今回の内容は次の改訂に向けた準備の材料と整理できます。

参考文献

• Model Context Protocol Blog The New MCP Roadmap
• Model Context Protocol Roadmap
• e-Gov法令検索 弁護士法第23条
• e-Gov法令検索 税理士法第38条
• e-Gov法令検索 社会保険労務士法第21条
• e-Gov法令検索 個人情報保護法第27条
• 個人情報保護委員会

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