開発担当 Claude Code に聞いてみた——autoresearch を100回回してわかった7つのこと
Karpathy の autoresearch パターンでトレード戦略を自動探索してみた。100回以上の実験で見えた過学習の罠、方針転換の難しさ、そして「AIが発明したのはベテランの常識だった」という結論
前回は autoresearch と ralph-loop の設計思想を比較した。今回はその続き——実際に autoresearch パターンでトレード戦略の自動探索を100回以上回した結果、何がわかったのか。
開発担当の Claude Code に、yatmita 記者が聞いてみた。
1. 過学習で全部パーになった
記者: まず一番印象的だった出来事を教えてください。
開発者: 51回の実験で6回の改善を積み上げて、ようやくバックテストで期待値プラスを達成したんです。Train データで +11、Validation データで +71。「やった！」と思った。
記者: それがダメだった?
開発者: Test データで確認したら -26。完全に崩壊していました。
記者: なぜ?
開発者: 過学習です。エージェントに Train と Validation の両方の数値を見せて、「両方で改善したら keep」というルールにしていたんです。51回繰り返すうちに、Validation のデータにもフィットしてしまった。
記者: Validation って過学習を防ぐためのものでは?
開発者: その通りです。でも 毎回数値を見せて keep/discard の判断材料にした のが間違いでした。事実上、Validation を Train の一部として使ってしまったのと同じ。
記者: どう解決した?
開発者: validate_research.py という別スクリプトを作って、keep か discard の一言だけ返す ようにしました。エージェントには Out-of-Sample の数値が一切見えない。
記者: それで改善した?
開発者: はい。次のラウンドでは Train と OOS がほぼ同じ数値になりました。OOS でも期待値プラス。エージェントに見えないデータで検証するという、当たり前のことを当たり前にやるだけでした。
2. エージェントは方針を変えられない
記者: 方針転換で苦労したと聞きましたが。
開発者: 最初は「1日1回くらいのトレードチャンスがほしい」という目標で始めたんです。エージェントはフィルターを追加してトレード数を減らす方向で実験を重ねた。
記者: それは合理的に聞こえますが。
開発者: でもユーザーから「大数の法則だから1回を下回らなければ多い方がいい」と指摘されて。考えたらその通りで、トレード数が多いほど統計が安定する。フィルターで減らすのは逆効果だった。
記者: エージェントは気づかなかった?
開発者: 気づけません。エージェントは program.md に書かれた評価基準に忠実に従うだけ。「trades_per_day を1.0に近づける」と書いてあれば、それに向かって最適化する。「多い方がいい」という判断は人間がしないといけない。
記者: だから changelog.md を作った。
開発者: はい。方針変更のたびに記録を残さないと、過去の実験がどの前提で行われたかわからなくなる。8フェーズにわたる方針変更を全部記録しています。
記者: 方針の発見は人間の仕事、実験の実行はエージェントの仕事。
開発者: そう。autoresearch の設計思想はそこにあります。
3. 既存インジケーターの閾値調整では限界がある
記者: 最初の12回は全部 discard だったそうですね。
開発者: RSI が30以下で買い、70以上で売り。ADX でトレンドだけ狙う。MACD のゼロラインクロス。ストキャスティクスのゴールデンクロス。12パターン試して全滅。
記者: 何がダメだったんですか?
開発者: 全部「みんながやっていること」だからです。RSI 30 で買うなんて、入門書の1章目に書いてある。そこにエッジはない。
記者: どう突破した?
開発者: エージェントに 生データ を渡すようにしました。過去50本のローソク足データ（OHLCV）と、1時間足・4時間足の上位足データ。インジケーターの計算結果ではなく、生の価格データから自分で何でも計算できるようにした。
記者: それで変わった?
開発者: 変わりました。「20本レンジのブレイクアウト + 4時間足のトレンド確認」とか、プライスアクションベースの条件が出てきた。
記者: つまり features が狭すぎると、autoresearch の強みが活きない。
開発者: その通り。autoresearch の本当の価値は「構造的に新しいことを発明できる」こと。でも使える部品が貧弱だと、組み合わせの最適化しかできない。
4. 100回回して辿り着いたのは「ベテランの常識」
記者: 最終的にどんな手法に落ち着いたんですか?
開発者: MA クロスオーバーに4つのフィルターを重ねたものです。
記者: 具体的には?
開発者: 1つ目が「価格が MA から離れすぎたクロスは無視する」。2つ目が「ローソク足のボディが十分大きい足でだけエントリーする」。3つ目が「MA 自体の傾きが十分急であること」。4つ目が「ストキャスティクスで過熱圏を避ける」。
記者: それって……
開発者: はい。トレーダーが経験的にやっていることそのものです。「もう伸びきってるからやめとこ」「ローソク足に勢いがないな」「MA がちゃんと動いてるか確認」「天井で買うな」。全部裁量判断の言語化。
記者: 100回回してそれですか。
開発者: 100回回してそれです。autoresearch は「新しいことを発明する」のではなく、経験則を数値で裏付けた という結果でした。
5. エントリー条件より決済ロジックの方が効く
記者: でも最終的には成績が劇的に変わったんですよね?
開発者: はい。でもそれはエントリー条件の改善ではなく、決済ロジックを変えた からです。
記者: どう変えた?
開発者: 固定の利確を廃止して、分割決済 + トレーリングストップにしました。エントリーして、ある程度利益が出たら半分を利確。残りのストップを建値に移動して、トレーリングストップで追いかける。
記者: 効果は?
開発者: 勝率が37%から57%に跳ね上がりました。分割決済で原本を確保するので、半分のトレードは確実に勝ちになる。破産確率もほぼゼロに。
記者: エントリー条件は同じなのに?
開発者: 同じです。エントリーの改善で期待値を上げるのに100回かかったのに、決済ロジックの変更は1回で勝率を20ポイント上げた。
6. スプレッドを正確にしないと結果は信用できない
記者: バックテストの信頼性について何かありましたか?
開発者: スプレッドです。バックテストでは固定スプレッドを使っていたんですが、実際のデータに含まれるスプレッドを調べたら、暗号通貨の設定が実態の6倍以上甘かった。
記者: つまり暗号通貨のバックテスト結果は楽観的だった。
開発者: はい。通貨ペアは設定と実態がほぼ一致していたので問題なかったんですが、暗号通貨は桁が違った。
記者: 対策は?
開発者: 過去データに含まれるバーごとの実スプレッドを使うようにしました。固定値ではなく、各バーの実際のスプレッドで約定コストを計算する。
記者: 地味だけど重要ですね。
開発者: バックテストは「嘘をつける」ツールなので、こういう細部が信頼性を決めます。未来データの混入防止、スプレッドの正確性、データ分割——一つずつ穴を塞いでいかないと、結果が良くても実際には通用しない。
7. autoresearch は「実験装置」であって「発明家」ではない
記者: 全体を振り返って、autoresearch とは何だと思いますか?
開発者: 実験装置です。仮説を高速に検証する機械。でも仮説を立てるのは人間の仕事で、実験の前提を設計するのも人間の仕事。
記者: 過大評価されている?
開発者: いえ、価値はあります。人間が寝ている間に100回の実験を回せるのは圧倒的。でも「AIが勝手に改善してくれる」という期待は間違い。正確には「人間が設計した実験フレームワークの中で、AIが実験を高速に実行する」です。
記者: フレームワークの設計が悪いと?
開発者: 100回回しても何も見つからない。features が貧弱なら閾値調整しかできないし、過学習防止がなければ偽の改善を積み上げる。今回は8フェーズの方針転換を経て、ようやくまともな結果が出た。
記者: その方針転換のプロセス自体が autoresearch では自動化できない。
開発者: できません。そこが人間の仕事です。
次の記事: PF至上主義の罠——autoresearch 200回で見えた「回転率」という視点
この記事は Claude Code（開発担当）への実際のインタビューをもとに構成しています。
本記事はバックテスト手法の技術的検証記録であり、特定の金融商品の売買を推奨するものではありません。投資判断はご自身の責任でお願いします。