crucible-investigation-methodology

調査手法 — 6つの実行パターン

自己進化型スキル：ここに記載したパターンが実際にうまく機能しない場合（結果が誤っている、計算リソースを無駄にするなど）、該当セクションを更新し、references/evolution-log.md に追記してください。先延ばしにしてはいけません。

この6つのパターンは、a-research-foundations の一環として実行しました。基礎における「なぜ」に対する「どのように」を示すものです。新しい仮説には、おおむねこの順序で適用してください。

---

1. LLM ネイティブなデータ表現 — 五分位トークン

エージェントに数値の市場データを「見て」もらう前に、因果的なウィンドウ内でローリング五分位ランクを使い、バーごとのトークンシーケンスとしてエンコードします。

標準スキーマ：

idx  dir  body_q  range_q  dur_q  uwick_q  lwick_q  loc  sess  fwd+H...

各五分位は、因果的な200バーのローリングウィンドウ内で 1..5 の値になります（Skill A §1 を参照）。エージェントは、浮動小数点値では見えない +1:5:1|+1:5:1|+1:5:1（高速で大きく上昇するバーが3本連続）などのモチーフを見つけられます。

コンテキスト予算のルール：トークン化した統計テーブルは60 KBならエージェントのコンテキストに収まりますが、生のバーは67 MBあるため収まりません。

詳細なリファレンス：findings/methodology/01-llm-native-data-representation.md。

---

2. 直列の敵対的ゲート（A/B/C/D/E プロトコル）

インサンプルでポジティブな結果が出ても、信頼する前に、互いに独立した4〜5つのゲートを順番に通過させます。

ゲート	問い	検出できること
A — 方向別の内訳	エッジはロング、ショート、または両方から得られていますか？	拡散的に見えるものの、実際には方向性のあるエッジ
B — 鏡像対称性	逆のトリガーにも鏡像エッジがありますか？	サンプルウィンドウのドリフトによる片側の過大評価
C — OOS 時系列分割（時系列順の80/20）	保留した後続データでも結果が再現しますか？	インサンプルの過学習
D — クロスアセットでの再検証	他のシンボルでも再現しますか？	特定アセットへの過学習
E — 全履歴での年別検証	年の60％以上でポジティブですか？	ある1年だけの幸運

ゲート C は必須です。 時系列分割による OOS 検証なしに、ポジティブな結果を報告してはいけません。

判定を分類します：

• すべて合格 → validated-cross-asset（昇格）
• A+B+C は合格、D は不合格 → validated-asset-specific（範囲を限定し、棄却しない）
• C は不合格 → 棄却し、resurrect_if: 条件を付けてアーカイブする

詳細なリファレンス：findings/methodology/05-serial-adversarial-gates.md。

---

3. 複数の視点によるエージェント統合（並行する4〜5人の専門家）

総当たりが現実的でない場合は、分析の視点が異なる専門エージェントを4〜5人、並行して起動します。意見の一致は検証を意味し、意見の相違は診断材料になります。

標準的な視点のセット：

1. パターンモチーフ／n-gram
2. レジーム／トレンド分類器
3. 形態／ヒゲ検出
4. 情報理論／サプライザル
5. 隠れたシグナルの探索／懐疑的な批評 — 必ず含めてください。確証バイアスを防ぎます。

ルール：

• 同じ生データを使い、視点ごとに異なるプロンプトを与える
• 各エージェントに次のように指示する：「シャッフルしたヌルモデルと比較して検証し、試したバリエーションの数を伝え、選択に使っていないデータで勝者を確認し、ヌル検定の z > 2 および年ごとの安定性を必須とすること」
• 5人目のエージェントには、明示的に「前の4人は同意しました。あなたも同意しますか、それとも異議がありますか？」と尋ねる
• 3/5以上が一致 → 実在する可能性が高い。1人だけが発見 → 視点固有のアーティファクトである可能性が高い

意見の相違は情報です。 2人のエージェントが異なるシグナルを見つけた場合は、それぞれを独立に検証してください。

詳細なリファレンス：findings/methodology/04-multi-lens-agent-synthesis.md。

---

4. 損失の事後分析に向けた取引ごとの拡充

シグナルが機能するときと失敗するときがある場合は、集計レベルの問いを行レベルの問いに変換します。

パイプライン：

Step 1 — Run signal across full history → collect N trade outcomes
Step 2 — Compute 20-30 causal features at each trigger bar
Step 3 — Emit parquet (per-trade × feature matrix)
Step 4 — Ship to multi-lens agents (§3)
Step 5 — Each agent hunts filters
Step 6 — Evaluate filters via shuffled-null + OOS

必須の特徴カテゴリ（各カテゴリから少なくとも1つ）：

• トレンド／レジーム（SMA、傾き、自己相関）
• ボラティリティレジーム（rv、値幅の圧縮、Kaufman ER）
• パターンのコンテキスト（トリガー時点の五分位数＋ラグ）
• 枯渇／クラスター（最後のシグナルからの経過バー数、ウィンドウ内のシグナル数）
• ポジション（スイング高値からの距離をATRで正規化）
• カレンダー（時間、曜日、月、セッション）

セッションの例：ベースラインの+0.178 bpsから、フィルタリング後は+0.514 bps（2.9倍の上昇）になりました。

完全なリファレンス：findings/methodology/06-per-trade-enrichment-postmortem.md。

---

5. 非依存な帰無仮説の段階的検証（直交する帰無仮説による再検定）

シグナルが1種類の帰無仮説を通過した場合でも、信頼する前に直交する帰無仮説で再検定します。セッションからの例：

• Phase F-Bではボラティリティ予測列をシャッフルし、+0.370のシグナルはその帰無仮説の下でz=−5.15となり、「失われました」
• Phase Cではトリガーマスクをシャッフルする（適切な帰無仮説）ことで、+0.439のシグナルはz=+5.74で通過しました

Phase Cだけを検定していたら、誤った帰無仮説を信頼していた可能性があります。Phase F-Bだけを検定していたら、本物のシグナルを見逃していたでしょう。

ルール：正の結果が得られたら必ず、直交する帰無仮説を少なくとも1つ特定して再検定します。よくある直交ペア：

• 特徴量シャッフルとマスクシャッフル
• 置換検定とブロックブートストラップ
• 選択対象のシャッフルとパラメトリック手法（例：二項分布の裾確率）

両方を通過した場合は、より信頼できます。一方を通過してもう一方に失敗した場合は、その理由を調べてください。結果の乖離から、シグナルの仕組みについて何かが分かります。

---

6. 計算オーケストレーション（pueue＋ラッパースクリプト）

長時間の並列スイープは、上で一定のルールに従ってpueue経由で実行します。

アンチパターン（気付かないうちに失敗し、0秒の「成功」となる）：

ssh <gpu-host> '~/.local/bin/pueue add -- bash -c "VAR=1 python script.py"'

正しいパターン：

cat > /tmp/run.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
export VAR="${VAR:-default}"
cd /tmp
exec uv run --python 3.14 --with numpy --with pandas python -u /tmp/script.py
EOF
scp /tmp/run.sh <gpu-host>:/tmp/
ssh <gpu-host> 'chmod +x /tmp/run.sh && ~/.local/bin/pueue add --group mygroup --label "job" -w /tmp -- /tmp/run.sh'
ssh <gpu-host> '~/.local/bin/pueue wait <id> --quiet; tail -50 ~/.local/share/pueue/task_logs/<id>.log'

重要なポイント：

• ラッパースクリプトを使う（インラインのbash -cは使わない）— pueueのsh -cによるラップで、インラインの引用符が削除されます
• バッファリングされない標準出力にはpython -uを使う（そうしないと、ログが40分間空のままになります）
• pueue restart --in-place <id>を使う（新しいタスクIDが作られる単なるrestartは使わない）
• forkマルチプロセスコンテキストを使い、COW経由で事前計算済み配列を共有する

完全なリファレンス：findings/methodology/08-compute-orchestration-pueue.md。

関連項目：拡張パターンについてはSkill(devops-tools:pueue-job-orchestration)を参照してください。

---

確認回数（暫定）

パターン	確認済み	備考
1. quintile-tokens	3	定性的スキャン、Phase Bの統計、取引ごとのCSV
2. serial-gates	主要なもの1つ（NGRAM3FUの4ゲート通過）	実証済みのテンプレート
3. multi-lens agents	3	Act-2の定性分析、Phase Cの統計、Phase Lの損失事後分析
4. per-trade-enrichment	1	Phase L — 再確認が必要
5. orthogonal null cascade	1	F-B対C — 原則そのものの発見
6. pueue orchestration	30件以上のタスク	確信度は非常に高い。標準的なインフラ

---

実行後の振り返り

このスキルを呼び出した後：

1. パターンによってバグを発見したり、時間を節約したり、検証済みの知見が得られたりしましたか？ 上の表のconfirmedを増やし、references/evolution-log.mdにセッション／監査フォルダーを記録してください。
2. パターンが失敗しましたか（誤解を招いた、計算資源を無駄にした）？ 簡単な注記を添えて表の評価を下げ、失敗したセッションへのリンクとともに進化ログに追加してください。
3. 新しい実行パターンが生まれましたか？ 新しいセクションを作成し、進化ログに追記してください。
4. 計算のアンチパターンにまた陥りましたか？ §6の説明を見直し、落とし穴を明確にしてください。