Your Trading Bot's Biggest Bottleneck Is the API Layer
By @CoinMarketMan - 14-Jul-2026
あなたのトレーディングボットの最大のボトルネックはAPIレイヤーにある
シグナルエンジンの改良に数週間を費やす。コホートの乖離、清算リスクスコアリング、ファンディングレートの極値。バックテストは鋭い結果を示している。そしてボットをデプロイした48時間以内に、データポーリングループがレート制限に引っかかり、20分間にわたってステールデータをサイレントに返し続けたことで、3回のトレードを逃す。シグナル自体は問題なかった。その周囲のアーキテクチャに問題があった。
これはHyperliquidのトレーディングボットで最もよく見られる失敗パターンであり、アルファの生成とはほぼ無関係だ。データ取り込みレイヤー、つまりAPIコールを通じてボットを市場に接続する部分こそ、ほとんどのボットが崩壊する場所だ。冗長なポーリング、非効率なエンドポイント選択、キャッシュなし、バックオフなし、データが実際にいつ更新されるかの認識なし。ビルダーはシグナルを最適化して、APIレイヤーを配管として扱う。しかし漏れる配管は、設計図がどれほど優れていても家を台無しにする。
このガイドは、Hyperliquid上でHyperTrackerのアナリティクスAPIを使用するボットを対象として、そのレイヤーを最初から正しく設計することについてだ。
データレイヤーがシグナルよりも重要な理由
シグナルエンジンは純粋関数だ。同じ入力、同じ出力、毎回変わらない。信頼できるペースでクリーンなデータを与えれば、クリーンな判断を生み出す。ステールなデータ、重複したデータ、あるいはエンドポイントがエラーを返してコードが例外を握り潰したために期待と異なる形のデータを与えれば、シグナルエンジンは回復できない。市場の状態をもはや反映していない情報に基づいて、確信に満ちた判断を下し続けてしまう。
データレイヤーは、ボットとそれが基にするすべての市場インテリジェンスの間に位置する。Hyperliquidでは、我々のデータはローリングインターバルで更新される: 状態スナップショットは15〜20分ごと、オーダーフロースナップショットは5分ウィンドウで。つまり、ポーリングペース、キャッシュロジック、エラー処理は、これらの特定の更新リズムに合わせて設計する必要がある。データが更新されるより速くポーリングするとリクエストクォータを浪費し、遅くポーリングするとシグナルウィンドウを逃す。
データ更新に合わせたポーリングペースの設定
ボットが犯す最も無駄なことの一つは、基礎となるデータが変化するよりも速くエンドポイントをポーリングすることだ。コホートメトリクスが15〜20分ごとに更新され、ボットが60秒ごとにポーリングしているなら、16回のうち15回は同一のデータが返ってくる。クォータを消費し、イベントループに遅延を加え、何も得られない。
設計の基準となる更新スケジュール
HyperTrackerのAPIは、エンドポイントカテゴリによって更新ペースが異なる:
| エンドポイントカテゴリ | 更新ペース | 推奨ポーリング間隔 |
| --- | --- | --- |
| コホートメトリクス (/cohort-metrics) | 約15〜20分 | 5分ごと（更新を速やかにキャッチ） |
| オーダーフロースナップショット (/orders) | ローリング5分ウィンドウ | 5分ごと（ウィンドウに同期） |
| 清算リスク (/liq-risk) | 約15〜20分 | 5分ごと |
| ポジションメトリクス (/position-metrics) | 約15〜20分 | 5分ごと |
| リーダーボード (/leaderboard) | 約15〜20分 | 15〜30分ごと（時間的緊急性が低い） |
ほとんどのエンドポイントで推奨される5分のポーリング間隔はバランスを考慮したものだ。更新後に速やかに新鮮なデータを取得したいが、15〜20分のウィンドウ内のどの秒に更新されるかは正確にはわからない。5分ごとにポーリングすることで、新しいスナップショットが利用可能になってから5分以内に取得でき、1時間以上のタイムフレームで動作する戦略には十分な速さだ。
リクエストバジェットの設計
すべてのAPIティアには月次リクエスト上限と1分あたりのレート制限がある。ボットのアーキテクチャは両方を尊重する必要があり、制約は利用しているティアによって異なる。
| ティア | 月次リクエスト数 | レート制限 | 1日あたりの実効バジェット | | --- | --- | --- | --- | | Pulse ($179/mo) | 50,000 | 60回/分 | 約1,667リクエスト | | Surge ($399/mo) | 150,000 | 100回/分 | 約5,000リクエスト | | Flow ($799/mo) | 400,000 | 200回/分 | 約13,333リクエスト | | Stream ($1,999/mo) | 2,000,000 | 500回/分 | 約66,667リクエスト |
Pulseティアのボットが4つのエンドポイントを5分ごとにポーリングすると、4 x 288 = 1,152リクエスト/日を使用する。これにより、アドホッククエリ、バックフィル、または追加アセット向けの2つ目のポーリングループに515リクエストが残る。余裕はあるが、計画なしにエンドポイントやアセットを追加していくとタイトになってくる。
Surgeティアでは、同じ4エンドポイント・5分間隔のループで同じ1,152リクエストを使用するが、1日のバジェットは約5,000なので、複数のアセットを監視したり、主要アセットのオーダーフロー向けに2つ目の高頻度ループを追加したりできる。重要なのは: レート制限を考慮せずに構築されたボットに後から対応を組み込むのは苦痛なので、ポーリングコードを書く前にバジェットをモデル化することだ。
リクエストバジェットのスプレッドシートパターン
ポーリングコードを書く前に、次のような表を書き出してみよう:
エンドポイント | アセット数 | 間隔 | 1日あたりのコール数
-------------------+--------+----------+----------
/cohort-metrics | 3 | 5分 | 864
/orders | 1 | 5分 | 288
/liq-risk | 3 | 5分 | 864
/position-metrics | 1 | 15分 | 96
-------------------+--------+----------+----------
合計 | | | 2,112
バジェット (Pulse) | | | 1,667 <- 超過
修正: /liq-riskを15分間隔に変更:
/liq-risk | 3 | 15分 | 288
新しい合計 | | | 1,536 <- OK
これは単純な計算だが、ほとんどのビルダーはこれを省略して、本番環境でボットが429エラーを返し始めたときにバジェット超過に気づく。まずモデル化し、それから構築する。
キャッシュ: ほとんどのボットが省略するレイヤー
ボットは、ポーリングするすべてのエンドポイントから最新のレスポンスを保持するローカルデータストア（メモリ内の単純な辞書でも可）を維持する必要がある。これには3つの目的がある。
第一に、重複排除。 /cohort-metricsを5分ごとにポーリングしても、データが15〜20分ごとにしか更新されない場合、4回のポーリングのうち3回は同一のデータが返ってくる。キャッシュは受信したレスポンスを保存済みのバージョンと比較し、何かが実際に変化した場合にのみシグナルエンジンに伝搬すべきだ。これにより、ボットがステールデータでシグナルを再評価して冗長なログを生成するのを防ぐ。
第二に、ステール検出。 各キャッシュエントリにタイムスタンプを付与する。あるエンドポイントのキャッシュが予想される更新間隔の2倍以上（たとえば20分更新なら40分）更新されていない場合、何かがおかしい。APIがダウンしているか、ネットワークが不安定か、ボットのイベントループが詰まっているかだ。ステールアラートが発動すれば、1時間前のデータでボットがトレードする前に調査のきっかけになる。
第三に、グレースフルデグラデーション。 ポーリングが失敗した場合（ネットワークエラー、500エラー、レート制限）、キャッシュは直前の正常なレスポンスを保持し続ける。ボットはそのデータで動作し続けながら、ステールな情報で動作していることを明示的に認識できる。この認識が重要だ: ステールデータで取引していることを知っているボットはポジションサイズを縮小したりストップを広げたりできる。データがステールであることを知らないボットは適応できない。
class DataCache:
def __init__(self, stale_threshold_seconds=2400):
self.store = {}
self.stale_threshold = stale_threshold_seconds
def update(self, endpoint, data):
prev = self.store.get(endpoint)
changed = prev is None or prev["data"] != data
self.store[endpoint] = {
"data": data,
"fetched_at": time.time(),
"changed": changed,
}
return changed
def get(self, endpoint):
entry = self.store.get(endpoint)
if entry is None:
return None, True # no data, considered stale
age = time.time() - entry["fetched_at"]
return entry["data"], age > self.stale_threshold
def is_stale(self, endpoint):
_, stale = self.get(endpoint)
return stale
エラー処理とバックオフ
APIコールは失敗する。ネットワークは切断される。レート制限に引っかかる。問題は、ボットがこれらの失敗をグレースフルに処理するか、クラッシュするか、積極的にリトライして（さらにクォータを消費して）、あるいは最悪の場合、データなしでサイレントに処理を続けるかだ。
3つの失敗モード
レート制限 (HTTP 429)。 APIがスピードを落とすよう伝えている。正しい対応は指数バックオフだ: 1秒待ち、次に2秒、4秒、8秒と増やし、60秒でキャップする。即座にリトライしてはならない。固定の1秒間隔でリトライしてもいけない。すでにレート制限を受けているときに即座にリトライするたびに、穴はさらに深くなる。
サーバーエラー (HTTP 5xx)。 API側で何か問題が発生した。バックオフしながら最大3回リトライする。3回すべて失敗した場合、エラーをログに記録し、キャッシュエントリにステールの可能性があるとマークし、処理を続ける。回復を待ってイベントループ全体をブロックしてはならない。
クライアントエラー (HTTP 4xx、429を除く)。 リクエストが不正な形式だ。リトライしても意味がない。デバッグのためにリクエストペイロード全体とともにエラーをログに記録し、このポーリングサイクルをスキップする。
async def poll_with_backoff(endpoint, params, max_retries=3):
for attempt in range(max_retries):
try:
response = await fetch(endpoint, params)
if response.status == 200:
return response.json()
elif response.status == 429:
wait = min(2 ** attempt, 60)
logger.warning(f"Rate limited on {endpoint}, waiting {wait}s")
await asyncio.sleep(wait)
elif response.status >= 500:
wait = min(2 ** attempt, 30)
logger.warning(f"Server error {response.status} on {endpoint}")
await asyncio.sleep(wait)
else:
logger.error(f"Client error {response.status} on {endpoint}")
return None
except NetworkError as e:
logger.error(f"Network error on {endpoint}: {e}")
await asyncio.sleep(min(2 ** attempt, 30))
logger.error(f"All retries exhausted for {endpoint}")
return None
エンドポイント選択: 必要なものだけ取得する
HyperTrackerは21のエンドポイントを公開している。ボットが実際に必要とするのはおそらく3〜5つだ。バジェットの最大の無駄の一つは、シグナルエンジンが実際にそのデータを消費しないのに「念のため」エンドポイントをポーリングすることだ。
APIからではなく、シグナルから始めよう。問いかけるべきは: シグナル関数が入力として必要とするデータは何か? コホートのポジショニングを使うなら/cohort-metricsをポーリングする。清算リスクを使うなら/liq-riskをポーリングする。リーダーボードデータを使わないなら/leaderboardはポーリングしない。ポーリングループに追加するエンドポイントはすべて、1日のリクエストバジェットを消費し、潜在的な障害ポイントを追加する。
シグナルとエンドポイントの一般的な対応関係
| シグナルタイプ | 必要なエンドポイント | オプションの補強 |
| --- | --- | --- |
| コホート乖離 | /cohort-metrics | /position-metrics（OIコンテキスト） |
| 清算リスクのフェーディング | /liq-risk | /cohort-metrics（方向性確認） |
| オーダーフローの不均衡 | /orders | /cohort-metrics（フローを主導しているのは誰か） |
| ファンディングレートの極値 | Hyperliquidネイティブ API | /cohort-metrics（Smart Moneyのスタンス） |
| コピートレード / ウォレットフォロー | /positions | /leaderboard（対象ウォレットの選定） |
/cohort-metricsがほぼすべてのシグナルタイプで主要または補強ソースとして登場していることに注目してほしい。コホートインテリジェンスを中心に構築するなら、これがメインのエンドポイントだ。我々のデータはHyperliquidのすべてのウォレットを16の行動コホート（口座サイズ別8つ、全期間PnL別8つ）のいずれかに分類しており、コホートレベルの集計こそシグナル密度が最も高い場所だ。
ポーリングループの構成
ポーリングループはボットの心臓部だ。正しく設計すれば、システムは数週間スムーズに動き続ける。誤れば、午前3時に競合状態とポーリング漏れのデバッグをすることになる。
スタッガードインターバルパターン
すべてのエンドポイントのポーリングを同じ秒に発火させてはいけない。4つのエンドポイントを5分ペースでポーリングするなら、インターバル全体にわたってずらす。/cohort-metricsをt+0に、/ordersをt+75秒に、/liq-riskをt+150秒に、/position-metricsをt+225秒にポーリングする。これによりリクエストレートが平準化され、1分あたりのレート制限を引き起こしかねないバーストを回避できる。
POLL_SCHEDULE = [
{"endpoint": "/cohort-metrics", "offset_sec": 0, "interval_sec": 300},
{"endpoint": "/orders", "offset_sec": 75, "interval_sec": 300},
{"endpoint": "/liq-risk", "offset_sec": 150, "interval_sec": 300},
{"endpoint": "/position-metrics","offset_sec": 225, "interval_sec": 900},
]
async def run_polling_loop(cache, signal_engine):
while True:
now = time.time()
for task in POLL_SCHEDULE:
elapsed = (now - start_time) % task["interval_sec"]
if abs(elapsed - task["offset_sec"]) < 2:
data = await poll_with_backoff(task["endpoint"], params)
if data and cache.update(task["endpoint"], data):
signal_engine.evaluate(cache)
await asyncio.sleep(1)
重要な詳細: シグナルエンジンが呼び出されるのは、キャッシュが本物のデータ変化を検出したときだけだ。冗長な評価なし、無駄なコンピューティングなし、ボットが下すすべての判断は新鮮な情報に基づく。
WebhookとWebSocketの代替手段
Flow ($799/mo) とStream ($1,999/mo) ティアでは、HyperTrackerはWebhookとWebSocket接続をサポートしている。これらはポーリングモデルを完全に逆転させる: タイマーでボットがデータを要求する代わりに、データが変化したときにAPIがボットにデータをプッシュする。
Webhookは対応するエンドポイントのポーリングループを完全に排除する。コールバックURLを登録すると、コホートメトリクスが更新されたときにボットが新しいデータを含むPOSTを受信する。ポーリングなし、リクエストの無駄なし、ステールウィンドウなし。
WebSocket接続（Streamティア）は継続的な更新のための永続チャンネルを提供する。データ更新後数秒以内に反応する必要がある高頻度システムを構築しているなら、WebSocketパスは定期的なポーリングのレイテンシを完全に除去する。
しかし、ほとんどの初心者ビルダーにとって、上述のポーリングパターンが正しい基盤だ。WebhookとWebSocketは、ボットの戦略が実証され、より低いレイテンシや高いスループットが必要になったときに移行する最適化だ。
まとめ: リファレンスアーキテクチャ
以下は、APIから実行まで、よく設計されたHyperliquidトレーディングボットの完全なスタックだ:
+----------------------------------------------------------+
| リスク管理 |
| （シグナルを拒否、ポジション制限の強制、停止可能） |
+----------------------------------------------------------+
| ^
v |
+------------------+ +------------------+ |
| シグナルエンジン |-->| 実行 |--+
| （純粋関数） | | （Hyperliquid |
| | | Python SDK） |
+------------------+ +------------------+
^
| （キャッシュ変化時のみ）
+----------------------------------------------------------+
| データキャッシュ |
| - 重複排除（変化のないレスポンスはスキップ） |
| - ステール検出（データが更新間隔の2倍を超えたらアラート） |
| - グレースフルデグラデーション（エラー時は最後の正常値を提供）|
+----------------------------------------------------------+
^
| （バックオフ付きスタッガードポーリング）
+----------------------------------------------------------+
| APIポーリングレイヤー |
| - エンドポイントごとにスタッガードインターバル |
| - 429/5xxに対する指数バックオフ |
| - リクエストバジェット追跡（1日あたり + 1分あたり） |
| - シグナル要件に基づくエンドポイント選択 |
+----------------------------------------------------------+
|
v
HyperTracker API
（REST / Webhooks / WebSocket）
各レイヤーは単一の責務を持つ。ポーリングレイヤーはAPI通信とエラー回復を処理する。キャッシュレイヤーはデータの鮮度と重複排除を処理する。シグナルエンジンは意思決定を処理する。実行レイヤーは注文管理を処理する。そしてリスク管理はすべての上に位置し、どのレイヤーからのアクションもブロックする権限を持つ。
データはスタックを通じて上に流れ、各レイヤーが特定の保証を追加する。シグナルが実行レイヤーに到達するまでに、データが新鮮であること、シグナルが変化した（繰り返しではない）入力で評価されたこと、リスクレイヤーがトレードを承認したことがわかる。それが夜通し動かし続けられるボットだ。
事前計算されたインテリジェンスの上にボットを構築する
HyperTrackerのAPIは、Hyperliquid全体のコホートアナリティクス、清算リスクスコアリング、オーダーフロースナップショット、ポジションメトリクスを提供する。16の行動コホート、すべてのウォレットを分類し、REST、Webhook、またはWebSocket経由で配信。無料ティアから始めて、ボットが成熟するにつれてスケールアップしよう。
よくある間違い（とその回避方法）
すべてのエンドポイントを同じ頻度でポーリングする。 リーダーボードデータはオーダーフロースナップショットほど速く変化しない。各エンドポイントのポーリング間隔をその更新ペースとシグナルがそのデータにどれだけ敏感かに合わせること。すべてのエンドポイントに5分間隔が必要なわけではない。
月次上限を手遅れになるまで無視する。 3週間は問題なく動くが4週目に月次クォータを使い果たすボットは、少し遅くても月全体を走り続けるボットより悪い。毎日の累積リクエストを追跡し、閾値でアラートを出すようにすること（たとえば、その日付が月のどの位置にあるかに対して月次バジェットの按分比率を超えて使用したとき）。
エラーをサイレントに飲み込む。 最悪のパターン: try/exceptブロックがすべての例外をキャッチしてNoneを返し、それが「データなし」としてシグナルエンジンに渡される。シグナルエンジンは「データなし」と「データが何も興味深いことを言っていない」を異なるものとして解釈する。「APIが空の結果を返した」（有効）と「APIコールが失敗した」（エラー）を区別すること。これらは異なる状態だ。
ホットループで履歴データを取得する。 HyperTrackerにはポジションとフィルについて数ヶ月さかのぼる履歴データがある。そのデータはバックテストとリサーチ用であり、一度取得してローカルに保存し、ライブポーリングループで再取得することは決してしてはならない。履歴エンドポイントはリアルタイムエンドポイントと同じレート制限を持つため、繰り返し取得すると理由もなくバジェットを食いつぶす。
シグナルを先に構築してデータレイヤーを後回しにする。 シグナルは楽しい部分だ。コホート乖離スコアリング、複合シグナル、閾値チューニング。しかしAPIコールをどれだけ使えるか、データがどのくらいの頻度で更新されるか、エラーがどのように伝搬するかを知らずにシグナルを構築すると、最初から設計すべきだった制約に合わせてデータレイヤーを後付けすることになる。まず配管を構築する。数日間はログのみ（取引なし）でテストする。それからシグナルを接続する。
結論
シグナルがアルファだ。APIレイヤーは、そのアルファをリクエストバジェットを使い果たすことなく、サイレントに劣化することなく、日々確実に届けるインフラだ。これを正しく実装したビルダーは、何ヶ月も動き続けるボットを構築する。データレイヤーを後付けとして扱う人たちは、エッジを改善するよりもインフラのデバッグに多くの時間を費やす。
コードを書く前にリクエストバジェットをモデル化する。積極的にキャッシュする。エラーを明示的に処理する。データが実際に更新されるペースでポーリングし、リクエストをスタッガードにしてバーストを防ぐ。この5つを実践すれば、APIレイヤーは見えなくなる。それこそが、優れたインフラがあるべき姿だ。