Ngrok vs. Hookdeck CLI: 純粋なWebhook専用ツールの比較

現代のアプリケーション設計はイベント駆動アーキテクチャに大きく依存しています。Stripe、Shopify、GitHub、TwilioなどのサードパーティAPIは、重要なデータを非同期HTTP POSTリクエスト（Webhook）を通じて内部システムに送信します。従来、ローカル開発環境はファイアウォールやルーター、NATによってインターネットから隔離されていました。これを回避し、http://localhostでWebhookペイロードを受信するために、エンジニアリングチームは伝統的にngrokを利用してきました。業界標準のトンネリングツールであるngrokは、トラフィックをローカルの開発ポートに直接ミラーリングする公開URLを作成します。

しかし、ngrokはWebhookを単なるHTTPストリーム内のペイロードの一つとして扱います。アプリケーションが分散マイクロサービスやノイジーなイベントネットワーク、より厳格な信頼性要件に移行するにつれ、汎用トンネルの限界が顕著になってきました。

一方、Hookdeck CLIは異なるアプローチを取ります。単なるネットワークパイプとして動作するのではなく、Webhook専用のイベントゲートウェイとして設計されており、ローカルトンネリングもその機能の一つです。このガイドでは、アーキテクチャ、運用、ワークフローの観点から両者を比較し、比較コンテンツで流布しているいくつかの誤った主張を正します。

アーキテクチャのパラダイム：オープントンネル vs. サブスクリプションストリーム

ngrokの動作：オープンインフラストラクチャトンネル

ngrok http 3000を実行すると、ngrokエージェントはngrokのクラウドインフラに長時間持続するアウトバウンド接続を確立します。ngrokは公開URLを割り当て、そのエンドポイントに送信されたすべてのパケットを接続経由でローカルポートに転送します。

[Webhookソース] --- [ngrokクラウドエッジ] ===(カプセル化されたトンネル)=== [ngrokエージェント] --- [ローカルサーバ:3000]

このモデルでは:

• レイヤー: Layer 4（TCP/TLS）またはLayer 7（HTTP）のリバースプロキシとして機能し、2026年時点では、ルーティングや書き換え、アクセス制御を行うYAMLベースのTraffic Policy層を持つ「ユニバーサルゲートウェイ」に拡張されています。
• スコープ: トンネルは、そのローカルポートで待ち受けているものを公開します。フレームワークが10のルートを提供している場合、トンネルをスコープまたはTraffic Policyルールで制限しない限り、すべてのルートにアクセス可能です。
• 状態: ポリシー未設定の場合、リアルタイムでトラフィックを流すステートレスストリームとして動作します。

Hookdeck CLIの動作：Webhookサブスクリプションストリーム

Hookdeckは、サードパーティのプロバイダーとローカルマシンの間に位置する非同期イベントブローカーとして機能します。純粋なネットワークのバイパスではありません。

                                                                                       +--- [開発マシンA: ポート4000]
[Webhookソース] --- [Hookdeckイベントゲートウェイ（キュー／ブローカー）] ===(CLIストリーム)=== |--- [開発マシンB: ポート4000]
                                                                                     +--- [開発マシンC: ポート5000]

hookdeck listen 4000 <source-nameを実行すると、単にポートをパイプするだけでなく、Hookdeckプロジェクト内に3つの抽象化を作成します:

• Source: 上流プラットフォームにマッピングされた永続的な追跡エンドポイント（例：stripe-webhooks）。CLIはhkdk.events下に永続的なURLを割り当て、再起動後も同じURLを維持します。
• Destination: ローカルターゲット（例：http://localhost:4000）を指す定義。
• Connection: SourceとDestination間のバインディング — 状態を持つ、隔離されたサブスクリプションストリームであり、純粋なパイプではありません。

WebhookがHookdeckエッジに到達すると、即座に認識されキューに入り、その後サブスクライブしているローカルCLIセッションに配信されます。ローカルサーバがクラッシュしたりブレークポイントで停止した場合でも、イベントはキューに残り続け、ドロップされません。Hookdeckのドキュメントではこれを「少なくとも一度配信保証」として、耐久性のあるキューイングによる保証と説明しています。

最初に訂正しておきたい点：CLIのフォワーディング機能を使うには無料のHookdeckアカウント（hookdeck login）が必要です — 一部の比較ページで示されるようなアカウント不要ではありません。HookdeckのnpmやGitHubのドキュメントによると、CLIの利用においては、ローカル開発用のイベントURLに制限やクレジットカード情報は不要です：”無制限の無料かつ永続的なイベントURL”が提供されます。

技術比較マトリクス

機能	ngrok	Hookdeck CLI
コアアーキテクチャ	汎用L4/L7リバースプロキシ、AI/APIゲートウェイへ拡張中	Webhook専用イベントゲートウェイ
トンネルの状態	デフォルトはステートレスの転送	状態を持つ（取り込み、キューイング、管理）
URLの安定性（無料層）	アカウントごとに自動割り当ての開発用ドメインがあり、再起動後も維持。ただしカスタマイズ不可。TCPアドレスはカード検証しない限りランダム割り当て	プロジェクトごとに永続的なSource URLを提供（カード不要）
トラフィックフィルタリング	Traffic Policy（YAMLルール言語）によるエッジレベルの制御（Webhookペイロード認識ではない）	ヘッダー、本文、パス、クエリに対するネイティブな詳細フィルタ（CLIフラグまたはダッシュボード）
ファンアウト／ルーティング	主に1:1。複数宛てのファンアウトはワイルドカードエンドポイントのforward-internalTraffic Policyアクションで可能だが、手動設定が必要	ネイティブの1:多ファンアウト — 1つのSourceが複数のConnections/Destinationsに配信
チームの隔離	FreeおよびHobbyistは1人、Pay-as-you-goは無制限メンバー（3人含む）	各開発者が共有Sourceに対して個別のCLIセッションを持ち、セッションレベルのフィルタリング（例：クエリパラメータやヘッダーによるルーティング）で管理し、再設定不要
デバッグインターフェース	localhost:4040のWebダッシュボードとリクエストリプレイ	TUI（ターミナルUI）とHookdeck Webコンソールの両方を備えたインタラクティブなフルスクリーンCLI（--output interactive）
リトライ／リプレイ	ローカルダッシュボードから手動リプレイ	CLIのrキーによる即時リトライと自動リトライルール
AIエージェント連携	CLIにはなし（ngrokは別途MCP関連ツールを提供）	MCPサーバー（hookdeck gateway mcp）を内蔵し、11のツールを提供

コアの差別化ポイント

1. 詳細なイベントフィルタリング vs. Firehose露出

Stripeの支払いはpayment_intent.created、customer.updated、charge.succeeded、invoice.createdなどを短時間で連続してトリガーします。charge.succeededだけをデバッグしたい場合、単純なトンネルはすべてを転送し、リクエストはローカルサーバに届きますが、CPU負荷やログの雑多さを招きます。これを避けるために、Hookdeck CLIはlistenコマンドのフラグとして直接フィルタリングをサポートし、実際の構文に一致します:

hookdeck listen 4000 stripe-webhooks --filter-body '{"type": "charge.succeeded"}'

CLIはまた、--filter-headers、--filter-query、--filter-pathもサポートし、リクエストの他の部分に対してマッチング可能です。マッチしないイベントはゲートウェイで除外され、端末やローカルサーバには届きません。これにより、デバッグセッションがテスト対象のペイロードに集中できます。

(注：--pathは別のフラグであり、ローカルサーバへのフォワーディング先を設定します（例：--path /webhooks/stripe）。これはフィルタではなく、スクリプト時に混同しないよう注意が必要です。）

2. マルチターゲットファンアウトによるマイクロサービスアーキテクチャ

ECサイトのチェックアウトを例に考えます。完了した注文Webhookは、フルフィルメントサービス、分析パイプライン、通知システムの3つの異なるローカルポートに届く必要があります。単純なトンネルでは、プロバイダーに登録された公開URLを3つ用意するか、ペイロードを複製・ルーティングするリバースプロキシスクリプトを自作する必要があります（ネイティブに複数エンドポイント登録をサポートしない場合）。

                                 +--- Destination 1: http://localhost:5001 (フルフィルメント)
[Stripe単一ソースURL] ---|--- Destination 2: http://localhost:5002 (分析)
                               +--- Destination 3: http://localhost:5003 (通知)

Hookdeckはこれをネイティブパターンとして扱います。1つのSourceが複数のConnectionsにマッピングされ、それぞれが異なるDestinationにフィルタや変換を独立して行います。

3. ネイティブなチームワークフロー

複数の開発者がStripeやShopifyのステージングアカウントを共有している場合、登録済みWebhook URLの制御を巡って競合が起きやすいです。Developer Aが自分のトンネルに設定すると、他の開発者のセッションが壊れることがあります。

Hookdeckのドキュメントでは、これに対する具体的な解決策として、各開発者が同じ共有Sourceに対してhookdeck listenを個別に実行し、セッションレベルのフィルタ（例：クエリパラメータやヘッダーによるルーティング）を設定することで、各自のイベントだけを受信できる仕組みを紹介しています。

デバッグ：ターミナルUI vs. Webダッシュボード

ngrokはhttp://127.0.0.1:4040のローカルダッシュボードを提供し、インバウンドリクエストのヘッダーや本文を全て表示、キャプチャしたリクエストを再送する”Replay”ボタンもあります。ブラウザタブに分かれているため、ターミナルからは離れた場所にあります。

Hookdeck CLIはデフォルトでインタラクティブなフルスクリーンターミナルUIを実行します（--output interactive）。また、compactやquietモードも起動時のフラグとして用意されており、これらはセッション中の切り替えではなく、起動時に設定します。実際のセッション例は以下の通り:

●── HOOKDECK CLI ──● 1つのソースを待ち受ける • 1つのコネクション • [i] 折りたたみ
Shopifyソース │ リクエスト先 → https://hkdk.events/src_...
              └─ 転送先 → http://localhost:3000/webhooks/shopify/orders

イベント • [↑↓] ナビゲート
─────────────────────────────────────────────────────────
 2026-07-10 14:42:55 [200] POST /webhooks/shopify/orders (34ms)

✓ 最後のイベント成功 | [r] リトライ • [o] ダッシュボードで開く • [d] データ表示

ドキュメントに記載されたキーバインドは：↑/↓（またはvimスタイルのj/k）でナビゲート、rで選択したイベントをローカルサーバに即時リトライ、dでリクエスト／レスポンスの詳細をインライン表示、oでHookdeckのWebコンソールでイベントを開き、詳細なトレースを行います。rを使ったリトライは、プロバイダーからの再送を待たずにペイロードを再現するため、StripeやShopifyの再送待ち時間を短縮できます。

MCPを利用したAI駆動ワークフロー

Hookdeck CLI v2（2026年3月リリース）は、組み込みのMCPサーバーを追加しました。起動コマンドは:

hookdeck gateway mcp

これは直接実行せず、MCPクライアント（Claude Desktop、Cursorなど）がサブプロセスとして起動します:

{
  "mcpServers": {
    "hookdeck": {
      "command": "hookdeck",
      "args": ["gateway", "mcp"]
    }
  }
}

Hookdeckのリリースノートによると、このサーバーは11のツールを公開しています：projects、connections、sources、destinations、transformations、requests、events、attempts、issues、metrics、helpです。これらは主に読み取りと検査用で、「何が失敗し、なぜか？」に答えるためのツールです。connectionsツールだけ書き込み可能で、接続の一時停止や再開が可能です。未認証の場合は自動的にhookdeck_loginツールが現れ、認証後に消えます。

Hookdeckの公式例として、エージェントが全体のメトリクスを取得し、失敗率の高い接続（例：shopify-orders → fulfillment-service）を特定し、失敗したイベントとその配信試行を調査し、422エラーを返す特定の宛先サービスの根本原因を追跡します。修正（フィルタルール）はCLI操作で行い、エージェントがあなたに渡します。

(補足：ngrokは独自のAI関連機能セットを持ち、MCPサーバーをゲートウェイ経由で公開できるマーケティングもありますが、Hookdeck CLIのMCPサーバーはWebhook配信のヘルスインスペクションに特化しています。)

料金体系の概要

2026年中頃の各ベンダーの公式料金ページに基づく最新情報です。

ngrok（ngrok.com/pricing）:

プラン	価格	主な制限
無料	$0	3エンドポイント、1GB/月データ転送、20kリクエスト/月、HTTPエンドポイントに警告ページ、1人のチームメンバー
Hobbyist	$8/月（年払い）、$10/月（月払い）	3エンドポイント、5GBデータ、100kリクエスト、警告ページなし、ngrokブランドドメイン
Pay-as-you-go	$20/月基本＋使用量	無制限エンドポイント、独自ドメイン、無制限メンバー（3人含む）、SSO/RBAC追加可能

注意点：一部の比較記事では無料プランのセッションタイムアウトを2時間と誤解しているケースがありますが、ngrokの公式ドキュメントでは、無料エンドポイントはタイムアウトなしで無期限に動作可能と明記されています（バックグラウンドサービスとして動作）。実際の制約は1GB/月の帯域幅、20kリクエスト制限、警告ページの強制表示です（ヘッダーや有料プランで解除可能）。

Hookdeck（hookdeck.com/pricing、Event Gateway用、CLIのローカル開発用は無料）:

プラン	価格	主な制限
開発者（無料）	$0	10,000イベント/月、3日保持、1ユーザー、クレジットカード不要
チーム	$39/月（基本）	追加イベントは約$0.33/10万件、無制限ユーザー、7日保持
成長	$499/月	SLA、SSO/SAML/SCIM、Datadogエクスポート、30日保持

Hookdeckの公式サイトでは、基盤となるEvent Gatewayの稼働率目標を99.999%と掲げています。これはベンダーの主張であり、独立監査済みの数値ではありませんが、公式サイトに明記されています。

本番環境対応：ローカル開発からエンタープライズまで

ローカルトンネルの一般的な課題は、本番移行時の対応です。ngrokは主に開発や臨時公開向けに設計されており、本番利用にはリトライロジックやレート制限、署名検証を追加する必要があります。あるいは、ngrokの本番向けゲートウェイ機能を利用して一部を実現します。

Hookdeckは、同じSource/Connection/Destinationモデルをそのまま使い続け、Destinationを本番URLに変更するだけです。Hookdeckのリトライドキュメントによると、1イベントあたり最大50回の自動リトライが設定されており、最大1週間のリトライウィンドウも設定可能です。StripeやShopifyのリトライスケジュールより積極的です。リトライを使い果たしたイベントは「Issues」としてグループ化され、SlackやPagerDutyのアラートとともに、問題解決後に一括リトライされます。

最終評価

• ngrokを選ぶべきとき：ローカルサーバを素早く公開したいとき、Webhook特化ではないHTTP/TCP/TLSトラフィックをテストしたいとき、またはほぼすべてのプロバイダーの導入ガイドに登場する最もドキュメント化されたトンネリングツールを使いたいとき。
• Hookdeck CLIを選ぶべきとき：ノイジーまたは高ボリュームのWebhookストリームをフィルタリングしてデバッグしやすくしたいとき、複数のローカルサービスに1つのイベントをファンアウトしたいとき、チームで共有のWebhookソースを使い、トンネルの競合を避けたいとき、またはローカル開発のワークフローを本番に持ち込みたいとき。

---

変更履歴

2026年7月時点の各ベンダーの最新ドキュメントに基づき、修正・追記を行いました:

• ngrok無料層のURL安定性：元の草稿では「エフェメラルで、エージェント再起動ごとに変わる」と記載していましたが、ngrokの公式ドキュメントでは、無料層は1つの自動割り当ての開発用ドメインを持ち、再起動後も維持されると明記されています（ただしカスタマイズ不可）。TCPアドレスはカード検証しない限りランダムです。
• ngrok無料層のセッションタイムアウト：2時間のタイムアウトに関する記述を削除。ngrokの公式ドキュメントでは、無料エンドポイントはタイムアウトなしで無期限に動作可能と明示しています（バックグラウンド動作）。
• ngrokの料金プラン：古いサードパーティ情報を削除し、公式のプラン名と価格（無料、Hobbyist $8/月年払いまたは$10/月月払い、Pay-as-you-go $20/月）に更新。
• Hookdeckの「アカウント不要」表記：誤りを修正。CLI利用には無料のHookdeckアカウント（hookdeck login）が必要です。
• Hookdeck CLIのフィルタコマンド例：--pathはパス設定用のフラグであり、フィルタではありません。実際のフィルタフラグ（--filter-body等）に修正。
• Hookdeck TUIのキーバインド：rリトライ、d詳細表示、oダッシュボードで開く、i折りたたみ／展開に修正し、起動時フラグ（compact、quiet）と区別。
• ngrokのトラフィックフィルタリング：純粋なフィルタではないが、Traffic Policy層によりエッジでのフィルタや書き換えが可能と追記。
• ngrokのファンアウト：ワイルドカードエンドポイントとforward-internalTraffic Policyアクションにより、多宛先ルーティングも可能と追記。
• Hookdeck MCPツールの説明：11のツールを確認し、connectionsは書き込み可能な唯一のツールであることを明記。hookdeck_loginは自動的に現れることも追記。
• 料金情報の追加：両ツールの最新料金体系を追記。
• 不要な記述の削除：第三者の推測や未検証の数値は除外。

参考資料

• ngrok Pricing — https://ngrok.com/pricing
• ngrok Pricing and Limits docs — https://ngrok.com/docs/pricing-limits
• ngrok Free Plan Limits — https://ngrok.com/docs/pricing-limits/free-plan-limits
• Hookdeck CLI reference — https://hookdeck.com/docs/cli
• Hookdeck CLI GitHub — https://github.com/hookdeck/hookdeck-cli
• Hookdeck CLI v2 (MCP) announcement — https://hookdeck.com/blog/hookdeck-cli-v2
• Hookdeck March 2026 changelog — https://hookdeck.com/blog/hookdeck-review-march-2026
• Hookdeck Retries docs — https://hookdeck.com/docs/retries
• Hookdeck Pricing — https://hookdeck.com/pricing
• Hookdeck localhost testing guide — https://hookdeck.com/docs/use-cases/test-debug-localhost