SHOTAI · 第5部 · 第19章 フォワード検証 ― アウトオブサンプルで測る イン・サンプルPF2.2が、OOS＋実コストで死ぬ。残るのは金と指数だけ。

過去検証は、あなたに都合のいい未来を語る。フォワード検証は、市場があなたに突きつける現実を語る。 バックテストでどれだけ綺麗な右肩上がりが出ても、それはもう答えを知っているデータで答え合わせを しただけだ。本物かどうかは、結果がまだ存在しない時間軸＝前向き(OOS)に、実際の約定コストを払いながら 回して初めて分かる。この章は第5部「守る」の卒業ゲート＝門である。

この記事のサマリ

この章を一言で

過去検証は、あなたに都合のいい未来を語る。フォワード検証は、市場があなたに突きつける現実を語る。 バックテスト(IS)でどれだけ綺麗な右肩上がりが出ても、それは「もう答えを知っているデータ」で答え合わせを しただけだ。本物かどうかは、結果がまだ存在しない時間軸——つまり前向き(OOS)に、実際の約定 コストを払いながら回して初めて分かる。この章は、第13章（予測日記）・第18章（前向き蓄積）で貯めてきた プロセスを、いよいよ実行系に接続する門である。

   OOS純益 = グロス益
           − 実コスト( スプレッド + スワップ + スリッページ + 約定ズレ )
           − ベンチマーク( 何もしない / 指数を持つ )

最後の「− ベンチマーク」まで引いて、なお正なら本物に近い。ここを引かずに勝った気になる人から、本番で 溶けていく。順に解剖する。

01IS と OOS ―「答えを見た試験」と「ぶっつけ本番」

検証には2つの時間がある。過去検証(IS)は、すでに起きた値動き＝答えが確定したデータの上で ルールを試す。フォワード検証(OOS)は、まだ結果が存在しない「これから」に対して、決めた ルールを動かす。

第18章で確認した通り、低頻度のスイングは過去検証だけでは届かない。だからこそ前向きに貯めるOOSが本線になる。

02IS→OOS の橋 ― 渡るときに何が落ちるか

ISで良く見えた戦略を、そのままOOSへ運ぶ。この「橋」を渡るとき、数字は必ず痩せる。何が橋から落ちるのかを 図にする。

当デスクの1,360セル横断検証は、この橋の実物だ。グロス／イン・サンプルでPF2を超えるセルが 多数あっても、実コスト＋OOS＋2倍コストを通すと、残ったのは金(ゴールド)と株価指数のトレンド フォローだけだった。FXの大半はスプレッドで消えた。「イン・サンプルは嘘をつく」を、自分のデスクの 数字で見せる教材である。

03実行コストは「前向きでしか」見えない ― 可視化

なぜOOSでないとコストが分からないのか。スプレッドの仮定値は静止画だが、現実の約定は動画だからだ。 値が走る瞬間にこそ取引したくなるが、その瞬間こそスプレッドは広がり、滑りは大きくなる。

1トレードの「実コスト」を分解して記録する

04卒業ゲート ― 4条件をすべて満たすまでサイズを上げない〔門〕

ここがこの章の核心であり、第5部「守る」の門だ。フォワード検証を「なんとなく良かった」で終わらせない。 次の4条件をすべて(AND)満たすまで、本番でサイズを上げてはならない。

なぜ「2レジーム」なのか

第9章で見た通り、相関やエッジは局面が変わると壊れる。リスクオンで効いた手法がリスクオフで 逆回転することは珍しくない。1つの局面だけで合格にすると、次の局面で初めて死ぬ。だから最低でも 性質の異なる2局面をまたいで生き残ることを門の条件にする。低頻度スイングではこれに時間が かかる——だが、それが正直な現実だ（第17章・第18章）。

なぜ「対ベンチマーク」を必ず引くのか

勝っていても、それが「指数をただ持っていた人」に負けているなら、あなたは余計なリスクを取って劣後した だけだ。超過(アルファ)があって初めて、この営みに意味がある。 第10章で定義した「パッシブ 代替を上回る理由」が、ここで前向きの数字として問われる。

05デモ → 極小 → 本番 ― 段階の踏み方

いきなり本番に資金を張らない。リスクを階段状に上げ、各段で確認すべきことを変える。

06当デスクも同じ門をくぐる ― Tier1 の前向き確認〔独〕

これは個人にだけ課す規律ではない。当デスクのTier1（最有力候補）も、実弾フォワードで前向き確認 できるまで「確定配備」を保留する。

具体的には、Tier1戦略を OANDA REST API 経由で、まずデモ口座で同一ルールを 自動執行し、約定の現実（滑り・拒否・スプレッド拡大）を記録する。そこで挙動が安定したら小ロットの 実弾へ落とし、ようやく前向きのコスト後成績が積み上がる。この前向き確認を通過するまで、 デスクは本配備のサイズを上げない。 個人に課す4条件の門を、デスク自身も同じようにくぐっている。

第13章（予測日記）で「主張＋反証条件」を前向きに書き、第18章（前向き蓄積）で公開採点(synchronize)に 積んできたものが、ここで実行系のコスト後成績として確定する。デスクは公開からまだ日が浅く、 前向き実績は蓄積中（n小）。だから点推定で「勝った」と言わず、信頼区間で現在地を語る （第17章）。あなたも同じ作法で、自分の前向きログを読む。

体験 ― 今すぐ手を動かす

読んで終わりにしない。自分のプロセスを実行系に乗せ、現実の数字を記録するのがこの章の体験だ。

① 実コストを1トレードごとに記録する

② 遵守率を採点する（記入式）

   遵守率 = ルール通りに実行できたトレード数 ÷ 全トレード数 × 100

   ルール通りの建玉 ____ 件
   ルール通りの損切り ____ 件
   ルール通りの見送り ____ 件   ← 「建てなかった正解」も1件
   ─────────────────────────
   遵守できた合計 ____ ÷ 全機会 ____ = 遵守率 ____ %
                                    （目標：90%超）

③ 卒業ゲート4条件チェック表を埋める

→ 1つでも⚠なら、門は閉じたまま。サイズを上げず、その条件が埋まるまで同じサイズで前向きに回し 続ける。

アクション ― 次の一歩

① 同一ルールの「執行手順書」を1枚で固める。 第13章の予測日記の書式（前提・主張・反証条件・ エントリー/損切り/サイズ）を、そのまま実行系に写す。検証中に手順を弄らない（第16章の「凍結」ルール）。

② デモで操作の型を1〜2週間、続いて極小ロットへ移す。 デモは約定が楽観的に出るので、 滑り・拒否・スワップの現実は必ず極小ロットで上書きする。最低でも異なる2レジームをまたぐ まで続ける（低頻度なら数ヶ月かかると覚悟する）。

③ 当デスクの公開採点（/synchronize）と現在のレジーム （/desk/usdjpy の5ドライバー圧力差・統合bias）を毎営業日チェックし、 自分の前向きログを信頼区間で読む。点推定の「勝った／負けた」でなく、「コスト後・対 ベンチマークで、どのレジームを何件またいだか」を見る。