パブリックリレーの終焉：ゼロトラストローカルホストトンネルへの移行

認証されていないローカルAPIをパブリックインターネットに配信するのはやめましょう。ゼロトラストトンネリングの仕組みは、パケットがマシンに触れる前に暗号認証による身元確認を必要とします。

---

10年以上にわたり、開発者やネットワークエンジニアは、厳格なファイアウォールやCarrier-Grade NAT（CGNAT）、ローカルネットワーク制限を回避するためにパブリックリレーツールに依存してきました。クライアントにローカルWebアプリを見せたり、サードパーティの決済プロバイダーのWebhookをテストしたり、ローカルデータベースで共同作業を行ったりする場合、ワークフローはシンプルでした：ngrokのようなツールを起動し、ランダムなパブリックURLを取得して共有するだけです。

しかし、2026年に向けて、クライアントやテストスイートにランダムなパブリックURLを送る時代は急速に終わりを迎えつつあります。デジタル環境はあまりにも敵対的になり、自動攻撃の表面も高度化しているため、セキュリティを隠すだけのセキュリティは通用しなくなっています。従来のパブリックインターネットから直接ローカルホストに穴を開けるパラダイムは、Identity-Native Zero Trust Networksに置き換えられつつあります。

このガイドでは、なぜパブリックリレーが終わるのか、その仕組みとOpenZiti（例：Zrok）を基盤としたツールがなぜngrokの決定版代替となりつつあるのか、そしてプライベートローカルホスト共有が開発者のワークフローをどう変えているのかを解説します。

---

1. パブリックリレーの構造（そしてなぜ時代遅れなのか）

革命を理解するには、まず従来のシステムを理解する必要があります。従来のトンネリングツールは「Public Relay」アーキテクチャで動作します。

開発者がローカルポート（例：ポート8080）を公開するコマンドを実行すると、マシン上の軽量エージェントがアウトバウンドのTCP接続を中央クラウドサーバーに確立します。トンネル提供者は、その接続にバインドされた公開可能なサブドメイン（例：random-string.tunnel-provider.com）を生成します。そのURLに到達したトラフィックは、確立されたトンネルを通じて直接ローカルマシンに転送されます。

セキュリティ・バイ・オブスキュリティの誤謬

従来、開発者はURLがランダムな文字列であれば推測されにくく安全だと考えていました。しかし、2026年にはこれは危険な誤謬です。

現代のサイバー犯罪者は、Certificate Transparency（CT）ログをリアルタイムで監視する分散スキャンボットネットを展開しています。CTログは公開アクセス可能な追跡帳簿であり、発行されたSSL/TLS証明書を記録しています。これは証明書の責任追跡のために設計されたシステムですが、近年は偵察ツールとしても悪用されています。2025年末にはLet’s Encryptだけで1日あたり1千万の証明書を発行し、5億5千万以上のWebサイトを保護しています。CTログは脅威情報や攻撃表面の発見にとって非常に豊富な情報源となっています。従来のトンネリング提供者が新しいランダムサブドメイン用にSSL/TLS証明書を発行すると、ボットはURLをスクレイピングし、一般的な脆弱性を探るためにプローブを開始します。これらはトンネルがオンラインになった瞬間から始まることもあります。

2026年には、さまざまなCTシステムに記録された証明書が82億を超え、これらのデータベースは従来のサブドメイン列挙を超えた攻撃者の情報源となっています。未認証の開発データベースやリモートコード実行（RCE）を許すデバッグインターフェース、レートリミットのないAPIを公開している場合、脆弱性の窓はトンネルが提供された瞬間に開きます。

信頼性の問題

さらに、従来のトンネルはネットワーク中心の信頼に依存しています。ファイアウォールは完全にバイパスされ、トラフィックを受け入れるか拒否するポイントは提供者のサーバー上のパブリックインターネットにあります。悪意あるペイロードがローカルホストに到達する頃には、すでに境界防御を突破しています。

---

2. ゼロトラストトンネリングの登場

この脆弱性に対するサイバーセキュリティ業界の答えは、Zero Trust Architectureの広範な採用です。ゼロトラストは企業VPNの置き換えとして長らく話題でしたが、2026年には開発者ツールエコシステムに完全に浸透し、日常の開発ワークフローにおけるゼロトラストトンネリングとして実現しています。

境界をアイデンティティにシフト

ゼロトラストネットワークでは、パブリックURLは存在しません。インターネット上に開放されたポートもありません。「ネットワークに接続する」という概念は、「アイデンティティに接続する」に置き換えられます。

公開リレーを生成し、誰もがアクセスできるURLを作る代わりに、ゼロトラストトンネルはプライベートなメッシュオーバーレイを作成します。ローカルサービスを共有したい場合、URLは渡さず、暗号認証トークンを受け取ります。リモートユーザー（またはサービス）は、自身のエージェントを使い、そのトークンを提示して、数学的に身元を証明します。これにより、オーバーレイネットワークを通じてパケットをルーティングする前に、身元確認が完了します。

不正なスキャナーがサービスを探ろうとした場合、403 Forbiddenエラーを返すだけでなく、何も返しません。サービスはインターネットから完全に見えなくなります。これが「Dark Infrastructure」と呼ばれる状態です。リッスンポートがゼロなら攻撃面もゼロです。認証されたクライアントだけがオーバーレイを通じて接続し、それ以外は何も見えません。

---

3. OpenZiti：アイデンティティネイティブネットワークの基盤

この変革の中心にあるのはOpenZitiです。NetFoundryが作成・支援するオープンソースのゼロトラストネットワーキングプラットフォームです。Apache 2.0ライセンスの下で、OpenZitiは単なるトンネリングツールではなく、サービスを認証されていないユーザーから見えなくするプログラム可能なオーバーレイネットワークです。

OpenZitiのすべての接続は、暗号認証アイデンティティによって認証され、中央のポリシーコントローラーによって許可され、最新の標準（例：mTLS）を用いてエンドツーエンドで暗号化されます。

既存アプリケーションと軽量トンネラー（コード変更不要）を使った新規アプリケーションの両方に対応し、最強のゼロトラストモデルを実現します。これにより、既存環境と新規開発の両方で実用的です。2026年には、ゼロトラストが企業のポリシー言語から開発者コントロールのインフラ設計へと移行し、分散チームやハイブリッドインフラ、マシン間通信が増加したことで、その採用が拡大しています。

OpenZitiの三本柱

OpenZitiは、ゼロトラスト導入の3つの段階をサポートします：

ZTNA（Zero Trust Network Access）: 最も従来型のモデル。OpenZitiエッジルーターを信頼されたネットワークゾーンに配置し、ユーザーはゼロトラストオーバーレイを通じてルーターに接続し、内部LANにトラフィックを転送します。VPNよりは安全ですが、信頼はローカルネットワーク内に留まります。

ZTHA（Zero Trust Host Access）: このモデルでは、OpenZitiトンネラーがホストマシン上で直接動作します。ホストのOSファイアウォールはすべてのインバウンドトラフィックをデフォルト拒否に設定し、サービスはlocalhost経由のみアクセス可能です。トンネラーは認証されたオーバーレイトラフィックを直接ルーティングし、ネットワーク内の東西移動を排除します。開発者向けのトンネリングには最適なセキュリティと利便性のバランスです。

ZTAA（Zero Trust Application Access）: 最もセキュアなネットワーキングの理想形。OpenZiti SDK（Go、Python、C、Java、Node.jsなど）をアプリケーションコードに埋め込み、アプリ自体が暗号認証アイデンティティを保持します。ネットワークポートにバインドせず、完全にゼロトラストのメモリ空間内で通信します。

管理層の自己管理

2026年初頭の重要な進展：OpenZiti 1.8以降、コントローラーAPI自体がOpenZitiサービスとしてバインド可能になりました。アプリに埋め込まれたゼロトラストが、管理層も保護します。これは重要なアーキテクチャの節目であり、ネットワーク全体を管理する制御チャネルも、 workloadsと同じ暗号認証アイデンティティ検証を受けることで、以前は別途強化が必要だった攻撃ベクトルを閉じます。

---

4. Zrok：OpenZitiネイティブの開発者向けトンネリングツール

OpenZitiはエンタープライズグレードの基盤を提供しますが、完全なオーバーレイメッシュを構築するにはインフラが必要です。そこでZrokが登場します。NetFoundryが直接開発し、OpenZitiの仕組みをベースにした、開発者向けの決定版トンネリングツールです。

ZrokはOpenZitiの高度な機能をシンプルで使いやすいCLIにパッケージ化し、開発者、テスター、運用チーム向けに最適化しています。

パブリックシェアとプライベートシェア

Zrokは、GitHubやStripe、TwilioなどのサードパーティWebhookプロバイダーが標準のHTTPSエンドポイントを必要とする場合など、パブリックURLが必要なシーンを認識しています。これにはzrok share publicコマンドを提供し、安全な一時的なパブリックURLをプロビジョニングします。ZrokのOpenZitiバックボーンにより、プライベートシェアの場合はパブリックエンドポイントは一切作成されず、認証された参加者間の接続のみが存在します。

しかし、Zrokの最大の特徴はプライベートローカルホスト共有です。

プライベートローカルホスト共有の仕組み

開発者がプライベートシェアを開始するには：

zrok share private localhost:8080

Zrokはサービスをインターネットに公開しません。代わりに、ローカルのZrokエージェントがOpenZitiオーバーレイにアウトバウンド接続を確立し、ユニークな暗号化シェアトークン（例：share_token_xyz123）を生成します。

開発者はこのトークンを安全に受信者に送信し、受信者は次のコマンドを実行します：

zrok access private share_token_xyz123

受信者のローカルエージェントはトークンを使ってオーバーレイネットワークに認証し、自身のマシン上のローカルポート（例：localhost:9191）を動的にバインドし、元の開発者のマシンへのエンドツーエンド暗号化された接続を確立します。受信者がhttp://localhost:9191にアクセスすると、トラフィックはシームレスにゼロトラストメッシュを通じてルーティングされます。

結果として：

• ファイアウォールポートは開放されません
• パブリックDNSレコードは作成されません
• 自動スキャナーは検知できません
• 攻撃面はほぼゼロです

バックエンドモード

Zrokのプライベートシェアは、さまざまなワークフローに対応した複数のバックエンドモードをサポートします：

• tcpTunnel — TCPポートを特定のホスト間でトンネリング。例：zrok share private --backend-mode tcpTunnel localhost:22
• udpTunnel — UDPのフルトンネリング（リアルタイムアプリ向け）
• socks — SOCKS5プロキシを作成し、複数の宛先に動的ポートフォワーディング。複数サービスへのアクセスに便利
• drive — ローカルディレクトリを安全なファイルサーバに変換。ログやバイナリ、アセットをクラウド不要で共有可能

VPNモードについての注意： 以前の--backend-mode vpnはホスト間VPNトンネリング用に導入されましたが、依存関係の問題でv1.1.11以降は削除されました。ZrokチームはVPN機能をzrok-vpnという別ツールとして再導入を検討中です。現状、tcpTunnelとsocksモードがVPNの主要用途をカバーしています。

カスタムドメイン

Zrokはカスタムドメインもサポートします。これにより、組織は自社ドメイン（例：<token>.your.domain.co）でシェアを提供でき、ブランド化されたエンドポイントを維持しつつ、ゼロトラストセキュリティモデルを適用できます。

---

5. HTTP以外のエフェメラルトンネルと高度なプロトコル

従来のトンネルはHTTP/HTTPSトラフィックに最適化されていましたが、2026年の現代開発ではより柔軟性が求められます。

生のTCPとUDPのサポート

ZrokのネイティブTCP・UDPトンネリングは、さまざまな分野で実用的です：

ゲームやリアルタイムメディア： UDPサポートにより、ゲームサーバやVoIP、WebRTCストリーミングを超低遅延でプライベートに共有可能です。

データベース管理： PostgreSQLやRedisの生のTCPストリームを、暗号化されたままリモートのデータサイエンティストと共有できます。HIPAAやSOC2などのコンプライアンスも満たします。

IoT・エッジ開発： NVIDIA Jetson Orin NanoのようなエッジAIデバイスも、暗号認証によりアクセス制御可能です。センサーのアクセス権を即座に取り消すことも可能です。

エフェメラリティと爆発範囲の縮小

現代のサイバーセキュリティでは、永続性は敵です。長時間稼働するトンネルはリスクを高めます。Zrokは設計からエフェメラルを採用し、タスク完了後に自動的に破棄される仕組みです。Webhookのテストやコードレビュー後にトンネルは消滅し、暗号トークンも無効化され、潜在的な被害範囲を最小化します。

---

6. 高度なワークフロー：ペンテストとエシカルハッキング

プライベートローカルホスト共有の普及は、サイバーセキュリティコミュニティに大きな影響を与えています。特にRed Teamsやペンテスターは、リバースシェルやコールバックを受け取る必要があります。

従来は攻撃インフラのインバウンドファイアウォールポートを開放したり、パブリックリレーを使ったりしていましたが、Zrokを使えば、リスナーを127.0.0.1にバインドし、プライベートシェアと一時的なトークンを作成できます。これにより、安全な認証済みオーバーレイネットワークを通じてコールバックを受け取り、ターゲットネットワークのアウトバウンドファイアウォールルールを完全に回避しつつ、コマンド＆コントロール（C2）インフラを第三者に乗っ取られる心配もありません。リスナーは活動期間中、インターネットから見えません。

---

7. AIエージェントの接続：新たなユースケース

2026年のOpenZitiエコシステムの注目の進展の一つは、AIエージェントワークロードのゼロトラスト接続です。NetFoundryはziti-mcp-serverを公開しており、これは200以上のZiti Management APIツールを備えたMCP（Model Context Protocol）サーバです。これにより、AIエージェントは他の通信と同じゼロトラストの原則に基づいて、アイデンティティやサービス、ルーター、ポリシーを管理できます。

OpenZitiはまた、OpenAI互換のプロキシであるゼロトラストLLMゲートウェイも公開しています。セマンティックルーティングや負荷分散を行い、OpenAI、Anthropic、Ollama、vLLMなどのバックエンドと連携します。アイデンティティ認証、仮想APIキー、エンドツーエンド暗号化はOpenZitiを通じて実現され、AI推論トラフィックもインターネットから隠すことが可能です。これは、AIワークロードが分散マシン間でAPIを通じて通信することが増える中、開発者トンネリングと同じゼロトラスト原則がマシン間AI接続にも適用される流れを示しています。

---

8. データ主権とセルフホスティング

NetFoundryはzrok.ioのマネージドSaaS版を提供していますが、規制産業の組織にとって重要なのはデータの主権です。

Zrokとその基盤のOpenZitiは完全にオープンソース（Apache 2.0）であり、Dockerを使ったセルフホスティングも可能です。自社のクラウドインフラやオンプレミスのデータセンターにOpenZitiエッジルーターとZrokコントローラーを展開すれば、ルーティングメタデータや暗号鍵、ユーザーアイデンティティを完全に管理できます。DockerとCaddyを使ったセルフホストでは、自動ワイルドカード証明書更新やTLSによるAPIと公開シェアの保護も可能です。第三者のリレーに頼る必要はありません。

帯域幅や計算リソースに制限なく、データも外部に渡さずに運用できます。これは、金融、医療、政府の防衛契約に従事する組織にとって必須の機能です。

---

9. 2026年の代替市場の動向

安全なトンネリングの需要増により、競争も激化しています。各ツールの現状を正直に比較します：

Cloudflare Tunnels (cloudflared): 高性能なHTTPトンネリングサービス。CloudflareのZero Trustプラットフォームと連携し、アクセス制御やログ、DDoS保護を提供。無料で帯域制限なし。ただし、ドメインはCloudflareのDNSに限定され、UDPサポートはなく、リクエストサイズ制限もあります。TCPのみの有料プランもあります。

ngrok: 伝統的な巨人。Webhook検査などの機能が充実。主にパブリックURLを重視し、スキャナーのターゲットになりやすい。料金は高めで、CTログの露出問題も継続。

Tailscale / WireGuard: 永続的なデバイス間VPNに最適。ただし、一時的な「ポート共有」には不向きで、クライアントの事前インストールが必要です。

Bore: TCP専用のシンプルなオープンソース。インフラ依存なし。シンプルな用途には良いが、HTTPや認証、UDPには対応していません。

Zrok (OpenZiti): これらのギャップを埋めます。ngrokの一時的な便利さと、Tailscaleのアイデンティティネイティブなゼロトラストセキュリティを兼ね備え、オープンソースでUDP/TCPやファイル共有も可能です。セルフホスティングも対応。ただし、ngrok http 8080のようなシンプルさに比べ、初期設定はやや複雑です。

---

結論：配信をやめて認証を始めよう

インターネットは根本的に変わりました。内部ネットワークを「信頼できる」とし、外部を「信頼できない」とする時代は終わりです。信頼は地理的・ネットワーク的属性ではなく、リクエスターのアイデンティティによって暗号的に証明される必要があります。

Zrokのようなゼロトラストトンネリングプラットフォームに移行することで、開発者は安全なコラボレーションの未来を受け入れています。公開URLから認証済みのプライベートローカルシェアへの移行は、自動化された脅威の表面を効果的に無効化します：スキャン対象の公開URLも、ポートも、CTログもありません。OpenZiti 1.8が管理層もゼロトラストの制御下に置いた決定は、エコシステムが開発者の利便性を超え、本番環境のインフラへと成熟している証です。

AIワークロードやエッジデバイス、分散チームがネットワークの境界をますます抽象化する中、重要なのは、ローカル開発サーバーの共有やAIエージェント間の推論トラフィックのルーティングにおいても、同じ原則が適用されることです：インバウンドポートを閉じ、ダークネットを受け入れ、すべてのパケットがアプリケーションに到達する前に暗号的に検証されることを確実にしましょう。

---

出典：OpenZiti Tech Blog; NetFoundry Documentation; Better Stack Community; Startupik; Have I Been Squatted CT Log Analysis (2026年3月); Secybers OSINT Guide (2026年3月); fxTunnel Blog (2026年2月); GitHub — openziti/zrok; GitHub — openziti/ziti.