2026 年 5 月 19 日、InfoQ が Anthropic Introduces MCP Tunnels for Private Agent Access to Internal Systems を公開しました。MCP Tunnels は、グローバル IP を持たない社内 DB / 基幹 / 内製 API に対し、ファイアウォールを開けずに外部の Claude エージェントを接続できる Anthropic 公式の双方向トンネル機能です。Cloudflare Tunnel / Tailscale Funnel に近い思想を MCP プロトコル専用に最適化したもので、送信側からの ngress 開放が不要な点が決定的に異なります。
受託で中堅企業の AI 化を担う立場では、これまで 「社外公開できない基幹システムは AI 化できない」 という壁がありました。本機能の登場で、自社MCPサーバー群の構築実務ガイド や MCP が Linux Foundation 入り で扱った社内 MCP 戦略の 「最後のピース」 が揃います。本記事では、MCP Tunnels を使って社内システムをエージェント化する際の設計論点と進め方を、受託の現場視点で整理します。
なぜ MCP Tunnels が中堅企業の AI 化のボトルネックを外すか
| 課題 | 従来の限界 | MCP Tunnels による変化 |
|---|---|---|
| 基幹 DB への接続 | VPN 払い出し + IP 制限が必要 | アウトバウンド接続のみで完結 |
| 内製 API の AI 連携 | リバースプロキシ + 認証の自前構築 | MCP プロトコル標準で接続 |
| オンプレ業務システム | DMZ 構築 / 機器調達が必要 | エージェント 1 プロセスで開通 |
| 情シスの審査工数 | 案件ごとに月単位の調整 | テンプレ化された審査ルートに |
| 監査ログ | 各経路で分散 | Tunnel 単位で一元化 |
これは 「金庫の中で AI を動かす」 から 「金庫の外から AI が金庫に手を伸ばす」 への転換です。インバウンド口を開けない情シス制約と、エージェントの便益を両立させる現実解になります。
MCP Tunnels が変える 3 つの構造
構造 1: 「VPN ベース」から「アプリケーション層トンネル」へ
従来は社外エージェントを社内に入れるために サイト間 VPN / クライアント VPN を張る必要がありました。MCP Tunnels は HTTPS アウトバウンドのみで確立されるため、新規ファイアウォール例外が不要になります。情シス審査が 数週間 → 数日に短縮されます。
構造 2: 「全体公開」から「ツール単位の最小権限」へ
VPN は 「ネットワーク全体に到達可能」になりますが、MCP Tunnels は **「MCP ツール単位での到達範囲」を絞れます。「在庫照会だけ許可、在庫更新は禁止」**のような粒度を トンネル定義で表現できます。これは 既存APIをMCPサーバー化する設計パターン の権限設計の延長です。
構造 3: 「経路ごとの監査」から「トンネル単位の監査」へ
接続元 / 接続先 / 呼ばれた MCP ツール / 引数 / 応答 / トークン消費を トンネル単位で 1 本のログに集約できます。「誰が、どの基幹に、何回、何をした」が監査側にとって追跡可能になります。
「MCP Tunnels + 社内システムエージェント化」を進める 5 フェーズ
フェーズ 1: 接続対象システムの棚卸し（2 週間）
顧客社内で **「どの業務システム」「どのデータ」「どの操作」を AI に解放するかを棚卸しします。販売管理 / 在庫 / 会計 / 人事 / 工程が典型です。「読み取り専用 / 書き込み許可」**の分類が最重要です。
フェーズ 2: トンネル設計とゼロトラスト統合（1〜2 週間）
- アウトバウンド経路（プロキシ / SOCKS 経由か直接か）
- 認証（顧客 IdP / OAuth / mTLS）
- ツール単位の権限マッピング
- 監査ログ集約先（顧客 SIEM / 自社運用）
を 「ネットワーク図 + 権限マトリクス + 監査ログ要件」として文書化します。
フェーズ 3: MCP サーバーのトンネル対応実装（2〜4 週間）
既存の社内 API / DB に MCP ラッパーを実装し、MCP Tunnels クライアントを同梱します。読み取り専用ツールから始め、書き込みツールは承認フロー付きで段階追加します。
フェーズ 4: 業務エージェント側の組み込み（2〜3 週間）
Claude / Claude Code / 顧客社内エージェントから トンネル経由で MCP ツールを呼ぶ実装を整備します。プロンプト設計 + ガードレール + フォールバックを含めます。
フェーズ 5: 月次運用代行（継続）
- トンネル稼働監視
- 監査ログレビュー
- 新規ツール追加 / 既存ツール権限変更
- インシデント一次対応
は、開通後に継続運用として回し続ける必要があります。誰が担うのかを構築フェーズの時点で決めておきます。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| トンネル | Anthropic MCP Tunnels（公式） | Cloudflare Tunnel + 自前 MCP |
| MCP サーバー | Python mcp / TypeScript SDK | 自前 HTTP API |
| 認証 | mTLS + OAuth（顧客 IdP 連携） | API キー（PoC のみ） |
| 権限管理 | OPA / Rego ポリシー | 自前 RBAC |
| 監査ログ | OpenTelemetry → 顧客 SIEM | Loki / Elasticsearch |
| シークレット | HashiCorp Vault / GCP Secret Manager | AWS Secrets Manager |
| 稼働監視 | Prometheus + Grafana | Datadog |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| 基幹 / 業務 DB に AI から触れたい | 社外公開 API のみで完結 |
| グローバル IP を持たない社内 API | 既に SaaS に集約済み |
| 情シスがインバウンド開放を拒否 | DMZ 運用が既に成熟 |
| 監査要件で経路一元化が必須 | 監査範囲外の社内ツール |
| 複数拠点 / 海外子会社の業務システム | 単一拠点のみ |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象システム | 接続するシステム名と操作種別 | 範囲外システムは別契約 |
| 権限マトリクス | ツール × ロールの許可表 | 経営層承認 |
| 監査ログ保管 | 12 / 36 / 60 ヶ月 | コンプライアンス |
| インシデント対応 SLA | 一次切り分け時間 / 復旧目標 | 業務影響度 |
| トンネル切断時挙動 | 自動再接続 / 業務停止判定 | 業務継続性 |
| 退会時引き渡し | MCP 定義 + IaC + 監査ログ | 自社運用継続性 |
ハマりやすい 5 つの落とし穴
落とし穴 1: 「すべてのシステムを一度に開通」
トンネルは 「同時に全部」ではなく 「読み取り系から段階解放」が鉄則です。書き込み系を初期に入れるとロールバックが地獄になります。
落とし穴 2: 権限マトリクスの未承認運用
経営層 / 情シス / 業務部門の三者承認なしで権限を増やすと、監査時に説明不能になります。承認 PR → 自動反映の運用を初期に設計します。
落とし穴 3: 監査ログの保管期間ズレ
業務システム側の保管期間（例: 7 年）と MCP Tunnel ログの保管期間（例: 12 ヶ月）が ズレると、事象発生時に紐付かない事故が起きます。最長期間に揃える設計が必要です。
落とし穴 4: トンネル切断時の業務停止連鎖
「トンネルが切れたら AI 機能だけ止まる」のか「業務 UI ごと止まる」のかが曖昧だと、現場が混乱します。サーキットブレーカー + ダウングレード表示を必ず設計します。
落とし穴 5: ツール定義の野放図な追加
MCP ツール定義を野放図に増やすと、エージェントが 不要なツールも試行してトークンが膨らみます。ツールカタログの月次レビューで剪定します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | 接続対象システムの棚卸し |
| Week 3〜4 | トンネル設計 + 権限マトリクス策定 |
| Week 5〜8 | MCP ラッパー実装 + 読み取り系開通 |
| Week 9〜11 | 業務エージェント組み込み + 段階リリース |
| Week 12〜13 | 監査ログ統合 + 月次運用立ち上げ |
まとめ — 「金庫の外から手を伸ばす」AI 化が標準になる
Anthropic の MCP Tunnels 公開により、「社内 DB / 基幹システムは AI 化できない」 という長年の制約が外れました。受託で中堅企業の AI 化を担う立場では、ゼロトラスト + ツール単位最小権限 + 監査統合を一体で設計できるかどうかが、これからの分かれ目になります。
社内システムのエージェント化は、接続対象の系統数・読み書きの範囲・監査要件によって設計も工数も大きく変わるため、要件をうかがったうえで個別にお見積りします。「基幹を AI に触らせたいが社外公開はできない」「情シスの審査で AI 案件が止まっている」「監査要件で経路一元化したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
