From Polling to Push: A Builder's Guide to Hyperliquid WebSockets

By @CoinMarketMan - 19-Jul-2026

ポーリングからプッシュへ：Hyperliquidウェブソケットのビルダーズガイendd

ポーリングからプッシュへ：Hyperliquidウェブソケットのビルダーズガイド

Hyperliquidのボットはどれも同じところから始まる。ループ、スリープタイマー、数秒ごとに呼ばれるRESTコール。それは動く。動かなくなるまでは。追跡する資産が一握り以上になった瞬間、ポーリングは想定外のボトルネックになる。レート制限の消耗、間隔ごとの古いデータ、追加する資産ごとに線形にスケールするアーキテクチャ。

WebSocketはモデルを逆転させることでこれを解決する。ボットがサーバーに「何か変わった？」と1時間に何千回も聞く代わりに、何かが変わった瞬間にサーバーがボットに知らせる。1つの持続的な接続が何千もの個別リクエストに取って代わり、ボットは数秒・数分遅れて気づくのではなく、マーケットイベントが起きたその瞬間に反応する。

このガイドでは、HyperliquidのネイティブWebSocket APIをトレーディングボットに組み込む方法、多くのビルダーが見落とす再接続のエッジケースの対処法、そしてHyperTrackerのプッシュデリバリーから事前計算された分析情報を重ね合わせてローマーケットデータとコホートレベルのインテリジェンスを同時に流す方法について解説する。

スケール時のポーリング問題

RESTポーリングはほとんどのボットの正しい出発点だ。シンプルで、ステートレスで、デバッグしやすい。コホートのポジションやファンディングレートを1時間に数回確認するスイングトレーディングボットなら、ライフサイクル全体をRESTで問題なくこなせる。アーキテクチャは単純で、リクエスト量も管理しやすい範囲に収まる。

問題が起きるのはファンアウトするときだ。10の資産を1秒のリフレッシュ目標で追跡するなら、1時間で36,000リクエストになる。30資産では100,000を超える。HyperliquidのパブリックAPIには1分あたり1,200の共有ウェイトバジェットがあり、個別のinfoクエリはほとんどのエンドポイントで2〜20ウェイトユニット（一部の特殊エンドポイントは最大60）かかる。軽い方でも、1秒ごとにポーリングする10資産ボットは数分でバジェットを使い果たす。

Polling Vs Push

もう一つの問題はレイテンシだ。1秒ポーリングでは、データは常に0〜1秒古い。ほとんどの場合、「何か変わった？」と聞いて同じ答えが返ってくる。WebSocketはその無駄な帯域幅を完全に排除する。サーバーは本当に新しいデータがあるときだけ送信するからだ。

HyperliquidのWebSocketチャンネル

Hyperliquidはメインネット向けにwss://api.hyperliquid.xyz/wsという単一のWebSocketエンドポイントを公開している（テストネット用のミラーはwss://api.hyperliquid-testnet.xyz/ws）。接続後、JSONメッセージを送ることで特定のデータフィードを購読する。

利用可能なサブスクリプションタイプは、トレーディングボットが必要とするコアデータをカバーしている：

AllMids： 全上場資産の最新ミッドプライス。1つの購読で、コインごとにポーリングすることなく全価格の継続的なフィードが得られる。
L2Book： 特定コインのオーダーブックスナップショット。エントリーのサイジングや流動性の把握に深度データが必要なボットに有用。
Trades： リアルタイムの約定データ。取引所で執行された全トレードがここに表示される。
Candle： 1分足から1日足までのOHLCVキャンドル。新しいキャンドルが確定するとサーバーがプッシュする。
UserEvents： 自分自身の約定、ファンディングの支払い、清算イベント。ボットの注文が約定したかどうかを知らせるフィード。

サブスクリプションメッセージはこのような形式：

{
  "method": "subscribe",
  "subscription": {
    "type": "allMids"
  }
}

特定コインのL2Bookサブスクリプションの場合：

{
  "method": "subscribe",
  "subscription": {
    "type": "l2Book",
    "coin": "BTC"
  }
}

サーバーは現在の状態のスナップショット（isSnapshot: trueとタグ付けされる）を含むサブスクリプション確認で応答する。これにより、別途RESTコールなしでボットのローカル状態をすぐに初期化できる。

接続を維持する

Hyperliquidは60秒の無通信でWebSocket接続を切断する。ボットは接続を維持するために20秒ごとにハートビートのpingを送る必要がある。メッセージは最小限：

{"method": "ping"}

実装は簡単だが、見落とすことが驚くほど多い。多くのビルダーがサブスクリプションロジックを組んでトラフィックの少ない環境でテストし、接続が安定していると思い込む。そしてボットが静かな夜間セッション中に沈黙し、サーバーが接続を切断し、誰も再接続を処理していないためにアジアセッションのオープンを丸ごと見逃す。

再接続を想定して設計する：必ず起きる

Hyperliquidのドキュメントには明記されている：切断は定期的かつ予告なく発生する。ボットは再接続を通常の運用イベントとして扱わなければならない。本番ボットが使うフローはこうだ：

Reconnection Flow

切断を検知する。 pingタイムアウト（適切な時間内にpongが返らない）またはWebSocketのエラー/クローズイベント。
指数バックオフで待機する。 1秒から始めて毎回倍にする。障害中にサーバーを叩き続け、もともとの問題にレート制限まで重なることを防ぐ。
再接続して再購読する。 新しいWebSocket接続を開き、全サブスクリプションメッセージを再送する。サーバーが新しいスナップショットで応答する。
スナップショットを処理する。 isSnapshot: trueとタグ付けされ、購読している各フィードの現在の状態が含まれる。これを使ってローカル状態を再構築する。
RESTで照合する。 切断が数秒以上続いた場合、Info APIにクエリして空白を埋める。約定とユーザーイベントはRESTで取得でき、障害中に見逃したものがないかを確認できる。

重要なのはステップ5だ。スナップショットは現在の状態を返すが、見逃したイベントは再生しない。切断中にポジションが開かれて閉じられた場合、スナップショットはどちらも示さない。再接続後にREST クエリを素早く実行することでそのエッジケースを捕捉する。

マルチ資産モニタリングパターン

WebSocketによる最大のアーキテクチャ上の恩恵はマルチ資産モニタリングだ。30資産を追跡するRESTベースのボットは30個の別々のポーリングループ（または30の連続リクエストを持つ1つのループ）が必要だ。WebSocketベースのボットはAllMidsを1回購読するだけで、単一接続を通じて全資産の更新を受け取れる。

より詳細なデータのためには、同一接続でサブスクリプションタイプを混在させられる。典型的なマルチ資産ボットは以下を購読するかもしれない：

市場全体の価格フィード用AllMids
実際にトレードする3〜4資産のL2Book（サイジング用の深度データ）
同じ資産のTrades（大きな約定をリアルタイムで検出するため）
自分の注文約定とファンディング支払いを追跡するUserEvents

合計で約10のサブスクリプションで、マルチストラテジーボットが必要とするすべてをカバーする。同じデータを1秒間隔のRESTポーリングで取得しようとすると、1秒あたり数十のリクエストが必要になる。

Pythonの最小接続マネージャー

PythonのWebSocketsライブラリを使った接続マネージャーの骨格を示す。ハートビート、自動再接続、メッセージルーティングを処理する：

import asyncio
import json
import websockets

WS_URL = "wss://api.hyperliquid.xyz/ws"

class HyperliquidWS:
    def __init__(self, subscriptions):
        self.subscriptions = subscriptions
        self.ws = None

    async def connect(self):
        while True:
            try:
                async with websockets.connect(WS_URL) as ws:
                    self.ws = ws
                    await self._subscribe_all()
                    await asyncio.gather(
                        self._heartbeat(),
                        self._listen()
                    )
            except websockets.ConnectionClosed:
                print("Disconnected. Reconnecting...")
                await asyncio.sleep(1)

    async def _subscribe_all(self):
        for sub in self.subscriptions:
            await self.ws.send(json.dumps({
                "method": "subscribe",
                "subscription": sub
            }))

    async def _heartbeat(self):
        while True:
            await self.ws.send('{"method": "ping"}')
            await asyncio.sleep(20)

    async def _listen(self):
        async for msg in self.ws:
            data = json.loads(msg)
            self._route(data)

    def _route(self, data):
        channel = data.get("channel")
        if channel == "allMids":
            self.on_price_update(data["data"])
        elif channel == "l2Book":
            self.on_book_update(data["data"])
        elif channel == "trades":
            self.on_trade(data["data"])

意図的にシンプルにしている。本番バージョンには指数バックオフ、チャンネルごとの状態追跡、再接続後のRESTによるギャップ照合、不正なメッセージのエラー処理が追加される。しかしコアのパターンはここにある：接続、購読、ハートビート、リッスン、切断時に再接続。

分析情報の重ね合わせ：マーケットデータとインテリジェンス

生のマーケットデータはボットに「何が起きているか」を教える。価格が動いた、約定が発生した、オーダーブックがシフトした。しかし「誰が動かしているのか」はわからない。クジラが蓄積しているのか？継続的に利益を上げているトレーダーたちは同じ方向に傾いているのか？Leviathanコホート（パープエクイティで500万ドル以上保有するウォレット）がポジションを積み上げながらリテールが売っているのか？

ここで分析情報のプッシュデリバリーが効いてくる。我々のデータはHyperliquid上の全ウォレットを16の行動コホートに分類する：口座サイズで8つ（ShrimpからLeviathan）、累計PnLの実績で8つ（Giga-RektからMoney Printer）。コホートメトリクスは5分ごとに更新される。つまりボットは、HyperliquidのネイティブWebSocketからのティックレベルのマーケットデータと、HyperTrackerのプッシュデリバリーからのコホートポジショニングインテリジェンスを組み合わせられる。

Websocket Architecture

アーキテクチャはこうなる：HyperliquidのWebSocketが価格、トレード、オーダーブックデータをボットに直接フィードしてティックレベルの反応を可能にする。HyperTrackerはFlowティア（$799/月）とStreamティア（$1,999/月）でウェブフック経由の事前計算済み分析情報（コホートポジショニング、Smart Moneyアラート、清算リスクスコア、オーダーフローサマリー）を配信する。HyperTrackerからのネイティブWebSocket配信は近日提供予定で、ストリーミングインフラが現在活発に開発中だ。ボットは両方のデータストリームを融合し、生のマーケットデータと行動インテリジェンスの両方で意思決定を行う。

例えば、ボットがHyperliquidのTradesフィードで突然の価格下落を検知したとする。生のデータは「価格が落ちた」と言う。ウェブフック経由で配信されるコホートデータは「Money Printer ウォレット（累計利益100万ドル以上のコホート）が下落中にロングエクスポージャーを増やした」と言う。Giga-Rektウォレット（累計PnLが最悪のコホート）が買っていた場合とは全く異なるシグナルだ。

RESTがまだ正解のとき

WebSocketには複雑さが伴う：接続管理、ハートビートループ、再接続ロジック、状態照合。多くのボットでは、その複雑さは正当化されない。

RESTポーリングの方が良い選択肢なのは、ボットがポジションやシグナルを低頻度（1時間に数回以下）しか確認しないとき、注文を執行するとき（HyperliquidのExchange APIは注文発注にRESTのみ）、日次レポートツールやポートフォリオトラッカーを構築するとき、またはプロトタイピング中で可能な限りシンプルなアーキテクチャが欲しいときだ。

ハイブリッドパターンが多くの本番システムの行き着く先だ。注文執行と口座管理にはRESTを使う。リアルタイムのマーケットデータにはWebSocketを使う。分析情報には、コホート更新が必要な頻度に応じてHyperTrackerのREST APIまたはプッシュデリバリーを使う。

| データタイプ | 最適な配信方法 | 理由 | | --- | --- | --- | | 価格フィード、約定、オーダーブック | WebSocket（Hyperliquidネイティブ） | ティックレベルの鮮度、スケール時の低オーバーヘッド | | 注文発注、キャンセル | REST（Hyperliquid Exchange API） | リクエスト・レスポンスモデルが執行セマンティクスに合致 | | コホートポジショニング、Smart Moneyシグナル | RESTポーリングまたはプッシュ（HyperTracker） | 分析情報は5分ごとに更新、閾値アラートにはプッシュ | | 清算リスク、リーダーボード変化 | RESTまたはウェブフック（HyperTracker） | イベント駆動型：閾値を超えたときのみ関連 | | 履歴データ、バックテスト | REST（HyperTracker） | 数ヶ月分の約定とポジションへのバッチクエリ |

よくある失敗とその回避法

両方のパターンを使ったボットを出荷した経験から、いくつかの失敗モードが繰り返し見られる。

再接続ロジックなし

最も一般的なWebSocketのバグは気づかないものだ。ボットが接続し、購読し、数時間問題なく動く。それからサーバーが接続を切断し（定期メンテナンス、ネットワークの小さな問題、Hyperliquidノードのローテーション）、ボットは何も処理しないまま沈黙する。あなたはまだ動いていると思っている。指数バックオフを使った再接続は必ず実装すること。切断のたびにログを残して、後でギャップを監査できるようにすること。

スナップショットを無視する

再接続して再購読すると、サーバーはisSnapshot: trueとタグ付けされた現在の状態のスナップショットを送る。スナップショットを捨てて増分更新だけを処理するボットがあるが、それでは再接続のたびにローカル状態が永久に古くなる。スナップショットを処理して状態を再構築し、その後に増分更新の処理に切り替えること。

執行にRESTとWebSocketを混同する

HyperliquidのWebSocketはマーケットデータのみを配信する。注文発注はREST Exchange APIを経由し、EIP-712署名リクエストが必要だ。WebSocket経由で注文を送ろうとしても何も起きない。ボットのデータパイプラインと執行パイプラインは別々のループにすること。

ティックスピードで分析情報をポーリングする

コホートレベルの分析情報（Smart Moneyのポジショニングや清算リスクなど）はティックごとに変化しない。我々のデータは5分ごとにリフレッシュされる。行動コホート分析にはそれが適切な粒度だ。コホートエンドポイントを毎秒ポーリングしてもレート制限バジェットを無駄に消費するだけで、データが新しくなるわけでもない。ポーリング頻度はデータの実際のリフレッシュレートに合わせること。または、ウェブフック/プッシュデリバリーに切り替えて、何かが変わったときにサーバーから通知を受け取ること。

両方で構築する：マーケットデータとコホートインテリジェンス

HyperTrackerのAPIはボットに16の行動セグメントにわたる事前計算済みのコホート分析情報を提供する。無料ティア（1日100リクエスト）のRESTポーリングから始め、ボットのデータニーズが成長するにつれてウェブフック（Flow、$799/月）またはWebSocketプッシュ（Stream、$1,999/月）にアップグレードする。

APIを探索する

卒業の道筋

成功しているHyperliquidボットのほとんどは予測可能な軌跡をたどる。論理的に理解しやすくプロトタイプが速いRESTポーリングから始まる。ボットが機能してエッジが証明されると、リクエスト量がポーリングでは持続不可能になるため、ビルダーはマーケットデータレイヤーでWebSocketに卒業する。分析情報レイヤーも似たような道筋をたどる傾向がある。最初はHyperTrackerのRESTエンドポイントを数分ごとにポーリングし、コホートのシフトにより即座に反応する必要が生じるとプッシュデリバリーに切り替える。

この卒業はどのプロトコルが「優れているか」についてではない。配信方法をデータの自然なリズムに合わせることだ。価格データはティックごとに変化するのでWebSocketが適する。コホート分析は5分ごとに更新されるのでRESTもプッシュも機能する。注文執行は個別のリクエスト・レスポンスアクションなのでRESTが自然な選択だ。

各データストリームをそのリズムに合った配信方法に接続すれば、レート制限を使い果たすことなくスケールし、再接続中も何も見逃さず、生のマーケットデータと行動インテリジェンスの両方で意思決定を行うボットが出来上がる。それが多くのビルダーが行き着くアーキテクチャだ。設計によってそこに到達するか、いくつかの痛みを伴う障害の後に偶然たどり着くかは、あなた次第だ。