カーパシーのオートリサーチ:エージェント型コーディングスキルの向上

Dev.to / 2026/3/25

💬 オピニオンIdeas & Deep AnalysisTools & Practical UsageModels & Research

要点

  • アンドレイ・カーパシーが公開した「autoresearch」ワークフローは、実験結果を使って学習(や改善)のループを自律的に回し、時間をかけてモデル(の振る舞い)を改善していく仕組みだと説明されている。
  • 著者は、Claude Codeのようなエージェント型コーディング環境を「複数スキル・メモリ・サブエージェント・フック等のエージェント的ハーネス」と捉え、従来の経験則ベースの評価から脱して、決定的な実験で改良する枠組みを提案している。
  • 改善ループを設計するために、タスクを「要請→探索→計画→実行→レビュー」に分け、ユーザー入力が必要な対話的部分は除外することで、実験を単純化している。
  • 自己改善の核は、世代(新バージョン)を結果で評価する実験であり、比較可能にするために出力と計測を安定・決定的にする必要があると述べている。
  • 評価指標として、トークン使用量(コスト最適化にも有用)、実行時間、ツール呼び出し回数(不要なオーバーヘッドや権限の抑制)などを設定し、品質だけでなく自律性・並列性・効率も同時に高めることを目指している。

はじめに

最近、Andrej Karpathy が、自身のオートリサーチ(autoresearch)ワークフローを公開しました: https://github.com/karpathy/autoresearch。目的は、実験結果に基づいてモデルの学習プロセスを自律的に改善することです。Claude Code を使ってこのループを何時間も、あるいは何日も回すと、より良いモデルにたどり着けます。全体の流れは、program.md ファイル内で「スキル」として説明されています: https://github.com/karpathy/autoresearch/blob/master/program.md

私は仕事でも趣味でも LLM をトレーニングしていませんが、今は主に Claude Code で多くのコーディングをしています。高品質なコードを、一貫して慣習や標準に沿って生成するために、複数のスキル、メモリファイル、サブエージェント、フックなどを使っています。これを「エージェント型のハーネス」と呼ぶことにします。

ただし私は、このハーネスをかなり雑に評価しています。実験や指標(メトリクス)に基づくのではなく、たとえば科学的ではない、ということです。一般的なやり方はこうです:役に立ちそうなベストプラクティスをテストする → うまくいったらワークフローに取り込む。あるいは、人間のレビューで問題が見つかったら → ワークフローを修正する。

しかし、Karpathy のオートリサーチからアイデアを借りて、それを決定論的な実験に基づいて私のエージェント型コーディングハーネスを改善するために適用できるのではないかと考えています。

コーディングスキルの自動改善ループを設計してみましょう。

解決策

日々のコーディングで共通するワークフローを実装するスキルがあると仮定します:

依頼(リクエスト/タスク)を受ける → 調査(探索)→ 計画 → 実行 → レビュー。

簡単のため、ユーザー入力を必要とするような対話ステップは除外します。これらの最適化には、より複雑な実験フレームワークが必要になります。

オートリサーチループの中核は、ある新しいバージョン(生成)を、その結果によって評価する実験です。そのために、決定論的な実験と安定した指標が必要になります。つまり、出力と測定値が、実行や世代をまたいで比較可能である必要があります。

このスキルの目的は何か?

コーディングエージェントが生成するコードが、予測可能で、標準に従い、人間のレビューに合格するようにするための、適切な手順と適切なコンテキストを特定することです。

しかしコード品質だけが課題ではありません。加えて次も目標にします:

  • 高い自律性(人間へのエスカレーションを最小限にする)
  • 多数のタスクを並列に実行できること
  • トークン使用量の最小化
  • 低い実行時間

評価フレームワーク

スキルのためにテストケースの集合を定義します:

依頼(リクエスト)/タスク → 参照コード

指標(メトリクス):

  • トークン使用量(エンドツーエンドおよび各ステップごと)、あるいは実際のお金でのコストでも可。これは、ステップごとのモデル選択の最適化にも役立ちます
  • 実行時間(エンドツーエンドおよび各ステップごと)
  • ツール呼び出し回数(不要な権限付与やオーバーヘッドを減らすため)
  • エラー回数、自動修正(自己修正)回数、または完全中断回数(ユーザー入力なしでは進められない場合)
  • 問題・自己修正・修正のログ

オリジナルのオートリサーチでは、単一の指標(val_bpb)がバージョンの前進可否を決めます。
コーディングスキルでは、複数の主要指標が必要です:

  • テストケースが通った数
  • 時間
  • トークン使用量
  • その他の指標は、将来の改善のためのシグナルとして働きます。

簡単のため、設計段階では二値スコアを使います:

  • 0 → 出力コードが参照と一致しない
  • 1 → 出力コードが参照と一致する 各テストケースは、通ったら 1 ポイント。

さらに:

  • 以前のバージョンより実行時間が改善したら +1
  • 以前のバージョンよりコストが改善したら +1 最終スコア = 全ポイントの合計

意思決定ルール:

  • 現在のスコア > 前回のスコア → 前進
  • それ以外 → 採用せず破棄して元に戻す テストケースが複数あるため、正確性がスコアを支配します。これは望ましい性質です。時間やコストが意思決定要因になるのは、まず品質を最大化した後です。

自動改善ループ

このループはオリジナルのオートリサーチと非常によく似ています。各イテレーションはステートレスです:

  1. 現在の SKILL.md を取り、分析し、特定の実験アイデアに基づいて変更を適用します。境界(バウンダリ)が重要です:変更の範囲を制限します。目指すのは大規模な書き換えではなく、反復的な改善です。その一方で、評価にはノイズがあるため、変更が小さすぎてはいけません。
  2. すべてのテストケースを実行します。テストケースごとに、非決定性をならすため、複数回実行します。
  3. 結果を評価します。測定値を集計し、総合スコアを計算します。
  4. 前回のベストバージョンと比較します。より良ければ → 新しいベースラインとしてコミットします。悪ければ → 破棄します。
  5. 新しい実験アイデアで繰り返します。

自動改善ループの図:

Autoimprove loop diagram

結論

私は、Andrej Karpathy のオートリサーチのアプローチ(もともとは LLM の学習ループを改善するために作られた)に基づいて、コーディングスキル向けの自動改善ループを設計しました。

大まかに言えば、エージェント型コーディングに同じアイデアを適用することを妨げるものは何もありません。理論上は、あるエージェントが特定のユースケースやコードベースに基づいて、人間の監督なしで自分自身のコーディングスキルを「学習」することも可能です。

とはいえ、まだ多くの課題があります:

  • エッジケースをカバーできる高品質なテストケースを定義すること
  • スキル修正のための適切な境界を設定すること
  • エージェントに設計空間(サブエージェント、メモリ戦略、ツールなど)を十分に探索させること
  • エージェントが新しいツール(CLIs、MCP)を取り込むべきタイミング、あるいはゼロから作るべきタイミングを判断すること

これらの課題は、おそらく実装や初期の実行段階で表面化するでしょう。初期結果と動作するバージョンが用意できたら、さらに共有します。