同じ検証を繰り返さない — 確定知見 docs の作り方

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 検証 = 1 doc (markdown): file-per-hypothesis 原則
  2. Negative result も保存: 「効かない」の蓄積が future の判断 quality を上げる
  3. 依存仮説をリンク: cascade 影響を追跡可能に
  4. Pre-registration 要素: 検証前に仮説と方法を文章化、結果を見て後から変えない
  5. AI context として再利用: 過去 docs を assistant に渡して議論質向上
  6. 時間予算 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.

コメントする