サンプル外テストと関連する為替概念の比較

直接的な回答

サンプル外テスト（略して OOS テスト）は、構築や調整に使用されていないデータに対して、一連のルールまたは適合されたパラメータがどの程度機能するかを測定するために設計された評価ステップです。これは、特にバックテストやフォワードテストといった関連する為替評価のアイデアとは異なり、それらの概念は、適合とパフォーマンス評価のそれぞれにおいていつ、どのデータを使用するかという点で異なります。

この違いを理解するための有益な考え方は、2 つのフェーズを分離することです：

1. モデル/パラメータの形成（ルールの選択とパラメータの決定）、および
2. パフォーマンス評価（結果の測定）。

OOS テストは、評価に「新しい」データを使用することでこれらのフェーズを明確に区別し、これが過学習によって引き起こされる楽観的な結果を（完全に排除することはできませんが）軽減する主要なメカニズムとなります。

メカニズム：各概念がデータをどのように扱っているか

サンプル外テスト (OOS)

サンプル外テストとは、開発期間から除外されたデータセット上で、候補となる取引ロジック（ルール、インジケーター設定、閾値、リスク制限など）を評価する実践です。

標準的な教育環境では、以下を前提とします：

• 過去の価格系列が存在する。
• それを少なくとも 2 つの部分に分割する：開発用（サンプル内）部分と評価用（サンプル外）部分。
• 開発用部分のみを使用してアプローチを形成または調整する。
• OOS 部分のみを使用してパフォーマンス指標を報告する。

目的は未来を直接予測することではありません。むしろ、開発期間での見かけ上の結果が、そのアプローチが未だに見たことのないデータにも適用可能かどうかをテストすることです。

バックテスト

バックテストは、ルールが過去データに対してどのように機能していたかをシミュレーションするという広範な概念です。最も単純な形では、バックテストは次のように答えます。「もしこれらのルールが過去に適用されていたなら、シミュレーションされた結果はどうなっていたでしょうか？」

バックテストは、同じデータを調整と評価の両方に使用するアプローチを含む、さまざまな方法で行うことができます。その場合、シミュレーションが偶然ノイズに合致する選択を反映している可能性があるため、真に未見のデータを使用した場合よりもパフォーマンスが良く見えることがあります。

したがって、OOS との決定的な違いは、バックテストが「間違っている」ことではなく、バックテスト単独では形成と評価の厳密な分離を保証しないことです。

フォワードテスト

フォワードテスト（「ペーパートレード」や「後のデータでの実行」とも説明されます）は、開発期間後のより後の時間期間にわたってアプローチを評価するものです。

概念的には、タイミングを強調します：システムが開発時に利用できなかった期間に「実行」されるようにします。これにより、単一の歴史的分割よりもリアルタイム運用に近いものになります。

しかし、フォワードテストも依然として仮定に依存します。時間の順序が尊重されていても、結果は以下の変動に影響を受けます：

• 取引コストがどのようにモデル化されているか、
• 執行が現実的にシミュレーションされているかどうか、
• および市場状況が変化するかどうか。

限定された比較：基準の違い

以下に、一般的な検証基準を用いた限定された比較を示します。各基準について、「正統な所有者」とは、その基準の定義を最も直接的に扱う概念を指します。

1) 開発と評価間のデータ分離

• OOS テスト（正統な所有者：OOS）： 明示的に除外された評価データを必要とします。
• バックテスト（正統な所有者：バックテスト概念）： 開発と評価を分離する場合もあれば、しない場合もあります。
• フォワードテスト（正統な所有者：フォワードテスト）： 通常、開発後に後の期間で評価しますが、すべての調整決定の完全な分離を自動的に保証するものではありません。

2) 主な目的

• OOS テスト： 新しい歴史データへの一般化能力を評価する。
• バックテスト： ルールセットの過去の挙動をシミュレーションする。
• フォワードテスト： 時間が経過してより後のデータに進む際の挙動を評価する。

3) 楽観的結果のリスク

• OOS テスト： 明確な分割で行われた場合、楽観的バイアスを軽減しますが、複数の比較、繰り返しの再調整、または前処理を通じたリークによって依然として影響を受ける可能性があります。
• バックテスト： 同じデータセットが設計と評価の両方を駆動する場合、非常に楽観的になる可能性があります。
• フォワードテスト： フォワードテストの結果を使用して手法が繰り返し修正される場合、または執行の仮定が非現実的な場合、依然として楽観的になる可能性があります。

4) 典型的な失敗モード

• OOS テストの失敗モード： データリーク（間接的に将来の情報を使用する）、特定の OOS セグメントへの過学習、多数の実験にわたるパラメータ選択の繰り返し。
• バックテストの失敗モード： 評価が適合プロセスと重複するため、サンプル内バイアス。
• フォワードテストの失敗モード： 開発後のレジーム変化、およびシミュレーションされた執行と実際の執行との不一致。

証拠または例（明示的な仮定付き）

事前に仮定を明記した簡単な教育例を考えてみましょう。

1 つのパラメータ（ルックバックウィンドウ長）を使用するルールから始めたと仮定します。10 年分の週次価格データがあるとします。

• 開発期間： 1 年目〜7 年目
• 評価期間： 8 年目〜10 年目

ステップ A（形成）： 複数のウィンドウ長を試して、1 年目〜7 年目の間に最高のパフォーマンスを示すものを選択します。

ステップ B（OOS テスト）： 選択したウィンドウ長を固定したまま、8 年目〜10 年目でのパフォーマンスを評価します。

この設定では：

• 8 年目〜10 年目で結果が劇的に改善した場合、そのルールが開発期間を超えて一般化できる可能性を示唆しています。
• OOS セグメントで結果が崩壊した場合、開発期間での成功がその以前のデータに固有のものであったことを示しています。

次に、10 年全体を一度に使用して評価とパラメータ選択の両方を行う純粋なバックテストシナリオと比較します。シミュレーションが強力な結果を示していても、評価期間が間接的にパラメータの形成に使用されたため、それらを一般化に起因するものとして帰属させることはできません。

最後に、フォワードテストと比較します：1 年目〜7 年目で手法を開発し、その後、時間の進行を模倣するように 8 年目〜10 年目で実行すると仮定します。これは、実用的な執行の仮定などの問題を明らかにできますが、市場が変動する可能性があり、取引コストや約定が簡略化されたモデルと異なる可能性があるため、将来のパフォーマンスを保証することはできません。

限界とリスク（何が起きうるか）

OOS テストであっても、為替評価に関連する重要な限界と失敗モードが存在します。

1. OOS を超えた過学習 OOS の結果に基づいてパラメータを繰り返し調整すると、OOS セグメントは事実上意思決定プロセスの一部となります。これにより、楽観性が再導入される可能性があります。

2. データリーク 前処理に、評価時点では利用不可能だった情報（例えば、将来の値を使用して計算された正規化など）が使用されている場合、OOS の結果は誤解を招く可能性があります。

3. 非定常性とレジーム変化 為替市場は時間とともに行動を変化させる可能性があります。あるレジームで機能する手法が、別のレジームでは機能しない可能性があるため、OOS パフォーマンスは堅牢性の保証にはなりません。

4. コストと執行の不一致 バックテストとフォワードテストのシミュレーションは、しばしば取引執行を簡略化します。取引コスト、スプレッド、スリッページ、注文処理の違いは、結果を意味のある形で変化させる可能性があります。