Hyperliquid APIのレート制限とベストプラクティス

2026年5月6日

hyperliquid rate limit
hyperliquid api limit
Hyperliquid API レート制限
API ベストプラクティス

Hyperliquid APIに依存するクオンツ戦略やデータツールにとって、レート制限は避けて通れない重要なテーマです。レート制限に達すると、戦略の実行が中断されるだけでなく、緊急のポジション解消が必要な場面などで許容できない遅延が発生する可能性があります。

この記事では、Hyperliquid APIのレート制限の考え方を整理し、本番環境で使いやすい対策とベストプラクティスを紹介します。堅牢で効率的なAPIクライアントを構築するための実務的な参考として活用してください。

なぜレート制限が重要なのか

レート制限の主な目的は、サーバー側のリソースを保護し、一部の高頻度リクエストによって全体のサービス品質が低下することを防ぐことです。Hyperliquidのようなオンチェーン取引プラットフォームでは、サーバーの安定性が多数の同時ユーザーの取引体験に直結します。

戦略開発者の視点では、レート制限は明確な制約条件です。つまり、どれだけ速くデータを取得できるか、どれだけ速く注文を送信できるかを決める要素になります。戦略アーキテクチャの設計段階でレート制限を考慮していないと、本番稼働後に429エラーが頻発し、対応に追われることになりかねません。

Infoエンドポイントのレート制限

Infoエンドポイント（/info）は、読み取り専用のデータ取得に使われます。一般的に、Exchangeエンドポイントよりも制限は緩やかです。ただし、具体的な上限値はHyperliquid公式ドキュメントの最新版を確認する必要があります。本記事では、未確認の具体的な数値は引用しません。

基本的な考え方として、Infoエンドポイントは通常のマーケット監視には十分なリクエスト頻度を許容しますが、板情報を毎秒数十回のように高頻度でポーリングすると、制限に達する可能性があります。リアルタイムデータが必要な場合は、RESTのポーリングではなくWebSocket購読を使うほうが適しています。リクエスト負荷を抑えられ、レイテンシーも低くなります。

よく使われるInfoエンドポイントの種類と、適した利用頻度は以下のとおりです。

アカウント状態の取得（clearinghouseState）：低頻度のポーリング向きです。目安として毎秒数回を超えない設計が望ましいです。
約定履歴の取得（userFills）：一括取得または低頻度の取得で十分です。高頻度に呼び出す必要は通常ありません。
マーケットメタデータ（meta）：起動時に一度取得し、ローカルにキャッシュする運用が適しています。
L2板情報のスナップショット：RESTポーリングではなく、WebSocket購読への切り替えを推奨します。

Exchangeエンドポイントのレート制限

Exchangeエンドポイント（/exchange）は、注文、キャンセル、注文変更などの書き込み操作を処理します。一般的に、Infoエンドポイントよりも厳しい制限が設けられています。これは自然な設計です。過度な注文・キャンセルはサーバーリソースを消費するだけでなく、他のユーザーの注文マッチング体験にも影響する可能性があるためです。

特に注意したいのは、頻繁な注文修正を行う戦略です。単純な注文・キャンセルよりもサーバー側の負荷が大きくなる場合があるため、本当にその頻度で注文変更が必要なのかを設計段階で検討する必要があります。各種Exchange操作の制限については、Hyperliquid公式ドキュメントを開発前に必ず確認してください。

WebSocket接続と購読の制限

WebSocketの制限はRESTとは異なり、主に同時接続数や1接続あたりの購読チャンネル数に関係します。複数銘柄のL2板情報を大量に購読すると、サーバー側のリソース消費が大きくなります。

以下の点を意識すると、安定した運用につながります。

複数チャンネルの購読は、できるだけ少ないWebSocket接続にまとめる
不要になった購読は、速やかに購読解除メッセージを送る
同一アカウントで過度に多くの並行接続を開かない

429エラーへの正しい対応

HTTP 429（Too Many Requests）は、レート制限に達した際に返される標準的なステータスコードです。429を受け取ったあとにすぐ再試行するのは避けるべきです。即時リトライは状況を悪化させ、さらに多くの429を引き起こし、結果的により長い待機や制限につながる可能性があります。

正しい対応フローは次のとおりです。

同種のリクエストを直ちに停止する
429を受け取ったら、その1件だけでなく、同じ種類のリクエスト全体を一時停止します。
レスポンスヘッダーのRetry-Afterを確認する
429レスポンスにRetry-Afterヘッダーが含まれている場合、その秒数だけ待機します。指定がある場合は必ず従うべきです。
Retry-Afterがない場合は指数バックオフを使う
初期待機時間を1秒とし、失敗するたびに2秒、4秒、8秒のように倍増させます。最大待機時間は、たとえば60秒などの上限を設けます。
待機中にログ記録とアラートを行う
429エラーは黙って無視すべきではありません。頻繁なレート制限は、戦略のリクエスト設計を見直す必要があるサインです。

Pythonで指数バックオフを実装する場合の基本的な考え方は以下のとおりです。

import time
import requests

def request_with_backoff(url, payload, max_retries=5):
    wait_time = 1

    for attempt in range(max_retries):
        response = requests.post(url, json=payload)

        if response.status_code == 200:
            return response.json()
        elif response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            sleep_duration = int(retry_after) if retry_after else wait_time

            print(f"Rate limited. Waiting {sleep_duration}s before retry.")
            time.sleep(sleep_duration)
            wait_time = min(wait_time * 2, 60)
        else:
            response.raise_for_status()

    raise Exception("Max retries exceeded")

リクエストのバッチ処理

リクエスト頻度を下げる有効な方法のひとつがバッチ処理です。複数の独立した問い合わせを、できるだけ少ないリクエストにまとめます。

データ取得では、複数アカウントや複数銘柄の情報が必要な場合、APIがバッチ取得パラメータをサポートしているかを確認してください。1件ずつ個別に送るよりも、必要なデータをまとめて取得するほうが効率的です。

取引操作では、Hyperliquidはバッチ注文（Batch Order）をサポートしています。単一のExchangeリクエストで複数注文を送信できるため、複数ポジションを同時に構築する戦略では、レイテンシーとリクエスト回数の両方を抑えられます。具体的なフォーマットは公式ドキュメントを確認してください。

コネクションプールと並行制御

マルチスレッドや非同期環境でHyperliquid APIを呼び出す場合、クライアント側で並行制御を行う必要があります。短時間に大量のリクエストが集中しないようにするためです。

たとえば、PythonではSemaphoreを使って同時リクエスト数を制限できます。

import asyncio
import aiohttp

# 最大同時リクエスト数を10に制限
semaphore = asyncio.Semaphore(10)

async def rate_limited_request(session, payload):
    async with semaphore:
        async with session.post(
            "https://api.hyperliquid.xyz/info",
            json=payload
        ) as response:
            return await response.json()

HTTP接続の再利用も重要です。毎回新しい接続オブジェクトを作成するのではなく、Pythonであればrequests.Sessionやaiohttp.ClientSessionを使うことで、HTTP Keep-Aliveを活用できます。TCPハンドシェイクのコストを削減し、レイテンシーとリソース消費を抑えられます。

ローカルキャッシュ戦略

すべてのデータを毎回APIからリアルタイム取得する必要はありません。適切なローカルキャッシュは、不要なAPIリクエストを大幅に減らします。

マーケットメタデータ（銘柄リスト、最大レバレッジなど）は変化が少ないため、数時間単位でメモリキャッシュできます。
資金調達率データは、次の決済タイミングまでキャッシュする設計が考えられます。
アカウント状態はローカルにキャッシュを持ち、WebSocketのアカウントイベントで更新することで、頻繁なポーリングを避けられます。

APIヘルスの監視

本番環境では、API呼び出しに対する体系的な監視が欠かせません。

インターフェース種別ごとの成功率とレスポンスタイムを記録する
429エラーにアラート閾値を設定し、発生時に通知する
WebSocketの切断頻度を追跡する。切断率が高い場合はネットワーク問題の兆候かもしれません。
ローカルキャッシュとAPIレスポンスの整合性を定期的に確認し、キャッシュ不整合によるデータずれを防ぐ

ベストプラクティスまとめ

項目	推奨アプローチ
リアルタイム相場データ	RESTポーリングではなくWebSocket購読を優先する
429エラー対応	即時リトライを避け、`Retry-After`または指数バックオフに従う
注文処理	必要に応じてバッチ注文を使い、リクエスト回数を削減する
並行制御	Semaphoreやキューで同時リクエスト数を制限する
接続管理	`Session`や`ClientSession`でHTTP接続を再利用する
キャッシュ	メタデータや低頻度更新データはローカルキャッシュする
監視	成功率、遅延、429、WebSocket切断を継続的に監視する
鍵管理	取引用の署名権限を安全に分離し、秘密鍵を平文で扱わない

秘密鍵の安全性とOneKeyの役割

API制限やパフォーマンス最適化を考えるうえでも、秘密鍵の安全性は絶対に妥協できない土台です。Exchangeエンドポイントへの各取引リクエストには秘密鍵による署名が必要です。つまり、API戦略を実行する環境では、何らかの形で署名権限にアクセスできる状態になります。

安全性と利便性のバランスを取る方法として、OneKeyウォレットで専用のAPI署名用キーを生成・管理し、メイン資金を管理するアカウントと分離するワークフローが実用的です。ハードウェアウォレットのセキュアチップにより、秘密鍵がソフトウェア上に平文で露出しにくくなります。仮に戦略サーバーが攻撃を受けても、署名鍵そのものを直接抜き取られるリスクを抑えられます。

OneKeyのGitHubで公開されているオープンソースコードは、アプリケーション層でウォレット署名を安全に統合する方法を理解するうえで参考になります。また、WalletConnectはウォレットとdApp間の標準的な通信プロトコルであり、OneKeyはこれをサポートしています。戦略コードや取引ワークフローにウォレット連携を組み込みたい開発者にとって扱いやすい選択肢です。

EU MiCAなどの規制フレームワークを意識する場合でも、適切な鍵管理記録は監査対応の重要な一部になります。

OneKeyはデスクトップとモバイルの両方で利用でき、オンチェーンAPI取引に参加する際のセキュリティ基盤として検討しやすいウォレットです。実際にHyperliquidを使ったパーペチュアル取引を行う場合は、OneKeyをダウンロードし、OneKey Perpsを通じて安全性を意識した取引ワークフローを試してみてください。

FAQ

Q1：レート制限に達するとアカウントは凍結されますか？

短時間のレート制限であれば、通常はリクエストが拒否され、429エラーが返るだけです。すぐにアカウント凍結につながるとは限りません。ただし、継続的な乱用はより深刻な措置につながる可能性があります。具体的なポリシーはHyperliquid公式ドキュメントを確認してください。適切なレート管理は技術上の要件であると同時に、プラットフォーム利用ルールを守るための基本でもあります。

Q2：WebSocketメッセージの処理が配信速度に追いつかない場合はどうすればよいですか？

受信したメッセージを処理しきれないと、キューが積み上がり、データがどんどん遅延します。対策としては、メッセージ処理ロジックの計算効率を改善する、受信処理と計算処理を分離する、不要な購読チャンネルを減らす、などが考えられます。最適化しても追いつかない場合は、戦略設計そのものが現実的かどうかを見直す必要があります。

Q3：複数の戦略インスタンス間でレート制限枠を共有するにはどうすればよいですか？

複数の戦略インスタンスを同時に動かす場合、各インスタンスが個別にレートを管理すると、合計リクエスト数が制限を超える可能性があります。中央集約型のリクエストプロキシやレート制限ミドルウェアを用意し、APIアクセスを一元管理する設計が望ましいです。Redisなどのインメモリデータベースを使えば、分散レートカウンターを実装し、複数プロセスや複数サーバー環境でもリクエスト頻度を統制できます。

Q4：429がレート制限によるものか、他の原因かはどう判断しますか？

標準的な429レスポンスには、レスポンス本文に原因を示すエラーメッセージが含まれることが多く、場合によってはRetry-Afterヘッダーも含まれます。レスポンス本文でレート制限が明示されている場合は、指数バックオフで対応します。一方、残高不足や注文パラメータ不正など別の理由が示されている場合は、単純に再試行するのではなく、エラー内容に応じた修正が必要です。

Q5：InfoエンドポイントとExchangeエンドポイントのレート制限は別々に計算されますか？

公式ドキュメントの説明では、これら2種類のエンドポイントの制限は分けて扱われます。つまり、高頻度のデータ取得が注文送信の枠を直接消費するわけではなく、その逆も同様です。戦略設計では、読み取り操作と書き込み操作を分けてレート予算を設計するとよいでしょう。

まとめ

レート制限の管理は、Hyperliquid API開発で見落とされがちですが、非常に重要な要素です。WebSocketを使ってポーリングを減らすこと、指数バックオフを含む堅牢なリトライ処理を実装すること、バッチ処理やローカルキャッシュで不要なリクエストを減らすことは、戦略の安定性と効率に直接影響します。

そのうえで、秘密鍵の安全性も忘れてはいけません。OneKey Perpsは、ハードウェアレベルの鍵管理とHyperliquidの流動性を活用しながら、より安全性を意識したパーペチュアル取引ワークフローを構築するための実用的な選択肢です。最初のオンチェーン・クオンツ戦略を作る場合でも、既存システムのセキュリティ基準を高めたい場合でも、OneKeyをダウンロードし、OneKey Perpsを実際に試してみるところから始められます。

---免責事項---

本記事は技術的な参考情報のみを目的としており、投資助言、財務アドバイス、法的助言ではありません。API取引には、技術的障害、ネットワーク中断、システム遅延などのリスクがあります。自動化戦略はコードの不具合により想定外の損失を生む可能性があります。永久先物取引は高いレバレッジリスクを伴います。リスクを十分に理解したうえで慎重に参加し、ご自身のリスク許容度に応じて資金を管理してください。