Ngrok vs. frp (Fast Reverse Proxy): マネージドトンネルとセルフホストの究極対決

ローカル開発サーバー、IoTデバイス、またはオンプレミスのステージング環境を公開インターネットに露出させるには、かつては面倒なルーター設定が必要でした。ISPレベルのキャリアグレードNAT（CGNAT）を回避し、静的パブリックIPを要求し、コンシューマファイアウォールのポートを手動で開ける必要がありました。

現代のエンジニアリングはこの摩擦を克服しています。今日では、リバーストンネリングツールがアウトバウンド接続を通じて安全なインバウンド経路を作り、ファイアウォールの制限を完全にバイパスします。

リバーストンネリングのアーキテクチャを選択する際、二つの主要な哲学が浮かび上がります。一方は ngrok で、完全に管理された開発者向けクラウドサービスで、プラグアンドプレイのシンプルさと瞬時のエッジ機能を優先します。もう一方は frp（Fast Reverse Proxy）で、GitHubで107,000以上のスターを持つオープンソースのセルフホスト型重鎮です。

これらの選択は単なるツールの選択ではなく、データ主権、コスト効率、運用負荷に関する根本的なアーキテクチャの決定です。本ガイドでは、ngrokとfrpのコアな違い、パフォーマンス特性、セキュリティ実装、設定戦略を解説し、あなたのインフラストラクチャに最適な選択を支援します。

1. アーキテクチャの哲学：SaaS vs. セルフホスト

ngrokとfrpの根本的な構造の違いを理解することで、それぞれがトラフィックルーティングとインフラ管理をどのように扱っているかが見えてきます。

ngrokのパラダイム：Managed Edge-as-a-Service

ngrokは商用のSoftware-as-a-Service（SaaS）プラットフォームとして動作します。ローカルマシン上でngrokエージェントを実行すると、暗号化されたアウトバウンド接続をngrokの世界中に分散されたクラウドエッジネットワークに開始します。

[ローカルアプリケーション]
       │
       ▼ (ngrokエージェント経由のアウトバウンド接続)
[ngrokクラウドエッジネットワーク] ◄───── (インターネット経由のパブリックリクエスト) ─── [外部ユーザー]

パブリックインターネットからのトラフィックはngrokのエントリーノードに到達し、管理されたWebアプリケーションファイアウォール（WAF）やDDoS保護層を通過し、確立されたトンネルを通じてローカルマシンへルーティングされます。サーバーや証明書、ルーティングテーブルは管理しません。すべてクラウドAPIを通じて処理されます。

frpのパラダイム：セルフホスト型トラフィック委任

frpはサードパーティのインフラを排除します。トンネリング処理を二つの軽量バイナリに分割しています：

• frps（frpサーバー）：あなたが公開アクセス可能なマシンにホストし、DigitalOcean、Linode、AWS Lightsailなどの低コストVPS上に配置します。
• frpc（frpクライアント）：ターゲットアプリケーションとともにあなたのプライベートネットワーク内で実行します。 [ローカルアプリケーション] │ ▼ (frpc経由のアウトバウンド接続) [あなたのクラウドVPS（frps）] ◄───── (インターネット経由のパブリックリクエスト) ─── [外部ユーザー]

frpcクライアントは、稼働中のfrpsサーバーにアウトバウンド接続します。外部クライアントがVPSに割り当てられたポートやドメインに接続すると、frpsはそのトラフィックをカプセル化し、アクティブな接続チャネルを通じてfrpcに送ります。frpcはそれをローカルアプリケーションのポートに直接マッピングします。あなたはインフラ提供者、ネットワーク運用者、唯一のデータ管理者です。

2. 機能別詳細解説

アーキテクチャの違いは、機能セットに大きな差をもたらします。この表は、2026年7月時点の各プロジェクトの最新、検証済み状態を反映しています。

機能 / 特徴	ngrok（管理されたクラウド）	frp（Fast Reverse Proxy）
主要モデル	商用SaaS / 管理されたクラウドエッジ	オープンソースセルフホスト（Go）
GitHub人気	独自クライアント（エージェントはクローズソース）	107,000+スター、15,100+フォーク
最新安定リリース	なし（継続的に展開されるクラウドサービス）	v0.69.1（2026年6月）
プロトコルサポート	HTTP, TCP（全層）；TLS（従量課金のみ）	TCP, UDP, HTTP, HTTPS, STCP, XTCP（P2P）
データ主権	第三者経由（ngrokのエッジネットワーク）	完全 — トラフィック経路をあなたが制御
帯域幅	プランによるメーター制（1GB〜5GB含む、その後$0.10/GB）	無制限 — VPSのアップリンク次第
TLS/SSL管理	自動化された管理証明書	手動またはACMEプラグインによる自動化
トラフィック検査	リアルタイムWeb UIコンソールとリクエスト/レスポンスのリプレイ	基本的なWebダッシュボード、Prometheusメトリクス対応
料金制約	無料プランは月1GB、3エンドポイントまで	機能制限なし — コストはVPSのみ
UDPサポート	どの層でも未対応	ネイティブUDP、KCP、QUICトランスポート対応

3. セルフホスティングの威力：frpの機能

frpは、商用代替品の制約を打ち破る広範で積極的にメンテナンスされた機能セットにより、エンタープライズグレードのセルフホストツールとしての地位を築いています。

完全なデータ主権

商用プロキシサービスを利用すると、暗号化されていないHTTPペイロード、認証ヘッダー、Webhookデータが外部プロキシノードを通過します。HIPAA、GDPR、SOC 2などのコンプライアンスフレームワークに縛られるチームにとって、これはデータ供給チェーンの重要な考慮点です。

frpでは、データはインフラの境界を超えず、エンドユーザーから直接あなたのクラウドコンピュートインスタンスを経由してローカルアーキテクチャへ渡ります。

機能制限なし

frpにはペイウォールの概念はありません。ホストに1Gbpsの無制限ポートがあれば、その能力を継承します。数百のプロキシを同時に稼働させ、カスタムのApexドメインをバインドし、TCP/UDPポートマッピングを予約しても、APIレート制限に引っかかることはありません。実質的な上限はあなたのVPSです。

高度なNATトラバーサル：STCPとXTCP

従来のリバースプロキシはすべてのデータを公開サーバー経由でルーティングし、サーバーの帯域幅が実効速度を制限します。frpはこれに対し、二つの追加接続モードを提供します：

• STCP（Secret TCP）：プロキシを完全にインターネットから隠蔽します。クライアントはsecretKeyを提示し、[[visitors]]ブロック内でfrpcインスタンスに接続します。公開ポートは不要です。
• XTCP（P2Pトラバーサル）：STUNベースのUDPホールパンチングを利用し、訪問者とローカルクライアント間の直接P2P接続を試みます。frpsは最初のハンドシェイクとシグナリングに必要ですが、一度確立すればデータはエンドポイント間を直接流れ、サーバーをバイパスします。frpのドキュメントでは、すべてのNATタイプで動作するわけではなく、失敗した場合はSTCPにフォールバックすることを推奨しています。

2026年中のfrpの新機能

frpは、過去のマイナーリリースでいくつかの重要なアップデートをリリースしています。2026年1年以上前に触れた場合は特に知っておくべき内容です：

• 正式な互換性ポリシー（v0.69.0以降）：各マイナーリリースは、次の9つのマイナーリリースまでサポートされます。例：v0.69.0はv0.78.0までサポートされ、アップグレードの明確な期間を提供します。
• Wire Protocol v2（v0.69.0+）：AEAD暗号化（xchacha20-poly1305またはaes-256-gcm）を交渉する新しいバージョンのfrpc↔frpsプロトコル。レガシープロトコルの置き換えを目指します。transport.wireProtocol = "v2"で有効化可能ですが、デフォルトではありません。
• 動的プロキシ管理（”Store”）（v0.68.0+）：frpcはWeb UIやAPIを通じて、ランタイムでプロキシやビジターを作成・更新・削除でき、ディスクに永続化します。
• SSHトンネルゲートウェイ（v0.53.0+）：frpsはssh -R接続を直接受け入れ可能となり、frpcをインストールせずにTCPプロキシを作成できます。
• VirtualNet（α版、v0.62.0+）：クライアントとビジター間のIPレベルのルーティングを拡張するTUNインターフェースベースの機能です。まだα段階で、デフォルトでは無効です。

注記：frpの長らく議論されてきた「v2」アーキテクチャの書き換え（Envoyのような4層/7層プロキシコア）は、上記のwire protocol v2とは別の大規模な取り組みです。2026年中の開発状況について、メンテナはその複雑さが予想以上と述べており、計画的なリリースは未定です。

4. ngrokの価値提案

セルフホスティングには明確な利点がありますが、ngrokは運用負荷ゼロのシンプルさと、プロダクションレベルのエッジ機能を重視するチームにとって強力な選択肢です。

インフラ管理不要

frpの設定にはVPSの準備、ファイアウォール設定、systemdデーモンの管理が必要ですが、ngrokはこれらを完全に排除します。ローカルインスタンスを公開するには、次のコマンド一つだけです：

ngrok http 8080

サーバーの準備やセキュリティパッチの追跡は不要です。

高度なトラフィック検査とリクエストリプレイ

ngrokのローカルWebインスペクター（http://127.0.0.1:4040）では、インバウンドHTTPリクエストのヘッダーやJSONボディまで確認でき、リプレイ機能によりキャプチャしたWebhookを再トリガーできます。

アイデンティティとエッジ保護の内蔵

ngrokはTraffic Policyを通じて認証を組み込み、OIDCやSAML、リクエストごとのレート制限を設定可能です。これにより、追加のインフラを立ち上げる必要はありません。

2026年版：ngrokのAI/MCPゲートウェイ

これはngrokの大きな変化の一つです。エッジプラットフォームを「Universal Gateway」と呼ばれるAI特化の層に拡張し、以下の機能を追加しています：

• ngrokをMCPゲートウェイとして利用：ローカルのMCPサーバーの前にngrokエージェントエンドポイントを配置し、Traffic Policyを使ってMCPリクエストを認証・承認・監査可能。例：AnthropicやOpenAIのIP範囲へのインバウンド接続制限やAPIキーごとのレート制限をコード変更なしで実現。
• ngrok.ai（AIゲートウェイ）：OpenAI互換のルーティング層（2026年7月1日リリース、app.ngrok.ai）で、モデル呼び出しの前に配置されます。プロバイダーキーの持ち込み、自動フェイルオーバー、セルフホストモデル（Ollama、vLLM）との併用も可能です。baseURLを変更するだけで設定完了。2026年4月以降、無料プランでも利用可能です。

これらはfrpの用途を置き換えるものではなく、LLMトラフィック用の並列製品です。ただし、エージェント型ワークフローにおいてngrokが重要な役割を果たす理由の一つです。この記事で取り上げたzrok/OpenZitiのゼロトラストAIエージェントトンネリングとも直接関係します。

ngrokの2026年の料金（ngrok.com参照、2026年7月）

プラン	価格	データ転送	HTTP/Sリクエスト	オンラインエンドポイント	プロトコル
無料	$0	1 GB含む	20,000/月	3	HTTP, TCP（カード認証必要）
Hobbyist	$8/月（年額請求、月額$10）	5 GB含む、その後$0.10/GB	100,000含む、その後$1/10万	3	HTTP, TCP
従量課金	$20/月 +使用量	5 GB含む、その後$0.10/GB	10万含む、その後$1/10万	無制限	HTTP, TCP, TLS

UDPはngrokのどの層でも利用不可です。これはアーキテクチャのギャップであり、料金の問題ではありません。ゲームサーバー、VoIP、UDPベースのIoTプロトコル（CoAPやDTLSなど）を扱う場合、最も一般的な理由の一つです。UDP必須でセルフホスティングfrpが選択肢にない場合、ngrokのこの制約は重要です。2026年にかけて、Localtonet、LocalXpose、Pinggy、Playit.ggなどのUDPネイティブの管理代替が台頭していますが、それらの評価はこの比較の範囲外です。

5. ステップバイステップ導入ガイド：プライベートfrpネットワークの構築

標準的なUbuntuクラウドインスタンスにおいて、最新の安定版（v0.69.1）と正確なTOML構文を用いたfrpトンネリングネットワークの設定例です。

ステップ1：サーバーノード（frps）の設定

SSHでクラウドVPSにログインし、最新リリースバイナリをダウンロードして展開します：

wget https://github.com/fatedier/frp/releases/download/v0.69.1/frp_0.69.1_linux_amd64.tar.gz
tar -zxvf frp_0.69.1_linux_amd64.tar.gz
cd frp_0.69.1_linux_amd64

サーバーバイナリを/usr/local/binにコピーし、設定ディレクトリを作成します：

sudo cp frps /usr/local/bin/
sudo mkdir -p /etc/frp

/etc/frp/frps.tomlを作成します。HTTP/HTTPSのvhostキーは大文字のHTTP/HTTPSを使用します。vhostHttpPortやvhostHttpsPortは無効なTOMLキーであり、バインドに失敗します：

# /etc/frp/frps.toml
bindPort = 7000

# HTTP/HTTPS仮想ホスト設定
vhostHTTPPort = 80
vhostHTTPSPort = 443

# 認証レイヤー（不正なクライアント接続防止）
auth.method = "token"
auth.token = "SUPER_SECURE_LONG_CRYPTO_TOKEN_STRING"

# 内蔵監視ダッシュボードの有効化
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "CHOOSE_A_COMPLEX_DASHBOARD_PASSWORD"

systemdユニット/etc/systemd/system/frps.serviceにラップします：

[Unit]
Description=frpサーバーデーモン
After=network.target

[Service]
Type=simple
User=nobody
Restart=on-failure
RestartSec=5s
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml

[Install]
WantedBy=multi-user.target

systemdをリロードし、有効化・起動します：

sudo systemctl daemon-reload
sudo systemctl enable frps
sudo systemctl start frps
sudo systemctl status frps

ステップ2：クライアントノード（frpc）の設定

ローカルマシンにfrpc.tomlを作成します。localIP（大文字）を使用し、localIpは誤りです。frpの設定パーサーはケースセンシティブです：

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

auth.method = "token"
auth.token = "SUPER_SECURE_LONG_CRYPTO_TOKEN_STRING"

# 例1：ローカルSSHサービスのフォワーディング
[[proxies]]
name = "secure-ssh-tunnel"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6022

# 例2：ローカル開発Webアプリの公開
[[proxies]]
name = "local-web-development"
type = "http"
localIP = "127.0.0.1"
localPort = 8080
customDomains = ["dev.yourdomain.com"]

クライアントを起動します：

./frpc -c ./frpc.toml

接続後、dev.yourdomain.com（DNSでVPSのIPにポイント）に届くHTTPリクエストは、ローカルのポート8080に直接ルーティングされます。

設定ファイルに構文エラーがないかfrpc verify -c ./frpc.tomlで確認し、frpc reload -c ./frpc.toml（webServerブロック設定必須）で再起動せずにプロキシ設定をリロードできます。

6. 実践的な意思決定マトリクス：どちらを選ぶべきか？

                  完全なデータ主権が必要か？
                                 │
                   ┌─────────────┴─────────────┐
                  YES                          NO
                   │                           │
              [frpを使用]           スタックの複雑さと
           (セルフホスト)        UDPやAI/MCPツールの必要性
                                   ┌────────────┴────────────┐
                                   ▼                         ▼
                              シンプルなHTTP/TCP、        複雑、または
                              AIゲートウェイ/ MCP必要  UDPが必要
                                   │                         │
                              [ngrokを使用]             [frpを使用]
                             (高速セットアップ)        (スケール/UDP/P2P)

ngrokを選ぶ理由: - 迅速な環境でインフラ管理が本質的なエンジニアリングから気をそらす場合 - 複雑なWebhookペイロードのインスペクションとリプレイをリアルタイムで行いたい場合 - 内蔵のOIDC/SAML認証やレート制限を設定したい場合 - エージェント型ツールやMCP対応トラフィックポリシー、多プロバイダーのLLMルーティングをインフラ構築なしで行いたい場合 - UDPを必要としない場合

frpを選ぶ理由: - 完全なデータ主権を求め、暗号化されていない内部データストリームを第三者インフラに渡したくない場合 - カスタムApexドメインや専用TCP/UDPポートマッピング、高帯域幅のワークロードをメーター制のSaaSプランなしで運用したい場合 - UDPネイティブのプロトコル（ゲームサーバー、VoIP、IoT）をトンネリングしたい場合 - VPSの管理に自信があり、積極的に開発・リリースされているプロジェクトを望む場合

最終判定

ngrokとfrpの議論は、便利さと制御のトレードオフの古典です。ngrokは複雑なネットワークルーティングを抽象化したユーティリティに変え、2026年にはAIトラフィックルーティングやMCPゲートウェイの役割も拡大しています。これはエージェント型ワークフローを重視する場合に重要です。frpは所有権、UDPサポート、ライセンス制限なしの標準として、積極的に開発され続けるプロジェクトです。

---

変更履歴

誤りの修正（元の誤情報）: - frpのGitHubスター数は「108,000」と四捨五入されていましたが、現在の正確な数は107,000+スター（105k〜108kのスナップショット）と15,100+フォークです。これに更新。 - デプロイガイドのfrp v0.70.0は存在しません。公式リリースページで確認し、最新はv0.69.1（2026年6月）です。バージョンとダウンロードコマンドを更新。 - frps.toml例のvhostHttpPort / vhostHttpsPortは無効なキーです。正しいのはvhostHTTPPort / vhostHTTPSPortです。公式READMEに基づき修正。 - frpc.tomlの例のlocalIpはケースセンシティブで誤りです。正しいのはlocalIPです。修正済み。 - ngrokのUDP未対応は、ngrokの料金ページ（ngrok.com/pricing）で確認済みです。HTTP、TCP、TLSのみ対応。

新情報の追加: - ngrokの料金表を公式から最新の正確なものに更新（プラン名、価格、データ量、リクエスト数、対応プロトコル）。 - ngrokの2026年のAIゲートウェイとMCPゲートウェイ機能（Traffic Policyによるリクエスト認証、ngrok.aiのプロバイダールーティング・フェイルオーバー）を新たに解説。 - frpの新機能（正式な互換性ポリシー、wire protocol v2、動的プロキシ管理、SSHトンネルゲートウェイ、VirtualNetのα版）を詳細に追加。 - frpの長期計画の「v2」アーキテクチャ書き換えは別の大規模プロジェクトであり、現状は進行中と明記。 - デプロイガイドにfrpc verifyやfrpc reloadコマンドを追加し、実用的な補足としました。

構造の変更: - コード例のフォーマットを整え、適切なコードブロックに修正。 - 不要なメタデータやフォーマットアーティファクトを除去。

これらの修正と追加により、内容の正確性と実用性を高めています。