CP_blog の最初の記事として、この研究がテストネットを起点にする理由を整理しておく。
前提
AI 自動売買システムの開発では、「ロジックが正しいか」よりも先に確認すべきことが多い。注文が意図した形で発行されるか、エラー時に何が起きるか、接続が切れたときにポジションがどうなるか。これらはロジックの良し悪しとは無関係に、システムを壊す要因になる。
実資金の環境でこれらを確認するのは、順序として誤っていると考えている。
テストネットで確認したいこと
テストネットは市場のリアリティに欠けるとよく言われるし、それは事実である。しかし、この段階で確認したいのは市場のリアリティではなく、システムの機械的な挙動である。
- 注文ライフサイクルの理解 — 発注、部分約定、キャンセル、拒否。それぞれのケースで API が何を返し、自分のシステムがどの状態に遷移するか。
- 異常系の挙動 — レート制限、タイムアウト、WebSocket の切断、取引所側のメンテナンス。正常系だけ動くシステムは、動くとは言えない。
- 状態の整合性 — システムが把握しているポジション・残高と、取引所側の実際の値がずれたとき、それを検出できるか。
- 停止処理 — 停止を指示してから、実際に安全な状態（新規注文なし、未約定注文の整理済み）に至るまでの流れが機能するか。
これらはすべて、実資金がなくても検証できる。逆に言えば、これらを実資金で検証する理由は存在しない。
テストネットの限界も記録しておく
テストネットを使う以上、その限界も前提として明記しておく。
- 板が薄く、約定の滑り方が本番と異なる
- 参加者の行動が本番市場と異なるため、価格系列そのものの参考価値は低い
- 手数料体系や細かい仕様が本番と一致しない場合がある
したがって、テストネットで得られた損益の数値には意味を持たせない。テストネットの成果物は「システムが仕様どおりに動き、仕様どおりに止まる」ことの確認記録だけである。
次の段階への条件
テストネット段階を「完了」とみなす条件は、現時点では次のように考えている。今後の検証で見直す可能性がある。
- 上記 1〜4 の各項目について、確認手順と結果が記録されていること
- 特に停止処理について、意図的に異常を発生させた状態でも停止が完了することを確認していること
この条件を満たしたとしても、次の段階は実資金投入ではない。バックテストの精緻化と、Cash Cockpit 側の安定化が先にある。この順序については別の記事で扱う。