MCPサーバーとは、AIから業務システムのデータや操作を呼び出させる接続口のことです。

顧客管理システムの情報をAIに読ませたいが、毎回コピーして貼るのは現実的ではない。この壁を越える仕組みがMCPサーバーです。2026年7月28日版の仕様では、プロトコルレベルのセッションが廃止され、通常のHTTP基盤の上で動く構造になりました（出典: Model Context Protocol Key Changes）。本記事では、士業事務所が顧客管理や会計システムとAIをつなぐサーバーを自前で用意する場合の工程を7つに分けて整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。仕様は公式ドキュメントの原文で、法令の条文はe-Gov法令検索で確認しています。

ステートレス化した仕様が事務所の構築に与える影響

まず仕様の現在地を押さえます。公式の変更点一覧によれば、2026-07-28版では、Streamable HTTPトランスポートからプロトコルレベルのセッションとMcp-Session-Idヘッダーが削除されました。またinitializeとnotifications/initializedのハンドシェイクが廃止され、すべてのリクエストが自らのプロトコルバージョンとクライアント能力を_metaに載せて運ぶ形になっています（出典: Model Context Protocol Key Changes）。

事務所が自前でサーバーを立てる立場から見ると、この変更は構築の敷居を下げます。セッション管理が不要になるということは、リクエストごとに独立して処理できるということであり、負荷分散やスケールの設計が普通のWebアプリケーションと同じ考え方でできるようになります。逆に、サーバー側で呼び出しをまたいだ状態を持ちたい場合は、サーバーが発行したハンドルを通常のツール引数として受け渡す形に設計を変える必要があると仕様は説明しています。

もうひとつ、事務所の運用に効く変更があります。tools/listなどの一覧系の結果にttlMsとcacheScopeの指定が必要になった点です。ttlMsは鮮度のヒントを示すミリ秒値で、cacheScopeはpublicまたはprivateのいずれかを取り、共有される中間装置が応答をキャッシュしてよいかを制御します（出典: Model Context Protocol Key Changes）。顧客ごとに見せるツールが変わる設計にしている事務所では、cacheScopeの指定を誤ると、別の担当者に別の顧客向けの一覧が見えてしまう経路を作りかねません。ここは構築時に確認する箇所です。

認可まわりも締まりました。認可サーバーはRFC 9207に従って認可応答にissパラメータを含めることが推奨され、クライアントは記録済みの発行者と照合してから認可コードを引き換えることが求められます。さらに、クライアント資格情報は発行した認可サーバーに紐づくものとして扱い、別の認可サーバーで使い回さないこと、認可サーバーが変わったら再登録することが求められています（出典: Model Context Protocol Key Changes）。加えて、OAuth 2.0の動的クライアント登録は非推奨となり、Client ID Metadata Documentsが推奨される方向になりました。

移行判断の全体像はMCPステートレス化で士業事務所が確認する項目の記事に整理しています。本記事はその先、自所でサーバーを構築する場合の手順に絞ります。

顧客管理と会計システムをつなぐ7工程

工程を7つに分けます。第3工程と第5工程が事務所の判断が最も要る部分です。

第1工程は、つなぐ先の確定です。士業事務所で候補になるのは、会計システム、顧客管理システム、案件管理システム、文書管理システムの4系統です。会計であればfreeeやマネーフォワード、業務システムであればkintoneのようなクラウド基盤が候補になります。いずれもAPIが公開されているかを最初に確認してください（参考: freee Developers Community、cybozu developer network）。APIが無いシステムは、この段階で対象外にするのが賢明です。

第2工程は、読み取り専用から始める設計です。最初のサーバーは、データを読むツールだけを実装します。書き込みや更新のツールは実装しません。AIが業務システムに書き込む設計は、監査と巻き戻しの仕組みを整えてからでないと事故が重くなります。読み取りだけでも、資料を探す時間の削減という効果は十分に出ます。

第3工程は、公開するツールの粒度の設計です。ここが設計の勘所です。APIをそのまま1対1でツールにすると、AIが意図しない広い範囲のデータを取ってしまいます。たとえば顧客一覧を全件返すツールを置くのではなく、担当者と期間で絞った結果だけを返すツールを置く。ツールの設計そのものが権限設計になるという発想で組み立ててください。誰が何を見られるかの階層設計は士業事務所の生成AI権限設定に関する記事で整理しています。

第4工程は、認可の実装です。仕様が求める発行者の検証と資格情報の紐づけを実装します。事務所内部でしか使わないサーバーであっても、認可を省略した設計にはしないでください。省略した設計は、後から社外に出す判断が下りたときに作り直しになります。

第5工程は、監査ログの設計です。誰が、いつ、どのツールを、どの引数で呼んだかを残します。2026-07-28版では、OpenTelemetryのトレースコンテキストを_metaのキー（traceparent、tracestate、baggage）で伝播させる規約が文書化されました（出典: Model Context Protocol Key Changes）。既存の監視基盤があるなら、ここに合わせておくと後の追跡が楽になります。顧問先から問い合わせを受けたときに、どのデータがAIに渡ったかを答えられる状態にしておくことが、事務所としての説明責任の土台です。

第6工程は、検証です。まず担当者ひとりに絞って使ってもらい、想定外のデータが返っていないかを確認します。ここで見るのは便利さではなく、返ってきてはいけないものが返っていないかです。

第7工程は、運用ルールの明文化です。誰がサーバーに接続できるか、どのクライアントから接続してよいか、障害時の連絡先は誰かを文書にします。

ツール設計を検討する際に生成AIを使うためのプロンプト例を示します。実在の顧問先名は使わず、架空のA社として扱います。

あなたは業務システムの設計者です。以下の条件で、MCPサーバーが公開すべきツールを設計してください。

【事務所】税理士法人、有資格者4名・補助者6名、顧問先は法人が中心
【つなぐ先】クラウド会計システム（APIあり）、顧客管理システム（APIあり）
【使う人】補助者が、担当している顧問先の月次資料の所在を調べる用途
【制約】
- 読み取り専用（書き込みツールは作らない）
- 担当外の顧問先のデータは返らないこと
- 顧客の氏名や口座番号など、識別性の高い項目は既定で返さないこと

【出力】ツールごとに、
  (1) ツール名、(2) 入力パラメータと型、(3) 返す項目、(4) 返さない項目、
  (5) このツールで起こり得る情報の過剰取得と、その防ぎ方

設計上の懸念は「論点になる」という書き方で列挙してください。
法的な適否の判断は書かないでください。

もう1本、既存の設計をレビューさせるプロンプトです。

以下のMCPツール定義をレビューし、情報の過剰取得につながる箇所を指摘してください。

【前提】士業事務所の内部利用。利用者は補助者。顧問先データを扱う。
【ツール定義】（ここにツール名・入力スキーマ・返却項目を貼る）

【観点】
1. 引数の指定次第で担当外のデータが取れてしまう経路はあるか
2. 返却項目に、用途に対して過剰な識別情報が含まれていないか
3. 一覧系の結果に cacheScope の指定はあるか。private にすべきものが public になっていないか
4. エラー応答から内部構造が推測できてしまわないか

指摘ごとに、修正案を1つずつ添えてください。
断定的な評価ではなく、確認すべき論点として書いてください。

どちらも出力は設計の材料であって、採用するかどうかは事務所の判断です。特に返却項目の取捨は、守秘の設計そのものなので有資格者が確認する工程を挟んでください。

顧問先データをAIから触れるようにする前に決める3つのこと

MCPサーバーを立てるということは、AIが顧問先データに直接手を伸ばせる状態を作るということです。ここは規程の整備が先に来ます。

第1に、投入と参照の区別です。プロンプトに貼り付ける投入と違い、MCP経由の参照は、AIがいつ何を取りに行くかを人が事前に把握できません。取得の範囲を人が決めるのではなく、ツールの設計が決めるという構造になります。したがって、事務所規程には、何を貼ってよいかではなく、どのツールを公開してよいかという形で書く必要があります。プロンプト投入側のルールはプロンプトに個人情報を入れる前に決める運用ルールの記事に整理しています。

第2に、個人情報の取扱いです。個人情報保護法第27条は、個人情報取扱事業者が、法令に基づく場合など一定の場合を除き、あらかじめ本人の同意を得ないで個人データを第三者に提供してはならないと定めています（出典: e-Gov法令検索 個人情報の保護に関する法律）。MCPサーバーが自所の管理下にあり、AIクライアントも自所の契約下にある場合と、外部のクラウドサービスを経由する場合とでは、検討すべき論点が変わります。個人情報保護委員会は生成AIサービスの利用について注意喚起を公表していますので、あわせて確認してください（出典: 個人情報保護委員会）。

第3に、士業ごとの守秘義務との関係です。税理士については税理士法第38条が、税理士は正当な理由がなくて、税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならないこと、税理士でなくなった後も同様であることを定めています（出典: e-Gov法令検索 税理士法）。MCP経由の参照がこの規定との関係でどう位置づけられるかは、事務所として整理しておく論点です。日本税理士会連合会の案内も確認してください（出典: 日本税理士会連合会）。

規程に落とすなら、公開してよいツールの類型、ツール追加時の承認手順、接続を許すクライアントの限定、監査ログの保存期間、の4項目を書き分けます。外部の第三者が提供するMCPサーバーを使う場合の審査観点は外部MCPサーバーの安全性審査に関する記事にまとめています。

構築でつまずく3つの場面と回避策

第1は、ツールを作りすぎる場面です。APIのエンドポイントの数だけツールを用意すると、AIがどれを呼ぶべきか迷い、意図しないツールを呼びます。仕様は、tools/listの結果を決定的な順序で返すことを推奨しており、これはクライアント側のキャッシュとプロンプトキャッシュの効きを良くするためです（出典: Model Context Protocol Key Changes）。ツール数を絞ることは、精度とコストの両方に効きます。最初は3つから5つに絞ることをおすすめします。

第2は、古い仕様のまま作ってしまう場面です。2026-07-28版では、SSEストリームの再開性とメッセージ再送（Last-Event-IDヘッダーとSSEイベントID）が削除され、応答ストリームが切れた場合は新しいリクエストIDで出し直すことがクライアントに求められます（出典: Model Context Protocol Key Changes）。また、HTTP+SSEトランスポートは非推奨として整理されました。実装の参考にする記事やサンプルが古い版を前提にしていないか、着手前に確認してください。

第3は、監査ログを後回しにする場面です。動くものができると、ログは後でいいという判断に流れがちです。しかし顧問先から問い合わせを受けたときに答えられないログは、無いのと同じです。ツールを1つ作った時点でログの形も決めておくほうが、結果として早く終わります。

費用と体制をどう見積もるか

自前でサーバーを構築する場合の費用は、開発工数とホスティング費用に分かれます。ステートレス化によって、セッションを保持する常駐プロセスが不要になったため、サーバーレス基盤に載せる選択肢が現実的になりました。これは小規模事務所にとって、固定費を抑えられる方向の変化です。

開発工数は、読み取り専用のツールを3つから5つ作る規模であれば、既存APIのドキュメントが整っている前提で、数日から二週間程度が目安になります。ただしこれは事務所の内製体制によって大きく変わるため、外部に委託する場合は要件を先に固めてから見積もりを取ってください。要件が曖昧なまま見積もりを取ると、後から膨らみます。

体制は、ツール設計を有資格者、実装を内製または外部委託、運用監督を事務所の管理担当という3層に分けるのが現実的です。ツール設計を外部に丸投げしないことが重要です。何を返すかの判断は守秘の設計であり、事務所の外に出せない判断だからです。

効果測定は、AIへの問い合わせ回数ではなく、資料の所在を探す作業に要していた時間の変化で見てください。測定の組み方は士業事務所のAI削減時間を検証する手順の記事を参考にしてください。

これから論点になること

ひとつは、書き込み系ツールの解禁をどう判断するかです。読み取りだけで運用が安定したあと、申告データの下書き作成や案件ステータスの更新をAIに任せたいという話が出てきます。そのときに必要なのは、承認工程を伴う設計です。2026-07-28版では、追加情報が必要な場合にサーバーがInputRequiredResultを返し、クライアントが再試行で応答するという往復のパターンが導入されました（出典: Model Context Protocol Key Changes）。この仕組みを人の承認に使う設計は検討の余地があります。

もうひとつは、クライアント登録の方式変更です。動的クライアント登録が非推奨となり、Client ID Metadata Documentsが推奨される方向になったため、いま動的登録前提で組むと後で作り直しになります。仕様は後方互換のために動的登録を残すとしていますが、新規実装で採用する理由は薄いでしょう。

3つ目は、非推奨機能の扱いです。仕様は最短十二か月の非推奨期間を定める機能ライフサイクル方針を採用し、非推奨機能の登録簿を持つようになりました（出典: Model Context Protocol Key Changes）。事務所として、年に一度は登録簿を見て自所の実装が影響を受けないかを確認する運用にしておくと、突然の作り直しを避けられます。

よくある質問

MCPサーバーとは何ですか

AIクライアントから業務システムのデータや操作を呼び出せるようにする接続口です。事務所が自前で用意することも、ベンダーが提供するものを使うこともできます。仕様はModel Context Protocolとして公開されています（出典: Model Context Protocol Key Changes）。

ステートレス化で何が変わりましたか

Streamable HTTPトランスポートからプロトコルレベルのセッションとMcp-Session-Idヘッダーが削除され、initializeのハンドシェイクも廃止されました。呼び出しをまたぐ状態が必要な場合は、サーバーが発行したハンドルをツール引数として渡す設計になります（出典: Model Context Protocol Key Changes）。

最初は何から作ればよいですか

読み取り専用のツールを3つから5つ作るところから始めてください。書き込み系は、監査と承認の設計ができてからにするのが安全です。ツールが多いほどAIが迷うため、絞ることが精度にもコストにも効きます。

顧問先データをAIから参照できるようにしてよいですか

事務所として、公開するツールの範囲と返却項目を決めたうえで判断する論点になります。個人情報保護法第27条の第三者提供の規律や、士業ごとの守秘義務との関係を整理しておいてください（出典: e-Gov法令検索 個人情報の保護に関する法律）。

認可はどう実装すればよいですか

仕様は、認可応答のissパラメータの検証、動的クライアント登録でのapplication_typeの指定、資格情報を発行元の認可サーバーに紐づけて別サーバーで使い回さないことを求めています（出典: Model Context Protocol Key Changes）。内部利用でも省略しない設計にしてください。

外部が提供するMCPサーバーを使う場合は何を見ますか

提供者の身元、データの保存場所、認可の実装、監査ログの提供有無を確認します。審査の観点は事務所として基準化しておくと判断が速くなります。

監査ログには何を残せばよいですか

誰が、いつ、どのツールを、どの引数で呼び、何が返ったかを残します。2026-07-28版はOpenTelemetryのトレースコンテキストを_metaで伝播させる規約を文書化しているため、既存の監視基盤と揃えておくと追跡が容易になります（出典: Model Context Protocol Key Changes）。

参考文献

• Model Context Protocol 2026-07-28 Key Changes
• Model Context Protocol Blog The 2026-07-28 Specification
• e-Gov法令検索 個人情報の保護に関する法律
• e-Gov法令検索 税理士法
• 個人情報保護委員会
• 日本税理士会連合会
• freee Developers Community
• cybozu developer network

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