backtest-expert

バックテストのエキスパート

楽観的な結果よりも堅牢性を優先する、専門的な手法に基づいた取引戦略の体系的なバックテストのアプローチです。

中核となる理念

目標：「最も利益を上げる」戦略ではなく、「最も崩れにくい」戦略を見つけます。

原則：摩擦を加え、前提条件をストレステストし、何が持ちこたえるかを確認します。悲観的な条件下でも戦略が機能するなら、実際の取引でも成功する可能性が高まります。

このスキルを使う場面

以下の場合にこのスキルを使います。

• システム取引戦略を開発または検証する
• 取引アイデアが実運用に耐えうるほど堅牢か評価する
• バックテストが誤解を招く理由を調べる
• 適切なバックテスト手法を学ぶ
• よくある落とし穴（カーブフィッティング、先読みバイアス、生存者バイアス）を避ける
• パラメーター感度と市場レジームへの依存度を評価する
• スリッページと執行コストについて現実的な期待値を設定する

前提条件

• Python 3.9+（評価スクリプト用）
• API キーは不要です
• 外部データへの依存はありません。指標はユーザーが提供します

ワークフロー

1. 仮説を立てる

優位性を一文で定義します。

例：「決算発表時に3%を超えるギャップアップが発生し、最初の1時間以内に前日の終値まで押し戻された株式は、平均回帰の機会となります。」

優位性を明確に説明できない場合は、テストに進まないでください。

2. 裁量の余地なくルールを定める

以下を完全に具体化します。

• エントリー：正確な条件、タイミング、価格の種類
• エグジット：損切り、利益確定目標、時間ベースの決済
• ポジションサイズ：固定額、ポートフォリオ比率、ボラティリティ調整
• フィルター：時価総額、出来高、セクター、ボラティリティ条件
• 対象ユニバース：対象となる金融商品

重要：主観的な判断は一切認められません。すべての判断をルールに基づき、曖昧さのないものにする必要があります。

3. 初期バックテストを実施する

以下の条件でテストします。

• 最低5年間（できれば10年以上）
• 複数の市場レジーム（強気相場、弱気相場、高ボラティリティ、低ボラティリティ）
• 現実的なコスト：手数料と保守的なスリッページ

初期結果を確認し、基本的な実現可能性を評価します。根本的な問題がある場合は、仮説を見直します。

4. 戦略をストレステストする

テスト時間の80%を費やすべき段階です。

パラメーター感度：

• 損切り幅を基準値の50%、75%、100%、125%、150%でテストする
• 利益確定目標を基準値の80%、90%、100%、110%、120%でテストする
• エントリー／エグジットのタイミングを±15～30分変える
• 狭い範囲の急上昇ではなく、安定したパフォーマンスが続く「プラトー」を探す

執行時の摩擦：

• スリッページを一般的な推定値の1.5～2倍に増やす
• 最悪の約定条件をモデル化する（買いは売り気配値＋1ティック、売りは買い気配値－1ティック）
• 現実的な注文拒否のシナリオを追加する
• 悲観的な手数料体系でテストする

時間的な堅牢性：

• 年ごとのパフォーマンスを分析する
• 大半の年で期待値がプラスになることを求める
• 1～2回の例外的な期間に依存していないことを確認する
• 異なる市場レジームごとに個別にテストする

サンプルサイズ：

• 絶対的な最低数：30件の取引
• 推奨：100件以上の取引
• 高い信頼度：200件以上の取引

5. アウトオブサンプル検証

ウォークフォワード分析：

1. 学習期間（例：1～3年目）で最適化する
2. 検証期間（4年目）でテストする
3. 期間を先に進めて繰り返す
4. インサンプルとアウトオブサンプルのパフォーマンスを比較する

警告サイン：

• アウトオブサンプルのパフォーマンスがインサンプルの50%未満
• 頻繁なパラメーターの再最適化が必要
• 期間ごとにパラメーターが大幅に変化する

6. 結果を評価する

回答する質問:

• 悲観的な前提を置いてもエッジは残りますか？
• パラメーターを変えてもパフォーマンスは安定していますか？
• 複数の市場レジームで戦略は機能しますか？
• 統計的な信頼性を得るのに十分なサンプル数がありますか？
• 結果は現実的ですか。「うますぎる話」ではありませんか？

判断基準:

• ✅ 導入：許容できるパフォーマンスを維持し、すべてのストレステストをクリアする
• 🔄 調整：基本ロジックは妥当だが、パラメーターの調整が必要
• ❌ 断念：ストレステストに失敗する、または脆弱な前提に依存している

評価スクリプトを使って、体系的かつ定量的に評価します。

python3 skills/backtest-expert/scripts/evaluate_backtest.py \
  --total-trades 150 \
  --win-rate 62 \
  --avg-win-pct 1.8 \
  --avg-loss-pct 1.2 \
  --max-drawdown-pct 15 \
  --years-tested 8 \
  --num-parameters 3 \
  --slippage-tested \
  --output-dir reports/

このスクリプトは5つの評価軸（サンプル数、期待値、リスク管理、堅牢性、約定の現実性）を採点します。機械可読形式のdecisionとblocking_reasonsを判断の基準としてください。0～100のquality_scoreは診断用です。スコアが高くても、期待値が正でない場合（ただし、取引数が30未満の場合は最初にNOT_EVALUABLEになります）、ドローダウンが50%以上の場合、ユーザーが指定したより厳しいドローダウン上限を超える場合、取引数が不十分な場合、スリッページや取引コストの検証が不足している場合、テスト期間が5年未満の場合、または結果が良すぎるように見える場合（最大ドローダウンが5%未満で勝率が90%を超え、理由がtoo_goodとなる場合。採用前に先読みとデータの監査が必要です）は、これらの条件を覆せません。verdictは、スコアに基づく判定より良くなることのない、保守的な「導入／調整／断念」の互換性フィールドです。ハード上限の50%を下回る個人的な上限を設定するには、--max-acceptable-drawdown-pctを使用してください。個人的な上限と同じ値は許容されます。入力が無効な場合はステータス1で終了し、レポートは出力されません。

テストの重要な原則

戦略に厳しい条件を課す

あらゆる面で摩擦を加えます。

• 実際より高い手数料
• 通常の1.5～2倍のスリッページ
• 最悪の約定条件
• 注文の拒否
• 部分約定

理由：悲観的な前提を置いても機能する戦略は、実取引でより良い結果を出すことがよくあります。

ピークではなく安定領域を探す

パフォーマンスが急上昇する最適値ではなく、パラメーターの範囲全体でパフォーマンスが安定する領域を探します。

良い例：損切り幅が1.5%から3.0%のどの値でも利益が出る戦略 悪い例：損切り幅がちょうど2.13%の場合にしか機能しない戦略

パフォーマンスの安定性は本物のエッジを示します。最適値が狭い場合は、カーブフィッティングの可能性があります。

恣意的に選んだ例ではなく、あらゆるケースを検証する

誤った方法：うまくいった「マーケットリーダー」を選んで調べる 正しい方法：条件を満たした株式を、失敗したものも含めてすべて検証する

例を選別するとサバイバーシップバイアスが生じ、戦略の質を過大評価してしまいます。

アイデアの創出と検証を分ける

直感：仮説を立てるのに役立ちます 検証：データのみに基づいて行う必要があります

アイデアへの思い入れによって、テスト結果の解釈が左右されないようにしてください。

よくある失敗パターン

こうしたパターンを早期に見つけることで、時間を節約できます。

1. パラメーター感度：特定のパラメーター値でしか機能しない
2. レジーム依存：特定の年には非常に良いが、別の年にはひどい
3. スリッページ感度：現実的なコストを加えると利益が出ない
4. サンプル不足：統計的な信頼性を得るには取引数が少なすぎる
5. 先読みバイアス：「うますぎる話」のような結果
6. 過剰最適化：パラメーターが多く、アウトオブサンプルの結果が悪い

詳しい例と診断フレームワークについては、references/failed_tests.mdを参照してください。

出力

• reports/backtest_eval_<timestamp>.json — 次元ごとのスコア、警告事項、decision、blocking_reasons、判定を含む構造化された評価
• reports/backtest_eval_<timestamp>.md — 次元別の表、主要指標、警告事項の詳細を含む、人が読みやすいレポート

主要な JSON フィールド：

• decision：正式な結果で、DEPLOY、REFINE、ABANDON、REJECT、RISK_LIMIT_EXCEEDED、VALIDATION_REQUIRED、NOT_EVALUABLE のいずれかです。ゲートの優先順位は、NOT_EVALUABLE（取引が30件未満、またはプロフィットファクターがオーバーフロー）、次に REJECT、次に RISK_LIMIT_EXCEEDED、次に VALIDATION_REQUIRED（スリッページテストなし、期間が5年未満、または too_good）です。どのゲートにも阻まれない場合に限り、スコアに基づいて DEPLOY／REFINE／ABANDON が決まります。
• blocking_reasons：発動したすべてのゲートの ID（profit_factor_overflow、small_sample、negative_expectancy、zero_expectancy、excessive_drawdown、risk_limit_exceeded、no_slippage_test、short_test_period、too_good）です。優先順位の高いゲートによって判定が決まった場合でも、すべて保持されます。
• profit_factor：null の場合があります。profit_factor_status はその理由を示します。FINITE（数値）、NO_LOSSES（粗利益がプラスで、粗損失がない）、UNDEFINED_ZERO_GROSS（粗利益も粗損失もない）、OVERFLOW（損失がゼロではないものの、比率がオーバーフローした状態）のいずれかです。

リソース

手法リファレンス

ファイル：references/methodology.md

読むタイミング：特定のテスト手法について詳しく知りたいとき。

内容：

• ストレステストの手法
• パラメーター感度分析
• スリッページと取引摩擦のモデリング
• サンプルサイズの要件
• 市場レジームの分類
• よくあるバイアスと落とし穴（サバイバーシップ、先読み、カーブフィッティングなど）

失敗テストのリファレンス

ファイル：references/failed_tests.md

読むタイミング：戦略がテストに失敗したときや、過去の失敗から学ぶとき。

内容：

• 失敗に価値がある理由
• よくある失敗パターンとその例
• ケーススタディの文書化フレームワーク
• バックテストを評価するための警告事項チェックリスト

重要な注意事項

時間配分：アイデアの生成に20％を使い、それを崩そうとすることに80％を使ってください。

コンテキストに依存しないこと：戦略が機能するために「完璧なコンテキスト」を必要とするなら、システマティックトレードには十分な堅牢性がありません。

警告事項：バックテストの結果が良すぎるように見える場合（勝率が90％超、ドローダウンが最小、タイミングが完璧など）は、先読みバイアスやデータの問題がないか、注意深く監査してください。

ツールの制約：バックテストプラットフォーム特有の動作（補間方法、流動性が低い場合の処理、データのアラインメントの問題など）を把握してください。

統計的有意性：小さな優位性を証明するには、大きなサンプルサイズが必要です。1取引あたり5％の優位性を偶然と区別するには、100件以上の取引が必要です。

裁量トレードとシステマティックトレードの違い

このスキルは、以下のようなシステマティック／定量的なバックテストに焦点を当てています：

• すべてのルールを事前にコード化する
• 実行に裁量や「勘」が入らない
• 厳選したケースではなく、過去のすべての事例でテストを行う
• コンテキスト（ニュース、マクロ要因）を意図的に排除する

裁量トレーダーは異なる方法で分析します。このスキルは、主観的な判断を必要とするセットアップには適用できない場合があります。