TL;DR
- 「効かないと分かった」結果は、効くと分かった結果と同じくらい価値ある
- retail researcher の time budget は限られる、同じ検証の繰り返しは贅沢
- 確定知見 docs の構造: 仮説 / 検証期間 / N / p値 / 結論 / なぜ機能しないか
- pre-registration (公開仮説) で post-hoc rationalization を防ぐ
- 1 仮説 4-8 時間で打ち切る規律
Hook
「あなたが効かないと分かった戦略リストは、効くと分かった戦略より価値がある」
retail で systematic strategy 開発を続けると、検証した仮説の 80-90% は effect なしで終わる。それを記録せずに脳内に置くと、半年後に同じ仮説をまた検証する。time budget の浪費。確定知見 docs を作って、negative result も含めて蓄積する習慣が、retail researcher の生命線。
Background — Negative Result の価値
academic 研究では publication bias で negative result が出版されにくい問題が指摘されている (publication bias、Rosenthal 1979)。retail でも同じ罠: 「効かない結果」を記録する習慣が薄いため、同じ検証を繰り返す。
実は systematic strategy の真の進化は negative result の蓄積で起きる。「これは効かない、これも効かない、これも効かない、…」を経て、機能する仮説の輪郭が見えてくる。
OSF.io (Open Science Framework) は academic で pre-registration を制度化したが、retail でも同じ概念は導入可能。
Theory — 確定知見 docs の構造
各検証 1 件につき 1 つの doc。markdown ファイル、ローカル or 公開ブログ。
推奨フォーマット
# 仮説名
## メタ情報
- 検証日: 2024-XX-XX
- 検証 N: XX trades / XX years
- 戦略カテゴリ: VRP / mean reversion / etc.
## 仮説
何を主張するか (1-2 文)
## 検証方法
- データ期間
- 戦略ロジック
- backtest プラットフォーム
## 結果
- 平均リターン: X%
- Sharpe: X.X
- p-value: X.XX
- Bootstrap CI: [X, Y]
- MaxDD: X%
## 結論
✅ 採用 / ❌ 棄却 / ⚠ 保留 のいずれか
## なぜ機能しない / なぜ機能する (考察)
理論的根拠と実証結果の整合性
## 依存仮説
この仮説が崩れたら再考必要な依存仮説のリストRetail で実装する場合
ファイル: knowledge/2024-04-VRP-15-strategy.md のような命名 バージョン管理: git で履歴を残す 公開: GitHub Pages / ブログで自分の検証履歴を一般公開する option
Practical Implementation
AI Assistant に context として渡す
retail researcher は ChatGPT / Claude / etc を使う。確定知見 docs を AI に渡せば、past 検証結果を踏まえた高品質な議論ができる。markdown frontmatter + paragraph 構造が AI への context delivery に向く。
Cascade Impact 分析
仮説 A が崩壊した時、仮説 A を前提としていた仮説 B、C も再考対象。docs に「依存仮説」フィールドを書いておくと、cascade 影響の追跡が可能。
例: – 仮説 A: 「VRP > 1.2 でしか PutWrite が機能しない」 – 仮説 B: 「VIX > 25 で sizing 拡大」(A を前提) – A が崩壊 → B も再評価必要
Time Budget Management
1 仮説の検証に 4-8 時間で打ち切る規律。8 時間超えても結論が出ない仮説は: – データが不足 → 検証棚上げ – 仮説が複雑すぎ → 分解 – 効果サイズが小さい → 棄却
「1 仮説に 1 ヶ月」のような時間投入は、retail の time budget で持続不可能。
Pre-Registration の retail 版
academic と同じ厳密さは要らないが、「事後に検定数を膨らませる」防止策として: – 検証前に仮説をブログ・Twitter・自分のメモに公開 – 結果を見てから仮説を変えるのを物理的に禁止 – 「検証する仮説リスト」を月単位で固定
OSF.io への正式登録までは要らない、自分の git repository でも機能する。
Concrete example
教科書的な docs entry:
# VRP > 1.5 で PutWrite sizing 拡大の検証
## メタ情報
- 検証日: 2024-XX-XX
- 検証 N: 156 月 (13 年)
- データ: SPX option chain、historical IV/RV
## 仮説
VIX が historical mean (20) の 1.5 倍以上 (= 30 以上) で
PutWrite ポジションを 2x に拡大すれば、
通常 sizing より Sharpe が改善する。
## 検証方法
- 1ヶ月 ATM SPX put sell
- VIX > 30 の時 2x、それ以下 1x
- T-bill collateral
## 結果
- 平均リターン (VIX>30 phase): +X%
- 平均リターン (VIX<30 phase): +Y%
- Bootstrap CI on Sharpe diff: [-Z, +W]
## 結論
⚠ 保留 — point estimate は positive だが CI 下限が 0 を割る。
N が少ない (VIX>30 の event N=18 のみ)。
## 考察
理論的には VRP magnitude が VIX 高時に大きく、sizing 拡大の rationale はある。
だが実証 sample が小さく、結論を出すには data 不足。
## 依存仮説
- VRP の long-run positivity (記事 1 参照)
- VIX mean reversion (記事 1 参照)
- sample 増加で結論が固まる可能性 (5 年後再検証)Limitation / Counter-argument
1. docs 作成自体に time cost
「knowledge docs を真面目に書く」のに 1 仮説あたり 30 分追加 cost。検証時間 4 時間に対して 12% の overhead。trade-off。
2. retail でこんな規律を続けるのは難しい
academic researcher と違い、retail は趣味の範囲。docs 文化を 6 ヶ月続けるのは個人差大。
3. AI assistant に依存しすぎるリスク
context として AI に渡すアプローチは便利だが、AI 自身の幻覚 / 古い知識で誤解を再生産する場面あり。docs の真偽は人間が check する必要。
4. Pre-registration の柔軟性問題
retail は「市場見ながら戦略を adapt する」flexibility が edge の一部。pre-registration が strict になりすぎると、市場 reactivity を失う。balance が要る。
5. 公開と secrecy の trade-off
知見を公開すると同業他者が真似する、secrecy だと AI / mentor との議論で context が失われる。retail は概念レベルで公開、具体的 parameter は私有、というハイブリッドが現実的。
Practical takeaway
retail researcher の knowledge management routine:
- 1 検証 = 1 doc (markdown): file-per-hypothesis 原則
- Negative result も保存: 「効かない」の蓄積が future の判断 quality を上げる
- 依存仮説をリンク: cascade 影響を追跡可能に
- Pre-registration 要素: 検証前に仮説と方法を文章化、結果を見て後から変えない
- AI context として再利用: 過去 docs を assistant に渡して議論質向上
- 時間予算 4-8 時間/仮説: 超えたら棚上げ or 分解
ただしこの方法論は個人の discipline 依存。継続できるかどうかが最大の不確実性。OOS 検証が future performance を保証しないように、docs 文化が future の strategy 質を保証するわけでもない。
まとめ
「効かないと分かった」結果は、retail researcher にとって effective な戦略リストよりも価値がある。同じ検証を繰り返さないこと、依存関係を追跡すること、time budget を厳守すること、これらが retail で systematic 改善を続ける規律。
OSF.io のような academic 制度は要らない、自分の git repo + markdown docs で十分機能する。「自分の知見ライブラリ」を作るのが、retail quant の最大の長期投資。
参考文献
- Lopez de Prado, M. (2018). Advances in Financial Machine Learning. Wiley. Research Process chapter.
- Open Science Framework (osf.io). Pre-Registration practice.
- Rosenthal, R. (1979). The “File Drawer Problem” and Tolerance for Null Results. Psychological Bulletin, 86(3), 638-641.
- Nosek, B.A., et al. (2015). Promoting an Open Research Culture. Science, 348(6242), 1422-1425.
- Bailey, D.H., Borwein, J., Lopez de Prado, M., Zhu, Q.J. (2014). Pseudo-Mathematics and Financial Charlatanism. Notices of the AMS.