はじめに
日本株を対象に、データの取得から因子（銘柄を選ぶための指標）の発掘、毎日の売買判断、模擬口座での検証までを自動で回す AI クオンツシステム「QuantG」を個人で作っています。
中心にあるのは、LLM に因子を自分で掘らせることです。この記事では、細かい実装よりも、このシステムをどんな考え方で組み立てたかを紹介します。
全体の流れ
データの自動取得
↓
時点を揃えたデータ（その日に知り得た情報だけ）
↓
因子テーマ・因子定義 → LLM が因子のコードを書く
↓
自動評価と前向き検証 → 因子プール
↓
毎日の売買判断 → 模擬口座・ヒストリカルリプレイ
↑
定時タスクがこの流れ全体を自動で回す
核心：LLM が自分で因子を掘る
これまでの因子研究は、人が仮説を立て、式を書き、検証するという流れでした。この方法では、試せる数に限りがあり、発想も書く人の癖に偏りがちです。
QuantG では役割を分けています。
- 人：どの方向を掘るか、何を良い因子とみなすかを決める
- LLM：因子のコードを書く
- システム：書かれた因子を自動で評価し、残すかどうかを決める
LLM が書いた候補は、過去のデータで選ばれたあと、選んだ時点ではまだ見ていなかった期間で改めて確かめられます（前向き検証）。両方を通ったものだけが因子プールに入り、売買判断に使われます。
掘り方のルール自体も育てていきます。一定期間ごとに、LLM がこれまでの結果を読んで「パラメータの範囲をこう変えてはどうか」と提案します。ただし、採用するかどうかは LLM ではなくシステムが決めます。提案どおりに過去を再現し、今のルールより明確に良い場合だけ新しいバージョンとして採用します。LLM はデータベースを直接書き換えられず、合否も決められません。LLM は提案し、判断はシステムが行うという線引きを全体で守っています。
因子テーマと因子定義：LLM にデータを使い切らせる
LLM に「良い因子を作って」とだけ頼むと、価格や出来高を使った似たような因子ばかりが出てきます。財務、決算予定、投資部門別の売買状況など、手元にあるデータの多くは使われないままです。
そこで、掘る範囲を二段階の「研究の地図」として先に定義しました。
- 因子テーマ：大きな研究の方向。たとえば「短期の値動き」「ボラティリティと値幅」「流動性と出来高」「相対強弱と市場状態」「決算とイベント」「ファンダメンタルとバリュエーション」など
- 因子定義：テーマの下にある具体的な研究課題。仮説、使ってよい入力データ、探索する観点、データを使うときのルールを構造化して書く
因子定義の例です（実際の定義を簡略化しています）。
{
"テーマ": "短期の値動き",
"定義": "短期のリターン状態",
"仮説": "ごく短期のリターンの向き・連続性・加速度で、勢いの継続と行き過ぎの反転を見分けられる可能性がある",
"入力": ["日足の日付", "銘柄コード", "調整後終値"],
"観点": ["累積リターン", "方向の一貫性", "加速度", "短期の反転"],
"ルール": [
"シグナル日より後のデータは使わない",
"データが足りないときは欠損のままにし、未来のデータで埋めない"
]
}
定義には式もコードも書きません。書くのは「何を調べたいか」と「どこまで使ってよいか」だけで、具体的な式を考えるのは LLM の仕事です。
定義がデータの各領域をくまなく覆うように並べておけば、LLM の探索も自然とデータ全体に広がります。定義ごとに独立して掘り、それぞれのルールをバージョン管理しているので、ある定義でうまくいかなくても他の定義には影響しません。
また、値動きのような速い因子は短い間隔で掘り直し、決算や開示のような遅い因子は新しい開示がある程度たまるごとに掘り直します。流れは同じで、区切り方だけが違います。
未来のデータを見ない
バックテストで一番怖いのは、知らないうちに未来の情報を使ってしまうことです。QuantG では、評価や判断に使うデータを「その日の時点で知り得た情報だけ」で毎回作り直します。財務データは開示された時点から使い、あとから訂正された値も、訂正された日からしか見えないように扱います。上の因子定義に「ルール」を書いているのも同じ理由です。
模擬口座とヒストリカルリプレイ
因子が良さそうに見えても、実際に売買して利益が出るとは限りません。そこで、最終的な評価は手数料を含めた売買の結果で見るようにしています。
- 模擬口座：毎日、因子プールの因子でモデルを学習し、翌営業日の買い候補・指値・数量を決めます。約定、手数料、受渡、損切り、期限での手じまいまでを台帳に記録します。資金や一日に買う銘柄数、損切りの幅などが違う口座を並べて、方針の違いを比べられます。
- ヒストリカルリプレイ：「もし過去のある時点から、今の因子と今の方針で模擬口座を始めていたらどうなったか」を、過去の一日一日をたどって再現します。設定ごとに使う因子を選べるので、因子を一つずつ足していき、それぞれがどれだけ効いているかを比べる実験もできます。リプレイの中でも、各日にはその日までのデータしか使いません。
ある因子を「入れた場合」と「外した場合」で売買の純利益を比べ、その因子が本当に利益に貢献しているかを確かめる仕組みもあります。
定時タスクで自動化する
日々の運用は、定時タスクで人の手を介さずに回ります。
- データの自動取得：取引所のデータ更新に合わせて、データが最新の取引日に追いついていなければ差分を取りに行きます。取引カレンダーも先の分まで延ばしておきます。
- 毎日の売買判断：データがそろったら、有効なすべての口座について、その日の判断と模擬売買を実行します。
- 因子の継続マイニング：新しく評価できる期間ができたら、因子の発掘を自動で先に進めます。
- そのほか、不要になった中間データの回収や、因子の健康診断なども定時タスクにしています。
スケジューラは「薄い目覚まし時計」として作りました。決まった時刻に業務側へ「今やるべきか」を聞き、やるべきなら実行を頼み、結果を記録するだけです。やるかどうかの判断はすべて業務側にあるので、新しい定時タスクを足してもスケジューラは変えずに済みます。また、失敗したあとの再開のように人の判断が必要な操作は、自動ではやらないようにしています。
技術構成
画面は React、バックエンドは Python（FastAPI）と PostgreSQL で作り、LLM は OpenAI 互換の API で呼び出すので、モデルは設定で切り替えられます。すべてのサービスは一台の Mac の中で動き、外からはアクセスできません。時間のかかる処理は状態をデータベースに残し、途中で止まっても続きから再開できます。
おわりに
QuantG の考え方をまとめると、人は「どこを掘るか」と「何を良しとするか」を決め、LLM が「掘る」を担い、システムが「確かめる」を担う、ということです。
まだ発展途上で、検証の結果をもとに各層を作り直している最中です。進み具合はまた記事にする予定です。
※ この記事は個人の研究・開発の記録で、特定の投資を勧めるものではありません。