Hyperliquid Webhook連携パターン徹底解説
自動売買システムを構築する場合、「イベント駆動」はポーリングより効率的なアーキテクチャです。Hyperliquidは、従来型のHTTP Webhookプッシュ機能をプロトコルとして標準搭載しているわけではありません。そのため、開発者はWebSocket購読やオンチェーンイベント監視を使ってWebhookに近いリアルタイム通知を実現し、受け取ったイベントを独自のHTTPエンドポイントへ転送する構成を取るのが一般的です。
本記事では、Hyperliquidを「Webhook化」するための主要な連携パターンを整理し、実装に使えるコード例も紹介します。
Webhookパターンが必要な理由
従来のRESTポーリングには、主に次の課題があります。
- 高頻度ポーリングは帯域幅と計算リソースを浪費しやすい
- ポーリング間隔の分だけ、イベント検知に遅延が発生する
- 複数アカウントを監視する場合、ポーリング数がアカウント数に比例して増える
一方、Webhook / イベント駆動型の構成には次の利点があります。
- イベント発生時に即座に通知でき、レイテンシを抑えやすい
- サーバー側でポーリング状態を管理する必要がない
- 複数アカウント、複数ストラテジーへの拡張がしやすい
Hyperliquidでイベント駆動アーキテクチャを実装する際は、公式のWebSocketドキュメントが中核的な参考資料になります。
パターン1：WebSocket購読をHTTP Webhookへ転送する
最も一般的なのは、ローカル環境またはクラウド上で「ブリッジサービス」を動かす構成です。このサービスがHyperliquidのWebSocketを購読し、受信したイベントを整形してHTTP POSTで下流のシステムへ転送します。下流のシステムとしては、取引ボット、アラートシステム、データベース書き込みサービスなどが考えられます。
アーキテクチャ例：
Hyperliquid WS --> [ブリッジサービス] --> HTTP POST --> [下流コンシューマー]
ブリッジサービスの実装例（Python + FastAPI）：
import asyncio
import json
import httpx
import websockets
from fastapi import FastAPI
import threading
app = FastAPI()
WEBHOOK_TARGET = "https://your-downstream-service.example.com/events"
WS_URL = "wss://api.hyperliquid.xyz/ws"
async def ws_to_webhook(user_address: str):
async with websockets.connect(WS_URL) as ws:
# ユーザーの注文更新を購読
await ws.send(json.dumps({
"method": "subscribe",
"subscription": {"type": "orderUpdates", "user": user_address}
}))
# 約定履歴を購読
await ws.send(json.dumps({
"method": "subscribe",
"subscription": {"type": "userFills", "user": user_address}
}))
async for raw in ws:
event = json.loads(raw)
async with httpx.AsyncClient() as client:
await client.post(WEBHOOK_TARGET, json=event, timeout=5)
@app.on_event("startup")
def start_ws_listener():
user_addr = "0xYOUR_ADDRESS"
thread = threading.Thread(
target=asyncio.run,
args=(ws_to_webhook(user_addr),),
daemon=True
)
thread.start()
この構成では、Hyperliquid側のリアルタイムイベントを、既存のWebhookベースの社内システムや通知基盤に接続しやすくなります。
パターン2：サーバーレス関数を使う
低頻度のイベント、たとえば日次の資金調達率（funding rate）集計や定期的な市場状態チェックであれば、常時接続のWebSocketではなく、スケジュール実行されるサーバーレス関数でも対応できます。
AWS LambdaやCloudflare Workersのようなクラウド関数をcronで起動し、HyperliquidのREST APIを問い合わせ、処理結果をSlack、Telegram、社内システムなどへ送信する形です。
Cloudflare Workerの例（cronで1時間ごとに実行）：
export default {
async scheduled(event, env, ctx) {
const resp = await fetch("https://api.hyperliquid.xyz/info", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ type: "metaAndAssetCtxs" }),
});
const [meta, ctxs] = await resp.json();
// 資金調達率が0.05%を超える銘柄を抽出
const highFunding = ctxs
.map((ctx, i) => ({ coin: meta.universe[i].name, rate: parseFloat(ctx.funding) }))
.filter(x => Math.abs(x.rate) > 0.0005);
if (highFunding.length > 0) {
await fetch(env.SLACK_WEBHOOK_URL, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
text: `高い資金調達率のアラート：${highFunding.map(x => `${x.coin} ${(x.rate*100).toFixed(4)}%`).join(", ")}`
}),
});
}
}
};
リアルタイム性が不要な監視では、サーバーレス構成により運用負荷を抑えられます。一方、注文状態や約定の即時処理が必要な場合は、WebSocketベースのブリッジサービスの方が適しています。
パターン3：オンチェーンイベント監視（on-chain indexing）
Hyperliquidの取引データはオンチェーンにも書き込まれるため、理論上はオンチェーンイベントを監視して完全な取引記録を取得できます。HyperliquidのドキュメントではEVM互換RPCインターフェースが提供されており、ethers.jsやweb3.pyなど、一般的なEthereum向けツールを使ってログイベントを購読できます。
from web3 import Web3
HL_RPC = "https://rpc.hyperliquid.xyz/evm"
w3 = Web3(Web3.HTTPProvider(HL_RPC))
# 最新ブロックを監視
def handle_new_block(block_number):
block = w3.eth.get_block(block_number, full_transactions=True)
for tx in block.transactions:
# Hyperliquid関連コントラクトアドレスをフィルタリング
if tx.get("to") == "0xHYPERLIQUID_CONTRACT":
print(f"新しいトランザクション: {tx['hash'].hex()}")
w3.eth.subscribe("newHeads", handle_new_block)
オンチェーン監視は監査性や履歴の完全性を重視する用途に向いています。ただし、実装時には対象コントラクト、イベント形式、再編成（reorg）への対応などを慎重に確認する必要があります。
信頼性の確保：リトライと冪等性
本番環境では、Webhookの送信先が一時的に応答しないことがあります。そのため、ブリッジサービス側にはリトライ機構を実装しておくべきです。
import tenacity
@tenacity.retry(
stop=tenacity.stop_after_attempt(3),
wait=tenacity.wait_exponential(multiplier=1, min=1, max=10),
reraise=True,
)
async def send_webhook(client: httpx.AsyncClient, url: str, payload: dict):
resp = await client.post(url, json=payload, timeout=5)
resp.raise_for_status()
同時に、下流コンシューマー側では冪等処理を実装することが重要です。ネットワーク障害により同じイベントが再送される可能性があるため、各イベントに一意のIDを含め、処理済みIDをデータベースに記録して重複処理を防ぎます。
監視とアラート連携
Webhookイベントを監視システムに接続すると、次のような異常を素早く検知できます。
- 強制清算イベント（
liquidationタイプ）：即時にアラートを発し、証拠金の追加が必要か評価する - 大きな資金調達率の変化：保有ポジションのコストが想定を超えていないか確認する
- 注文拒否：証拠金不足やパラメータ不備を確認する
前述のブリッジサービスとGrafanaなどを組み合わせれば、Hyperliquid向けの監視ダッシュボードを構築できます。
OneKeyウォレット：自動売買を安全に実行するために
自動化されたWebhookシステムは、最終的にオンチェーン取引や注文実行をトリガーする場合があります。この段階で最も重要なのが秘密鍵の安全性です。
OneKeyハードウェアウォレットは、USBまたはBluetooth接続によるハードウェア署名を提供します。仮に自動化スクリプトが侵害されたとしても、物理デバイスなしにトランザクションへ署名することは困難です。
高頻度の自動化シナリオでは、HyperliquidのAgentアドレスの仕組みを活用し、ホットウォレットによる署名と、ハードウェアウォレットをVaultとして使う構成を検討できます。これにより、運用効率とセキュリティのバランスを取りやすくなります。
また、OneKey Perpsは永続先物（Perps）トレーダー向けの実行レイヤーとして活用できます。Webhook自動化システムと組み合わせることで、監視、シグナル処理、注文実行までを含む取引インフラを構築しやすくなります。
自動売買やPerps運用を始める前に、まずはOneKeyをダウンロードし、OneKey Perpsで実際のワークフローを確認してみてください。過度な期待ではなく、秘密鍵管理と実行環境を分離するための実用的な選択肢として検討するのがおすすめです。
よくある質問
Q1：HyperliquidはHTTP Webhookプッシュをネイティブにサポートしていますか？
いいえ。現時点で、HyperliquidはネイティブのHTTP Webhookを提供していません。リアルタイム通知はWebSocket経由で実現されるため、開発者が「WSからHTTPへ転送する」ブリッジ層を自前で構築する必要があります。
Q2：複数アカウントを監視する場合、WebSocket接続に性能上の問題はありますか？
各アカウントには個別のWebSocket購読が必要です。数十アカウント程度であれば、並列接続は十分現実的です。数千アカウント規模になる場合は、接続プールやasyncioのような非同期フレームワークを使った最適化を検討してください。
Q3：Webhookメッセージの偽造を防ぐにはどうすればよいですか？
ブリッジサービス内では、メッセージの発信元は自分で管理するWebSocketリスナーなので、通常は追加検証の必要性は限定的です。ただし、Webhookエンドポイントを外部の第三者に公開する場合は、HMAC署名検証などの仕組みを追加するべきです。
Q4：Cloudflare Workersの無料プランでHyperliquid監視は足りますか？
Workersの無料プランには1日あたりのリクエスト数制限（10万回/日）があります。1時間に1回の低頻度監視であれば通常は十分です。高頻度のリアルタイム監視には、有料プランまたは自前サーバーの利用を検討してください。
Q5：WebSocket購読のuserFillsとorderUpdatesは何が違いますか？
userFillsは注文が約定したときに、約定価格、数量、手数料などの詳細を通知します。orderUpdatesは注文の状態変化、たとえば送信、部分約定、キャンセルなどを通知します。両者は補完関係にあります。
リスクについて
本記事は技術アーキテクチャの参考情報であり、投資助言ではありません。自動売買システムには、コード上の欠陥、ネットワーク障害、API仕様変更、秘密鍵管理ミスなどのリスクがあります。十分なテストを行ったうえで、慎重に本番環境へデプロイしてください。
