HyperliquidのRESTとWebSocket：どちらをいつ使うべきか

2026年5月6日

hyperliquid rest websocket
hyperliquid api types
Hyperliquid REST API
Hyperliquid WebSocket

Hyperliquid APIを実装する際、多くの開発者が最初に悩むのが「自分の戦略ではRESTを使うべきか、それともWebSocketを使うべきか」という点です。両者は仕組みが大きく異なり、向いているユースケースもまったく違います。選び方を間違えると、帯域を無駄に消費するだけでなく、戦略の反応速度が落ち、想定以上のスリッページにつながる可能性があります。

この記事では、REST APIとWebSocketの仕組み、適した用途、レイテンシーの特徴、実装時の落とし穴を整理し、Hyperliquid APIを使う際の判断基準を解説します。

REST API：リクエスト・レスポンス型のインターフェース

REST（Representational State Transfer）は、もっとも一般的なHTTP APIの形式です。クライアントがリクエストを送り、サーバーがレスポンスを返す「一問一答」のモデルで、基本的には処理が終わると接続も完了します。

HyperliquidのREST APIは、大きく2種類のエンドポイントに分かれます。

Infoエンドポイント（/info）：現在の市場メタデータ、過去約定、口座ポジションのスナップショットなど、読み取り専用のクエリを扱います。署名は不要で、任意のクライアントから呼び出せます。
Exchangeエンドポイント（/exchange）：注文、キャンセル、レバレッジ変更、証拠金調整などの書き込み操作を扱います。EIP-712形式の構造化署名が必須で、サーバーは署名者とアカウントアドレスが一致するかを検証してから処理を実行します。

RESTが向いている典型的なケース

RESTが得意なのは、一度だけ取得すればよいデータの問い合わせです。たとえば、戦略起動時に現在のポジションを取得する、定期的に口座残高を確認する、必要なタイミングで特定銘柄の資金調達率履歴を取得するといった処理です。これらはリアルタイム性がそこまで求められず、リクエストを1回送り、結果を1回受け取れば十分です。

注文やキャンセルもRESTで行います。戦略がリアルタイムの市場データを必要とする場合でも、実際の注文指示はExchangeエンドポイントにRESTリクエストとして送信する必要があります。これは回避できない仕様上の要件です。

また、バックテスト用に大量の過去約定やローソク足データを取得する場合もRESTが適しています。Infoエンドポイントをページングしながら呼び出す方式であれば、実用上十分な効率で履歴データを取得できます。

RESTの限界

RESTの本質的な制約は「プル型」であることです。市場がいつ変化するかはクライアント側には分からないため、定期的にポーリングするしかありません。

たとえば100msごとに板情報を取得しようとすると、レート制限に当たりやすくなります。一方で、1秒に1回まで頻度を下げると、値動きの速い相場では戦略の反応が遅れる可能性があります。市場変化に即応する必要がある戦略にとって、高頻度のRESTポーリングは非効率であり、信頼性の面でも限界があります。

WebSocket：持続接続とリアルタイム配信

WebSocketは、クライアントとサーバーの間で一度接続を確立したあと、双方向に通信できるプロトコルです。クライアントが何度もリクエストを送らなくても、サーバー側から継続的にデータをプッシュできます。

HyperliquidのWebSocketエンドポイントは次のとおりです。

wss://api.hyperliquid.xyz/ws

接続後、クライアントは購読したいデータタイプを指定するサブスクリプションメッセージを送信します。その後、接続が切れるか、クライアントが購読を解除するまで、サーバーは該当データの更新イベントを継続的に配信します。

WebSocketが向いている典型的なケース

リアルタイムの板監視は、WebSocketの代表的な用途です。l2Bookチャンネルを購読すると、注文板に変化があるたびに更新データを受け取れるため、戦略はミリ秒単位で市場深度の変化を把握できます。

リアルタイム約定ストリーム（tradesチャンネル）は、市場へのインパクトや約定ペースを把握するのに役立ちます。短期的な市場センチメントを判断する実用的なシグナルにもなります。

アカウントイベント（userEventsチャンネル）を購読すると、約定通知や清算関連の通知など、アカウント単位の重要イベントをリアルタイムで受け取れます。これにより、口座状態を頻繁にポーリングする必要が少なくなります。

資金調達率の変化をリアルタイムで追う用途にもWebSocketは有効です。特に裁定取引では、次のポーリングタイミングを待つのではなく、変化を即座に検知できることが重要になる場合があります。

WebSocket実装時の注意点

WebSocketで最も重要なのは接続の安定性です。ネットワークの揺らぎ、サーバー側の再起動、長時間アイドル状態などにより、接続が切れることがあります。本番環境では、心拍確認（定期的なping/pong）と自動再接続処理を必ず実装すべきです。再接続後はすべてのチャンネルを再購読し、切断中に失われた可能性のあるデータも考慮する必要があります。

また、メッセージ処理の負荷も軽視できません。主要銘柄のL2板など高頻度データを購読すると、非常に多くのメッセージが届くことがあります。クライアント側のJSONパースや処理ロジックが遅いと、キューが詰まり、受信データがどんどん遅延します。その状態では、WebSocketを使っていてもリアルタイム性の意味が薄れてしまいます。

詳細比較

RESTとWebSocketは、どちらが優れているというより、役割が異なります。

項目	REST API	WebSocket
通信方式	リクエスト・レスポンス	持続接続、サーバープッシュ
主な用途	スナップショット取得、履歴データ取得、注文・キャンセル	リアルタイム板、約定ストリーム、アカウントイベント
レイテンシー特性	ポーリング間隔に依存	更新が発生次第プッシュ
実装難易度	比較的シンプル	再接続、購読管理、メッセージ処理が必要
書き込み操作	対応。Exchangeエンドポイントを利用	通常は監視用途。注文送信はREST
向いている戦略	定時実行、中低頻、初期化処理	マーケットメイク、短期判断、リアルタイム監視

コード例の比較

RESTで板のスナップショットを取得する例（Python）：

import requests

response = requests.post(
    "https://api.hyperliquid.xyz/info",
    json={"type": "l2Book", "coin": "ETH"}
)

book = response.json()

# 現在時点の板スナップショットを取得するだけで、自動更新はされません

WebSocketで板のリアルタイム更新を購読する例（Python）：

import asyncio
import websockets
import json

async def stream_orderbook():
    uri = "wss://api.hyperliquid.xyz/ws"

    async with websockets.connect(uri) as ws:
        await ws.send(json.dumps({
            "method": "subscribe",
            "subscription": {"type": "l2Book", "coin": "ETH"}
        }))

        # 板が更新されるたびにメッセージを受信します
        async for message in ws:
            data = json.loads(message)
            # リアルタイム更新を処理します
            print(data)

asyncio.run(stream_orderbook())

違いは明確です。RESTは1回スナップショットを取得して終了します。一方、WebSocketは接続を維持し、切断されるまで継続的に更新を受け取ります。

注文署名とOneKey連携

RESTで注文を出す場合でも、WebSocketでアカウントイベントを監視する場合でも、書き込み操作を伴うリクエストにはEIP-712署名が必要です。署名鍵の管理は、アカウントの安全性を大きく左右します。

OneKeyウォレットは、ハードウェアレベルの署名分離を提供します。秘密鍵はセキュアチップ内に保存され、署名処理はデバイス内部で完結します。ホストPC上のコードが生の秘密鍵にアクセスすることはありません。量的取引や自動化戦略を扱う開発者にとって、これは重要です。仮に戦略コードに脆弱性があっても、攻撃者がコード注入だけで秘密鍵そのものを抜き取るリスクを抑えられます。

実務上の流れは次のようになります。戦略コードが署名対象の注文リクエストを構築し、WalletConnectを通じてOneKeyデバイスへ署名リクエストを送信します。ユーザーがデバイス画面で内容を確認して承認すると、署名結果が戦略コードへ返り、その後HyperliquidのExchangeエンドポイントへ送信されます。

この方式は人間による確認ステップを挟むため、中低頻の戦略に向いています。高頻度かつ完全自動の戦略では、メイン口座と専用ホットウォレットを分離して管理するなど、別途リスク設計を検討する必要があります。

OneKeyはデスクトップとモバイルに対応しており、オープンソースのコードを通じて署名連携の実装を確認できます。Hyperliquidの流動性をより使いやすい形で活用したい場合は、OneKey Perpsを使うワークフローも実践的な選択肢です。

ハイブリッド構成：実運用でのベストプラクティス

本番環境では、RESTとWebSocketは置き換え関係ではなく、補完関係として使うのが一般的です。典型的な量的取引システムでは、次のような構成になります。

WebSocketの長期接続で、L2板、約定ストリーム、アカウントイベントなどの市場データをリアルタイム購読する
RESTで注文、キャンセルなどの取引指示を送信する
戦略起動時にRESTで口座状態と現在ポジションを一度取得し、初期状態として使う
定期的に、たとえば1時間ごとにRESTで口座状態をフル照合し、WebSocket切断などによる状態ズレを検出する

このハイブリッド構成は、両者の強みを活かす実務的な設計です。Hyperliquid APIを使う場合も、基本的にはこの分担を前提に考えると実装しやすくなります。

FAQ

Q1：単純な定時注文戦略だけなら、WebSocketは必要ですか？

必要ありません。定時注文戦略の主な要件は、指定時刻に処理を起動し、署名付きで注文を送ることです。これはRESTだけで実現できます。戦略の実行時にRESTで現在価格や口座状態を確認し、注文を構築してExchangeエンドポイントへ送信すれば十分です。このような戦略では、WebSocketは追加コストになり、保守の複雑さを増やす場合があります。

Q2：WebSocketが切断された場合、どのデータを取りこぼしたか分かりますか？

これはWebSocket開発でよくある問題です。一般的には、再接続後すぐにRESTで現在の完全な状態、たとえば板のスナップショットや口座ポジションを取得し、それを新しい基準点にします。切断中の差分更新は捨て、最新状態から再開する考え方です。約定履歴のようなデータであれば、再接続後に切断期間中の履歴をRESTで取得し、欠損を補完する方法もあります。

Q3：RESTで注文してから約定通知を受け取るまでの遅延はどのくらいですか？

RESTの注文レスポンスは、多くの場合「注文が受け付けられた」ことを示すものです。実際の約定通知はWebSocketのuserEventsチャンネルで受け取るか、後から口座状態を再度ポーリングして確認します。全体の遅延はネットワーク環境やHyperliquid側の処理状況に依存します。通常時は短いとされていますが、極端な相場環境では遅延する可能性があります。

Q4：WebSocket接続はいくつ開くのが適切ですか？

同一アカウントの購読は、できるだけ少数の接続に集約することをおすすめします。過剰な並列接続は接続数制限に触れる可能性があります。具体的な上限は公式ドキュメントの最新情報を確認してください。複数の独立した戦略がある場合でも、内部メッセージバスを使って1つのWebSocket接続を共有すれば、外部接続数を減らしつつ、再接続管理も簡素化できます。

Q5：Jupyter NotebookでWebSocketコードをデバッグする際の注意点はありますか？

Jupyterのデフォルトevent loopは、asyncioと相性の問題が出ることがあります。asyncio.run()をそのまま実行するとエラーになる場合があります。その場合は、nest_asyncioをインストールしてノートブックの冒頭でnest_asyncio.apply()を呼び出すか、WebSocket処理を独立したPythonスクリプトに移して実行する方法が現実的です。

まとめ

RESTとWebSocketは競合する選択肢ではなく、異なる目的のために設計された補完的なツールです。簡潔に言えば、「その時点のデータ」が必要ならREST、「リアルタイムの変化」が必要ならWebSocketを使います。そして、注文などの書き込み操作はRESTで行います。

この役割分担を理解すれば、Hyperliquid APIの設計思想をつかみやすくなります。そのうえで、署名バックエンドとしてOneKeyウォレットを組み合わせれば、秘密鍵を直接ホスト環境に置かずに、より堅牢なオンチェーン取引システムを構築しやすくなります。

OneKey Perpsを使うと、Hyperliquidの深い流動性を、より分かりやすい操作フローで利用できます。まずはOneKeyをダウンロードし、ウォレットのセットアップ後にOneKey Perpsの利用手順を確認してみてください。なお、取引の判断は必ずご自身のリスク許容度に基づいて行ってください。

---免責事項---

本記事は技術学習を目的とした情報であり、投資助言ではありません。自動売買戦略には、コードの不具合、ネットワーク障害、API仕様変更などの技術的リスクがあり、予期しない損失につながる可能性があります。無期限先物を含む高レバレッジ取引は非常にリスクが高いため、ご自身の技術力、資金状況、リスク許容度を十分に確認したうえで慎重に判断してください。