wind-alice/バックテストエキスパート

バックテストエキスパート は何をしますか？

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

コア哲学

目標: 紙面上で「最も利益を上げる」戦略ではなく、「最も壊れにくい」戦略を見つけること。

原則: 摩擦を加え、前提をストレステストし、何が生き残るかを確認する。悲観的な条件下でも戦略が持ちこたえれば、ライブ取引で機能する可能性が高い。

このスキルを使用するタイミング

以下の場合にこのスキルを使用します：

• 体系的な取引戦略の開発または検証
• 取引アイデアがライブ実装に十分ロバストかどうかの評価
• バックテストが誤解を招く可能性がある理由のトラブルシューティング
• 適切なバックテスト方法論の学習
• 一般的な落とし穴（カーブフィッティング、先見バイアス、生存バイアス）の回避
• パラメータ感応度と市場環境依存性の評価
• スリッページと執行コストに対する現実的な期待値の設定

前提条件

• 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倍に増加
• 最悪のケースのフィルをモデル化（ask+1ティックで買い、bid-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つの次元（サンプルサイズ、期待値、リスク管理、ロバスト性、実行現実性）にわたってスコアリングし、レッドフラグを検出し、導入/改善/破棄の判定を出力します。

主要なテスト原則

戦略を罰する

いたるところに摩擦を追加：

• 現実よりも高い手数料
• 典型的な1.5～2倍のスリッページ
• 最悪のケースのフィル
• 注文拒否
• 部分約定

根拠: 悲観的な前提を生き残る戦略は、ライブ取引で優れたパフォーマンスを発揮することが多い。

ピークではなく台地を探す

パフォーマンススパイクを生み出す最適値ではなく、パフォーマンスが安定しているパラメータ範囲を探します。

良い例: ストップロスが1.5%から3.0%のどこにあっても戦略が利益を上げる 悪い例: ストップロスが正確に2.13%でのみ機能する戦略

安定したパフォーマンスは真のエッジを示し、狭い最適値はカーブフィッティングを示唆します。

選りすぐりの例ではなく、すべてのケースをテストする

間違ったアプローチ: 機能した「市場リーダー」を厳選して研究する 正しいアプローチ: 失敗したケースも含め、基準を満たしたすべての株式をテストする

選択的な例は生存バイアスを生み出し、戦略の品質を過大評価します。

アイデア生成と検証を分離する

直感: 仮説生成に有用 検証: 純粋にデータ駆動であるべき

アイデアへの愛着がテスト結果の解釈に影響を与えてはなりません。

一般的な失敗パターン

時間を節約するためにこれらのパターンを早期に認識します：

1. パラメータ感応度: 正確なパラメータ値でのみ機能する
2. 環境依存: ある年では素晴らしいが、他の年ではひどい
3. スリッページ感応度: 現実的なコストを追加すると収益性がなくなる
4. 小さなサンプル: 統計的信頼性に十分なトレード数がない
5. 先見バイアス: 「良すぎて真実ではない」結果
6. 過剰最適化: 多くのパラメータ、サンプル外の結果が悪い

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

出力

• reports/backtest_eval_<timestamp>.json — 次元別スコア、レッドフラグ、判定を含む構造化評価
• reports/backtest_eval_<timestamp>.md — 次元テーブル、主要メトリクス、レッドフラグ詳細を含む人間が読めるレポート

リソース

方法論リファレンス

ファイル: references/methodology.md

いつ読むか: 特定のテスト手法に関する詳細なガイダンスが必要な場合。

内容:

• ストレステスト手法
• パラメータ感応度分析
• スリッページと摩擦のモデリング
• サンプルサイズ要件
• 市場環境分類
• 一般的なバイアスと落とし穴（生存バイアス、先見バイアス、カーブフィッティングなど）

失敗テストリファレンス

ファイル: references/failed_tests.md

いつ読むか: 戦略がテストに失敗した場合、または過去の過ちから学ぶ場合。

内容:

• 失敗が貴重である理由
• 例を用いた一般的な失敗パターン
• ケーススタディ文書化フレームワーク
• バックテスト評価のためのレッドフラグチェックリスト

重要な注意事項

時間配分: アイデア生成に20%、それを壊そうとすることに80%を費やす。

コンテキストフリー要件: 戦略が機能するために「完璧なコンテキスト」を必要とする場合、体系的な取引には十分ロバストではありません。

レッドフラグ: バックテスト結果が良すぎる場合（勝率90%以上、最小限のドローダウン、完璧なタイミング）、先見バイアスやデータの問題がないか注意深く監査します。

ツールの制限: バックテストプラットフォームの制限を理解します。