手法・タスク説明

研究の現場では、人間がやっている作業の大半は実は手続き的な作業です。論文を読んで実装を真似する、ハイパラを変えて再実験する、関連論文を探す、結果が論文と一致するか検証する — こうした作業を AI が自動でできるようになれば、人間は「何を研究すべきか」という創造的な判断に集中できます。

このプロジェクトでは、研究のサイクル全体を 4 つの独立した CLI ツールに分解しました。それぞれが単独でも価値を生み、組み合わせると end-to-end の研究エージェントになります。

4 つの道具と、それぞれが担当する研究ステップ

以降、それぞれの道具のタスク（何を解こうとしているか）と手法（どう設計したか）を、必要な前提技術を含めて説明します。

提案手法 — generate-then-iterate

多くの再現エージェント（DeepCode、IterativeAgent 等）は「1 回コードを生成 → 評価」で止まります。我々は 「生成 → 評価 → 失敗分析 → 改善コード生成」を反復する ことでスコアを引き上げます。背景の問題意識:

• 業界の再現エージェントは 1-shot 生成が主流で、PaperBench Code-Dev で 43-75% に頭打ち
• 人間の研究者は「初稿 → 動かして直す → また直す」と反復して仕上げる
• AI も同じことをすればスコアは伸びるはず（仮説）

1 反復のステップ

1. 初期コードを生成: Reproduce Pipeline の Stage 2（Code Finding）で Claude が論文記述だけからコードを書く（v0 = baseline）
2. PaperBench で採点: SimpleJudge（claude-sonnet-4）が 58 ノードの rubric を 0〜100 で採点。0-25 / 26-50 / 51-75 / 76-100 の 4 段階で集計
3. 低スコアノードを抽出: スコアが低かった項目とその reasoning（「なぜ低かったか」の説明）を集める
4. 改善コードを生成: 論文 + 既存コード + 低スコアの分析結果を Claude に渡し、改善版を作らせる（v1, v2）
5. 再採点: 同じ rubric で新コードを採点。スコア推移を記録

実処理の流れ — どこで Claude が呼ばれ、何が起きているか

各反復で具体的に変えたこと（Stochastic Interpolants の例）

結果が示すこと

• v0 = 43.2%: 1 回生成だけで IterativeAgent o1-high の 20 本平均（43.4%）とほぼ同等。「初期生成は SOTA レベル」
• v2 = 94.5%: 2 回反復で同じ論文に対し SOTA を超える
• 反復改善ループは効くことの単一論文での実証 ✓

提案手法 — autoresearch + NRR + rollback

Karpathy の autoresearch（edit → execute → measure → evaluate のループ）は「動く」が、長く回すと同じ失敗方向を繰り返す傾向があります（LLM の弱点）。本コンポーネントは 3 つの拡張で対処:

• NRR 統合: 失敗実験を構造化保存。新提案に対して proceed / caution / avoid を返し、avoid なら別方向を強制
• 自動ロールバック: 精度が best から大きく退行したら、自動で best チェックポイントに戻す
• 提案カテゴリの強制多様化: scheduler / regularization / architecture / optimizer / augmentation / other の 6 種類から偏らずに選ばせる

1 サイクルの流れ

1. 現在の train.py で訓練（CPU で 1-3 分）→ CIFAR-10 テスト精度・損失を測定
2. Claude が失敗分析: なぜこの精度なのか、どこを変えれば改善できそうか
3. Claude が改善案を提案（カテゴリ + 具体的な diff）
4. NRR が過去の類似失敗を照合: proceed / caution / avoid を返す。avoid なら別方向を Claude に再提案させる
5. train.py を自動修正して再訓練
6. 精度が best から大きく退行したら自動ロールバック。そうでなければ次サイクルへ
7. 結果（精度・損失・提案内容・diff）を cycle-NNNN.json に記録

実処理の流れ — 1 サイクルで何が呼ばれるか

実際に走った 5 サイクル（結果ページの数字に対応）

結果が示すこと（工学的知見）

• 毎サイクル改善するわけではない: 5 回中 2 回は退行。LLM が常に賢い提案をするわけではない
• LLM の提案には偏りがある: 何度も同じ方向（深くする・容量増やす）を提案しがち。NRR が無いと延々と同方向で失敗を続ける
• ロールバックが死活的: 退行を放置すると best が失われる。自動ロールバックがあれば「悪い試行は無害化」できる

背景の問題意識

研究自動化の最大ボトルネックは 環境構築（成功率 < 7% / EnvBench）と 実行検証（end-to-end 数値一致 0% / PRBench）です。コード生成自体（PaperBench Code-Dev で 75% 程度）はかなり commoditize していますが、実際に動かして論文の数値が出るところは未解決の領域です。本コンポーネントはこのパイプライン全体を観測可能にし、どこで何が起きているかを分解します。

5 ステージの設計

1. Paper Fetching（論文取得・解析） 〜15 秒
   arXiv API で PDF 取得 → Claude が方法論・claims（主張する数値）・hyperparameters を構造化抽出。なぜ Claude か: 構造化抽出は LLM が得意、ヒューリスティックパーサーより堅牢。
2. Code Finding（コード取得・生成） 〜90 秒
   論文に公式 GitHub があればクローン、なければ Claude が論文記述から実装を生成。なぜ生成 fallback: 論文の 60-70% は公開コード無し or 部分的のため、生成パスが必要。
3. Environment Building（環境構築） 〜0.3 秒
   Python venv 作成 + 依存解決。なぜ Docker 不採用: arXiv:2601.12811 が「Docker でも完全な再現性は保証されない」と示している。まず軽量な venv で進める。
4. Experiment Execution（実験実行） 〜56 秒
   訓練スクリプトを実行、GPU/CPU 自動判定、stdout/stderr を構造化キャプチャ
5. Result Verification（数値検証） <1 秒
   Claude が論文の Table/Figure から数値を抽出 → 実行結果の metrics と ±5% 許容で比較。一致しなければ理由を記録

実処理の流れ — 5 ステージそれぞれで何が起きるか

Stochastic Interpolants での実走 — 161 秒で完走

5 ステージ全て成功で、合計 161 秒。人手なら数時間の作業がエージェント単独で完了。ただし再現スコアは 0.5（後述）。

Code Finding が時間の 56% を占める理由

Stochastic Interpolants には公式 GitHub があるが、Claude による生成 fallback を選択したため、論文を読んで一からコードを書く時間（90 秒）が長くなった。公式コードをクローンする選択肢なら数秒で済む。これは設計上のトレードオフ（生成精度 vs 速度）。

結果が示すこと

• 5 ステージ全て成功・合計 161 秒で完走 ✓
• 再現スコア 0.5: 3 つの数値主張のうち untested（実行出力に該当 metric が無かった）が多かった
• つまり 「動かすところまでは行った」が「数値完全一致は未達」。これは EnvBench / PRBench で示された業界全体のギャップと一致
• 残課題: Stage 2（コード生成精度）は §1 PaperBench Iter で +51.3pp 改善できることを実証済み。Stage 5（数値抽出）は強化が必要

背景: push 型 vs pull 型の文献調査

本プロジェクトには既に Intel というpush 型の自動収集システムがあり、5 つのコレクターが日次で 200+ 件の論文・ブログを収集しています。これは「毎日勝手に入ってくる」ストリーム型。

一方 Literature Scout は pull 型: 「いま、この瞬間に、このトピックを深掘りたい」というオンデマンドの問いに応える道具。両者を使い分けます。

動作の流れ

1. ユーザーが自然言語クエリ + 任意の --context（進行中研究の説明）を入力
2. arXiv API と Semantic Scholar API を並列呼出（同じクエリでも取れる論文集合が大きく異なるため、両方叩く）
3. 各論文の title + abstract を Claude に渡す
4. Claude が --context に対する関連度（0.0〜1.0）+ 判断理由を出力
5. 関連度でソート、上位 N 件を CLI 出力

実処理の流れ — クエリから論文カードまで

なぜ 2 ソース並列か

arXiv は preprint（査読前）中心で機械学習の最新動向に強い。Semantic Scholar は引用ネットワークと意味検索が強く、「同じトピックで似た論文」を取りやすい。同じクエリで取れる論文集合が大きく異なるので、両方叩いて重複除去するのが取りこぼしを最小化する設計です。

Claude による関連度判定が効く理由

title + abstract のキーワードマッチだけでは「関連あり」と「真に役立つ」の区別が難しい。--context として「ML 実験を自律実行して精度改善するシステムを作っている」のような文脈を Claude に渡すと、「この研究文脈で読む価値があるか」を判定してくれます。判断理由（reasoning）も同時に出るので、なぜ関連と判定したかが透明です。

結果が示すこと

• 30〜60 秒で関連論文リストが返る（API 呼び出し + Claude 分析の合計）
• Intel（push）と Scout（pull）の使い分けで「毎日勝手に入ってくる」+「気になった瞬間に深掘れる」が両立
• 残課題: 関連度判定の精度評価、autoresearch の program.md（次に試すべき手法リスト）への自動追記との連携

4 つはそれぞれ単独で動く独立した CLI ツールですが、組み合わせると研究の end-to-end ループになります。

シナリオ別の使い分け

統合運用 — 4 コンポーネントが end-to-end でどう繋がるか

同じことを別の見方で（時間軸）

1. 朝 Literature Scout が「今日の関連論文 5 本」を返す（30 秒）
2. 選択 1 本を選ぶ（人間 or 自動）
3. 3 分後 Reproduce Pipeline が再現完了。Stage 2 のコードと再現スコアが出る
4. 15 分後 PaperBench Iter で 2 反復まわす。スコアが 43% → 67% → 94% と上がる
5. 1 時間後 Self-Improving Agent が改善された train.py を走らせ、ハイパラ自動探索を開始
6. 翌朝 新しい知見（改善版モデル + 失敗パターン）が NRR に蓄積される。次の Literature Scout がこれを参考に次の論文探索を方向づける

残された大きな課題（AutoRes グループとして取り組みたい領域）

• 環境構築の堅牢化: 業界全体で 7% 未満の成功率。最大のボトルネック。Docker や仮想化を超えた解が必要
• 数値結果の検証強化: PRBench end-to-end は 0%。論文の Table/Figure から正確に数値を取り出し、実行出力と比較する仕組みが弱い
• 暗黙知の補完: 論文に書かれない関係的・身体的・集団的知識（コード作者と話さないと分からない細部）
• 長時間運用の安定性: 24/365 ループのメモリ管理、コスト管理、ドリフト検出

これらは AutoRes グループとして次の 12〜18 ヶ月で取り組むべき領域です。各コンポーネントを個別に磨きつつ、統合運用への橋渡しを進めていきたいと考えています。