サーバーワークスの尾崎です。
SNSで Andrej Karpathy 氏の autoresearch が話題になっていました。AIエージェントにLLMの学習を自律的に改善させるフレームワークです。面白そうだったので「このパターン、LLM学習以外にも使えるのでは？」と思い、手近な題材として社内アプリケーションのバックエンドテスト（pytest）の実行時間短縮を試してみることにしました。
- autoresearch とは
- テスト速度改善に応用してみた
- 実験結果
- autoresearch パターンが効く理由
- ハーネスエンジニアリングとしての autoresearch
- このパターンが使えそうな他のケース
- まとめ
テスト実行時間は約5分。正直、そこまで困っていたわけではありません。ただ、autoresearch のパターンを試してみたかった、というのが正直なきっかけです。
結果、AIエージェント（Claude Code）に試行錯誤させたところ 295秒 → 71秒（76%短縮） を達成。テスト高速化の個々の手法（並列化やfixture最適化）はよくある話ですが、この記事で紹介したいのは autoresearch の「評価→実験→判定」ループをAIに自律的に回させたというアプローチのほうです。
autoresearch とは
autoresearch は、Andrej Karpathy 氏が2026年3月に公開したリポジトリで、「AIエージェントにLLMの学習を自律的に改善させる」ための実験フレームワークです。
構成はたった3ファイルしかありません。
| ファイル | 役割 | 誰が編集するか |
|---|---|---|
prepare.py |
評価ハーネス（データ準備・メトリクス計測） | 誰も触らない |
train.py |
モデル定義・学習ループ | AIエージェント |
program.md |
AIへの指示書 | 人間 |
AIエージェントは以下のループを無限に繰り返します。
train.pyを仮説に基づいて変更するgit commitするtrain.pyを実行する（5分間の学習）prepare.pyの評価関数でval_bpb（検証データのbits per byte）を測定する- 改善したら keep（コミット維持）、悪化したら discard（
git resetで戻す） - 結果を
results.tsvに記録して、1に戻る
ポイントは、評価ハーネスが固定されていることです。AIが測定方法を変えてしまうと改善の比較ができなくなるため、計測する側は完全に固定し、最適化する側だけを自由に変えさせます。1回の実験が5分で完了するため、一晩で約100回の実験を回せます。
このフレームワークの役割分担は明快です。
- 人間の仕事:
program.md（指示書）を磨くこと - AIの仕事:
train.py（モデル）を磨くこと - 誰もやらないこと:
prepare.py（評価）を変えること
autoresearch の元々の用途は LLM のモデル最適化ですが、この「固定された評価関数＋自由なワークスペース＋keep/discardループ」というパターンは、もっと汎用的に使えるのではないかと思いました。
テスト速度改善に応用してみた
やったこと: autoresearch のリポジトリを見せて「これ使えない？」と聞いただけ
大げさではなく、本当にこれだけです。
Claude Code に autoresearch のリポジトリを見せて、「同じような機構を利用することで、自動テストの実行時間を短縮することをAIに試行錯誤させられるんじゃないか」と伝えました。すると AI が autoresearch の prepare.py、train.py、program.md を自分で読み込み、テスト速度改善への対応関係を整理してきました。
| autoresearch | テスト速度改善 |
|---|---|
val_bpb（最小化対象） |
テスト実行時間（最小化対象） |
| 全テストパス = 制約条件 | 全テストパス = 制約条件 |
train.py（変更対象） |
テスト設定・fixture・pytest構成 |
prepare.py（固定ハーネス） |
evaluate.sh（テスト実行＋時間計測） |
AIが自律的に行ったこと
ここから先は、ほぼAIが自分で進めました。
- 評価ハーネスの設計: autoresearch の
prepare.pyにあたるevaluate.shを作成。テスト実行時間・テスト数・合否を構造化フォーマットで出力する計測スクリプト - 現状分析: テストのプロファイリング（
--durations=30）を自分で実行し、「どのテストが遅いか」「ボトルネックはどこか」を特定 - 実験ループの実行: 仮説→コード変更→commit→計測→keep/discard を繰り返し
- 結果の記録: 全実験を
results.tsvに記録し、試行履歴を蓄積
人間（私）がやったのは、最初に autoresearch のリポジトリを見せたことと、「worktree を切って試して」と言ったこと、結果を眺めて「ワーカー数もう少し増やしたらどうなる？」と口を出した程度です。何を試すか、どうコードを変えるか、結果をどう判断するかはすべてAIが自分で決めています。
autoresearch パターンだから回せた自律的なフィードバックループ
ここが今回の工夫ポイントです。
普通に「テストを速くして」とAIに頼んでも、1回きりの改善提案が返ってくるだけです。しかし autoresearch パターンを適用すると、AIが 「変更→計測→判定」のフィードバックループを自分で回し続ける ようになります。
例えば実験3がわかりやすいです。
テンプレートDB方式 — AIはプロファイル結果から「テナントDB作成が遅い」と分析し、PostgreSQL の CREATE DATABASE ... TEMPLATE ... で高速化する仮説を立てました。理屈としては正しいアプローチです。しかし計測すると、直前の実験で導入した並列化により DB作成のオーバーヘッドが他のテストと並行処理されるため、効果が相殺されていました。AIは数値を見て discard を判断し、次の仮説に進みました。
これは「1回の提案」では起きないことです。実験2の並列化が実験3の前提を変えてしまうという 実験間の相互作用 は、実際に計測しないとわかりません。autoresearch パターンがあるからこそ、AIが「試す→測る→駄目なら捨てる→次を試す」を安全に繰り返せるのです。
実験結果
全7回の実験で、以下の改善を積み重ねました。
| # | 変更内容 | 実行時間 | 判定 |
|---|---|---|---|
| 0 | ベースライン | 295秒 | — |
| 1 | bcrypt rounds削減 + performanceテスト除外 | 166秒 | keep |
| 2 | pytest-xdist で並列実行 | 121秒 | keep |
| 3 | テンプレートDB方式 | 123秒 | discard |
| 4 | moto（AWSモック）のsessionスコープ化 + TRUNCATE統合 | 93秒 | keep |
| 5 | --dist loadfile 分散戦略 |
78秒 | keep |
| 6 | ワーカー数チューニング | 71秒 | keep |
最終的に 295秒 → 71秒（76%短縮、4.2倍） 。
個々の手法（xdist による並列化、fixture スコープの調整、ワーカー数チューニングなど）は、テスト高速化としてはよくあるものです。ポイントは、これらを AIが自分でプロファイリングして発見し、仮説を立て、計測して取捨選択した という点です。しかも discard のケースも含めて、すべて自律的に判断しています。
autoresearch パターンが効く理由
「1回の提案」と「フィードバックループ」の違い
AIに「テストを速くして」と頼むとき、1回の提案で終わるか、フィードバックループで回すかで結果がまるで違います。
- 1回の提案: AIが改善案をリストアップし、人間がレビューして適用する
- フィードバックループ: AIが変更→計測→判定を繰り返し、実測に基づいて改善を積み重ねる
1回の提案だと「理屈上は正しいが、他の変更との組み合わせで効かない」ケースに対応できない。autoresearch パターンでは、直前の変更が次の実験の前提を変えるという相互作用も含めて、AIが自分で適応していきます。
評価ハーネスの固定が鍵
このパターンが成立する条件は、メトリクスが明確で自動計測できることです。テスト実行時間はまさにそれで、evaluate.sh を1回書けば、あとは何度でも同じ基準で計測できます。「速くなった気がする」ではなく、数値で keep/discard を判定できるからこそ、AIが自律的にループを回せます。
失敗のコストがゼロ
git commit → 計測 → git reset のサイクルが確立されているので、どんな実験も安全に試して捨てられます。人間が「これ試してみようかな、でも壊れたら面倒だな」と躊躇するところを、AIは results.tsv に discard と記録して次に進むだけです。
ハーネスエンジニアリングとしての autoresearch
2026年に入り、「ハーネスエンジニアリング」という考え方が注目されています。AIエージェントの性能は、モデルそのものよりも モデルを包む「ハーネス」（制約・フィードバックループ・評価・ガードレールの総体）の設計で決まる という考え方です。
LangChainの実験では、モデルを変えずにハーネスだけを変更したところベンチマークスコアが大幅に向上したという報告もあり、「モデルがCPUなら、ハーネスはOS」という比喩が定着しつつあります。
今回の取り組みを振り返ると、autoresearch パターンはまさにハーネスエンジニアリングの実践例でした。
| ハーネスの役割 | autoresearch での実装 |
|---|---|
| 行動を制約する | 変更可能なファイルを限定（テスト設定のみ。プロダクションコードは変更禁止） |
| 情報を提供する | program.md で目標・制約・ヒントを明示 |
| 出力を検証する | evaluate.sh で全テストパス＋実行時間を自動計測 |
| 誤りを修正する | keep/discard ループで改善しない変更を自動的に巻き戻し |
ハーネスエンジニアリングの文脈では、CLAUDE.md やリンター設定など「AIが正しく動くための環境整備」が議論されることが多いのですが、autoresearch パターンが面白いのは、ハーネスの設計が極めてシンプルなことです。固定された評価関数（evaluate.sh）と指示書（program.md）の2ファイルだけで、AIが自律的にフィードバックループを回せるハーネスが成立しています。
しかも、このハーネスは軽量で汎用的です。評価関数を差し替えるだけで、テスト速度以外の最適化タスク（ビルド時間、バンドルサイズなど）にもそのまま転用できます。「ハーネスは軽量に、壊して作り直せる前提で設計する」というハーネスエンジニアリングの原則にも合致しています。
このパターンが使えそうな他のケース
autoresearch パターンの本質は「固定された評価関数＋自由なワークスペース＋keep/discardループ」です。メトリクスが明確で、変更→計測→判定のサイクルが短い場面なら応用できます。
- ビルド時間の短縮 — ビルド完了＋成果物の同一性を評価関数に
- バンドルサイズの削減 — バンドルサイズを評価関数に
- SQLクエリの最適化 — 実行時間＋結果の正確性を評価関数に
- Docker イメージサイズの削減 — イメージサイズ＋動作確認を評価関数に
いずれも「AIに1回提案させる」のではなく、「AIにフィードバックループを回させる」ことで、実測に基づく改善の積み重ねが可能になります。
まとめ
今回やったことを振り返ると、私がやったのは「autoresearch のリポジトリを見せて、テスト改善に使えないか聞いた」だけです。AIが自分でリポジトリを読み、パターンを理解し、テスト基盤の現状を分析し、実験ループを設計・実行してくれました。
個々のテスト高速化テクニックは目新しいものではありません。面白いのは、autoresearch のパターンを適用することで AIが「変更→計測→判定」のフィードバックループを自律的に回し、実測に基づいて改善を積み重ねた という点です。「AIにコードを書かせる」から一歩進んで、「AIに仮説検証ループを回させる」。計測可能な評価関数さえ定義できれば、あとはAIが勝手に山を登ってくれます。
今回は「実験間の相互作用で仮説が覆される」という、1回きりの提案では見えない現象に出会えたのが一番の収穫でした。引き続きAIを活用した開発に取り組みつつ、こうした試行錯誤の過程も共有していきます。
