日本株の自動売買ツール開発を続けています。
前回は、仮想注文を出すだけではなく、
「その注文が実際の市場なら約定していたのか?」
を市場データから判定し、約定した場合だけ仮想口座の現金や保有株へ反映する仕組みを作りました。
→ 仮想注文は本当に約定した?日本株Paper Tradingに約定判定を実装
これで、
AIが売買候補を判断する
↓
人間が確認する
↓
仮想注文を出す
↓
市場データから約定したか判定する
↓
仮想口座へ反映する
という流れがかなりつながってきました。
ここまで来ると、
「もうPaper Tradingを始めてもいいのでは?」
と思いたくなります。
しかし、実際に開発を進めてみると、もう一つ確認しておきたいことがありました。
それが、
「システムが正しく動いたことを、あとから確認できるのか?」
という問題です。
今回は、正式なPaper Tradingを始める前に、システムの動きを記録し、安全に動いたか確認する仕組みを追加した過程をまとめます。
仮想売買が動くだけでは不十分だった
ここまでの開発で、仮想注文から約定判定、仮想口座への反映まで動かせるようになりました。
しかし、
「とりあえずエラーが出ずに動いた」
だけでは、本当に問題がなかったのか分かりません。
例えば、
- どの注文を出したのか
- どの市場データを使って約定を判断したのか
- 同じ注文を二重に処理していないか
- 安全機能が正しく働いたか
- 仮想口座の現金や保有株に矛盾がないか
- プログラムを再起動しても状態がおかしくならないか
といったことを確認する必要があります。
特に自動売買では、
「問題が起きていないように見える」
ことと、
「問題が起きていないことを確認できる」
ことは別です。
そこでPaper Tradingを始める前に、
システムが何をしたのかを記録し、あとから確認できる仕組み
を追加することにしました。
システムの動きを記録する仕組みを追加
まず追加したのが、システムの動作を記録する仕組みです。
注文や約定だけではなく、
「いつ、何が起きたのか」
をあとから追えるようにしました。
今回の実装では、注文や安全確認などを含めて17種類の出来事を記録できるようにしています。
また、過去の記録を書き換えるのではなく、基本的には新しい記録を追加していく形にしました。
さらに、同じ処理がもう一度実行された場合でも、同じ内容を何度も記録しないようにしています。
一方で、証券会社APIの認証情報など、記録する必要のない重要情報は残さないようにしました。
これによって、
「このときシステムは何をしていたのか?」
をあとから確認しやすくなります。
「エラーが0件」だけでは安全とは判断しない

記録を残せるようにしたあと、次に考えたのが、
「何を確認できたらPaper Tradingへ進んでよいのか?」
です。
例えば、確認画面に、
重大なエラー:0件
と表示されていたら、安全そうに見えます。
しかし、そもそもエラーを確認するための記録が残っていなかったらどうでしょうか。
確認できる情報がないのに、
「エラーが見つからなかったから問題なし」
としてしまうのは危険です。
そこで今回は、確認結果を大きく3つに分けました。
問題なし
必要な記録がそろっていて、安全条件を確認できた状態です。
問題あり
安全条件に問題が見つかり、そのまま次へ進めない状態です。
確認できない
安全だったとも、問題があったとも判断できない状態です。
例えば、確認に必要な記録そのものが不足している場合です。
ここで重要なのは、
「確認できない=問題なし」にはしない
ことです。
必要な情報がなければ、Paper Tradingへ進まずに止めます。
利益が出たかどうかと安全性は分けて考える
Paper Tradingを始めたあとには、当然ながら損益も確認します。
ただし、
利益が出ているからシステムも安全
とは限りません。
仮に利益が出ていても、
- 同じ注文が二重に処理されている
- 必要な記録が残っていない
- 仮想口座の現金や保有株が合っていない
- 安全機能が正しく働いたか確認できない
のであれば、その状態で実運用へ進むのは危険です。
逆に、売買で損失が出たからといって、それだけでシステムが壊れているとも限りません。
そこで今回は、
「売買ルールが利益を出せるか」
と、
「システムが正しく安全に動いているか」
を分けて確認することにしました。
システムの記録と仮想口座が合っているか確認する
もう一つ確認するようにしたのが、
システムの記録と、仮想口座の状態が一致しているか
です。
例えば、
100株買った記録があるのに、仮想口座では200株保有していたら明らかにおかしい状態です。
同じように、
- 現金
- 保有株
- 注文
- 約定
などについて、処理した内容と現在の状態に矛盾がないか確認します。
一致していることを確認できれば問題なし。
一致しなかった場合や、そもそも確認するための情報が足りない場合は、そのまま先へ進まないようにします。
Paper Tradingを長期間動かす前に、
「仮想口座の数字を信用できる状態なのか」
を確認するためです。
最初から最後まで通してテスト
ここまでの仕組みを追加したあと、
売買処理を最初から最後まで動かして、途中で問題が起きないか
も確認しました。
テストでは20日分の売買処理を想定し、
- 売買処理が最後まで完了するか
- 安全上の問題が発生していないか
- 必要な記録が残っているか
- 仮想口座の状態に矛盾がないか
- Paper Tradingへ進むための条件を満たしているか
を確認しました。
その結果、テスト用に設定した条件では、Paper Tradingへ進むための安全条件をクリアできました。
さらに、これまで作ってきた機能を含めてテストを実行したところ、
972件のテストがすべて成功
しました。
ここまでを見ると、
「これでPaper Tradingを始められる」
ようにも見えます。
しかし、まだ正式には開始していません。
テスト成功=正式なPaper Trading開始ではない
今回確認できたのは、
テスト用に用意した条件の中で、一連の仕組みが正しく動いた
ということです。
実際の市場データを使って一定期間動かし、
「実際の相場でも問題なく運用できた」
ことを確認したわけではありません。
そのため、この段階ではまだ正式なPaper Trading開始とはしていません。
テストがすべて成功したことは大きな前進ですが、
「テストで動く」ことと「実際の市場で継続して動かせる」ことは別
と考えています。
次に問題になったのが「実際の日足データ」
安全確認の仕組みまで作ったことで、次は実際の日足データを使った確認へ進みました。
ところが、実際のデータを使ってみると、すぐに新しい問題が見つかりました。
主な問題は、
- 過去データを確認するための取引カレンダーが一部不足していた
- 取引時間中の、まだ完成していない当日の日足を取得してしまった
というものです。
特に日足を使って売買判断する場合、
「今日の株価データがある」
ことと、
「今日の日足が完成している」
ことは同じではありません。
取引時間中であれば、その日の始値・高値・安値・終値はまだ変化します。
その途中のデータを完成した日足として使ってしまうと、売買判断そのものが変わる可能性があります。
そこで次は、
「売買判断に使ってよい完成した日足だけをどう取得するか」
を確認することになりました。
この問題については、次の記事でまとめます。
まとめ
今回は、正式なPaper Tradingを始める前に、
システムが正しく動いたことを、あとから確認する仕組み
を追加しました。
今回の開発で特に重要だと感じたのは、
「動いたからOK」ではなく、「正しく動いたことを確認できるか」を見る
ことです。
そのために、
- システムの動きを記録する
- 問題があれば先へ進まない
- 必要な情報がなく確認できない場合も先へ進まない
- システムの記録と仮想口座の状態を照合する
- 最初から最後まで一連の動作をテストする
という仕組みを追加しました。
テストでは972件すべてが成功し、テスト用の条件ではPaper Tradingへ進むための安全条件もクリアしました。
ただし、
まだ正式なPaper Tradingを開始したわけではありません。
次は実際の日足データを使って、
「実際の市場データでも安全に動かせるのか」
を確認していきます。
KABU BUILDでは、完成した結果だけではなく、
作る → 試す → 問題を見つける → 改善する
という開発過程も引き続き公開していきます。


コメント