テーマ株の相関検出と次テーマ予測を深夜バッチに分ける
銘柄評価を毎日回していると、個別企業の良し悪しだけでは説明しにくい動きが出てくる。ある時期だけ特定の業種、材料、社会テーマに関連する銘柄がまとまって動くことがあり、通常のファンダメンタルズ評価とは別に「今どのテーマが効いているのか」を観測したくなる。今回は、日次の銘柄評価パイプラインとは分けて、テーマ株の相関検出と次テーマ予測を行う深夜バッチを追加した。
> 本記事は自動化とデータ分析の実装記録です。特定銘柄の推奨や投資助言ではありません。候補出力は調査の入口であり、売買判断には一次資料と人の確認が必要です。
実際に行ったことと確認できた結果
手元の実装では、既存の銘柄評価基盤に対して、テーマ株検出・予測システムを独立した機能として追加した。日次ノート上では、株価の動きと相関が大きいテーマ株を見つけ、次に来そうなテーマと関連銘柄を予測する仕組みとして記録されている。変更は深夜バッチ関連を含む複数ファイルにまたがり、通常の銘柄評価、通知、コスト削減、ドキュメント同期とは機能単位で分けて整理された。
確認結果として、テーマ株システムは現行の銘柄評価とは別枠で深夜バッチとして実行する設計になったこと、作業内容が機能別コミットに分割されたこと、最終ツリーで全532テスト成功とruffクリーンが確認されたことが記録されている。つまり、単なるアイデアではなく、実装・構成整理・検証まで進んだ取り組みとして扱える。
仕組みの流れ
この機能の狙いは、毎朝の個別銘柄評価へさらに処理を詰め込むことではない。評価バッチはすでに市場別の対象選定、公開情報確認、スコア保存、通知を担っているため、テーマ探索まで同じ時間帯に入れると実行時間と推論コストが読みにくくなる。そこで、テーマ検出は別ジョブに分離した。
処理の流れは次のように一般化できる。
1. 既存DBまたは日次成果物から、銘柄ごとの価格変化、評価結果、関連キーワードを読む。
2. テーマ辞書や抽出済みキーワードを使い、銘柄とテーマの対応候補を作る。
3. 同じテーマに属する候補群の値動き、出来高、評価イベントを集計する。
4. 相関や急変の強さをもとに、注目テーマ候補を並べる。
5. 次回の深掘り評価に回すテーマと関連銘柄を、レポートまたはDBへ保存する。
6. 既存の日次評価バッチとは別のcronで、安価または空いている時間帯に実行する。
ポイントは、「テーマ候補を出す処理」と「個別企業の投資判断」を分けることだ。前者は探索、後者は検証であり、同じスコアのように扱うと誤解を招く。
再現手順
公開例では、実際のユーザー名、プロジェクト名、通知先、データベースの場所は置き換える。
“`bash
cd /path/to/project
uv sync
python -m pytest
ruff check .
“`
次に、テーマ抽出用の設定を用意する。最初は本番DBではなく、小さなサンプルDBやCSVで試す。
“`bash
export STOCK_DB=/path/to/sample.sqlite3
export THEME_OUTPUT=/path/to/theme-report.md
export HERMES_NOTIFY_TARGET=discord:YOUR_TARGET
python theme_batch.py –db "$STOCK_DB" –date 2026-08-19 –dry-run
“`
ドライランで、入力件数、テーマ候補数、除外理由、出力先が想定どおり表示されることを確認する。問題なければHermes Agentのcronへ、既存の朝バッチとは別時刻で登録する。Hermes公式ドキュメントでは、cronは自然言語またはcron式で自動実行を登録でき、CLIからは`hermes cron create`を使えると説明されている。
“`bash
hermes cron create "30 2 * * 1-5" \
"Run the stock theme detection batch and report only verified output" \
–name "stock theme nightly batch" \
–workdir /path/to/project
“`
初回は通知を短くし、保存されたレポート、実行ログ、終了コードを確認する。既存の銘柄評価レポートへ混ぜる場合も、見出しを分けて「テーマ候補」と明記する。
失敗しやすい点と安全策
一番危ないのは、相関を因果や予測的中として扱うことだ。短期間に同じ方向へ動いた銘柄群があっても、原因が同じとは限らない。テーマ候補は「次に調べる入口」として保存し、個別銘柄の採用判断とは切り離す。
次に、通常バッチとの責務混在に注意する。テーマ探索は候補数が増えやすく、LLM要約を入れるとコストも増える。今回のように深夜バッチへ分けると、朝の評価ジョブが失敗したときの切り分けもしやすい。
未完了事項として、深夜cronの実運用スケジュールと監視方針は継続確認対象になっている。テスト成功はコードの契約確認であり、将来のテーマ抽出品質を保証するものではない。
再現チェックリスト
- [ ] テーマ探索を通常の銘柄評価ジョブから分けている。
- [ ] ドライランで入力件数、候補数、出力先、除外理由を確認した。
- [ ] テーマ候補を投資判断や推奨として表示していない。
- [ ] 既存DBへ書く前にサンプルデータで検証した。
- [ ] 全テストとlintを実行し、失敗時はcron登録前に止める。
- [ ] Hermes cronの実行ログと通知先を初回運用で確認する。
公式一次情報
- [Hermes Agent CLI Commands Reference](https://hermes-agent.nousresearch.com/docs/reference/cli-commands)
- [Hermes Agent Scheduled Tasks (Cron)](https://hermes-agent.nousresearch.com/docs/user-guide/features/cron)
- [Python sqlite3 documentation](https://docs.python.org/3/library/sqlite3.html)
