From Proxy to Gateway: Managing Multi-Tenant Webhooks on Localhost
外部の3つのサービスとローカルAPIを共有していますか？アプリ内でカスタムルーティングロジックを書くのはやめましょう。Webhooksを認証・ルーティングするために、Local API Gatewayトンネルを使う方法を学びましょう。
現代の開発では、ソフトウェアの構築は孤立したコードを書くことだけではありません。今日のアプリケーションはAIエージェントを調整し、Stripeを通じて支払いを処理し、Slackにリアルタイム通知を送信 — これらを同時に行います。これらの外部サービスはすべて、Webhooksを通じてあなたのローカル開発環境に通信します。
従来はこれが大きなボトルネックでした。開発者は単一のローカルトンネルを開き、すべてのサードパーティサービスを一つのエンドポイントに向け、アプリに複雑なルーティングと認証ロジックを書いて、着信トラフィックを処理していました。
その方法は終わりです。シンプルなリバースプロキシは進化しました。ここにLocal API Gateway — 高度なマルチテナントトンネルが登場し、localhost上でのWebhookルーティングの方法を根本的に変えます。
シングルポートトンネルの混乱
Local API Gatewayの価値を理解するには、まず従来のワークフローの痛みを理解する必要があります。
StripeやGitHub、AIモデル提供者のような外部プラットフォームがあなたのアプリにイベント通知を送るとき、HTTP POSTリクエストをあなたが指定したURLに送ります。あなたのノートパソコンはパブリックIPを持たないルーターの背後にあるため、トンネルサービスを使ってローカルポートをインターネットに公開します。
従来は、ポート3000を公開するコマンドを実行し、Node.jsアプリがインターネットの交通整理役を担うことになっていました。これにより、混乱がすぐに始まります。
ビジネスロジックの汚染。 アプリのコードは、/stripe、/slack、/githubなどのパスを検査し、適切な内部モジュールにルーティングしなければなりません。これはインフラ作業をアプリケーションコードに詰め込んだ状態です。
認証の悪夢。 各プロバイダーは異なる認証方法を使用します。StripeはHMAC-SHA256でペイロードに署名します。AIエージェントは一般的にJSON Web Tokens（JWT）を使います。あなたのアプリはこれらすべての秘密情報と検証ロジックを管理しなければなりません。
生のボディの問題。 Expressのようなフレームワークでは、標準のJSONパースミドルウェア（express.json()）はボディを解析し、生のバイト列を破棄します。これが署名検証に失敗する最も一般的な理由です。ペイロードが暗号ハッシュの計算前に変更されてしまうためです。開発者は複雑なexpress.raw()の回避策を書いてWebhookの検証を行います。
マイクロサービス間の摩擦。 ポート4000で支払いサービスを、ポート5000で通知サービスを動かしている場合、シングルポートトンネルはコード内にリバースプロキシを構築し、正しいローカルサーバにルーティングさせる必要があります。
すべてを単一のポートにルーティングすることで、アプリはゲートウェイ、ロードバランサー、ファイアウォールの役割を担います — これらは本来の設計範囲外です。
コンセプト：マルチテナントトンネルをローカルAPIゲートウェイとして
現代の解決策はLocal API Gatewayです。トンネルプラットフォーム — 特にngrokは、AIとAPIゲートウェイプラットフォームとして完全に再位置付けされ、トンネルのエッジで複雑なマルチテナントトラフィックルーティングを定義できるようになりました。これにより、トラフィックがコードに到達する前に認証とルーティングを行います。
Webhookの検証とルーティングロジックを各サービスに個別に実装する代わりに、WebhookゲートウェイはすべてのサードパーティWebhookのための単一で安全なエントリーポイントを提供します。トンネル自体が、ローカルマシン上で動作する完全なAPI Gatewayとして機能し、宣言的なYAMLファイルで設定されます。
ゲートウェイはリクエストがあなたのコードに届く前に次のことを行います：
- Webhookルーティング： HTTPリクエストのパスとヘッダーを検査し、ペイロードを異なるローカルポートやマイクロサービスにルーティング
- 暗号署名の検証： Stripe、Slack、GitHubなどのプロバイダーの署名をネイティブに理解し、無効な場合はリクエストを破棄します。
- JWT検証： 受信リクエストに含まれるJWTをインターセプトし、発行者と対象を設定と照合し、認証されていないトラフィックをエッジで拒否します。
これはパラダイムシフトです。アプリケーションコードはビジネスロジックの処理に専念し、ネットワーク、認証、ルーティングはゲートウェイに任せることができます。
深掘り：localhostでのWebhookルーティング
マイクロサービスアーキテクチャでは、ポート8080で支払いサービス、ポート8081で通知サービスを動かしていることがあります。Local API Gatewayを使えば、2つの別々のトンネルと2つの公開URLを設定する代わりに、宣言的なTraffic Policyファイルで構成できます。
ゲートウェイは受信リクエストのURLパスを検査し、次のようにルーティングします：
/stripeに着信したリクエストは支払いサービスに転送/slackに着信したリクエストは通知サービスにルーティング
このパターンのngrok Traffic Policy設定例は以下の通りです：
on_http_request:
- expressions:
- req.url.path.startsWith('/stripe')
actions:
- type: verify-webhook
config:
provider: stripe
secret: "${STRIPE_WEBHOOK_SECRET}"
- type: forward-internal
config:
url: https://payment-service.internal
- expressions:
- req.url.path.startsWith('/slack')
actions:
- type: verify-webhook
config:
provider: slack
secret: "${SLACK_SIGNING_SECRET}"
- type: forward-internal
config:
url: https://notification-service.internal
このアプローチの魅力は、本番環境と同じ構成をローカルでも実現できる点です。実運用ではIngressコントローラーやクラウドのAPIゲートウェイを使いますが、Local API Gatewayを使えば、ローカル開発環境と本番環境のアーキテクチャの整合性を保てます。
ネイティブWebhook署名検証
最も重要なワークフロー改善の一つは、ネイティブなWebhook署名検証です。これにより、Express開発者が悩む生のボディ問題を解決します。
StripeやGitHubのようなプロバイダーは、ペイロードが改ざんされていないことを証明するために共有秘密鍵で署名します。署名の検証には厳格な暗号ロジックが必要です。HMAC署名を再計算し、一定時間内のタイムスタンプを検証し、リプレイ攻撃を防ぎます。
例えば、Expressで生のボディをキャプチャしないと署名検証が失敗します。
現代のLocal API Gatewayはこのエラーのクラスを排除します。ngrokのWebhook Gatewayは、Webhook署名を中央で検証し、不正なリクエストをルーティング前に排除します。2025年時点で、ngrokは70以上のプロバイダー（Stripe、Twilio、Slack、GitHub、Shopify、DocuSignなど）に対応した検証アクションを提供しています。
あなたはプロバイダーの秘密を設定し、署名が有効ならゲートウェイは暗号ヘッダーを除去し、検証済みのクリーンなJSONペイロードをアプリに送ります。署名が無効なら自動的にリクエストを拒否します。アプリのログはクリーンになり、有効なビジネスイベントだけが記録されます。
JWT検証プロキシ
AIエージェントやカスタムクライアントアプリケーションの普及に伴い、インバウンド認証の管理が重要になっています。多くのAPIやエージェントフレームワークはOAuth 2.0、OpenID Connect（OIDC）、API認証フローにJWTを利用します。
従来はJWTライブラリを各サービスに導入し、JWKSを取得し、トークンを解析し、署名を検証し、クレームを抽出していました。3つのマイクロサービスがあれば、そのオーバーヘッドも3倍です。
この問題を解決するのがマルチテナントトンネルのJWT検証プロキシです。最新のゲートウェイツールは複数の発行者を指定でき、リクエストは任意の発行者のJWTで署名されていれば検証されます。トークンはAuthorizationヘッダーから取得され、Bearerプレフィックスを除去し、ペイロードを検証します。
トークンが無効、欠落、期限切れの場合、ゲートウェイは即座に401 Unauthorizedを返します。ローカルアプリは未認証のトラフィックを受け取りません。
ゲートウェイはJWKSリストをキャッシュし、パフォーマンスを向上させます（約15分ごとに更新）。これにより、毎回キーを手動で取得する必要がなくなります。
この仕組みのメリットは次の通りです：
- 認証の強制をネットワーク層で行う
- バックエンドの負荷軽減 — 未認証リクエストは事前に拒否
- ライブラリ不要 — JWTライブラリの管理や更新が不要
WAF層：OWASP CRSとCoraza
2025年12月にngrokは、OWASP Coraza WAFエンジンをTraffic Policyシステムに統合したことを発表しました。これにより、すべてのリクエストに対して攻撃検出を行い、1.2%のトラフィックをブロックしています。
CorazaはGoで書かれた高性能なオープンソースWAFエンジンで、OWASP Core Rule Set（CRS）を実行します。CRSはSQLインジェクションやクロスサイトスクリプティング（XSS）、PHPやJavaのコードインジェクション、Shellshockなどの攻撃に対して保護します。
ngrokの実装では、CRSのリクエストとレスポンスフェーズに対応するowasp-crs-requestとowasp-crs-responseの2つのTraffic Policyアクションを追加しています。これにより、YAMLの数行でエンタープライズレベルの攻撃検出を有効にできます：
on_http_request:
- actions:
- type: owasp-crs-request
config:
mode: block
このWAFはドライラン検出モードもサポートしており、本番展開前に誤検知を確認できます。すべてのブロック決定はアクション結果変数で確認でき、拒否理由も把握可能です。
これにより、ローカル開発環境でも本番と同じWAFルールセットを実行でき、展開後にのみ現れるセキュリティのリグレッションを排除します。
エージェントAIとMCPゲートウェイ
2026年に入り、自治型AIエージェントの台頭により、ゲートウェイの重要性が増しています。ngrokのエンジニアリングチームは2026年4月に次のように述べています：“2025年、AIゲートウェイはLLMトラフィックを管理。2026年、自治エージェントも管理。”
これはアーキテクチャの変化です。単一のユーザーリクエストが20〜50のLLM呼び出しやツール呼び出し、多段階推論チェーンをトリガーします。エージェントはSlackやNotion、データベース、内部APIと通信し、Model Context Protocol (MCP)サーバーを通じて連携します。これらの接続は認証、監査、レート制限が必要です。
ngrokは公式にMCPゲートウェイとしての利用をサポートし、次のことが可能です：
- ローカルのMCPサーバーをクラウドAIエージェントに永続的に公開
- IPホワイトリスト制御（例：特定のIPのみ許可）
- ツール呼び出しの監査と変換
以下はMCPサーバー用のngrok設定例です：
version: 3
agent:
authtoken: <your_ngrok_authtoken>
endpoints:
- name: mcp-server
url: https://mcp.example.internal
upstream:
url: http://localhost:8787
これは一般的なHTTPトンネルの課題と同じです。エージェント指向のワークフローは、永続的なサブドメイン、Server-Sent Events（SSE）による並列ストリーミング、ローカルマシンの再起動後も生き続けるエンドポイントを要求します。専用のゲートウェイインフラはこれらをネイティブに処理します。
トラフィックシェーピング、可観測性、リプレイ
マルチテナントトンネルは、ルーティングや認証だけでなく、Webhookの非同期性を伴うデバッグに役立つ堅牢な開発者体験も提供します。
トラフィックインスペクター
最新のLocal API GatewayにはリアルタイムのトラフィックインスペクターUIが付属します。ローカル開発中にWebhookペイロードの検証やリクエストヘッダーの確認、統合問題のトラブルシューティングが可能です。
重要なのは、アプリがクラッシュしたり、パースロジックにバグがあった場合でも、StripeやGitHubのダッシュボードに新たなイベントをトリガーする必要はありません。インスペクターからWebhookリクエストをリプレイでき、ヘッダーやボディの変更も可能です。
追加のトラフィック制御
- レート制限： Webhookプロバイダーは大量のイベントを送信します。ゲートウェイはトラフィックを制御し、ローカルアプリの負荷を軽減します。
- ヘッダー操作： ゲートウェイは、検証済みのJWTクレームなどのメタデータを含むカスタムヘッダーを挿入して、アプリに渡すことができます。
- 動的ルーティング： ngrokのTraffic PolicyはCommon Expression Language (CEL)を使い、
https://${req.headers('X-Custom-Header')}.internalのような動的ヘッダーベースのルーティングを可能にします。 - 地理的ルーティングとコンプライアンス： 同じインフラは、特定の地域ポイントを通じたトラフィック流通もサポートし、ローカル開発から本番まで一貫した運用が可能です。
最新ワークフローの構築
以下は今日のエンドツーエンドの開発者ワークフローです。
1. ローカルサービスを起動。 Node.jsで請求サービスをポート3000に、Goでユーザー管理サービスをポート4000に起動します。
2. Traffic Policyを定義。 YAMLファイルにゲートウェイの挙動を記述します：
on_http_request:
- expressions:
- req.url.path.startsWith('/api/billing')
actions:
- type: verify-webhook
config:
provider: stripe
secret: "${STRIPE_SECRET}"
- type: forward-internal
config:
url: https://billing.internal
- expressions:
- req.url.path.startsWith('/api/users')
actions:
- type: jwt-validation
config:
issuer:
allow_list:
- value: "https://your-auth0-tenant.auth0.com/"
audience:
allow_list:
- value: "https://your-api.example.com"
- type: forward-internal
config:
url: https://users.internal
3. ゲートウェイを起動。 YAML設定をngrokに渡し、公開トンネルURLをバインドします。
4. プロバイダーにURLを設定。 StripeやSlack、GitHubなどのWebhookに公開URLをPOSTさせます。
5. 安心して開発。 ゲートウェイはすべてのトラフィックをインターセプトし、暗号化を検証し、パスを整理し、認証済みのクリーンペイロードを適切なマイクロサービスに配信します。検証に失敗したリクエストは自動的に4xxレスポンスを返し、Traffic Inspectorに記録されます。
アプリのログはクリーンです。有効なビジネスイベントだけが記録されます。
競合環境
ngrokはこの分野の唯一のプレイヤーではありませんが、2026年時点でのリファレンス実装です。:
- Kong AI Gateway（v3.14、2026年4月）は、MCPとエージェント間（A2A）トラフィックをサポートし、すべてのAIトラフィックタイプの統一制御プレーンとして位置付けられています。Gartnerの*Emerging Tech Adoption Radar 2026*では、AIゲートウェイがエージェントワークロードの可視性と制御を支援すると評価されています。
- Traefikは、Kubernetesネイティブの展開をターゲットにしたタスクベースのアクセス制御を持つMCP Gatewayをリリースしました。
- Cloudflare AI Gatewayは、巨大なスケールのログ（1億以上）を持つエッジレベルの可観測性を提供します。
- InstaTunnelは、個人開発者向けにより寛容な帯域幅を持つ無料の代替手段として登場しましたが、ngrokのエンタープライズグレードの可観測性には及びません。
これらの共通点は、シンプルなリバースプロキシは2026年の開発ワークフローには不十分であり、業界はゲートウェイモデルに収束していることです。
結論：ゲートウェイを採用しよう
シンプルなリバースプロキシの時代は終わりました。WebhookプロバイダーやAIエージェント、MCPサーバー、OAuthフローの複雑さが増す中、未認証の生トラフィックを直接アプリに流すのは、技術的負債とセキュリティリスクの原因です。
Local API Gatewayは、あなたのローカル開発環境に本番クラスの堅牢性をもたらします：
- アプリ内のカスタムルーティングロジックは不要
- HMAC検証のためのExpressボディパーサとの戦いも不要
- 各マイクロサービスでJWTライブラリを複製する必要もなし
- 再現できないWebhookイベントによる手動デバッグも不要
高トラフィックWebhookやMCP経由のAIエージェント認証、ローカルマイクロサービス間のトラフィックルーティングなど、すべて本番環境と同じインフラをローカルに持ち込むためのツールです。
出典： ngrok Webhook Gatewayドキュメント · ngrok AI Gateway 2026 · ngrok WAF with OWASP CRS and Coraza · ngrok MCP Gatewayドキュメント · Kong Agent Gateway発表
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.