全部緑でも、昇格させない――採用条件を満たしたのに見送った理由

はじめに：チェックリストは全部緑だった

私は新しいルールをいきなり実際の資金で動かしません。まず「観察運用」として、注文を出したつもりで仮想の損益を記録し、事前に決めた条件をすべて満たしたら実運用に昇格させる、という段階を踏みます。

あるゴールドのルールが、その条件をすべて満たしました。管理表の表示は「100%」。あとは昇格させるだけです。

それでも、私は昇格を見送りました。この記事はその理由と、「条件を満たした」と「優位性がある」の間にある隙間の話です。

管理表の上では問題なし

このルールに設定していた昇格の条件と、実測は次のとおりです。

条件	実測	判定
バックテストの検証期間でプロフィットファクター1.2以上	2.43（59件）	満たす
観察運用のシグナル10件以上	15件	満たす
観察運用の仮想損益がプラス	+3.14R	満たす
ゴールド全体の建玉の上限	稼働中	満たす

記録の欠損もありませんでした。15件すべてに損益と決済の記録があり、上書きもゼロです。ここまでは健全です。

条件にない観点で見ると、落ちる

ところが、このルールの昇格条件には入っていないチェックがありました。「最大の1件を除いても、コスト控除後の平均がプラスであること」です。別のルールで痛い目にあったあとに追加した条件で、このルールはそれより前に登録していたため、入っていませんでした。

当てはめると、こうなります。

	件数	合計	平均
全件	15	+3.14R	+0.209R
上位1件を除く	14	−0.71R	−0.051R
上位2件を除く	13	−1.64R	−0.126R
上位3件を除く	12	−2.44R	−0.203R

最も大きい勝ちの1件（約+3.9R）を除くだけで、合計がマイナスに反転します。中央値は−0.064R、勝率は46.7%です。プラスの成績は、ほぼその1件が作っていました。

コストは問題ない

念のため、コストも測りました。このルールは損切りの幅が平均約95ドルと広く、実測のスプレッド（約0.43ドル）はほとんど効きません。コストは平均利益の約3%で、私が目安にしている上限（平均利益の3分の1）に対して約33倍の余裕がありました。

つまり問題はコストではなく、「成績が1件に乗っていること」だけです。

では却下するのか：似た形の別のルールと比べる

以前、まったく同じ形で見送った別のルールがあります。そちらは最大1件が合計の290%を占めていました。では今回も却下すべきかというと、私はそう判断しませんでした。中身を比べると、決定的に違うからです。

	以前見送ったルール	今回のルール
観察運用の平均	+0.014R	+0.209R（約15倍）
コスト	平均利益の62%（上限超え）	平均利益の3%
バックテストの頑健性	優位性なし	95%信頼区間 +0.062〜+0.566R、平均がプラスの確率99%
上位を除いたとき（バックテスト）	—	5件除いても符号が反転しない

バックテスト（全体164件、うち検証期間59件）では、外れ値への依存は見られません。外れ値への依存が出ているのは、観察運用の15件だけです。

つまり素直な読み方は「ルールが外れ値頼みだ」ではなく、「観察運用の件数がまだ少なすぎる」です。15件しかなければ、1件の大勝ちが合計を左右するのは当然のことです。以前のルールはバックテストの段階で優位性がなかったので、性質が違います。

判断：昇格も却下もしない

結論は「観察運用を続けて、件数を増やす」です。あわせて、3つのことを決めました。

1. 条件をすべてのルールにそろえる 「最大の1件を除いてもプラス」は、登録した時期の違いで一部のルールにしか入っていませんでした。同じ落とし穴に2度落ちないための条件が、一部にしか効いていない状態は放置できません。

2. 必要な件数と判定日を、実際のペースから逆算する このルールは59日で15件、つまり1日およそ0.25件のペースです。30件に達するのは約2か月後です。判定日を「だいたいこのあたり」で置くと、その日には判断できるだけの件数がそろっていません。

3. 「判定できない」を「合格」に丸めない 昇格条件には「実運用とバックテストの成績が一致すること」もありましたが、実運用の前には原理的に判定できません。それでも管理表は「100%」と表示していました。判定できない項目を障害として扱っていなかったためです。管理表の「100%」は、こういう穴を含んだまま表示されます。

やってはいけないこと

この場面でやりたくなることが2つあり、どちらも禁じています。

• 大勝ちの1件を「たまたま」として除外し、残りで判断すること。除外するかどうかは、事前に決めた規則でだけ決めます。結果を見てから選ぶと、昇格にも却下にも、好きな方へ転ばせてしまいます。

• 件数を増やすために、ルールの条件を緩めること。頻度を上げるための調整は、結果を見ながらの最適化そのものです。バックテストで確かめたルールとは別物になります。

まとめ：「条件を満たした」は「優位性がある」ではない

• 採用条件は、過去に失敗した形を防ぐために後から増えていく。そのたびに、既存のルールすべてに当て直す

• 上位1〜3件を除いた合計を、必ず確認する

• 外れ値への依存が見つかったら、バックテスト側にも同じ形があるかを比べる。両方にあればルールの問題、観察側だけなら件数の問題

• 判定日は、必要な件数と実際のペースから逆算して置く

• 判定できない項目を合格に数えない

管理表が全部緑のときほど、表に載っていない観点でもう一度疑う価値があります。

このルールの観察運用は今も続けています。件数がそろった時点で、外れ値への依存が解けたかどうかを改めて報告します。

おまけ：同じ確認を自分のバックテストで

この記事で使った「上位1〜3件を除いた合計」「平均の95%信頼区間」「コストの余裕」といった確認は、MT5のバックテストレポートに対してまとめて行えるよう、点検ツール「EA頑健性チェック」として形にしました。判定の基準は固定で、結果を見てから緩めることはできません。気になる方はのぞいてみてください。