MCPロードマップとは、AIと外部システムをつなぐ規格の今後の重点領域を示す文書のことです。

事務所の会計システムや顧客管理をAIにつなぐ規格が、次にどこへ向かうかが公表されました。この記事では、五つの重点領域のうち士業事務所の実務に先に効くものから順に読み解き、いま決めておける設計を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。ロードマップは2026年8月22日にコアメンテナ名義で公表されました（出典: Model Context Protocol Blog The New MCP Roadmap）。

五つの重点領域を実務の近さで並べ替える

結論から書くと、士業事務所がいま気にすべきなのは五領域のうち二つです。エージェントの身元と企業向けセキュリティ、そして道具の出し方の改善です。残る三つは、当面はベンダー側が引き受ける領域になります。

公表された重点領域は、エージェント向けメッセージング基本要素、HTTPネイティブなトランスポートの統一と堅牢化、エージェントの身元と企業向けセキュリティ、基本要素の改善、SDKの開発者体験の改善の五つです（出典: Model Context Protocol Blog The New MCP Roadmap）。詳細は公式ロードマップに掲載されています。

事務所の実務に最も近いのは、三つ目のエージェントの身元と企業向けセキュリティです。公表文は、現在の認可がブラウザ上で人が承認する形を前提としている一方、呼び出し側が自身の身元を持つクラウド上のワークロードとして動き、その場にいない利用者の代わりに動作したり、下位のエージェントに限定した権限を委譲したりする場面が増えていると説明しています。あわせて、貼り付けたAPIキーや長期間有効なトークンではなく既存の標準に基づいて身元を認識し信頼する方法を目指すと述べられています。事務所の言葉に置き換えると、誰の権限でその処理が動いたのかを後から辿れるかどうかの話です。監査ログの設計はMCPに監査ログの標準はない 証跡の7設計で扱っています。

次に近いのが、四つ目の基本要素の改善です。公表文は、道具の数が増え続ける課題を挙げ、百個の道具を持つサーバーに接続すると利用者が何も尋ねないうちにその全体をモデルが負担することになり、道具の選択も一覧が伸びるほど悪化しがちだと説明しています。そのうえで、サーバーが小さな入口を示し、会話が絞られるにつれて目録を段階的に開示する取り組みを始めるとしています。事務所側では、会計と労務と顧客管理を一度に接続した結果、AIが毎回どれを使うか迷うという症状として現れる部分です。

この二つが先に効く理由を、事務所の日常に引き寄せて書きます。身元の話は、職員が退職したあとにAI連携がどう振る舞うかという問題です。個人アカウントの権限を借りて動かしている構成では、アカウントを止めた瞬間に処理が止まります。逆に権限を残したまま止め忘れると、退職者の名義で処理が動き続けます。どちらも事務所として説明しづらい状態です。道具の出し方の話は、AIが適切な機能を選べないという日常的な不便に直結します。会計と労務と顧客管理を同時につないだ事務所で、AIが労務の質問に会計の機能を使おうとする挙動が起きるのは、この構造が背景にあります。

一つ目のエージェント向けメッセージング基本要素は、長時間動く処理と、サーバー側から結果を送る仕組みに関わります。公表文は、クライアントが結果を取りに行き続けなくて済むよう、サーバー起点のイベントに取り組むとしています。事務所の用途では、大量の書類を読み込ませて結果を待つような処理が該当します。

二つ目のトランスポート統一は、2026-07-28版で遠隔のMCPサーバーが他のHTTPワークロードと変わらなくなった流れを、他の配備形態にも広げるものです。その前提となった仕様変更についてはMCPが2026年7月に大改訂 事務所のシステム連携7つの実務影響で整理しています。五つ目のSDK改善は、事務所がサーバーを自作する場合に効いてきます。自作の手順は士業事務所のMCPサーバー構築手順にまとめています。

いま決めておける7つの設計

先に線を引きます。ロードマップは今後の方向を示す文書であり、仕様として確定したものではありません。事務所がやるのは、方向が示された領域について、いま決められる設計を先に固めておく作業です。仕様を先読みして実装を作り込むのは、確定してからで足ります。

第一の設計は、接続先の棚卸しです。事務所のAIがどのシステムにつながっているかを列挙します。会計、労務、顧客管理、文書管理、電子契約。この一覧が無いと、権限の話が始められません。

第二の設計は、読み取りと書き込みの区別です。接続先ごとに、読むだけか、書き換えもできるかを決めます。書き込み権限は、必要な範囲に絞ったうえで、どの操作を許すかまで具体化します。ここを曖昧にしたまま接続すると、後から絞り込むのが難しくなります。

第三の設計は、誰の権限で動くかの決定です。職員個人のアカウント権限を引き継ぐのか、事務所として用意した専用の権限で動かすのか。ロードマップが身元の標準化を重点に挙げている以上、この決め方は今後の実装に影響します。いま決めておけば、規格が固まったときに移行しやすくなります。

第四の設計は、人が判断を挟む地点です。AIが自律的にシステムを操作する構成では、どの操作の前で人の承認を求めるかを決めます。総務省と経済産業省が公表したAI事業者ガイドライン（第1.2版）でも、AIエージェントについて、判断が必要となる事項を重要度に応じて整理し、人間の判断を適切に介在させる仕組みの構築が重要になる旨が留意点として整理されています（出典: PwC 「AI事業者ガイドライン（第1.2版）」改定のポイントと事業者への期待）。

第五の設計は、記録の取り方です。どの操作が、いつ、どの権限で実行されたか。規格側に監査ログの標準がまだ無い以上、記録は接続先のシステム側と事務所側の両方で確保する形になります。誰がその記録を定期的に見るかまで決めて、初めて記録が機能します。

第六の設計は、接続する道具の絞り込みです。段階的な開示が重点領域に入っているのは、道具が多すぎる状態が問題として認識されているからです。事務所側でも、当面は用途ごとに接続を分け、一度に全部をつながない構成にしておくほうが動作が安定します。接続先の選び方はMCPサーバーを選ぶ7つの判断軸で扱っています。

第七の設計は、ベンダーへの確認です。使っているツールがロードマップのどの領域に関係し、身元や認可の実装をいつ更新する予定か。回答が取れない場合は、取れないこと自体を記録に残します。更新の予定が示されないツールは、乗り換えの候補として棚に置いておく判断もあります。

七つの設計は、前半三つが接続の骨格、後半四つが運用の枠です。骨格を決めないまま運用の枠だけ作ると、規程に書いた承認や記録がどの操作に掛かるのか分からなくなります。棚卸しと権限の決定を先に済ませるほうが、規程の文言も短く書けます。

進め方の順番についても補足します。第一の棚卸しで接続先を並べると、想定より多くのシステムがAIから触れる状態になっている事務所が出てきます。ここで一気に絞り込みたくなりますが、絞り込みは第二の読み書き区分を確認してからのほうが精度が上がります。読み取りしかできない接続まで外してしまうと、業務側の反発が出るためです。

第一と第二の設計を進めるときに使えるプロンプトを示します。実在の顧客情報は入れず、架空のA社に置き換えます。

あなたは士業事務所のシステム管理アシスタントです。
以下のメモから、AI連携の接続先一覧の下書きを作ってください。

【入力】事務所のシステムとAI連携の設定メモ
（ここに貼る。顧問先名は「A社」、職員名は「甲」に置換済み）

出力する列：
1) 接続先システム名
2) AIができる操作（読み取りのみ／書き込みあり／メモから読み取れない場合は「不明」）
3) その操作が動くときの権限の持ち主（職員個人／事務所共通／不明）
4) 操作履歴が残る場所（不明なら「不明」）
5) 追加で確認すべき点（1行）

注意：
- メモに書かれていない事実を補わないでください
- 「不明」を空欄にしないでください
- セキュリティ上の評価や断定的な助言は書かないでください

次の接続先について、人の承認を挟む地点の候補を洗い出してください。

【入力】接続先システムでAIが実行しうる操作の一覧
（ここに貼る）

出力形式：
1) 操作名
2) 実行された場合に元に戻せるか（メモの範囲で。不明なら「不明」）
3) 顧問先に影響が及ぶか（同上）
4) 人の承認を挟む候補かどうかと、その理由（1行）

注意：
- 一覧に無い操作を追加しないでください
- 断定的な結論ではなく、候補として提示してください
- 判断が分かれそうな箇所は「要検討」と明記してください

出力は素案として扱い、事務所の実態と突き合わせる工程を挟みます。とくに二本目は、元に戻せるかどうかの判断が実装に依存するため、システム側の仕様を開いて確認する作業が残ります。

顧問先データが通る経路をどう規程に書くか

結論を先に置きます。AIが自律的にシステムを読みに行く構成では、入力の可否を入力の瞬間に判断できません。事前の権限設計が、そのまま守秘義務の設計になります。

判断の起点は資格ごとの守秘義務です。弁護士法第23条は、弁護士又は弁護士であった者がその職務上知り得た秘密を保持する権利を有し、義務を負う旨を定めています。税理士法第38条は、税理士が正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、又は窃用してはならない旨を定めています。社会保険労務士法第21条も同趣旨の規定を置いています。AIが会計システムを読みに行く構成では、そこに入っている顧問先の情報が、事務所の判断を経ずに外部のモデルへ渡り得ます。だから接続の設計が守秘義務の設計になります。

外部サービスへ渡す側の規律も並行します。顧問先の個人データを含む情報が外部へ出る構成では、個人情報保護法第27条の第三者提供の規律が論点になります。個人情報保護委員会は生成AIサービスの利用に関する注意喚起を公表し、プロンプトに個人情報を入力する場合には、それが特定された利用目的の達成に必要な範囲内であることの確認を求める趣旨を示しています（出典: 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等について）。ここでは公表資料の紹介にとどめます。個別の構成がこれらの規定との関係でどう評価されるかは、事案ごとの判断になります。

規程に落とすときの構成としては、接続先の列挙、操作の区分、権限の持ち主、承認を挟む地点、記録の保存先と確認担当という並びを採る方式があります。ツール名で書くと更新が頻繁になるため、接続先システムの単位で書くほうが改定の回数が減ります。

顧問先への説明では、AIが事務所のどのシステムに接続しているかを一枚に書いて渡す形が機能しています。エージェント型を使っていない事務所は、使っていない旨を書けば足ります。空欄にしておくと、顧問先の側で確認のやり取りが発生します。

事務所内の運用としては、接続の追加を誰が承認するかを先に決めておきます。職員が個別に接続を増やせる状態だと、棚卸し表が実態から離れます。承認の記録を残す先も、規程に書いておく項目です。

連携設計で起きやすい3つの失敗

一つ目は、ロードマップの内容を確定仕様として扱ってしまう失敗です。公表文は今後の方向を示すもので、仕様提案がこれらの領域に該当する場合に審査が優先されるという位置づけです。実装の作り込みを先走ると、仕様が固まる過程で手戻りが出ます。

二つ目は、道具を一度に全部つないでしまう失敗です。段階的な開示が重点領域に入っているのは、道具が多い状態でAIの選択が悪化する問題があるためです。事務所側でも、用途ごとに接続を分けたほうが安定します。全部つないでから絞り込むより、必要なものから足すほうが早く落ち着きます。

三つ目は、権限の持ち主を決めないまま接続してしまう失敗です。職員個人のアカウントで動く構成は、その職員が退職したときに処理が止まります。逆に事務所共通の強い権限で動かすと、誰の操作か分からなくなります。第三の設計を先に置く理由がここにあります。

回避策は共通していて、接続を増やす前に棚卸し表を更新する順番を守ることです。表を後追いで作ろうとすると、抜けが出やすくなります。接続の追加と表の更新を同じ手続の中に置いておくと、この抜けは起きにくくなります。

事務所側の工数と体制

接続設計の工数は、既存システムの構成で振れます。クラウドサービスに集約されている事務所なら、管理画面から権限を確認して一覧化するだけで進みます。オンプレミスの会計システムを使っている事務所は、接続の可否から調べる作業が加わります。

体制としては、接続の管理を一人に集約するほうが安定します。棚卸し表と承認記録が一箇所にまとまるためです。一方、どの操作で人の承認を挟むかの判断は、業務を知っている有資格者が持ちます。管理と判断を分けつつ、記録は一本化する形です。

生成AIで短縮できるのは、接続先一覧の下書きと承認地点の候補出しです。システム側の仕様確認とベンダーへの照会は短縮できません。ロードマップが示す領域は今後の実装に関わるため、確認の頻度そのものが増える面もあります。

料金設計の面では、接続設計を初期構築の一部として受けるか、独立した診断として切り出すかで分かれます。初期構築に含めると、構築が終わった後の見直しが有償にしづらくなります。規格側の動きが続く領域なので、定期的な見直しを別枠にしておくほうが、事務所側も顧問先側も継続しやすくなります。

顧問先向けに同じ整理を提供する場合、事務所自身の接続設計が済んでいるかどうかが説得力を左右します。自事務所で一度通してから顧問先支援に入る順番が、結果的に早く進みます。手元で一度通しておくと、顧問先のシステム担当と話すときに具体的な質問ができるようになります。

これから論点になること

一つ目は、エージェントの身元が標準化されたときの移行です。公表文はDemonstrating Proof of Possessionの確定と普及、ワークロード身元連携や標準的なトークン交換を通じた委譲の道筋づくりを挙げています。事務所が使うツールの側が対応した段階で、いまの設定を見直す作業が発生します。第三の設計を先に決めておく理由がここにもあります。

二つ目は、段階的な開示が実装されたときの接続方針の変化です。サーバー側が小さな入口を示す形になれば、いま用途ごとに分けている接続を統合できる可能性が出てきます。ただし統合すると権限の粒度が粗くなるため、統合するかどうかは事務所ごとの判断になります。

三つ目は、監査ログの扱いです。規格側に標準が置かれるかどうかで、事務所が自前で確保すべき記録の範囲が変わります。当面は接続先システム側のログに依存する構成が続くとみられるため、システムを乗り換えるときにログの保存期間を確認する運用が要ります。

よくある質問

ロードマップは仕様として確定したものですか

今後の方向を示す文書という位置づけです。公表文は、これらの重点領域に該当する仕様提案が優先的に審査されると説明しています（出典: Model Context Protocol Blog The New MCP Roadmap）。実装の作り込みは、仕様が固まってからで足ります。

五つの領域のうちどれを先に読めばよいですか

事務所の実務に近いのは、エージェントの身元と企業向けセキュリティ、そして基本要素の改善の二つです。残りはベンダー側が引き受ける比重が大きい領域になります。

いま接続を止めておいたほうがよいですか

止める判断と続ける判断のどちらが適するかは、事務所の運用状況によります。実務では、接続先を用途ごとに絞り、権限の持ち主と承認地点を決めたうえで運用を続ける形が採られています。

監査ログはどう残せばよいですか

規格側に標準が置かれていない現状では、接続先システム側のログと事務所側の記録を併用する形が採られています。誰がいつ確認するかまで決めておかないと、記録は事故のあとに初めて開かれることになります。

顧問先への説明には何を書きますか

AIが接続している事務所内システムの一覧、AIができる操作の区分、人の承認を挟む地点、最終確認者が有資格者であること。この四項目を一枚にまとめる形が機能しています。

AIエージェントを止める判断はどこで下しますか

総務省と経済産業省のAI事業者ガイドライン（第1.2版）では、判断が必要となる事項を重要度に応じて整理し、人間の判断を適切に介在させる仕組みの構築が重要になる旨が留意点として整理されています。事務所では、元に戻せない操作と顧問先に影響が及ぶ操作を候補として洗い出す方式が採られています。

参考文献

• Model Context Protocol Blog The New MCP Roadmap
• Model Context Protocol 公式ロードマップ
• 経済産業省 AI事業者ガイドライン（第1.2版）
• 総務省 AI事業者ガイドライン
• e-Gov法令検索 個人情報保護法第27条
• 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等について

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