MCPトンネルで所内サーバーをClaudeにつなぐ前に士業事務所が確認する7論点

MCPトンネルとは、非公開ネットワーク内のMCPサーバーをClaudeにつなぐ仕組みのことです。

事務所の文書管理サーバーを、インターネットに公開せずにClaudeから呼び出せたら、と考えたことはないでしょうか。Anthropicが提供するMCPトンネルは、この発想に近い仕組みです。ただしリサーチプレビューの段階にあり、公式ドキュメントには、稼働や保守の約束がないことも明記されています。この記事では、公式ドキュメントに書かれていることだけを土台に、士業事務所が採用を検討する前に確認したい7つの論点を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、製品の仕様はAnthropicの公式ドキュメントで確認しています。なお、実際に試して検証した結果ではなく、ドキュメントの記載を読んだ整理である点をあらかじめお伝えします。

MCPトンネルの仕組みと、公式ドキュメントが明記している条件

最初に事実関係を確認します。公式ドキュメントによると、MCPトンネルは、非公開ネットワーク内で動くMCPサーバーにClaudeを接続するための仕組みで、通信は外向きのみの接続で流れます。そのため、内向きのファイアウォールのポートを開けたり、サービスを公開インターネットに出したり、Anthropic側のIPアドレス帯を接続元で許可したりする必要がないと説明されています（出典: Anthropic公式ドキュメント MCP tunnels）。

構成要素は2つで、どちらも利用者側のネットワーク内で動かします。1つ目はCloudflareのオープンソースのトンネルコネクタであるcloudflaredで、外向きの接続だけを張り、暗号化された通信を運びます。2つ目はAnthropicのプロキシで、内側のTLSを終端し、接続先のIPが許可された範囲に入っているかを検証し、ホスト名に基づいて各MCPサーバーに振り分けます（出典: 同ドキュメント）。

現時点の位置づけも重要です。同ドキュメントは、MCPトンネルがリサーチプレビューであり、利用にはアクセス申請が必要で、現状のまま提供され、稼働時間、サポート、継続性の約束はないとしています。また、基盤となる通信は第三者のネットワーク事業者であるCloudflareに依存し、その事業者も可用性を約束していないこと、Anthropicがいつでも変更や提供終了を行い得ることも書かれています（出典: 同ドキュメント）。Claudeの発表記事でも、MCPトンネルはリサーチプレビューとして紹介され、公開エンドポイントやIP許可リストが不要になる点が利点として挙げられています（出典: Claude MCP 2026-07-28 の解説記事）。

利用できる場所にも限りがあります。同ドキュメントによれば、トンネル経由のMCPサーバーは、Claude Managed AgentsとMessages APIから使えます。コンソールで作成したトンネルは、claude.aiのコネクタとしては使えません（出典: 同ドキュメント）。つまり、事務所の職員が普段のチャット画面から所内サーバーを呼び出す用途ではなく、API連携やエージェントの構築を前提にした機能です。この点は、導入の担い手が誰になるかに直結します。

論点1から3 提供段階、利用範囲、構築の担い手を見極める

1つ目の論点は、提供段階をどう評価するかです。リサーチプレビューで、稼働や継続性の約束がないことは、業務の基幹に据えにくいことを意味します。事務所の業務が止まると困る用途ではなく、止まっても影響の小さい用途で試す、という切り分けが考えられます。たとえば、事務所の内部資料の検索補助のような、失敗しても人が代替できる業務です。納期のある書面作成の経路に組み込むことは、現時点では慎重に検討する領域になります。

2つ目の論点は、利用範囲です。前述のとおり、claude.aiのコネクタとしては使えないため、職員が日常的に使うチャットから呼び出せるようになるわけではありません。使えるのは、Managed AgentsとMessages APIです。この制約を知らずに採用を決めると、期待していた使われ方と実態が食い違います。事務所内で誰が、どの画面から使うのかを、先に絵にしておきます。

3つ目の論点は、構築の担い手です。必要条件として、同ドキュメントはKubernetesクラスターか、DockerとDocker Composeを動かせる仮想マシンを挙げています。認証には、ワークロードIDフェデレーションによる方法（推奨とされています）と、手動で認証情報を用意する方法があります。手動の場合は、コンソールのトンネルトークンと、登録した認証局が署名したサーバー証明書を用意します（出典: 同ドキュメント）。これらは、一般的な士業事務所の職員が担当できる範囲を超えることが多く、外部のIT事業者との役割分担が前提になります。その場合、事務所とIT事業者のどちらが何を管理するかを、契約と手順書で決めておくことが論点です。

試験導入の進め方 5つの工程で段階的に確かめる

採用を決める前の試験は、小さく始めて工程ごとに確認する形が考えられます。以下は公式ドキュメントの記載を土台にした編集部の整理で、手順書そのものではありません。実際の構築は、公式のクイックスタートとIT事業者の支援を前提にしてください。

工程1は、接続対象の選定です。トンネルで公開するMCPサーバーを1つに絞り、その中身を、公開済みの資料や事務所の書式集のような、影響の小さい情報に限ります。顧問先の個人データを含むサーバーは、最初の対象から外します。ここで決めた範囲が、後の工程の評価基準になります。

工程2は、アクセス申請と社内の合意です。公式ドキュメントはアクセス申請のフォームを案内しており、申請が通るかどうかは本記事では確認できていません。申請と並行して、所長と情報担当、IT事業者の三者で、試験の目的と終了条件を文書にします。終了条件には、いつまでに何を確かめたら採用の判断に進むか、問題が起きたらどう止めるかを含めます。

工程3は、構築環境の準備です。公式ドキュメントが挙げる前提は、KubernetesクラスターかDockerとDocker Composeを動かせる仮想マシン、コンソールまたはAPIで作るトンネル、認証の手段、非公開ネットワーク内のMCPサーバー、外向き通信の確保です（出典: Anthropic公式ドキュメント MCP tunnels）。認証は、ワークロードIDフェデレーションを使う方法と、トンネルトークンと証明書を手で用意する方法から選びます。試験では手動でも足りますが、本番に近づくほど鍵の管理が重くなるため、どちらを採るかを工程の早い段階で決めておきます。

工程4は、経路の動作確認です。各MCPサーバーには、トンネルのドメイン配下のホスト名が割り当てられ、プロキシがホスト名に基づいて振り分けます。同ドキュメントによれば、プロキシは接続先のIPが許可された範囲に入っているかも検証します。つまり、サーバーを増やすたびに、ホスト名と許可範囲の設計が必要になります。確認項目としては、想定したサーバーだけに届くか、想定外のサーバーには届かないか、認証がかかっているかの3点を、記録を取りながら見ます。

工程5は、評価と判断です。試験の記録をもとに、業務での有用性、運用にかかった工数、障害の有無、鍵と証明書の管理の負担を並べて確認します。提供段階が変わる可能性があるため、判断には期限を設け、期限が来たら再評価する、という形にしておくと、使い続ける理由が曖昧にならずに済みます。有資格者が最終的な採否を判断し、その記録を残すことも、この工程に含めます。

この5工程のうち、最も軽く見られがちなのは工程1と工程5です。技術的な構築は外部の事業者が進められますが、何を対象にするかと、結果をどう評価するかは、事務所自身の判断事項です。

論点4から5 セキュリティの責任分担と、見えるもの・見えないもの

4つ目の論点は、責任分担です。同ドキュメントのセキュリティモデルは、3つの独立した層を示しています。AnthropicとCloudflareの間の相互TLSとIP検証、Anthropicのバックエンドから利用者のプロキシまでの内側のTLS、各MCPサーバー上のOAuthです。内側のTLSは利用者だけが持つ証明書で終端されるため、Cloudflareは通信の中身を読めないと説明されています（出典: Anthropic公式ドキュメント MCP tunnels）。

一方で、責任分担の表は、利用者側の役割を明記しています。トンネルを通る内容と通信の全て、および第三者の利用規約（Cloudflareのものを含む）の遵守、トンネルトークンとTLS秘密鍵の保護、サーバー証明書の更新、各MCPサーバーのOAuth設定、プロキシとMCPサーバーへのネットワークアクセスの制限、侵害が疑われる場合のAnthropicへの通知は、利用者の側の取り組みとされています（出典: 同ドキュメント）。さらに、トンネルトークンとTLS秘密鍵の両方が攻撃者の手に渡ると、プロキシのなりすましとMCPリクエストの内容の読み取りが可能になり得る、という警告も書かれています（出典: 同ドキュメント）。つまり、仕組みが公開ポートを閉じても、鍵の管理という新しい守りが事務所側に生じます。

5つ目の論点は、見えるものの範囲です。同ドキュメントは、Cloudflareが通信の中身は読めない一方、接続メタデータを受け取るとしています。具体的には、cloudflaredを動かすホストの外向きIPアドレス、cloudflaredのホストのフィンガープリント、接続のタイミングとバイト量、トンネルに割り当てられたサブドメインです。AnthropicとCloudflareの契約はこのテレメトリの利用を制限しており、Cloudflareはこのリサーチプレビューでサブプロセッサーとして扱われます（出典: 同ドキュメント）。通信の中身は見えなくても、いつ、どれだけ通信したかは第三者に見える。この区別を、顧問先への説明や事務所の規程にどう反映するかが論点になります。

守秘義務・規程上の論点所内サーバーの中身がAIの経路に乗る前に

士業にとって最も重いのは、所内サーバーの情報がAIの処理経路に乗ることの意味です。弁護士法第23条は、弁護士に職務上知り得た秘密を保持する権利と義務を定めています（出典: e-Gov法令検索弁護士法第23条）。税理士法第38条は、税理士業務に関して知り得た秘密を正当な理由なく漏らしたり窃用したりしてはならないと定めます（出典: e-Gov法令検索税理士法第38条）。司法書士法第24条も、業務上取り扱った事件について知ることのできた秘密を、正当な事由がある場合でなければ他に漏らしてはならないと定めています（出典: e-Gov法令検索司法書士法第24条）。

個人情報保護法の側では、個人データの安全管理措置を定める第23条、委託先の監督を定める第25条が、検討の入口になります（出典: e-Gov法令検索個人情報保護法第23条、同第25条）。トンネル経由でAIが所内サーバーの顧問先データを読む場合に、AI提供者や通信事業者との関係をどう整理するかは、個別の構成や契約で結論が変わります。本記事は当てはめを行いません。所属の職能団体の指針や専門家に確認してください。

規程に落とす場合の運用例として、4点を挙げます。第1に、トンネルに接続するMCPサーバーを、公開してよい範囲の資料に限定する。第2に、各MCPサーバーにOAuthなどの認証を設定し、権限を最小にする。第3に、誰がいつ何を呼び出したかを記録する。第4に、鍵と証明書の保管者と更新日を台帳に残す。これらは公式ドキュメントの責任分担表を、事務所の運用に引き直した編集部の整理です。MCPサーバーの設計の考え方は、既刊の自作MCPサーバーを事務所の業務データにつなぐ手順とMCP連携の監査ログを書籍化する設計で解説しています。

論点6から7 費用と運用体制、そして撤退の設計

6つ目の論点は、費用と運用体制です。公式ドキュメントには料金の記載がなく、本記事では費用を確認できていません。確認できるのは、動かす場所（KubernetesまたはDockerを動かせる仮想マシン）、セットアップ用のコンポーネントがapi.anthropic.comの443番ポートへ、cloudflaredがトンネルのエッジの7844番ポートへ、外向きに通信できる必要があるという要件です（出典: Anthropic公式ドキュメント MCP tunnels）。仮想マシンの費用、保守を担う人の工数、証明書の更新作業が、実質的なコストになります。これらの金額は事務所の構成によるため、IT事業者からの見積りで確認するのが現実的です。

7つ目の論点は、撤退の設計です。提供終了が起こり得ると公式に書かれている以上、使えなくなる日を前提にした設計が欠かせません。トンネルに依存した業務フローを作る場合は、停止時に人が手作業で代替できる手順を残します。また、トンネル用に作ったMCPサーバーやOAuthの設定は、トンネルがなくなっても別の経路で使い回せるように、疎結合に作っておくと被害が小さくなります。

試す前に使えるプロンプト例

次のプロンプトは、構成案を書き出して論点の抜けを探すためのものです。実在の事務所情報は入れず、架空の条件で試してください。

あなたは法律事務所の情報システム担当を支援するアシスタントです。
次の構成案について、守秘義務と個人データの観点から、確認が必要な項目を洗い出してください。
根拠が確認できない点は「要確認」と付け、法令の条番号は書かないでください。

構成案: 所内の文書管理サーバーにMCPサーバーを置き、MCPトンネル経由でAPIから呼び出す。
接続する資料は、公開済みの判例メモと事務所の書式集に限る。認証はOAuthを使う。

次の運用メモを、事務所の規程に載せる文章の下書きにしてください。
断定的な表現は避け、確認者の欄と、鍵と証明書の台帳の項目を加えてください。

運用メモ: トンネルの鍵は情報担当が保管し、更新は年1回。接続サーバーは追加時に所長が承認する。

出力は下書きです。内容の確認と採否の判断は、有資格者である所長や担当者が行います。

失敗例と回避策

想定される失敗を3つ挙げます。実在の事例ではなく、公式ドキュメントの構造から編集部が考えた例です。1つ目は、公開ポートを開けなくて済むことから、セキュリティの検討を簡略にしてしまうケースです。回避策は、責任分担表の利用者側の項目を、チェックリストにして1つずつ確認することです。

2つ目は、各MCPサーバーのOAuth設定を省略するケースです。同ドキュメントは、トンネルは暗号化された通信を運ぶだけで、MCPサーバーへの認証は行わないと説明しています。トンネルがあるから安全、と考えると、サーバー側の認証が抜け落ちます。回避策は、サーバーごとに認証を設定し、設定の有無を台帳に残すことです。

3つ目は、鍵と証明書の更新を忘れるケースです。サーバー証明書の更新は利用者の責任と明記されています。期限切れで突然つながらなくなる事態は、納期のある業務で起きると痛手になります。回避策は、更新期限をカレンダーに登録し、担当者を複数置くことです。

今後の展望と考察

MCPトンネルは、所内サーバーの資料を外部に出さずにAIから参照させたい、という士業の根強い要望に応え得る仕組みです。ただし、現時点では提供段階、利用範囲、構築の難しさのどれもが、全ての事務所に勧められるものではありません。論点になるのは、一般提供への移行時期と、claude.aiからの利用可否、料金の公表の3点です。これらが公式に示された段階で、あらためて評価し直すのが妥当です。

それまでの間にできるのは、所内データの整理と、アクセス権限の見直しです。トンネルを使わない場合でも、これらはAI活用の基礎になります。

よくある質問

MCPトンネルは今すぐ事務所で使えますか

使えるとは言い切れません。公式ドキュメントでは、リサーチプレビューでアクセス申請が必要とされています。申請の可否や条件は、本記事では確認できていません。

職員がチャット画面から所内サーバーを呼び出せますか

公式ドキュメントでは、コンソールで作成したトンネルはclaude.aiのコネクタとして使えないとされています。使えるのは、Managed AgentsとMessages APIです。

通信の中身はCloudflareに見られますか

同ドキュメントでは、Cloudflareは通信の中身を読めないとされています。ただし、接続元のIPアドレスやタイミングなどのメタデータは受け取ると記載されています。

公開ポートを開けなくて済めば、セキュリティは十分ですか

十分かどうかは、構成によります。同ドキュメントは、トンネルトークンやTLS秘密鍵の管理、各MCPサーバーのOAuth設定などを利用者側の責任としています。要件を満たしているかは、IT事業者や専門家に確認してください。

料金はいくらですか

公式ドキュメントには料金の記載がなく、本記事では確認できていません。料金の有無も含めて、公式の案内をご確認ください。

守秘義務の観点では、どこから手を付ける運用例がありますか

接続する資料の範囲を決めることから始める運用例があります。公開済みの資料や事務所の書式集など、影響の小さいものに限定して試す方法です。条文の当てはめは、個別の事情によるため、専門家に確認してください。

参考文献

あわせて、外部MCPサーバーの安全性を審査する基準、MCP OAuth2.1のセキュリティ確認7項目もご覧ください。

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

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

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

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

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