AIエージェントによるローカルトンネル管理

長年、ローカル開発サーバーをインターネットに公開する際の摩擦は、AIコーディングアシスタントの範囲外でした。エージェントにWebhookハンドラーを書かせることは可能ですが、Stripeやモバイルクライアント、クライアントデモのために公開URLが必要なとき、チャットを離れて別のターミナルを開き、トンネルコマンドを実行し、URLをコピーして貼り付ける作業を繰り返していました。コード自体は自動化されましたが、ネットワークの結合部分はそうではありませんでした。Model Context Protocol（MCP）がエージェントにツールコールを提供し、トンネル自体に直接アクセスできるようになったことで、この状況は変わりつつあります。

これは完全な革命ではなく、多くの開発者は今も手動で cloudflared や ssh -p 443 -R0:localhost:3000 a.pinggy.io を実行していますし、それを自動化するMCPサーバーも、運用者の認めるところではまだ初期段階です。しかし、これらの仕組みは実在し、ドキュメント化されており、ターミナルアクセスを持つエージェントに組み込む前に理解しておく価値があります。

これまでのボトルネックの置き換え

Webhook連携のテストは、コードの問題ではありません。StripeやShopify、GitHubアプリは公開URLを必要とし、あなたの開発サーバーは localhost のみで待ち受けています。従来の流れは:

1. ローカルサーバーを起動
2. もう一つのターミナルを開く
3. トンネルコマンドを実行し、接続待ち
4. 生成されたURLをコピー
5. サードパーティのダッシュボードに貼り付け
6. テストイベントを送信
7. トンネル再起動やURL変更ごとに3〜6を繰り返す

これらは難しくありませんが、フローを妨げるものであり、ツール呼び出しエージェントが吸収できる機械的な多段階作業です。トンネルがツールとしてアクセス可能であれば、これらの作業を自動化できます。

MCPがこれを可能にする標準

Anthropicは2024年11月25日にModel Context Protocol（MCP）をオープンソース化し、AIアプリケーションとデータやツールが存在するシステムをつなぐ標準としました。MCP以前は、モデルと外部ツールの連携は個別の統合が必要で、「N×M」問題と呼ばれ、NモデルとMツールの組み合わせごとにカスタム接続が必要でした。MCPはこれを、どのツールも一つのサーバーで扱える仕組みに集約します。

アーキテクチャは三つの部分:

• Host — ユーザー向けアプリケーション（IDE、チャットクライアント、カスタムエージェント）
• Client — MCPを話すホスト内の部分で、呼び出しをサーバーにルーティング
• Server — ツール（実行可能なアクション）、リソース（文脈データ）、プロンプト（テンプレート）を公開

メッセージはJSON-RPC 2.0で交換され、Request/Responseの流れはLanguage Server Protocol（LSP）に由来します。これにより、エディタと任意の言語の補完バックエンドがカスタム統合なしに通信可能です。

既に二度のトランスポート層の変更

最初のリリース（2024-11-05）は、stdio（ローカル・シングルクライアント用）とHTTP+SSE（リモートサーバー用）をサポート。2025-03-26の改訂で、HTTP+SSEは「Streamable HTTP」に置き換えられ、負荷分散やセッション再開に対応した単一エンドポイントとなりました。SSEは後方互換のためだけに残されています。

その後、2026年7月28日に、プロトコルのメンテナは大きな変更を行い、セッションハンドシェイクを廃止し、MCPをステートレス化しました。これにより、クライアントの状態を追跡する必要がなくなり、リクエストはどのインスタンスでも応答可能に。拡張フレームワークや機能廃止の猶予期間も正式化されました。既存の2025-11-25クライアントは引き続き動作し、新しいリビジョンはアップグレード時に選択可能です。

迅速な採用

OpenAIは2025年3月26日にAgents SDKにMCPサポートを追加し、その後Responses APIやChatGPTデスクトップも対応。Google DeepMindは翌月にGeminiに採用を表明。2025年12月9日、AnthropicはMCPのガバナンスをLinux FoundationのAgentic AI Foundationに寄付し、AWS、Google、Microsoft、Cloudflare、Bloombergなどが参加。2026年7月の仕様リリース時点で、公開サーバーは10,000以上、SDKダウンロードは月97百万以上に達し、TypeScriptとPython SDKはそれぞれ10億回超のダウンロードを記録しています。ガバナンスはコミュニティ運営のままです。

スキルとMCPサーバーは別物

以下のトンネリングベンダーは、MCPとは別に「エージェントスキル」という仕組みも利用しています。スキルはCLIフラグやSDKの使い方、例示プロンプトなどの指示と資料をパッケージ化したもので、エージェントは一度読み込み、通常のターミナルアクセスで自己実行します。一方、MCPサーバーは、エージェントが直接呼び出すツールとして動作し、ドキュメントからコマンドを再構築しません。これらは共通のコミュニティ標準（skills CLI、npx skills add <URL>）で公開・インストールされ、エージェントのスキルディレクトリに配置されます。Claude Codeの場合は ~/.claude/skills/<name>/です。ベンダーの指針は一貫しており、ツール理解にはスキルから始め、エージェントに自律運用させたいときにサーバーを追加します。

PinggyのスキルとMCPサーバー

Pinggyは両方を提供し、独立してインストール可能です。

スキル:

npx skills add https://pinggy.io

これにより、https://pinggy.io/.well-known/skills/からマニフェストを取得し、エージェントのスキルディレクトリに書き込みます。必要なのはNode.jsだけです。

MCPサーバー — ソースは github.com/Pinggy-io/pinggy_mcp で、Python 3.10+とuvが必要です:

curl -LsSf https://astral.sh/uv/install.sh | sh

グローバルインストールは不要で、クライアントは uvx 経由で pinggy-mcp を必要に応じて実行します。Claude Codeでは登録コマンドは設定ファイルではなくCLIコマンドです:

claude mcp add pinggy-mcp -- uvx --from git+https://github.com/Pinggy-io/pinggy_mcp.git pinggy-mcp

Claude Desktop、Cursor、WindsurfはJSON設定ファイルの mcpServers キーを使います（パスはクライアントやOSによる）。VS Codeは servers キーを使います。Pinggyのドキュメントでは、MCPサーバーは「早期かつ実験的」と記載されており、フィードバックを求めています。

接続後の例プロンプト例:

• “Expose my dev server on port 3000.”
• “Open a TCP tunnel to localhost:22.”
• “Share my ~/Downloads folder over the internet.”
• “List my active tunnels.”
• “Only allow traffic from 1.2.3.4 to my tunnel.”
• “Stop the tunnel.”

これらはエージェント向けのドキュメントであり、すべてMarkdown形式で公開されており、pinggy.io/llms.txtに要約もあります。エージェントはHTMLをスクレイピングせずに直接ドキュメントを読むことが可能です。

CloudflareのMCPサーフェスは「トンネル」以上

CloudflareのMCPサーバーは、cloudflaredに限定されません。Cloudflare API全体をカバーしています。代表的なものは Cloudflare API MCPサーバー (https://mcp.cloudflare.com/mcp) で、DNS、Workers、R2、Zero TrustのAPIを2,500以上のエンドポイントで公開。search()とexecute()の二つのツールを使い、OpenAPI仕様に基づくJavaScriptコードをCloudflareの「Code Mode」内で実行します。トークンの計算コストは、全エンドポイントをフルスキーマで公開した場合約117万トークンに対し、Code Modeは約1,000トークンです。

その他、ドメイン固有のサーバーもあり、ドキュメントサーバー、Workersバインディング、観測性、レーダー、監査ログ、DNS分析などがそれぞれサブドメインで運用されています。トンネル管理は、一般的なAPI MCPサーバーのsearch()/execute()パターンを使い、特定のトンネルツールを呼び出すわけではありません。例えば、search()/execute()を使ってトンネルの一覧や状態を取得します。

Cloudflareはまた、Cloudflare Skillsプラグイン (github.com/cloudflare/skills)を通じて、コンテキストスキルやスラッシュコマンドも提供しています。これらはClaude Codeのプラグインマーケットプレイスや/plugin marketplace add cloudflare/skillsコマンドからインストール可能です。

MCPサーバーポータル：実際のエンタープライズ制御層

Cloudflareの「ポータル」は、複数のMCPサーバーを一つのHTTPエンドポイントに集約し、Cloudflare Accessで保護します。具体的には:

• 認証：ユーザーはCloudflare Accessを通じてIDプロバイダーでログイン。OAuth認証も個別に促します。
• ツールの選別公開：管理者はツールやプロンプトの公開・非公開設定や、許可リスト化が可能。
• Code Mode：すべてのツールをcodeツールに集約し、エージェントはJavaScriptを書きます。これにより、複数サーバーをまとめてもコンテキストウィンドウの使用量は一定。
• ロギング：リクエストごとのログ（時間、ステータス、サーバー、ツール、所要時間）をダッシュボードで確認可能。LogpushによるSIEMエクスポートもEnterpriseプランで利用可。
• ルーティング：トラフィックはCloudflare Gateway経由も可能。認証情報や財務データを含むツール呼び出しやレスポンスをブロックできます。

ただし、Cloudflareの公式ドキュメントによると、ポータル経由で認証されたサーバーには、MFAや一時認証、目的明示のプロンプトは適用されません。これらはあくまでOAuthやツールの選別、DLPログのための仕組みです。

実例：Webhookテスト

Stripeはこのワークフローの典型例です。StripeのMCPサーバーは https://mcp.stripe.com で動作し、標準のOAuthフローとAPIキー（Bearerトークン）をサポートします。ツールはアカウント情報、払い戻し、リソース検索・取得、ドキュメント検索、統合計画などです。エージェントは、一般的な書き込みツールを使ってWebhookエンドポイントのURLを更新可能ですが、Webhookの受信やストリームの購読はMCPでは行えません。実際の流れは:

1. エージェントにローカルサーバーを起動させ、PinggyやCloudflare MCPツールで公開
2. Stripe MCP書き込みツールを使い、WebhookエンドポイントのURLを新しいトンネルに更新
3. StripeダッシュボードやCLIからテストイベントをトリガー
4. ローカルサーバーが受信・解析

Stripeの公式ドキュメントは、書き込みツールに人間の確認を有効にし、Stripe MCPサーバーと他のサーバーの併用に注意を促しています。PinggyもStripe Webhookのテストガイドを公開しています。

2026年中頃のエージェントIDEの現状

このワークフローに関わる主要エディタは以下の通り:

• Cursor（Anysphere製）は、SpaceXの買収により2026年第3四半期に完了予定の約60億ドルの取引に向けて動いています。現在は未完了。
• Windsurfは、2025年7月にCognition AIに買収され、2026年6月にDevin Desktopにリブランドされました。元のエージェントや拡張機能はそのまま継続。
• Claude Codeは、端末CLI、VS Code拡張、JetBrainsプラグイン、デスクトップアプリ、Web（claude.ai/code）、Slackといった6つのインターフェースを持ち、設定やMCPサーバーも共有しています。

これらはすべてMCPクライアントであり、どのエディタからもトンネルを操作可能です。PinggyやCloudflareのサーバーも同じ仕組みで動作します。

セキュリティの考慮点

上記の仕組みは、判断力を持つ必要があります。VS CodeのMCPドキュメントは、「ローカルのMCPサーバーは任意のコードを実行できる」と明記しています。信頼できるソースからのみ追加し、レビューを行うことが基本です。特に、エージェントがMCPツールの出力を信頼しすぎると、攻撃の対象になり得ます。例えば、偽のエラーイベントを注入し、バグを修正させるといった攻撃例もあります。したがって、IP制限やツールの選別、書き込み時の人間確認などの最小権限の原則を守る必要があります。

まとめ

トンネル管理をMCPツールコールにすることは、今日でも実現可能なパターンです。Pinggyのサーバーとスキル、CloudflareのAPI MCPサーバーとポータル、StripeのMCPサーバーはすべて稼働中で、ドキュメント化されています。ただし、「早期かつ実験的」との記述や、プロトコルの大きな変更、エディタの買収・リブランド途中である点には注意が必要です。これらをワークフローに組み込む場合は、まずサーバーの動作を理解し、アクセス範囲や安全性を確認した上で導入してください。

---

変更履歴

この文章は以前の草稿から書き直したものです。主な修正点:

1. 「旧式」や「革命」の表現を削除。最初の草稿は、AI管理のトンネルがすでに完了した変化として描いていましたが、実際は進行中の新しいパターンであり、多くの開発者はまだ日常的に使っていません（PinggyのMCPサーバーも「早期・実験的」と記載）。
2. Pinggyのスキルインストールコマンドを修正。npx skills add pinggy/skillsではなく、npx skills add https://pinggy.ioとし、pinggy.io/.well-known/skills/から取得します。
3. PinggyのMCPサーバー詳細を追加。GitHubソース、Python 3.10+とuvの必要性、登録コマンド、serversとmcpServersの違い、例プロンプトを実例に修正。
4. Cloudflareの仕組みを具体的に修正。APIの規模、エンドポイント数、仕様変更、ドメイン固有のサーバー例を追加。トンネル管理は一般APIサーバーを使うことを明示。
5. ポータルの詳細を正確に記述。認証、ツールの選別、Code Mode、ロギング、ルーティングの詳細と制約を明示。
6. MCPのリリースと仕様変更を正確に記述。リリース日、N×M問題、JSON-RPCとLSPのメッセージ、仕様変更の詳細を追加。
7. 採用事例と普及状況を追記。OpenAI、DeepMind、Anthropicの動きと採用状況を具体的に。
8. スキルとサーバーの違いを明確化。具体的なインストール例と運用例を示す。
9. StripeのWebhook例を修正。エージェントはWebhookのURL更新は可能だが、Webhookの受信はできないことを明示。Stripeの公式ガイドも引用。
10. IDEの現状を具体的に修正。Cursorの買収状況、Windsurfの買収とリブランド、Claude Codeのインターフェースを詳細に。
11. セキュリティの具体的な注意点を追加。VS Codeのドキュメントや攻撃例を引用し、信頼性の重要性を強調。
12. 不確かな情報や誤情報を削除。Cloudflareの専用ツールやWAF監査の記述を除外。
13. SEOや「若手DevOps」フレーズを削除。実用的なまとめに置き換え。

これらの修正により、情報の正確性と信頼性を高め、実務に役立つ内容としています。