autoresearch とは何ですか？

Andrej Karpathy が公開した、小さな言語モデルの学習リポジトリにAIエージェントを閉じ込めて自動で実験を回させる仕組みです。公開リポジトリは github.com/karpathy/autoresearch で、prepare.py、train.py、program.md の3つのファイルで構成されます。

3つのファイルにはそれぞれ何を書きますか？

公式READMEによれば、prepare.py は固定の定数と一度だけのデータ準備と実行時ユーティリティ、train.py はエージェントが編集する唯一のファイルでモデルと最適化と学習ループを含み、program.md はエージェントへの基本指示です。役割の分離そのものが設計の中心にあります。

1回の実験にどれくらい時間がかかりますか？

公式READMEでは、学習は5分の固定時間予算で走ると明記されています。起動時間とコンパイル時間は除いた実時間です。時間を固定することで、実験どうしを同じ条件で比べられます。

一晩でどれくらいの実験を回せますか？

公式READMEは「およそ1時間に12実験、寝ているあいだにおよそ100実験」と述べています。人間が張り付いていない時間帯にも試行が積み上がることが、この設計の実利です。

エージェントは何を見て「良くなった」と判断しますか？

val_bpb（validation bits per byte）という単一の指標です。公式READMEは値が小さいほど良いと明記しています。判定基準が1つに定まっていることが、自動で回せる条件になっています。

改善しなかった変更はどう扱うべきですか？

公式READMEはループを「コードを変更し、5分学習し、結果が改善したか確認し、残すか捨てるかを決め、これを繰り返す」と説明しています。どこまでを機械的に決め、どこから人間が判断するかの線引きは、かなうテックでは業務ごとに事前に決めておく運用にしています。

エージェントに任せられる仕事とそうでない仕事の違いは何ですか？

かなうテックの見解として、出力が測れること、操作が巻き戻せること、1回の結果が短時間で返ること、影響範囲が閉じていることの4つを目安にしています。1つ欠けるだけで、同じ仕組みはそのままでは動きません。

評価指標が数値化できない業務ではどうすればよいですか？

全体を任せるのではなく、測れる部分だけを切り出します。文章の良し悪しは測れなくても、必須項目が埋まっているかは測れます。測れる部分を自動化し、測れない部分の判断を人に残す分け方が現実的です。

最初から複数のエージェントを組み合わせるべきですか？

Anthropic は公式記事で「単純なプロンプトから始め、包括的な評価で最適化し、単純な解では足りないときにだけ多段のエージェント構成を足す」と述べています。組み合わせを増やすのは、単体で足りないと分かってからで十分です。

中小企業がこの考え方を自社の業務に持ち込むには何から始めればよいですか？

まず、判定が1つの数字か○×で決まる業務を1つ選ぶことです。次に、やり直しが効く形にします。この2つが揃った業務は、ツールを入れ替えても仕組みが壊れにくくなります。

AIエージェントに任せられる仕事の4条件とループ設計【2026年版】

この記事の概要

項目	内容
対象読者	AIエージェントの導入を検討する開発者、および従業員5〜100名の中小企業経営者、DX担当者
対象テーマ	AIエージェントに仕事を任せられる条件と、任せるためのループの組み立て方
想定読了時間	約12〜15分
最終更新	2026年8月2日
出典基準	公開されている一次ソース（公式リポジトリ、公式ドキュメント）のみを事実として記述。かなうテックの見解は文中で明示して区別

本記事は全3回シリーズの第1回です。第2回では複数のエージェントが同時に動くときの記録の残し方を、第3回では知識をグラフとして持つべき場合と持つべきでない場合を扱います。

イントロ：任せられないのは、モデルが足りないからなのか

AIエージェントを業務に入れようとすると、たいてい同じところで止まります。やらせてみると、それらしく動く。ただ、目を離せない。

この状態を「モデルがまだ足りないから」と説明したくなります。しかし、目を離せない理由の多くは、モデルの側ではなく仕事の側にあります。何をもって成功とするかが決まっていない仕事は、誰がやっても成功を判定できません。やり直しが効かない仕事は、失敗した時点で取り返しがつきません。

そこで本記事は、AIに任せられる仕事と任せられない仕事を分ける線を扱います。題材にするのは、Andrej Karpathy が公開した autoresearch というリポジトリです^[1]。小さな言語モデルの学習を、AIエージェントに延々と改良させ続けるための仕組みです。

扱うのは個別のテクニックではありません。記憶（何を残すか）と評価（何をもって良しとするか）をどこに置くか、という一点です。

Part 1: 3つのファイルに分けるという設計

1-1 設定、実験、運用規則を分ける

autoresearch の構成は3つのファイルに分かれています^[1]。公式リポジトリの説明を、そのまま日本語にすると次のようになります。

prepare.py：固定の定数、一度だけ実行するデータ準備（学習データのダウンロードと BPE トークナイザの学習）、実行時のユーティリティ
train.py：エージェントが編集する唯一のファイル。GPT モデル本体、最適化アルゴリズム、学習ループを含む
program.md：エージェントへの基本指示。ここを指してエージェントを走らせる

この3分割は、単なるファイル整理ではありません。エージェントが触れる範囲が、train.py の1ファイルに限定されています。実験の土台となるデータ準備と、進め方を定めた指示は、実験の対象から外れています。

なぜ分けるのか。ここからはかなうテックの解釈ですが、比較の土台を動かさないためだと考えています。土台を含めて何でも書き換えられる状態では、結果が良くなったのか、比べ方が変わっただけなのかを区別できません。何を固定し、何を動かすかを先に決めておくと、変化の原因を1つに絞れます。

1-2 5分という時間を固定する意味

学習は5分の固定時間予算で走ります^[1]。公式リポジトリは、起動時間とコンパイル時間を除いた実時間だと明記しています。

そして実験の回転数について、公式リポジトリはこう述べています^[1]。およそ1時間に12実験、寝ているあいだにおよそ100実験。

ここで効いているのは速さそのものではなく、時間が固定されていることです。実験ごとに所要時間が変わると、良い結果が出たときに、工夫が効いたのか単に長く回しただけなのかが分かりません。時間を予算として固定すると、比較の条件が揃います。

1-3 何をもって良しとするか

判定に使う指標は val_bpb です^[1]。 validation bits per byte の略で、公式リポジトリは値が小さいほど良いと明記しています。

指標が1つに定まっていることが、この仕組みが自動で回る条件になっています。複数の指標が並んでいると、片方が良くなり片方が悪くなったときに、採用するかどうかを人が決めることになります。その瞬間、ループは止まります。

指標を1つにできない場合でも、優先順位を先に決めておけば同じことができます。どちらを優先するかを実行時に相談しなければならない状態だけを避ければよいわけです。

1-4 中小企業の業務に置き換えると

この3分割は、ソフトウェア開発の外でもそのまま使えます。

たとえば見積書の作成を自動化するとします。このとき、単価表や取引条件は動かさない土台に置きます。自動化の対象は、案件情報から見積書を組み立てる部分だけに絞ります。そして進め方の決まりごとは、コードでもツール設定でもなく、読める文書として別に置きます。

土台と対象と決まりごとが混ざっていると、出力が変わったときに原因を追えません。単価表が変わったのか、組み立て方が変わったのか、担当者の判断が変わったのかが分からなくなります。

Part 2: ループの規律

ここから Part 2 で述べる運用の型は、公式リポジトリの仕様ではなく、かなうテックが実務で採っている進め方です。公式に確認できるのはループの1周分だけで、公式リポジトリは次のように説明しています^[1]。コードを変更し、5分学習し、結果が改善したか確認し、残すか捨てるかを決め、これを繰り返す。

2-1 1回に1つしか変えない

1周で変更を1つに絞ります。 2つ同時に変えて結果が良くなった場合、どちらが効いたのか分かりません。悪くなった場合はさらに厄介で、片方が効いていて片方が足を引っ張っている可能性が残ります。

制約に見えますが、回転数が確保されていれば実害は小さくなります。 1つずつ試して1時間に12回試せるなら、2つまとめて試して迷うより速く進みます。

2-2 残すか捨てるかを、その場で決める

1周が終わったら、結果を残すか捨てるかをその場で決めます。判断を後回しにすると、良かったのか悪かったのか分からない変更が積み上がります。そうなった時点で、次の変更が何と比べられているのかが不明になります。

かなうテックでは、捨てる側の操作をあらかじめ用意しておくことを重視しています。残す判断より、捨てる判断のほうが実行しにくいからです。戻し方が決まっていない仕組みでは、人は変更を捨てられません。

2-3 やったことを残す

人が実験するとき、仮説と失敗と気付きは頭の中に留まります。複数のエージェントが交代で作業する場合、頭の中にあたるものが存在しません。

そこで、1周ごとに何を変え、何がどう動き、残したか捨てたかを、機械が読める形で残します。残っていれば、うまくいかなかった方向へ戻ってやり直せます。失敗した試行も、同じ道を二度通らないための材料になります。

2-4 中小企業の業務に置き換えると

この3つは、AIを入れる前の業務改善にもそのまま当てはまります。

やり方を変えるときは、1度に1箇所だけ変える。効果が出たかどうかを、その場で判定して記録する。戻し方を先に用意しておく。

すでに実践している職場もあるはずです。その場合、AIを入れるための下地はできています。逆に、複数の施策を同時に始めて効果測定を後回しにしている職場では、AIを入れても何が効いたのかは分かりません。

Part 3: 任せられる仕事の4条件

ここから示す4条件は、かなうテックが導入判断に使っている目安です。公式に定義されたものではありません。

3-1 出力が測れる

結果の良し悪しが、数字か○×で決まることです。測れなければ、エージェントは自分の出力を評価できません。評価できなければ、改善もできません。

3-2 巻き戻せる

失敗した操作を元に戻せることです。戻せない操作を任せる場合、成功率がどれだけ高くても、1回の失敗が確定的な損失になります。送信済みのメール、実行済みの振込、削除済みのデータは戻りません。

3-3 1回の結果が短時間で返る

変更してから結果が分かるまでが短いことです。 1周に3日かかる仕事では、試行が積み上がりません。 autoresearch が5分という時間予算を置いているのは、この条件を満たすためだと読めます。

3-4 影響範囲が閉じている

作業の影響が、決まった範囲の外へ出ないことです。 1つのフォルダ、1つの帳票、1つのシステムの中で完結する仕事は任せやすくなります。外部の取引先や公開されている場所に影響が及ぶ仕事は、範囲が閉じていません。

3-5 条件が揃わない仕事はどうするか

4条件のうち1つでも欠けると、同じ仕組みはそのままでは動きません。ただし、仕事全体を諦める必要はありません。

現実的なのは、仕事を割って条件を満たす部分だけを取り出すことです。提案書の作成を例にすると、内容の説得力は測れません。しかし、必須項目が埋まっているか、数字が単価表と一致しているか、宛先の表記が揃っているかは測れます。測れる部分を自動化し、測れない部分の判断を人に残す。この分け方であれば、4条件を満たす範囲まで縮小できます。

もう1つの方法は、条件を満たすように仕事の側を作り替えることです。戻せない操作なら、実行前に下書きを作る段階を挟んで戻せるようにする。結果が返るのが遅いなら、途中で判定できる中間指標を置く。仕事の性質は固定ではなく、設計しなおせる部分があります。

3-6 単純な解から始める

条件が揃った業務が見つかると、次に複数のエージェントを組み合わせたくなります。これについて Anthropic は公式記事で次のように述べています^[2]。単純なプロンプトから始め、包括的な評価で最適化し、単純な解では足りないときにだけ多段のエージェント構成を足す。

順序が示されています。まず単純な形で始め、評価の仕組みを整え、それでも足りないと分かってから構成を増やす。最初から複雑な構成を組むと、うまくいかないときに、構成の問題なのか対象の問題なのかを切り分けられません。

まとめ：任せられるかどうかは、仕事の側の性質で決まる

autoresearch から取り出せるのは、特定のテクニックではありません。何を固定し、何を動かし、何をもって良しとするかを先に決めておく、という構造です。

判定を1つに定め、時間を固定し、1周ごとに残すか捨てるかを決める。この形が成り立つ仕事は任せられます。成り立たない仕事は、まず成り立つ形に割り直すところから始まります。

次回は、この仕組みを1体から複数へ広げたときに何が起きるかを扱います。実験の履歴をどう残すか、そして結果の大半が採用されない前提で、どう記録を組むかという話になります。

回	テーマ	示す内容
第1回（本記事）	ループ設計	3つのファイルに分ける構造、1回1変更の規律、任せられる仕事の4条件
第2回	協働と探索グラフ	変更履歴を探索の記録として扱う設計、並列化の上限とコスト
第3回	知識の置き場所	作業の系譜と知識を分ける理由、導入順序、グラフが不要な場合

AIに任せられる業務が自社にあるかどうかの切り分けは、無料相談でも承っています。

参考文献

すべての出典は2026年8月2日時点のものです。

Andrej Karpathy「autoresearch」公式リポジトリ — https://github.com/karpathy/autoresearch
Anthropic「Building Effective AI Agents」（2024年12月19日） — https://www.anthropic.com/engineering/building-effective-agents

注記：本記事のうち、autoresearch の構成（3ファイル）、5分の固定時間予算、val_bpb という指標、実験の回転数、ループの1周の説明は、いずれも公式リポジトリのREADMEに記載された内容です。Part 2 の運用の型（1回1変更、戻し方の事前用意、記録の残し方）と Part 3 の4条件は、かなうテック（屋号：Kanau Tech™）が実務で用いている判断基準であり、公式に定義されたものではありません。両者を混同しないようご注意ください。autoresearch は研究目的の実験的なリポジトリであり、本記事はその業務転用を推奨するものではなく、設計の考え方を業務に持ち込む視点で紹介しています。最新の内容は各公式ページでご確認ください。