autoresearch：KarpathyのAIエージェントが一晩でLLMを自律改善する最小構成フレームワーク入門

この記事ではAIエージェントに特化して解説します。AIエージェント全般は AIエージェントフレームワーク比較2026年版 をご覧ください。

autoresearchとは：630行で実装された自律AI研究エージェント

2026年3月、Andrej Karpathyが「autoresearch」を公開しました。GitHubで73,000以上のスター（2026年4月時点）を集めた、シングルGPUのLLM自律改善フレームワークです。

Karpathy自身がREADMEに添えた文章が、このプロジェクトの性格を的確に表しています。

「かつてフロンティアのAI研究は、食事・睡眠・その他の楽しみの合間にやっている”肉コンピュータ”によって行われ、”グループミーティング”という音波インターコネクトで同期されていた。その時代は終わった」

実際のコードはそれより地に足のついた内容です。コアはわずか約630行。人間が program.md に研究方針を書くと、AIエージェントが train.py を自律的に編集し、5分間学習→val_bpb計測→採否判定→次の実験のループを延々と繰り返します。

Karpathy自身がH100で2日間走らせたところ、約700件のコード編集が発生し、そのうち約20件の変更が生き残りました。起動前のval_bpb 0.9979が、89実験で0.9773、126実験で0.9697まで改善されたことがREADMEのログで公開されています。1時間で約12実験、一晩で約100実験が可能です。

AIエージェントフレームワーク比較2026では汎用エージェントフレームワークが多く紹介されていますが、autoresearchはML研究という特定のドメインに絞ったエージェント活用の好例です。

技術的な仕組みの詳細

3ファイル設計の哲学

autoresearchはわずか3ファイルで完結するよう設計されています。

この設計の意図は明確です。「変更スコープを小さく保ち、差分をレビュー可能にする」ことです。エージェントが触れるのは train.py だけで、変更は常にGitで追跡できます。

val_bpb（1バイトあたりの検証ビット数）という指標

autoresearchが採用する評価指標 val_bpb（validation bits per byte）は、語彙サイズに依存しない指標です。これにより、トークナイザーやアーキテクチャを大きく変更した場合でも、異なる実験結果を公正に比較できます。

• 値が低いほど良い（情報をより効率的に表現できている）
• 語彙サイズが異なるモデルでも比較可能
• 5分という固定時間内での改善幅が評価の主眼

固定タイムバジェットの設計

5分という固定タイムバジェットには2つの利点があります。

1. 公正な比較：バッチサイズ・シーケンス長・モデルサイズがどう変わっても、すべての実験が同じ時間条件で評価される
2. プラットフォーム最適化：autoresearchは「そのハードウェアで5分に最適なモデル」を探索する。H100で見つかった設定がA100では最適でないことも多いが、それで正しい動作

nanochat：学習基盤の実装

train.py に組み込まれているのは、Karpathy製のシングルGPU GPT実装「nanochat」を簡略化したものです。デフォルト設定では以下のアーキテクチャ要素がエージェントの改変対象になります。

• DEPTH：モデルの深さ（デフォルト8。多くの変数がこれの関数として決まる）
• WINDOW_PATTERN：アテンションパターン（例：”SSSL” = 3層バンドアテンション + 1層全アテンション）
• TOTAL_BATCH_SIZE：バッチサイズ（2のべき乗推奨）
• MAX_SEQ_LEN：最大シーケンス長（prepare.py 側）
• オプティマイザー：Muon + AdamWの組み合わせと各パラメータ

インストールとセットアップ

必要要件

• NVIDIA GPU 1枚（開発・テストはH100で実施）
• Python 3.10以上
• uv（astral.sh製の高速Pythonパッケージマネージャー）

クイックスタート

# 1. uvをインストール（未導入の場合）
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2. リポジトリをクローン
git clone https://github.com/karpathy/autoresearch.git
cd autoresearch

# 3. 依存ライブラリをインストール
uv sync

# 4. データ準備とBPEトークナイザー学習（初回のみ、約2分）
uv run prepare.py

# 5. 動作確認として1回だけ手動学習（約5分）
uv run train.py

train.py が正常に完了し、val_bpbが出力されれば環境は正常です。

エージェントの起動

動作確認後、Claude CodeやCodexのエージェントをリポジトリに向けて起動します。README推奨のプロンプト：

Hi have a look at program.md and let's kick off a new experiment! let's do the setup first.

重要な設定：エージェントの全アクセス許可を無効化せず起動します。autoresearchはエージェントが train.py を自由に書き換えることが前提の設計です。

program.mdの初期設定例

リポジトリに含まれるデフォルトの program.md は意図的にシンプルに保たれています。研究の方向性を指定する例：

# Research Program

## Current Objective
Minimize val_bpb on the current dataset within a 5-minute training budget.

## Architecture Constraints
- Single GPU (H100)
- Must maintain trainability (val_bpb should not diverge)

## Exploration Directions
1. Experiment with attention window patterns beyond the default SSSL
2. Try modified Muon optimizer parameters
3. Explore different DEPTH values (currently 8)

## History
- Baseline: val_bpb = 0.9979 (stock train.py)

実践的な活用パターン

パターン1：週末の自律実験

研究者がprogram.mdに「今週の探索方針」を書いてエージェントを起動し、週末の間実験を走らせます。月曜朝にval_bpbのログとGitの変更履歴を確認して、生き残った変更をレビューします。

Karpathyの実績では2日間で約700件の変更から約20件が生き残り、val_bpbを0.9979から0.9697まで改善しました。

パターン2：探索対象の段階的な拡大

初期は保守的な探索（オプティマイザーのハイパーパラメータのみ）から始め、安定性を確認してからアーキテクチャの変更（DEPTH・WINDOW_PATTERN）へと探索範囲を広げます。

パターン3：コードリーディング教材として

train.py はGPTモデル・Muonオプティマイザー・学習ループが1ファイルにまとまった約630行のコードです。深層学習の実装を学ぶ際の教材として価値があります。

# train.py内のMuonオプティマイザー設定例（公式コードより抜粋）
# DEPTH・WINDOW_PATTERN・TOTAL_BATCH_SIZE等がエージェントの改変対象
DEPTH = 8          # モデルの深さ（多くのパラメータがこの値の関数）
WINDOW_PATTERN = 'SSSL'  # アテンションパターン（S=スライディング, L=全体）
TOTAL_BATCH_SIZE = 2**18  # 約26万トークン/バッチ

小規模環境での実行（MacBook・RTX等）

autoresearchはH100向けに最適化されていますが、コミュニティフォークが各プラットフォーム向けに対応を進めています。

Karpathyが推奨する小規模プラットフォーム向けの調整パラメータ：

# prepare.py の調整（小規模環境向け）
MAX_SEQ_LEN = 256      # デフォルトより大幅に削減（元は約2048）
EVAL_TOKENS = 65536    # 検証データも削減

# train.py の調整
DEPTH = 4              # デフォルト8 → 4
VOCAB_SIZE = 2048      # デフォルト8192 → 2048
TOTAL_BATCH_SIZE = 2**14  # 約16Kトークン
WINDOW_PATTERN = 'L'   # バンドアテンションを使わずフルアテンションに統一

競合ツールとの比較

autoresearchは「ハイパーパラメータ探索ツール」ではなく「自律コード編集エージェント」です。この違いが競合ツールとの根本的な差分です。

W&B SweepsやRay Tuneは「人間が設計した探索空間を効率的に走る」ツールです。探索空間の定義（どのハイパーパラメータを、どの範囲で変化させるか）は人間が行います。autoresearchはこの探索空間の定義すらエージェントに委ねる点が根本的に異なります。

Neural Architecture Search（NAS）と比較すると、NASはアーキテクチャの探索を自動化しますが、探索の方法論（微分可能NAS、強化学習ベース等）は人間が設計します。autoresearchは「Claude/Codexに train.py を読ませて自由に書き換えてもらう」という極めてシンプルなアプローチです。

よくある質問・つまずきポイント

Windowsでの実行

WindowsではWSL2経由での実行が推奨されます。ネイティブWindowsでの直接実行はコミュニティフォーク jsegov/autoresearch-win-rtx を参照してください。

autoresearchのコードアーキテクチャ詳細

train.py のアーキテクチャ要素をより詳しく理解するために、READMEが参照している nanochat リポジトリも確認することをおすすめします。

# autoresearchのpyproject.toml（依存関係の例）
# uvを使って管理される
[project]
name = "autoresearch"
requires-python = ">=3.10"
dependencies = [
    "torch>=2.0",
    "numpy",
    # ... その他の依存パッケージはpyproject.tomlを参照
]

エージェントが探索するコード変更の典型例：

• アテンションレイヤーのヘッド数の変更
• Muonオプティマイザーのモーメントパラメータ調整
• バッチサイズとシーケンス長のトレードオフ最適化
• ウォームアップスケジューラーの変更
• WINDOW_PATTERN（’SSSL’→’SSLL’など）の実験

autoresearchの実験ログ：具体的な改善の記録

Karpathy自身がREADMEで公開している実験ログから、autoresearchが実際にどのような変更を加えて改善を達成したかを理解できます。

val_bpbの改善推移

実験ログの概要（Karpathy本人のH100実行結果より）
初期値: val_bpb = 0.9979（stock train.py）

実験 1〜89:  val_bpb = 0.9773 まで改善
実験 90〜126: val_bpb = 0.9697 まで改善

総変更試行数: 約700件
生き残った変更: 約20件（採択率 約2.9%）
実行時間: H100で2日間

約97%の変更は採択されずに破棄されます。これはエージェントが積極的に実験し、失敗から学ぶプロセスです。

典型的な「生き残る変更」の例

実際に改善に繋がりやすい変更のカテゴリは、Karpathyの実験や他のコミュニティフォークのフィードバックから以下のパターンが報告されています。

# エージェントが試みる変更の例（概念）
# 変更1: アテンションパターンの調整
# BEFORE
WINDOW_PATTERN = 'SSSL'  # デフォルト

# AFTER（エージェントが試みる例）
WINDOW_PATTERN = 'SSLL'  # より多くのフルアテンション層

# 変更2: バッチサイズの最適化
# BEFORE
TOTAL_BATCH_SIZE = 2**18  # デフォルト

# AFTER
TOTAL_BATCH_SIZE = 2**19  # H100のメモリを最大活用

# 変更3: オプティマイザーのモーメント調整
# エージェントがMuonのβパラメータを微調整するケース

Gitを使った実験管理

autoresearchではすべての変更をGitで追跡することが推奨されています。これにより、実験の採否判定後に変更の差分をレビューできます。

推奨ワークフロー

# 実験開始前にブランチを作成（オプション）
git checkout -b experiment-$(date +%Y%m%d)

# 実験中、エージェントが自動的にtrain.pyを変更
# → git diffでいつでも変更を確認可能
git diff train.py

# 一晩の実験後、変更をレビュー
git log --oneline  # エージェントがコミットした場合
git diff HEAD~5 -- train.py  # 直近5変更の差分

# 良い実験だった場合、mainブランチにマージ
git checkout main
git merge experiment-20260418

# 悪い実験だった場合、ブランチを破棄
git checkout main
git branch -D experiment-20260418

PRとして公開するワークフロー

Karpathyはautoresearchの実験ログをGitHub PRとして公開するワークフローを推奨しています。これにより：

• 実験の過程と結果が他の研究者と共有できる
• コードの変更履歴が透明に保たれる
• コミュニティからのフィードバックが得られる

autoresearchとAIエージェントの未来

autoresearchが73,000以上のスターを集めた理由は、技術的な実用性だけでなく、「AIエージェントが研究を自律的に行う」というビジョンの具体的な実証にあります。

影響を受けたプロジェクト

autoresearchのコンセプトは複数の派生プロジェクトを生み出しています。

「自律AI研究」の限界と課題

autoresearchは研究の自動化における重要な第一歩ですが、現時点での限界も認識することが重要です。

現時点の限界：

• データセットの選択・前処理は人間が行う（エージェントは train.py だけを変更）
• 根本的に新しいアーキテクチャの提案（Transformerから別パラダイムへ）は現状難しい
• H100以外のハードウェアへの完全な対応はコミュニティフォークに依存
• 実験が大量に走るため、GPU電力・コスト管理の考慮が必要

将来への示唆：

• program.md の改善そのものをAIエージェントが行う「メタ研究」への発展可能性
• 複数エージェントの並列実験（マルチGPUクラスター対応）
• 検証データセットの自動選択・難易度調整

まとめ

autoresearchは「AIエージェントにコードを書き換えさせてLLMを自律改善する」という実験的なアプローチを、わずか3ファイル・約630行で実装したプロジェクトです。Karpathy自身の2日間の実験でval_bpbを0.9979から0.9697まで改善した実績があります。

このプロジェクトの本質的な価値は以下の3点にあります。

第一に、AIエージェントが「コードを書く」だけでなく「実験設計・実行・採否判定」まで自律的に行うシステムの最小実装例として、エージェント設計のリファレンスになること。

第二に、program.mdという「人間とエージェントのインターフェース」を通じて、研究者はコードではなく研究方針を書くという新しいワークスタイルを示していること。

第三に、train.py・prepare.py がGPTモデル・Muonオプティマイザー・学習ループの完全な実装を含む教育的なリファレンスとしても価値があること。

73,000を超えるスターが示すように、ML研究の自動化というコンセプトは大きな関心を集めています。H100でなくても小規模なGPUでの実験は各種フォークで対応が進んでいるため、自律AI研究エージェントの実装例として、幅広い開発者・研究者が手を動かして試せる入門点になっています。

参照ソース

• karpathy/autoresearch - GitHub
• Andrej Karpathy のX（Twitter）投稿
• nanochat - karpathy/nanochat
• uv - Astral.sh Python パッケージマネージャー