AIエージェントが操縦：2026年のMCPサーバーとトンネル自動化

開発者と環境のインタラクション方法は根本的に変わっています。2026年、AIは単なるボイラープレートの自動補完や正規表現の生成だけではなく、ターミナルや環境へのアクセスを直接コーディングアシスタントに委ねる時代になっています。Model Context Protocol (MCP) を通じて、CursorやWindsurfのようなIDE内のAI、Claude Codeのようなターミナルネイティブツールは、動的にコマンドを実行し、ファイルシステムを読み取り、ネットワーク設定を行うことが可能です。

この変化の最も明確な例の一つはローカルネットワークの露出です。従来、ローカルサーバーの共有やWebhookのテストは、エディタを離れCLIコマンドと格闘し、ポートを管理し、一時的なURLをサードパーティのダッシュボードにコピーする必要がありました。今日では、Pinggyのようなツールが専用のMCPサーバーとAgent Skillsを提供し、その作業を既にAIアシスタントとやり取りしている会話の中に折り込んでいます。例えば、「ローカルの決済サービスを公開してStripeのWebhookをテストして」と指示すれば、エージェントが配線を処理します。

このガイドでは、AIエージェントがMCPを通じてネットワークトンネルを提供する仕組み、Claude CodeやCursorがlocalhostを公開する際に実際に何をしているのか、そしてそのようなアクセスをエージェントに信頼させる前に確認すべきポイントについて解説します。特に、以前の草稿で誤って記載された詳細についても触れます。

1. Model Context Protocol：AIのユニバーサルUSB-C

Anthropicは2024年11月25日にMCPをオープンソース化し、「N×M統合問題」と呼ばれる課題を解決しようとしました。標準が共有されていないため、各AIエージェントは個別にツールと連携する必要がありましたが、MCPはクライアント–サーバーアーキテクチャに置き換え、MCPクライアント（例：Claude Code、Cursor、Windsurf）がMCPサーバー（特定のツールやリソース、プロンプトを公開する軽量なローカルまたはリモートプロセス）と通信します。

この「2026年までに業界全体に採用される」という表現は、その速さを正確に伝えきれていません。OpenAIは2025年3月にMCPを採用し、最初にAgents SDKにサポートを追加、MCPの運営委員会に参加しました。Responses APIやChatGPTデスクトップのサポートも続きました。Google DeepMindは翌月のGeminiでサポートを確認。MicrosoftとGitHubはBuild 2025で委員会に参加し、AWSも2025年11月に加わりました。2025年9月にはChatGPT Developer Modeが完全なread/write MCPサポートを追加し、2025年12月にはAnthropicがLinux Foundationの新設されたAgentic AI FoundationにMCPのガバナンスを移譲。創設メンバーにはAnthropic、Block、OpenAI、そしてGoogle、Microsoft、AWS、Cloudflareがプラチナメンバーとして参加しています。これらの動きは、単一ベンダーのプロジェクトからの脱却を示す重要なシグナルです。

成長の数字もそれを裏付けます。2026年3月時点で、PythonとTypeScript SDKの月間ダウンロード数は約200万から97百万に増加し、2026年7月の次期仕様リリースでは、月間ダウンロード数は約5億に迫ると報告されました。SDK単体での累計ダウンロード数も10億を超えています。

2026年7月28日付の仕様リリースは、MCPの最大の改訂であり、従来の状態維持型・接続志向のプロトコルからステートレスに移行しました。initialize/initializedハンドシェイクやMcp-Session-Idヘッダーは廃止され、自己完結型のリクエストがプロトコルバージョンと機能を持ちます。これにより、負荷分散の背後にあるサーバーでもリクエストに応答できるようになり、MCPサーバーの設計や監査が容易になりました。同時に、MCP Apps（インタラクティブなサーバーサイドUIを提供）やTasks extension（長時間動作するタスクのサポート）も正式にサポートされ、OAuth 2.1やOpenID Connectの認証モデルも強化されました。これらの変更は日常的なトンネルサーバーの利用感には影響しませんが、仕様変更に伴うガイダンスの見直しは重要です。特に、2026年7月以前の仕様に基づく情報は古くなっている可能性があります。

2. PinggyのAIエージェントツール：実際の内容

Pinggyは、SSHリバーストンネルを利用してローカルサーバーをインターネットに公開するシンプルな方法を提供します。ポートフォワーディングやルーター設定不要で、一時的なHTTPS URLを発行可能です。手動のトンネル例は次の通りです：

ssh -p 443 -R0:localhost:3000 free.pinggy.io

-p 443はHTTPSポート経由でSSH接続を行い、ファイアウォールのブロックを回避します。-R0:localhost:3000はPinggyサーバーにランダムな公開ポートを割り当て、そのポートをローカルの3000番にフォワードします。

Pinggyはこの仕組みの上に、2つの独立したAIエージェントツールを提供しています。これらは以前の草稿で誤った詳細を記載していた部分です。

Agent Skillは、SSHコマンドやCLIフラグ、SDKの使い方などの指示とリファレンスをまとめたもので、エージェントがこれを読み取り、通常のターミナルアクセスを使って自動的に実行します。インストールは次のコマンドで行います：

npx skills add https://pinggy.io

これにより、~/.claude/skills/pinggy/にスキルが保存され、Node.jsがあれば動作します。

MCPサーバーは、トンネル操作を呼び出し可能なツールとして公開するプロセスです。これにより、エージェントはドキュメントからコマンドを再構築する必要がなくなります。実際のサーバーはpinggy_mcpというPythonパッケージで、github.com/Pinggy-io/pinggy_mcpに公開されています。Python 3.10+とuvが必要で、uvxを通じて起動します。Pinggyのドキュメントでは、これは早期ソフトウェアとして位置付けられ、「フィードバック用に共有、粗さもある」と記載されています。接続後、サーバーは以下のツールを登録しています：

• 認証 — authenticate（OAuth 2.0デバイストークンフローの開始とURL返却）、check_authentication、get_profile、logout
• トンネル — start_tunnel（HTTP/TCP/TLS/UDP、IP許可リストやヘッダー書き換え、Webデバッガ付き）、stop_tunnel、list_tunnels、get_tunnel_info
• ファイル共有 — share_directory、stop_file_share、list_file_shares（Pinggyの--serveフラグを利用、WebDAVではありません）
• トークン管理 — トークンの発行と取り消し

Pinggyのドキュメント例には、「ポート3000の開発サーバーを公開」「localhost:22へのTCPトンネル」「~/Downloadsフォルダの公開」「特定IPからのアクセス制限」などがあります。すべてのページはMarkdown形式でも公開されており、pinggy.io/llms.txtで概要を確認できます。

3. Claude Codeのlocalhost公開：ターミナルネイティブの自動化

Claude Codeはシェル上でネイティブに動作し、MCPに対応しているため、この種の環境タスクに適しています。例としては次のようなコマンドです：

claude "このアプリをQAチームと共有 — 公開してエンドポイントを要約して" 

Pinggy MCPサーバーが登録済みの場合、Claude Codeはpackage.jsonからポートを読み取り、開発サーバーを起動し、start_tunnelツールを呼び出し、結果のURLとルートの概要を報告します。これにより、複数のターミナルをまたぐ作業が一つのやり取りに短縮されます。

この操作の権限管理については、2026年初頭から変化しています。デフォルトでは、Claude Codeはファイル書き込みやシェルコマンドごとに承認を求めます。これをスキップするには--dangerously-skip-permissionsフラグ（通称「YOLOモード」）を使いますが、これはすべての許可・拒否ルールを無効化し、プロンプトインジェクションのリスクも伴います。rootやsudo権限での実行時はこのフラグは無効です。Anthropicは、コンテナやサンドボックス内での実行を推奨しています。

2026年3月以降は、中間的な選択肢としてauto modeが導入されました。これは、ツール呼び出しごとに危険な操作をブロックする背景分類器を用いるもので、約93%の許可プロンプトに承認されている現状を改善します。例えば、「開発サーバーを起動しトンネルを開く」作業には、auto modeがより安全なデフォルトです。

4. CursorのWebhookテスト：エージェントモードとMCPチェーン

2026年、Cursorの自律機能の主役は「Agent Mode」です。従来のComposerは引き続き存在しますが、Agent Modeはコードベースの読み込み、ファイル編集、ターミナルコマンド実行、出力監視、反復を行います。Webhookテストのような複合タスクもこのモードで実行されます。

例として、「Stripeのpayment_intent.succeededイベント用のWebhookハンドラーを書き、公開し、エンドポイントを設定し、テスト支払いをトリガーする」という指示があります。PinggyのMCPサーバーとStripeの公式MCPサーバーが接続されている場合、エージェントはルートハンドラーを書き、ローカルサーバーを起動し、start_tunnelを呼び出して公開URLを取得し、Stripeのツールを使ってWebhookエンドポイントを作成または更新します。ただし、StripeのMCPサーバー（mcp.stripe.com）はWebhookエンドポイントの作成と管理は可能ですが、ライブのイベントストリームの取得はMCP自体ではできません。テストイベントのトリガーと確認はStripe CLIのtriggerコマンドを使う必要があり、これをエージェントが直接シェルコマンドとして実行します。

5. セットアップ方法

Claude Code — CLIから直接登録（設定ファイル不要）：

claude mcp add pinggy-mcp -- uvx --from git+https://github.com/Pinggy-io/pinggy_mcp.git pinggy-mcp
claude mcp list   # 登録確認

Cursor — ~/.cursor/mcp.json（グローバル）またはプロジェクトルートの.cursor/mcp.jsonに以下を追加：

{
  "mcpServers": {
    "pinggy-mcp": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/Pinggy-io/pinggy_mcp.git", "pinggy-mcp"]
    }
  }
}

Claude DesktopとWindsurfはCursorと同じJSON構造を使いますが、パスが異なります。Claude Desktopは~/Library/Application Support/Claude/claude_desktop_config.json（macOS）、%APPDATA%\Claude\claude_desktop_config.json（Windows）、~/.config/Claude/claude_desktop_config.json（Linux）。Windsurfは~/.codeium/windsurf/mcp_config.jsonです。

VS Codeは少し異なり、トップレベルのキーはserversで、各エントリーには"type": "stdio"を明示します：

{
  "servers": {
    "pinggy-mcp": {
      "type": "stdio",
      "command": "uvx",
      "args": ["--from", "git+https://github.com/Pinggy-io/pinggy_mcp.git", "pinggy-mcp"]
    }
  }
}

これらを混同すると、クライアントが正しく読めなくなります。

実用的なガードレール

• ポートの範囲を限定：エージェントに許可されたポート範囲（例：3000–8000）を設定し、ローカルデータベースなどの露出を防ぐ。
• Webデバッガを監視：Pinggyのローカルインスペクター（通常ポート4300）を開き、トンネルを通るリクエストとレスポンスを常に確認できる状態にしておく。
• トンネルは一時的に：タスク完了後はエージェントにトンネルを閉じさせる。Pinggyの「早期実験段階」ラベルも考慮し、慎重に運用する。
• 自動モードやコンテナを推奨：ネットワーク境界を開く作業には、--dangerously-skip-permissionsの乱用を避け、代わりに自動モードやサンドボックス内での実行を選択してください。

6. 今後の展望

MCPの成長、ステートレス化、Pinggyのようなベンダーによるエージェントツールの標準化は、AIがコード生成からインフラ運用へと進化していることを示しています。この動きは今後も続きますが、まだ初期段階です。プロトコル自体は約1年半前に登場し、トンネル用のMCPサーバーは実験的な位置付けです。エンタープライズのセキュリティ実践（OAuth 2.1の採用など）も遅れ気味です。

しかし、これらのツールを使う価値は十分にあります。重要なのは、エージェントの実行内容を事前に検証し、無監督運用を避けることです。この記事では、そのためのポイントを解説しています。

---

改訂履歴

元の草稿に対して、一次資料（MCPの公式仕様・ブログ、Pinggyのドキュメント・GitHub、AnthropicのClaude Codeドキュメント・エンジニアブログ、StripeのMCPドキュメント）をもとに修正・追記を行いました：

• MCPのリリースと採用のタイムライン — 2024年11月25日にMCPが公開されたことは正しいですが、「2026年までに業界全体に採用された」という記述には具体性がありませんでした。正確な流れを追加：OpenAI（2025年3月）、Google DeepMind（2025年4月）、Microsoft/GitHub（Build 2025）、AWS（2025年11月）、Linux FoundationのAgentic AI Foundationへのガバナンス移譲（2025年12月）など。
• 成長と仕様更新 — 2026年7月28日の仕様リリースを追記。ステートレス化、initialize/Mcp-Session-Idの廃止、MCP AppsとTasksの正式サポート、OAuth 2.1の強化など。ダウンロード数も97M/月（2026年3月）、約5億/月（2026年7月）と具体的な数字を掲載。
• Pinggyのインストールコマンドは実在しないため修正。実際のpinggy_mcpパッケージはPythonで、uvxを使って起動します。公式ドキュメントから正しいコマンド例に置き換え。
• ツールの数と内容も正確に。認証、トンネル、ファイル共有、トークン管理の13ツールを記載。OAuth 2.0デバイストークンフローも追加。
• パーミッションバイパスの説明を具体化。--dangerously-skip-permissionsの詳細と、2026年導入のauto modeを紹介。
• Cursorの主要機能名を修正。2026年の現状では、「Agent Mode」が自律的なマルチツールワークフローの主役です。
• StripeのWebhook例を修正。mcp.stripe.comはWebhookエンドポイントの作成・管理は可能だが、ライブイベントの取得はStripe CLIのtriggerを使う必要があることを明記。
• メタデータの除去：著者・日付・トラッキング情報は削除し、クリーンな形にしています。