外部MCPサーバーの安全性をどう審査するか士業事務所の導入基準7項目

MCPとは、AIと外部ツールをつなぐ接続の共通規格のことです。

事務所のAIに外部のMCPサーバーをつなぐとき、どこを見て可否を決めているでしょうか。この記事では、外部MCPサーバーを事務所に入れる前に確認する7項目と、審査の記録の残し方、そして顧問先の資料を扱う場面での守秘義務の論点を扱います。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁および独立行政法人の公表資料で確認しています。情報処理推進機構は、情報セキュリティ10大脅威2026の組織向け順位でAIの利用をめぐるサイバーリスクを3位に選出しました（出典: 情報処理推進機構情報セキュリティ10大脅威 2026）。

MCPサーバーが士業事務所に入り込む2026年の状況

先に押さえるのは、MCPが事務所の業務に入ってくる経路が、担当者の自発的な設定である場合が多いという点です。全社的な導入決定を経ずに広がる性質があるため、気づいたときには誰が何をつないだか分からない状態になります。

MCPは、AIクライアントと外部のツールやデータ源をつなぐための接続の共通規格です。表計算ソフト、社内の文書管理、クラウドストレージ、業務システムなど、つなぎたい先ごとにサーバーが用意され、AI側からそのサーバーの機能を呼び出せます。事務所にとっての利点は明確で、資料をコピー貼り付けする手間が消えます。同時に、AIが触れられる範囲が一気に広がります。

情報処理推進機構は、AIの利用をめぐるサイバーリスクを情報セキュリティ10大脅威2026の組織向け順位で3位に選出し、この順位が初選出であることを公表しています。同順位は2026年1月29日の公表です（出典: 情報処理推進機構情報セキュリティ10大脅威 2026）。同機構はAIセキュリティ短信という定期的な情報提供も行っており、MCPを含むAI関連の脆弱性事例が扱われています（出典: 情報処理推進機構 AIセキュリティ短信）。

規格側でも、想定される攻撃と対策が文書として整理されています。MCPの仕様文書には、権限を持つ主体が第三者の意図で動かされてしまう問題、クライアントから受け取ったトークンをそのまま下流のAPIへ渡してしまう設計上の誤り、セッション識別子の乗っ取り、ローカルで動かすサーバーが侵害される経路といった項目が並びます（出典: Model Context Protocol Security Best Practices）。士業事務所の側でこの仕様を実装する場面は多くありませんが、審査の観点を作るときの下敷きとしては有用です。

事務所の実務に引き寄せると、危ないのは3つの局面です。第1に、ローカルで動くサーバーを何気なく設定する局面。この形式は事務所のパソコン上で任意のコマンドを実行できる構造になり得ます。第2に、外部のサービスに認証情報を預ける局面。どのスコープの権限を渡したかが記録に残っていないと、後から範囲を確定できません。第3に、AIが外部から取得した文章の中に、AI自身への指示が仕込まれている局面です。取得した資料の内容をAIが命令として解釈すると、想定していない操作が走ります。

この3つは、いずれも導入時の審査で相当程度を潰せます。逆に、導入後に事故が起きてから範囲を確定しようとすると、顧問先への説明が難しくなります。当媒体のAIエージェントの法務スキル搭載で変わるツール選定士業事務所の7基準でも触れたとおり、ツール選定の段階に判断を集めるほうが結果的に軽く済みます。

外部MCPサーバーを入れる前に見る7項目の審査手順

審査項目は7つに固定します。項目が多すぎると誰も回さなくなり、少なすぎると抜けます。この7つを1枚のシートにして、導入申請のたびに埋める運用にしている事務所があります。

第1項目は、提供元の素性です。誰が開発し、誰が保守しているか。公式のベンダーが提供しているものか、個人が公開しているものか。同じ機能でも、事務所の資料が通る経路として見たときの重みが変わります。提供元が特定できないサーバーは、この時点で見送りの対象になります。

第2項目は、動作の形式です。事務所のパソコン上で動くのか、外部のサーバーに接続するのか。ローカルで動く形式は、設定時に指定されたコマンドがそのまま実行される構造を持ち得ます。MCPの仕様文書でも、ローカルサーバーの侵害が独立した項目として扱われています（出典: Model Context Protocol Security Best Practices）。導入前に、実行されるコマンドの全文を目で確認する工程を入れます。

第3項目は、渡す権限の範囲です。読み取りだけで済むのか、書き込みや削除まで必要か。クラウドストレージ全体への権限を渡すのか、特定のフォルダに限れるのか。ここは最小限から始めて、足りなければ広げる順序にします。広い権限を先に渡してしまうと、後から絞るときに業務が止まります。

第4項目は、データの流れ先です。事務所の資料がどのサーバーを経由し、どこに保存され、どれだけの期間残るか。提供元の公式ドキュメントで確認できる範囲を確認し、記載が読み取れない部分は、公表資料からは確認できないものとして審査シートに書きます。空欄のまま通すのではなく、確認できなかったという事実を残すのが要点です。

第5項目は、認証の仕組みです。事務所のアカウントでログインする形式か、発行した鍵を設定ファイルに書く形式か。鍵を平文で置く形式であれば、その設定ファイルが誰の目に触れるかまで含めて考えます。退職者が出たときに権限を切る手順も、この項目で確認します。

第6項目は、ログの取得可否です。いつ誰がどのツールを呼び出したかを後から追えるか。事故が起きたときに範囲を確定できるかどうかは、ここで決まります。ログが取れない構成であれば、扱う資料の範囲を絞る判断につながります。

第7項目は、停止手順です。問題が起きたときに、どの操作で接続を切れるか。事務所内の誰がその操作を行えるか。停止手順が明文化されていないと、事故のときに時間を失います。

ここから手順です。手順1で、導入を希望する担当者が上の7項目を埋めた申請シートを出します。手順2で、審査担当が提供元の公式ドキュメントにあたり、記載を確認します。手順3で、確認できなかった項目を明示したうえで、扱う資料の範囲を決めます。手順4で、権限を最小の状態に設定して試験導入します。手順5で、実際の業務で1週間ほど動かし、ログと挙動を確認します。手順6で、有資格者が最終的な可否を判断し、シートに署名します。手順7で、承認済みの一覧に追加し、次回の見直し時期を書き込みます。

生成AIは、この手順のうち手順2の下ごしらえに使えます。公式ドキュメントを読み込ませ、7項目に対応する記載を抜き出させる作業です。判断そのものは人が行い、AIには記載の所在を示させるにとどめます。次のプロンプトは、その抜き出しを行わせるものです。

あなたはセキュリティ審査の下調べを担当するアシスタントです。
以下に貼り付けるドキュメントを読み、次の7項目について
「記載あり（該当箇所を引用）」か「記載が見つからない」かを判定してください。

1. 提供元と保守体制
2. 動作形式（ローカル実行か外部接続か）
3. 要求される権限の範囲
4. データの保存先と保存期間
5. 認証方式と鍵の管理方法
6. 操作ログの取得可否
7. 接続の停止手順

制約:
- 推測で補完しないでください。書いていないことは「記載が見つからない」と答える
- 該当箇所は原文のまま引用し、要約しないでください
- 安全かどうかの結論は書かないでください。判断はこちらで行います

--- ドキュメントここから ---
（公式ドキュメントを貼り付け）

もう1つは、申請シートの内容から、事務所内で共有する要約を作らせるプロンプトです。審査の結論は人が書き、AIは体裁を整える役割に限定します。

あなたは事務所内の情報共有文書を整える担当者です。
下の審査シートの内容を、事務所メンバー向けの共有文に整えてください。

条件:
- 300字程度、ですます調、表は使わない
- 「確認できなかった項目」を必ず独立した段落で示す
- 安全である、問題ないといった評価の言葉は使わない
- 扱ってよい資料の範囲と、停止手順の担当者名を最後に置く

--- 審査シートここから ---
（記入済みシートを貼り付け）

出てきた文章は、そのまま共有せずに審査担当が通します。特に、AIが確認できなかった項目を確認済みのように書き換えてしまう挙動には注意が要る部分です。当媒体のAIエージェントに人の確認をどう挟むか士業事務所の設計で扱った確認工程の考え方が、そのまま当てはまります。

顧問先の資料をMCP経由で扱う前に決めておくこと

MCPを通すと、AIが触れる資料の範囲が設定ひとつで広がります。ここが守秘義務との接点になります。

最初に決めるのは、接続してよい保存先の限定です。事務所のクラウドストレージ全体を接続対象にすると、顧問先の資料も過去の案件も一括で射程に入ります。AIに触れさせてよい資料を置く場所を1か所に決め、その場所だけを接続する構成にしておくと、範囲の確定が容易になります。この設計は、事故が起きたときの説明可能性に直結します。

守秘義務の根拠は職種ごとに置かれています。弁護士については弁護士法第23条が、弁護士または弁護士であった者は職務上知り得た秘密を保持する権利を有し義務を負う旨を定めています。税理士については税理士法第38条が、正当な理由なく税理士業務に関して知り得た秘密を他に洩らし、または窃用することについて定めています。他の職種にも同様の位置づけの規定が置かれており、事務所として統一した運用を作る際の出発点になります。

顧問先の個人データを含む資料を扱う場面では、個人情報の保護に関する法律第27条が定める第三者提供の枠組みが論点になります。外部のMCPサーバーを経由して資料が事務所の外へ出る構成であれば、この論点を避けて通れません。委託の形で整理できるかどうかは契約と処理の実態によって変わる部分であり、個別の判断は有資格者が行う領域です。事務所としては、個人データを含む資料を接続対象の保存先に置かない運用にしておくと、この論点自体を回避できます。

顧問先への説明については、顧問契約の締結時にAIと外部ツールの利用範囲を説明しておく形と、案件ごとに確認する形の2通りが見られます。MCPの場合、接続先が増えるたびに範囲が変わるため、承認済みの接続先一覧を事務所側で維持し、変更があったときに顧問先へ通知する運用を採る事務所があります。

事務所規程に書く内容は3つに絞れます。第一に、AIが接続してよい保存先の限定。第二に、外部MCPサーバーを追加するときの審査手順と承認者の指定。第三に、承認済み一覧の維持と見直しの頻度です。個別のサーバー名を規程に書き込むと改定が追いつかなくなるため、規程は手順のレベルにとどめ、一覧は別の管理表に置く構成が回しやすくなります。

見落とされやすいのが、AIが外部から取得した文章の扱いです。MCP経由で取得したウェブページや文書の中に、AIへの指示として読める文章が仕込まれている場合があります。事務所側の対策としては、取得した内容をAIが命令として扱わない設定にできるか、そして重要な操作の前に人の承認を挟む設計になっているかを、導入時に確認する形になります。

導入で起きやすい3つの失敗と回避策

第1の失敗は、担当者が個別に接続を増やしていく野良化です。便利だからという理由で各自が設定を追加し、事務所として誰が何をつないでいるか把握できなくなります。回避策は承認制で、承認されていない接続先を使わない運用を先に決めることです。承認の手続きが重すぎると迂回されるため、7項目のシート1枚で完結する軽さにしておく設計が効きます。

第2の失敗は、権限を広く渡したまま運用が固定されることです。試験導入のときに面倒だからと全権限を渡し、そのまま本番運用に移行してしまう例があります。回避策は、試験導入の段階から最小権限で始めることと、承認済み一覧に権限の範囲を書き込んで見直し時期を設定することです。

第3の失敗は、確認できなかった項目が確認済みとして扱われることです。公式ドキュメントに記載がない項目を、審査シートに空欄のまま残すと、次に見た人は確認済みだと解釈します。回避策は、確認できなかったという記載を明示的に残す様式にすることです。上のプロンプト例で、推測による補完を禁じ、記載が見つからない旨を答えさせているのは同じ理由です。

もう1つ、実務で見られるのが、AIの出力に含まれる接続先の説明を鵜呑みにする例です。生成AIは、実在しないオプションや存在しない設定項目をもっともらしく説明します。審査は公式ドキュメントの原文で行い、AIの説明は所在の手がかりとして使うにとどめる工程設計になります。

審査体制と工数の見立て

初期に作るのは、7項目の審査シート、承認済み一覧の管理表、そして停止手順の書面です。この3つが揃えば、以後の審査は定型作業になります。作成そのものにはまとまった時間がかかりますが、一度作れば使い回せます。

審査を回す担当は、事務所内で情報システムに明るい人と、有資格者の二者体制にしている例があります。前者が公式ドキュメントの読み込みと設定を担い、後者が扱ってよい資料の範囲と最終的な可否を判断します。ひとりに集約すると、技術的な確認と業務判断が混ざり、判断の質が落ちます。

見直しの頻度は、承認済み一覧の項目ごとに期限を設けて管理する形が実務的です。MCPサーバーは更新が速く、機能追加によって扱えるデータの範囲が変わることがあります。導入時に確認した内容が、半年後にも同じとは限りません。情報処理推進機構のAIセキュリティ短信のような定期刊行物を確認する担当を決めておくと、外部の変化に気づく経路ができます（出典: 情報処理推進機構 AIセキュリティ短信）。

費用については、審査の作業そのものに外部費用は発生しません。既存の生成AI契約の範囲で回せます。むしろ費用として意識するのは、審査に人の時間を使うことです。この時間を惜しんで無審査で入れると、事故が起きたときの調査に何倍もの時間を使うことになります。

接続先が増えていく前提で何を決めておくかという論点

第1の論点は、承認済み一覧の粒度です。サーバー単位で管理するのか、機能単位まで下ろすのか。機能追加で扱えるデータが変わる性質を踏まえると、機能単位まで下ろしたい一方で、管理が重くなります。事務所の規模と接続先の数で落としどころが変わります。

第2の論点は、顧問先への説明のタイミングです。接続先が変わるたびに通知するのか、定期的にまとめて知らせるのか。通知が多すぎると読まれなくなり、少なすぎると説明の記録が残りません。ここは顧問先の性質によって選択が分かれます。

第3の論点は、事務所自身が業務システムをAIにつなぐ側になる場面です。顧問先のシステムと事務所のAIを接続する構成では、事務所が接続を求める側に立ちます。そのとき顧問先から同じ7項目を問われる前提で、自分の側の説明を用意しておくことが、結果として審査の質を上げます。

よくある質問

外部MCPサーバーは使わないほうがよいのですか

使わないという選択だけが答えではありません。審査の手順と承認済み一覧を先に作り、扱う資料の範囲を限定したうえで使う運用が見られます。無審査で広げることと、一切使わないことの間に選択肢があります。

ローカルで動くMCPサーバーと外部接続型はどちらが安全ですか

一方が常に安全ということはありません。ローカル実行には任意のコマンドが実行され得る構造の論点があり、外部接続には資料が事務所の外へ出る論点があります（出典: Model Context Protocol Security Best Practices）。扱う資料の性質に応じて選ぶ形になります。

顧問先の資料をMCP経由でAIに読ませてもよいですか

事務所として範囲を決めてから使う順序になります。守秘義務の根拠は職種ごとに置かれており、税理士については税理士法第38条が秘密を守る義務を定めています。個別の資料について判断する場面は有資格者の領域です。

審査に何を書き残せばよいですか

7項目の確認結果と、確認できなかった項目の明示です。特に後者を空欄にせず、確認できなかったという事実として残すことが、後から範囲を確定するときに効きます。承認者と承認日も同じシートに置きます。

承認済み一覧はどれくらいの頻度で見直しますか

項目ごとに期限を設ける形が実務的です。MCPサーバーは機能追加で扱えるデータが変わることがあるため、導入時の確認内容が持続する前提を置かないほうが安全側になります。

情報の更新はどこを見ればよいですか

情報処理推進機構のAIセキュリティに関する情報提供が起点になります（出典: 情報処理推進機構 AIセキュリティ短信）。規格側の変更はMCPの仕様文書で確認できます。担当者を決めて定期的に見る運用があります。

小規模事務所でもこの7項目を回せますか

項目を減らさずに、様式を軽くする方向で対応している事務所があります。シートは一枚で完結する形にし、審査を二者で回す体制にすると、少人数でも運用できます。手続きが重いと迂回されるため、軽さの設計が要点になります。

参考文献

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

本記事の作成体制について

本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。

本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。

記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。