coreytrading
レビュー済みで監査可能な状態変更を備えた、LLM エージェントによるトレーディング運用システム
プロジェクト背景
LLM はエビデンスを読み、分析を書くのには役立つが、状態やお金を直接動かすべきではない。設計上の問いは、データ・計算・書き込みの完全な制御をコードが握ったまま、どうやってモデルにリサーチで協働させるかだった。
アーキテクチャ
スケジューラー → ホストコントローラー → エビデンス取得（証券会社・マーケットのキャッシュ、バリュエーション台帳。凍結・ハッシュ化）→ ロールワーカー（Claude / Codex。構造化 JSON のみ、ワークスペースや証券会社へのアクセスなし）→ ホストによる検証（ポリシー、鮮度、リビジョン）→ 制御されたカードライター → レシート → 人間によるレビューと手動執行。
主な技術ポイント
各エージェントは凍結・ハッシュ化されたエビデンスのスナップショットを受け取り、スキーマ検証済みの JSON を返さなければならない
状態変更は制御されたライターを経由：変更前イメージのバックアップ、リビジョンチェック、事前に用意したレシート、盲目的なリトライの代わりにハッシュベースの突合
ロールからモデルへのルーティング。呼び出しごとにモデルと effort を明示指定。呼び出し予算（同時2件、ローリング1時間あたり12件）
取引所カレンダーに連動したスケジュールジョブ：寄り付き前ブリーフィング、引け後の状態遷移、コードで描画するマクロ視点、週次レビュー
約12.1万行の Python コードと約2,900件の自動テスト
コア実装
モデルが提案し、コードが決める
ワーカーは凍結されたエビデンスを受け取り、構造化された提案を返す。ホストはポリシーと対象の現在のリビジョンに照らして検証し、その後で制御されたライターが適用する。
Why: モデルの出力は信頼できない入力である。検証、リビジョンチェック、レシートによって、すべての変更が説明可能で元に戻せるものになる。
不確実な書き込みはリトライせず突合する
すべての書き込みには変更前後のハッシュを含む事前レシートがある。クラッシュ後のリカバリーではハッシュを比較してレシートを更新し、書き込みを繰り返さない。
Why: 仕事で払い出し処理に用いたのと同じ冪等性の規律を、シングルユーザーのシステムに適用した。