生データがないと自分がトレードした内容と、実際に検証したデータとの乖離の検証自体ができない。他から入手したデータはお金を払ったとしても使えないデータであることが多い。最近の相場であれば、1年間の生データがあるだけで十分使える。検証用のデータが入手できれば、次はバックテストと行う。いうような形で価格を流した時、安値で買いエントリーして高値で決済するロジックができやすい。2つの決済ロジックを導入していると、良い方の価格で決済されてしまう場合がある。累積系の分析等をシステムに組み込んでしまうと、システムを稼働した時期によって差がでてしまい、リアルトレードとバックテストとの差が生じた時の原因究明に大きな支障をきたすことになる。私は最近、これに嵌まりました。高速化をするべく、近似した累積移動平均などを使ってしまっていたが、リアルトレードとの差が生じてしまい、損失の原因究明ができなくなってしまった。再現性の取りにくい方法は使わないこと¶より限られた条件の中で、より少ない計算量で良質な分析を行えるようにする。自分が使っている検証ソフトの持っている特性と落とし穴をよく知り、その上でより精査なバックテストの検証を行うようにする。実際のバックテストは高速化のため、始値ベース、もしくは終値ベースでのバックテストを行うことになるとは思うが、Tickデータ(都度データ)による検証も行い、その2つの差が全く無い、もしくは差の理由が明確に理由付けできるぐらいにはしておく。バックテストを行って詳細な分析もし、リアルトレードソフトもできた。自分が注文した価格と、実際に注文が通った価格は必ず残す。その差が致命的な運用損失になっていることもある。最良値の価格情報も必須。FXでいうところのスプレッド。約定したときのパラメータ等も履歴に残しているとなお良い。約定にかかった時間を記録しておく連続発注をしてしまうような要素は使わない。¶システム自体に、連続で発注してしまうような要素の組み込みはやめたほうがいい。それを考慮したうえでのソフトウェアも可能ではあるが、一瞬で全財産を飛ばすようなシステムに繋がってしまうことがあることは肝に銘じておくこと。業者によっては、約定が通らないというレスポンスがあって、数時間立った後に「実は通ってました」みたいなことを平然と言ってくるところもある。約定の安定はソフトウェアの改善より、業者の選定で行ったほうが安心。基本的に一人で開発することになるので、メンテナンスのしにくいソフトは避けるべき。細かい注文を何十回も行うようなシステムは向かない。-0.3実際にデータを記録し続けたから見えた事実。バックテストへの影響が致命的な差となって現れる。1.2最初のスプレッドが小さいので、少しの差が致命的な差になりやすい。したとたん勝てなくなった。spread5[0]df.plot()plt.show()リアルトレードとの差¶それでも完全には一致しない。理想的な状態¶リアルトレードでポジションをとって、決済したとして、その検証のためのバックテストがすぐに行なえ、バックテストでもそのトレードが再現されることが確認できる。上での計算をさせるのをやめた。起動して、自動でバックテストを行い、自作バックテストソフトとの結果の一致テストを書いた。丸め誤差や、アルゴリズムの微妙なずれが生じていることが発覚。ほかにもいくつか不一致、場合によってはバグの発見にも繋がった。複数のバックテストソフトで同じアルゴリズムを書いてみることで、自分のアルゴリズムの見直しと、動作の確認、そのバックテストソフトの仕様への理解の深まりなど、利点が多くおすすめ。バグの発見にも繋がる。まとめ¶バックテスト自体の検証力も大事だが、リアルトレードの検証力はもっと大事で、データをしっかり集めていないと難しい。精度の高い運用を目指すこと。