MCPサーバーとは、AIを外部システムに接続するための標準化された窓口のことです。

公開されているMCPサーバーの数は、公式レジストリの集計で1万件規模に達したと報じられています（出典: Official MCP Registry、要確認）。この記事では、その中から士業事務所が会計・労務のシステム接続に使うものを選ぶときの7つの判断軸と、選定を誤ったときに起きる守秘義務上の論点を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。仕様や運営体制は各プロジェクトの公式ドキュメントで確認しています。

数が増えたことで、選定が仕事になった

結論から書くと、MCPをめぐる士業事務所の課題は、繋げるかどうかから、どれを繋ぐかへ移っています。プロトコル自体が主要ベンダーに採用されて標準の位置に着いたため、技術的な可否ではなく、選定と管理が実務の中心になりました。

MCPは、AIと外部のツール・データを繋ぐための共通の作法です。従来はサービスごとに個別の連携を作る必要がありましたが、共通の窓口を用意すれば、対応するAIクライアントから同じやり方で呼び出せます。Anthropicは、このプロトコルをLinux Foundation傘下のAgentic AI Foundationへ寄贈したと公表しており、特定企業の所有物ではない運営体制へ移っています（出典: Anthropic）。同じ発表では、この財団にOpenAIやBlockが共同設立者として、GoogleやMicrosoft、AWSが支援側として名を連ねていることが説明されています。

公開サーバーの一覧は、公式のレジストリに集約されています。レジストリは公開されているMCPサーバーのメタデータを集める場所として運営されており、複数の主要な貢献者に支えられていると説明されています（出典: The MCP Registry）。士業事務所にとっての意味は単純で、探す場所が1つに定まったということです。裏を返せば、レジストリに載っていること自体は品質の保証ではありません。

士業の実務で接続先として想定されるのは、会計・税務のシステム、給与・勤怠のシステム、案件管理と文書管理、そして官公庁のオンライン手続に関わる領域です。このうち、顧問先の生データに触れる前者2つが、選定の慎重さを最も要する領域になります。プロトコル自体の仕様変更が実務に与える影響については、MCPが2026年7月に大改訂 事務所のシステム連携7つの実務影響で整理しています。

会計・労務システムを繋ぐ前に見る7つの判断軸

選定は、次の7つを順に見ていく形で進めます。上から順に、落ちたらそこで止める設計にすると判断が速くなります。

第1の軸は、提供元です。接続先サービスのベンダー自身が公式に提供しているサーバーか、第三者が作ったものかを最初に分けます。顧問先の会計データや給与データに触れる用途では、公式提供のものに絞る、という線引きをしている事務所があります。第三者製を使う場合は、ソースコードが公開されているか、誰が保守しているかを確認する工程が加わります。

第2の軸は、認証の方式です。APIキーを設定ファイルに直接書く方式か、OAuthのような認可の流れを経る方式かで、鍵の管理コストが変わります。前者は導入が速い代わりに、鍵が端末や設定ファイルに残ります。後者は初期設定に手間がかかる代わりに、権限の取り消しが後からできます。

第3の軸は、権限の粒度です。読み取りだけで足りる用途に、書き込み権限まで持つサーバーを繋ぐと、AIの誤作動がそのままデータの改変になります。読み取り専用の設定ができるか、対象を特定の顧問先や期間に絞れるかを確認します。権限の分け方の考え方は、記帳を担うAIエージェントの権限をどう分けるか 会計事務所の内部統制7設計で整理した内部統制の設計と接続できます。

第4の軸は、データの流れです。サーバーがどこで動くか、つまり事務所内で動かすのか、ベンダーのクラウドで動くのか、第三者のホスティングを経由するのかを確認します。顧問先の情報がどの事業者の管理下を通るかは、守秘義務の整理に直結する事項です。

第5の軸は、ログです。誰が、いつ、どのデータに触れたかが記録されるかを見ます。記録が残らない接続は、後から説明ができません。事後の説明責任を果たせるかどうかが、士業の業務では選定の分岐点になります。

第6の軸は、保守の実態です。最終更新がいつか、不具合の報告に対する反応があるか、破壊的な変更のときに告知があるか。レジストリに登録されていても、更新が止まっているサーバーは相当数あります。業務で使うなら、更新履歴を確認する工程を入れます。

第7の軸は、撤退の容易さです。使うのをやめるときに、権限の取り消しと設定の削除が完結するかを見ます。繋ぐときの手間より、外すときの手間のほうが後で効いてきます。

導入の手順は5つです。第1に、用途を1つに絞ります。試算表の取得だけ、勤怠データの集計だけ、というように単機能から始めます。第2に、テスト用の環境か、自事務所のデータで検証します。顧問先のデータをいきなり使わないのが要点です。第3に、7つの軸で評価し、記録に残します。第4に、限定した範囲で運用し、ログを見て想定外の呼び出しがないかを確認します。第5に、有資格者が結果の妥当性を確認する工程を業務フローに固定したうえで、対象を広げます。

評価を補助させるプロンプト例を2本示します。1本目は、候補サーバーの棚卸しです。

あなたは士業事務所のシステム選定の補助です。以下のMCPサーバー候補について、
公式ドキュメントとリポジトリの記載だけを根拠に評価表を作ってください。
記載が確認できない項目は「記載なし」と書き、推測で埋めないでください。

評価項目:
1 提供元（接続先ベンダー公式 / 第三者 / 個人）
2 認証方式（APIキー / OAuth / その他）
3 権限の粒度（読み取り専用の設定可否、対象の絞り込み可否）
4 実行場所（ローカル / ベンダークラウド / 第三者ホスティング）
5 監査ログの有無と保存先
6 最終更新日と直近3か月のコミット有無
7 権限取り消し・アンインストールの手順の記載

出力の最後に、確認できなかった項目だけをまとめて列挙してください。

2本目は、事務所の判断基準に照らした一次仕分けです。

以下の評価表を、当事務所の基準で3段階に仕分けてください。
基準を満たすかどうかだけを判定し、導入の可否は判断しないでください。

当事務所の基準:
- 顧問先データに触れる用途は、接続先ベンダー公式のサーバーのみ
- 書き込み権限が必要な用途は、監査ログが取れることが前提
- 実行場所が第三者ホスティングの場合は、対象を自事務所データに限定

仕分け: A=基準を満たす / B=条件付き / C=基準を満たさない
各判定に、根拠となった評価項目の番号を必ず添えてください。
最終的な導入判断は有資格者が行うため、推奨の表現は使わないでください。

自分で作る選択肢もあります。既製のサーバーが要件に合わない場合、事務所の業務データに合わせて自作する方法は事務所の業務データに自作MCPサーバーを繋ぐで整理しています。自作は権限とログを自分で設計できる代わりに、保守の責任も自分で持つことになります。

会計・労務それぞれで最初に繋ぐならどこか

会計側で最初の1本を選ぶなら、試算表と仕訳の読み取りに絞るのが現実的です。月次のチェックでAIに異常値を拾わせる用途であれば、書き込み権限は要りません。読み取りだけに絞れば、第3の軸で落ちる候補が減り、選定そのものが軽くなります。逆に、仕訳の自動登録まで一気に狙うと、権限とログと巻き戻しの3点を同時に設計する必要が出て、初回の導入としては重くなります。

労務側で最初の1本を選ぶなら、勤怠データの集計と、法定帳簿の記載漏れの洗い出しが向きます。給与データは個人情報の密度が高いため、氏名や個人番号を含まない形で取り出せるかを先に確認します。取り出す段階で絞れないシステムであれば、その接続は後回しにして、集計済みの数値だけを扱う経路から始める判断もあります。

案件管理や文書管理の接続は、顧問先データに触れる度合いが業務によって大きく変わります。案件名だけを扱うのか、添付ファイルの中身まで読ませるのかで、必要な整理の深さが変わります。ここは用途を書き出してから軸に当てる順序を守ると、判断がぶれません。

官公庁のオンライン手続に関わる領域は、現時点では接続先そのものが限られます。手続の自動化を狙うより、公表資料や様式の読み取りにAIを使い、送信は人が行う形にとどめている事務所が多い状況です。

顧問先データが外へ出る経路をどう説明するか

MCPで会計・労務システムを繋ぐと、顧問先の生データがAIの文脈に流れ込みます。ここが守秘義務の側から見た最大の論点です。

各士業の守秘義務は法律に根拠を持ちます。税理士法第38条は、正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならないと定めています。公認会計士法第27条、社会保険労務士法第21条にも、同趣旨の規定が置かれています。MCP経由の接続がこれらの規定との関係でどう位置づけられるかは、データがどの事業者の管理下を通るかによって変わるため、接続ごとに整理しておく論点になります。

整理の手順は3段階です。第1に、経路を図に落とします。顧問先データが、事務所の端末からどのサーバーを経てどのAIモデルに渡るかを、事業者名で書き出します。ここで名前が出てくる事業者の数が、説明しなければならない相手の数になります。第2に、各事業者のデータ取り扱いの説明を、公式ドキュメントで確認して保存します。契約プランによって入力の扱いが変わる場合があるため、事務所が実際に契約しているプランのドキュメントを特定します。第3に、顧問契約や業務説明の中で、外部サービスの利用範囲をどう伝えるかを決めます。

個人情報を含むデータの扱いについては、個人情報保護委員会が生成AIの利用に関する注意喚起を公表しています。事務所として参照先を1つに固定し、接続を増やすたびに同じ観点で見直す運用にすると、判断がぶれにくくなります。

事務所規程に落とす項目は6つです。第1に、接続を許可する用途の範囲。第2に、提供元に関する基準。第3に、書き込み権限を認める条件。第4に、監査ログの取得と保存期間。第5に、接続の棚卸しの頻度と担当。第6に、接続を止めるときの手順です。特に第5の棚卸しは形骸化しやすいため、四半期ごとに実際の設定と規程を突き合わせる形にしておきます。

選定でつまずく3つの場面

1つ目の場面は、試したまま本番で使い続けてしまうことです。検証目的で繋いだサーバーが、そのまま顧問先データに向いた状態で残る。これは設定ファイルに接続が積み上がっていく形で起きます。検証用と本番用の設定を物理的に分け、検証用は月末に消す運用にすると防げます。

2つ目の場面は、権限を広く取ってしまうことです。動かないときに権限を足していくと、最終的に全権限を持った接続ができあがります。動かない原因を権限で解決する前に、呼び出しの内容をログで確認する順序を決めておきます。ログを見ずに権限を足す作業は、原因が分からないまま範囲を広げる作業と同じです。

3つ目の場面は、保守が止まったサーバーに気づかないことです。動いている限り問題は見えませんが、接続先のAPI仕様が変わった日に急に止まります。四半期の棚卸しで最終更新日を確認するだけで、この事故はかなり減らせます（根拠は、更新停止から障害までに通常は数か月の間があるためです）。

いずれの場面も、共通する対策は棚卸しです。接続の一覧、用途、権限、提供元、最終確認日を並べた台帳を1つ持ち、四半期に一度見る。この1つの習慣が、7つの判断軸を運用に定着させます。

費用と工数 誰が接続台帳を持つか

費用面では、MCPサーバー自体は無償で公開されているものが中心です。費用が発生するのは、接続先サービスの上位プランや、AIモデルの利用料のほうです。会計システムのAPI利用が上位プラン限定になっている場合、そのプラン差額が実質的な導入コストになります。

工数の目安は、1つの接続を7軸で評価して台帳に載せるまでで、半日から1日です（根拠は、公式ドキュメントの確認と検証環境での動作確認が作業の中心を占めるためです）。運用に入ってからは、四半期の棚卸しに接続数あたり15分程度を見込みます。接続が10本を超えると、棚卸しだけで半日仕事になるため、使っていない接続を削る判断を同時に行う設計にします。

体制としては、接続台帳の管理者を1人だけ置き（根拠は、承認の窓口が複数あると台帳の記載漏れが起きるためです）、新規接続の申請と承認を通す形が扱いやすい形です。管理者は技術に詳しい必要はなく、7軸の評価表が埋まっているかを見る役割で足ります。判断が要る部分、つまり顧問先データを通してよいかどうかは、有資格者の判断として残します。

導入初月の進め方を絞るなら、接続は1本だけにします（根拠は、複数を同時に動かすと想定外の呼び出しの出どころが特定できなくなるためです）。用途を1つに限定し、自事務所のデータで2週間動かし、ログを毎週見る。この期間に見るのは便利さではなく、想定していない呼び出しが起きていないかです。想定外の呼び出しが1件も無いまま2週間過ぎたら、対象を顧問先1社に広げる。この刻み方であれば、問題が起きても影響範囲が特定できます。

所内への説明では、MCPが何かを教えるより、事務所が何を許可し何を許可していないかを伝えるほうが効きます。技術の説明は担当者に閉じてよく、他のメンバーが知る必要があるのは、勝手に接続を増やさないという1点です。設定ファイルを触れる権限を絞っておくと、この線は自然に守られます。

台帳に何を書くか

台帳の項目は8つで足ります。接続名、接続先サービス、用途、提供元の区分、権限の範囲、実行場所、監査ログの保存先、最終確認日です。これに承認者の欄を足せば、誰の判断で有効になっている接続かが後から追えます。表計算ソフトで作って共有フォルダに置き、四半期の棚卸しのたびに最終確認日を更新する形が、最も続きやすい運用です。

台帳を作ると、副次的な効果が出ます。事務所がどのサービスに依存しているかが一覧で見えるため、契約更新やシステム入れ替えの検討がしやすくなります。接続の管理は守秘義務のための作業として始まりますが、事務所の資産管理としても機能します。

標準になったプロトコルの次に来る論点

選定が仕事になった次に来るのは、接続の総量をどう抑えるかという論点です。繋げば繋ぐほど便利になる一方で、説明しなければならない経路と、棚卸しの対象が増えます。士業事務所の場合、便利さの上限は説明可能性の上限に規定されます。

もう1つは、接続の責任の所在です。プロトコルが財団に移り、サーバーの多くが第三者製である以上、不具合が起きたときの責任は分散します。事務所としては、どこまでを自分の管理責任と考えるかを先に決めておく必要があります。少なくとも、どの接続を有効にしたかは事務所の判断であり、そこは自分の責任範囲に入ります。

3つ目は、監査への備えです。会計監査や個人情報の取り扱いに関する確認で、AIとシステムの接続経路を説明する場面が今後増えていくと見られます。台帳を持っているかどうかが、そのときの初動を分けます。

よくある質問

MCPサーバーは誰が作っているものですか

作り手は3種類あります。接続先サービスのベンダー自身、有志の開発者コミュニティ、そして個人です。公式レジストリはメタデータを集約する場であり、登録されていること自体は品質を示しません（出典: The MCP Registry）。顧問先データに触れる用途では、提供元を最初の判断軸に置く形が採られています。

顧問先の会計データをMCP経由でAIに渡してよいですか

データの経路と契約内容によって変わるため、接続ごとに整理する論点になります。守秘義務の根拠は税理士法第38条に置かれており、どの事業者の管理下をデータが通るかを図に落としたうえで、顧問先への説明範囲とあわせて決める手順が現実的です。

読み取り専用にできない場合はどうしますか

書き込み権限を認める条件を規程で先に決めておく形が採られています。監査ログが取れること、対象データが限定できること、誤作動時に巻き戻せることの3つを条件に挙げている事務所があります。条件を満たさない場合は、人が実行する工程を残します。

無料のMCPサーバーを業務で使って問題ないですか

無償かどうかと業務での適否は別の軸です。判断は、提供元・認証方式・権限の粒度・実行場所・ログ・保守の実態・撤退の容易さの7軸で行います。無償で公式提供のサーバーもあれば、有償でも保守が薄いものもあります。

接続はどのくらいの頻度で見直せばよいですか

四半期に一度が現実的な出発点です。接続先のAPI仕様変更や、サーバーの更新停止に気づく間隔として、これより長いと障害の形で気づくことになります。棚卸しでは最終更新日と、実際に使っているかどうかの2点を見ます。

MCPが財団に移ったことで、事務所の実務は変わりますか

直接の変化はありません。運営が特定企業から中立の財団へ移ったことで、特定ベンダーの都合で仕様が変わる懸念は下がったと説明されています（出典: Anthropic）。事務所側でやることは、選定と棚卸しという点で変わりません。

自作と既製品はどちらを選ぶべきですか

要件と保守体制で決まります。既製品は導入が速い代わりに、権限やログの設計が提供元の仕様に縛られます。自作は設計の自由度がある代わりに、保守の責任を事務所が持ちます。判断材料は事務所の業務データに自作MCPサーバーを繋ぐで整理しています。

参考文献

• Official MCP Registry
• Model Context Protocol The MCP Registry
• Anthropic Donating the Model Context Protocol and establishing the Agentic AI Foundation
• e-Gov法令検索 税理士法第38条
• e-Gov法令検索 公認会計士法第27条
• e-Gov法令検索 社会保険労務士法第21条
• 個人情報保護委員会

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