2 年間、AI エージェントからより多くの成果を引き出すには、より良いプロンプトを書くことだった。
その時代は静かに終わりつつある。世界最高のエンジニアたちは、しばらく前からプロンプトを書くのをやめ、ループを書き始めている。つまり、エージェントにプロンプトを与え、結果を確認し、作業が完了するまで実行し続けるシステムだ。
Karpathy の徹夜スクリプトは、彼が 20 年にわたって手動で調整して見逃していた 20 の最適化を発見した。Claude Code を構築した Boris Cherny は、今年に入って一行もコードを書いていない。Anthropic のエンジニアは現在、2024 年と比較して 1 日あたり約 8 倍のコードをマージしている。
彼らの誰も、より賢いことをタイプしたわけではない。彼らはタイプするのを完全にやめたのだ。
ここでは、ループとは実際何なのか、いつループが必要で、いつ必要ないのか、そして最初のループを構築する方法について説明する。
人間が寝ている間に 700 回の実験
2026 年 3 月。Andrej Karpathy が 3 つのファイルを GitHub にプッシュする。約 630 行のコードだ。
1 つのファイルはモデルを保持していた。1 つはスコアリング用だった。1 つはエージェントに何を探求し、何を放置すべきかを指示した。エージェントはトレーニングファイルにのみ触れることができた。それ以外は不可だった。
サイクルは意図的に退屈なものだった。コードを読み、変更を提案し、5 分間トレーニングし、スコアが向上したか確認し、向上した場合は変更を保持し、しなかった場合はロールバックし、そして再び実行する。
彼はそれを、自ら 20 年にわたって手動で調整してきたモデルに向けて実行した。2 日間実行させた。
700 回の実験が実行された。20 の改善点が見つかった。そのうちの 1 つは、アテンション機構におけるスカラー乗算器の欠落だった。微妙で、どんなリンターも決して捕捉できない種類のバグだが、まさに注意深いエンジニアなら見つけられたはずで、誰も見つけられなかった類のものだ。
Shopify の CEO は、社内モデルに対して同じ手法を一晩で実行した。翌朝、以前のモデルの半分のサイズで 19 パーセントの品質向上を目の当たりにした。
ここでの洞察は「AI の方が賢い」ということではない。人間は 12 回目の実験の後には疲れてしまう。ループは決して疲れない。
ループとは、スケジュール化されたプロンプトではない
ほとんどの人は「ループ」と聞くと cron を思い浮かべる。それでは本質を完全に見逃している。
プロンプトは 1 つの指示である。ループは、誰も座っていなくても、AI が目標に到達するまで働き続ける目標である。計画し、実行し、自身の結果を検証し、その結果をフィードバックし、繰り返す。
5 つの段階：発見、計画、実行、検証、反復。このうち 3 つが実際の作業を行う。
検証機能こそがループの核である。出力に本当のゲートがなければ、ループは存在せず、エージェントが自分の宿題を永遠に採点しているだけになる。ゲートとは、合格か不合格かのテスト、コンパイルされるかクラッシュするかのビルド、ゼロまたは非ゼロを返すリンターである。意見を持つセカンドエージェントではない。
状態こそがループに学習をもたらす。サイドのファイル、Linear ボード、プロジェクトログ、会話の外で何を試み、何が失敗したかを記録する場所。明日の実行は、ゼロから始めるのではなく、再開される。
停止条件こそがループを正常に保つ。すべての本物のループには 2 つの出口がある：目標が達成されるか、ハードキャップが作動するかだ。これを省略すると、一晩中何もせずに稼働し続けるマシンを作ることになる。
これら 3 つのうち 1 つでも欠けていると、ループを構築したことにはならない。高価なスクリプトを構築したことになる。
ループを構築する前の 4 つの条件
ループがそのコストに見合うのは、4 つの条件がすべて同時に満たされた場合のみである。1 つでも欠けると、セットアップにかかるコストがリターンを上回る。
- タスクは少なくとも毎週繰り返される。それ以下だと、セットアップコストは決して償却されない。
- 作業を自動的に不合格にできるものがある。テスト、型チェック、リンター、ビルドなど。
- トークンバジェットが無駄を吸収できる。ループはコンテキストを再読み込みし、リトライし、探索する。
- エージェントにシニアエンジニア向けのツールがある。ログ、再現環境、自身が書いたコードを実行して何が壊れるかを確認する機能。
正直なところ、ループを販売している誰も教えてくれない部分がある：ほとんどの人はまだヘビーバージョンを必要としていない。コンシューマープランで真剣な作業に対して一晩中検証ループを実行しようとすると、生産性向上が訪れる前にトークン代の請求書が届く。
良い最初のループは、退屈なものだ。CI トリアージ。依存関係のバンプ。Lint と修正のパス。不安定なテストの再現。すでに強力なテストが整っているコードベースでの Issue から PR へのドラフト作成。
悪い最初のループは、面白いものだ。アーキテクチャの書き換え。認証コード。決済。「完了」が判断に委ねられ、人間がまだ意見を述べなければならないもの。
ループを現実のものにする 5 つのブロック
すべての本物のループは、同じ 5 つの要素から組み立てられる。Claude Code と Codex は現在、これらすべてを備えている。
1 つ目は自動化。鼓動だ。スケジュールやイベントに基づいてループを起動するもの。/loop は一定の周期で実行される。/goal は、あなたが定義した条件が実際に成立するまで実行を続ける。鼓動がなければ、ループは一度実行したきり忘れられるスクリプトになる。
2 つ目はスキル。エージェントが実行のたびに読み込む claude-md ファイルとして保存されたプロジェクト知識。これがないと、ループは毎サイクルゼロからコンテキストを再導出する。これがあれば、意図が積み重なる。ループは、あなたの規約、ビルド手順、3 ヶ月前のあるインシデント以来決してやらないことを認識する。
3 つ目はサブエージェント。作成者とチェッカーは同じモデルであってはならない。コードを書いたモデルは、自身の作業を評価するのにあまりにも寛大すぎる。記事を書いたモデルは、自身の弱いセクションを見逃す。書き手は高速かつ安価に。レビュアーは低速かつ厳格に。この分離こそが品質の大部分を占める。
4 つ目はコネクタ。ループはプルリクエストを開き、チケットをクローズし、CI がグリーンになったらチャンネルに通知する。これが、「修正案はこちらです」と言うエージェントと、朝に PR がすでにマージされたことを知らせるレポートとの違いである。
5 つ目は検証機能。悪い作業を自動的に不合格にするテスト、型チェック、またはビルド。その他はすべて配管である。ループがあなたの役に立つのか、単にお金を消費するだけなのかを決定するのは、このブロックである。
これらを積み重ねると、本格的なチームが現在大規模に実行しているものが得られる。数十のループが、それぞれ 1 つの狭いジョブを担当し、皆が寝ている間に並行して実行される。あるエンジニアは、このようなフリートループを使用して、コードベース全体をある言語から別の言語に約 6 日間で書き換えた。これは手作業ではほぼ 1 年かかる作業だった。
ループが静かに失敗する場所
ループはクラッシュしない。静かに請求書を送ってくる。名前を挙げる価値のある 2 つの失敗モードがあり、どちらもループが改善されるにつれて悪化し、簡単にはならない。
1 つ目は Ralph Wiggum ループだ。エンジニアの Geoffrey Huntley が文書化した。エージェントが早すぎる段階で完了したと判断し、半分しか終わっていないジョブに対して完了シグナルを発行し、ループは満足して終了する。ハードな客観的ゲートがなければ、ループは翌晩も実行を続け、費用を費やし続け、誰も受け入れない成果を生み出し続ける。
修正方法は、より賢いエージェントではない。より愚かなゲートだ。合格か不合格かのテスト。コンパイルされるかされないかのビルド。意見を持たないもの。
2 つ目はより微妙だ。理解負債（Comprehension debt）。ループがあなたが書いていないコードをより速く出荷すればするほど、リポジトリに含まれているものと実際に理解しているものとの間のギャップは大きくなる。スムーズに動作するループは、そのギャップに対して複利を課す。チームの誰も読んだことのないシステムをデバッグしなければならない日が来ると、トークン代よりもはるかに多くのコストがかかる。
それに伴い、認知放棄（Cognitive surrender）が生じる。ループが自動的に実行されるとき、意見を形成するのをやめて、返ってきたものを受け入れるのは魅力的である。判断力を持ってループを設計することは、その治療法である。考えることを避けるためにループを設計することは、促進剤である。同じ行動でも、結果は逆になる。
2 人の人間がまったく同じループを構築して、正反対の結果に終わる可能性がある。1 人は、深く理解している作業をより速く進めるためにそれを使用する。もう 1 人は、その作業をまったく理解することを避けるためにそれを使用する。ループはその違いを知らない。あなたは知っている。
10 個ではなく、1 つのループから始める
誰もが犯す間違いは、初日からシステム全体を構築しようとすることだ。10 のループ、ダッシュボード、フリート。どのループが何をしたか区別がつかなくなるため、週末までに崩壊する。
1 つから始めよう。最も厄介な繰り返しタスク、習慣で毎朝チェックしているものを選び、その単一のジョブをループに変える。数日間実行させてみる。どこで無理をしているか、どこで見逃しているかを観察する。締め付ける。それから 2 つ目を追加する。
ツールよりも順序が重要だ。まず、1 つの手動実行を高速ではなく、信頼性高くする。その実行を claude-md スキルに変える。そのスキルを、客観的ゲートとハードな停止条件を備えたループでラップする。そして、その後にのみ、スケジュールに載せる。先を急いで、手動で信頼性を確保していないものをスケジュールすることは、まさにループが寝ている間に爆発する原因となる。
ループが機能しているかどうかを判断する指標は、消費されたトークン、試行されたタスク、開かれた PR の数ではない。それは、受け入れられた変更あたりのコストである。受け入れられた変更の割合が 50 パーセントを下回っている場合、ループが本来除去するはずだったレビュー作業を行っており、ループは負けている。
Karpathy はトレーニングコードを書くのをやめた。Cherny はプロンプトを書くのをやめた。二人とも考えるのをやめたわけではない。この記事から何か一つだけ持ち帰るとすれば、それを持ち帰ってほしい。ループとは、あなたが実際にリスクを伴う 5 パーセントに完全に集中している間、退屈な 95 パーセントを処理するシステムである。
あなたはエージェントのフリートに支払いをしているのに、1 つのチャットウィンドウしか使っていない。
フォローして、私の Telegram チャンネルに登録してください： https://t.me/+75nMf005jRpjMDU1
