Funnels vs. Tunnels: ngrok、Tailscale、Cloudflareを見直すゼロトラストインフラ

長年、ngrokのようなツールは「このローカルサーバーをインターネットに公開するにはどうすればいいか」の標準解答でした。1コマンド実行で公開HTTPS URLを取得し、完了です。その便利さは確かですが、プラットフォームやセキュリティチームが次第に抵抗感を持つようになったトレードオフもあります。クラシックなトンネルは、ライブになった瞬間に公開・未認証のエンドポイントを作成します。

代替案として注目されているのは、アイデンティティベースのメッシュネットワーキングです。Tailscaleのようなプライベートオーバーレイネットワークと、公開アクセスが本当に必要な場合に限定した狭い監査済みの”funnel”メカニズムです。これは、1つのツールがもう一つを置き換える物語ではなく、異なる2つの質問に対する2つの答えです。ngrokは「このサービスをインターネットの誰にでも公開するにはどうすればいいか」に答え、Tailscaleは「チームのデバイスを何も公開せずにどう接続するか」に答えます。実際のチームは、時には同じ日のうちに両方の答えを必要とするため、Funnelの機能は存在します。

---

1. 従来のトンネルの仕組み

ngrokのようなツールは、軽量なエージェントをマシン上で動かし、ngrokのクラウドエッジへのアウトバウンド接続を開きます。そのクラウドエッジは公開URLを返し、そのURLへのリクエストはトンネルを通じてローカルのポートにルーティングされます。ngrok http 8080を実行すれば、数秒で公開状態になり、その使いやすさは変わりません。

アーキテクチャはサービス中心です：URLへのアクセスがアクセス制御の役割を果たします。トンネル自体にはアイデンティティチェックは組み込まれていません（追加すれば別ですが）。これにはいくつかの実務的な影響があります：

1. 設計上ファイアウォールをバイパスします。 これがトンネルの目的ですが、未承認のトンネルはネットワークへの監視されていない入り口となります。
2. ランダムに見えるURLはセキュリティ境界ではありません。 スキャナーによる推測は時間とともに可能になり、サービス側に認証がなければURLを見つけた人はアクセスできます。
3. シャドウITになり得ます。 セキュリティチームが知らないトンネルを通じたデータ流は、SOC 2、HIPAA、GDPRのコンプライアンスに複雑さをもたらします。

これらはngrokの安全性を損なうものではなく、むしろ公開デモや顧客Webhookなど外向きの用途に最適化されたツールです。内部のステージング環境やチーム間共有には向きません。

---

2. ゼロトラストへのシフト：アイデンティティベースのメッシュネットワーキング

Tailscaleのようなメッシュネットワーキングツールは、逆のデフォルトを採用しています。公開URLではなく、各デバイスが認証（通常はSSO経由）され、プライベートオーバーレイネットワーク（”tailnet”）に参加します。デバイスはWireGuardを使って通信し、認証されていないデバイスは何も解決・到達できませんし、サービスの存在さえ見えません。

一つの微妙な点は、TailscaleのトラフィックはNATトラバーサルが成功した場合にピアツーピアですが、常に直接のホップではありません。2つのデバイスが直接経路を確立できない場合（制限されたNATや企業のファイアウォールの背後など）、Tailscaleは独自のリレーインフラ（DERPサーバー）を使って暗号化されたトラフィックを運びます。ペイロードはエンドツーエンドで暗号化されたままですが、「決して中央サーバーに触れない」という表現はやや誇張です。

コアの価値提案は変わりません：アクセスはtailnetのメンバーシップに基づき、URL推測ではなく、認証されたアイデンティティに紐づきます。

---

3. Tailscale Funnel vs. ngrok：2つのアーキテクチャと2つの哲学

ngrokは、サービスに対して*公開*を望むケース向けに設計されています。Webhookのテスト、VPNクライアントなしでのデモ、顧客環境からのインバウンド接続の受け入れなどです。トラフィックインスペクター、リクエストのリプレイ、Traffic Policyエンジン（認証や書き換え、レート制限のルール層）は、ライブAPIトラフィックのデバッグにおいて非常に強力です。

Tailscaleは逆の前提から始まります：デフォルトでプライベート、基本的にはデバイス間のメッシュです。公開の入り口ツールではありません。

Funnelは、Tailscaleの回答です。時折その境界を越える必要がある場合に、特定のノードに対して公開インターネットトラフィックをルーティングする機能です。実運用で使う場合に知っておくべきポイントは以下の通りです：

• まだベータ機能です。 2026年初頭のTailscaleのドキュメントによると、Funnelは引き続きベータラベルであり、使えますが正式なサポートSLAはありません。セキュリティチームに事前に伝えるべきです。
• ポートは厳格に制限されています。 Funnelは443、8443、または10000番ポートのみTLS上でリッスンします。これはデフォルトではなく、強制です。*.ts.netのTLS証明書は自動的に発行されます。
• 帯域幅は制限されており、その上限は公開されていません。 Funnelのトラフィックは非設定可能な帯域制限の対象です。
• ServeとFunnelは同じポートを同時に使えません。 最後に設定したコマンドが優先されます。serveならtailnet内のみ、funnelなら公開です。中間状態はありません。
• ngrokには同等のポート制限はありません。 任意のTCP/UDPトラフィックをほぼすべてのポートでサポートし、ゲームやVoIPのUDPトラフィックにはngrok（またはUDPトンネルの専門ツール）が適しています。

---

4. ゼロトラストローカルホスト共有：実践的なワークフロー

フロントエンド開発者がlocalhost:3000をQAやPMと共有するケースを想定します。

従来のやり方： ngrok http 3000を実行し、URLをSlackに貼る。誰かがターミナルを閉じ忘れると、そのURLは誰でもアクセス可能なまま週末まで放置されることも。実はngrokの*無料プラン*は、セッションを一定時間後に自動的に閉じる仕組みではなく、長時間持続します（後述の誤解についても触れます）。最大のリスクはタイムアウトではなく、何も閉じる仕組みがないことです。

ゼロトラストのやり方（現行CLI構文）： Tailscaleはクライアントバージョン1.52でServe/Funnelコマンドの構文を変更しました。古いチュートリアルのtailscale serve --port 3000は非推奨となり、エラーまたは自動変換されます。現在の構文は以下の通りです：

tailscale serve https / http://localhost:3000

これにより、ローカルアプリは開発者のtailnetアドレス（例：https://dev-laptop.tailnet-name.ts.net）にバインドされ、認証されたデバイスだけがアクセスできます。トラフィックはWireGuardでエンドツーエンド暗号化され、アイデンティティヘッダーも渡せるため、内部共有用の認証レイヤーを構築せずに誰が接続しているかを知ることが可能です。

外部クライアントがTailscale未インストールで必要な場合は、同じポートを公開に昇格させます：

tailscale funnel 443 on

これにより、公開インターネットからTailscale管理のHTTPSエンドポイントにアクセス可能になります。意図的に固定ポートで、誰かがオンにした記録も残ります。

---

5. Cloudflare Tunnel：もう一つのFunnel代替案

Cloudflare Tunnel（Cloudflare One / Zero Trustプラットフォームの一部）は、異なるアプローチを取ります。Peer Meshの代わりに、Cloudflareのグローバルエッジを経由します。cloudflaredデーモンはマシンやサーバー上で動作し、Cloudflareの最寄りのデータセンターへアウトバウンド接続を確立します。インバウンドポートは不要です。Cloudflare Accessを前面に配置すれば、訪問者はSSO認証を経てからオリジンに到達します。

最近の変更点として、2026年2月にproxy-dnsコマンドが削除され、2026年10月にTunnel/Mesh APIのルート識別子やconnectionsフィールドがroute_idに置き換えられる予定です。これらはTerraformやAPI経由で管理する場合に重要です。

実務上の大きな分かれ目は、Cloudflare Tunnelは既存の内部アプリを分散したチームに公開するのに適しており、Tailscaleはピアツーピアの低遅延WireGuardを重視する開発者間やホームラボの接続に適しています。

---

6. セキュアなチームインフラ構築：2026年の変化

この移行を計画する場合、今年の変化を踏まえたポイントを押さえておきましょう：

SCIMはもはやエンタープライズ専用ではありません。 2026年4月のTailscaleの価格改定（”pricing v4”）により、自動ユーザープロビジョニング、デバイスポスチャポリシー、Webhookはすべての有料セルフサービスプランに含まれました。以前はEnterprise契約が必要でした。現在のプランは、Personal（無料、6ユーザまで）、Standard（$8/ユーザ/月）、Premium（$18/ユーザ/月、SSO/SAML、ネットワークフローログ、Funnelを含む）、カスタムのEnterpriseプランです。SCIMを使った移行を想定していた場合は見直しが必要です。

設定監査ログもすべての有料プランに含まれます。 これにより、「誰がいつFunnelを有効にしたか」の監査証跡が得られます。

これを踏まえた展開計画はほぼ変わりません：

• メッシュクライアントを各ワークステーションやCI/CDランナー、ステージングサーバに展開し、SSOとSCIMで自動プロビジョニング/デプロビジョニングを設定
• MagicDNSを有効化し、名前でアクセスできるようにし、ACLでチームごとにアクセス範囲を設定
• トンネリングトラフィックをデフォルトでServeに設定し、FunnelはACLポリシーの明示的なノード属性の背後に配置
• フローログと監査ログをSIEMに送信し、ngrokのような監視されていない状態を避ける

---

7. ngrokが今も適しているケース

これはゼロサムの比較ではなく、ngrokが依然として優れる場面もあります：

1. 組織間の接続。 SaaSが顧客のネットワークにアクセスする必要がある場合、顧客にtailnetへの参加を求めることはできません。サービス中心のトンネルが適しています。
2. 詳細なトラフィック検査。 ngrokのリクエストリプレイやインスペクターは、WebhookやAPIトラフィックのライブデバッグにおいて優れています。
3. HTTPS以外のプロトコル。 FunnelはHTTPS専用で、固定ポートのみです。UDPやVoIP、IoTプロトコルなどの公開が必要な場合は、ngrokやUDP専用のツールが適しています。

また、広く流布している「ngrok無料プランは2時間でタイムアウト」という情報は、2026年現在のngrokのドキュメントと一致しません。無料プランはセッションタイムアウトなしで、プロセスが動作している限りエンドポイントは維持されます。制限は1GB/月のデータ容量、3つのオンラインエンドポイント、ブラウザ経由の警告ページ（APIやプログラム用のngrok-skip-browser-warningヘッダーでバイパス可能）、カスタムドメイン非対応です。これらは制限であり、2時間のタイムアウトは含まれません。

---

8. 現実的な視点：ゼロトラストも完璧ではない

「公開トンネルは悪、プライベートメッシュは良い」と単純化したくなるところですが、そこには抵抗も必要です。2026年5月、TailscaleはServeとFunnelのDoS脆弱性（TS-2026-008）を公開しました。これは、パスが/で始まらないHTTPリクエストが無限ループに入り、CPUを100%に固定してしまうものでした。修正はパスマッチングの正しい終了です。

これにより、アイデンティティベースのアクセスのアーキテクチャ的意義は揺るぎません。DoSの脆弱性は、「誰でもこのURLにアクセスできる」問題とは異なる失敗モードです。Tailscaleの公開プロセスは、信頼できるインフラの透明性の証です。ただし、「ゼロトラスト」がアクセスモデルであり、バグからの完全な免疫ではありません。選択した入口層は、パッチや監視、障害時の対応計画も必要です。

---

結論

トンネルからFunnelへの移行は、チームにとっての”便利さ”の意味の変化です。最速で公開する方法から、最適な人に素早く届け、記録を残す方法へ。ngrokは公開向き（顧客接続、Webhook、デモ）には最適です。一方、TailscaleやCloudflare Tunnelは、内部用途に最適な選択肢です。

実際の運用は、一方のツールを排除することではなく、プライベートをデフォルトにし、公開は意図的かつ記録された例外とすることです。

---

変更履歴

構造的変更: - SEOメタデータ、繰り返しの強調フレーズ、擬似引用リストを除去し、平易な文章に書き換え - 2026年のTailscaleのServe/FunnelのDoS脆弱性に関する新セクション追加（バランスのため）

一次資料に基づく修正: - ngrokの無料プランのタイムアウト誤情報の訂正 — 現在のngrokドキュメントによると、無料プランはセッションタイムアウトなし。制限は1GB/月のデータ、3エンドポイント、ブラウザ警告ページのみ。 - ngrokのプラン構成の更新 — 現在のセルフサービスプランはFree / Hobbyist（$8–10/月）/ Pay-as-you-go（$20/月+使用量）/ Enterpriseに変更。 - Tailscale CLI構文の修正 — 旧コマンドtailscale serve --port 3000やtailscale funnel 3000は非推奨。新構文はtailscale serve https / http://localhost:3000とtailscale funnel 443 on。 - SCIMや監査ログの制限の修正 — 2026年4月の価格改定により、これらはすべての有料プランに移行。プラン名と価格も更新（Personal無料/6人、Standard$8、Premium$18、Enterpriseカスタム）。 - Funnelは依然ベータ機能（2026年初頭のドキュメント）と明記。 - DERPリレーの補足 — Tailscaleは常にピアツーピアではなく、NAT Traversal失敗時はリレーサーバーを使用しつつ、エンドツーエンド暗号化は維持。 - Cloudflare Tunnelの2026年の変更点 — proxy-dnsコマンドの削除（2026年2月）、APIのルート識別子とconnectionsのroute_idへの置換（2026年10月予定）を追加。 - ポート制限や帯域制限の正確性 — Funnelは443/8443/10000のみTLS、帯域制限は非公開、ServeとFunnelの同一ポート動作の挙動も確認済み。

情報源確認: ngrokドキュメント（料金・制限）、Tailscale（Funnel、Serve、CLIリファレンス、セキュリティ情報、価格v4）、Cloudflare One / Tunnelのドキュメントと変更履歴。