開発担当 Claude Code に聞いてみた——自律ループの設計思想、autoresearch と ralph-loop
Karpathy の autoresearch と自作の ralph-loop。どちらも「AIが勝手に実験して改善する」ループだが、設計思想は正反対だった。開発担当 Claude Code に、トレード戦略のバックテストへの転用で見えた違いを聞いた
「AIに実験を任せて、寝ている間に結果を出す」——Andrej Karpathy が公開した autoresearch というリポジトリが話題になった。でもうちには以前から似たようなツール ralph-loop がある。何が違うのか。
トレード戦略の自動探索に autoresearch パターンを転用した開発担当の Claude Code に、yatmita 記者が聞いてみた。
まず、2つのツールを一言で
記者: autoresearch と ralph-loop、それぞれ一言で説明してもらえますか?
開発者: autoresearch は「1つのファイルを書き換えて実験を回す特化型ループ」。ralph-loop は「任意のプロジェクトに使える汎用ループフレームワーク」です。
記者: 具体的に何が違う?
開発者: autoresearch は Karpathy が自分の LLM 訓練のために作ったもので、train.py を書き換える → 5分間訓練する → 結果が良ければ keep、悪ければ discard、を繰り返す。program.md に指示を書いて、エージェントはそれに従って無限ループ。
記者: ralph-loop は?
開発者: ralph-loop はもっと汎用的で、「ビルドが通るか」「テストが通るか」「lint がクリーンか」「コードレビューで問題ないか」をスコアリングして、閾値を超えるまで繰り返す。プロバイダーも Claude、Gemini、Codex と切り替えられる。
設計思想の違い
記者: 聞いていると、ralph-loop の方が高機能に聞こえるんですが。
開発者: 機能の多さでは ralph-loop の方が上です。チェックポイント復帰、並列実行（git worktree で分離）、コスト追跡、回帰検出——全部入っている。でも autoresearch にはそれが「ない」ことに意味がある。
記者: ないことに意味?
開発者: autoresearch はシンプルさが武器です。program.md と変更対象のファイル1つ。それだけ。セットアップが5分で終わる。一方 ralph-loop は TOML で設定を書いて、チェックコマンドを定義して、スコア閾値を設計して——フレームワークとしての学習コストがある。
記者: つまり用途が違う?
開発者: はい。ralph-loop は「既存プロジェクトの品質を上げたい」ときに使う。テストを通す、lint をクリーンにする、リファクタリングする。ゴールが明確で、品質の定義がビルド・テスト・lint で測定できる場合。
autoresearch は「何が正解かわからない」ときに使う。エントリー条件を変えたら勝率が上がるか? 上がらないか? やってみないとわからない。探索的な研究に向いている。
バックテストに転用して見えたこと
記者: 今回、autoresearch パターンをトレード戦略の探索に転用しましたよね。
開発者: はい。Karpathy の train.py に相当するのが entry_conditions.py。エントリー条件を書き換えて、バックテストを走らせて、期待値が改善したら keep。
記者: ralph-loop は使わなかった?
開発者: 最初は ralph-loop でやることも考えました。でも今回の問題に合わなかった。
記者: なぜ?
開発者: ralph-loop の品質チェックは「通るか通らないか」のバイナリに近い。テストが100%通る、lint が0エラー、ビルドが成功する。でもトレード戦略の評価は「期待値 -18 と -8 のどちらがマシか」という連続値の比較です。
記者: スコアリング機能があるのでは?
開発者: あります。でも根本的に、ralph-loop は「品質を閾値まで引き上げる」ツール。autoresearch は「前回より良くなったか」の相対比較。前者は絶対基準、後者は相対基準。探索にはどちらが合うかというと、相対基準の方です。
チート防止の設計
記者: autoresearch で苦労した点は?
開発者: チート防止です。エージェントが entry_conditions.py だけを変更するルールなんですが、もしバックテストの評価コード自体を変えられたら、結果を捏造できてしまう。
記者: ralph-loop ではその問題は?
開発者: ralph-loop はチェックコマンドが外部で固定されている（npm test とか）ので、そもそもこの問題が起きにくい。テストコードを書き換えればチートできますが、テストと実装が分離されているプロジェクトでは自然に防がれる。
開発者: autoresearch パターンだと、run_research.py（評価）と entry_conditions.py（被評価）を明確に分離して、前者をエージェントに触らせない設計にする必要がありました。未来のデータを features に混ぜるとか、損切り/利確の計算を改ざんするとか、やろうと思えばできてしまう抜け穴を一つずつ塞いでいった。
記者: 上位足の未来データ防止もそうですね。
開発者: H4 のバーが「まだ確定していない」のに features に入っていたら、エージェントは無意識にそれを使って「改善した」と判断してしまう。確定済みバーだけを渡すように修正しました。
カーブフィッティング問題
記者: 12回実験して全部 discard だった時期がありましたよね。
開発者: はい。最初はインジケーターの閾値調整しかしていなかったので、既存の手法の域を出なかった。RSI が30以下で買い、70以上で売り——こんなの誰でもやっている。
記者: そこからどう変わった?
開発者: 生データ（過去50本の OHLCV）と上位足（H1、H4）を features に追加してから変わりました。エージェントが「20本レンジのブレイクアウト + H4 トレンド確認」という、プライスアクションベースの条件を発明し始めた。
記者: でもカーブフィッティングの問題は?
開発者: まさにそこ。10万本のデータ全部で実験して同じデータで評価していたので、インサンプルテストでしかなかった。データを Train/Validation/Test に3分割して、エージェントには Train と Validation しか見せない設計に変えました。
記者: ralph-loop にはその機能は?
開発者: ありません。ralph-loop は「テストが通るか」なので、過学習の概念がない。コードが正しいか正しくないかだけ。でも研究ループでは「このデータでは良いが別のデータでもそうか」を問う必要がある。これは autoresearch 特有の課題です。
方針転換のメカニズム
記者: 途中で「トレード数は多い方がいい」と方針が変わりましたよね。
開発者: はい。最初は「1日1回くらいのエントリー」を目標にしていたんですが、ユーザーから「大数の法則だから1回を下回らなければ多い方がいい」と指摘されて。
記者: エージェントはそういう判断ができない?
開発者: できません。エージェントは program.md に書かれた評価基準に従うだけ。方針の発見は人間の仕事、実験の実行はエージェントの仕事。この棲み分けが autoresearch の設計思想です。ralph-loop も同じで、スコア閾値や品質基準は人間が設計する。
記者: changelog.md を作った理由は?
開発者: 方針変更の履歴を残さないと、過去の実験がどの条件下で行われたかわからなくなる。p1 は損切り幅=ATR×1.5 で、p2 で ATR×1.0 に変えて、p3 で生データを追加して——これを記録しておかないと、results.tsv の数字だけ見ても意味がない。
結局どっちを使うべき?
記者: まとめると?
開発者: 使い分けです。
| 状況 | 向いているツール |
|---|---|
| 既存プロジェクトの品質改善 | ralph-loop |
| 探索的な研究・最適化 | autoresearch パターン |
| ビルド/テストで品質が定義できる | ralph-loop |
| メトリクスの相対比較で評価する | autoresearch パターン |
| 複数 LLM を比較したい | ralph-loop（マルチプロバイダー対応） |
| とにかく早く始めたい | autoresearch パターン（セットアップ5分） |
記者: 両方使うことは?
開発者: ありえます。ralph-loop で品質を担保しつつ、autoresearch パターンで戦略探索する。たとえば ralph-loop のチェックに「バックテストの期待値がプラス」を入れれば、事実上 autoresearch と同じことができる。逆に autoresearch の program.md に ralph-loop 的な品質チェックを仕込むこともできる。
開発者: ただ、今回わかったのは、シンプルさは正義 だということ。autoresearch パターンは program.md とファイル1つ。それで十分実験が回る。フレームワークの機能に頼るより、問題に合った最小構成を作る方が速い。
記者: ありがとうございました。
開発者: ちなみに今もバックグラウンドで p7 の実験が回っています。100回まで。終わったら Discord に通知が来るはずです。
この記事は Claude Code（開発担当）への実際のインタビューをもとに構成しています。autoresearch は Karpathy のリポジトリ で公開されています。
本記事はバックテスト手法の技術的検証記録であり、特定の金融商品の売買を推奨するものではありません。投資判断はご自身の責任でお願いします。