デモ口座、バックテスト、フォワードテスト、マーケットリプレイ

戦略はデモ口座、過去データによるテスト、リアルタイム、マーケットリプレイで検証できます。それぞれの環境が答える問いは異なり、固有の限界があります。本記事では、結果から何が分かるのか、コストをどう織り込むか、パラメータの選択と独立した評価をどう分けるかを説明します。また、ルールが実際の注文執行に直面する前に、データやシミュレーションの誤りが成績曲線をよく見せてしまう仕組みも示します。

1. デモ、ペーパートレード、バックテスト、フォワードテスト、リプレイ、ライブ — 異なる六つの問い

テストを巡る誤解の多くは、「戦略は検証済みだ」という単純化から生じます。どこで、何について検証したのでしょうか。これらの環境は、正確さという一つの尺度に沿って順に並ぶ段階ではありません。測っているものが異なります。

デモ口座 は、ブローカーのサーバー上で仮想資金を使う口座です。レートは通常、実口座と同じ配信元から来ますが、執行はデモサーバー側で簡略化したルールによりシミュレートされます。そのルールを決めるのはプラットフォームではなくブローカーで、口座種別によっても異なり得ます。したがって、「デモでは再現されない」という説明は、該当口座の資料を確認して初めて成り立つもので、普遍的な原則ではありません（参考文献の16番 は、ある提供元での説明例です）。執行モデルやブローカーの注文フローの扱いは、 ブローカー選びの章で説明しています。

ペーパートレード とは、ブローカーに実際の執行注文を送らず、判断を記録することです。約定値は表計算、スクリプト、チャート環境内のエミュレーターが割り当てます。この違いは見落とされがちですが重要です。仮想注文をエミュレーターが約定させるなら、エントリー価格を決めるのは市場ではなくエミュレーターのルールだからです。ペーパートレードが調べるのは判断の論理です。エミュレーターのルールを別途説明し、その妥当性を示さない限り、執行品質のテストにはなりません。

バックテスト は、過去データでルールを再現します。答えるのは、データ、ティックモデル、コストモデルが現実と一致していたらどうなったか、という条件付きの問いです。答えの品質は、前提の品質を超えません。

フォワードテスト は、調整に使った期間の外でルールを検証します。最適化処理に一度も見せていない過去の留保区間を使う場合もあれば、後戻りできないリアルタイムの観測を足ごとに行う場合もあります。

マーケットリプレイ は、先の値動きを隠して過去を再生し、手動で判断する仕組みです。裁量戦略の訓練ツールであり、実資金口座と同等ではありません。

実口座 は、スリッページ、スプレッド拡大、拒否、部分約定といった実際の執行コストを測定できる唯一の環境です。

2. デモとペーパートレードで測れないもの

デモ口座は「お金を使わないライブ取引」と説明されることがあります。しかし、具体的に確認できる複数の点で正しくありません。以下の表は、デモサーバーでは存在しない、あるいは簡略化される可能性のある要素を挙げています。実資金に移ると、いずれも結果に直接影響します。「デモ」の列は典型的な簡略化を説明するもので、全ブローカーに共通の規則ではありません。シミュレーションの範囲は口座提供元が決め、同じブローカーでも口座種別により異なり得ます。

表の最後の行は、妥当な計画を場当たり的な判断に変えてしまい得ますが、本記事の主題ではありません。プレッシャー下の行動の仕組みについては、 プロセスと結果の記事で説明しています。ここで扱うのは、測定可能な執行コストです。

スリッページを見積もらず、測定する方法。 各取引について、シグナル時の価格、要求価格、執行価格、クリック時のスプレッド、約定時のスプレッド、遅延、セッション、マクロイベントの有無、ブローカーのサーバー時刻を記録します。標本が集まったら、平均だけでなく中央値と分布の裾も計算してください。少数の極端な約定を含む平均は、良い方向にも悪い方向にも誤解を招きます。こうして得た数値こそ、バックテストのコストモデルに入れるに値します。

基準となる事例：2019年1月3日の円急変。 アジア時間の薄い流動性の中で、円の通貨ペアが数分間で急変しました。この出来事はオーストラリア中央銀行の報告書の独立した囲み記事で説明されています（参考文献の12番、内容参照日22.08.2026）。報告書は「AEDT午前9:36、重要なニュースがない中、約30秒間で円が米ドルに対して3パーセント上昇した」とし、売値と買値の差が「約2 pipsから100–300 pipsへ」拡大したと記しています。同じ囲みの二つの記述が本記事では重要です。一つは「この時間帯、季節の市場流動性は低かった」こと。もう一つは、個人向けブローカーが損失の一定水準超過時にストップロス注文でポジションを自動決済することです。つまりこの時間には、まさにその仕組みが作動しました。そのコストをテスターが再現できるのは選択したモデル方式の範囲内だけであり、簡略方式では注文に記載された価格で約定させるため、全く再現できません（指値・逆指値注文の約定に関する小節を参照）。値動きの幅と約定価格はデータ提供元やブローカーごとに異なるため、ここに唯一の「正しい」pips値はなく、提示もしません。戦略テストに対する結論は限定的で具体的です。固定スプレッド、スリッページゼロのコストモデルは、このような時間帯を全く再現せず、タイトなストップを使う戦略が最も影響を受けます。出来事の経過と市場背景については、 セッションと取引時間の章で扱います。

3. バックテスト結果の構成要素：データ、ティックモデル、コストモデル

テスターの結果は、利用者が意識しないまま決めてしまう三つの事柄で変わります。どのデータを読み込んだか、足の中の値動きをどう再現したか、各取引に何を上乗せしたかです。

ティック生成モデル

MetaTrader 5の資料には、テスターの五つのモードが示されています。 全ティック, リアルティックに基づく全ティック, 1分足OHLC, 始値のみ および 数学的計算。ここで最も重要なのは最初と二番目の違いです。 全ティック モードでは、分足データからアルゴリズムでティックを生成します。 リアルティックに基づく全ティック モードでは、ブローカーが収集したティックを使います。つまり、特定の配信一つの記録であり、市場全体の完全な再構成ではありません。 1分足OHLC は毎分四つの価格を再現し、 始値のみ は足の開始時にロジックを実行します。 数学的計算 は過去データを全く読み込まず、数学関数の最適化に使います。モード名と順序はテスター設定ページで確認できます（参考文献の2番、参照日22.08.2026）。テスターのモードは端末のバージョンとともに変わることがあるため、利用する前に自分のバージョンのヘルプを確認してください。

ただしリアルティックのモードを選んでも、計算で生成されたティックが一切含まれないという意味にはなりません。資料は代替処理を明記しています。「銘柄履歴に分足はあるが対応するティックデータがない場合、テスターは»全ティック«モードでティックを生成する」。逆に「分足がなく、その分の対応ティックデータがある場合、そのティックは無視される」とされています（参考文献の1番、参照日22.08.2026）。つまり、ブローカーの保存データに欠落や不整合があれば、一部区間はモデルで生成したティックで再現され、報告書にはその区間が別途表示されません。同じページは、リアルティックでは「分足内でスプレッドが変わり得る」一方、生成ティックでは該当足の固定スプレッドを使うとも説明しています。したがってデータモードは価格経路だけでなくスプレッドモデルも変えます。

実務上の帰結は単純ですが厄介です。足の中で高値と安値のどちらに先に到達したかにルールが依存するなら、ストップと目標を同時に置く戦略はすべて該当しますが、分足から生成したティックによるテストはその順序を推測します。プログラムの不具合ではなく、モデルの性質です。MetaTrader 4のテスターは過去データのカバー率を別の指標で示しますが、足の中の値動きはやはり実際の配信記録から読むのではなく、計算されます。資料が説明するモデル方式は三つです。 始値のみ, コントロールポイント および 全ティック 。最後の方式では「直近の下位時間足だけでなく、利用できるすべての近接時間足のデータも生成に使う」とされ、下位足データがない部分には既成の波形テンプレートを使います（参考文献の14番、参照日22.08.2026）。モデリング品質のバーは、実際にどの時間足を使ったかを示します。時間足が短いほど価格経路の推測は減ります。リアルティックの有無と履歴の深さは、ブローカーと保存期間に依存します。

テスターは指値・逆指値注文をどう約定させるか

ティックモデルは、テスターがどの価格を見るかを決めます。それとは別の前提が、待機注文が市場にあるとき、その価格をどう扱うかです。この前提は設定画面では見えにくく、ツールの資料を調べる必要があります。ここには二つの異なる問いが隠れており、分けて初めて計算を正しく理解できます。 いつ 注文が執行されるか、そして どの価格で執行されるか。後者の答えは、MetaTrader 5のテスターでは二つの別の軸、すなわち銘柄の種類とデータのモデル方式に依存します。この軸を混同すると、資料の正しい記述を、当てはまらない場面に適用してしまいます。

遅延。 MetaTrader 5のテスターの遅延再現は、自動売買による注文の発注を対象とし、その後のサーバー上の執行を対象としません。「EAが待機注文を使う場合、遅延は注文の発注だけに適用され、執行には適用されない（実際には執行はサーバー上でネットワーク遅延なしに行われる）」とされています（参考文献の2番、参照日22.08.2026）。したがって、すでに市場に置かれている注文の約定には、テスト内でネットワーク遅延が加わりません。現実にも加わらないので、この扱いは妥当です。

第一の軸：銘柄の種類。 遅延がないからといって、注文に書かれた水準で約定するとは限りません。資料はまず銘柄の種類で区別しています。ここで扱う店頭FX/CFD銘柄は非取引所銘柄であり、取引所上場の通貨契約とは別区分です。非取引所銘柄の規則は、「すべての待機注文とSL/TPはBidとAskで発動し、発動時点の現在の市場BidとAskで執行する」とされています（参考文献の13番 の 注文の発動と執行節、第一段落、参照日22.08.2026）。したがって、指値を含むすべての待機注文とストップロス、テイクプロフィットは、注文に書かれた水準ではなく、発動時の現在のbidまたはaskで執行されます。指値に対し指定価格より有利な差が生じれば価格改善です。これは指値を超え、不利な方向で約定してよいという意味ではありません。

指値注文はスリッページなしで約定するという記述は、取引所銘柄についてのもの。 同じ節の次の段落は、株式と取引所契約を別に扱い、異なるルールを示します。「取引所銘柄では、チャートの描画とストップ注文の発動は直近の取引価格（Last）に基づく。指値注文はBidとAskで発動する。指値注文は注文の指定価格で執行され（スリッページなし）、それ以外の注文は現在の市場BidとAskで執行される（スリッページがあり得る）」という説明です（参考文献の13番、同節第二段落、参照日は同じ）。これをテスター全般の規則として引用することがありますが、引用の誤りではなく適用範囲の誤りです。「指値はスリッページなし」は取引所銘柄に適用されます。非取引所FX銘柄には前の段落が適用され、取引所上場の通貨契約には取引所銘柄の規則が適用されます。

第二の軸：モデル方式。 銘柄の種類による扱いが成り立つのは、精密なモード、すなわち 全ティック と リアルティックに基づく全ティックです。モデル方式は別の軸であり、簡略モードではその規則自体が無効になります。「»始値のみ«と»1分足OHLC«のテストでは、待機注文とSL、TPは注文の指定価格で執行される。精密モード（全ティックとリアルティック）で使う市場価格執行アルゴリズムは、精度の低いモードには適さない」とされています（参考文献の13番、参照日は同じ）。提供元は理由と結論も説明します。「一部モードでは中間ティックを生成しないため、要求注文価格と現在価格（OpenまたはOHLC）の差が大きくなり得る。»始値のみ«と»1分足OHLC«で要求価格を使って執行すると、より正確なテスト結果を得られる」。直感とは逆の論理です。簡略モードには発動後の市場価格を取得する材料がないため、注文に書かれた価格で約定させます。次の足の始値での約定は、指定水準での約定以上に大きな誤差になるからです。

二つの軸を合わせて考える。 MetaTrader 5のテスターで非取引所FX銘柄を扱うと、二つの異なる執行環境になります。報告書の見た目が同じなので、混同しやすい点です。

• 精密モード (全ティック, リアルティックに基づく全ティック）— すべての待機注文とSL、TPは、発動時の現在のbidまたはaskで約定します。スリッページはモデル化されますが、分足から生成した経路であれブローカーのティック履歴であれ、テスターが再現した価格経路の範囲内だけです
• 簡略モード (1分足OHLC, 始値のみ）— すべての待機注文とSL、TPは、注文に書かれた価格で正確に約定します。全注文種別について、スリッページが計算から完全に消えます

結果への影響は同じ方向でも、簡略化の仕組みは注文種別によって異なります。ストップ注文は発動後、成行注文として振る舞います。現実の執行価格は水準突破後に最初に利用できる価格であり、その水準自体ではありません。簡略モードのように指定水準で約定させると、価格の飛びによるコスト全体が消え、成績がよくなります。指値注文は市場より下で買う、または上で売る注文です。指定水準での約定は、その価格でポジション全量を約定させる流動性があると仮定しますが、価格への到達だけで十分な流動性は保証されません。取引所では待ち行列の順位も重要で、店頭FX/CFDには提供元の執行ルールが適用されます。テスターは待ち行列も、その価格で利用できる数量もモデル化せず、価格経路しか知りません。どちらの簡略化も結果を有利にしますが、選んだモードで認められる場合にのみ計算に入ります。

市場の売買側も別の条件です。水準への到達は注文側に対応する価格系列で判断され、買いはask、売りはbidに反応します。一つの系列、通常はbidで行うテストは、スプレッドを加えて反対側を再現します。MQL5の資料は「テスト中、スプレッドはモデル化せず、過去データから取得する」と説明しています（参考文献の3番、参照日22.08.2026）。したがって発動時点は、自分の口座で発生したはずのスプレッドではなく、データに記録されたスプレッドで決まります。価格経路の密度自体も重要です。ティックの説明ページは「ストップ水準や待機注文は、指定価格と異なる価格で発動することがある（特に上位時間足でのテスト）」と警告しています（参考文献の1番）。

報告書を読むときの意味。 テスターの報告書には、二つのうちどちらの環境で生成したかは示されません。実行時の設定を読む必要があります。同じルールでも精密モードと簡略モードでは計算が異なり、これは計算精度ではなく約定ルールの違いです。平均損益が小さい戦略やタイトなストップの戦略は、除かれた価格の飛びのコストが成績の大きな部分を占めるため、特に敏感です。そのため待機注文の約定ルールは、ティックモデルやコストモデルと同列で環境説明に含める必要があります。それを開示しない報告書は、ツールの資料と照合すべきです。確認テストに大きな手間はかかりません。精密モードで再実行し、さらに平均的なスリッページ程度だけ約定を悪化させてもう一度実行し、どれだけ成績が残るかを確認します。

コストモデル

単位の異なる四つの項目を各取引に加えます。混同してはいけません。

• スプレッド — 単位はpipsまたはpoints。固定値、データに記録された値、テスト開始時の現在値のどれを使うかが重要です。答えが三通りなら結果も三通りです。MetaTrader 5のテスターは前述の資料で確定できますが、他のツールでは該当テスターの説明を探す必要があります
• 手数料 — 口座通貨建てで、通常はロットごと、片道ごとです。スプレッドと比較するには、銘柄とポジションサイズに対応するpip価値を使ってpipsに換算します
• スワップポイント — 決済日の切り替わりをまたぐ保有にかかり、特定の曜日には三倍分が発生します。日中完結戦略では関係しませんが、長期保有戦略ではスプレッドより大きいこともあります
• スリッページ — 単位はpipsまたはpointsで、要求価格と執行価格の差です。テスターには約定ルールで許される箇所だけで入ります。MetaTrader 5の通貨ペアでは、精密モードなら全待機注文とSL、TPに適用されますが、 1分足OHLC と 始値のみ では、注文の指定価格で約定するため全く入りません（参考文献の13番）

遅延を第五項目として付け加えることがありますが、ここでは意図的に含めていません。遅延の単位はpipsではなくミリ秒であり、取引から差し引く項目ではありません。執行モデルのパラメータであり、影響するのは どの価格 が使われるかであって、 いくら を差し引くかではありません。MetaTrader 5のテスターでは、 遅延なし と ランダム遅延 の各モードや固定遅延で再現できます。ただし待機注文の約定の小節で示した通り、自動売買による発注を対象とし、すでに市場にある注文の執行を対象とはしません（参考文献の2番）。コスト計算の同じ行でこの二つの量を混ぜるのは、丸めではなく単位の誤りです。

似て見える二つの誤りを分けて考える必要があります。サーバーアドレスへのpingで測ったネットワーク遅延は、注文執行にかかる時間ではありません。その間にはブローカー側の検証、待ち行列、実際の執行時点があります。インフラ、仮想サーバー、自動売買の稼働維持については、 自動化・EA・VPSの記事で詳しく説明します。ここで重要なのは、テストの遅延を黙ってゼロとせず、明示的に仮定することです。

データ自体の品質

結果に意味を持たせるには、まずデータを確認します。系列の欠落や不連続、重複、外れ値、時系列順、タイムゾーンと夏時間の切り替え、足の時刻が開始時刻か終了時刻か、さらにbid、ask、仲値のどれで系列を作ったかです。最後の点は軽視されがちですが、そもそも水準に達したかを左右します。ショートはaskで決済するため、bidで作った足にはストップを発動させた価格が一度も表示されないことがあります。

4. 完璧だが非現実的なバックテスト — 美しい曲線の構造

見栄えのよいテスト結果は、大きなごまかし一つではなく、単独では無害に見える小さな四つの妥協から生まれることが多いものです。各妥協と見抜き方を示します。

第一の妥協：まだ知り得ない価格でのエントリー

「足が移動平均より上で確定したら入る」というルールなのに、その同じ足の終値でエントリーしています。最終的な終値を必要とするシグナルは、終値が確定して初めて、その時点で利用できる価格で注文を出せます。終値で一度計算する一般的なモデルなら、次の足の最初のティックです。約定価格が偶然前の終値と一致することはあっても、モデルを指定せずその価格で取引できると仮定してはいけません。この前提を修正すると、結果は大きく変わり得ます。

判決ではなく感応度テスト： エントリーを一足ずらして再実行します。成績が消えた場合、分かるのは一期間のずれに耐えられないことだけです。未来情報の漏洩は可能な説明の一つですが、唯一の説明ではありません。単にシグナルの寿命が短い、あるいは執行価格に敏感な可能性もあります。判断を決めるのは、意思決定時点で各変数が利用可能だったかの監査です。このテストの全手順と、証明できないことは、 ルックアヘッドの節の最後の囲みに示します。

第二の妥協：コストなし

スプレッド、手数料、スリッページのないテストは、同じシステムの簡略版ではありません。期待値も損益分岐点も異なる別のシステムです。その変化の大きさは計算でき、次節で示します。

第三の妥協：千回の試行から選んだ一設定

最適化処理が返すのは順位表です。その最上段だけを戦略の成績として示すと、調べたバリエーションの数が抜け落ちます。試行が十分多ければ、意味のないルールでも探索の統計だけで最高成績は高くなります。この現象の形式的な説明は、 参考文献の8番 にあります。調べたバリエーションの数は、期間やコストと同じく結果の説明に必要です。

第四の妥協：調整に使ったデータで評価する

成績を報告する期間と同じ期間でパラメータを選んだなら、そこに検証はなく、当てはまりの説明があるだけです。同時に最も見抜きやすい誤りでもあります。どの区間を調整に使い、どの区間を評価専用にしたかを聞けばよいからです。

四つの妥協を一つの計算で見る — 美しい曲線はどれだけ残るか

四つを列挙するだけでは大きさは分かりません。以下の計算はそれを示し、各段階を一つの演算で確認できるようにしています。

各行の確かめ方。 ドル列はpipsの結果×10.00 USD×1,000取引です。段階0、1、2は同じパラメータ設定から前提を一つずつ除くので、縦に引き算できます。2.60 − 1.40 = 1.20、1.20 − 1.20 = 0.00です。段階3と4は追加の引き算ではなく、同じ結果に対する別の二つの問いの答えです。そのため段階2に継ぎ足さず、別に計算します。

段階1 では1.40 pipsを除きます。これは、確定時にしか分からない価格で入ることで、ルールが取り込んでいたシグナル足の値動きの部分です。修正後にちょうど1.20 pipsの粗利益が残るのは偶然ではありません。次節でコスト感応度を分解するのと同じシステムだからです。 段階2 は、その感応度が何をもたらすかを示します。往復コスト1.20 pipsを加えると、セント単位まで結果はゼロになります。

段階3 は、選ばれた成績と検証した設定群の中央値の差を示します。1,200通りの首位は1,200個の値の最大値です。中央値に対する優位、ここでは一取引0.45 pipsは選択の効果を示しますが、それだけで過剰適合を測るものではありません。順位表全体の中央値が負でも、選択点が孤立した突出値だとは証明できません。近傍と独立データを評価してください。 段階4 は、最適化処理が見ていない12か月で同じ固定設定を評価し、一取引−0.30 pipsとなります。

この仮の計算では、四つのうち三つの妥協を除くと、戦略のルールを一つも変えず、同じ1,000取引換算で+26,000 USDが−3,000 USDになりました。第四の妥協、すなわち順位表首位を示す特権は、第四行でも残っています。同じ固定パラメータをアウトオブサンプルで使っているからです。中央値との差は、異なる問いに答える第三行で別途示します。変わったのは、いつ入れるか、一取引のコストはいくらか、どの設定を示すか、どのデータで評価するかという前提だけです。

5. コスト感応度テスト — 計算を順に確認する

多くの戦略が成立しなくなるのはここです。以下は実行したテストの結果ではなく、明示した前提に基づき電卓で確認できる構成例です。出所を追えない数値が一つもないため、仕組みを示すのに適しています。

各行の確かめ方。 「コスト合計」は左の三列の合計です。「純損益」は1.20 pipsからコスト合計を引いたものです。ドル列は純損益×10.00 USD×1,000取引です。純プロフィットファクターは、全取引にコストを加えた同じ分布から計算します。例えばコスト1.20 pipsなら、一取引の利益は8.00から6.80 pipsに減り、損失は9.00から10.20 pipsに増えます。利益は600 × 6.80 = 4,080 pips、損失は400 × 10.20 = 4,080 pipsで、プロフィットファクターはちょうど1.00です。この行の総コストは1,000 × 1.20 = 1,200 pipsで粗利益全体と一致するため、結果はセント単位までゼロになります。

この計算では二つの数値が参考になります。第一に、第三行と第四行の差はスリッページわずか0.20 pipsですが、最終損益では2,000 USDです。第二に、コストなしと、この例の水準のコストありの差は小さな補正ではなく、利益が出るシステムと出ないシステムの違いです。自分の戦略に1.20 pipsが現実的かどうかは、自分の口座での測定だけで決まります。ここでは市場から読み取った値ではなく、計算用に選んだ値です。一取引の平均粗損益が小さく、頻度が高いほど、この切り替わりは急になります。平均損益が数十pipsある保有型戦略なら、同じコスト変化の影響は小さくなります。したがって他人の例を使わず、自分の戦略のコスト感応度を計算する必要があります。

6. ルックアヘッドとデータ漏洩 — 未来からの情報混入

ルックアヘッド・バイアスは、判断時点でまだ利用できなかった情報を使うことです。データ漏洩はより広く、ルールの構築や評価に未来の知識が入り込むあらゆる経路を指します。どちらも誤りではなく好成績に見えるため、危険です。

漏洩が生じる箇所：

1. シグナル足の終値でのエントリー。 第四節で説明しました。修正は、早くても次の足の始値で入るか、確定済みデータだけでシグナルを計算することです
2. 過去に遡って再計算される指標。 Pine Scriptの資料は、スクリプトの「過去とリアルタイムの計算または描画」が異なる振る舞いになる状態をリペイントと定義します（参考文献の4番、参照日22.08.2026）。すべてがごまかしではありませんが、信頼できる結果として扱う前に、すべて説明しなければなりません。アラートの仕組みと過去・リアルタイムの違いについては、 TradingViewの記事で詳しく説明します
3. 中心化された指標。 ある時点の値に、その先の観測値、すなわち t+k を使って t の値を求める仕組みは、過去チャートでどれほどよく見えても取引には使えません
4. 改定後のマクロデータ。 数年後に改定された指標値は、発表時点で知られていた値ではありません。マクロデータを使うルールは、その時点で公表済みの改定を含め、判断時に利用できた版と実際の公表時刻を使う必要があります。発表内容自体の解釈については、 指標発表時の取引の記事で説明します
5. 未来を知った上で銘柄を選ぶ。 現在まで存続した銘柄や、上昇したと分かっている銘柄だけでテストすると、未来に基づく選択が入ります。通貨では特にエキゾチックペアや為替制度変更期に関係します
6. 標本を分ける前にデータを前処理する。 全データで計算した正規化、尺度調整、特徴量選択は、アウトオブサンプルの情報をインサンプルに持ち込みます。IS/OOSの分割は最後ではなく、最初の操作でなければなりません

7. インサンプル、アウトオブサンプル、ウォークフォワード

原則は一文で、例外を許しません。 調整に使ったデータを、同時に独立した検証に使うことはできない。他のすべてはここから導かれます。

インサンプル（IS）は、パラメータ選択、設定の試行、ルール変更に使ってよい過去区間です。アウトオブサンプル（OOS）は、その作業中に見ない区間です。時系列で分ける必要があります。全期間の観測をランダムに混ぜてもIS/OOS分割にはなりません。時系列には記憶があり、混ぜると情報が両方向に伝わるからです。

分割の最も重要な帰結： アウトオブサンプルの結果が後の変更に影響した時点で、独立性は失われる。OOS結果を見て弱いと判断し戦略を変えれば、その区間は以後の作業に対してOOSではなくなります。引き続き使えますが、独立した証拠ではなくISの一部としてです。実務でこの仕組みがどれほど頻繁に検証を壊すかのデータはなく、あるように装う必要もありません。効果は明白です。パラメータ変更に使ったOOS期間は、修正後のモデルの独立した証拠ではありません。

MetaTrader 5のテスターには、この分割が組み込まれています。 フォワード 設定には、 なし, 1/2, 1/3, 1/4 と カスタムがあり、常に期間の後半、時間的に後の部分を留保します（参考文献の2番）。OOSを誤ってのぞくことを防ぎやすい便利な仕組みですが、窓は自動移動しません。複数回のウォークフォワードは手動か外部ツールで組み立てる必要があります。資料の確認日は2026年8月22日です。

ウォークフォワード：移動する窓

ウォークフォワードは、過去区間を順にずらしながら同じ手順を繰り返します。一度の判定ではなく判定の列を得て、検証区間をつなぐことで、最適化処理が全体として一度も見ていない実績列を作るのが目的です。

1. 最初の実行前に窓の長さを決める — 例えばISを12か月、OOSを3か月にします。結果を見てから長さを選ぶのは、別の調整です
2. ISの窓だけで最適化する 調べた設定数も記録します
3. 選んだパラメータをOOSの窓に適用する 一切変更しません
4. 両方の窓をずらす OOSの窓の長さだけ進め、繰り返します
5. つなぎ合わせた検証区間を評価する最適化結果ではありません。プラスの区間数、最悪区間の状態、各回で選ばれたパラメータが似ているかを確認します

ウォークフォワード効率はPardoが導入した指標で（参考文献の7番）、IS外でどれほど成績を維持できるかを表す簡便な尺度として使われます。

WFE = OOSの年率換算リターンISの年率換算リターン × 100%

意味を持たせるには、両リターンを同じコスト控除後、同じ通貨、同じポジションサイズ規則で計算する必要があります。ISリターンがゼロなら比率は未定義、負なら正の優位性の維持を表す尺度にはなりません。リターンの定義が異なるシステム間でWFEを比較しても意味はありません。さらに重要なのは、WFEは合否を二分する門ではないことです。OOS十二取引の高いWFEは、四百取引の中程度のWFEより情報量が少なくなります。取引数、各回の結果分布、ドローダウン、コスト上昇時の挙動と合わせて見てください。

8. 最適化、パラメータの安定性、モンテカルロ法

最適化が答えるのは、このデータで最良の結果を出したパラメータはどれかです。今後よい設定がどれかには答えません。言葉の微妙な違いではなく、過去の記述と予測の違いです。運用記録がないため、本記事ではこの理由で失敗するシステム数を示せません。最適化処理は与えられたデータの結果を順位付けするだけで、将来成績を立証しません。

突出点と台地

順位表の首位だけでなく、その近傍を見ます。隣接するパラメータでも似た成績なら、小さな設定変化にルールの挙動があまり変わらない台地です。一段階動かすだけで崩れるなら突出点であり、過去データの構成に偶然合った可能性が高くなります。通常は頂点より台地の中央を選ぶ方が合理的です。この区別とウォークフォワード手法全体はPardoの研究に由来します（参考文献の7番）。

通常は最適化しないパラメータにも同じ確認をすると有用です。取引時間、最小ストップ距離、曜日フィルターなどです。サーバー時刻22:00までか23:00までかで成績が変わるなら、そのフィルターの経済的根拠と調整期間外の安定性を確認します。時間差だけで過剰適合は証明できません。

試した設定数も結果の一部

バックテストを報告するときは、成績とともに調べた組み合わせ数を示します。この習慣が、テストの記述と広告を分けます。多重検定の問題と、最高成績が探索の産物である確率の体系的な議論は、Bailey、Borwein、López de Prado、Zhuの論文にあります（参考文献の8番）。結果に基づく選択の体系的な説明はAronsonにあります（参考文献の9番).

予測ではなく頑健性テストとしてのモンテカルロ法

TomasiniとJaekleなどが説明する、単純で有用な方法です（参考文献の10番）。検証区間の取引損益を取り出し、順序を何度も無作為に変え、最大ドローダウンの分布を求めます。注目するのは、 その分布の右の裾 です。例えば最大ドローダウンの95パーセンタイル、すなわち模擬経路の95パーセントが超えない値です。それがリスク計画のドローダウン上限を超えるなら、平均が良く見えても、仮定したモデルと数量はそのリスク基準を満たしません。

二つの限界を明示する必要があります。順序の入れ替えは取引の独立を仮定しますが、相関したポジションを開く戦略や、直近成績で数量を変える戦略では成り立ちません。もう一つは、広く言いすぎられがちな点です。入れ替えは既発生の結果から抽出するため、観測分布の外の 個々の取引 は生成しません。ただし最大ドローダウンが制限されるわけではありません。むしろ、既存の損失を別順序で連続させ、観測値より大きなドローダウンを作り得ることが、このシミュレーションの狙いです。モンテカルロ法が調べるのは出来事の順序への感応度であり、個々の出来事の可能範囲ではありません。ドローダウン上限と取引停止の仕組みは、 ドローダウンとキルスイッチの記事で説明します。

9. フォワードテスト、デモ、マーケットリプレイで何を確認できるか

フォワードテストは最終的な証拠と言われることがありますが、そうではありません。確認できるのは限定的で具体的な事柄です。

留保した過去区間でのフォワードテスト は、固定パラメータのルールが、最適化処理に見せていないデータで特定の成績を出したことを確認します。執行コストや別の相場局面での挙動は確認しません。

デモ口座でのリアルタイム・フォワードテスト は二つを加えます。端末の通常稼働で実装が正しく働くか、利用者が場当たり的な変更なくルールを適用できるかです。デモサーバーが再現しない範囲の執行コストは測れません。何を再現するかは一般論ではなく、該当ブローカーと口座種別の資料で決まります。確認するまでは、デモ成績は執行前提が未検証のシミュレーションを表します。

実資金口座で最小数量を使うフォワードテスト は、執行コストの測定を加えます。ただし第二節の留保通り、取引した数量に対する測定です。エクスポージャーを増やす判断はテスト手順ではなく、 リスク管理計画に属し、そもそも計画が許可している場合に限られます。

マーケットリプレイ

リプレイでは、先を隠して過去を再生します。足を進め、判断し、その後で結果を見ます。裁量戦略なら、リアルタイムで待ったりルールをコード化したりせず、多くの反復を集められます。環境は注文パネルや統計を備えた専用シミュレーターと、チャート基盤内のモードに分かれます。後者も、もはや単なるチャート送りではありません。TradingViewは現在、独立したReplay Tradingモードについて「実際のブローカーと同じように、ポジションを開き、指値、逆指値、ストップリミット注文を置ける」と説明し、セッション結果を次のタブにまとめます。 概要, パフォーマンス, 取引分析, リスク／パフォーマンス比率 および 取引一覧。そのうち「パフォーマンスと取引一覧は、追加分析や記録用にエクスポートも可能」とされています（参考文献の5番、参照日22.08.2026）。

リプレイで得られないもの。約定値はシミュレーター独自のルールで割り当てるため、実際の執行コストは得られません。セッションを単なる練習以上に扱う前に、そのルールを把握する必要があります。実損失のプレッシャーも得られません。固有の弱点は、気づかずにごまかしやすいことです。直前の判断を戻す、区間をやり直す、「今度は違って見えたのでもう一回」といった操作は、テストを物語に変えます。セッションをデータにするには、開始前の規則と、悪い判断も含む全判断の記録が必要です。

10. テストツール — 条件別の比較

全段階を完結できるツールはありません。以下は機能数ではなく、実際に選択を左右する条件で比較します。

選択は三つの問いに集約されます。ルールをコード化できるか。できなければテスターではなくリプレイ環境が必要です。リアルティックが必要か。足内の順序に依存するなら必要で、それが選択を決めます。標本分割方式を自分で管理したいか。そうなら、内蔵分割は意図的に単純なので、いずれ自作コードに行き着きます。

11. 再現手順と信頼性チェックリスト

再現できないテストは、数値で書いた意見です。以下は、半年後の自分や他の人が、全く同じ実行を再現するための最低限の項目です。復元できない項目があれば、飛ばさず限界として記載します。

バックテストの信頼性チェックリスト

他人の結果にも自分の結果にも全く同じように問う十一項目です。「分からない」は否定の回答です。

1. 銘柄、正確なシンボル、期間、データの出所が示されているか
2. ティック生成方式が示され、戦略の時間軸に適合しているか
3. 指値・逆指値をどの価格で約定させるか分かり、推測ではなくツール資料で確認したか
4. スプレッド、手数料、スワップ、仮定したスリッページを含み、各単位を示しているか
5. 口座で実測した平均スリッページ程度コストを増やしても成績が残るか
6. 判断に使う全変数について、値が分かった時点を記録し、判断より後のものがないか。遅延エントリー試験はこの監査の補助であり、代替ではない
7. IS/OOS分割と境界日が示されているか
8. OOSを見たのはパラメータ固定後の一度だけか
9. 調べたパラメータ設定数が示されているか
10. 一点だけでなく、選んだパラメータの近傍でも成績が維持されるか
11. 一般化する結論に対し、取引数と期間は複数の相場局面をカバーしているか

最悪の壊れ方は項目を一つ抜かすことではなく、結果を先に出し、後から正当化するという順序の逆転です。順序は好みでなく意味が成立する条件です。第七・第八項目は結果を見た後では誠実に決められません。事前にルールを書き、最適化前に境界日を決め、設定数をその都度記録するのは十五分程度です。それが検証と美しいグラフ探しを分けます。

手順を書いたら、次はテスターのクリック操作から、同じ処理を反復可能に実行し標本分割も管理するコードへ移すことがよくあります。そこから別記事のテーマである、 取引におけるPythonが始まります。環境の再現性は、テスト自体の再現性と同じほど重要です。