タグ: 要件定義

「この条件を足せば、EAはもう少し勝てるはず」。そう考えてコードを一行変え、バックテストを回す。数字がよくなると、すぐ実運用に入れたくなるものです。

でも、改善したのは売買ルールでしょうか。それとも、たまたま過去の値動きに合うよう調整しただけでしょうか。

EA開発で怖いのは、動かないコードだけではありません。動くのに、根拠が弱いコードです。この記事では、エントリー条件を追加する前に決めたい仕様、検証の順番、t値・取引コスト・Bidデータの点検方法を、実務で使えるチェック表にして整理します。

この記事でわかること

• EAの条件を「思いつき」から検証可能な仕様に変える方法
• t値を使うときの意味と、過信を避ける確認手順
• スプレッド・スリッページ・スワップを損益へ反映する考え方
• Bidデータの歪みや欠損を見つけるチェックポイント
• 今日からできる、小さなEA開発の一歩

EAの条件追加は、コードを書く前に文章で固定する

先に「何を、いつ、どう判定するか」を文章で決めると、テスト結果を読み違えにくくなります。曖昧な条件は、実装者の解釈やテスト後の後付け判断を混ぜるからです。

たとえば「押し目で買う」だけではEAの仕様になりません。どの時間足の、どの確定足を使うのか。押し目の幅を何で測るのか。条件が成立した瞬間に発注するのか、次の足の始値で入るのか。停止条件は何か。これらが未定なら、同じ言葉から別のEAができあがります。

まず、条件を次のように分解します。数値は例です。実際の採用値は、対象通貨ペアと取引時間、データの仕様に合わせて決めてください。

仕様項目	決める内容	曖昧なままのリスク
判定時点	確定足のみか、ティックごとか	未来情報の混入、再現性の低下
価格系列	Bid、Ask、仲値のどれを使うか	発注価格と判定価格のズレ
シグナル	指標、期間、閾値、比較方法	後から条件を増やす余地
決済	損切り、利確、時間決済、反対シグナル	損失が想定外に伸びる可能性
例外処理	取引停止時間、注文拒否、最大保有数	異常時に意図しない注文を繰り返す

仕様を文章で残すと、検証で変えたものも追えます。つまり、勝ちやすい条件探しより先に「同じ条件を誰でも再現できる状態」を作るのです。

例外条件こそ、損益グラフに出る前に決める

EAは通常時より、想定外の場面で設計品質が表れます。週明けの窓、指標前後の急変、通信断、約定拒否、最小ロット未満の計算などは、平均損益だけでは見えにくいからです。

最低限、注文に失敗した場合の再試行回数、同一シグナルの重複発注防止、最大ポジション数、損切り注文を置けない場合の動作を決めます。「失敗したらもう一度」では危険です。何秒後に何回まで試し、どの条件なら停止するかを明記します。

こうした仕様は、見栄えのよいバックテストを作るためではありません。実運用でEAが何をするかを、先に人間が理解するためにあります。

t値は「勝てる証明」ではなく、偶然を疑う入口

t値は平均的な成績がばらつきに比べてどれほど大きいかを見る指標で、将来利益を保証しません。サンプル数、独立性、分布の偏り、試した条件の数を無視すると、数字だけが一人歩きします。

単純な平均リターンの検定では、t値は「標本平均 ÷ 標準誤差」で計算します。標準誤差は、標準偏差を標本数の平方根で割った値です。たとえば取引ごとの損益を使う場合、損益の平均とばらつき、取引数が必要になります。

ただし、FXの取引損益は常に独立とは限りません。同じ相場局面で連続してポジションを持つと、隣り合う取引の成績が似ることがあります。大きな利益が数回だけ含まれる場合も、平均値は見かけ上よくなります。通常のt値をそのまま「有意」と読み替えないでください。

確認	見る理由	手順
損益単位	ロットや通貨で比較が歪む	R倍数、pips、資産比率などを明記
取引数	少数の大勝ちに左右される	期間別・相場局面別にも分ける
連続性	取引の独立性を損なう	日・週単位の集計やブロック再標本化を検討
試行回数	多数試行から良い結果だけ選ぶ	試した条件数と選定ルールを記録
未使用期間	作成データへの過剰適合を検出	条件決定後の期間で一度だけ評価

検証済みの個別案件では、バックテスト表示上の勝率96%が、元データを再点検すると52%になった例もありました。これは全EAに当てはまる割合ではありません。数字が派手でも、元データと計算過程を確かめる必要がある、という監査事例です。

t値を出す前に、まず取引履歴の欠損・重複、損益計算、試行回数を確認します。t値は最後の飾りではなく、検証設計の一部として扱いましょう。

スプレッド会計を入れると、勝ちトレードの見え方が変わる

取引コストは、勝ち負けを決めたあとに引くのではなく、売買の成立条件に組み込みます。特に短期EAでは、小さなコスト差が期待値を削るからです。

基本の損益は、決済損益からスプレッド、手数料、スリッページ、スワップを差し引いて考えます。口座タイプによって、スプレッドが狭い代わりに取引手数料がある場合もあります。比較するときは「表示スプレッド」だけでなく、同じロット・通貨ペア・時間帯で総コストをそろえます。

例として、1回の取引で往復コストが平均0.8pips、年間取引数が1,000回なら、単純合計は800pips相当です。これは特定口座の実測値ではなく、計算方法を示す仮定例です。1pipの金額は通貨ペア、ロット、口座通貨で異なるため、自分の条件で換算してください。

だから何か。バックテストの利益が800pips未満なら、この仮定のコストだけで優位性が消える可能性があります。実際には各取引のコスト分布を使い、平均だけでなく悪化側も検証します。

正直会計では、バックテストの設定値を「実測」と呼びません。固定スプレッドを設定したなら固定値テスト、変動スプレッドのティックデータを使ったならそのデータ範囲のテスト、と記録します。約定遅延を再現できない環境なら、その制約も結果に添えます。

コスト表は平均だけでなく、時間帯ごとに作る

平均スプレッドだけでは、EAが実際に入る瞬間のコストが隠れます。流動性が薄い時間や指標時には、通常時間と異なる値が出ることがあります。

取引履歴にエントリー時刻を残し、時間帯別にスプレッドとスリッページを集計します。取引の多い時間がコストの高い時間と重なれば、月平均より悪い条件で運用しているかもしれません。曜日、セッション、指標前後を分けるのも有効です。

費目	記録するもの	見落としやすい点
スプレッド	発注時のBid/Ask差	固定値で全時間を代用していないか
手数料	往復・片道、ロット単位	口座通貨への換算時点
スリッページ	要求価格と約定価格の差	バックテストでゼロ扱いになっていないか
スワップ	保有日数、通貨ペア、方向	日々変動や付与日の違い

口座のスプレッド、手数料、スワップは変更されることがあります。利用前に各社の公式ページで、対象口座・取引時間・適用条件を確認してください。広告や比較ページの数字だけで判断しないことが、検証の再現性を守ります。

Bidの歪みは、ローソク足の外側に潜む

Bid系列だけの異常は、チャートの形より先にデータ品質の問題として調べます。FXの多くのチャートはBid価格を基準に表示され、買い注文はAskで成立します。Bidだけ見て売買条件を作ると、実際の約定可能価格とずれる場合があります。

たとえば、短時間だけ価格が飛ぶ、同じ時刻に重複したティックがある、High/Lowが前後の値とかけ離れる、BidとAskの差が不自然に広がる、といった異常です。これが実市場の急変か、データ配信の欠損かは、一本のチャートだけで断定できません。

確認では、(1)タイムスタンプの重複・逆行、(2)OHLC整合性、(3)隣接ティックの変化幅、(4)スプレッドの分布、(5)別データソースとの同時刻比較を行います。比較元が異なる場合は、サーバー時刻、夏時間、価格更新頻度が一致しているかもそろえます。

怪しい値を見つけても、都合よく削除してはいけません。元データを保管し、除外条件を先に定義し、除外前後の結果を両方報告します。データを整える操作そのものが、EAの成績を変えるからです。

検証は「作った期間」と「触っていない期間」を分ける

条件を決めた期間だけで成績を評価すると、偶然に合った設定を選びやすくなります。開発用データで調整した後、未使用期間や別の相場局面で同じルールを試します。

実務では時系列を崩さず、過去側を設計・調整に使い、後ろ側を検証用に確保します。検証結果を見て条件を変えたら、その期間はもう「未使用」ではありません。再び別の期間を用意するか、評価を探索的な結果として扱います。

結果はPFや勝率だけでなく、最大ドローダウン、取引回数、連敗、平均保有時間、月別損益、コスト控除前後を並べます。相場環境別に分けると、利益が特定の数か月だけに集中しているかも見つけやすくなります。

過去記事の監査事例では、勝率96%と表示されたEAを元データから再検証したところ52%になったケースがありました。原因が違えば必要な対策も違います。数字の大きさより、再現可能な計算過程を確かめることが先です。

今日できる最初の一歩は、条件を一枚に書くこと

いきなりEAを作り直す必要はありません。まずは一つのエントリー条件を、検証可能な文章にします。この作業なら、今日30分ほど確保して始められます。所要時間は内容による目安です。

1. 対象通貨ペアと時間足を書く
2. シグナル判定を確定足・ティックのどちらで行うか決める
3. Bid/Askのどの価格を条件と発注に使うか記す
4. 損切り、利確、時間決済、最大保有数を書く
5. スプレッド・手数料・スリッページ・スワップの前提を記録する
6. 開発用期間と未使用の検証期間を分ける
7. 条件変更のたびに、変更理由と試行回数を残す

そして小さなデモ検証へ進みます。最初からリアル口座で試す必要はありません。デモ環境でも、注文拒否や価格更新、EAログの読み方を確認できます。ただし、デモの約定条件が実口座と同じとは限らないため、差は別途記録します。

「勝てそうな条件を見つける」より、「何を試し、何がわかり、次に何を変えるか」を残す。これが、再現できるEA開発の出発点です。

まとめ: 良いEAは、結果より先に検証の筋道がある

EAの開発では、条件をコードにする前に文章で固定し、t値を過信せず、取引コストを損益へ反映し、Bidデータの品質を確かめます。さらに、調整に使った期間と未使用期間を分けます。

派手な勝率の裏に、データ欠損や過剰な条件調整が隠れていないか。最初に抱いた不安への答えは、数字を一つ増やすことではなく、数字がどう作られたかを追える状態にすることです。

まずは今あるEAのエントリー条件を一つ、紙に書き出してみませんか。そこから、次の検証が始まります。

関連記事

• EA開発は検証設計で決まる: t値・スプレッド会計・Bid歪みを開発前に組み込む
• 勝率96%のEAを本物のデータで再検証したら52%になった: データ破損を見抜いた監査実録
• 勝率7割でも資産は減る: EAの期待値を削る取引コストの正体

※本記事にはアフィリエイト広告も含みます。