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

顧問先の資料が入ったフォルダに、AIツールを直接つないでよいか。この問いに事務所として答えを持っているでしょうか。MCPの仕様書は、この規格が安全性の原則をプロトコルの層で強制することはできない、と明言しています（出典: Model Context Protocol Specification）。守る責任は、規格ではなく実装する側と使う側に置かれています。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、規格の内容は仕様書の原文で確認しています。

MCPは何を守り、何を守らないのか

結論から書くと、MCPが定めているのは通信の作法であって、事務所の情報を守る仕組みではありません。仕様書のSecurity and Trust & Safetyの節は、利用者の同意と制御、データのプライバシー、ツールの安全性という3つを原則として挙げたうえで、MCP自体はこれらの原則をプロトコルの層で強制できないと述べ、実装者が同意と認可のフローを作り、安全性の影響を文書化し、適切なアクセス制御とデータ保護を実装することを推奨しています（出典: Model Context Protocol Specification）。規格に準拠していることと、安全であることは別の話です。

3つの原則のうち、事務所が最初に読むべきはツールの安全性です。仕様書は、ツールが任意のコード実行を表すものであり相応の注意をもって扱うべきこと、そしてツールの挙動を説明する記述や注釈は、信頼できるサーバから得たものでない限り信頼できないものとして扱うべきことを記しています（出典: 前掲仕様書）。ツール一覧に並ぶ説明文は、人間向けの説明であると同時にAIモデルへの指示として読まれます。説明文に仕込まれた指示でAIが動く余地がある、という前提で接続先を選ぶことになります。

もう一つ、設計の前提として押さえておく点があります。2026-07-28版の仕様において、MCPはステートレスであり、プロトコル層のセッションを持たないと整理されました。複数のリクエストにまたがる状態を持ちたいサーバは、カートIDやワークフローIDのような明示的なハンドルを発行し、毎回の引数として受け取ります（出典: MCP Security Best Practices）。この設計は、ハンドルを手に入れた第三者が他人の状態へ触れるという攻撃の入口にもなります。

仕様側は攻撃手法の整理も公開しています。認可コードを横取りするconfused deputy、宛先の違うトークンをそのまま下流へ流すtoken passthrough、内部ネットワークへ到達させるSSRF、状態ハンドルの乗っ取り、ローカルMCPサーバの侵害、認可URLを使ったスクリプト実行、スコープの過大付与などが挙げられています（出典: 前掲ガイド）。専門用語が並びますが、事務所の側で判断できる論点に翻訳できます。

たとえばconfused deputyは、一度承認した記録が残っているせいで、次からは承認画面が出ないまま別の相手に権限が渡ってしまう、という筋の話です。ガイドは、静的なクライアントIDを使いながら利用者ごとの同意確認を挟んでいない構成でこの攻撃が成立すると説明し、第三者の認可へ進む前に自前の同意画面を出すことを対策として示しています（出典: 前掲ガイド）。日常の感覚に置き換えれば、一度渡した合鍵が、別人の手に渡っても誰も気づかない状態です。

token passthroughのほうは、受け取ったトークンの宛先を確かめずに下流へ流す設計を指します。ガイドは、この設計がレート制限やリクエスト検証といった安全側の仕組みを迂回させること、そして下流のログに実際とは異なる主体からの要求として記録され、事後の調査を難しくすることを挙げています（出典: 前掲ガイド）。事故が起きたときに誰が何をしたのか説明できない、という結果に直結する論点です。

以上を事務所が判断できる形に直すと、次の7点になります。

接続前に潰す7点検 事務所が判断できる形に直す

第一に、接続先のMCPサーバが何者かを確認します。ローカルで動くMCPサーバは、事務所のパソコン上でバイナリを実行するものです。仕様のガイドは、ワンクリックでのローカルサーバ設定を支援するクライアントに対し、実行されるコマンドを省略せずに表示し、利用者のシステム上でコードを実行する危険な操作であることを明示し、明示的な承認を得ることを求めています（出典: MCP Security Best Practices）。事務所側の点検は単純で、起動コマンドの全文を見せてもらい、見せられないツールは入れない、という一線を引くことです。

第二に、トークンの宛先を確認します。ガイドは、MCPサーバが自分宛てに発行されていないトークンを受け入れてはならないと明記しています（出典: 前掲ガイド）。宛先の検証を省いたサーバは、盗まれたトークンの中継地点になり得ます。事務所が自前でサーバを立てないとしても、ベンダーに対して、トークンの宛先検証をどう実装しているかを質問する形で確認できます。回答が出てこないベンダーは、その一点で候補から落とせます。

第三に、スコープを最小から始めます。ガイドは、入口では発見や読み取りといった低リスクな操作だけを含む最小のスコープ集合から始め、権限の必要な操作が初めて試みられたときに段階的に引き上げる、という累進的な設計を挙げています。あわせて、ワイルドカードや全権限を意味するスコープを common mistakes として名指ししています（出典: 前掲ガイド）。事務所の実務では、まず読み取りだけで接続し、書き込みや送信を伴う操作は別途の承認を経てから解放する運用になります。

第四に、状態ハンドルを認証の代わりにしないことを確認します。ガイドは、認可を実装するMCPサーバがすべての受信リクエストを検証しなければならず、状態ハンドルの所持を認証として扱ってはならないと述べています。あわせて、推測しにくい乱数で生成すること、利用者に紐づけて保存することを推奨しています（出典: 前掲ガイド）。案件番号のような連番を外部に渡す設計は、この観点で危うい形です。

第五に、リダイレクト先とURLスキームの検証状況を確認します。ガイドは、MCPクライアントが認可URLについてhttpとhttpsのみを許可し、javascriptやdata、fileといったスキームを拒否すること、URLを開く際にシェルコマンドを使わないことを求めています（出典: 前掲ガイド）。ここが甘いと、悪意あるサーバが渡したURLからスクリプトが動き、端末の操作にまで広がる経路が残ります。

第六に、内部ネットワークへ到達しない設計かを確認します。ガイドは、プライベートIPの範囲やループバック、クラウドのメタデータ取得に使われるリンクローカルアドレスへの到達を遮断することを推奨しています（出典: 前掲ガイド）。事務所の環境では、会計システムや文書管理サーバが社内ネットワークに置かれている場合があり、AIツールがそこへ到達できるかどうかは、守秘義務の観点で直接効いてきます。

第七に、同意の記録を残します。ガイドは、MCPプロキシサーバに対し、利用者ごとに承認済みのクライアントIDの台帳を維持し、第三者の認可フローへ進む前にその台帳を確認することを求めています。同意画面についても、要求元のクライアント名を明示すること、要求されているスコープを表示すること、トークンの送り先となる登録済みURLを示すことを挙げています（出典: 前掲ガイド）。事務所側に置き換えると、誰が、いつ、どのツールに、どの範囲の接続を許したのかを一覧にして残す作業です。承認者と日付を入れた別表を作り、四半期ごとに見直す運用例があります。

7点の並べ方には意図があります。第一と第二は入口の話で、ここで落とせるツールが最も多くなります。第三から第六は設定と実装の話で、ベンダーへの質問が中心になります。第七は運用の話で、導入後に効いてきます。導入の検討段階では前半に時間を使い、稼働後は第七だけを定例で回す、という切り分けにすると、点検が負担になりにくいところです。

この7点を、ツール導入の審査シートへ落とすところまで生成AIで下書きできます。

あなたは士業事務所の情報管理担当です。
以下のMCP対応ツールについて、導入審査シートの草案を作ってください。

【ツール名】（貼り付け）
【公開されているドキュメントの抜粋】（貼り付け）

審査項目は次の7つとし、各項目について
(1) ドキュメントに書かれている事実
(2) 書かれていないので提供元に質問すべきこと
の2点を、表ではなく箇条書きで出してください。

1 起動コマンドと実行環境
2 トークンの宛先検証
3 スコープの初期値と昇格方法
4 状態ハンドルの扱い
5 リダイレクト先とURLスキームの検証
6 内部ネットワークへの到達可否
7 承認の記録方法

ドキュメントに書かれていない事項を推測で埋めないこと。
不明な項目は必ず「記載なし」と書いてください。

接続後に不審な挙動が出たときの初動も、あらかじめ言語化しておけます。

以下は当事務所で発生したAIツールの不審な挙動の記録です。

【発生日時と事象】（貼り付け）
【接続していたツールと権限】（貼り付け）

次の順で整理してください。
- 止めるべき接続（優先順位つき）
- 顧問先の情報が外部へ出た可能性のある経路
- 確認すべきログの種類と保管場所
- 顧問先へ連絡する場合に伝える事実と、まだ伝えられない事項の切り分け

法的評価の断定はせず、事実の整理に留めること。
甲事務所・A社のような架空の呼称を使い、実在の顧問先名は書かないこと。

出力はいずれも下書きです。接続の可否と顧問先への連絡は、事務所の有資格者が判断する工程として残します。

守秘義務から見たMCP接続の論点

MCPの仕様が守らないものを、士業側の条文が守っているわけでもありません。条文が定めているのは結果としての秘密保持であって、技術的な手当ての中身は事務所が設計する領域です。

公認会計士法第27条は、公認会計士が正当な理由がなくその業務上取り扱ったことについて知り得た秘密を他に漏らし、または盗用してはならないと定めています。社会保険労務士法第21条、弁理士法第30条にも同趣旨の規定が置かれています。弁護士法第23条は、職務上知り得た秘密を保持する権利を有し義務を負うという形で書かれています。文言の差はありますが、いずれも漏えいの有無を問う構造です。接続経路の技術的な細部は条文に書かれていません。

個人データを扱う場面では、個人情報の保護に関する法律第23条が、個人情報取扱事業者に対し、取り扱う個人データの漏えい、滅失または毀損の防止その他の安全管理のために必要かつ適切な措置を講じなければならないと定めています。何が必要かつ適切かは条文の文言から一義に決まるものではなく、扱う情報の性質と規模に応じて事務所が組み立てる部分です。MCP接続の7点検は、この組み立てを具体化する材料として使えます。

国のガイドラインの側にも、同じ方向の記述があります。AI事業者ガイドラインの第1.2版は、AIエージェントが外部システムと自律的に連携する際に内部データが不正に外部へ送信されるリスクに触れ、扱うデータを必要最小限に限定することと、適切な権限設定の重要性を追記しました（出典: 総務省・経済産業省 AI事業者ガイドラインの令和7年度更新内容）。MCPの仕様が実装者へ投げた責任と、国のガイドラインが利用者へ示した留意事項は、同じ場所を指しています。

実務で判断が割れやすいのは、事務所の共有フォルダをまるごと接続対象にしてよいか、という点です。AIに調べさせる範囲を広く取るほど回答の質は上がりますが、同時に外へ出る可能性のある情報も増えます。対応としては、AI向けに参照させるフォルダを別に切り、そこへ入れる資料を選ぶ運用が採られています。作業は増えますが、どの資料が接続対象かを一覧で言えるようになるため、顧問先への説明が一段楽になります。事件記録や人事評価のように、そもそも接続対象から外すと決めておく類型を先に定義しておくと、現場で迷う場面が減ります。

顧問先への説明では、接続しているツールの名前を並べるよりも、どの情報が事務所の外へ出る経路にあるのかを示すほうが伝わります。社内サーバの文書には接続していない、外部送信を伴う操作は所内の承認を経る、といった事実を一枚にまとめておくと、問い合わせに即答できます。接続構成を変えたときに更新する担当を決めておくと、説明資料が実態から離れずに済みます。

接続まわりでつまずく3つの型

一つめは、便利さが先に走って接続範囲が広がる型です。読み取りだけのつもりで入れたツールに、あとから書き込みやメール送信の権限を足し、誰も範囲を把握していない状態になります。スコープを最小から始める設計は、この広がりを止めるためのものです。権限を足した日付と理由を記録に残すだけでも、棚卸しのときに追えます。

二つめは、ツールの説明文を人間向けの文章として読んでしまう型です。仕様書はツールの記述や注釈を信頼できないものとして扱うべきだと述べています（出典: Model Context Protocol Specification）。説明文はAIモデルへ渡される入力でもあるため、そこに書かれた指示が挙動へ影響する余地が残ります。出所の分からない配布元からツールを入れない、という運用がここでの防御になります。

三つめは、事故が起きたときに何を見ればよいか決まっていない型です。接続したツールのログがどこに残るのか、保管期間はどれだけか、そもそもログを取得できる契約なのかを、導入時に確認していない事務所は少なくありません。ガイドはstdioトランスポートの利用をログに残して監視することを推奨しており、記録の設計が事後の説明を支えます（出典: MCP Security Best Practices）。

四つめは、導入したツールの棚卸しが止まる型です。試用のまま使い続けているもの、担当者が個人の判断で入れたもの、更新が止まって久しいものが混ざり、一覧が実態を表さなくなります。接続先が増えるほど、どこか一か所の弱さが全体に響く構造になるため、使っていないものを外す作業そのものが防御になります。棚卸しの日を年間予定に先に入れておく方法が採られています。

点検にかかる工数と担当の置き方

7点検そのものは、ツール一つあたり半日から一日で終わる規模です。時間がかかるのは、ベンダーへの質問と回答待ちのほうです。記載なしの項目が多いツールほど往復が増えるため、候補を三つ程度に絞ってから審査に入る進め方が現実的です。

担当は、情報システム担当と有資格者の二名体制が回しやすいところです。技術的な確認は前者が、顧問先の情報がどこまで流れるかの判断は後者が持ちます。AI事業者ガイドラインの第1.2版が、差別的出力の分類を技術的リスクから倫理・法に関するリスクへ移したのも、技術的特性だけでは判断が決まらないという整理によるものです（出典: 総務省・経済産業省 令和7年度更新内容）。接続の可否も同じ構造で、技術担当だけに預けきらない形が合います。

費用面では、仕様書とセキュリティのガイドはいずれも無償で公開されています。審査そのものに追加の支出は発生しません。発生するのは、条件を満たさないツールを見送る判断による機会損失のほうで、ここをどう見るかは事務所の方針になります。

審査の記録は、あとから効いてきます。見送ったツールについても、どの項目で落としたのかを一行残しておくと、次に似たツールが来たときの判断が早くなります。ベンダー側が仕様を改善して再提案してくることもあるため、落とした理由が残っていれば、その一点だけを確認して再検討に入れます。記録の形式は凝らなくてよく、ツール名、確認日、落とした項目、確認した担当の四つが並んでいれば足ります。

なお、審査を通ったツールでも、事務所が扱う情報の種類によって接続してよい範囲は変わります。同じツールを使っていても、税務の顧問業務と、係争中の案件とでは、外部へ出してよい情報の線が違うためです。ツール単位ではなく、業務類型とツールの組み合わせで可否を持つ形にしておくと、現場の判断が揺れにくくなります。

次に論点になりそうなこと

仕様の側は動き続けています。2026-07-28版ではステートレス化が明記され、セッションIDを前提にした旧版の記述は過去のバージョンへ移されました（出典: MCP Security Best Practices）。事務所の点検項目を仕様のバージョンに紐づけて書いておかないと、数か月で前提が合わなくなります。審査シートの冒頭に、参照した仕様のバージョンを書いておく運用が要ります。

もう一つは、複数のAIエージェントが相互に連携する形態です。MCPは一つのホストと複数のサーバをつなぐ規格ですが、エージェント同士の連携は別の規格が担います。連携が増えるほど、どの段階で人間が判断に入るのかを決めておく設計が効いてきます。接続の点検と、委任範囲の設計は、別々に組み立てる話として分けておくほうが整理しやすいところです。

よくある質問

MCPに対応していれば安全なツールと考えてよいですか

規格への対応と安全性は別です。仕様書は、MCP自体が安全性の原則をプロトコルの層で強制することはできず、実装者が同意と認可のフローを組み込むことを推奨すると述べています（出典: Model Context Protocol Specification）。対応の有無ではなく、実装の中身を確認する作業が残ります。

ツールの説明文はどこまで信用できますか

信頼できるサーバから得たものでない限り、信頼できない入力として扱うべきだと仕様書は述べています（出典: 前掲仕様書）。説明文はAIモデルへ渡される入力でもあるため、内容がそのまま挙動へ影響する余地があります。

ローカルで動くMCPサーバは社内なので安全ですか

ローカルサーバは端末上でコードを実行するものです。ガイドは、ワンクリック設定に対応するクライアントが、実行されるコマンドを省略せずに表示し、明示的な承認を得ることを求めています（出典: MCP Security Best Practices）。社内かどうかではなく、何を実行するかで判断する箇所です。

スコープは最初から広く取ったほうが手間が減りませんか

ガイドは、ワイルドカードや全権限を意味するスコープを避けるべき設計上の誤りとして挙げ、最小のスコープから段階的に引き上げる方式を推奨しています（出典: 前掲ガイド）。広いトークンが漏れた場合の影響範囲が広がることが理由として示されています。

守秘義務の条文にMCPのことは書かれていますか

書かれていません。公認会計士法第27条や社会保険労務士法第21条は秘密の漏えいと盗用を禁じる形で書かれており、技術的な手当ての中身までは定めていません。どう手当てするかは事務所が設計する領域として残ります。

顧問先に接続構成を説明する義務はありますか

説明の要否は契約と事案によるため、一律には言えません。個人データを扱う場面では個人情報の保護に関する法律第23条が安全管理措置を定めており、その内容を説明できる状態にしておく実務上の利点があります。どこまで開示するかは事務所の判断になります。

小規模事務所でも7点検は現実的ですか

ツール一つあたりの作業としては現実的な規模です。ベンダーの公開ドキュメントを読み、記載のない項目を質問する形で進められます。審査シートの草案づくりに生成AIを使い、質問の送付と判断を有資格者が担う分担が採られています。

参考文献

• Model Context Protocol Specification 2026-07-28
• Model Context Protocol Security Best Practices
• 総務省・経済産業省 AI事業者ガイドラインの令和7年度更新内容
• e-Gov法令検索 公認会計士法第27条
• e-Gov法令検索 社会保険労務士法第21条
• e-Gov法令検索 弁理士法第30条
• e-Gov法令検索 弁護士法第23条
• e-Gov法令検索 個人情報の保護に関する法律第23条

あわせて、MCP新ロードマップの5領域と導入前の確認事項、MCPのサンプリング廃止と遮断設計、AI事業者ガイドライン第1.2版を規程に落とす7項目もご覧ください。

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