完全なデータコントロール：frp、Zrok、Inletsによるセルフホスティングトンネル

エンタープライズのセキュリティコンプライアンスでは、内部トラフィックをサードパーティの商用サーバー経由でルーティングすることが厳しく禁じられる場合があります。インフラエンジニアやDevOpsチームにとって、ローカルサービスの公開、Webhookのデバッグ、プライベートKubernetesクラスターへのアクセスは日常的な必要事項です。しかし、商用SaaSトンネルに依存すると、データ主権やコンプライアンスの問題を引き起こす可能性があります。

組織のセキュリティポリシーが、「内部のバイトがサードパーティのサーバーを通過してはいけない」と定めている場合、自前のngrokの代替手段が必要です。高性能なオープンソースツールを活用することで、チームは速度やコンプライアンスフレームワーク（SOC 2、HIPAA、FedRAMPなど）を犠牲にすることなく、安全でプライベートなトンネルを構築できます。

この記事では、セルフホスト型トンネルのデータ主権の観点から、そのメリットを解説し、次の3つのソリューションを詳しく紹介します：オープンソースのリバースプロキシ frp、ゼロトラスト Zrok ネットワーク、そして商用の Inlets 製品群 — そしてオンラインで流布している「無料のオープンソースInlets」というフレーズがもはや現実と合わなくなっている点も指摘します。

1. 現代のDevOpsにおけるデータ主権の必要性

データ主権とは、デジタルデータが収集・処理される法域の法律やガバナンスの対象となるという考え方です。リバースプロキシやネットワークトンネルにおいては、データが通る物理的・仮想的な経路を制御し続けることが重要です。

SaaSトンネルの問題点。 商用トンネルサービスは、軽量なクライアントをマシンにインストールし、中央のリレーにアウトバウンド接続を確立します。次に、そのリレーが公開URLを提供し、そのURLを通じてトラフィックをインフラ経由でルーティングし、あなたのローカルサービスに戻します。便利ですが、規制の厳しいチームにとっては次のようなリスクがあります：

• メタデータの露出： エンドツーエンドの暗号化があっても、接続のメタデータ（IP、タイミング、ペイロードサイズ）はプロバイダーに見えています。
• コンプライアンスリスク： 医療、金融、政府部門では、内部アプリケーションデータをマルチテナントのサードパーティインフラにルーティングすることは法的に制限される場合があります。
• ベンダー依存： パイプラインはサードパーティの稼働率やレートリミットに依存します。

セルフホスト型の代替手段では、クライアント、リレー、暗号鍵をすべて自分で管理します。

2. frp：高性能なオープンソースリバースプロキシ

frp（Fast Reverse Proxy）は、多くのインフラチームが最初に選ぶセルフホストngrokの代替ツールです。Go言語で書かれ、クロスプラットフォーム対応。二つのコンポーネントに分かれています：frps（サーバー、あなたが管理するパブリックホスト上に展開）と frpc（クライアント、プライベートネットワーク内で動作）。GitHubスター数は約108,000で、活発に開発が続いています。最新の安定版（v0.70.0）は2026年7月にリリースされました。

プロトコルとトランスポートのサポート。 frpはTCP、UDP、HTTP、HTTPSを標準サポートし、SSH、RDP、MySQL、RAW TCPストリームとWebトラフィックを同時にトンネル化可能です。frpcとfrps間では、標準のTCP、KCP（UDPベースのプロトコルで、損失の多いネットワークでも耐性を持たせるためにオーバーヘッドを一部犠牲に）または QUIC（最新のUDPベースの多重化トランスポート）を選択できます。これにより、グローバルに分散したネットワークでも信頼性を確保できます。

設定のポイント： frpは古い frps.ini / frpc.ini 形式から移行し、v0.52.0以降はTOML（YAMLやJSONもサポート）を推奨。INIは非推奨となっています。設定例は次の通りです：

# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

TLSはデフォルトで有効。 以前のドキュメントでは tls_enable = true の手動設定が必要とされていましたが、v0.50.0以降は transport.tls.enable がデフォルトで true となり、暗号化は標準装備です。サーバ側で明示的に無効化したり、transport.tls.force = true で未暗号化クライアントを拒否する設定も可能です。

P2Pモード（XTCP）。 frpのP2P機能は xtcp プロキシタイプで、「モード」ではありません。STUNベースのNATホールパンチングを利用し、一度直接経路が確立されると、実データはfrpsを経由せず、最初のネゴシエーションだけがサーバを通ります。すべてのNATタイプに対応するわけではなく、ホールパンチングが失敗した場合は fallbackTo のSTCPビジターを設定可能です。これにより、「サーバはデータを見ていない」というよりも、frpsも接続交渉に関与している正確な動作になります。

ダッシュボードとAPI。 frpsのダッシュボードは継続的に改善されており、2026年7月のリリースではAPI v2への移行、クライアントやプロキシ、サーバーの概要と詳細ビュー、ページネーション、トラフィック履歴、システム情報、フィルタリング機能が追加され、規制のある環境での監査ログに役立ちます。

v2へのリライトは進行中。 メンテナは長期にわたりfrp v2の開発を進めており、Envoyに似たL4/L7のモダナイズされたコアを目指しています。2026年中頃現在も開発は遅れ気味ですが、スコープが大きく、断片的に進行しています。リリース予定は未発表です。

3. Zrok：ゼロトラストネットワークオーバーレイ

frpはポイントツーポイントのリバースプロキシですが、多くの企業アーキテクチャはZero Trust Network Access（ZTNA）へと移行しています。そこでZrokが登場します。

OpenZiti上に構築。 ZrokはNetFoundryのオープンソース共有・トンネリングプラットフォームで、OpenZitiを基盤としています。単にポートを転送するだけでなく、暗黙の信頼を持たず、IDに基づくアクセス制御を行います。リレーサーバーもトラフィックを復号できず、エンドツーエンドの暗号化が実現されています。

共有モード。 Zrokは二つの主要モードをサポートします：

• 公開共有：HTTPS URLを生成し、誰でもアクセス可能 — ngrokと類似。
• プライベート共有：認証済みのZrokクライアント間でトークンベースの接続を作成し、公開エンドポイントを持たない。バックエンドモードにより、HTTPプロキシ、raw TCP/UDP（tcpTunnel / udpTunnel）、SOCKS5の動的プロキシ、またはOpenZitiオーバーレイ上のホスト間VPNスタイルのトンネルも可能。

インバウンドポート不要。 すべてのZrok接続はアウトバウンドで確立されるため、ファイアウォール設定やポートフォワーディング、パブリックIPの設定は不要です。

2026年のセキュリティ強化。 OpenZiti 1.8以降、コントローラーAPIはOpenZitiサービスとしてバインド可能となり、管理プレーンも暗号認証を受けるため、攻撃リスクが低減します。

バージョン情報。 現在の安定版はzrok v1.x（2026年初時点でv1.1.11）。次世代の「zrok2」は開発中であり、正式運用には推奨されません。調査中の参考情報として知っておくと良いでしょう。

新たなユースケース：AIエージェント向けゼロトラストトンネル。 2026年のOpenZitiエコシステムでは、AIワークロード向けのゼロトラストゲートウェイやMCP（Model Context Protocol）ゲートウェイ、LLMゲートウェイなどのコミュニティプロジェクトが進行中です。AIコーディングエージェントやMCPサーバーに関わるインフラを構築する場合、注目すべき分野です。

セルフホスト対応。 ZrokとOpenZitiはApache 2.0ライセンスで、完全セルフホストも可能です。自前のOpenZitiコントローラーとZrokインスタンスを運用すれば、規制のあるチームも追加料金なしで運用できます。

4. Kubernetesローカルホストトンネリング：クラウドネイティブなアプローチ

組織がコンテナ化を進める中、よくある質問は「ローカルサービスをリモートのKubernetesクラスターに公開するにはどうすれば良いか」「内部クラスターサービスをローカル開発マシンに安全に公開できるか」です。

内部クラスターリソース（ステージングAPIやプライベートダッシュボード）の公開には、Ingressコントローラー設定やLoadBalancerサービス、DNSレコードが必要です。デバッグのためにkubectl port-forwardを使うこともありますが、長時間の接続や外部共有には脆弱です。これを補うのが、frp（手動のKubernetesマニフェストを用いる）やInletsのようなツールです。

5. Inlets vs. frp：適切なトンネルの選択と訂正

セルフホストKubernetesトンネルの比較では、「inlets vs. frp」がよく話題になります。両者ともNATをバイパスし、SaaS依存を避けますが、ビジネスモデルは大きく異なっています。

訂正点： オリジナルのオープンソース版「inlets」は廃止され、更新も停止しています。GitHub上にはソースコードはありますが、メンテナンスされていません。代わりにinlets Pro（商用版）が登場しています。無料のオープンソース版はもはや存在しません。したがって、「無料 vs. 有料」の比較は、Inletsは「有料」と考えるべきです。

現在のInlets製品ラインナップ（OpenFaaS Ltd）:

• inlets Pro — HTTP/TCPトンネルのコアクライアントとサーバー。個人や小規模チーム向け。
• Inlets Uplink — Kubernetesネイティブのセルフホスト制御プレーン。SaaSやサービスプロバイダー向けで、顧客の環境（プライベートデータベースやAPI）にアクセス可能。VPNのような仕組みではなく、クライアントからサーバーへアウトバウンドのTLS/WebSocket接続を確立し、データプレーンは基本的にプライベートのままです。
• Inlets Cloud — 完全管理型サービス。

料金例（inlets.dev/pricing）： - パーソナル：$25/月（5トンネル） - 商用：$50/月（2トンネル＋追加は$25/月／トンネル） - Uplink：$250/月／クラスター（10トンネル＋追加は$25/月／トンネル） ※ 年払いで割引あり。古い「$25–$50/月」の範囲よりも正確な価格です。

Kubernetes連携。 inlets-operatorはTunnelカスタムリソースを使い、LoadBalancerタイプのサービスを監視して自動的にクラウドVMにinlets Proサーバーを展開します。これにより、クラウドのLoadBalancerがなくても、ホームラボやベアメタル環境で便利です。

frpの優位点： ネイティブのKubernetesオペレーターはなく、自分でDeploymentやConfigMap、Serviceを作成する必要がありますが、その分無料で高機能なプロトコル対応のリバースプロキシ（KCPやQUICもサポート）を利用できます。ライセンス料も不要です。

結論： サポート付きのKubernetesネイティブ商用製品（Inlets Pro/Uplink）は導入が容易で、コストも明確です。一方、frpは無料で高機能な自己管理型リバースプロキシとして優れています。選択は、「商用・管理型」か「無料・DIY」かの違いです。

6. 実践例：主権を保証する実装

ステップ1：リレーサーバーの法域を確保。 frpsやOpenZitiコントローラーは、組織の法的管轄区域内に設置します。例：EUのヘルステック企業がEU内にリレーを置き、データの越境を防ぐ。

ステップ2：エンドツーエンドの暗号化を実施。 frpはv0.50.0以降、transport.tls.enableがデフォルトで有効となり、追加の暗号化は不要です。ZrokはOpenZitiの暗号化機能により、データは送信元から宛先まで暗号化され、管理プレーンも同じ基準で保護されます。

ステップ3：IDに基づくアクセス制御。 Zrokのプライベート共有モードでは、特定の認証済みZrok IDにアクセス権を付与できます。社員退職時にはIDを取り消すだけで、すべての内部トンネルのアクセスが停止します。リンクの漏洩リスクも排除されます。

7. まとめ：ネットワークの取り戻し

商用トンネルの便利さは否定できませんが、規制のある環境ではデータ主権が最優先です。 proprietaryコードや内部データベース、未発表の製品プレビューをベンダーのインフラに預けるのはリスクです。

frpは無料でプロトコルに柔軟なネットワークトラバーサルの万能ツールです。最新のTOML設定、TLS標準装備、ダッシュボードの改善も進行中です。ZrokはOpenZitiを基盤とし、ゼロトラスト・IDベースの共有に最適です。公開・非公開の両方に対応し、インバウンドポートを開ける必要もありません。AIエージェントやMCPワークロード向けの新しいゼロトラストトンネルも増えています。InletsはKubernetesネイティブの商用サポート製品として検討価値がありますが、無料のオープンソース版は廃止されており、今利用できるのはPro/Uplink/Cloudラインです。

ネットワークの完全なコントロールを取り戻すには、トラフィックのライフサイクル全体を所有し、各ツールのコストや運用負荷を正確に理解することが重要です。

---

変更履歴

2026年7月時点の主要情報源（gofrp.org、github.com/fatedier/frp、github.com/openziti/zrok、inlets.dev、docs.inlets.dev）に基づく修正と追加：

• SEO/メタデータの削除とタイトルの整形
• frp設定フォーマットの更新：INIからTOMLへ移行し、非推奨化
• TLSのデフォルト有効化の明記
• P2P/XTCPの説明を明確化：frpsは交渉に関与し続ける点を追記
• 最新安定版のバージョンとリリース情報を追加
• Zrokのプライベート共有の詳細とバックエンドモード（proxy、tcpTunnel/udpTunnel、socks、vpn）を明示
• OpenZiti 1.8のコントローラーサービス化によるセキュリティ強化を追記
• zrok v1.1.11とzrok2の開発状況を記載
• AIエージェント向けゼロトラストゲートウェイの新規セクションを追加
• Inletsの廃止と商用化の事実を明示し、価格情報を最新化
• Inlets Uplinkの用途と特徴を修正
• 価格例と料金体系を正確に記載
• Kubernetes連携の仕組みを詳述
• frpとInletsの比較と選択ポイントを整理
• 実践例とセキュリティ対策の具体的なステップを追加
• 結論部分を最新の情報に合わせて修正