MCP 2026-07-28仕様とは、AIと業務システムをつなぐ規格の最新版のことです。

会計ソフトや顧客管理システムをAIから直接触らせる仕組みが、2026年7月28日の仕様改訂で作り直しになりました。この記事では、何が変わったのか、事務所の業務システム連携にどう効くのか、顧問先データを流す前に決めておくことは何かを、一次情報だけで整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。仕様の内容はModel Context Protocol公式の変更履歴の原文で、法令の条文はe-Gov法令検索の原文で確認しています。

ステートレス化で消えたもの、増えたもの

2026-07-28仕様の中心は、MCPが双方向の状態保持型プロトコルから、単純なリクエスト・レスポンス型に変わったことです。理由は運用のしやすさで、結果としてサーバをサーバレス基盤やエッジ環境に置けるようになりました。士業事務所の目線で言えば、常時起動のサーバを抱えなくても業務システム連携が成り立つ、という変化です。

技術的に消えたものは大きく三つあります。第一に、接続の最初に一度だけ行っていた initialize と notifications/initialized のやりとりが廃止されました。代わりに、すべてのリクエストが自分でプロトコルバージョンとクライアント能力を _meta に載せて名乗ります。第二に、Streamable HTTP トランスポートから Mcp-Session-Id ヘッダとプロトコルレベルのセッションが取り除かれました。第三に、ping と logging/setLevel、notifications/roots/list_changed が廃止されています。いずれも公式変更履歴に記載された内容です。

増えたものもあります。server/discover という新しい呼び出しが追加され、サーバは自分が対応するプロトコルバージョンと能力、身元を返すことが求められます。長時間かかる処理は Tasks という公式拡張に移り、サーバがタスクの控えを返してクライアントが tasks/get で状況を取りに行く形になりました。サーバが処理の途中で追加情報を必要とする場面は、Multi Round-Trip Requests という新しい型でまとめられ、サーバは入力要求を返し、クライアントが同じリクエストを再送するときに答えを添えます。

前の版は2025-11-25で、今回が五回目の仕様リリースにあたります（出典: Claude公式ブログ）。同ブログによれば、MCPのSDKは月間4億回のダウンロードを超え、この1年で4倍に伸びたとされています。Claudeのコネクタディレクトリに掲載されたMCPサーバは950を超えるとも記載されています。規格として枯れる前に大改訂が入ったことになりますが、非推奨になった機能には最低12か月の猶予期間が設けられる方針が同時に決まりました。この期間の考え方も変更履歴に明記されています。

もう一つ、地味ですが実務に効く変更があります。一覧を返す呼び出しの結果に、キャッシュの有効期間と共有範囲を示す欄が必須になりました。クライアントが結果を一定時間手元に持てるようになるため、同じ問い合わせを繰り返すことによる無駄な通信が減ります。事務所の使い方でいえば、職員が同じ画面を何度も開くような場面で応答が軽くなる方向の変更です。認可の面でも、認可応答に発行元を示す値を含めることが推奨され、クライアント側がそれを照合する形が定められました。細かい話に見えますが、なりすましのような経路を潰す変更で、顧問先データを扱う事務所には効いてきます。

事務所にとっての最初の論点は、いま使っている連携が新旧どちらの仕様で動いているかです。ベンダーが提供するMCPサーバなら、対応時期はベンダーの告知で追えます。事務所で内製したものがあるなら、猶予期間のうちに作り直す計画が要ります。

事務所のシステム連携をMCPで組み直す5ステップ

結論から書くと、いま着手すべきは棚卸しと認可設計であって、実装は後回しで構いません。仕様が変わったばかりで、ベンダー側の対応も出そろっていないためです。順番を守れば、対応が出そろった時点で短期間で乗り換えられます。

第一に、事務所が現在つないでいる、あるいはつなぎたい業務システムを書き出します。会計ソフト、給与計算、顧客管理、申告ソフト、文書管理、グループウェアあたりが典型です。それぞれについて、AIに読ませたいデータと、AIに書き込ませたい操作を分けて書き出します。この時点で読み取りと書き込みを分けておくと、後の権限設計が一気に楽になります。

第二に、各ベンダーのMCPサーバが2026-07-28仕様に対応しているかを確認します。新仕様では server/discover を呼べばサーバが対応バージョンを返すため、技術的な確認は一度の呼び出しで済みます。会計クラウドの連携基盤については、freee Agent Hubの正式提供開始と事務所の内製判断でも触れたとおり、ベンダー製で足りる範囲と自前で組む範囲の線引きが先に来ます。

第三に、認可の設計です。新仕様では認可が実運用のOAuth 2.0とOpenID Connectに寄せられ、Entra IDやOktaのような企業向けIDプロバイダと素直につながるようになりました。事務所の実務では、職員のアカウントをIdPで一元管理し、MCP経由のアクセス権をそのグループに紐づける形が扱いやすくなります。ここで守るべき原則は二つで、読み取り専用から始めること、顧問先ごとにアクセス範囲を切ることです。

第四に、監査ログの設計です。セッションが消えてリクエスト単位で完結する形になったため、どのリクエストが誰の権限で何を触ったかが素直に残せます。記録項目の考え方は事務所のAI利用ログを監査証跡にする保管設計に整理したものがそのまま使えます。MCP連携ではこれに加えて、呼び出したツール名、対象の顧問先識別子、読み取りか書き込みかの区別を残しておくと、後から説明できる形になります。

第五に、有資格者の最終確認工程を手順の中に置きます。MCP経由でAIが取ってきた数字は下書きであって、成果物ではありません。試算表の異常検知でも、申告書の下書きでも、AIの出力に有資格者が目を通して確定させる工程を明示的に挟みます。この工程を省いた運用は、事務所の品質管理の観点から後戻りができなくなります。

以下は、MCP経由で取得した月次データから異常点の候補を洗い出させるプロンプト例です。実在の顧問先情報は入れず、架空のA社として書いています。

あなたは会計事務所の月次レビュー担当者です。
以下の試算表データ（架空のA社）を読み、前月比・前年同月比で
説明のつかない動きがある勘定科目を最大10件まで挙げてください。

出力形式:
1. 勘定科目
2. 変動額と変動率
3. 考えられる原因の仮説を2つ
4. 担当者が顧問先に確認すべき質問文

制約:
- 断定はせず、必ず「確認が必要な候補」として提示すること
- 会計処理の適否について結論を書かないこと（有資格者が判断します）
- データから読み取れないことは「データ不足」と明記すること

試算表データ:
{ここにMCP経由で取得したデータを貼る}

次は、ベンダーのMCPサーバを事務所に入れる前の確認事項を洗い出させるプロンプト例です。仕様の変更点を踏まえた確認項目を、自分の言葉で整理するために使います。

あなたは士業事務所の情報システム担当者です。
外部ベンダーが提供するMCPサーバを事務所に導入する前の
確認チェックリストを作成してください。

前提:
- 事務所は顧問先の会計データ・給与データを扱う
- MCP 2026-07-28仕様（ステートレスコア、OAuth/OIDC準拠の認可）を想定

チェックリストに含める観点:
1. 対応プロトコルバージョンの確認方法
2. 認可方式とIDプロバイダ連携の可否
3. 読み取り専用スコープの有無
4. 入力データがモデルの学習に使われるかどうかの記載箇所
5. ログの保存場所・保存期間・削除依頼の手段
6. サーバの稼働地域（データの所在地）
7. 障害時の連絡経路

各項目は、ベンダーの公式ドキュメントのどこを見れば確認できるかを
併記する形で出力してください。

手順を通して意識したいのは、MCPは配管であって判断機構ではないという点です。配管が新しくなったからといって、判断の責任分担は1ミリも変わりません。

顧問先データをMCPで流す前に決める3つのこと

まず決めるのは、そのMCPサーバの先で入力データがどう扱われるかです。MCPは規格であって、データの扱いを決めるのは接続先のベンダーとAIモデルの提供者です。事務所が確認するのは、入力が学習に使われるか、ログがどこに何日残るか、稼働地域はどこかの三点になります。いずれもベンダーの公式ドキュメントに書かれている事項で、書かれていなければ問い合わせて記録に残す運用が現実的です。

次に決めるのは、守秘義務との整理です。士業の守秘義務は各法に定めがあり、条文の書きぶりはそれぞれ異なります。税理士については税理士法第38条が、正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、又は窃用してはならないと定めています。弁護士については弁護士法第23条が、その職務上知り得た秘密を保持する権利を有し、義務を負うと定めています。社会保険労務士については社会保険労務士法第21条が、公認会計士については公認会計士法第27条が、同趣旨の規定を置いています。条文の当てはめは有資格者の領域ですので、ここでは条文の存在と文言の確認に留めます。

三つ目は、外部サービスの位置づけです。個人情報の取扱いを外部に委ねる形になる場合、個人情報保護法第25条は、委託を受けた者に対する必要かつ適切な監督を行わなければならないと定めています。同法第27条は第三者提供の制限を定め、委託に伴う提供は第三者に該当しないものとする旨も同条に置かれています。自分の事務所のMCP連携がこのどちらの枠組みに当たるかは、契約の形と実際のデータの流れで変わりますので、ベンダーとの契約書を確認したうえで整理する論点になります。生成AIの利用と個人データの関係については、個人情報保護委員会が公表資料を出しており、一次情報として押さえておく価値があります。

事務所規程に落とすなら、書く項目は絞れます。MCP経由で接続してよいシステムの一覧、接続に使う認可の経路、読み取りと書き込みの権限を誰が持つか、ログの保存期間、顧問先への説明の型、そして接続を解除する手順です。運用例として、顧問先との契約書または業務案内に、AIを利用した処理を行う旨と、有資格者が最終確認を行う旨を明記している事務所があります。説明の型を先に決めておくと、顧問先から質問が来たときに担当者ごとに答えがぶれません。

もう一点、新仕様で Sampling 機能が非推奨になった影響があります。Sampling はサーバ側がクライアント側のモデルを間接的に呼び出す仕組みで、公式には各社のモデルAPIと直接つなぐ形への移行が示されています。データがどこを通るかが見通しやすくなる方向の変更ですので、事務所としてはむしろ説明しやすくなります。

MCP連携でつまずいた3つの型と回避策

一つ目は、書き込み権限を最初から渡してしまう型です。読み取りだけで足りる用途なのに、ベンダーの初期設定のまま全権限で接続し、AIが誤ってデータを更新してしまう事故が起こり得ます。回避策は単純で、最初の接続は読み取り専用に限定し、書き込みが必要な業務が固まってから、その業務に限って権限を足します。新仕様では認可がOAuthとOIDCの標準に寄ったため、スコープを細かく切る運用が取りやすくなっています。

二つ目は、接続が切れたときの扱いを決めていない型です。2026-07-28仕様では、応答ストリームの再開機能が廃止されました。途中で切れた処理は失われ、クライアントが新しいリクエストとして出し直すことになります。これは変更履歴に明記された挙動です。長時間の処理を投げっぱなしにする運用は成り立たなくなりますので、大量データの処理はTasks拡張の形に寄せるか、処理単位を小さく分けて投げる設計に変えます。切れたことに気づかないまま処理が終わったつもりで進むのが、一番危ない状態です。処理の完了をログで確認する工程を、担当者の手順に入れておくと事故が減ります。

三つ目は、誰が何を接続したか分からなくなる型です。職員が個人のアカウントで勝手にMCPサーバをつなぎ、顧問先データが把握できない経路を通るケースが典型です。回避策は、接続を事務所のIdP経由に限定し、個人アカウントでの接続を運用上認めない形にすることです。あわせて、接続中のサーバ一覧を月次で棚卸しし、使っていないものを外します。棚卸しの記録があれば、顧問先や職能団体から質問が来たときに、経路を説明できます。

MCP連携の費用・工数・体制の目安

費用は三層に分かれます。AIモデルの利用料、MCPサーバ側のサービス利用料、そして自前でサーバを持つ場合の稼働費用です。三層目については、ステートレス化によりサーバレス基盤に載せられるようになったため、常時起動のサーバを抱える構成より安く済ませられる余地が生まれました。実際の金額はベンダーの公開価格で確認するのが確実で、ここでは構成が変わったという事実だけを押さえます（根拠: 前掲の公式変更履歴およびClaude公式ブログ）。

工数の考え方も整理しておきます。ベンダー製のMCPサーバをそのまま使う場合、事務所側の作業は認可設定と権限設計、テスト、規程への追記が中心になります。自前で組む場合は、これに設計と実装、保守が乗ります。自前実装を選ぶなら、非推奨機能の猶予期間が最低12か月と定められている点を計画に織り込みます（根拠: 公式変更履歴の feature lifecycle 記載）。

体制は、技術を触る担当と、規程と説明責任を持つ担当を分けるのが扱いやすい形です。前者は情報システム担当や外部のベンダー、後者は事務所の管理者層になります。分けておくと、便利さを追う力と、止める判断をする力の両方が働きます。小規模事務所で兼任せざるを得ない場合でも、接続を増やす判断だけは所長が承認する運用にしておくと、野良接続が起きにくくなります。

ステートレス化の次に来る論点

配管が標準化されると、次に問われるのは中身の設計です。どの業務データをAIに渡すか、どこまでを下書きとして扱うか、成果物として確定させる工程を誰が持つか。この三つは規格が何回変わっても事務所側で決めるしかありません。

短期的には、ベンダー各社の対応時期が分かれることによる過渡期の混乱が論点になります。旧仕様のまま動いているサーバと新仕様のサーバが事務所内に混在する期間が生まれ、どちらで動いているかを把握していないと、障害時の切り分けができません。接続一覧に対応バージョンの欄を足しておくと、この期間を乗り切りやすくなります。

中期的には、認可がIdPに寄ることで、事務所のアカウント管理そのものが業務品質に直結する論点になります。職員の入退所に伴う権限の付け外しが、そのまま顧問先データへのアクセス制御になるためです。AIツールの選定より先に、アカウント管理の棚卸しが効いてくる構図です。Anthropicが公開した機能群の広がりについてはAPIなき士業業務も操作対象になった件でも触れており、接続経路が増えるほど権限設計の重みが増します。

よくある質問

MCPは事務所に必須の技術ですか

必須ではありません。MCPはAIと外部システムをつなぐための共通規格であり、AIを文章生成にだけ使っている事務所には当面関係しません。会計ソフトや顧客管理システムのデータをAIに直接読ませたい段階になって初めて検討対象になります。

2026-07-28仕様に対応していない既存の連携はすぐ止まりますか

すぐには止まりません。公式の変更履歴には、非推奨となった機能について最低12か月の猶予期間を設ける方針が示されています（出典: 公式変更履歴）。ただし新規に組むものは新仕様に寄せるのが素直で、既存の内製サーバは猶予期間のうちに移行計画を立てる形になります。

顧問先の同意はどこまで取ればよいですか

同意の要否と範囲は、扱うデータの性質と契約の形で変わります。個人データの取扱いを外部に委ねる形になる場合、個人情報保護法第25条が委託先への監督について定めています。実務としては、AIを用いた処理を行う旨と有資格者が最終確認を行う旨を業務案内や契約書に明記し、顧問先に説明する運用を採る事務所があります。個別の判断は有資格者が行う領域です。

内製と既製品のどちらを選ぶべきですか

判断の分かれ目は、つなぎたいシステムに公式のMCPサーバがあるかどうかです。あるなら既製品から始めるほうが保守の負担が軽くなります。無い場合や、事務所固有の業務フローに合わせた処理が必要な場合に、内製の検討が現実味を帯びます。仕様が大きく動いた直後は、内製の保守コストが読みにくい時期でもあります。

ステートレス化で事務所側に直接のメリットはありますか

あります。サーバレス基盤で動かせるようになったことで、常時起動のサーバを持たずに連携を維持できる構成が取りやすくなりました。加えて、セッションが無くなったことでリクエスト単位の記録が素直に残せるため、監査証跡の設計がしやすくなっています。

職員が勝手にMCPサーバをつなぐのを防ぐ方法はありますか

接続経路を事務所のIDプロバイダ経由に限定し、個人アカウントでの接続を運用上認めない形が現実的です。あわせて接続中のサーバ一覧を定期的に棚卸しし、使っていないものを外す運用を組み合わせます。技術的な遮断だけでなく、規程と棚卸しの両輪で運用する形になります。

参考文献

• Model Context Protocol 2026-07-28 Key Changes（公式変更履歴）
• Claude公式ブログ Bringing MCP 2026-07-28 to Claude
• e-Gov法令検索 税理士法
• e-Gov法令検索 弁護士法
• e-Gov法令検索 個人情報の保護に関する法律
• 個人情報保護委員会

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