MCP新ロードマップとは、AI連携仕様の次期開発で優先する5領域を示した工程表のことです。

事務所に入れたAIツールが、来年も同じつなぎ方で動くと言えるでしょうか。この記事では、MCPの中核メンテナが2026年8月22日に公表した新しいロードマップの5領域を読み解き、士業事務所が業務システムとAIをつなぐ前に確認しておく項目を工程の形で整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、仕様の内容は策定主体の公表資料で確認しています（出典: Model Context Protocol Blog The New MCP Roadmap）。

ロードマップが5領域に組み替わった意味 事務所の設備投資にどう効くか

結論から言えば、今回のロードマップは新しい仕様バージョンの告知ではありません。中核メンテナと作業部会が、次の仕様サイクルでどこに審査の時間を使うかを宣言した文書です。事務所の立場では、いま導入しようとしているツールが今後どちらの方向へ動くのかを読むための材料になります。

MCPは、AIモデルと外部のツールやデータをつなぐための共通仕様です。2025年12月にAnthropicがLinux Foundation傘下のAgentic AI Foundationへ寄贈し、現在は同財団のプロジェクトとして運営されています。ロードマップは中核メンテナのDavid Soria ParraとDen Delimarskyの連名で公表され、公開日は2026年8月22日と記載されています（出典: Model Context Protocol Blog The New MCP Roadmap）。

新しい優先領域は5つです。第一がエージェント型メッセージングの基本要素、第二がHTTPネイティブ転送の統一と堅牢化、第三がエージェントのアイデンティティと企業向けセキュリティ、第四が基本要素そのものの改善、第五がSDKの開発者体験です。直前の版は転送の進化と拡張性、エージェント間通信、ガバナンスの成熟、企業対応の4領域だったので、並びが組み替わったことになります。

組み替えの背景として押さえておきたいのが、直前のサイクルで実際に何が入ったかです。2026年7月28日の仕様リリースで、プロトコルレベルのセッションと初期化ハンドシェイクが廃止され、サーバが状態を保持せずに水平方向へ拡張できるようになりました。クライアントは接続前にサーバの対応バージョンと機能を問い合わせられるようになり、一覧結果のキャッシュも可能になっています。事務所側の実務にとっては、AI連携を担うサーバを社内に置くか外部に委ねるかの選択肢が広がった、という意味を持ちます。ステートレス化が事務所の改修計画にどう効くかは、別稿で期間を区切って整理しています（MCPのステートレス化で変わる事務所のAI連携 12か月で組む改修計画）。

読み手として忘れずにおきたいのは、ロードマップに並んだ項目がすべて仕様として確定するわけではないという点です。優先領域に該当する仕様拡張提案が優先的に審査されるという運用上の宣言であって、採否はこれからの議論に委ねられています。事務所が設備投資の判断をするときは、ロードマップに載ったこと自体ではなく、すでに仕様に入った機能を土台に考えるほうが安全側に倒れます。

業務システムとAIをつなぐ前の7確認 どこを事務所が決めるか

結論を先に置くと、確認すべきは技術仕様ではなく、どのデータがどの経路で外に出るかと、誰の権限で動いているかの2点です。技術の詳細はベンダーの仕事ですが、この2点は事務所が決めるほかありません。

第一の確認は、接続先サーバの所在です。事務所の中に立てるのか、ベンダーのクラウドにあるのか、第三者が公開しているものを使うのか。所在が変われば、データがどの国のどの事業者の設備を通るかが変わります。契約書や利用規約に書かれたデータの保管場所を、導入前に読んでおきます。

第二の確認は、認可の方式です。ロードマップの第三領域では、これまでのMCPの認可が人がブラウザで承認する形を前提としてきた点が課題として挙げられています。今後は、クラウド上のワークロードとして動くエージェントが自分のアイデンティティで、あるいは不在のユーザーに代わって呼び出す場面が増えるという見立てです。そこで作業の対象に挙がっているのが、所持証明であるDPoPの確定と普及、ワークロード・アイデンティティ・フェデレーション、企業向け認可拡張の裏側にあるID-JAGグラント、そして標準的なトークン交換です（出典: Model Context Protocol Blog The New MCP Roadmap）。事務所としては、貼り付けたAPIキーや期限の長いトークンで運用していないかを、まず棚卸しします。

第三の確認は、企業向け認可拡張への対応状況です。企業が管理する認可の仕組みは拡張として提供されており、安定版になったことが公表されています。導入候補のツールがこの拡張に対応しているかどうかを、ベンダーに書面で確認しておくと、後から社内の認証基盤へ寄せるときの手戻りが減ります。

第四の確認は、転送方式です。第二領域では、リモートサーバが通常のHTTPワークロードと変わらなくなったことを踏まえ、ローカルのサーバも標準入出力の上でStreamable HTTPを話す方向へ統一する構想が示されています。事務所の手元で動かすツールと、クラウドで動かすツールの設定が将来的に揃うという話なので、いま両方を別々に管理している事務所ほど、統一後の運用を先に想像しておく価値があります。

第五の確認は、ツールの数です。第四領域では、百個のツールを持つサーバに接続すると、利用者が何も尋ねないうちからその全体をモデルが読み込むことになり、選択の精度も落ちるという課題が挙げられています。対策として段階的な開示の取り組みが始まると記されています。事務所の運用では、ひとつのAIに全部つなぐのではなく、業務ごとに接続先を絞る設計が当面は堅実です。

第六の確認は、権限の粒度です。誰がどのツールを呼べるかを役職や担当案件で分ける設計になっているかを見ます。権限設計の具体的な項目立ては、別稿で整理しています（MCP連携の権限設計 士業事務所が詰める7項目）。

第七の確認は、監査証跡です。誰がいつどのツールを呼び、何が返ってきたかを後から追える形にしておきます。ログの設計は、監査対応だけでなく、顧問先から説明を求められたときの材料にもなります（MCPの監査ログをどう残すか 士業事務所の証跡設計）。

ベンダーへの確認事項を漏れなく並べるために、次のようなプロンプトで下書きを作る使い方があります。

あなたは士業事務所の情報システム担当を支援するアシスタントです。
以下の前提で、AI連携ツールの導入前にベンダーへ確認する質問リストを作ってください。

【事務所】社会保険労務士事務所、有資格者2名・補助者4名
【つなぎたい先】勤怠管理システム、給与計算システム、社内の共有フォルダ
【懸念】顧問先の個人データが外部へ出る経路、権限の粒度、ログの保存期間

出力形式:
1. 質問文（担当者がそのままメールに貼れる形で）
2. 期待する回答の型（例: 保管リージョン名、対応の有無、保存日数）
3. 回答が得られなかった場合に取り得る代替案

制約:
- 法令の解釈や適法性の評価はしない
- 推測で仕様を断定せず、不明な点は「要確認」と書く
- 表は使わず、番号付きの箇条書きで

導入後の棚卸しには、次の形が使えます。

以下の接続一覧を読み、リスクの観点から並べ替えてください。

【接続一覧】（ツール名 / 接続先 / 認証方式 / 誰が使うか / 取得できるデータ）
（貼り付け）

出力してほしいもの:
- 認証方式が長期有効なキーに依存している接続
- 取得できるデータの範囲が用途に対して広すぎる接続
- 利用者が限定されていない接続

制約:
- 貼り付けた一覧に書かれていない情報を補完しない
- 各項目に「なぜそう並べたか」を1文で添える
- 結論の断定ではなく、確認すべき論点として書く

七つの確認のうち、第一から第五まではベンダーへの照会で埋まりますが、第六と第七は事務所の中でしか決められません。この二つを先に決めてから照会に入ると、話が早く進みます。

顧問先データが外部サーバへ渡る前に決める3点 守秘義務との接続

結論から言えば、MCPの仕様がどう変わっても、事務所が背負う秘密保持の義務は変わりません。変わるのは、どこまでが事務所の管理下かという線の引き方です。

士業の秘密保持は、それぞれの業法に置かれています。弁護士については弁護士法第23条が職務上知り得た秘密を保持する権利と義務を定めています。税理士については税理士法第38条が、正当な理由なく税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならない旨を定めており、税理士でなくなった後も同様とされています。社会保険労務士については社会保険労務士法第21条に同趣旨の規定があります。AI連携で顧問先のデータが外部サーバへ渡る設計を考えるときは、これらの規定との関係が論点になります。

第一に決めるのは、外部サーバへ渡すデータの範囲です。MCPの接続先は、事務所の業務システムそのものを読みに行く形になることがあります。読み取り専用にするか、どのテーブルやフォルダまで見せるかを、接続を作る時点で決めておきます。あとから絞るより、最初に狭く作って必要に応じて広げるほうが、説明の筋も通しやすくなります。

第二に決めるのは、AIベンダーのデータ利用方針の確認です。Anthropicは商用サービスの入出力を既定でモデルの訓練に使用しない旨を利用規約で明記しています（出典: Anthropic Commercial Terms of Service）。OpenAIはビジネス向けプランについて、既定で顧客のビジネスデータを訓練に使用しないと公表しています（出典: OpenAI Enterprise privacy）。MCPを使う場合、データはAIベンダーだけでなく接続先サーバの運営者にも渡ることがあるので、両方の方針を確認しておきます。

第三に決めるのは、顧問先への説明です。委任契約や業務委託契約に、外部サービスの利用範囲を書く運用を採る事務所があります。書き方は事務所ごとに異なりますが、どの範囲のデータが事務所の外へ出るのかが読み取れる粒度にしておくと、後から問われたときに答えられます。顧問先によっては、自社のデータを外部AIに通すこと自体を契約で制限している場合があるので、受任時に相手方の社内規程を確認する流れを入れておく事務所もあります。

エージェントのアイデンティティが仕様として整備されていくと、この説明はやりやすくなる見込みです。人が承認する形から、エージェント自身の身元と委任の範囲を機械的に示す形へ移れば、誰の権限で何をしたかが記録として残ります。ただし現時点では作業中の領域なので、いまの運用は人が承認する前提で組んでおくのが現実的です。

MCP導入で起きやすい3つの失敗と、その手前で止める方法

ひとつ目は、仕様の更新に追随できないまま運用を止めてしまう失敗です。2026年7月28日のリリースではセッションと初期化ハンドシェイクが廃止され、廃止の手続そのものも新しい機能ライフサイクルと廃止方針に沿って進められました（出典: Model Context Protocol Blog The New MCP Roadmap）。自作のサーバを持っている事務所は、廃止予定の告知を追う担当を決めておかないと、ある日つながらなくなります。

ふたつ目は、権限を広く取りすぎる失敗です。設定が面倒だからと管理者権限で接続を作ると、AIが業務システムの全範囲を読めてしまいます。誰がどこまで見られるかの設計は、接続を作る前に紙に書いてから着手します。

三つ目は、ロードマップに載った機能を前提に運用を組む失敗です。優先領域に入ったからといって、その仕様が確定したわけではありません。段階的な開示や統一された転送方式は、いまは検討中の項目です。導入判断は、すでに仕様に入っているものと、拡張として安定版になっているものを土台にします。

導入と維持にかかる費用と工数、誰が持つか

費用の中心は、AIモデルの利用料と、接続先サーバを動かす基盤の費用です。モデルの利用料は各社の公開価格で見積もれますが、MCP経由の呼び出しは、人が手で入力する場合よりトークン消費が増える傾向があります。ツールの一覧そのものがモデルへ渡るためで、接続するツールの数が増えるほど固定的に乗る分が大きくなります。段階的な開示が仕様として入るまでは、接続を絞ることが費用対策も兼ねます。

工数のほうは、初期の設計と接続作りに数日規模、その後の維持に月あたり数時間という見方が現実的です。維持の中身は、仕様更新の追随、権限の見直し、ログの点検です。この三つを誰が持つかを決めておかないと、導入した人が異動した時点で止まります。

外部の開発会社に委託する場合も、仕様更新の追随を契約に含めるかどうかで見積もりが変わります。含めない契約にしておいて、更新のたびに追加費用が発生する形になっている例があるので、契約前に確認しておくと予算が読めます。

アイデンティティ整備が進んだとき、事務所の何が変わるか

今後の論点は、エージェントに身元が付くことで、責任の所在をどう記録するかに移っていきます。現在は人がブラウザで承認するため、誰の判断で動いたかは承認した人にひもづきます。ワークロードとしてのエージェントが自分の身元で動くようになると、承認者と実行者が分かれます。士業の実務では、最終的な判断を有資格者が行う構造をどう記録に残すかが、そのまま説明責任の設計になります。

もうひとつの論点は、顧問先側の要求です。大企業の顧問先ほど、自社の認証基盤で事務所側のアクセスを管理したいという要求を出してきます。企業が管理する認可の拡張が普及すれば、この要求に応える技術的な手段は整います。事務所としては、対応できるツールを選んでおくことが、数年先の取引条件に効いてくる可能性があります。AI連携基盤をめぐる標準化の動きは、MCPだけでなくエージェント間通信の仕様も含めて広がっているので、あわせて見ておくと選定の軸がぶれません（AAIFの4仕様が出そろった 士業事務所のツール選定7判断軸）。

よくある質問

MCPの新ロードマップで仕様は変わったのですか

変わっていません。ロードマップは次の仕様サイクルで優先的に審査する領域を示した文書であり、新しい仕様バージョンの告知ではないと明記されています（出典: Model Context Protocol Blog The New MCP Roadmap）。仕様として確定した内容は、2026年7月28日のリリースに含まれるものです。

小規模な事務所でもMCPを導入する意味はありますか

業務システムを複数使っていて、そのデータをAIに読ませたい場面があるなら意味があります。逆に、扱うデータがほぼ表計算ソフトの中にあるなら、ファイルをその都度渡す運用のほうが管理は簡単です。接続を作るほど、権限とログの管理対象が増える点を見込んでおくと判断しやすくなります。

顧問先のデータを外部のMCPサーバへ渡してよいですか

可否は、渡すデータの内容と、顧問先への説明がどこまでできているかで変わります。事務所として線を引くなら、特定個人を識別できる情報や機微な相談内容は渡さず、統計化した情報や公開情報に限る運用から始める形が扱いやすいところです。各士業の秘密保持規定との関係が論点になるため、所属会の指針も確認しておくと判断材料が増えます。

企業向け認可拡張とは何ですか

企業が自社の認証基盤でMCPサーバへのアクセスを管理するための仕組みで、MCPの拡張として提供され、安定版になったことが公表されています（出典: Model Context Protocol Blog The New MCP Roadmap）。事務所側では、顧問先の情報システム部門から対応を求められる場面が出てくる項目です。

接続するツールは何個までにすべきでしょうか

上限の数値を示す公表資料は見当たりません。ロードマップでは、ツールの数が増えるほど選択の精度が落ち、利用者が尋ねる前からその全体をモデルが読み込む点が課題として挙げられています。業務ごとに接続先を分け、ひとつの用途に必要な範囲だけをつなぐ設計から始める運用例があります。

自作のMCPサーバを持つ場合、何を追いかければよいですか

仕様の変更履歴と、機能の廃止方針を追う担当を決めておく形が現実的です。2026年7月28日のリリースでは、廃止の手続が新しいライフサイクル方針に沿って進められました（出典: Model Context Protocol Blog The New MCP Roadmap）。廃止の告知から実際に使えなくなるまでの期間内に改修できる体制かどうかが、自作を選ぶかどうかの分かれ目になります。

ロードマップの議論に事務所が関わることはできますか

できます。仕様拡張提案の仕組みと作業部会は公開されており、参加方法も公表されています（出典: Model Context Protocol Blog The New MCP Roadmap）。士業の実務から見た要件は、開発側からは見えにくい部分なので、実務者の声が反映される余地はあります。

参考文献

• Model Context Protocol Blog The New MCP Roadmap（2026年8月22日）
• e-Gov法令検索 弁護士法第23条
• e-Gov法令検索 税理士法第38条
• e-Gov法令検索 社会保険労務士法第21条
• Anthropic Commercial Terms of Service
• OpenAI Enterprise privacy

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