売買ロジックに優位性があるのかどうか？
それを確認するためにバックテストプログラムを組み、バックテストを実施する。
しかし、バックテストプログラムの組み方次第では、優位性の判断を間違えてしまうものとなる。
そう、実は勝てないシステムが、勝てるシステムへと変貌してしまう。
過剰最適化以前の問題だ。
気をつけなければいけない。
バックテストプログラムを組むうえで注意することは、
- 取引手数料を考慮すること
- 成行注文の場合は、スリッページコストを考慮すること
- 指値注文の場合は、同値を約定したことにしてはいけない（寄付きと引けは例外）
- 限月をまたぐトレードをどう扱うか？実運用と併せて検討しておくこと
１．取引手数料を考慮すること
取引手数料を考慮しなければならないことは、特に説明は不要だろう。
私の場合は、ミニ1枚1往復100円で計算している。
実際は、岡三オンライン証券の場合、86円。
（税込み、通常取引コース、2017年10月17日現在）
実際よりも少し高めで、キリの良い数字に設定している。
２．成行注文の場合は、スリッページコストを考慮すること
新規注文をを指値注文で実施するとしても、決済注文は成行であることが多いと思う。
決済において、利食いの場合は指値としても、ロスカットの場合は成行でないと、いつか大惨事となる。
そして、成行注文の場合は、スリッページコストを考慮しておかないと、
バックテスト結果が楽観的なものとなってしまう。
ラージのチャートでサイン判定して、ミニで売買する場合、
悪い方に1ティックどころか2ティック滑ることが、多々ある。
一方、良い方に2ティック滑る(？)ことも、まれにある。
では、スリッページコストをいくらで見積もっておくべきか？
必ず1ティック滑るものとしておくのも良い。
しかし、少し厳しすぎるように思う。
悩ましい。
そこで、実測値を用いることにした。
手じまいサインの価格と実際の約定価格の乖離を録り、滑ったティック数換算、その確率を求めた。
（採取した件数は忘れた）
結果、およそ60%の確率で1ティック（5円）滑っていた。
（もちろん、悪い方に）
つまり、成行注文1回あたり、300円（5円×100(レバレッジ)×60%）をスリッページコストとすれば良い、ということになる。
（ミニ1枚あたり）
実際は、実測値より少し厳しく見積もり、確率を70%とし、350円としてバックテストしている。
新規注文も成行注文とすると、スリッページコストは往復で700円となる。
逆指値注文を事前に発行している場合は、ここまで滑らないと思う。
取引所でトリガーヒットを察知しすぐに処理されるからだ。
ここで気にしているのは、手じまいポイントが事前に確定しておらず（例えば、移動平均線のクロスで手じまいなど）、
手じまいサインをプログラムが認識、決済注文発行、約定の間に発生するスリッページ。
『岡三RSSを使う際の注意事項～まとめ～』に書いたが、
- 「リアルタイム」といっても数秒程度遅れることを前提としたシステムにしなけらばならない
バックテストにおいても、このことを考慮しておかなければならない。
３．指値注文の場合は、同値を約定したことにしてはいけない（寄付きと引けは例外）
寄付きと引けを除き、指値注文の約定は必ず、1ティック以上「突き抜けて」いなければ、約定したこととしてはいけない。
同値を約定とみなす場合とみなさない場合の違いは、
プログラムでは、約定判定の条件文に「＝」を入れるかどうかのわずかな違いだが、
バックテスト結果は全く違うものとなる。
その一例が下図
主要な数字を比較すると、
（左が同値約定、右が同値未約定）
- 損益累計：791,600 ⇔ -216,350
- 勝率：56.8 ⇔ 47.38
- プロフィットファクター：1.267 ⇔ 0.917
- (1)バックテストプログラムは何も対応しない。誤差と考える。そして、誤差も把握しない。
実際の運用では、限月切り替え前は運用停止する等、任意に対応する。 - (2)バックテスト誤差と考えるが、誤差を計算するプログラムを組み、参考とする。
実際の運用は、(1)と同様。 - (3)限月をまたがないように取引最終日大引けで決済するようバックテストプログラムを組む。
実際の運用も、取引最終日大引けで決済する。 - (4)ロールオーバー（限月の乗り換え）処理をバックテストプログラムに入れる。
実際の運用も、ロールオーバーする。 - (5)実際のSQ値で清算する処理をバックテストプログラムに入れる。
実際の運用も、SQ前に決済せず、SQ値で清算する。
-
同値を約定したとみなすことにより、負けシステムも勝システムになる。
実際のトレードにおいて、「置いていかれる」場面でも、
バックテスト上では、置いていかれず勝ちトレードとなる。
都合の良いバックテスト結果が出来上がる。
４．限月をまたぐトレードをどう扱うか？実運用と併せて検討しておくこと
限月をまたぐトレードをバックテストでどう扱うか？
つなぎ足チャートを使ってバックテストを実施すると、この問題が発生する。
限月をまたぐポジションは、実際はあり得ないが、バックテスト上では発生し得る。
ただし、寄り引けシステムのように、もともとセッションをまたぐことがない売買ロジックだと、限月をまたぐポジションが発生しないため、この問題は発生しない。
どう扱うか？考えられるのは、以下の5つぐらいか？
バックテストプログラムを組む上で、(1)は何もしなくて良いので、一番楽な対応策だ。
そして、短期売買でトレード回数が多い場合、(1)でも良いかも知れない。
例えば、バックテスト期間5年（約1200日）で、1000回のトレード回数があったとする。
1年間に限月切り替えは4回（メジャー限月）あるので、5年で20回。
限月切り替え時に毎回ポジションを持っているとは限らないので、このケースでは影響は2%以下だ。
ただし、この数字は回数ベースであり、損益額ベースではない。
損益額に及ぼす影響を押さえておくケースが、(2)だ。
私がバックテストプログラムに組み入れてるのが(3)。
一応入れているが、バックテスト結果（損益）は(1)とあまり変わらなかったりする。
実際の運用において、ロールオーバーするつもりは無いので、(4)のプログラムは組んでいない。
(5)も組んでいない。
いずれにしても、実際の運用で、限月切り替え前にアタフタしないために、
バックテスト時点で方針を決めておかなければならない。