暗号資産の取引ボットを開発するとき、「中央集権型取引所（CEX）用に組んだコードを、そのままオンチェーン DEX に流用できるだろう」と考えがちです。ところが実際には、データ取得の流れから監視体制、リスクガードに至るまで設計思想が大きく異なります。本記事では、CEX ボットと Hyperliquid のようなロールアップ系 DEX ボットを比較しながら、価格フィード、注文執行、監視ポイント、ガス管理などの要点を整理します。まずは“最小限のガード”で素早く運用を始めるアプローチを紹介し、そのうえで段階的に監視レイヤを厚くしていくロードマップをまとめます。CEX 向けのボット開発経験はあるものの、オンチェーン運用はこれからという方に、実践的な指針をお届けできれば幸いです。
監視機構を最低限整えてCIテストも通したので、ここからは最低限のガード機構だけ整備して実弾テスト回すフェーズ。サクサク進んでいる。 https://t.co/XggY7QjWec pic.twitter.com/bf9D4K9dky
— よだか(夜鷹/yodaka) (@yodakablog) June 17, 2025
1. イントロ──なぜ「同じトレードボット」でも作りが変わるのか
CEX と DEX は、ユーザーから見るとどちらも「板情報を取得して、約定させるための API」を提供している点で似ています。しかし、裏側のアーキテクチャはまったく異なります。CEX では撮合エンジンが取引所の内部サーバー群で完結し、WebSocket と REST API はその撮合結果をクライアントへ運ぶだけです。一方、オンチェーン DEX──とくにロールアップ型──では、撮合（順序付け）を担う Sequencer と、トランザクションをファイナライズする L1（L2）のブロックチェーンが分離されています。
この構造の違いが、ボット開発者に次のような影響を与えます。
- データ取得レイヤの役割が変わる
CEX では「WS＝差分ストリーム」「REST＝スナップショット補完」が定番ですが、オンチェーン DEX では「WS＝価格フィード」「RPC＝注文送信／ブロック情報」と二系統に分かれます。 - レイテンシの支配要因が異なる
CEX ではネットワーク RTT（数ミリ秒）が勝負になりますが、オンチェーンではブロック確定や Sequencer スロット長（数百ミリ秒）がボトルネックです。 - 監視ポイントが増える
CEX では WS 落ち・REST 429・API Key BAN などが主な故障要因ですが、オンチェーンではさらに「Sequencer Outage」「RPC 遅延」「TVL ドロップ」「ガス高騰」など、複数レイヤを個別に監視する必要があります。
本記事では、まず Hyperliquid DEX ボットで実際に導入した最小限の監視ガード（WS 再接続、ping/pong、プロセスハートビートなど）を軸に、CEX ボットとの違いを順に紐解いていきます。そのうえで、どの段階でどの監視を厚くすべきかというロードマップを示し、開発と運用の両面での意思決定をサポートします。
2. データ取得レイヤ──REST＋WS と WS＋JSON-RPC の違い
2-1. CEX の定番アプローチ
中央集権型取引所では、多くの場合「WebSocket でリアルタイム差分」「REST でスナップショット」という二段構えが推奨されています。
- WebSocket
- 板の更新（
depthUpdate/l2Bookなど） - 約定ティック（
trade） - ユーザー注文イベント（
executionReport）
- 板の更新（
- REST
/depthや/bookTickerで板の全量を取得/aggTradesでヒストリカル約定をダウンロード
ボットはまず REST で最新スナップショットを取り込み、そこに WS の差分を順番に適用して “最新状態” を構築します。WS が瞬間的に切断されても、再接続後に再び REST スナップショットを取ればロスト分を補完できる設計です。
2-2. Hyperliquid（独自 L1"ロールアップ構造"）のデータ設計
一方、Hyperliquid では価格系データは基本的に WebSocket 側に集約されており、REST は「ヒストリカル取得」あるいは「オンチェーン証跡 API」の役目が中心です。
| API | 主な役割 |
|---|---|
WebSocket wss://api.hyperliquid.xyz/ws | trades・l2Book など “プッシュ型” データを高速配信 |
REST https://api.hyperliquid.xyz/info | recentTrades・candle で履歴取得、オンチェーン state のスナップショット |
撮合順序は Sequencer が管理し、ブロックチェーン上でファイナライズされるため、「REST から板スナップショットを頻繁に取得して差分を合成する」必要がほぼありません。
その代わり、注文送信やブロック情報取得は JSON-RPC を通じて行う形になります（送信先は default.yml の rpc_endpoints に列挙）。
2-3. 開発時に意識すべき違い
| 観点 | CEX ボット | Hyperliquid ボット |
|---|---|---|
| スナップショットの頻度 | WS 再接続時ごとに REST 取得 | 基本不要。ローカルキャッシュが壊れた場合のみ REST |
| 帯域コスト | 板全量（数百 KB）を定期取得 | 主に WS 差分のみ |
| 再接続ポリシー | WS→REST→WS の三段リカバリ | WS 自動再接続＋RPC 健康チェック |
| 新たな通信経路 | ほぼ不要 | JSON-RPC (注文送信・ブロック番号) |
2-4. 当プロジェクトでの現在の実装状況
- WebSocket
trades購読 …api.stream_trades()で実装済み - REST
recentTrades… テスト・バックテスト用に呼び出しのみ実装 - JSON-RPC（注文送信 / ping） … 次フェーズで
monitors.bridge_healthと戦略執行にて追加予定
ポイント
- 価格フィードは WS 一本でリアルタイム性を最優先。
- スナップショット取得は「壊れたときだけ REST」で十分。
- そのぶん Sequencer 健康度（RPC）を別レイヤで監視する必要が出てくる──これが CEX ボットとの大きな構造差です。
補足：Hyperliquidでのデータ取得
補足 — 注文送信経路について
Hyperliquid では、オンチェーン操作を行う場合は HyperEVM の JSON-RPC でトランザクションを送信しますが、従来どおり 公式 REST エンドポイント/tradeを叩いて注文を出すことも可能です。運用環境やライブラリの都合に応じて、
- JSON-RPC（署名済みトランザクションを送信）
- Trade REST API（API キー認証で撮合サーバへ直接リクエスト）
のいずれか、または両方をフォールバックとして併用できます。
3. 注文執行とレイテンシ──撮合サーバとブロックタイムの壁
3-1. CEX におけるレイテンシの意味
中央集権型取引所では、注文は撮合サーバ（マッチングエンジン）へ直接送られます。撮合はミクロ秒～数ミリ秒単位で完結し、約定価格は撮合順に即座に確定します。そのためボット開発者は、ネットワーク往復時間（RTT） と 撮合キュー遅延 を主な最適化対象にします。
— Ping が 5 ms から 3 ms に速くなれば、そのぶん「先に板に乗る」あるいは「板を刈る」確率が上がる、というイメージです。
3-2. Hyperliquid（ロールアップ DEX）のレイテンシ構造
Hyperliquid では「撮合順序＝Sequencer がブロックへ並べる順序」が確定し、ブロック or スロットの確定間隔（おおむね 300 ms 前後）が最小単位になります。つまり、あなたの注文が 50 ms 早く届いても「同じスロットに入るか否か」でレイテンシ優位は頭打ちになります。
さらに、注文はブロックチェーン上で確定するため、最終確定（L1 反映） までは 1 ～ 2 秒の重ね遅延があります。
| レイヤ | CEX（撮合サーバ） | Hyperliquid（Sequencer + ブロック） |
|---|---|---|
| ネット RTT | 1 〜 10 ms | 1 〜 10 ms |
| 撮合／スロット | 1 〜 5 ms | 300 ms 前後 |
| ファイナライズ | 内部確定ほぼ即時 | L1 Commit 1 〜 2 秒 |
実務上の示唆
- ネットを 10 ms → 3 ms に短縮しても、ブロック確定 300 ms に隠れて優位性は限定的。
- その代わり、ガス価格を上げて優先度付けする選択肢がある。
- 「slot 内で約定しなかったらキャンセル」など、スロット境界を意識したアルゴ が重要。
3-3. 監視ポイントの差
| 監視項目 | CEX で重視 | DEX で重視 |
|---|---|---|
| ネット RTT | ◎ | △（あくまでも基礎） |
| 撮合キュー遅延 | ◎ | ―（撮合は Sequencer が一元） |
| スロット／ブロック遅延 | ― | ◎ - Sequencer slot time |
| ガス高騰 | ― | ◎ - 優先度 & 手数料管理 |
| Reorg / Sequencer 落ち | ― | ◎ |
3-4. プロジェクトでの実装方針
- WS RTT モニタ（次フェーズ）でピン遅延を計測し、突発的に 1 s 以上長引いたら再接続。
- ガス残高ウォッチを実装し、少額残高なら Slack Warn → 自動クールダウン。
- Sequencer slot time 監視（ブロック間隔が閾値を超えたらアラート）を BridgeHealth に組み込み。
このように、CEX ボットで使ってきた「ミリ秒レイテンシ最適化」よりも、スロット境界をどう越えるか／ブロック確定が遅れたらどうするか が、オンチェーン DEX では勝負どころになります。
4. 監視ポイントのシフト──WS 再接続から TVL ウォッチまで
4-1. CEX での“定番監視”
中央集権取引所ボットの監視は、概ね下記３系統で完結します。
| 系統 | 代表的な指標 | 障害時の挙動 |
|---|---|---|
| WebSocket | 接続断・ping/pong 応答 | WS 切断 → REST へフォールバック |
| REST | 429（Rate-limit）・5xx | バックオフ再試行 |
| API Key / 取引所ステータス | メンテナンス告知 | 取引停止・アラート |
つまり「通信断＝同一ベンダ内の別 API へ切り替えれば済む」という単一レイヤの世界観で設計できます。
4-2. DEX で増える監視対象
オンチェーン DEX では、撮合レイヤと確定レイヤが分かれるため、見るべきポイントが増えます。
| レイヤ | 監視項目 | 目的 |
|---|---|---|
| WebSocket | 再接続・ping/pong RTT | 価格ストリームの生存確認 |
| RPC / Sequencer | eth_blockNumber RTT、slot 遅延 | 注文が確定しない／reorg 兆候 |
| ガス残高 | Wallet ETH / USDC 残量 | 送信失敗を未然に防ぐ |
| TVL / Vault | プロトコル全体の資産推移 | ハック・Rug リスク検知 |
| PnL / DD | 日次ドローダウン | 自動クールダウン発火 |
4-3. きょう実装した“最小ガード”
| 監視点 | 実装スクリプト | 動作概要 |
|---|---|---|
| WS 再接続 | api.stream_trades() | 例外捕捉 → 指数バックオフ |
| WS ping/pong | collector.periodic_heartbeat() | 未応答45 s → 再接続 |
| プロセス Heartbeat | monitors.heartbeat | 30 sごとに 💓 ログ |
ここまでで保証されること
- 価格フィードが途切れたら自動で立て直す
- ボット自体がフリーズしたら外形監視ですぐ検知
- データ損失はバッファ flush で最小化
4-4. 次フェーズで厚くする監視
| 追加予定 | 具体策 | いつ着手 |
|---|---|---|
| RPC ヘルス | monitors.bridge_health で複数 endpoint を ping | 戦略がオンチェーン注文を投げる前 |
| レイテンシ RTT | monitors.latency で ws.ping() 往復を計測 | 滑りが目立ち始めたら |
| TVL / Vault Watch | /tvl API 監視 → Slack Critical | 本資金を大きく預ける前 |
| ドローダウンガード | PnL 集計 → 閾値超えで自動停止 | 実額運用に移行後 |
4-5. まとめ
CEX ボットで重要だった「WS が落ちたら REST に切り替える」という単純なフォールバックは、オンチェーン DEX では通用しません。代わりに “レイヤごとに独立した監視” を置き、異常レイヤだけをリカバリする構造が求められます。
本プロジェクトではまず WS レイヤを完全自律復旧できる状態にし、実運用で得たログを基に RPC・TVL などの監視を段階的に追加していく方針です。
5. ガス & 手数料管理──二重在庫をどう守るか
オンチェーン DEX では、取引手数料とは別に ガス（L2 ネイティブ通貨） が必須です。Hyperliquid の場合、USDC 証拠金 + （必要に応じて）HYPE ガス の “二つの残高” を常に意識しなければなりません。
ガス残高が底を突くと、API は生きていても注文トランザクションが Revert し、ポジション解消やリスクヘッジが不能 になる点が CEX との決定的な違いです。
| 監視対象 | しきい値例 | アクション案 |
|---|---|---|
| ETH ガス残高 | 0.01 ETH 未満 | Slack Warn → 自動クールダウン |
| ガス単価 | 100 gwei 超 | 手数料％を上限にスリッページ拡張 or 発注停止 |
| 手数料バケット | USDC 証拠金 5 % 未満 | 証拠金自動補充（ブリッジ） or 取引サイズ縮小 |
現行コードでは ガス残高チェックは未実装 ですが、次フェーズで RPC 呼び出し (eth_getBalance) を追加し、Slack へ残高警告を送る予定です。
6. リスクガード戦略──ハッキング・Rug・Reorg に備える
CEX 運用では「API Key BAN やシステムメンテ」が主な停止要因ですが、オンチェーン DEX ではさらに以下のリスクを監視に組み込む必要があります。
| リスク | 発生ケース | ガード例（実装予定） |
|---|---|---|
| TVL 急減 | ハッキング / 資本流出 | vault_watch: 1 h で -5 % ドロップ → 全ポジション決済 |
| Sequencer Outage | Sequencer 停止 / L2 ネットワーク分断 | bridge_health: ブロック生成間隔が閾値超過 → Slack Critical |
| Reorg / Fork | L1 再組成 | 取引結果ハッシュの二重チェック、再送ロジック |
| ガス高騰 DoS | メンテナンス or ミームコイン祭り | 上限 gwei 監視 → 発注スロットリング |
今回の整備では Sequencer や TVL の監視はまだ空ファイル です。まずは少額・短時間でリアルログを取り、発生頻度と影響度を測った後に実装するのが効率的です。
7. まとめ──ミニマム稼働で学びを最速ループへ
- 通信レイヤ
- WebSocket 再接続 & ping/pong 監視を実装し、価格フィードは自律復旧できる状態になりました。
- 監視体制の第一歩
- プロセス Heartbeat とログローテートで「止まったら必ず気付く」最低ラインを確保しました。
- 次フェーズ
- RPC ping・ガス残高・TVL などオンチェーン特有の指標を段階的に追加し、実運用データから優先度を判断します。
まずは 小資本で24 時間稼働させ、得られたログを分析して戦略と監視項目を磨く――これがオンチェーン DEX ボット開発を加速させる最短ルートです。本記事が、CEX 向けの知識を持つ開発者の皆さまが DEX へステップアップする際のガイドになれば幸いです。