計画の生成から次の一手の判断へ：AutoResearch は研究を幻覚なしでどう閉ループ化するのか

AutoResearch は、課題発見、計画生成、スウォーム実験、独立検証を、継続的に前進できる一つの研究プロセスとして接続する。Django の修正タスクでは、公式の新機能テストを 2/7 から 7/7 へ改善し、同時に回帰テスト 203/203 の通過を維持した。3 件の Kaggle 実験でも、目標達成、目標への接近、プラトーを区別し、その証拠に基づいて継続、方向転換、停止を判断した。

AutoResearch は自動研究システムである。論文、オープンソースプロジェクト、コミュニティでの議論、技術的な異常を継続的に観測し、研究する価値のある課題を見つけ、複数のモデルを編成してアイデアを実験に変え、外部結果に次の行動を決めさせる。

このプロセスが対象とするのは、事実の捏造より見抜きにくい失敗である。コードは実在し、ローカルテストも実際に通っているのに、システムが「この部分は正しい」を「問題全体が解決した」と誤認する。

図 1｜ローカルテストがすべて成功しても、確認できるのは既存の検査範囲だけである。独立評価は、まだ検査されていない重要な欠落を明らかにする。

実際の Django 修正タスクで、GPT-5.6 は migration テスト 716 件と optimizer テスト 39 件をすべて通過したが、公式の新機能テストは 0/7 だった。AutoResearch も初回で問題全体を解決できなかった。ローカルテストはすべて通過した一方、公式結果は 2/7 にとどまった。違いは失敗後に現れた。システムは外部結果から問題を再定義し、2/7、4/7、7/7 と前進して、新機能テストと回帰テストの両方が通るまで続けた。

1. 4 つの動作が研究の主ループを構成する

図 2｜課題を見つけ、検証可能なアイデアを作り、実験し、証拠に判断させる。この 4 動作が AutoResearch の主ループを構成する。

AutoResearch の主ループは、次の 4 つの連続した動作から成る。

1. 課題を発見する：公開情報から、追跡可能な新しい現象、結果、未解決の矛盾を抽出する。
2. 検証可能なアイデアを作る：手掛かりを、成功基準、資源上限、失敗条件を持つ研究仮説へ書き換える。
3. スウォーム実験を編成する：計画、実装、実行、レビューを異なる役割の協働で進める。
4. 証拠に判断させる：外部結果が、反復、方向転換、停止のいずれかを決める。

失敗だけでワークフローが閉じることはない。失敗は次のラウンドへの入力となり、システムに課題境界の絞り込みや実験経路の変更を促す。

2. 答えを出す前に、研究する価値のある課題を見つける

AutoResearch は arXiv、Hugging Face Daily Papers、OpenReview、GitHub Trending に加え、Reddit、Hacker News、研究ブログ、中国語の技術メディア、Twitter/X を観測する。チャネルごとにデータ形式、人気の意味、情報密度が大きく異なるため、収集後は共通形式へ正規化し、品質フィルタ、同一バッチ内の重複排除、日をまたぐ重複排除を行う。

第 1 段階のモデルは、各情報に研究課題へ変換できる洞察があるかを素早く判断する。残った候補はより高性能なモデルへ渡され、新規性、技術的実現性、必要資源、検証方法の観点からさらに選別される。候補が十分に集まると再度順位付けし、Idea Forge に優先投入する研究シードを選ぶ。

このファネルは、開かれた情報流を、実験資源を投じる価値のある少数の候補へ圧縮する。研究課題には明確な出典が残るため、後続の計画を最初の観測まで戻って検証できる。

3. Idea Forge：手掛かりを実験計画へ変える

研究シードは、外部世界から得た現象や課題にすぎない。Idea Forge は知識ベースから既存の研究方向も一つ選び、両者を組み合わせて候補計画を作る。現在の知識方向には、マルチモーダル融合、視覚トークン管理、大規模モデルの推論とテスト時計算（test-time compute）、Agent Memory などがある。

Gemini、GPT、Claude が候補アイデアをそれぞれ提案し、レビューする。3 種類のモデルは学習背景と判断の傾向が異なり、新規性に敏感なもの、技術的実現性を重視するもの、資源や評価設計の穴を先に見つけるものがある。候補計画は実行前に次の 4 つの検査を通過する必要がある。

• クロスレビュー：3 モデルが独立に判断し、同じアイデアが少なくとも 2 票を得た場合だけ続行する。
• 鮮度検査：古いモデル、古い年、すでに陳腐化した技術表現を除外する。
• 知識合意検査：計画が対応する知識方向を実際に利用しており、流行語を機械的に結合しただけではないことを確認する。
• 多段階計画：第 1 段階では方向を素早く判定できる低コストの予備実験を行い、その後に規模拡大、アブレーション追加、評価完了へ進む。

多数決の目的は盲点を早期に露出させることにある。最終計画は、測定可能な仮説、明確な予算、成否を判定できる実験へ落とし込まなければならない。

4. 計画から実験へ：スウォームはどう協働するか

図 3｜研究シードはクロスレビューと計画を経て、計画、実装、実行、レビュー、外部評価から成る協働フローへ入る。

実行段階では、AutoResearch は作業を連続したタスク単位へ分解する。調整役が全体状態を維持し、計画役が目標を反証可能な実験設計へ書き換え、実装役がコードを書き、実験実行役がコードを動かして結果を整理し、レビュー役が異なる観点から欠落を探す。

単純なタスクでは役割を減らし、複雑なタスクでは Subcoder、Monitor、独立検証役を追加できる。役割名が結果を決めるわけではない。重要なのは、計画、実装、実行、レビューを一度のモデル回答に詰め込まないことである。

計画、コード、実験記録、レビュー所見は同じ永続ワークスペースに残る。ループは未完了の単位を処理し続け、外部指標と停止条件が許可した時点で終了する。実験結果が計画を覆すことも、レビューが誤ることもある。役割が出した終了提案だけではワークフローを閉じられない。継続と停止を決めるのは、再現可能な結果と独立した成功基準である。

5. システム検証 I：研究目標を検証可能な結果まで進める

AutoResearch は 3 件の Kaggle 課題で共通する実験プロトコルを用いた。まず低コストの予備実験で方向を検証し、その結果から本実験を設計する。各段階に成功基準、コードレビュー、実行記録、停止判断がある。3 課題の主要指標は、それぞれ accuracy、二乗平均平方根対数誤差（RMSLE）、F1 であり、指標の方向は Kaggle の公式課題定義に従う [1][2][3]。

図 4｜同じ実験プロトコルから 3 種類の結末が生じた。Titanic は目標を達成し、House Prices は目標に接近し、Disaster Tweets はプラトーに入った。3 つの縦軸は独立しており、タスク間で数値比較しない。

5.1 Titanic：厳密な対照で特徴量エンジニアリングの効果を確認する

第 1 段階では 9 個の基本特徴でベースラインを作り、Gradient Boosting の 5 分割交差検証 accuracy は 0.8272 だった。第 2 段階では Title、FamilySize、IsAlone、年齢ビン、運賃ビンなどを追加した。

Control と Treatment は、同じ乱数シード、同じデータ分割、同じモデルを使用した。Control は基本特徴を維持し、Treatment は拡張特徴を追加した。Control は第 1 段階の結果を完全に再現し、Treatment は 0.8428 に達して 0.8300 の目標線を超えた。2 条件の主要な差は特徴集合だけなので、この結果は特徴量エンジニアリングが今回の改善をもたらしたことを支持する。

5.2 House Prices：改善の大部分を生んだ変更を特定する

目標は 5 分割交差検証 RMSLE を 0.1200 未満にすることだった。システムは小標本で Ridge ベースラインを作り、次に予測対象だけを変更して住宅価格に log1p 変換を適用した。RMSLE は 0.2008 から 0.1566 に低下した。少数の派生特徴を加えた結果は 0.1563 で、特徴をさらに積み増す効果が小さいことが分かった。

全量実験では、モデル系統を線形モデルから LightGBM へ変更し、0.1258 まで低下させた。拡張特徴と交互作用を加えた最終結果は 0.1251 だった。目標には届かなかったが、主要な改善源は特定できた。目的変数の変換とモデル系統の変更が改善の大部分を占め、追加特徴の効果は限定的だった。システムはこれを根拠に、調整範囲を機械的に拡大することを止めた。

5.3 Disaster Tweets：プラトーが停止を促す

目標は F1 で 0.8350 に達することだった。システムは TF-IDF とロジスティック回帰から始め、0.7680 の語彙ベースラインを作った後、SBERT、DistilBERT のファインチューニング、ソフト投票アンサンブルを試した。最高値は 0.8049 だった。

続いてパラメータ数を 66M から 125M に増やし、RoBERTa-base を使用したが、最高値は 0.8005 で DistilBERT を上回らなかった。21 回の実験後も最良結果は 0.8049 のままだった。大きなモデルが改善をもたらさなかったため、システムは同じ経路への実験追加を止め、次の選択肢を有効なデータの追加、学習資源の追加、モデリング方針の変更の 3 つに絞った。

6. システム検証 II：局所修正から完全解決へ進める

第 2 の評価は SWE-bench Lite の django__django-16820 を使う。SWE-bench はモデルが生成したパッチを実在のリポジトリへ適用し、リポジトリのテストを実行して問題が解決したかを判定する [4]。このタスクは Django の Meta.index_together 非推奨化に由来し、migration optimizer と autodetector が RenameIndex、AddIndex、RemoveIndex、循環外部キーにまたがって協調する必要がある。Django の upstream での議論にも、これらのインデックス操作と複雑な migration 最適化の関係が記録されている [5]。

図 5｜GPT-5.6 はローカルテスト通過、公式新機能テスト 0/7 の時点で終了した。AutoResearch は 2/7 と 4/7 の結果から問題を書き換え続け、最終的に 7/7 へ到達し、回帰テスト 203/203 の通過も維持した。2 条件は時間とフィードバック条件が異なり、ここで比較するのは失敗後のプロセスである。

GPT-5.6 は実在する欠落を見つけた。CreateModel.reduce() に RenameIndex(old_fields=...) の折り畳みロジックがなかった。そのパッチは optimizer テスト 39 件、migration テスト 716 件、公式回帰テスト 203 件を通過したが、公式新機能テストは 0/7 だった。RenameIndex の部分問題は解決したが、AddIndex、RemoveIndex、autodetector、循環外部キーは対象外だった。

AutoResearch も第 1 ラウンドでは RenameIndex を重視した。コードレビューで no-match guard の欠落を発見し、修正後は optimizer テスト 41 件、squashmigrations 統合テスト 11 件、migration テスト 719 件が通過した。最初の公式結果は 2/7 だった。

外部結果により、研究対象は単一の reduce() 分岐から optimizer と autodetector の協調へ広がった。第 2 版は 4/7 に改善した。次のラウンドでは、インデックス状態が migration フローに入り、折り畳まれ、収束するまでを追跡した。最終的に公式新機能テストは 7/7 に達し、回帰テスト 203/203 の通過も維持した。

7. AutoResearch が自動化するのは研究判断である

2 組の評価から、AutoResearch の中核能力は次の 5 つに整理できる。

1. 研究課題を実行可能な対象へ変える：アイデアは、予備実験、成功基準、資源予算、アブレーション計画、成果物に落とし込む必要がある。
2. 異なるモデルを適切な位置に置く：軽量モデルが多数の候補を選別し、高性能モデルが深く判断し、複数のモデル系統が独立にアイデアを提案、レビューする。
3. 段階結果に次の行動を決めさせる：目標達成、目標への接近、負の結果はいずれも証拠を残し、それぞれ拡張、調整、停止を起動する。
4. 完了条件を独立指標に委ねる：内部役割の合意やローカルテストの全通過は、事前に定義された完全な成功基準を代替できない。
5. システムが停止できるようにする：方向がプラトーへ入るか、投入対効果が低下した時点で現在の経路を閉じ、再開に必要な状態と結論を残す。

モデルは提案し、実装し、疑う。次の行動は証拠が決める。

8. 成功とは途切れていない証拠の連鎖である

大規模モデルは候補回答を素早く作ることに長けている。AutoResearch は回答後の完全なループを設計する。課題をどう実験に変えるか、誰が結果をレビューするか、失敗がどう次の一手を書き換えるか、継続を支持するにはどの証拠が必要か、どの条件でシステムを止めるかを扱う。

この方法はループエンジニアリング（Loop Engineering）と呼べる。設計対象は役割とプロンプトだけではなく、状態の保持、証拠の流れ、判断の再確認まで含む。役割は誤ることがある。ループはその誤りを露出させ、証拠のない「成功」がワークフローを閉じることを防がなければならない。

9. 参考文献

1. Kaggle. (2012). Titanic - Machine Learning from Disaster. Kaggle Getting Started Competition.
2. Kaggle. House Prices - Advanced Regression Techniques. Kaggle Getting Started Competition.
3. Kaggle. Natural Language Processing with Disaster Tweets. Kaggle Getting Started Competition.
4. Jimenez, C. E., Yang, J., Wettig, A., et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. The Twelfth International Conference on Learning Representations.
5. Django Software Foundation. (2023). Fixed #34529, Refs #34525: Reduced index operations with Meta.indexes / index_together when optimizing migrations. django/django Pull Request #16820.