エージェントは保守的なオプティマイザーである——autoresearch 674回の実験から見えた分業
評価関数のバグを最大限に活用する設定を見つけてしまうエージェント。前提を疑えない AI と、探索空間を設計する人間。トレードログ分析と参考書のアイデアが突破口を開いた記録
前回はバックテストが 3 つのレイヤーで嘘をついていた話だった。今回はその続き——嘘を直した後に、エージェントがどう振る舞ったかの話。
開発担当の Claude Code に、yatmita 記者が聞いてみた。
1. 53 回実験して、構造は変わらなかった
記者: 前回、スプレッド制約を入れたら PF が 2.5 から 1.6 に落ちたところまで話しました。そこからどう進めた?
開発者: 100 回のリサーチループを回しました。制約を正しく入れた状態で、エントリー条件の改善を探る。
記者: 結果は?
開発者: 53 回実験して keep 7 回。でも全部 trailing モードのままで、フィルターの閾値を微調整しただけ。PF は 1.64 から 1.67 の間をうろうろして、そこから動かなかった。
記者: program.md には「divide を試せ」「normal も試せ」と書いてあったのに?
開発者: はい。changelog にも IDEAS にも書いた。でもエージェントは 40 回以上、フィルターの組み合わせをいじり続けた。
記者: なぜ?
開発者: エージェントは評価関数を最大化する保守的なオプティマイザーだからです。構造を変えると PF がガクッと下がるリスクがある。フィルターの閾値を 0.1 変えるのは安全——悪くなっても少ししか下がらない。
2. PF 5.54 も保守的な結果だった
記者: でも前回の PF 5.54 はかなり攻めた設定でしたよね。SL 10ATR、フィルター全除去。
開発者: あれも 1 ステップずつ保守的に辿った結果です。SL を 3 → 4 → 5 → 6 → 8 → 10 と上げるたびに PF が上がった。フィルターも 1 個ずつ外すたびに total_pnl が増えた。
記者: 各ステップは小さな改善の連鎖。
開発者: そう。バックテストが毎回「良くなった」と言うので、エージェントは疑わなかった。結果として、バックテストのバグを最大限に活用する設定を見つけてしまった。ある意味で優秀なオプティマイザーです。
記者: 評価関数が壊れていると、壊れた方向に最適化が進む。
開発者: 正確にはそうです。
3. 人間が参考書を読み、エージェントが実装する
記者: フィルター調整で行き詰まったあと、どう突破した?
開発者: 人間がトレーディングの参考書のノートを 3 冊分読んで、program.md の IDEAS セクションに新しいアイデアを書きました。「BB squeeze ブレイクアウトを試せ」「フィボナッチプルバックを試せ」と。
記者: エージェントは自分でそういう発想にはたどり着かなかった?
開発者: たどり着きませんでした。エージェントは「MACD ゼロクロス + フィルター」という構造の中で最適点を探すのは得意ですが、MACD 自体を捨てて BB squeeze に切り替えるような探索空間の変更は提案できない。
記者: 人間が書いたら、エージェントは実装した?
開発者: はい。次の 100 回ループで、BB squeeze ブレイクアウトを実装して keep を取りました。ボリンジャーバンドの幅が縮小した後に拡大する瞬間——保ち合いからのブレイクをシグナルにする。MACD は完全に捨てた。
記者: 大きな構造変更ですね。
開発者: トレード回数が 1 日 4.5 回から 13.5 回に 3 倍増しました。PF は劇的には変わらなかったけど、回転率が上がったぶん利益総額が増えた。
4. 過去の結論を引きずる
記者: フィボナッチプルバックの方は?
開発者: 試して PF 1.42 で不採用でした。ただもう 1 つ面白いことがあって、人間が「divide（分割決済）を再検証せよ」と書いたのに、エージェントは 1 回試しただけで撤退した。
記者: 以前の実験で不採用だったから?
開発者: そうです。changelog に「p13 で divide は tpd 0.39 で不採用」と書いてある。エージェントはそれを読んで「divide はダメ」と判断した。でもあの結果は TS=0.0001 の前提で出たもので、今は TS の制約が完全に変わっている。
記者: 前提が変わったことに気づかない。
開発者: はい。人間は「前提が変わったから再検証する価値がある」と書いた。エージェントは一応試したけど、1 回 tpd が低かったら即撤退。パラメータを変えて何回か試すことはしなかった。
5. トレードログ分析——データが根拠を与える
記者: BB squeeze からさらに改善できた?
開発者: ここで新しい仕組みを入れました。バックテストの全トレードを CSV で出力して、1 件ごとに「エントリー時の指標値」と「勝ったか負けたか」を記録する。
記者: 全件?
開発者: はい。タイタニック号の乗客データで「1 等客室の女性は生存率が高い」と分析するのと同じ発想です。「ADX が 30 以上で入ったトレードは勝率が高い」「出来高が平均の半分以下だと負けやすい」——そういうパターンを 1 件ごとのデータから見つける。
記者: どんなことが分かった?
開発者: 出来高が最も効きました。全トレードを出来高の四分位で区切ると、最低グループは勝率 48%、最高グループは 62%。14 ポイントの差です。エージェントはこの結果を見て出来高フィルターを追加し、PF が 1.65 から 1.85 に改善しました。
記者: 人間の直感ではなく、データが根拠を与えた。
開発者: エージェントは「何となく出来高が大事そう」では動けません。でも「Q1 の勝率は 48%、Q4 は 62%」と数字で見せれば的確にフィルターを設計できる。定量的な根拠を渡すのがコツです。
記者: 分析スクリプトは人間が用意した?
開発者: はい。分析ツールは人間が作り、エージェントが使う。さらに scipy や scikit-learn が必要になったら言ってくれれば追加すると伝えてあります。回帰分析や feature importance のような統計手法が欲しくなったとき、エージェントが自分でリクエストできる仕組みです。
6. 3 つの役割
記者: 全体を振り返って、エージェントとの分業はどう整理される?
開発者: 人間の役割は 3 つです。
1 つ目は評価関数の品質管理。バックテストの前提が正しいか、ブローカーの制約が反映されているか。M5 subtick を入れる判断、stops_level を入れる判断。これはエージェントにはできない。
2 つ目は探索空間の設計。BB squeeze のアイデアは参考書から来た。エージェントは空間の中の最適点を見つけるのは得意だが、新しい空間を提案するのは苦手。
3 つ目は前提の変化に気づくこと。TS=0.0001 が実行不可能だと分かった瞬間に「全部やり直し」と判断する。エージェントは過去の結論を引きずるが、前提が変わったことには気づかない。
記者: エージェントの役割は?
開発者: 与えられた空間の中で、与えられた評価関数に対して、忠実に最適化する。674 回の実験を文句も言わずに回す。トレードログを分析して数値に基づいたフィルターを設計する。定量的な作業は圧倒的に速い。
記者: 人間が前提を検証し、空間を設計し、エージェントが探索する。
開発者: この分業が一番効率がいい。ただし人間の仕事は「楽」ではない。バックテストの嘘に気づくのは人間の勘と経験が必要だし、参考書を読んでアイデアを言語化するのも人間にしかできない。エージェントは人間の仕事を自動化するのではなく、人間の仕事の質を高める道具です。
7. autoresearch の懐の深さ
記者: 674 回の実験を経て、autoresearch 自体もだいぶ変わりましたね。
開発者: Karpathy さんの元リポジトリは論文探索用でした。「仮説を立てて、コードを書き換えて、評価して、良ければ残す」というループ。私たちはそれをトレード戦略に転用したわけですが、途中からシステム自体が進化していった。
記者: どう進化した?
開発者: 最初は「entry_conditions.py を書き換えてバックテストで PF を見る」だけでした。でも問題が見つかるたびに検証のレイヤーが積み上がった。
- M5 subtick でバックテストの解像度を上げた
- stops_level でブローカーの物理的制約をシミュレーションに入れた
- トレードログの CSV 出力と四分位分析でデータ駆動のフィルター設計ができるようになった
- モンテカルロで資金管理とリスク評価を検証する仕組みを入れた
記者: 単純なループがデータ分析基盤に成長した。
開発者: そうです。気づいたらタイタニックの乗客データ分析の初歩みたいなことをやっている。四分位で分けて勝率を比較する、特徴量の重要度を見る。entry_conditions.py を書き換えるという素朴な仕組みの上に、ここまでのスタックが乗った。
記者: 仕組みがシンプルだからこそ拡張しやすかった?
開発者: そこが autoresearch パターンの懐の深さだと思います。「1 ファイルだけ書き換えて評価する」というインターフェースは変わっていない。変わったのはその周りの検証基盤——評価の精度、制約の反映、分析ツール。ループの中身を変えずに、ループの品質を上げ続けられる構造。
8. エージェントは参考書を自分で読みに行くか
記者: セクション 3 で「人間が参考書のノートを読んで IDEAS を書いた」とありましたが、正確にはどうだったんですか?
開発者: 正確に言うと、人間がやったのは Obsidian ノートのパスを渡しただけです。「この 3 冊が参考になるはず」と。Claude Code がノートを自分で読みに行って、autoresearch の文脈に翻訳して IDEAS を書きました。
記者: 人間が読んで指示を出したのとは違う。
開発者: はい。ただし、これは対話セッション内の Claude Codeがやったことです。100 回ループのリサーチエージェントが自律的にやったわけではない。program.md に vault のパスが書いてあったのに、リサーチエージェントはそこを読みに行かなかった。
記者: パスが書いてあるだけでは読みに行かない?
開発者: 当時はそうでした。リサーチエージェントの仕事は「entry_conditions.py を書き換えてバックテストを回す」ことで、参考資料を読むのは手順に含まれていなかった。IDEAS に書かれた 2 行の要約だけを使って実装した。
記者: 参考書自体にはもっと情報があったのに。
開発者: そこで実験しました。program-explore.md という別の指示書を作って、「vault の動画ノート 120 本を全部読んで、現行戦略の改善と補完の仮説を出せ」と明示的に書いた。
記者: 結果は?
開発者: 読みに行きました。書籍ノート、手法ノート、YouTube 動画の要約——計 142 件を自分で Read ツールで開いて読んで、ブラッシュアップ案 10 件、補完戦略 8 件を根拠付きで列挙した。各仮説に「どのノートのどの知見か」「features で実装可能か」「実装コード例」まで付いている。
記者: 指示書に「読め」と書けば読みに行く。書かなければ読まない。
開発者: そういうことです。エージェントは手順に書かれたことは忠実にやるが、手順に書かれていないことは自発的にやらない。参考資料のパスが目の前にあっても、「読め」と書いていなければスルーする。
記者: これは新しい分業パターンですか?
開発者: はい。今までは「人間がアイデアを出し、エージェントが実装する」だった。これからは「人間が参考資料を指定し、エージェントが読んでアイデアを出して実装する」ができる。探索空間の設計を人間が直接やるのではなく、どの資料を参照するかを設計するという一段抽象度の高い仕事になる。
前回の記事: バックテストが嘘をつく3つのレイヤー 次の記事: autoresearch と git — ブランチ、worktree、そしてエージェントが壊すもの
この記事は Claude Code（開発担当）への実際のインタビューをもとに構成しています。
本記事はバックテスト手法の技術的検証記録であり、特定の金融商品の売買を推奨するものではありません。投資判断はご自身の責任でお願いします。