ランブック

デスク準備チェックリストと統合認定テストの完全版です。

デスク準備チェックリスト

本番稼働の前に、以下を確認してください。

API接続

• ステージングエンドポイントのテスト完了
• 本番エンドポイントの設定完了（利用可能な場合）
• ヘルスチェックエンドポイントが応答している
• WebSocket接続が安定している

認証

• EIP-712署名が動作している
• エージェント認可の設定完了（該当する場合）
• ノンス管理の実装完了
• 署名検証のテスト完了

クオートシステム

• 一括注文発注のテスト完了
• 注文ライフサイクルの照合検証完了
• 約定トラッキングの実装完了
• キャンセル機能のテスト完了

リスク管理

• MMPの設定とテスト完了
• 証拠金モデルの理解
• ティア制限の検証完了
• ポートフォリオ監視の実装完了

モニタリング

• WebSocketフィードの購読完了
• 注文/約定の照合の自動化完了
• ヘルスチェックの設定完了
• アラートの設定完了

キルスイッチ

• 全注文をキャンセルできる
• 即座に切断できる
• 緊急時手順の文書化完了

ヘッジ

• Hyperliquidパーペチュアルとの統合検証完了
• デルタヘッジ戦略の実装完了
• パーペチュアル証拠金計算の理解

決済

• 満期処理のテスト完了
• ポジション決済の検証完了
• 参照価格ソースの理解

統合認定テスト

テスト1: 注文発注

手順:

1. POST /order で単一注文を発注する
2. 注文ステータスを確認する: ACKED → OPEN
3. GET /orders?wallet=... に注文が表示されることを確認する
4. WebSocketの order_updates を受信したことを確認する

期待結果: 注文が正常に発注され、ステータス更新が受信される

テスト2: 一括注文発注

手順:

1. POST /bulk_order で10件の注文を発注する
2. すべての注文が受理されたことを確認する
3. RESTとWSで注文ステータスを確認する
4. 署名/認証エラーがないことを確認する

期待結果: すべての注文が正常に発注される

テスト3: 約定トラッキング

手順:

1. 約定する注文を発注する
2. WebSocketの fills チャネルを監視する
3. 正しい order_id で約定を受信したことを確認する
4. GET /fills?wallet=... に約定が表示されることを確認する
5. 注文ステータスが FILLED に更新されることを確認する

期待結果: 約定が正しくトラッキングされ、注文ステータスが更新される

テスト4: 部分約定トラッキング

手順:

1. 部分的に約定する注文を発注する
2. WebSocketの fills チャネル（order_updates ではない）を監視する
3. 部分約定を受信したことを確認する
4. order_id ごとに約定を集計して約定済みサイズを計算する
5. 注文ステータスが OPEN のままであることを確認する（WSでは PARTIALLY_FILLED にならない）

期待結果: 部分約定が fills チャネル経由でトラッキングされ、注文ステータスが正しい

テスト5: 注文キャンセル

手順:

1. POST /order で注文を発注する
2. DELETE /order で注文をキャンセルする
3. 注文ステータスを確認する: CANCELED
4. WebSocketの order_updates を受信したことを確認する

期待結果: 注文が正常にキャンセルされ、ステータス更新が受信される

テスト6: MMPトリガー

手順:

1. POST /mmp-config でMMPを設定する
2. MMP有効の注文を発注する
3. 制限を超過してMMPをトリガーする
4. MMP理由で注文がキャンセルされたことを確認する
5. 他のMMP有効注文もキャンセルされたことを確認する

期待結果: MMPが正しくトリガーされ、注文がキャンセルされる

テスト7: 証拠金による拒否

手順:

1. 証拠金を超過する注文を発注する
2. 「Insufficient margin」の理由で注文が拒否されたことを確認する
3. 拒否理由に必要額、利用可能額、不足額が含まれることを確認する
4. 注文ステータスを確認する: REJECTED

期待結果: 明確な理由とともに注文が拒否される

テスト8: ティア制限

手順:

1. ロング限定アクセスに設定されたウォレットを使用する
2. ロング（買い）ポジションを持たない状態で売り注文の発注を試みる
3. ティア理由で注文が拒否されたことを確認する
4. 買い注文を発注する（成功するはず）
5. クローズのための売り注文を発注する（成功するはず）

期待結果: ティア制限が正しく適用される

テスト9: WebSocket再接続

手順:

1. WebSocketに接続する
2. チャネルを購読する
3. WebSocketを切断する
4. 指数バックオフで再接続する
5. チャネルを再購読する
6. RESTをポーリングして見逃した更新をキャッチアップする

期待結果: 再接続が動作し、ステートが復元される

テスト10: ポートフォリオ照合

手順:

1. 注文を発注し約定させる
2. GET /portfolio?wallet=... でポートフォリオを確認する
3. ポジションが約定と一致することを確認する
4. 証拠金使用量が正しいことを確認する
5. WebSocketの portfolio 更新と照合する

期待結果: ポートフォリオの状態が正確で、照合が成功する

本番稼働の準備

本番稼働前チェックリスト

• すべての統合テストに合格
• モニタリングとアラートの設定完了
• キルスイッチのテスト完了
• 緊急時手順の文書化完了
• インシデント対応に関するチームトレーニング完了
• サポート連絡先の特定完了

稼働開始チェックリスト

• ステージング環境の完全なテスト完了
• 本番エンドポイントの検証完了
• モニタリングダッシュボードの準備完了
• アラートの設定完了
• チームのオンコールスケジュールの確立完了
• ドキュメントのレビュー完了

参考資料

• クイックスタート: クイックスタート
• APIリファレンス: REST API
• エラーと拒否: エラー
• インシデントプレイブック: インシデント