AIエージェントとトンネル自動化：Pinggy MCPサーバーの内部

開発者がClaude Code、Cursor、Claude Desktop、または Windsurf を主要インターフェースとして使用している場合、これらのエージェントにコード生成以上のことをさせたいと考えることが増えています。例えば、ローカル開発サーバーの公開URLを立ち上げるなどです。Pinggyは、専用のエージェントツールを備えた最初期のトンネリングベンダーの一つです： Agent Skill とスタンドアロンの MCPサーバーの両方を、アーリーアクセスの実験的ラベルで公開しています。本記事では、それぞれの機能、正しいインストール方法（クライアント間で設定パスが予想以上に異なる点も含む）、そしてエージェントが自らトンネルを開くことができるようになったときのセキュリティの現状について解説します。

手動トンネリングとその課題

基本的なワークフローは長年変わっていません：ssh -p 443 -R0:localhost:8000 free.pinggy.io（または ngrok、Cloudflare Tunnel などの同等コマンド）を実行し、結果のURLをコピーして必要な場所に貼り付ける — webhookダッシュボード、Slackメッセージ、.envファイルなどです。AIコーディングエージェントが既にターミナルを操作している場合、これはエージェントのコンテキストとあなたの間のもう一つの手動の引き継ぎとなります。

Anthropicが2024年末にリリースしたModel Context Protocol（MCP）は、エージェントがCLIに出力をパースさせる代わりに外部ツールを呼び出す標準化された方法を提供します。MCPの設定は3つの部分から成ります：hosts（エージェントアプリケーション — Claude Code、Cursor、Claude Desktop、Windsurf）、clients（各ホストが維持するプロトコル接続）、servers（特定のツールやリソース、プロンプトを公開するプロセス）。トンネルクライアントを MCPサーバーにラップすることで、エージェントは start_tunnel のようなツールを直接呼び出し、構造化されたデータ（公開URL、トンネルID、状態）を受け取り、シェルコマンドの構築やパースを行う必要がなくなります。

SkillとMCPサーバーの違い

Pinggyは二つの別個のエージェントツールを提供しています。これらの違いを正確に理解することが重要です。なぜなら、ベンダーのドキュメントは次のようになっているからです：

	Skill	MCPサーバー
何か	パッケージ化されたリファレンスドキュメント（SSH、CLI、SDK、すべてのフラグとトンネルタイプ）	トンネル操作を呼び出し可能なツールとして公開する実行中のプロセス
エージェントの役割	ドキュメントを読み、通常のターミナルアクセスでコマンドを実行	直接ツールを呼び出し、コマンド構築不要
インストール方法	npx skills add https://pinggy.io	uvxを用いたクライアントごとの設定

Pinggyの公式ガイドでは、エージェントにツール理解させたい場合はSkillから始め、トンネルを自律的に操作させたい場合はMCPサーバーを追加することを推奨しています。両者は独立してインストール可能で、Skillのインストールはエージェント間で共通です — CLIはクライアントを検知し、~/.claude/skills/pinggy/（Claude Codeの場合）にスキルファイルを書き込みます。

この後半部分は、エージェントが”チャットを離れずにトンネルを作る”動作を可能にするMCPサーバーに焦点を当てています。

Pinggy MCPサーバーが公開する内容

このサーバーはPythonパッケージ（Python 3.10+とuvが必要）で、github.com/Pinggy-io/pinggy_mcpに公開されています。READMEには明示的に実験的と記載されており、「早期フィードバック用、粗い部分もある」とのことです。導入前に念頭に置くべきポイントです。

インストール後、以下の13のツールを4つのグループに分けて登録します：

認証 - authenticate — OAuth2デバイスフローを開始し、ログインURLを返す - check_authentication — ログイン状態、アカウントメール、トークン有効期限 - get_profile — Pinggyアカウントプロフィール取得 - logout — セッションをクリア

トンネル - start_tunnel — HTTP、TCP、TLS、UDP（IP許可リスト、ヘッダー書き換え、Webデバッガ付き） - stop_tunnel、list_tunnels、get_tunnel_info

ファイル共有 - share_directory — WebDAV経由でローカルフォルダを公開URLで共有 - stop_file_share、list_file_shares

トークン管理 - add_token、remove_token、list_tokens、update_token — 特定のPinggyトークンをポートに紐付け

これらは直接呼び出すのではなく、「ポート3000を公開」「アクティブなトンネル一覧」「特定IPからのみ許可」などの自然言語でリクエストし、エージェントが適切なツールを選びます。最初の説明と一致しており、HTTP/TCP/TLS/UDPトンネルやWebDAVによるディレクトリ共有をサポートしています。

認証：この部分は正しい

PinggyがOAuth 2.0デバイス認証（RFC 8628）を使用しているのは正しいです。「Pinggyにログイン」コマンドはauthenticateを呼び出し、Pinggyのバックエンドに接続してURLを返します。ブラウザで承認し、MCPサーバーがバックグラウンドでポーリングし、セッションを保存・自動更新します。セッション情報は~/.config/pinggy-mcp/config.json（Linux/macOS）または%LOCALAPPDATA%\pinggy-mcp\config.json（Windows）に保存され、Unix系ではchmod 600を推奨します。保存されたトークンは任意で、OAuthがカバーしない特定のサブドメインやカスタムドメインのバインドに必要です。

インストール方法 — クライアントごとに修正

元の説明には誤りがありました。設定パスの間違いは、「動作する」か「ツールリストに表示されない」かの差です。CursorとVS Codeは異なる設定場所とJSONスキーマ（mcpServers vs. servers）を使用しており、これらを混同すると、意図したクライアントが設定を読み取れません。

Claude Code — 最も簡単な方法。1行のCLIコマンドです：

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

claude mcp listで確認できます。

Claude Desktop — 設定ファイルを直接編集： - macOS: ~/Library/Application Support/Claude/claude_desktop_config.json - Windows: %APPDATA%\Claude\claude_desktop_config.json - Linux: ~/.config/Claude/claude_desktop_config.json

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

アプリを再起動し、pinggyがMCPインジケーターに表示されるはずです。

Cursor — VS Codeとは異なるパスです： - グローバル: ~/.cursor/mcp.json - プロジェクトごと: .cursor/mcp.json（プロジェクトルートに配置）

JSONの形状は上記のClaude Desktopと同じです。

VS Code — パスとスキーマが異なります（serversと`