Your Trading Bot Shouldn't Poll: Webhooks for Hyperliquid Alerts

By @CoinMarketMan - 26-Jun-2026

トレーディングボットはポーリングをやめるべき: Hyperliquid アラートのための Webhook

5秒ごとに、ボットがサーバーに問い合わせる。「何か新しいことはある?」ない。「何か新しいことはある?」ない。「何か新しいことはある?」まだない。そしてWhaleコホートがBTCでネットロングに転換した瞬間、すぐに掴まなければならないムーブなのに、次のポーリングは4秒後だ。その遅れがエントリーを逃させる。

これがトレーディングアラートにRESTポーリングを使う根本的な問題だ。機能はするが、2分おきにポストを確認しに行くのと、郵便配達員がドアベルを鳴らすのとの違いに似ている。分析ダッシュボードや過去データのクエリにはポーリングで十分だ。しかしHyperliquidでのイベント駆動型トレーディングでは、コホートのシフトや清算クラスターが数分で市場を一変させることがある。ドアベルが必要だ。

そのドアベルがWebhookだ。Hyperliquidの市場状況に反応するものを構築しているなら、Webhookをいつ使うべきか(そしてポーリングの方が実は適しているのはどんな時か)を理解することで、無駄なAPIコールを省き、コードをシンプルにし、反応速度を上げることができる。

ポーリングのコスト: なぜボットはレートリミットを無駄に消費するのか

RESTポーリングはほとんどのトレーディングボットのデフォルトアーキテクチャであり、理由は明快だ。シンプルだからだ。ループを書き、N秒ごとにGET /cohort-metricsを呼び、レスポンスを前回と比較し、変化があれば動く。10行のコード、ボット以外のインフラは不要だ。

しかしシンプルさには隠れたコストがある。3つのエンドポイント(コホートポジション、清算リスク、資金調達レート)を60秒ごとにポーリングすると、1日あたり4,320件のAPIリクエストになる。月5万リクエストのPulseプランでは、ポーリングだけで約11日で枠を使い切ってしまい、スポットクエリや過去データ分析に使えるリクエストが残らない。

本当の問題は無駄だ。その4,320件の日次リクエストの大半は同じデータを返す。コホートポジションが毎分変わるわけではない。清算リスクのしきい値が常に発動するわけでもない。何も起きていないことを繰り返し確認するために、レートリミット枠とサーバー負荷を消費しているのだ。

Polling Vs Webhooks

Webhookがモデルを逆転させる

Webhookはボットとデータソースの関係を逆転させる。タイマーでボットが「何か変わった?」と問い合わせる代わりに、サーバーにURL(自分のエンドポイント)を渡し、「気にしていることが起きたらこのアドレスにPOSTして」と伝える。サーバーが監視を担い、ボットは反応することに専念する。

Hyperliquid分析において、Webhookで設定すべきイベントは、トレーディングの意思決定に実際に影響するものだ:

コホートポジションのシフト: Smart Money(生涯PnL +$100K〜+$1MのウォレットグループS)がETHでネットショートからネットロングに転換
清算リスクのしきい値: 設定した深刻度レベルを超えたアセットレベルの清算エクスポージャー
資金調達レートの急騰: 設定したしきい値を超えるレートのスパイク(偏ったポジションのシグナル)
大口ポジションの変化: WhaleまたはLeviathanコホートによる大きなポジションの開閉

これらのイベントはまばらにしか発生しない。毎秒でも、毎分でもない。だからこそポーリングは非効率であり、Webhookが自然な選択だ。ボットは設定した条件が発動する瞬間まで待機し(APIコールをゼロ消費で)、POSTを受け取り、シグネチャを検証し、ロジックを実行する。

Webhookアラートフローの実際の仕組み

アーキテクチャは単純だが、細部が重要だ。市場イベントからボットのアクションまでのシーケンスを示す:

市場イベントが発生する。 Whaleコホートのウォレット群(パープエクイティ $500K〜$1M)が集団でBTCポジションをネットショートからネットロングに転換する。
HyperTrackerがシフトを検出する。 データパイプラインが次のリフレッシュサイクルでコホートの状態変化を処理し、設定したWebhookルールと照合する。
Webhookが発動する。 登録済みエンドポイントに、イベントタイプ、アセット、コホート、方向、規模を含むJSONペイロードを持つPOSTリクエストが届く。
ハンドラーが検証して動く。 HMACシグネチャを確認し、ペイロードを解析し、構築したロジックを実行する: ポジションを開く、ダッシュボードを更新する、Telegramアラートを送る、またはその三つすべてを行う。

Webhook Flow

ハンドラーがすべきこと

Webhookを受け取るのは簡単だ。確実に処理するところで多くのビルダーがつまずく。エンドポイントに必要なのは:

シグネチャの検証。 すべてのWebhookにはHMACシグネチャヘッダーが含まれるべきだ。ペイロードを処理する前に共有シークレットと照合して検証する。このステップを省くと、エンドポイントのURLを知った誰もが偽のイベントを送れてしまう。
素早いレスポンス。 数秒以内に200ステータスを返す。ハンドラーがコストの高い処理(トレードの発注、モデルの実行)を行う必要がある場合、まずWebhookを受け付けてから、ジョブキューを使って非同期に処理する。
重複の処理。 ネットワーク障害が再送を引き起こすことがある。同じイベントがボットを二度起動させないよう、べき等性ロジックを実装する。シンプルな方法: ペイロードをハッシュ化し、短命キャッシュと照合し、既出なら処理をスキップする。
すべてをログに残す。 Webhookペイロードは一過性だ。処理してしまえば、保存しない限り消えてしまう。デバッグとバックテストのためにタイムスタンプ付きで受信したイベントをすべてログに記録する。

# 最小構成のWebhookハンドラー (Python / FastAPI)
from fastapi import FastAPI, Request, HTTPException
import hmac, hashlib

app = FastAPI()
WEBHOOK_SECRET = "your_shared_secret"

@app.post("/webhook/alerts")
async def handle_alert(request: Request):
    body = await request.body()
    signature = request.headers.get("X-Signature")

    expected = hmac.new(
        WEBHOOK_SECRET.encode(), body, hashlib.sha256
    ).hexdigest()

    if not hmac.compare_digest(signature or "", expected):
        raise HTTPException(status_code=401)

    payload = await request.json()
    # 非同期処理のためにキューに入れる
    process_alert.delay(payload)
    return {"status": "received"}

ポーリングの方が正しい選択の場面

Webhookがポーリングより常に優れているわけではない。Webhookは特定の問題(リクエストを無駄にせず低頻度イベントに反応する)を解決するが、ポーリングの方がクリーンなアーキテクチャになるシナリオもある:

定期的なダッシュボードの更新。 数分ごとにすべてのアセットのコホートポジションを表示する分析ダッシュボードを構築している場合、スケジュールされたポーリングの方が、大量のWebhookサブスクリプションを管理するより簡単だ。一定間隔での完全なスナップショットが必要であり、それこそがRESTの設計目的だ。

過去データのクエリ。 Webhookは前向きだ。これ以降に起きることを通知する。バックテスト用の過去コホートデータが必要な場合(HyperTrackerはコイン別コホートメトリクスを最大4週間、ポジションとフィルデータを6ヶ月超保存)、それはRESTクエリだ。

高ティアプランのシンプルなボット。 FlowまたはStreamプランで月あたり数十万リクエストを持つ場合、「無駄なポール」のコストは無視できる。1つのエンドポイントを5分ごとにポーリングするボットは月あたり約8,640リクエストを使い、予算内に十分収まる。Webhookのアーキテクチャ上の複雑さはその価値がないかもしれない。

経験則: ボットが特定の条件を待ちトリガーに反応するならWebhookを使う。ボットが広範な市場状態の定期スナップショットを必要とするならポーリングを使う。多くの本番システムは両方を使う: アラートにはWebhook、アラートが発動した時のコンテキスト読み込みにはRESTを使う。

HyperTrackerでの配信方法の選択

HyperTrackerは価格ティアをまたいで3つの配信方法を提供しており、適切な選択は構築するものと、どれだけイベント駆動型のアーキテクチャかによる。

Delivery Tiers

REST(全プラン)。 FreeからStreamまでの全ティアにRESTアクセスが含まれる。構築を始めるビルダーにとって、RESTポーリングはプッシュ型インフラに投資する前にトレード戦略をプロトタイプ化して検証する最も手っ取り早い方法だ。

Webhook(FlowおよびStream)。 Flowティア($799/月、40万リクエスト/月、レートリミット 200リクエスト/分)から利用可能だ。アラート駆動型ボットに最適なポイントだ。監視するイベントを設定し、エンドポイントを登録し、サーバーに監視を任せる。レートリミット枠はオンデマンドクエリのために空けておける。

WebSocket(Streamのみ)。 Streamティア($1,999/月)は継続的なデータフィードのための持続的WebSocket接続を追加する。機関投資家向けデータパイプライン、マルチアセット監視ダッシュボード、多くの銘柄を同時に継続的に更新する必要があるシナリオ向けに設計されている。

ハイブリッドアーキテクチャ

最も堅牢な本番環境セットアップは配信方法を組み合わせる。FlowプランのHyperliquidトレーディングボットの典型的なパターン:

Webhookがコホートポジションのシフトと清算リスクのしきい値超過を監視する。発動するとボットが起動する。
RESTコールがWebhookのトリガー時にコンテキストを読み込む。ボットは現在のポジション、最近のフィル、広範な市場メトリクスをクエリして情報に基づいた判断を下す。
RESTポーリングが遅いスケジュール(15分ごと)で実行され、一般的な市場状態のローカルキャッシュを維持する。このキャッシュにより、コンテキストがすでに読み込まれているためWebhookトリガーの意思決定が速くなる。

このハイブリッドモデルはレートリミットの使用を効率的に保つ: 低頻度ポールは最小限のリクエストを使い、Webhook自体はゼロリクエストコストで(サーバーがプッシュする)、アラート発動時のRESTコールのバーストは的を絞って短い。

Webhookの一般的な落とし穴(とその回避方法)

エンドポイントがダウンする

Webhookが発動した時にサーバーが到達不能な場合、イベントを逃す。ポーリング(次のサイクルで再試行するだけ)と違い、見逃したWebhookはプロバイダーが再送しない限り失われる。冗長性を組み込む: アップタイム保証のあるクラウドプロバイダーでハンドラーを実行し、後でリプレイできる失敗した配信のためのデッドレターキューを実装する。

シグネチャ検証を無視する

シグネチャ検証なしで露出したWebhook URLは開いたドアだ。誰でもエンドポイントに偽のイベントをPOSTしてボットを起動させることができる。ペイロードに基づいて行動する前に必ず共有シークレットに対してHMACシグネチャを検証する。実際の資金でトレードするボットには絶対に欠かせない。

ハンドラーをブロックする

Webhookハンドラーがトレードを同期的に発注しているため応答に30秒かかる場合、配信システムがタイムアウトして再送し、重複したアクションを引き起こす可能性がある。すぐにWebhookを受け付け(200を返し)、非同期で処理する。BullMQ、Celery、またはシンプルなRedisリストのようなジョブキューでこれをすっきり解決できる。

監視がない

Webhookは機能している時も機能していない時も見えない。監視なしでは、配信が静かに停止していても気づかない。ハートビートを設定する: 設定可能なウィンドウ内(例えばアクティブな市場時間中に数時間)にWebhookが発動しない場合、調査のための内部アラートをトリガーする。受信したすべてのイベントをログに記録し、定期的に期待される配信頻度と比較する。

Hyperliquidデータでイベント駆動型アラートを構築する

HyperTrackerのFlowおよびStreamプランは、コホートのシフト、清算リスク、資金調達レートの急騰をエンドポイントに直接配信する。ウォレットサイズと生涯PnLで分類された16の行動コホート。1つのWebhookが発動すれば、ボットが反応する。

HyperTrackerのプランを見る

まとめ: 意思決定フレームワーク

Hyperliquid上で構築しながらポーリングとWebhookのどちらかを選ぶ場合、答えはほぼ常に「両方を、異なる目的で」だ。しかしここに、ボットが消費する各データフィードの決定を固めるための簡単なフレームワークを示す:

| 質問 | Yesの場合 | | --- | --- | | ボットは特定のイベント(コホートの転換、清算リスクのスパイク)に反応するか? | Webhook | | ボットは定期的な全市場スナップショットを必要とするか? | 低頻度のRESTポール | | ボットはバックテスト用の過去データを必要とするか? | RESTクエリ(一回限りまたはバッチ) | | ボットは多くのアセットを並行して継続的に監視するか? | WebSocket(Streamティアの場合) | | ボットはプロトタイプまたはMVPか? | まずRESTポーリングから始め、後でWebhookに移行する |

私たちのデータを最大限活用しているビルダーは、Webhookで「いつ見るべきか」を知り、RESTで「何を見ているか」を理解する。Webhookが「Smart MoneyがETHでロングに転換した」と伝える。RESTコールが、シフトの規模、他のコホートの動向、清算リスクがそのムーブを支持するかを教えてくれる。

その組み合わせが生データを意思決定パイプラインに変える。ボットは1日に何千回も「何か新しいことはある?」と問い合わせるサイクルを無駄にしない。待機し、合図を受け取り、完全なコンテキストを持って動く。それが構築する価値のあるアーキテクチャだ。