# Webhook、WebSocket、または RPC ポーリングの選択

> Source: https://docs.blockvectra.com/ja/guides/webhook-vs-websocket/

HTTPS 受信先への配信にはアドレス Webhook、対応しているリアルタイム購読には WebSocket、ワークフローに独自のカーソルと復旧が必要な場合には有界ポーリングを使用します。

開発者や AI エージェント向けのオンチェーンイベントリスナーを構築する際は、アプリケーションアーキテクチャをネットワーク機能、配信保証、受信側の制約、運用コストに適合させる必要があります。

## 決定マトリクス

以下の表は、サポートされるネットワーク機能、インフラ要件、復旧戦略、課金モデルの観点から、3 つの連携メカニズムすべてを比較したものです：

| 項目            | アドレス Webhook                                                                                                                      | WebSocket 購読                                                                                            | 有界 RPC ポーリング                                                                                                |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **主なメカニズム**   | パブリックエンドポイントへの HTTPS POST によるプッシュ通知配信                                                                                             | 持続的な TLS 接続（`wss://`）を介したプルストリーム購読                                                                      | クライアント起点の HTTP JSON-RPC バッチまたはスケジュールクエリ                                                                     |
| **利用可能なチェーン** | `GET /v1/push/chains` で宣言されているサポート対象の全 9 ネットワーク                                                                                   | Robinhood Chain（robinhood\_mainnet および robinhood\_testnet）でサポート。未提供のネットワークは `ws: false` で HTTP 404 を返却  | キー不要のパブリック RPC または認証付き JSON-RPC を介したサポート対象の全 9 ネットワーク                                                       |
| **受信側の要件**    | パブリックにアクセス可能な HTTPS URL、有効な TLS 証明書、タイムアウト以内の 2xx 応答、生ボディの HMAC SHA-256 署名検証                                                      | 送信 TCP/TLS クライアント接続（`wss://`）。ping/pong ハートビートと再接続バックオフを処理                                              | ステートレスな HTTP クライアントまたはスケジュールされたワーカー。ローカルのブロックカーソルを保存                                                        |
| **配信と順序付け**   | 指数バックオフ再試行を伴う at-least-once（少なくとも 1 回）配信。受信側はイベント `id`、または購読全体で `ref` + `type` による重複排除が必須                                         | 単一のアクティブソケット上での厳密に順序付けられたフレーム。切断中の通知は破棄                                                                 | 確認済みブロック高に対する確定的なプル応答。クライアントが実行ペースを制御                                                                       |
| **チェーンの再編成**  | `chain.reorg` の制御通知を発行。受信側は正規チェーンのリプレイを適用する前に置き換えられたイベントを破棄                                                                       | ログ通知は再編成されたログに対して `"removed": true` を保持。`newHeads` は親ハッシュのチェックが必要                                       | クライアントがポーリング間隔全体で `parentHash` のチェーン連続性を追跡して再編成を検出                                                          |
| **障害復旧**      | サーバーの保持期間内であれば `POST /v1/push/subscriptions/{id}/replay` によるリプレイが可能。有効化ブロックより前の欠落には `eth_getLogs` によるバックフィルが必要                    | サーバー側キューなし。クライアントが再接続し、`(blockHash, transactionHash, logIndex)` で重複排除しながら `eth_getLogs` で取り逃した範囲をバックフィル | 保存された `last_synced_block` からクエリを再開。ネットワークの `max_logs_block_range`（1,000 ブロック）ごとにチャンク分割                      |
| **課金モデル**     | グループ単位のアドレス日額料金（UTC 日のオンライン中の最大アドレス数に基づく）に加え、配信されたデータイベントの CU。詳細は [Webhook の課金](https://docs.blockvectra.com/en/guides/webhook-push/#billing-and-example) を参照 | ハンドシェイクとハートビートは無料。`eth_subscribe` / `eth_unsubscribe` およびソケット送信バッファにフラッシュされた通知ユニットは CU で課金              | リクエストごとに Compute Unit で計測：`eth_blockNumber`（1 CU）、`eth_call`（15 CU）、`eth_getLogs`（30 CU）。1 ドルあたり 1,000 万 CU |
| **最適な用途**     | ユーザーの入金監視、ホットウォレットのアドレス追跡、加盟店の決済処理、非同期イベント Webhook                                                                                | リアルタイムの `newHeads` とフィルタリングされた `logs`、リアクティブボット、サポート対象ネットワーク上の対話型 UI                                    | バッチ照合、cron ジョブ、ETL パイプライン、WebSocket 非対応のチェーン（HyperEVM など）                                                   |

## アドレス Webhook を選択すべきケース

バックエンドがインバウンド HTTPS リクエストを受信可能な標準 Web サービスとして稼働している場合は、[ブロックチェーン Webhook API](https://docs.blockvectra.com/en/guides/webhook-push/) を選択してください：

* **大規模なアドレスリスト**：ウォレットごとに持続的なソケットを維持することなく、数千もの顧客アドレスにわたる入金や出金を監視できます。
* **サーバーレスまたはコンテナ化された受信側**：サーバーレス関数（AWS Lambda、Cloudflare Workers など）は Webhook の受信時に起動するため、常時接続を維持し続ける必要がありません。
* **自動再試行とリプレイ**：受信側の一時的な障害は、自動再試行バックオフによって緩和されます。サーバーの保持期間内であれば、取り逃した配信をリプレイエンドポイントを使用して再配信できます。
* **有効化境界に関する考慮事項**：照合は購読の変更が適用された後（`applied_from_block`）にのみ開始されます。アドレスが追加される前や、購読が `offline` であった期間に発生したイベントは、過去の RPC ログから照会する必要があります。

本番環境で Webhook 受信側を公開する前に、[署名検証とリプレイのワークフロー](https://docs.blockvectra.com/en/guides/webhook-push/#verify-signatures) を確認してください。

## WebSocket 購読を選択すべきケース

低遅延が要求され、プロセスが長時間稼働する送信ソケットを維持できる場合は、[WebSocket 購読](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) を選択してください：

* **リアルタイムのブロックヘッダー**：チェーンヘッドに各ブロックが追加されるたびに `newHeads` をストリーミングします。
* **コントラクトイベントフィルター**：アドレスまたは特定の `topic0` に一致するリアルタイムのコントラクト `logs` をストリーミングします。
* **プライベート環境**：インバウンドのパブリック HTTPS ポートを公開できない、NAT やファイアウォールの背後にあるローカルスクリプト、CLI エージェント、バックエンドサービスに最適です。
* **ネットワークの対応状況の確認**：WebSocket は Robinhood Chain（ネットワークスラッグ `robinhood_mainnet`、Chain ID 4663、および `robinhood_testnet`）でサポートされています。HyperEVM は現在 WebSocket をサポートしていません（`ws: false`）。未提供のチェーンに WebSocket 接続を試行すると、HTTP 404（[`unknown_chain`](https://docs.blockvectra.com/en/errors/#unknown_chain)）が返されます。
* **切断時の対応規律**：切断をまたいで WebSocket の通知がサーバー側に保持されることはありません。ソケットが切断された場合、クライアントはランダム化された指数バックオフで再接続し、`eth_getLogs` を使用して取り逃したブロックをバックフィルする必要があります。

フィルターの制限、接続上限（キーあたり 20 接続、アカウントあたり 50 接続）、および viem の接続例については、[WebSocket 購読ガイド](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) を確認してください。

## 有界 RPC ポーリングを選択すべきケース

スケジュールされたワーカーやデータパイプラインを実行する場合、または WebSocket が利用できないネットワークで運用する場合は、有界 JSON-RPC ポーリングを選択してください：

* **WebSocket 非対応のネットワーク**：HyperEVM（`hyperevm_mainnet`）は現在 JSON-RPC HTTP アクセスを提供していますが、WebSocket には対応していません（`ws: false`）。サポートされているブロック範囲内で `eth_blockNumber` をポーリングし、`eth_getLogs` を照会することで、HyperEVM のイベント処理をサポートします。
* **制御されたクエリペース**：ポーリングにより、開発者や AI エージェントはリクエスト頻度を制御し、レート制限（無料アカウントではデフォルトでキーあたり 400 CU/s）に対する Compute Unit の消費を管理し、長時間稼働タスク中のソケット切断を回避できます。
* **ブロック範囲の制限**：認証付きの `eth_getLogs` クエリは、ネットワークの `max_logs_block_range`（1,000 ブロック）に制限されます。この制限を超えると、エラーコード `-32602`（[`logs_range_too_large`](https://docs.blockvectra.com/en/errors/#logs_range_too_large)）が返されます。より広い区間は、1,000 ブロックを超えない連続したチャンクに分割してください。

チャンク分割アルゴリズムについては、[HyperEVM ログバックフィルガイド](https://docs.blockvectra.com/en/guides/hyperevm-backfill/) および [eth\_getLogs ブロック範囲ガイド](https://docs.blockvectra.com/en/guides/getlogs-block-range/) を参照してください。

ワークロードの完全なチェックリストとセルフテストについては、まず [RPC プロバイダーの選び方](https://docs.blockvectra.com/en/guides/choose-rpc-provider/) をご覧ください。

少量のポーリングでプロバイダーを選ぶ際は、[標準的な RPC 課金とカバー範囲についてプロバイダーを比較](https://docs.blockvectra.com/en/guides/quicknode-alternative/) してください。従量課金とトライアルやサブスクリプションの費用を比較してください。通知とバックフィルのコストは RPC 読み取りとは異なるメーターを使用します。

## 実装ガイド

### Robinhood Chain での WebSocket

Robinhood Chain でリアルタイムの `newHeads` またはフィルタリングされた `logs` を取得するには、認証と購読リクエストについて [WebSocket 購読ガイド](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) に従ってください。切断後はバックオフを伴って再接続し、再購読して、保存されたカーソルから `eth_getLogs` で取り逃したブロックをバックフィルしてください。ログは `(blockHash, transactionHash, logIndex)` で重複排除します。

### HyperEVM での有界ポーリング

HyperEVM（`hyperevm_mainnet`）の場合は、有界ポーリングと復旧について [HyperEVM ログバックフィルガイド](https://docs.blockvectra.com/en/guides/hyperevm-backfill/) に従ってください。保存されたカーソルから `max_logs_block_range` 内のチャンクで照会し、処理が成功した後にイベントと進捗を一緒に永続化し、未完了の範囲を再試行してください。チェーンの連続性をチェックし、重複する範囲をスキャンして再編成を処理します。

## 次のステップ

* [データセットディレクトリを閲覧](https://blockvectra.com/en/data/) して、BlockVectra がインデックス化しているすべてのデータセットを確認できます。
* [無料プランと料金](https://blockvectra.com/en/pricing/#free) で、アカウントに含まれる内容を確認できます。
* [コンソールにログイン](https://console.blockvectra.com/login/?next=%2Fkeys%2F) して、API key を作成してください。