【要約】バリュースクリーニングを2年前にやってたら勝てたか試したら、PBRが壊れてた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がJ-Quantsとyfinanceを用いてバックテストを行った際、計算結果が実態と乖離する問題に直面した。具体的には以下の課題が発生した。
- ・APIのレート制限により、全銘柄のループ処理が中断した。
- ・基準日より後の決算データを使用する「未来データの混入」が発生した。
- ・yfinanceの調整後株価とJ-Quantsの未調整BPSが混在し、PBRが異常に低く算出された。
// Approach
開発者は、データの整合性を確保し、API制限を回避するために以下の手法を採用した。
- ・銘柄単位ではなく開示日単位でリクエストを行い、API負荷を軽減した。
- ・基準日以前に開示された本決算のみを抽出するフィルタリングを実装した。
- ・yfinanceの分割情報を利用し、調整後株価を取引当時の実株価へ復元した。
- ・分割情報の異常値（極小値）を除外するクリーニング処理を追加した。
// Result
バグ修正後の検証により、スクリーニング手法の有効性が定量的に示された。
- ・上位30銘柄の平均リターンは+57.45%を記録した。
- ・TOPIXを約12ポイント、市場平均を約19ポイント上回った。
- ・30銘柄中28銘柄がプラスとなる、93.3%という高い勝率を得た。
- ・特定の業種に偏らず、ディープバリュー株の選別が成功した。
Senior Engineer Insight
> 外部APIを複数組み合わせる際、データの「基準」の不一致は致命的なバグを生む。本件では、株式分割による株価の調整有無が計算を破壊した。データパイプライン設計では、各ソースのデータ定義を厳格に定義すべきだ。また、APIのレート制限や異常値への対策も、実運用では必須となる。単なるロジックの実装以上に、データの整合性検証にリソースを割くべきである。