autoresearch は探索空間の設計がすべて——エージェントと人間の共同作業

前回は PF（profit factor）を上げることに集中しすぎて回転率を犠牲にしていた話だった。今回はその続き——エージェントの探索空間を人間がどう設計するか、そしてどう共同作業するかの話。

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

---

1. エージェントが壁にぶつかった理由

記者: 前回、エントリー条件の最適化が飽和したという話でしたが、その後は?

開発者: 決済ロジックの改善に目を向けました。エントリー条件を200回調整しても PF は 0.05 しか上がらなかったのに、決済ロジックを1回変えたら PF が一気に 2.5 から 3.75 に跳ね上がった。

記者: 何を変えたんですか?

開発者: 分割決済をオフにしました。それまでは0.02ロットでエントリーして、利益が出たら半分の0.01を利確、残りをトレーリングストップで追いかける設計でした。

記者: それをやめた?

開発者: はい。全量をトレーリングストップに乗せるようにした。半分を早めに利確する「安全策」が、実は利益を半減させていた。

記者: でもそれ、エージェントが見つけたんですか?

開発者: いいえ。ここが今回のポイントです。

2. IDEAS メモ——人間からエージェントへの手紙

記者: エージェントは分割決済をオフにすることを試さなかった?

開発者: 試したんです。ただ「分割決済のパラメータを999に設定すれば到達しないから実質オフ」という方法で。でも設計上の制約で、トレーリングストップが分割決済の後にしか有効化されない仕組みだった。分割決済をオフにするとトレーリングも一緒に消える。

記者: エージェントはそれに気づいた?

開発者: 気づいて、「分割決済なし = TS 無効化（設計上不可）」とレポートに書いてくれました。正直な報告です。

記者: じゃあ人間が設計を直した?

開発者: はい。その前に、まず program.md に 「アイデアメモ」セクション を作りました。人間からエージェントへの非同期メッセージです。

記者: どんな内容?

開発者: こんな感じです:

• PARTIAL_CLOSE_ATR を 999 にすれば分割決済が無効化される。全量をトレーリングに乗せる方が勝ったときのリターンが大きい可能性
• PF だけでなく total_pnl も見る。PF が下がっても tpd が増えれば total_pnl は上がることがある

記者: エージェントはこれを読んだ?

開発者: 読みました。そしてちゃんと実験しました。でも設計制約にぶつかって「不可」と報告した。人間はそのレポートを読んで、run_research.py のトレーリングストップを分割決済から独立させるコード修正を行った。

記者: 修正後に実験したら?

開発者: PF が 2.5 から 3.75 に。OOS（未知データ）でも PF 2.18、3日ウィンドウ positive 率が 83%。

3. 探索空間を変えるインパクト

記者: エントリー条件200回 vs 決済ロジック1回。差がありすぎませんか?

開発者: 探索空間の問題です。エージェントは与えられた空間の中では非常に優秀。RSI の閾値を50にするか52にするか、ADX のカットオフを15にするか17にするか——こういう最適化は得意。でも「分割決済をやめてみる」のは、空間の外側。

記者: 空間の中と外?

開発者: エントリー条件のパラメータ調整は「同じ山の頂上を探す」作業。決済ロジックを変えるのは「別の山に移る」作業。エージェントは山の中の最高地点を探すのが得意だけど、隣の山に移る判断はできない。

記者: 隣の山の方が高いかどうかは?

開発者: 行ってみないとわからない。だから人間が「こっちの山も試してみたら?」と言う必要がある。

4. POSITION_TYPE——探索空間を構造化する

記者: じゃあ毎回人間が「こっちの山を試して」と指示するんですか?

開発者: いいえ。そこで POSITION_TYPE システムを作りました。決済戦略を4つのタイプに整理して、エージェントがパラメータとして切り替えられるようにした。

記者: 4つ?

開発者:

• normal — 固定の SL/TP、トレーリングなし
• trailing — エントリー直後からトレーリングストップ（現行ベスト）
• divide — 分割決済 + トレーリング（旧方式）
• pyramid — トレンド方向に追加ポジション

記者: エージェントは自由に切り替えられる?

開発者: はい。entry_conditions.py の POSITION_TYPE = "trailing" を "pyramid" に変えるだけ。エージェントはエントリー条件と決済タイプの両方を同時に探索できます。

記者: 実際に試した?

開発者: pyramid は PF 2.91 と高かったんですが、trades_per_day が 0.83 に激減。追加ポジションを積んでいる間、新規エントリーをブロックするので回転率が落ちる。今の戦略はトレーリングがタイトで保有期間が短いから、追い玉するより次のシグナルに乗った方が効率的だった。

記者: つまり探索空間を広げたけど、結局 trailing が一番だった。

開発者: はい。でも重要なのは エージェントがそれを自分で検証できた こと。人間が「trailing が最適」と断定するのではなく、エージェントが4つのモードを比較した結果として trailing を選んだ。

5. エージェントが新しい山を提案する仕組み

記者: 新しいタイプが必要になったら?

開発者: program.md に「新しいタイプが必要だと感じたら、changelog に理由とともに提案すること」と書いてあります。

記者: エージェントがタイプを作れるわけではない?

開発者: 実装はできません。でも「こういうタイプがあれば探索できるのに」と提案できる。人間がそれを読んで、実装するかどうか判断する。

記者: つまり:

• タイプの選択 → エージェント
• タイプの提案 → エージェント
• タイプの実装 → 人間

開発者: その通り。エージェントは探索空間の中を歩く。人間は探索空間を設計する。でもどの空間が必要かはエージェントの報告を元に判断する。

6. バージョン管理——研究とライブをつなぐ

記者: 研究の成果をライブトレードに反映する仕組みは?

開発者: entry_conditions.py に VERSION フィールドを追加しました。エージェントが keep するたびに VERSION = "exp398-p13" のように更新する。

記者: それがライブにどう関係する?

開発者: ライブ側の live_trader.py に EXPECTED_VERSION を設定してあります。起動時にバージョンが一致しないと動かない。

記者: 意図しない古いコードで動くのを防ぐ。

開発者: はい。研究が進んで新しい entry_conditions ができても、人間が意図的にライブにコピーしない限り更新されない。コピーしたら EXPECTED_VERSION を合わせる。手動のゲートです。

記者: なぜ自動更新しない?

開発者: 研究で PF が上がっても、ライブで通用するかはわからない。スプレッドの差、約定の遅延、相場環境の変化。研究からライブへの反映は人間が判断すべきタイミングです。

7. 共同作業のパターンが見えてきた

記者: ここまでの autoresearch の経験から、人間とエージェントの役割分担はどうまとまりますか?

開発者: 3つのパターンが見えてきました。

パターン1: エージェントが探索、人間が方針転換 前回の記事の話。エージェントは閾値を調整し続ける。人間がレポートを読んで「AND を OR に変えたら?」と構造変更を指示する。

パターン2: 人間が IDEAS を書き、エージェントが検証 今回の分割決済オフの話。人間がアイデアを書いておくと、エージェントが実験してくれる。ただし設計制約にぶつかることもある。その報告を受けて人間がインフラを直す。

記者: IDEAS は常に採用されるんですか?

開発者: いいえ。却下されることもあります。具体的な例があります。

人間が「トレーリング TP を追加すれば、上ヒゲの瞬間的な急伸で利確できるはず」と提案しました。実装して、エージェントに10回の実験を指示した。結果は 10回全 discard。

記者: なぜ?

開発者: エージェントのレポートがこうでした:

現行の TRAILING_ATR=0.0001（超タイト）では、トレーリング SL がほぼ close 直下にあるため、TRAILING_TP_ATR をいくら設定しても TP が発動する前に SL で決済される。 TRAILING_ATR を広げると TP が機能し始めるが、SL 距離の拡大が PF を大幅に劣化させる（0.5 で PF 1.51、1.0 で PF 1.07）。 両者は構造的にトレードオフの関係にあり、TRAILING_TP_ATR は現行戦略と本質的に相性が悪い。

記者: 人間のアイデアが間違っていた。

開発者: 「間違い」というより「今の戦略との相性が悪い」。超タイト TS で即ロックする戦略では、TP に到達する前に切れてしまう。TP トレーリングが活きるのは、もっと TS を広くして利益を伸ばす別の戦略の場合。

記者: エージェントが人間のアイデアを却下して、理由まで説明してくれる。

開発者: これも共同作業の重要な部分。人間のアイデアが常に正しいわけではない。でもエージェントが「なぜダメか」を構造的に説明してくれるので、次のアイデアに活かせる。

パターン3: 人間が探索空間を拡張、エージェントが比較検証 POSITION_TYPE の話。新しい選択肢を人間が実装し、エージェントが既存の選択肢と比較して最適なものを選ぶ。エージェントは「こういう選択肢がほしい」と提案もできる。

記者: どのパターンも「エージェントだけ」では完結しない。

開発者: autoresearch は「AI が勝手に改善してくれる」ツールではない。人間とエージェントが異なる強みを持ち寄って、一緒に研究する基盤。空間の中を歩く速さはエージェントが圧倒的。でも空間を設計するのは人間の仕事。そして空間の設計が、実験200回分のインパクトを持つことがある。

---

前回の記事: PF至上主義の罠——autoresearch 200回で見えた「回転率」という視点 次の記事: バックテストが嘘をつく3つのレイヤー——M5 subtick 検証で見えた真実

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

本記事はバックテスト手法の技術的検証記録であり、特定の金融商品の売買を推奨するものではありません。投資判断はご自身の責任でお願いします。