Autoresearchは「長く回す機械」ではない

0. 入る前に

M5 で「eval があって agent が方向感覚を持つ」という話を長めにしました。信号がないと loop はただ車輪が速く回るだけで、信号があって初めて次の試行が前の試行を越えていく、という内容でしたね。

今回はそこから一歩だけ先に進みます。「Autoresearch」という用語が最近の AI ニュースによく出てきます。論文のタイトルにも埋め込まれ、スタートアップのピッチデックにも入り、Twitter でも「AI はもう自分で研究までする」みたいな一文が流れています。この単語を初めて聞くとなかなか怖く響きますよね。「AI がひとりで研究する機械」なんて、自分の仕事はどうなるのかとも思う。

でもこの記事の目的は、その怖い感覚をほどくことです。Autoresearch を分解して覗いてみると、それは ひとりで研究する魔法の箱 ではなく、「実験をずっと回す構造」 に近いんです。長く回す機械ではなく 実験が反復される機械。この違いが核心です。これを見落とすと、プロダクトを比較するときも論文を読むときも、的外れな場所に期待を置いてしまいます。

今回は M1〜M5 を読み終えた方を前提に書きます。retrieval、agent、tool use、evaluation の感覚がすでにある読者を想定します。その感覚の上に autoresearch という1マスを積み上げる回です。次の M7 で「Meta-Harness」というさらに外側の概念に移る橋渡しの役割もこの記事が担います。

---

1. 「AIが勝手に研究する」という言葉が危ない理由

まずこの言い回しの問題点から。ヘッドラインによく登場するのが「AIが自分で実験して論文まで書く」です。タイトルだけ見ると絵がこう描かれます。ボタンを押すと AI が夜通しひとりで何かを回し、朝になってみると新しい発見が紙1枚になって出てくる。まるで SF 小説のワンシーンです。

この絵がなぜ危ないかと言うと、実際の autoresearch システムを使うときに 判断をどこに置くべきか を曖昧にするからです。

比喩に替えます。料理の実験室を想像してみてください。新しいレシピを作るとしたら、流れはこう。「この組み合わせが良さそう」という仮説を立て、実際にその組み合わせで作ってみて、味見して、どこが足りないかメモして、次は塩を減らしてまた作る。これを20回ほど繰り返すと使えるレシピが出来上がります。

この料理人はひとりでやったように見えて、よく見ると手に持っているものが複数あります。味を判断する基準(塩辛いか薄いかを見抜く舌)、予算(材料費)、時間(一度煮るのに40分)、止める判断(20回やってもダメなら方向を変えるべき)。これをぜんぶ人間が握っていた。料理人がひとりで動いたのではなくて、複数の制約の中で働いていた んです。

Autoresearch も同じです。「AI がひとりでやる」という言葉はこの文脈をぜんぶ飛ばしてしまいます。実際には、仮説をどう立てるか、どんな実験を許可するか、いつ止めるか、結果をどう解釈するか、ぜんぶ人間が設計した枠の中で回ります。枠がよく出来ていればシステムは良い結果を吐きますし、雑なら高いコストで何も得られません。

この記事が終わるまで繰り返す一文があります。「Autoresearch は AI がひとりで研究する機械ではなく、実験が反復される構造そのものだ。」 この一文を手に持って次のセクションへ進んでください。

---

2. One-shot agent と Persistent loop agent

このふたつをまず明確に分けておきます。M3、M4 で「agent は tool を使える LLM だ」という話をしましたが、その agent の中にも2つの枝があります。

One-shot agent

一度質問を受け、一度計画を立て、道具を何回か使って、答えを吐いて終わりの agent。初期の LLM プロダクトはほぼこの構造でした。ChatGPT の初期に「Python でこのデータを分析して」と入れると、一度計算して答えが出る。途中で間違っていてもそのまま終わっていて、ユーザーが「違うじゃん」と再入力して新しいターンが始まる、という流れでした。

One-shot の特徴は 「試行が1回」 ということです。失敗してもその失敗を反映して再び試行する構造がない。人がまた話しかければ新しいセッションが開きますが、それは agent 内部の loop ではなく、人間が作る loop です。

Persistent loop agent

対して persistent loop agent は、一度で答えが出ないと 自分で再試行 します。試行 → 結果確認 → 仮説修正 → 再試行。これを何ターンも回して、ある時点で「終わった」と判定したら止まる構造。

Claude Code を使ったことがある方は感覚が掴めるはず。「このテストを通して」と投げると、Claude Code がコードを書き、テストを回し、赤が出ればコードを直し、また回し、また直します。人が介入しなくても 失敗信号を受けて次のターンが回っていく。これが persistent loop の骨組みです。

Autoresearch は、この persistent loop を「研究課題」という問題ドメインに適用したもの です。バグ修正ではなく仮説探索。テスト合格ではなく「この条件で性能が上がるか」のような実験的な問い。

2つの構造の大きな違い

One-shot は 「単発計算」 です。来た問題を加工して1回吐くこと。

Persistent loop は 「実験室」 です。問題を何度も叩いて、毎回少しずつ違う形で叩いて、スコアが上がる方向に動くこと。

多くの人が autoresearch を「長く回る One-shot」と誤解します。これは違う。長く回るのではなくて 何度も違うやり方で 回るんです。同じ試行を長く続けるのは時間の無駄で、違う試行を反復するのが探索 です。このひとつの差を掴んで進むのが、今回の記事の核心です。

---

3. Autoresearch の5つの構成要素

それでは autoresearch が実際にどんな部品で出来ているかを見ていきます。これらの部品は、科学哲学でいう「科学的方法」の再配置に近い。研究という活動を作動可能な単位に分解した結果です。

(a) 明示的な仮説

出発点は 仮説 です。「これをこう変えたらスコアが上がるか?」「この組み合わせのほうが速いか?」のような問い。大事なのはこの仮説が 明示的 であるべきだということ。頭の中だけにあるのではなく、システムが読める形で書かれていないとダメです。普通は設定ファイルかプロンプトの中に構造化された形で入ります。「learning rate 0.001 のほうが 0.01 より validation loss が低いだろう」みたいな文がその例です。

なぜ明示的でないといけないかと言うと、後で結果を解釈するときに 「何を期待したか」 と比べなければいけないからです。期待が曖昧だと、結果が来ても解釈できません。

(b) 行動(実験)

仮説を確認するには、実際に何かやらないといけません。コードを実行するか、モデルを学習させるか、ベンチマークを回すか、API を叩くか。これが 行動 あるいは 実験 です。

行動は必ずツール(tool)呼び出しを通じて起きます。ここで M4 でやった tool use の話が繋がります。Agent が直接計算するのではなく、環境に対して何かを実行して結果を受け取る形です。コード実行器、ファイルシステム、HTTP リクエスト、GPU クラスタ、なんでもあり得ます。

(c) 結果の観察

実験が終わると 結果 が出ます。スコア、ログ、出力、エラーメッセージ。これをシステムが読める形で受け取らないといけない。

ここが意外と難しい地点です。結果が単純に「数字ひとつ」のこともあれば、長いログ文字列や複数指標の組み合わせということもあります。Agent がこれをどう要約して次の判断に使うかは、システム設計の隠れた難題です。

(d) 結果の解釈(eval 基盤)

結果が来たら 解釈 です。「この結果は前より良いのか?」「期待した方向に動いたのか?」「失敗なのか部分成功なのか?」

この解釈がまさに M5 で話した evaluation です。Eval があって初めて結果を数字で比較でき、数字で比較できて初めて方向感覚が生まれます。Eval なしで結果を見ると「何か回ったけれど、良いのか悪いのか分からない」状態になる。この状態で次の仮説に進めば、それはただのランダム探索になります。

(e) 次の仮説へ更新 → 反復

解釈が終わったら、今度は 次の仮説 を作らないといけない。「learning rate をもっと下げてみるか?」「データ前処理を変えるか?」「この方向はダメそうだから、別の軸に振るか?」

ここが autoresearch の いちばん繊細な部品 です。仮説更新がどれだけ賢いかが、全体システムの効率を決める。単に「ランダムに別の値を試す」ならグリッドサーチと同じで、「前の結果を反映して次の方向を取る」がちゃんと入って初めて 探索が情報を積みながら前進する 形になります。

5つの部品がひとつの輪に結ばれる

仮説 → 行動 → 観察 → 解釈 → 仮説更新。この5ステップが 閉じた輪 を作ります。ひとまわりが終わると次のまわりが始まる。この輪が autoresearch の骨組みです。表に LLM が乗ろうが強化学習 agent が乗ろうが、この5部品の循環構造があれば autoresearch システムと呼べます。

逆に、このうち1ステップでも抜けたら autoresearch とは呼びにくい。仮説がないならただの trial and error、解釈がないならただの無限再試行、仮説更新がないならただの retry loop。この区別を次のセクションで詳しく見ます。

---

4. eval がないと autoresearch はただ長く回るシステム

M5 で長くやった話を1文に圧縮すると、「loop は信号があって初めて方向が出る」 です。

Autoresearch も例外ではありません。いや、もっとシビアです。Autoresearch は loop がすべて のシステムだから。Loop の中の信号が粗いと、全体が粗くなります。

eval が粗いとき何が起きるか

具体的に見ます。例えば「要約品質を上げるプロンプトを探索する」autoresearch システムを回すとします。Eval 関数が「要約の文字数が200字以下なら良い要約」とだけ定義されていたら、どうなるでしょう。

システムはスコアが上がる方向に進みます。なので要約を短くする方向にプロンプトが収束する。結果、「この論文の核心は AI である。」みたいな無意味な要約が満点を取るような状況が生まれます。Autoresearch は eval を 本当に 最適化するので、eval が間違っていれば、システムは その間違った方向に堅固に 進んでいきます。

これを普通 Goodhart の法則 と呼びます。「測定が目標になると、測定は良い測定ではなくなる。」もともと経済学から来た言葉ですが、AI でも同じように働きます。長く回る autoresearch ほど、この罠は深くなっていきます。

信号の質がシステムの天井だ

もう一度。M5 の核心メッセージがここで戻ってきます。eval の質がシステムの天井 です。どれだけ賢い LLM を入れても、どれだけ長く回しても、eval が 0〜1 だけ返すノイジーな関数なら、システムはそれ以上行けません。

この話を長くするのは理由があります。Autoresearch のプロダクト・論文を評価するときに一番先に見るべきなのが 「このシステムの eval は何で出来ているか」 だからです。モデルが何か、何ターン回るか、パラメータは何か、より先に聞くべき問いです。

---

5. 終了条件の重要性

Loop は回ることと同じくらい 止まること も重要です。これは意外と見落とされる部分です。

autoresearch が無限に回るとどうなるか

理論上は仮説を無限に作り、無限に実験し、無限に解釈できます。現実では3つ壊れます。

コストが暴走する。Autoresearch は毎ターンごとに LLM 呼び出し + ツール実行が起きる。トークンコスト + API コスト + インフラコストがターン数に比例する。100ターン回せば100倍のコストに、1000ターンなら1000倍。終了条件なしに「良い答えが出るまで」で回せと言うと、数百ドル・数千ドルがあっという間に消えます。

品質が停滞するか悪化する。最初の数十ターンはスコアが上がりますが、どこかで収束する。そこからはランダムな変動だけが残る。ひどい場合は 過剰適合 が起きてスコアが下がる現象も報告されています。Eval のバイアスを掘り下げる方向にシステムが行ってしまうからです。

目的を見失う探索。これはやや定性的な問題ですが、agent が長く回っているうちに最初の目標を見失うケースがある。「新しい要約プロンプトを探す」で始まったのに、10時間後には要約ではなく翻訳実験をしている、みたいなこと。Goal drift とも呼びます。

どんな終了条件が使われるか

実務では複数を重ねて使います。

Budget 消尽。一番単純で確実。「この実験にトークン100万個まで」または「API コスト50ドルまで」という上限を置く。到達したら止める。

Iteration 上限。「最大50ターン」のように loop 回数に上限を置く。トークン量が予測しづらいドメインで有用です。

性能収束の検知。直近 N ターンでスコア改善が閾値以下なら止める。「5ターン連続で1%以上上がらなかったら収束と見なす」みたいなルール。

失敗累積の閾値。失敗が連続 K 回出たら止める。「同じエラーが3回連続で出たらシステムが詰まったとみなして中断」というパターン。

人の確認チェックポイント。特定条件で人間に承認を要求する。危険操作、高コストステップ、異常検知時など。

本番の autoresearch システムは、この5つを ほぼぜんぶ重ねて 使います。ひとつでも抜けると、どの方向から事故が起きるか分かりません。これがハーネス設計の地味な部分ですが、事故を防ぐのは全部ここで行われています。

終了条件の設計 = autoresearch の安全装置

自動運転車でもアクセルだけでブレーキがないなら、それは車ではないですよね。Autoresearch も同じ。Loop を回す能力だけあって止める能力がなければ、それはただの 高い無限ループ です。ニュースで「AI が研究する」という華やかな話が出るとき、実際のエンジニアはこの終了条件の設計にほとんどの時間を使っています。

---

6. 具体的な事例 — 科学実験自動化の研究群

用語の説明だけだと手に馴染みにくいので、実際に回ったシステムをいくつか軽く触れておきます。これらの事例が、現在「autoresearch」という用語の具体的な参照点です。

Sakana AI — The AI Scientist (2024)

日本の AI スタートアップ Sakana AI が2024年に発表した “The AI Scientist” は象徴的な事例です。このシステムは機械学習の研究プロセスを自動化しようと試みます。論文アイデア生成 → 実験コード作成 → 実験実行 → 結果分析 → 論文初稿作成 → 自己レビュー、までが1本のパイプラインに束ねられている。

この記事で大事なのは パイプラインの内部に loop が入っている という点です。アイデアが出たら一度で論文になるのではなく、実験を回して結果を解釈して修正してまた実験する、というステップが自動で回る。これが autoresearch の典型です。

発表当時に話題になったのは、実際に論文初稿が複数本出てきたこと。もちろん質的には研究者の水準にはまだ届いておらず、新しい科学的発見と呼べるものはありませんでした。でも「パイプライン全体を回すシステムが可能ではある」ことは証明しました。限界と過大評価の議論はセクション9で再び触れます。

DeepMind — FunSearch (2023)

DeepMind が2023年に Nature に発表した FunSearch は少し違う軸です。このシステムは数学的難題に対する プログラム を LLM が反復生成しながら、その中から良いものを evaluator が選別して次の世代の seed にする構造です。

具体的には「cap set problem」という組合せ論の難題で、人間がそれまで知っていたより良い解を見つけ出しました。重要なのは FunSearch が一度で答えを出したのではなく、数万回のプログラム生成 → 評価 → 選別 → 再生成 を回したことです。まさに autoresearch の輪構造です。

仮説は「このプログラムがより良い解を出すだろう」、行動はプログラム実行、観察は解の品質、解釈は evaluator のスコア、更新は LLM が上位プログラムを seed に新しいプログラムを生成すること。5つの部品がそのまま入っています。

Autonomous chemistry labs

これは特定プロダクトというより研究の流れです。Carnegie Mellon、Liverpool、ETH Zurich などで ロボット実験室 + LLM を組み合わせて、仮説を立て実際の化学実験を自動で回すシステムが出てきました。2023年に Nature に発表された “Autonomous chemical research with large language models” のような論文が代表例です。

ここでは LLM が「この反応をこの条件で回せば収率が上がるだろう」のような仮説を立て、ロボットアームが実際にビーカーに材料を入れ、スペクトルで結果を測り、LLM がそれを読んで次の条件を提案する。物理的な行動が loop に入った珍しい事例です。現在は特定の反応クラスに限定された水準ですが、「autoresearch が digital を超えて physical ドメインに広がる方向」を示す事例です。

3事例の共通点

3事例とも 一度では答えが出ない。ぜんぶ数十〜数万回の反復をする。そしてぜんぶ 評価基準 が明示的です。Sakana は自己 peer review、FunSearch はプログラム実行結果のスコア、自律実験室は実測値。この評価基準が loop の羅針盤の役割を果たします。

これがまさにセクション4で話した「eval がシステムの天井」という言葉の現場です。成功した autoresearch システムは例外なく 評価関数を丁寧に設計 していました。

---

7. Autoresearch と ただの loop — 何が違うのか

ここまで来ると疑問がひとつ出てきます。「ただの retry loop と何が違うの?」。失敗したらまたやってみる、というのは Claude Code でも ChatGPT でも起きますよね。ならあれも autoresearch なのか?

retry loop の構造

一般的な retry loop は普通こんな流れ。

1. 試行
2. 失敗検知
3. 同じやり方(またはごく少しだけ変えて)再試行
4. 成功すれば終了、失敗が積もれば諦め

この構造の特徴は 仮説がない こと。「なぜ失敗したか」のモデルがないんです。ただ「もう一度やる」。失敗の原因が一時的なネットワーク問題なら効くし、根本問題なら失敗し続けます。Retry は 探索ではなく忍耐 です。

autoresearch の構造

Autoresearch は失敗が出ると「なぜ失敗したか」を解釈します。その解釈に基づいて 次の試行は前と意図的に違うように 設計される。「learning rate が大きすぎて発散したらしい → 次は半分に下げよう」。これが仮説更新です。

この更新があると、失敗も情報になります。「この方向じゃない」と分かっただけでも探索空間を狭めたわけだから。Retry は失敗から何も学ばないけれど、autoresearch は失敗から学びます。

境界が曖昧なケース

実務ではふたつが混ざる場合が多い。「失敗したらエラーメッセージを読んで違うやり方で試す」というパターンは中間くらいの位置です。仮説更新はあるけれど浅い。これを miniature autoresearch と呼べます。次のセクションで詳しく見ます。

区別の一文: 仮説更新がない反復は retry、仮説更新がある反復は autoresearch。この境界を握っておくと、プロダクト比較のときの混乱がぐっと減ります。

---

8. 実務で出会う autoresearch の要素

あなたはすでに autoresearch の小さな断片を毎日使っています。私が主に使う Claude Code の中にいくつも隠れています。

Verification loop

Claude Code の verification loop は「作業完了 → テスト実行 → 失敗なら修正 → 再実行」を回します。これは retry に近いですが、失敗メッセージを読んで 修正方向を変える 部分に浅い autoresearch 要素があります。

仮説: このコードはこのテストを通すだろう。
行動: コード保存 + テスト実行。
観察: テスト結果。
解釈: 赤が出たらどこで出たか、どの assertion が壊れたか。
更新: その部分を修正した次のバージョンを作成。

5つの部品が浅くても存在しています。通常はこの loop を数ターン内で終えるように設計されていて、10ターンを超えたら「人間が見るべき」という警告が出るようになっています。

TODO.md ベースの再進入

もう少し大きな規模の autoresearch 要素が TODO ファイルベースの再進入 です。複数セッションにわたって TODO.md や似たファイルに進捗を書いておき、新しいセッションではそのファイルを読みながら「ここまで済んで、次はこれをやる」を引き継ぐ構造です。

これは1セッション内の loop ではなく 複数セッションにまたがる meta-loop です。1セッションで得た失敗と部分成功を次のセッションが読んで出発点にする。ただしこのとき TODO ファイルに 「なぜそう決めたか」の文脈が残っていて 初めて、次のセッションが同じミスを繰り返さずに済みます。ただやることだけ書かれていると、仮説更新がない retry になります。

prompt iteration

プロンプトエンジニアリングも小さな autoresearch です。「このプロンプトが欲しい出力を返すか」という仮説で始まって、実際に LLM に投げて出力を受け取り、期待と比べて、次のプロンプトに修正する過程。これを数十回繰り返してプロンプトを磨き込むのが、まさに autoresearch の手動バージョンです。

自動化された道具がこれを少しずつ人の代わりに回してくれるようになっています。例えば DSPy、PromptBreeder のようなフレームワークが「プロンプトを自動で探索する」方向で出ています。これはセクション6の事例と同じ系譜です。

現在の水準

今使っているプロダクトに入っている autoresearch 要素は miniature です。Loop が浅く、仮説更新が単純で、終了条件が短い。それでも「loop がある」だけで one-shot に比べて出来ることがずっと増えます。次世代のプロダクトは、この loop をもっと深く、もっと長く回す方向に向かっています。それが M7 で話す meta-harness とも繋がります。

---

9. Autoresearch の限界と過大広告

Autoresearch が話題になるにつれて、誇張された主張もたくさん出回っています。実務者として濾過すべきポイントを整理します。

(a) 計算コストの暴騰

Autoresearch の最も直接的な限界は コスト です。数十〜数千回の LLM 呼び出し + 実験実行が積もると、1研究セッションが数百〜数万ドルに達します。Sakana AI の The AI Scientist の公式資料でも、論文初稿1本生成にそれなりのコストがかかると述べられています。

これが問題なのは、コストが上がると実験を頻繁に回せない ことです。本来の研究は安い実験をたくさん回しながら仮説を立てる必要があるのですが、各実験が高くなると自己検証の頻度が落ちる。皮肉なことに、「自動化でもっと多く回せる」という約束と逆の方向です。

(b) 創造的な仮説はまだ人が種を撒く

現在の autoresearch システムは 与えられた仮説空間の中で 探索するのは得意です。「このパラメータ範囲で最適を探す」とか「この関数形態の中で良いものを探す」のような課題には強い。ですが まったく新しい仮説フレーム を作るのはまだ難しい。

FunSearch も「cap set 問題」という決まった問題枠の中で動きました。The AI Scientist も与えられた ML 研究テンプレートの上で変形を試みました。まったく新しい研究領域を開くような創造性は観察されていません。種となる問題のフレームは、依然として人間が撒かないといけない。

これが変わるかどうかはまだ分からない話です。ただ現在の「AI が科学全体を自動化する」のような主張は誇張と見るのが安全です。

(c) 終了条件がないと発振する

セクション5で言ったままです。終了条件が粗ければ autoresearch は高いコストで何も得られずに終わります。これは限界というより 設計責任 です。自動化の約束を壊さないためには、終了条件を最初からしっかり打ち込んでおく必要があります。

(d) eval の質が天井

繰り返しますが eval が天井です。Eval がノイジーだったり偏っていたりすると、autoresearch は その偏りをもっと速く掘り下げます。人間が手で実験するときは途中で「あれ、これ測定がおかしいな」と気づく余地があるけれど、自動化された loop はその自覚がありません。設計されている eval を額面通りに最適化する。

Eval をまともに設計できていない autoresearch は、人間がやるよりも もっと悪い結果 を生むことがあります。この点は Sakana AI の The AI Scientist の後続議論でも認められている部分です。「自己 peer review が十分に厳しいのか」という問いがずっと投げかけられています。

(e) 再現性と検証負担

Autoresearch が吐いた結果を人間が検証しないといけないのですが、その検証コストが依然として大きい。システムが10本の論文初稿を出したら、人間がそれを読んで検証する時間が必要になります。検証まで自動化すると「誰が検証を検証するのか」という無限後退が起きる。現状は人間の検証が病口で、この病口が autoresearch の実質的な処理量を決めます。

誇張を濾過するために

ニュースで「AI がひとりで研究する」というヘッドラインを見たら、次の問いを心の中でしてみてください。

• 仮説空間は誰が定義したか?
• eval 関数は何か? 検証可能か?
• 終了条件は何か? コスト上限はあるか?
• 結果は何人の人間が検証したか?

この4つの問いに対する答えが明確なら真面目なシステムで、曖昧なら誇張が混じっています。この4つの問いは次の M7 で meta-harness の設計ポイントとして再登場します。

---

---

10. Autoresearch と Meta-Harness は何が違うか

M7 の予告として、ふたつの違いを先に押さえておきます。

Autoresearch = 探索 loop の改善。仮説をうまく作り、実験をうまく回し、結果をうまく解釈し、次の仮説にもっと賢く進む方向を扱う。loop そのもの が主役です。

Meta-Harness = その loop が乗る土地を変える。Harness は agent が道具を使い、リソースを割り当てられ、安全に回るようにしてくれる 環境 です。Meta-harness はその harness そのものを改善する harness です。「自動車をもっと速く走らせるエンジンチューニング」が autoresearch なら、meta-harness は「その自動車が走る道路を新しく舗装する」に近い。

具体的にはこんな感じ。道具 API を自動で最適化する、権限モデルを自動で調整する、コストモデルを見てリソース割り当てを変える、他の agent を自動で呼び出して管理する。こういうのが meta-harness の領域です。

Autoresearch と meta-harness は 階層が違います。Autoresearch は実験室の中で研究者の仕事を改善し、meta-harness は実験室の建物と設備を改善する。次回の M7 でこの比喩を長めにほどきます。今は「階層が違う」だけ覚えておいてください。

---

11. 実務者チェックリスト — autoresearch のプロダクト・論文を見るとき

Autoresearch と名乗るプロダクトや論文に会ったら、次の6つの問いを聞いてみてください。これらにどれだけ鮮明に答えられるかが、そのシステムの堅牢さをかなり正確に語ってくれます。

1. 仮説表現のやり方は明示的か? システムがどんな形で仮説を書き、どう読むか。自然言語プロンプトか構造化された config か。ログを見たときに「この試行がどの仮説を確認しようとしたか」が明確に追跡できるか。

2. Eval 関数はどう組まれているか? 何を測り、ノイズはどれくらいで、検証可能か。Eval が1行の単純なものなら信頼度を下げて見るべき。複数指標の組み合わせならより信頼できます。

3. 終了条件は文章化されているか? Budget、iteration、convergence、failure cap、human checkpoint — このうちいくつが結合されているか。1つだけなら脆いです。

4. 失敗がどう次のターンに反映されるか? ただの retry なのか、仮説更新があるのか。ログを見たときに「前の失敗がこの試行にこう影響した」が見えるか。

5. 計算コストはいくらで、誰が負担するか? 1実験セッションあたりのコスト、そのコストがユーザーに転嫁される構造か、プロダクト提供者が飲むのか。これがプロダクトの持続可能性を決めます。

6. 結果は誰が検証するか? システム自身か、人間か、両方の組み合わせか。自己検証だけならその検証の独立性をどう担保するか。

この6つが autoresearch システムの「骨組み点検表」です。論文でもプロダクトでもセールスピッチデックでも、この6つに答えを得ようと試みてみると、文脈がぐっと掴みやすくなります。

---

12. 締めの一文

Autoresearch は AI がひとりで研究する魔法の箱ではなく、仮説・行動・観察・解釈・更新 が反復される構造がシステムに組み込まれたものだ。この構造がよく設計されれば人間より速く探索できるし、雑なら高いコストで何も得られない。長く回す機械ではなく、実験が反復される機械。この感覚を握ってニュースを見ると、誇張と実体がはるかに鮮明に分かれます。

次回は M7 — Meta-Harness が loop の上の土地を変える です。Autoresearch が loop を洗練させるなら、meta-harness は loop が走る土地自体を組み替える話。ふたつの階層がどう違って、どう協力するかを見ると、自動化された agent の設計感覚がまた一段降りてきます。

---

FAQ

Q1. Autoresearch と AutoML は同じものですか?

違います。AutoML は与えられたデータセットで ハイパーパラメータとモデル構造を自動で探索 するシステムです。歴史が長くて(2013年前後から本格化)、探索空間が明確に定義されています。Autoresearch はその1つ上の層です。「何を実験するか」自体を仮説の形で立てる 段階が含まれる。AutoML は決められた問題をうまく解くことで、autoresearch は問題自体を新しく取り出すところまで一部含む概念です。もちろん現在の水準で autoresearch の「新しい問題を取り出す」は限定的です(セクション9参照)。

Q2. うちのチームで autoresearch システムをすぐ導入できますか?

まず eval 関数があるかから確認してください。「うちの業務で、良い結果と悪い結果を自動で区別できる関数があるか」が問いです。あれば miniature autoresearch から始められます。例えば「このプロンプトが別のプロンプトより良いか」を自動で評価できれば、prompt iteration の形で autoresearch を付けられます。Eval がなければ autoresearch は絶対に失敗します。Eval を先に作るのが順序です。

Q3. Autoresearch は人間の研究者を置き換えますか?

現在の水準では置き換えではなく 拡張 に近い。人間が仮説を投げ、システムがその仮説の周辺を速く探索し、人間が結果を解釈して次の仮説を投げる、というように混ざって働くパターンが一番うまくいきます。Sakana AI の The AI Scientist のようなフル自動システムも出てきていますが、成果物の品質はまだ上位ジャーナルの水準には届いていません。10年後は違うかもしれないけれど、2026年時点では「人間 + autoresearch」が「人間だけ」より速く、「autoresearch だけ」は「人間だけ」に届かない領域が多い、というのが実情です。

---

---

ニュースレターのご案内

こうしてひとつの概念を最後まで解きほぐしていく記事を、毎週月曜日の朝にメールでお届けしています。受け取ってみたい方は ニュースレター登録(無料・30秒) からどうぞ。

---

ソース

• Sakana AI. “The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery” (2024)
• Romera-Paredes et al. “Mathematical discoveries from program search with large language models” (FunSearch, Nature 2023)
• Boiko et al. “Autonomous chemical research with large language models” (Nature 2023)
• Khattab et al. “DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines” (2023)
• Anthropic. “Agentic systems and evaluation” — 公式ガイド (anthropic.com)

---

著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)

ソースリスト

• テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
• AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 公式ドキュメント
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス

---

著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。