「実験の結果を確認したら、もう朝だった。」
MLの実験ループを手動で回していた頃の話だ。モデルのアーキテクチャを少し変えて、ハイパーパラメータを調整して、学習を走らせて、バリデーションスコアを確認して——この繰り返しに、研究者の時間の大半が費やされる。AIの力でAIを改善するはずが、実際は人間がひたすら「実験係」をやっている状況だった。
2026年3月、Andrej Karpathy（元Tesla AI責任者、OpenAI共同創業者）がこの問題にシンプルな答えを出した。autoresearch——630行のPythonコードで実装された、AI自律実験フレームワークだ。「寝ている間にAIが100回実験する」というコンセプトが、ML研究の常識を揺さぶり始めている。
この記事では、autoresearchの仕組みと実際のセットアップ手順を、コピペ可能なコード・設定つきで全公開する。ML経験がなくても今夜から動かせるよう、順を追って説明していく。
AIエージェントの基本概念や構築パターンについては、AIエージェント構築完全ガイドで体系的にまとめているので、合わせて参照してほしい。
最初に全体の流れをつかむために、実際に動かしてみよう。以下の3ステップで自律実験ループが起動する。
セットアップ1：リポジトリのクローンと依存パッケージのインストール
autoresearchはNVIDIA GPU（H100で検証済み）とPython 3.10+を必要とする。Macユーザー向けのApple Silicon（MLX）ポートも有志によって公開されているが、ここではオリジナル版を使う。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.10+, NVIDIA GPU (H100推奨), uv package manager
git clone https://github.com/karpathy/autoresearch.git
cd autoresearch
# uvがない場合は先にインストール
pip install uv
# 依存パッケージをインストール
uv sync
# データ準備（約2分。BPEトークナイザーの学習、データシャードの作成）
uv run prepare.py
# 動作確認：手動で1回学習を走らせる（5分で終了する）
uv run train.py
ポイント：
prepare.pyは一度だけ実行すれば良い。データシャードとトークナイザーが~/.cache/autoresearch/に保存されるtrain.pyは毎回ちょうど5分で終了するよう設計されている（時間予算が固定）- 初回実行で
results.tsvにベースラインのスコアが記録される
セットアップ2：program.mdで研究戦略を書く
autoresearchの核心は、コードを書く代わりに「研究方針」を自然言語で記述できる点だ。AIエージェントが program.md を読んで、何を試すべきかを自分で判断する。
<!-- program.md の記述例 -->
# Research Direction
## Goal
Reduce val_bpb (validation bits per byte) by optimizing the attention mechanism.
## Constraints
- Do not modify prepare.py or change tokenizer/vocabulary size
- Keep total training time under 5 minutes (wall clock)
- Model parameter count should stay within 2x of baseline
## Suggested Experiments
1. Try different numbers of attention heads (4, 8, 16)
2. Experiment with rotary position embeddings (RoPE)
3. Test grouped query attention (GQA) to reduce KV cache
4. Adjust learning rate schedule (cosine vs linear decay)
5. Modify batch size and gradient accumulation steps
## What NOT to try
- Changing the dataset or tokenizer
- Experiments that require more than 1 GPU
ポイント：
- 「やること」だけでなく「やらないこと」も明記するとエージェントの試行錯誤がより的確になる
- 日本語でも書けるが、英語の方がLLMの理解精度が高い
- 最初は制約を緩めに設定して、エージェントに広く探索させると良い
セットアップ3：AIエージェントに自律実行を委任する
準備が整ったら、Claude Code、Codex、その他のコーディングエージェントをリポジトリに向けて指示するだけだ。
# Claude Codeを使う場合の指示例
# リポジトリのルートディレクトリでClaude Codeを起動し、以下を指示する：
# "program.mdを読んで、autoresearchの自律実験ループを開始してください。
# train.pyを編集 → 学習実行 → 結果評価 → 改善/revert → 繰り返し
# の順で、私が起きるまで実験を続けてください。"
# エージェントが実行するサイクル（autoresearch.jsonlに自動記録される）：
# 1. program.mdで研究方針を確認
# 2. train.pyに変更を加える（アーキテクチャ、オプティマイザ、ハイパーパラメータ等）
# 3. uv run train.py を実行（5分）
# 4. val_bpb（validation bits per byte）を評価
# 5. 改善していれば変更をcommit、悪化していればrevert
# 6. ステップ2に戻り繰り返す
これだけだ。あとはエージェントが寝ている間に動き続ける。
autoresearchの3ファイル構造——「一GPU・一ファイル・一メトリクス」哲学
autoresearchがシンプルかつ強力な理由は、そのミニマルな設計にある。リポジトリに存在するコアファイルは3つだけだ。
| ファイル | 役割 | エージェントが編集するか |
|---|---|---|
| prepare.py | 固定インフラ。データダウンロード、BPEトークナイザーの学習、データローダー、評価ロジック | 絶対に触らない |
| train.py | GPTモデル定義、オプティマイザ（Muon + AdamW）、学習ループ。約630行 | ここだけを編集する |
| program.md | 人間が書く研究方針。エージェントへの指示書 | 人間が編集。エージェントは参照のみ |
「なぜ1ファイルだけ？」という疑問はもっともだ。Karpathyの答えはシンプルで、train.pyの全コードがLLMのコンテキストウィンドウに収まるからだ。エージェントがファイル全体を一度に把握した上で、論理的に一貫した変更を加えられる。複数ファイルに分割すると、エージェントが「見えていない部分」で矛盾した変更を加えるリスクが生まれる。
実験ループの詳細——何が自動で行われるか
エージェントが実行する自律ループを図解すると以下のようになる。
┌─────────────────────────────────────────────────────────┐
│ autoresearch ループ │
│ │
│ program.md を読む │
│ ↓ │
│ train.py を編集（アーキテクチャ/HPs/オプティマイザ） │
│ ↓ │
│ uv run train.py（固定5分） │
│ ↓ │
│ val_bpb を評価 │
│ ↓ │
│ 改善した？ → YES: commit して次の実験へ │
│ → NO: revert して別のアプローチへ │
│ ↓ │
│ autoresearch.jsonl に結果を記録 │
│ ↓ │
│ ← ループ先頭に戻る（停止命令があるまで繰り返す） → │
└─────────────────────────────────────────────────────────┘
速度: 12実験/時間、約100実験/一晩（8時間）
重要な設計上のポイントが2つある。
第一に、学習時間は常に5分固定だ。アーキテクチャを大幅に変えても、ハイパーパラメータを調整しても、計算予算は変わらない。これによってすべての実験が公平な条件で比較される。「大きなモデルが良いスコアを出したのは、単に学習時間が長かったから」という見かけ倒しの結果が出ない。
第二に、失敗コストがほぼゼロだ。エージェントが試みた変更がval_bpbを悪化させれば、自動でrevertされる。コードが壊れてもエラーがコンテキストとして返ってきて、エージェントが自己修正する。研究者が寝ている間に100回試して、99回失敗しても問題ない。1回うまくいけば良い。
なぜval_bpbなのか——評価指標の設計思想
autoresearchが使う評価指標 val_bpb（validation bits per byte）は、パープレキシティよりも汎用性が高い。パープレキシティは語彙サイズに依存するため、異なるトークナイザーを使ったモデル間で比較できない。val_bpbは語彙サイズに依存しないため、アーキテクチャの本質的な良し悪しを公平に測れる。
低いほど良い——これがエージェントに伝える唯一のルールだ。あとはエージェントが自分でどうやって下げるかを考える。
Shopify CEOが8時間で体験した「19%改善」の衝撃
autoresearchが公開直後に注目を集めたのは、Karpathyの解説だけが理由ではない。Shopify CEOのTobi Lütkeが実際に試して、その結果をSNSで公開したからだ。
事例区分: 公開事例
以下はTobi Lütke氏がSNSで公開した実験結果に基づいた情報です（2026年3月）。
Lütke氏は0.8Bパラメータの内部モデルにautoresearchを向けた。MLの専門知識は持っていない。ただ「program.mdを書いてエージェントに渡した」だけだ。
8時間後、エージェントは37回の実験を完了していた。結果はval_bpbが19%改善。それだけではなく、その0.8Bモデルが、従来使っていた1.6Bモデルより高い性能を示した——パラメータ数が半分のモデルが、大きなモデルを超えたのだ。
この結果が示唆するのは、「モデルのサイズより、アーキテクチャの最適化の方が重要かもしれない」ということだ。人間が手動で実験を回していたら、37回の試行に何日かかるだろうか。
autoresearchが変える研究者の役割
正直に言うと、autoresearchはMLの実験を「なくす」ツールではない。研究者の役割を変えるツールだ。
これまでの研究者の時間配分を考えてみよう：
- 実験の設計：20%
- コードの実装・デバッグ：30%
- 実験の実行・監視：30%
- 結果の分析・次の仮説立案：20%
autoresearchを使うと、このバランスが大きく変わる。実装・実行・監視の大半がエージェントに移譲され、研究者は「設計」と「分析→次の仮説」に集中できる。要するに、研究者が「実験係」から「研究ディレクター」に昇格するのだ。
program.mdの書き方で品質が決まる
これが実は最も重要なスキルになる。エージェントに渡す「研究方針」の質が、実験の方向性と最終結果を左右する。
<!-- 上級者向け program.md の構造例 -->
<!-- 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。 -->
# Research Directive v2
## Primary Objective
Minimize val_bpb below 1.45 (current baseline: 1.52).
## Architecture Hypotheses (Priority Order)
### High Priority
- H1: Flash Attention 2 implementation may speed up per-step throughput,
allowing more gradient steps within the 5-minute budget
- H2: Reducing model depth (fewer layers) with wider FFN might
be more parameter-efficient for this data scale
### Medium Priority
- H3: Different positional encodings (ALiBi vs RoPE vs learned)
### Low Priority (only if high/medium exhausted)
- H4: Different normalization (RMSNorm vs LayerNorm)
## Lessons Learned (Update after each session)
- [2026-03-14] Increasing num_heads from 4→8 improved val_bpb by 0.02
- [2026-03-14] Doubling learning rate caused divergence (NaN loss)
## Hard Constraints
1. Do NOT change prepare.py
2. Do NOT modify the evaluation function in train.py
3. All experiments must complete within 5 minutes wall clock
4. If loss becomes NaN, immediately revert and try a smaller LR
「Lessons Learned」セクションを毎セッション後に更新する運用がポイントだ。エージェントが前の実験結果を活かして次の仮説を立てる文脈になる。
Apple Siliconでも動かしたい人へ——MLXポートの活用
オリジナルのautoresearchはNVIDIA GPU前提だが、有志がApple Silicon（MLX）ポートを公開している。PyTorchもCUDAも不要で、Macで動かせる。
# autoresearch-mlx のセットアップ
# 動作環境: macOS Sequoia以降, Apple Silicon (M1/M2/M3/M4), Python 3.10+
git clone https://github.com/trevin-creator/autoresearch-mlx.git
cd autoresearch-mlx
# MLXとその他の依存パッケージをインストール
pip install mlx mlx-lm numpy
# データ準備
python prepare_mlx.py
# 動作確認
python train_mlx.py
ただし注意点がある。Apple SiliconのGPUメモリはNVIDIA H100と比べると大幅に少ない（M4 Maxで最大128GB UMAだが、ML用途では実効的に異なる）。大きなモデルは動かせない。小規模な実験向けの選択肢だと理解した上で使おう。
【要注意】autoresearchでよくある失敗パターン4選
失敗1：program.mdが曖昧すぎて実験が迷走する
❌ 「モデルを改善してください」
⭕ 「val_bpbを1.45以下にするために、attention headの数を{4, 8, 16}で試し、最も良い結果をcommitしてください。LRは1e-3以下に固定すること」
なぜこれが重要か：制約が緩すぎると、エージェントが「モデルサイズを極端に増やす」「5分の制約を無視した変更を加える」などの予期しない行動をとる場合がある。実験の方向性と制約を具体的に書くことで、探索空間が意味のある範囲に絞られる。
失敗2：val_bpbが下がってもそれが本当に良いモデルかを確認しない
❌ val_bpbが下がったから即座に本番モデルとして採用
⭕ 実際のタスクでの性能（例：特定のベンチマーク）を手動で検証してから採用
なぜこれが重要か：val_bpbは言語モデリング能力の代理指標に過ぎない。特定のタスク（例：コード生成、数学的推論）では、val_bpbが改善していてもタスク性能が変わらない、あるいは悪化するケースがある。autoresearchは探索フェーズのツールであり、最終的な評価は人間が担う。
失敗3：一晩で全部解決しようとする
❌ 一度のセッションで100個の変数を同時に探索しようとする
⭕ 「今夜はattention mechanismだけ」「明日はオプティマイザ」と変数を絞る
なぜこれが重要か：変数が多いと、どの変更が効いたのかが分からなくなる。実験の再現性と解釈可能性のために、各セッションでフォーカスする変数を絞ることが重要だ。小さく始めて段階的に拡張する——これはMLに限らずすべての実験設計の鉄則だ。
失敗4：autoresearch.jsonlのログを確認しない
❌ 朝起きて「良くなった！」でそのまま使う
⭕ ログを読んで「どの変更が効いたのか」を理解する
# autoresearch.jsonlのログ解析スクリプト
# 動作環境: Python 3.10+, 標準ライブラリのみ
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
import json
from pathlib import Path
log_path = Path("autoresearch.jsonl")
experiments = []
with open(log_path) as f:
for line in f:
experiments.append(json.loads(line))
# 改善した実験だけ抽出
improvements = [e for e in experiments if e.get("kept", False)]
print(f"総実験数: {len(experiments)}")
print(f"改善した実験: {len(improvements)} ({len(improvements)/len(experiments)*100:.1f}%)")
print()
# val_bpbの推移を表示
print("改善した実験の詳細:")
for exp in improvements:
print(f" 実験 #{exp['id']}: val_bpb {exp['val_bpb_before']:.4f} → {exp['val_bpb_after']:.4f}")
print(f" 変更内容: {exp.get('change_description', 'N/A')}")
print()
このスクリプトを朝イチで実行することで、「どの変更が本当に効いたか」を把握できる。ログを読むことがautoresearchを使いこなす上での最重要スキルだ。
autoresearchの現実的な限界——正直に言っておくこと
正直にお伝えすると、autoresearchはまだ特定のユースケースに最適化されたツールだ。万能ではない。
現在のautoresearchが自動化しないこと：
- 実験の方向性の設定：program.mdは人間が書く。どこを探索するかの判断は研究者の仕事だ
- 結果の深い解釈：「なぜこの変更が効いたのか」の理解は人間が担う
- タスク固有の評価：val_bpb以外のカスタム評価指標への対応は、現状では自分でtrain.pyを修正する必要がある
- マルチGPU・分散学習：現状は単一GPU前提。大規模モデルには対応していない
また、「ML経験がなくても使える」という表現には注意が必要だ。Tobi Lütke氏のケースは、あくまで0.8Bという比較的小さなモデルの最適化だった。最先端の大規模モデルの研究には、依然として深いML知識が必要だ。
autoresearchが本当に輝くのは、すでに動くベースラインモデルがあって、それをさらに最適化したいフェーズだ。ゼロからモデルを設計する作業を置き換えるツールではない。
自律実験ループの広がり——autoresearchから派生したプロジェクト
autoresearchが公開から数日で、コミュニティが動き出した。いくつかの注目すべき派生プロジェクトを紹介する。
| プロジェクト | 特徴 | GitHub |
|---|---|---|
| autoresearch-mlx | Apple Silicon（MLX）ポート。PyTorch不要 | trevin-creator/autoresearch-mlx |
| autokernel | GPUカーネルの最適化版。PyTorchモデルを与えると最適化されたTritonカーネルを生成 | RightNow-AI/autokernel |
| pi-autoresearch | Raspberry Piなど小型デバイス向けの拡張版 | davebcn87/pi-autoresearch |
| autoexp | 定量化可能な任意のメトリクスに汎用化した版（ML以外にも使える） | adhishthite/autoexp gist |
特に autoexp は興味深い。autoresearchの「コード編集→実行→メトリクス評価→keep or revert→繰り返し」というパターンを、ML以外の最適化問題全般に適用しようとするプロジェクトだ。Webアプリのパフォーマンス最適化や、コンパイラの設定チューニングへの応用が議論されている。
AIエージェント開発者が知っておくべきこと——autoresearchが示す設計原則
autoresearchの技術的な詳細を超えて、このプロジェクトはAIエージェント設計の重要な原則を体現している。これはLLMを使ったエージェント開発全般に応用できる考え方だ。
原則1：評価指標をシンプルにする
autoresearchが機能する理由の一つは、最適化すべき指標が val_bpb（低いほど良い） の一つだけだということだ。エージェントは「何を改善すれば良いのか」について迷わない。
複数の指標を同時に最適化しようとすると、エージェントはトレードオフの判断に迷い、一貫した方向性を失う。「一つのメトリクスに集中させる」という設計は、他のエージェントシステムにも応用できる。
原則2：失敗のコストを下げる
autoresearchは失敗した実験を自動でrevertする。これによって「失敗したらどうしよう」というエージェントの（擬似的な）躊躇をなくし、積極的な探索を可能にしている。
AIエージェントをビジネスプロセスに組み込む際も、「失敗した場合の自動ロールバック」を設計に含めることで、エージェントが安心して挑戦的な行動をとれる環境を作れる。
原則3：コンテキストウィンドウに収まるタスクスコープ
train.pyが630行（LLMのコンテキストに収まるサイズ）に制限されているのは意図的だ。エージェントがタスクの全体を一度に把握できることで、局所的な最適化ではなく、システム全体を見た上での変更が可能になる。
エージェントに与えるタスクは「コンテキストウィンドウに収まるスコープに分割する」という原則は、あらゆるエージェント設計で有効だ。
参考・出典
- karpathy/autoresearch — GitHub（参照日: 2026-03-14）
- Andrej Karpathy’s new open source ‘autoresearch’ lets you run hundreds of AI experiments a night — VentureBeat（参照日: 2026-03-14）
- Shopify’s CEO Let Karpathy’s AI Agent Run Overnight and Woke Up to a 19% Better Model — Firethering（参照日: 2026-03-14）
- Karpathy’s autoresearch: 100 Autonomous ML Experiments Overnight — jangwook.net（参照日: 2026-03-14）
- Andrej Karpathy Open-Sources ‘Autoresearch’: A 630-Line Python Tool — MarkTechPost（参照日: 2026-03-14）
- trevin-creator/autoresearch-mlx — GitHub（Apple Silicon版）（参照日: 2026-03-14）
まとめ：今日から始める3つのアクション
- 今夜やること：
git clone https://github.com/karpathy/autoresearch.gitでリポジトリをクローンし、uv run train.pyでベースラインのval_bpbを記録する。「動く状態」を確認するだけで良い - 今週中：program.mdを書いてエージェントに渡し、一晩走らせてみる。朝、autoresearch.jsonlのログを読んで「どの変更が効いたか」を確認する
- 今月中：「Lessons Learned」セクションを毎セッション後に更新する運用を作る。エージェントが前の実験から学ぶ文脈を積み上げることで、実験の質が週を追うごとに上がっていく
あわせて読みたい:
- AIエージェント構築完全ガイド — エージェント設計の基本から応用まで体系的に解説
- AIエージェント構築ツール徹底比較2026 — LangChain、Dify、n8nなど主要ツールの使い分け
AI研修・導入支援について、自社への適用イメージを相談したい方は Uravationのお問い合わせフォームからお気軽にどうぞ。
この記事はAIgent Lab編集部がお届けしました。
