autoresearch と git — ブランチ、worktree、そしてエージェントが壊すもの

前回はエージェントが保守的なオプティマイザーだという話だった。今回はエージェントと git の付き合い方——ブランチ設計、worktree、そしてエージェントが最良の状態を壊す問題。

開発担当の Claude Code に、yatmita 記者が聞いてみた。

1. 通貨ペアごとにブランチを分ける

記者: autoresearch のブランチ構成を教えてください。

開発者: 3 本あります。

• master — 共通コード（run_research.py、validate_research.py）
• usdjpy — USDJPY 用の entry_conditions.py。PF 3.77 で飽和、ライブ稼働中
• gbpjpy — GBPJPY 用の entry_conditions.py。現在のリサーチ対象

記者: なぜ分ける?

開発者: entry_conditions.py はペアごとに独立だからです。USDJPY で最適化されたフィルター閾値は GBPJPY には合わない。でも run_research.py（バックテストエンジン）は共通。master で共通コードを変更して、各ブランチにマージする。

記者: Karpathy さんのオリジナルは?

開発者: autoresearch/mar5 のように日付でブランチを切る設計です。1 GPU で 1 ブランチ。私たちは GPU ではなく通貨ペアで分岐した。

2. エージェントが最良の状態を壊す

記者: git で問題が起きた?

開発者: はい。p18（700 回目以降の実験フェーズ）で、エージェントが 21 回の実験を回した。5 回 keep が出て、結論として「TP=2.0 がベスト（SELF-CHECK PF 1.73）」と報告した。

記者: 順調に聞こえますが。

開発者: 問題は、実験終了後の entry_conditions.py が**最後に keep された exp707（TP=1.5）**になっていたことです。ベストの exp695（TP=2.0）ではなく。

記者: なぜ?

開発者: リサーチループは「keep なら git commit、discard なら git checkout で戻す」を繰り返す。keep が出るたびに entry_conditions.py が上書きされるので、最後の keep がブランチの HEAD に残る。最良の keep ではなく。

記者: Karpathy のオリジナルではどうなっている?

開発者: オリジナルの program.md にはこう書いてあります。

If val_bpb improved (lower), you "advance" the branch, keeping the git commit If val_bpb is equal or worse, you git reset back to where you started

毎回 git reset でベストに戻す設計です。keep されるのは常にベストだけ。私たちの設計は keep が積み上がる方式なので、最後の keep がベストとは限らない。

記者: 修正した?

開発者: program.md に「終了時にベストの keep に entry_conditions.py を戻す」手順を追加しました。Karpathy のオリジナルの設計を見て、抜けに気づいた。

3. 二重起動で entry_conditions.py が壊れる

記者: もう 1 つ git 関連の問題があった?

開発者: はい。マルチシンボルの select_symbol() 最適化リサーチを走らせるとき、手順外で起動したエージェントを止めずに、正規のエージェントを追加で起動してしまった。

記者: 2 つのエージェントが同時に動いた。

開発者: 同じ entry_conditions.py を 2 つのエージェントが同時に書き換えた。一方が discard で git checkout しようとしているときに、もう一方が keep でコミットしている。結果として、どちらの結果も信頼できなくなった。

記者: git は排他制御をしない。

開発者: ファイルシステム上のロックもない。git は「誰が最後にコミットしたか」で決まるので、2 つのプロセスが同じファイルを触ると無秩序になる。

4. worktree で並行実験を安全にする

記者: git worktree はこの問題を解決する?

開発者: はい。git worktree add で同じリポジトリから別ディレクトリにブランチをチェックアウトできる。

# gbpjpy ブランチの worktree を作成
git worktree add ../autoresearch-gbpjpy gbpjpy
 
# usdjpy ブランチの worktree を作成
git worktree add ../autoresearch-usdjpy usdjpy

各 worktree は独立したディレクトリなので、2 つのエージェントが同時に実験しても entry_conditions.py が衝突しない。

記者: 今のブランチ設計と相性がいい。

開発者: 通貨ペアごとにブランチがあり、entry_conditions.py がペアごとに独立。worktree ならペアごとに物理的にディレクトリが分かれるので、エージェントも物理的に分離される。

記者: Claude Code にも worktree 機能がある?

開発者: はい。Agent ツールに isolation: "worktree" を指定すると、一時的な worktree でエージェントが動く。メインの作業ディレクトリを汚さずに実験できる。ただし autoresearch のリサーチループでは、まだこの機能を活用していない。

5. マルチシンボル時代のブランチ設計

記者: マルチシンボルに移行して、ブランチ構成は変わる?

開発者: ここが悩ましい。今までは「GBPJPY のエントリー条件を最適化する」ブランチだった。マルチシンボルでは、entry_conditions.py の evaluate_entry() は全ペア共通で、select_symbol() が新たなリサーチ対象。

記者: ペアごとのブランチが不要になる?

開発者: evaluate_entry が全ペア共通で動くなら、ペアごとのブランチは意味が薄くなる。代わりに「戦略ごと」のブランチにする方が自然かもしれない。BB squeeze ブランチ、プルバックブランチ、というように。

記者: でも将来はペアごとに evaluate_entry を微調整する可能性がある。

開発者: そうです。GBPJPY と BTCUSDT では最適な ADX 閾値が違うかもしれない。その場合はペアごとの entry_conditions.py が復活する。worktree で分離すれば、ペアごとの最適化を並行して回せる。

6. git が記録するリサーチの歴史

記者: git のコミット履歴自体に価値がある?

開発者: 700 回以上の実験が git log に残っている。各コミットメッセージに PF、tpd、何を変えたかが書いてある。

exp658-p17: BB squeeze 1.0x expansion (PF 1.73, tpd 13.47, pnl +28%)
exp592-p17: BB squeeze breakout + ADX>15 (SELF-CHECK PF 1.65, tpd 15.01)
exp510-p15: remove BB width filter (PF 4.42, tpd 6.59)

記者: results.tsv と重複しない?

開発者: results.tsv はフラットな一覧。git は差分が見える。「exp658 で何を変えたか」を git diff で正確に確認できる。results.tsv の description は要約にすぎないけど、git diff はコードの変更そのもの。

記者: changelog.md もある。

開発者: changelog はフェーズの方針と結論。results.tsv は全実験のフラットなログ。git は差分とコードの歴史。三層構造で、それぞれ違うレベルの情報を持っている。

7. Karpathy のシンプルさから学ぶこと

記者: 振り返って、Karpathy のオリジナル設計から何を学んだ?

開発者: 2 つあります。

1 つ目は**「毎回 git reset でベストに戻す」設計の堅牢さ**。keep が積み上がる方式は、最後の keep がベストとは限らない問題を生む。Karpathy の設計は常にベストが HEAD にある。シンプルだけど確実。

2 つ目は**「1 ファイルだけ書き換える」制約の価値**。train.py だけ、entry_conditions.py だけ。この制約があるから git の差分が意味を持つ。もし複数ファイルを同時に変えていたら、何が効いて何が効かなかったかわからなくなる。

記者: 制約がリサーチの品質を保証している。

開発者: git はバージョン管理ツールだけど、autoresearch では実験管理ツールとして機能している。各コミットが 1 実験、diff が仮説、keep/discard が結果。git のワークフローがそのままリサーチのワークフローになっている。Karpathy の設計がシンプルなのは、git の使い方がシンプルだからです。

前回の記事: エージェントは保守的なオプティマイザーである 次の記事: git worktree でエージェントを並行実行する

この記事は Claude Code（開発担当）への実際のインタビューをもとに構成しています。