HyperliquidでマーケットメイクBotを構築する方法
-
hyperliquid market maker
-
hl market maker tutorial
-
hyperliquid マーケットメイクBot
-
オンチェーン無期限先物のマーケットメイク
-
hyperliquid api マーケットメイク
マーケットメイク（Market Making）は、金融市場で古くから使われてきた取引戦略の一つです。マーケットメイカーは買いと売りの両側に同時に指値注文を出し、スプレッドから収益を狙う一方で、市場に流動性を提供します。
Hyperliquidのようなオンチェーン無期限先物取引所が普及したことで、機関投資家でなくても、個人開発者や小規模なクオンツチームが公開APIを使ってマーケットメイクに参加しやすくなりました。本記事では、Hyperliquid上でマーケットメイクBotを構築するための考え方を、戦略ロジック、技術アーキテクチャ、リスク管理、そしてOneKeyハードウェアウォレットを使った署名鍵の保護まで整理して解説します。
無期限先物におけるマーケットメイクとは
従来の現物市場では、マーケットメイカーは実物の在庫を保有します。一方、無期限先物市場における「在庫」は、ネットのロングまたはショートのエクスポージャーとして表れます。
理想的なマーケットメイカーは、できるだけデルタニュートラルな状態を維持し、価格の方向性に賭けるのではなく、買い注文と売り注文を頻繁に更新しながらスプレッドの獲得を目指します。
Hyperliquidのオーダーブック構造は中央集権型取引所に近い一方で、決済はオンチェーンで行われ、資金はユーザー自身がセルフカストディします。注文タイプ、手数料体系、API仕様については公式ドキュメントで詳しく説明されており、マーケットメイクBotを開発する際には必ず確認すべき資料です。
マーケットメイクBotの基本ロジック
スプレッド計算
最もシンプルな対称型マーケットメイク戦略では、ミッド価格（mid price）の上下に一定割合のスプレッドを置いて注文を出します。
買い価格 = mid_price * (1 - spread / 2)
売り価格 = mid_price * (1 + spread / 2)
spreadは、少なくとも次のコストやリスクをカバーできる水準に設定する必要があります。
- 取引手数料（Taker fee）
- 予想される不利な価格変動（Adverse selectionリスク）
- 資金調達率の変動に伴うヘッジコスト
各マーケットの手数料階層はHyperliquid公式ドキュメントで確認し、自分の資金規模や取引頻度に合ったスプレッドの基準を決めることが重要です。
注文更新ロジック
市場価格は常に変動するため、指値注文は定期的に更新し、妥当な価格で提示し続ける必要があります。一般的な更新トリガーは次のとおりです。
- 時間トリガー：一定時間ごと、例えば5秒ごとに更新する
- 価格乖離トリガー：市場のミッド価格が現在の注文価格から一定以上離れたら即時更新する
- 約定トリガー：注文が約定したら、すぐに再発注して流動性を補充する
実運用では、複数のトリガーを組み合わせるのが一般的です。更新頻度が高すぎると不要なAPIリクエストや手数料負担が増え、低すぎると古い価格の注文が狙われやすくなります。
在庫リスク管理
マーケットメイクでは、片側の注文だけが連続して約定し、もう片側が約定しないことで在庫が偏ることがあります。その結果、ネットポジションが中立から外れます。在庫リスクは、マーケットメイクにおける主要なリスクの一つです。
主な対処方法は次のとおりです。
- ポジション・スキュー（skewing）：ネットロングを持っている場合、買い価格と売り価格の両方を下方向に調整し、売りを促しながら買いを抑制することで、受動的にポジションを中立へ戻す
- ハードなポジション制限：ネットポジションが一定の閾値を超えた場合、偏りをさらに増やす方向の注文を停止し、ポジションが戻るまで待つ
# 疑似コード：ネットポジションに基づく価格スキュー
position = get_net_position("BTC") # 正の値はロング、負の値はショート
skew_factor = -position * inventory_risk_param # inventory_risk_param は調整可能なパラメータ
bid_price = mid_price * (1 - spread / 2) + skew_factor
ask_price = mid_price * (1 + spread / 2) + skew_factor
システムアーキテクチャの概要
完全なマーケットメイクBotは、主に次のモジュールで構成されます。
┌─────────────────────────────────────────────────────┐
│ マーケットメイクBotのメインループ │
├──────────────┬──────────────┬────────────────────────┤
│ データ層 │ 戦略層 │ 実行層 │
│ │ │ │
│ WebSocket │ ミッド価格計算 │ REST APIで発注/取消 │
│ 板情報購読 │ スプレッド計算 │ バッチ注文管理 │
│ 約定通知 │ 在庫スキュー │ 署名（OneKeyハードウェア層）│
│ │ ポジション管理 │ │
└──────────────┴──────────────┴────────────────────────┘
│ │
市場データ入力 Hyperliquidへの注文送信
- データ層はWebSocketを通じてオーダーブックのスナップショットや約定データをリアルタイムに購読します。詳細はHyperliquidドキュメントのWebSocketセクションを確認してください。
- 戦略層は最新データをもとに新しい気配値を計算します。
- 実行層はREST APIで注文の一括取消と再発注を行い、EIP-712の構造化署名を使ってリクエストの安全性を確保します。
技術実装のポイント
REST APIで注文を出す
バッチ注文APIを使うと、買い側と売り側の注文を一度のリクエストで同時に送信でき、ネットワーク遅延を抑えやすくなります。
def refresh_quotes(exchange, coin, bid_px, ask_px, order_size):
# 先に既存注文を一括取消
open_orders = get_open_orders(coin)
if open_orders:
cancel_ids = [o["oid"] for o in open_orders]
exchange.bulk_cancel(coin, cancel_ids)
# 新しい気配値を一括送信
new_orders = [
build_limit_order(coin, is_buy=True, px=bid_px, sz=order_size),
build_limit_order(coin, is_buy=False, px=ask_px, sz=order_size),
]
return exchange.bulk_orders(new_orders)
WebSocketで約定を監視する
RESTのポーリングだけでは、約定通知のリアルタイム性が不足する場合があります。そのため、WebSocketでユーザーの約定イベントを購読する必要があります。
def on_user_fill(fill_data):
coin = fill_data["coin"]
side = fill_data["side"] # "B" は買い約定 / "A" は売り約定
sz = fill_data["sz"]
px = fill_data["px"]
update_inventory(coin, side, sz, px)
trigger_quote_refresh(coin) # 約定後すぐに気配値を更新
WebSocket接続は一時的に切断されることがあります。必ず自動再接続ロジックを実装し、再接続後にはすべてのチャンネルを再購読し、ローカル状態をリセットまたは再同期してください。
主なリスク分析
マーケットメイクは「無リスク裁定」ではありません。特に以下のリスクには注意が必要です。
- 急激な価格変動により、片側の注文だけが連続して約定し、大きなポジションを抱えるリスク
- 板が薄い時間帯やボラティリティ上昇時に、スプレッド収益以上の在庫損失が発生するリスク
- WebSocket切断、API遅延、注文取消失敗などの技術的リスク
- 資金調達率、手数料、スリッページが想定より悪化するリスク
- 秘密鍵やAPI権限の管理不備による資金流出リスク
リスクを過小評価せず、ポジション上限、損失上限、注文停止条件、監視アラートをあらかじめ設計しておくことが重要です。
OneKeyハードウェアウォレット：Botの鍵管理におけるベストプラクティス
マーケットメイクBotは頻繁に取引へ署名する必要があります。しかし、頻繁に署名するからといって、セキュリティ基準を下げるべきではありません。
OneKeyハードウェアウォレットは、秘密鍵をネットワークから隔離された安全なチップ内に保管します。仮にサーバーが侵害されたとしても、攻撃者は秘密鍵そのものをエクスポートできません。
推奨される構成は次のとおりです。
- HyperliquidのAPI Agent機能を使い、Bot用の独立したサブアカウントウォレットを作成し、メインアカウントに紐づける
- サブアカウントウォレットの秘密鍵をOneKeyハードウェアウォレットで管理する
- Botロジックが取引メッセージを作成し、ローカル署名サービス経由でOneKeyに署名を依頼する
- 署名済みリクエストをHyperliquidへ送信する
この構成では、仮にBotのコードに悪意あるロジックが注入されたとしても、OneKeyハードウェア側での確認を経ずに資金を移動することは困難になります。
パフォーマンス最適化のヒント
- 取消と再発注をできるだけ一体化する：Hyperliquidはcancel-and-placeのバッチインターフェースをサポートしています。
Alo（Post-only）注文タイプを優先的に使い、Maker手数料のメリットを活用します。- 各約定のタイムスタンプ、価格、数量を記録し、定期的に戦略パフォーマンスを分析します。損益要因は、スプレッド収益と在庫損失に分けて確認すると有用です。
- サーキットブレーカーを実装します。口座損失が日中の閾値を超えた場合、自動的にBotを停止し、アラートを送信します。
よくある質問
Q1：Hyperliquidでマーケットメイクを始めるには、どのくらいの資金が必要ですか？
Hyperliquidには、公式に定められた最低マーケットメイク資金はありません。実際の参入ハードルは、対象市場の価格や最小注文数量によって変わります。まずは極小サイズで戦略ロジックをテストし、システムが安定していることを確認してから、段階的に規模を上げることをおすすめします。
Q2：マーケットメイクBotの収益源は何ですか？
主な収益源は買値と売値のスプレッドです。近い価格帯で買い注文と売り注文がそれぞれ約定すると、その差額から手数料を差し引いた分が収益になります。市場が活発で出来高が多いほど収益機会は増えますが、同時に競争も激しくなります。
Q3：実資金をリスクにさらさずにBotをテストする方法はありますか？
Hyperliquidはテストネット環境を提供しています。公式ドキュメントのテストネット設定を参照し、APIエンドポイントをテストネットに切り替えることで、実資金を使わずにデバッグできます。
Q4：OneKeyハードウェアウォレットはBotのパフォーマンス上のボトルネックになりますか？
OneKeyの署名速度は、多くのクオンツ戦略にとって十分実用的です。一方で、毎秒数十回の署名を必要とするような超高頻度のケースでは、API Agentウォレット構成と組み合わせ、高頻度操作をホットウォレットに委任しつつ、OneKeyでメインアカウントや資金移動を管理する設計も考えられます。安全性とパフォーマンスのバランスを取ることが重要です。
Q5：APIレート制限にはどう対応すればよいですか？
Hyperliquidにはリクエスト頻度の制限があります。具体的な閾値は公式ドキュメントを確認してください。実装面では、トークンバケット方式でリクエスト頻度を制御し、HTTP 429などのレート制限レスポンスを受け取った場合は、自動的にバックオフして再試行する仕組みを入れるとよいでしょう。
まとめ
HyperliquidでマーケットメイクBotを構築することは、クオンツ金融、システムエンジニアリング、ブロックチェーンセキュリティを組み合わせる実践的な取り組みです。スプレッド計算から在庫管理まで、あらゆる部分に改善余地があります。また、ソフトウェア秘密鍵からOneKeyハードウェア署名へ移行することで、運用上のセキュリティを一段高めることができます。
まだゼロからBotを開発する段階ではない場合は、まずOneKeyをダウンロードして、OneKey Perpsの無期限先物取引インターフェースを試してみるのも現実的な方法です。実際の市場構造、注文タイプ、ポジション管理の流れを確認してから、自動化戦略を構築するかどうかを検討できます。
Hyperliquid Appで取引体験を確認するか、Hyperliquid公式ドキュメントでAPIの詳細を確認してください。
リスク提示： マーケットメイクは高リスクなクオンツ取引戦略であり、市場変動、技術的障害、戦略の不調により大きな損失が発生する可能性があります。無期限先物のレバレッジ特性は潜在的な損失を拡大します。本記事は技術学習を目的とした参考情報であり、投資、取引、法務、税務その他の助言ではありません。ご自身のリスク許容度を十分に評価し、居住地域の法令を遵守したうえで慎重に判断してください。
