- Autoresearch システムは、LLM エージェントが
train.py を繰り返し修正しながら性能を改善する制約最適化ループ構造で、仮説設定から評価までを自動で循環実行する
- 実験はコンテナベースのサンドボックス環境で実行され、ネットワークアクセスと任意コード実行を遮断する
- Ukiyo-eVG データセットを用いて、約 11,000 枚の日本木版画画像と注釈情報を学習に活用し、CLIP ベースのモデルで Mean Rank 34.30、R@5 約 53% の性能を達成した
- 主な改善は temperature パラメータの制約緩和（Mean Rank -113） と ハイパーパラメータチューニング（Mean Rank -30） で、1 日 42 回の実験のうち 13 回のコミットを通じて 54% の性能向上を記録した
- LLM エージェントは明確に定義された探索空間では効果的だったが、構造変更フェーズ以降は不安定性が増し、完全な自律研究には限界があることが明らかになった
コアアイデア
- Autoresearch は LLM エージェントを中心とした制約最適化ループ構造で、エージェントが
train.py を修正しながら評価指標を反復的に改善する
- エージェントは
program.md の指示を読み、scratchpad.md を作業メモとして使って実験過程を記録する
- 探索はいくつかの**フェーズ（phase）**で構成され、初期はハイパーパラメータチューニングから始まり、小規模な構造変更を経て、その後は制約を最小化した自由探索へと拡張される
- 全体ループは 仮説設定 → コード修正 → 学習 → 評価 → コミットまたはロールバック → 反復 の循環構造として設計されている
- 各実験は約 5 分以内で完了するよう制限され、高速な反復と過学習防止を促す
- エージェントは時間制限内で
train.py を自由に修正できる
-
サンドボクシング
- 任意コード実行の危険を防ぐため、コンテナ環境で学習ループを実行し、ネットワークアクセスを遮断する
run.sh が実験全体のフローを管理し、Claude Code は train.py と program.md のみ修正可能- Python の直接実行、pip インストール、ネットワークアクセス、git push などはすべて制限される
- 関連実装は GitHub リポジトリで公開されている
データセット
- 元の研究で使われた医療 X-ray データセットにアクセスできなかったため、代わりに Ukiyo-eVG データセットを新たに使用した
- 約 11,000 枚の日本木版画画像とフレーズ-バウンディングボックス注釈を含む
- バウンディングボックスを ガウシアンヒートマップに変換してモデル入力に追加し、元の eCLIP 論文の専門家 attention メカニズムに近い方式を適用した
- ヒートマップはモデルが特定領域に集中するよう誘導する
Claude Code との実験設定
- Claude Code が既存研究コードを最新の Python 環境向けにアップグレードし、新しいデータセット読み込みと実験ループのスキャフォールディングを作成した
- 交差検証分割、評価ロジック、
program.md の初期アイデアを設定した
- 評価指標には Mean Rank を使用し、最終報告では Recall@K も併記した
- Mean Rank は直感的な判断用に用いられたが、外れ値の影響を受けにくい Median Rank のほうが適切だった可能性があると述べられている
- モデル構成: CLIP バックボーンは ViT-Small（22M）+ DistilBERT（66M）+ HeatmapProcessor で、合計約 90M パラメータ
- 学習: 800 ステップ（RTX 4090 基準で約 3 分/実験）
- 評価: 1,000 枚のテストセットで Mean Rank および Recall@K を測定
- ベースライン性能: Val Mean Rank 344.68、img→txt R@1 17.2%、txt→img R@1 16.5%
実験結果
- 1 日のあいだに合計 42 回の実験を行い、そのうち 13 回をコミット、29 回をロールバックした
- Mean Rank は 344.68 から 157.43 へ 54% 低下した
- 全データセットで最終学習を行うと、テストスコアが検証スコアより高く現れた
- これは短い 800 ステップ実験がアンダーフィット状態だったことを示唆する
- 最終テスト性能: Mean Rank 34.30、img→txt R@5 53.0%、txt→img R@5 51.4%
主な改善ポイント
-
Temperature clamp の修正（Mean Rank -113）
- コード内の学習可能な temperature パラメータが 2 に固定されていたが、エージェントがこの制約を緩和して性能が大きく向上した
- 全体改善の中で最も大きい単独効果を示した
-
Optuna++（Mean Rank -30）
- その後の改善は主にハイパーパラメータチューニングから生じた
- 射影次元の増加と学習率の再調整により、さらに 30 ポイント改善した
- 人間が繰り返し行う退屈な作業を、エージェントがより速く体系的に実行した
-
収穫逓減の区間
- 第 4 フェーズ（構造変更）以降、LLM の仮説成功率は急激に低下した
- attention メカニズムの変更や**大胆なアイデア（moonshot）**の試みは大半が失敗した
- 探索後半ではランダムな試行が多くなった
-
サンドボックスの重要性
- Claude Code はときどき権限を忘れて不適切な bash 呼び出しを試みたり、学習待機中にループを中断したりするなど、不安定な挙動を見せた
- 完全な自律実行にはなお限界がある
総括的な観察
- 全体プロセスでは最初の 90% はスムーズに進行し、最後の 10% では多くの介入が必要だった
- LLM エージェントは明確に定義された探索空間の中では、ML 研究を効果的に進められる
- Autoresearch のコミット-ロールバックループは、構造化された探索戦略として有用である
- しかし未知の領域へ拡張すると、最適化ループは不安定になる
- 実験ごとに 1 回の変更しか許さない制約は、大規模なアイデア探索には厳しすぎた可能性がある
- 今後は計画フェーズの追加や**サブエージェント（subagent）**の導入が改善案として示されている
- 実験終了後、Claude Code との協業は日常へ戻る形で締めくくられた
謝辞
- Ukiyo-eVG データセット: 約 11K の日本木版画画像とフレーズ-バウンディングボックス注釈を含む
- Autoresearch: Andrej Karpathy の元のアイデアに基づく
1件のコメント
Hacker Newsの意見
メインリンクが遅い場合は、archive.is版を試すとよいとの提案
私はよくLLMを使って既存研究を探ったり、問題を別のやり方で考えたりしている
結果の90%は自分のドメインには合わないが、残りの10%はかなり有用だった
ただ、LLMが勧めたものをすべて実際に試させるエージェントを置くのはコスト（$$$）が高すぎる
推薦リストには、しばしば保守されていないニッチなライブラリが多い
一方で、会社の「専門コンサルタント」も同じように突拍子もない提案をしがちなので、むしろエージェントに代わりに相手してほしい
ただし、1回のテストが速い場合に限って意味がある。私の仕事ではテスト1件に半日かかるので、一晩中回すのは難しい
MCPサーバーやAGENTS.mdのようなものを設定している人たちを見ると、結局LLMが宣伝どおりには動かない証拠のようにも思える
特定のワークフロー向けにうまくチューニングすれば素晴らしいが、それがスケールするかは疑問だ
莫大な資金が学習とインフラを支え続けない限り、持続可能なビジネスモデルになり得るのだろうか？
「エージェントがハイパーパラメータ最適化アルゴリズムのように振る舞った」という表現が印象的だった
核心は
program.mdというシステムプロンプト用ファイル1つで、「train.pyの改善 → 学習実行 → 評価 → 結果記録」を繰り返す構造だ残りは任意のMLモデルにすぎない
動いているコードをLLMに渡し、バグ修正、性能測定、テストカバレッジ評価を繰り返すやり方が、私たちのチームの標準的なアプローチだ
反復ごとに別のモデルを使うと、新しい視点が得られる感じがしてよかった
なぜ「Autoresearch」がここまで話題になったのか疑問だった
AI/MLのボトルネックは常にデータ品質か計算資源だと思っていたので、これがそれを改善するのかよく分からない
Bayesian最適化やGaussian Processのようなアプローチもあったが、結局はランダムサーチのほうが良かった
LLMは文献を見て常識的な推論ができる点が違う
完璧ではないが、従来手法より良い可能性はある
まったく新しい概念ではないが、よりbrute-forceでないことが期待されているようだ
つまり、すでに誰かが行った研究をLLMが活用できる
MLの本質は、同じ入力Xに対してより良い関数マッピングを見つけることだ
単に計算資源を増やせば解決するわけではない
結果的には機能していた。LLMがバグを見つけて最適化も行っていた
こういうことはClaude Codeでもすぐできる
Autoresearchの本当の価値はアーキテクチャ探索にありそうだ
誰か探索的モデリングに使ってみた経験があるのか気になる
コミットログ（GitHubリンク）を見ると、大半がハイパーパラメータ調整だった
その程度ならトークンコスト（$$$）がもったいないと感じる
LoRaアダプターでコストフィードバックを与える形にも改善できそうだ
元論文では医療X線データを使っていたが、アクセス権がなかったためUkiyo-eVG（日本の木版画1.1万点）で代用したとのこと
奇妙な切り替えに見えた。無料の医療画像データは Cancer Imaging Archive にも多い
誰かがこういう実験をしてくれたらと思っていたので、実際にやってくれてうれしかった
「学習が終わるのを待っているうちに疲れて会話を終了した」という部分が面白かった
結果の共有に感謝する
これは自動化された研究というより、構造化された試行錯誤に近い
結局のところ鍵になるのは評価指標の品質だ。それが弱ければ、間違った方向により速く最適化するだけだ