セルフホスティングによるデータ主権：オープンソースのリバースプロキシの変遷

企業の必要性：なぜマネージドTunnelsだけでは不十分なのか

ローカルサービスをインターネットに公開してテストやWebhook、リモートアクセスを行うことは、ソフトウェア開発やインフラ管理において日常的な作業です。長年、ngrokやCloudflare TunnelのようなマネージドSaaSプロバイダーが標準的な解決策でした。しかし、企業のインフラエンジニアやコンプライアンス担当、安全保障チームにとって、内部トラフィックを第三者のマネージドSaaSにルーティングすることは、厳しい規制の下ではますます正当性を説明しづらくなっています。

GDPR、HIPAA、SOC 2、FedRAMPの下で運用される企業は、データが収集された法域の法律とガバナンスに従う必要があります。マネージドSaaSのリバースプロキシを利用すると、内部APIやWebhookのペイロードは、第三者が管理するサーバーを経由してルーティングされるため、法的管轄区域が異なる場合もあります。

これにより、自己ホスティング型の本番用トンネリングツールへの移行が進んでいます。frp (Fast Reverse Proxy)、Zrok（OpenZitiのゼロトラストネットワーク上に構築）、およびInlets（Kubernetes向け）は、インフラチームがゲートウェイを社内に保持し、SaaSのサブスクリプション料金を避けるだけでなく、トラフィックの終点や検査権限をコントロールできるようにします。

この記事では、これら3つのツールの現状、比較、そしてコンプライアンスの観点から安定している部分と進化中の部分を解説します。

---

1. データ主権とコンプライアンスの状況

SaaSリバースプロキシの問題点

ngrokのようなマネージドツールは、プライベートネットワークに軽量クライアントをインストールし、プロバイダーのエッジサーバーへアウトバウンドトンネルを確立します。プロバイダーは公開URLを生成し、そのURLに送信されたトラフィックはプロバイダーのインフラを経由してあなたのネットワークに戻ります。便利ですが、以下のようなコンプライアンス上の課題も伴います:

• データの居住地: ドイツの開発者が米国にあるエッジサーバーを経由してローカルAPIをテストする場合、その越境ルーティングには合法的な転送メカニズムが必要です。ここで正確に理解しておきたいのは、トランスアトランティックの転送が自動的に違法になるわけではないことです。EU–US Data Privacy Framework (DPF)は、2023年7月に欧州委員会によって採用され、2025年9月にEU一般裁判所での最初の法的挑戦に耐えました。ただし、DPFは過去に何度も無効とされており（Safe Harborは2015年に、Privacy Shieldは2020年の*Schrems II*判決で無効化）、現在もCJEUでの審議中です。米国最高裁判決（2026年6月）や欧州データ保護委員会の監督義務に関する不確実性もあります。したがって、コンプライアンスチームは、過去の判例を踏まえ、クロスボーダーの問題を完全に排除した方が安全と判断するケースもあります。
• エッジでのTLS終端: HTTPレベルのマネージドプロキシは、TLSをエッジで終端し、トラフィックを復号して正しいトンネルにルーティングした後、再暗号化します。信頼できるプロバイダーでも、第三者がトラフィックの鍵を保持することになります。
• 可用性の依存: SaaSトンネルプロバイダーに依存すると、そのサービスの稼働状況に左右されます。
• スケール時の課金: ユーザや帯域に応じた料金体系は、利用が増えるとコストが高くなる可能性があります。

“Bring Your Own Infrastructure” (BYOI) アプローチ

第三者の転送メカニズムへの依存を減らすために、一部の組織は自社管理のインフラ上にゲートウェイをセルフホストしています。リージョンを選び、監査やアクセス制御を自社で行う方式です。以下の3つのツールは、それぞれ異なるアプローチを示しています。

---

2. frp (Fast Reverse Proxy): ベアメタルの基幹ツール

frp (fatedier/frp on GitHub)は、Goで書かれたリバースプロキシで、NATやファイアウォール背後のローカルサーバーを公開します。2026年6月時点で、GitHubスターは約107,000、180以上の公開依存プロジェクトに採用されており、Apache-2.0ライセンスです。最新安定版はv0.69.1です。

アーキテクチャとデータ主権

frpは、frps（サーバー側）とfrpc（クライアント側）の2コンポーネントから構成されます。frpsを自社のインフラに配置することで、トラフィックの法域をコントロール可能です。例えば、eu-central-1のサーバーにfrpsを配置すれば、その経路はドイツ/EU内に留まります。

コンプライアンス重視の読者向けに補足すると、frpのTransport Layer Encryptionはv0.50.0以降デフォルトでTLSですが、ペイロードレベルの暗号化や圧縮（transport.useEncryption, transport.useCompression）はデフォルトでは無効で、個別に設定が必要です。

企業利用に関する特徴

• プロトコル対応: TCP、UDP、HTTP、HTTPS、STCP。
• ゼロ公開露出のSTCP/XTCP: STCP（Secret TCP）は、frpsに登録しながら公開ポートを開かずに済みます。認証用の事前共有キーを提示する必要があります。XTCPは、STUNを用いたNATホールパンチングにより、クライアント間の直接P2P接続を試み、NATタイプが対応しない場合はSTCPにフォールバックします。
• コネクションプールと多重化: frpsは事前に確立したコネクションプールを維持し、リクエストごとの遅延を低減します。TCPストリームの多重化もv0.10.0以降サポート。
• KCPとQUIC: これらのトランスポートモードや、ssh -Rを使ったSSHトンネルゲートウェイ（v0.53.0）、IPレベルのルーティングを行うVirtualNet（TUNベース）もあります。
• 設定フォーマット: v0.52.0以降、TOML、YAML、JSONに対応。旧来のINIは非推奨です。

また、frpの開発者は、よりEnvoyに近いL4/L7プロキシコアのv2のリライトを進めています。READMEによると、かなり複雑化しており、リリース時期は未定です。

frpを選ぶべきタイミング

柔軟なプロトコル対応と完全セルフホスティングを望むチームに適しています。従来のVPNの代替として、特定サービスへのリモートアクセスに向いています。

---

3. Zrok：OpenZitiを基盤としたゼロトラストネットワーク

ZrokはNetFoundryが開発し、OpenZitiを基盤としたゼロトラストネットワークのオーバーレイです。ポートをフォワーディングするのではなく、エンドポイント間に暗号化されたアイデンティティベースのオーバーレイを確立します。OpenZitiのモデルでは、公開インターネット上にリスニングポートはなく、アクセスは暗号認証によって制御されます。

重要なバージョンアップ：v2.0 / zrok2

2026年3月に大規模なv2.0リリースが行われました。旧バージョンのチュートリアルを見ていると、コマンド構文が変わっています:

• バイナリはzrok2に変更され、zrokと並行してインストール可能です。v2は独自の環境ディレクトリ（~/.zrok2）、環境変数プレフィックス（ZROK2_*）、systemdユニットを持ち、アップグレード時に既存のv1に影響しません。
• 予約共有は名前空間/ネームモデルに置き換えられました。旧zrok reserve / zrok release / zrok share reservedコマンドは廃止され、zrok2 create shareとzrok2 delete shareが公開・非公開の共有を管理します。--share-tokenフラグも追加されています。
• 新コマンドzrok2 access dynamicProxyは、ホストヘッダーを解析せずにコントローラーから直接名前マッピングを受け取ります。

パブリックとプライベート共有

Zrokは2つの共有モードをサポートします:

1. パブリック共有 (zrok2 share public <target>)は、一般的なHTTPS URLを生成します。StripeやGitHub Webhookのような外部連携に適しています。
2. プライベート共有 (zrok2 share private <target>)は、URLの代わりにシェアトークンを生成します。コラボレーターやCI/CDパイプラインはzrok2 access private <token>を実行してサービスにアクセスします。公開DNSやオープンポートは不要で、トラフィックはエンドツーエンドでOpenZitiのネットワーク内を流れ、暗号鍵はエンドポイントだけが保持します。

また、“クローズド”パーミッションモード (--closed, v0.4.26以降)もサポートし、作成者の環境に限定したアクセス制御や、--access-grantによる特定アカウントへの付与も可能です。

ホスティングと価格設定

ZrokはApache-2.0ライセンスで、Linux、Docker、Kubernetes上にセルフホスト可能です。zrok.ioのホスティッドサービスもあり、無料プランは1日あたり5GB、25環境、50シェアバックエンド、50プライベートアクセスフロントエンドを提供（執筆時点）。セルフホスティングは利用制限を完全に解除しますが、その分OpenZitiコントローラーの構築が必要です。

Zrokを選ぶタイミング

ゼロトラスト、アイデンティティベースのアクセス制御を重視し、プライベートシェアを公共インターネットに触れさせたくない組織に適しています。新しいコードベースであり、v1→v2の移行も視野に入れる必要があります。

---

4. Inlets：Kubernetes向けトンネリング製品ライン

InletsはOpenFaaSの創設者Alex Ellisによる製品です。クラスタからサービスを公開したいが、パブリックIPを持たない環境（ベアメタルKubernetesやRaspberry Piクラスタ、エッジサイト）向けに、プライベートクラスタから選択したクラウドリージョンの軽量エグジットノードへアウトバウンドトンネルを作成します。

ライセンスの訂正：Inletsはオープンソースのトンネルではない

重要なポイント：inlets-proのバイナリはクローズドソースの商用ソフトウェアです。プロジェクトのFAQによると、inlets-operatorとinletsctl（エグジットノードのVMをプロビジョニングし、トンネルを設定するオーケストレーションツール）はMITライセンスですが、実際にトラフィックを運ぶinlets-proバイナリは商用ライセンスキー（個人・商用・エンタープライズ）をOpenFaaS Ltd.から取得しなければ動作しません。完全オープンソースのinlets（HTTPのみ、TLS自動化なし）は歴史的に存在しますが、inlets-proに置き換えられ、現在は非推奨です。

この点は、データ主権の観点からも重要です。出口ノードの場所を選び、トラフィックをエンドツーエンド暗号化できる一方、ベンダーが鍵を保持しない設計も可能です。ただし、inletsはngrokの商用モデルに近く、frpやZrokの完全オープンソースとは異なります。ライセンスコストやベンダー関係を避けたい場合は適しませんが、自己管理の出口ノードを持つことは可能です。

データ主権とアーキテクチャ

出口ノードのクラウドリージョンを選択できるため、トラフィックの地理的終点をコントロールできます。L4（TCP）とL7（HTTP）のトンネリングに対応し、inlets-proのL4モードではTLS終端はクラスタ内（例：内部のIngressコントローラー）で行われ、出口ノードは暗号化されたバイト列を中継します。

Inlets Operator

inlets-operatorはMITライセンスのKubernetesオペレーターで、ServiceオブジェクトのLoadBalancerタイプを監視します。出現したら、クラウドの負荷分散を設定せずに、選択したプロバイダー（DigitalOcean、Hetzner、AWSなど）に軽量な出口ノードVMを立ち上げ、トンネルを設定し、内部のPodに接続します。

2026年の製品ライン

InletsはCLIツールから拡張し、以下の製品群になっています： - Inlets Pro（セルフホスト型のトンネル、ライセンスは前述） - Inlets Cloud（管理型トンネル、HTTPS/SSHがバンドルされたサブスクリプション） - Uplink（SaaSベンダー向けのKubernetesネイティブコントロール層、複数顧客環境の接続に特化）

Inletsの選択タイミング

Kubernetesを多用し、運用の自動化と商用ライセンスによるサポートを重視するチームに適しています。ライセンスコストを避けたい場合はfrpやZrokが良いでしょう。

---

5. 新たなフロンティア：AIエージェントとMCPサーバー向けゼロトラストトンネリング

データ主権のトンネリングは、AIエージェントやMCP（Model Context Protocol）サーバーの内部ツールへのアクセスにも拡大しています。2026年に入り、NetFoundryはOpenZitiを拡張し、”AIエンクレーブ”と呼ばれるゼロトラストゲートウェイを発表しました：

• openziti/mcp-gatewayは、MCPツールをOpenZitiのオーバーレイ（またはZrok）上に集約・公開します。従来のローカル標準入出力やHTTPエンドポイントの代わりに、暗号化されたアイデンティティベースの通信を確立します。
• OpenAI互換のLLMゲートウェイは、OpenAI、Anthropic、Azure OpenAI、Bedrock、Vertex AI、Ollamaなどのプロバイダー間でセマンティックルーティングを行い、同じOpenZitiのアイデンティティで認証します。これにより、モデル呼び出しとツール呼び出しの両方を一つのアイデンティティと監査トレースで管理可能です。
• ziti-mcp-serverは、同時期にリリースされたMCPサーバーで、OpenZiti Management APIの約200ツールをMCPクライアントに公開します。エージェントは自然言語リクエストを通じてアイデンティティやサービス、ポリシーを管理し、人的操作と同じ認証を行います。

この動きは、トンネリングベンダーがエージェントとツール間の通信専用インフラを構築し、Webhookのような汎用トンネルを流用するのではなく、目的別のインフラを作る方向性の明確な例です。2026年3月にリリースされたZrok v2.0とともに進化中です。

---

6. 比較表

機能/要件	frp	Zrok (OpenZiti)	Inlets
主な用途	ベアメタルのTCP/UDPトンネリング	ゼロトラスト、アイデンティティベースの公開・非公開共有	Kubernetesのインゲスト、クラウドネイティブL4/L7トンネリング
ライセンス	完全オープンソース（Apache-2.0）	完全オープンソース（Apache-2.0）	オーケストレーションツール（inlets-operator, inletsctl）はMIT、inlets-proはクローズドソース商用
セキュリティモデル	ポートフォワーディング; STCP/XTCP事前共有キー	ゼロトラストオーバーレイ;エンドツーエンド暗号化	アウトバウンドWebSocketトンネル;L4パススルーと内部TLS終端
デフォルトの暗号化	TLS（v0.50.0以降）;ペイロード暗号化はオプション	プライベートシェア間でエンドツーエンド	トンネルモードに依存;L4は内部TLSを維持
データ主権	高い — 完全セルフホスト、リージョン選択可能	高い — セルフホストまたはホスティング、エンドツーエンド暗号化	中〜高 — 出口ノードのリージョン選択可能、商用ベンダー依存
Kubernetesネイティブ	手動設定	コンテナ化可能、設定必要	自動化されたエグジットノードプロビジョニングのオペレーター
公開IP必要性	必須	非必須（プライベートシェアの場合）	必須（出口ノード側）
運用の複雑さ	中程度	高い — OpenZitiコントローラー必要、またはv1→v2移行	低〜中 — 自動化された運用

---

7. セルフホストトンネリング戦略のベストプラクティス

1. セルフホスティング＝暗号化がデフォルトではないことを理解する。 frpの例のように、Transport層のTLSはデフォルトで有効でも、ペイロードレベルの暗号化は設定次第です。ツールごとのデフォルトを確認しましょう。
2. TLS終端は可能な限り内部で行う。 L4/TCPパススルー（frp、inlets-pro）や内部IngressでTLS終端を行えば、リレーサーバーは復号済みトラフィックを保持しません。攻撃リスクを低減します。
3. 規制要件に合ったリージョンにリレーを配置し、その理由を記録する。 監査や規制当局の問い合わせに備え、なぜそのリージョンを選んだのかを明確にしておきましょう。
4. アクセスを定期的に監査する。 frpならallowPorts設定、Zrokならクローズドシェアのアクセス許可とトークンのローテーションを行います。
5. トンネルトラフィックも他のインゲストと同様に監視。 ログをSIEMに取り込み、帯域パターンをPrometheusやOpenTelemetryで追跡します。セルフホスティングはベンダーのエッジを排除しますが、トンネルはプライベートネットワークへの橋です。

---

結論

マネージドSaaSリバースプロキシの便利さは、厳しいデータ保護規制下の組織にとっては、実際のコンプライアンスリスクも伴います。クロスボーダーのデータ転送は、DPFのような仕組みを使えば合法となる場合もありますし、セルフホスティングが必ずしもトラフィックの暗号化を保証するわけではありません。設定次第です。

ただし、frp、Zrok、Inletsは、それぞれインフラチームにトンネルの終点を選択させ、Zrokでは内部共有のために公開エンドポイントを避けることも可能です。3つの中で、frpとZrokはライセンスコストなしのオープンソースです。一方、Inletsは商用ライセンスと自動化されたKubernetesワークフローを提供します。どれが適しているかは、プロトコルの柔軟性（frp）、ゼロトラストのアイデンティティ認証（Zrok）、Kubernetesネイティブの自動化とサポート（Inlets）次第です。

---

変更履歴

修正点: - US拠点のSaaSトンネルを通じたルーティングが自動的に違法とされる誤解を削除し、EU–US Data Privacy Frameworkの正確な状況を追記（2023年7月採用、2025年9月EU一般裁判所判決、CJEU審議中、2026年6月米国最高裁判決の影響も言及）。 - Inletsを「オープンソースのngrok代替」とした記述を修正。inlets-operatorとinletsctlはMITライセンス、inlets-proはクローズドソースの商用ライセンスが必要と明記。 - Zrokのコマンド構文と概念を更新。v2.0は2026年3月にリリースされ、バイナリ名はzrok2に変更、予約共有モデルは廃止され、ネームスペース/ネームモデルに置き換え。 - frpのTransport層TLSはv0.50.0以降デフォルトで有効だが、ペイロード暗号化と圧縮はオプションであることを明示。 - 広告的な表現（軍用グレード等）を中立的な記述に修正。

追記: - 現在のfrpの実績（約107kスター、Apache-2.0、最新v0.69.1、設定フォーマットの移行、SSHゲートウェイ、α版VirtualNet、未リリースのv2リライト） - 2026年のAIエージェント・MCPサーバー向けゼロトラストインフラの詳細（openziti/mcp-gateway、OpenAI互換LLMゲートウェイ、ziti-mcp-serverのリリース） - Inletsの製品ライン詳細（Inlets Cloud、Uplink、セルフホストのInlets Pro） - Zrokの”クローズド”パーミッションモードとライセンス表記 - 比較表にライセンスの区分を追加し、オープンソースと商用の違いを明示

情報源: github.com/fatedier/frp、github.com/openziti/zrok、blog.openziti.io、netfoundry.io/docs、zrok.io/pricing、inlets.dev、github.com/inlets/inlets-pro、github.com/inlets/inlets-operator、prnewswire.com、github.com/openziti/mcp-gateway、blog.openziti.io、EU-US Data Privacy Frameworkの法的分析資料など。