ループ・エンジニアリング――検証が安いところでループは勝つ

Claude Code を生み出したエンジニア、Boris Cherny は、日中は数百のエージェントを走らせながら 5〜10 個のセッションを開いたままにし、毎晩は数千のエージェントを走らせています。² 「もう Claude にプロンプトを書くことはない……私の仕事はループを書くことだ」と語る彼のクリップが先週 X 上で拡散したとき、ほとんどのコメントはこの一言を自律的なソフトウェア開発の予言として扱いました。そして数日のうちに、Addy Osmani がそこに一つの規律の名前を与えたのです。ループ・エンジニアリング、と。⁷ 私はそのクリップの元になった 3 つの講演の全文書き起こしを引き出してみました。書き起こしが語るのは、もっと静かな物語です。そして、土台にすべきはその静かなほうなのです。Cherny が実際に名前を挙げているループは、どれも機械がタダで確かめられる成功条件を持っています。何を自動化できるかを決めるのは、ループの組み立てではなく検証のコストなのです。私は 2 月から本番環境でループを走らせてきましたが、私のログも書き起こしと一致します――苦い形でその教訓を叩き込んでくれた 2 件の事故も含めて。

TL;DR / 要点

• バズったこの引用は、Cherny の Acquired Unplugged インタビューに由来します。そこで彼はループを、パンチカードからアセンブリ、高水準言語、そしてプロンプトへと続く連続体の、次の一歩として位置づけています。¹ そしてこの移行には短い賞味期限を与えています。「これからの数か月、おそらく今年いっぱいくらい」だと。¹
• その仕組みは、意図して平凡です。Sequoia での講演で Cherny は、/loop とは Claude が cron を使って繰り返しジョブをスケジュールしているだけのものだと説明しています。² 彼が名前を挙げるループは、プルリクエストの世話をし、CI を健全に保ち、30 分おきに Twitter のフィードバックをクラスタリングする――そういう類のものです。²
• これらのループはどれも雑用係です。それぞれが機械でチェックできる終了状態を持っています。CI がグリーンになる、PR がリベースされる、フィードバックがまとまる。彼が名前を挙げた例の中に、無人で機能を作り上げるものは一つもありません。
• ループを書く仕事そのものは、すでにモデルの中へ溶け込みつつあります。Cherny によれば、新しいモデルは自らの判断でループを始めるそうで、彼はユーザー側でループを組むことを「プロダクトデザインの問題」と呼び、それは「自分がうまくやれていない」ということだと述べています。⁵
• ミームの底に残る、長持ちするスキルはこうです――無人で自動化して安全なものは何かを見極めること。その判断は検証可能性についての判断であり、ループの構文が消えたあとも、あなたの手元に残り続けます。

彼が実際に言ったこと

誰もが共有したクリップは、ライブの Acquired インタビューから来ています。Cherny はこの一言を、家族の歴史とともに切り出します。彼の祖父はソ連でパンチカードを使ってプログラミングをし、父はアセンブリを書いていて、「Python を書いている自分を笑っただろう」と。そして、拡散したのは次の部分です。

「これはプログラミングというものの性質みたいなものなんです。抽象度のレベルは常に上がっていく……1 年前の私のコーディングは、IDE の中で何らかの自動補完を使ってコードを書くというものでした。11 月に、私は IDE をアンインストールしました。使っていなかったからです……その時点では、たぶん 5 個、10 個の Claude を並列で走らせていて、私のコーディングとは Claude にプロンプトを書いてコードを書かせることでした。それがまた一段上がったのです……もう私は Claude にプロンプトを書きません。走っているのはループです。Claude にプロンプトを出し、何をすべきかを考えているのはそのループたちです。私の仕事はループを書くことなのです。」¹

Acquired Unplugged の全編インタビュー。ループのくだりは 11:14 から始まります。

全文書き起こしには、クリップに決して入らなかった 2 つの細部があります。第一に、Cherny 自身がこの移行に時期を切っています。ループとは「これからの数か月、おそらく今年いっぱいくらいに見られるようになるもの」なのです。¹ 彼が描いているのは一つの局面であって、終着点ではありません。第二に、この議論をたどる人のための出典についての注記です。複数のバズった投稿が、ループの話を彼の 1 時間に及ぶ Y Combinator のポッドキャスト出演に帰していました。私はそのエピソードの全文書き起こしを確認しました。そこにはループへの言及は一切ありません。エピソードが扱っているのは、プロダクトの成り立ちとサブエージェントです。⁶ 本題は、Acquired インタビューと 24 分の Sequoia 講演のほうにあります。

ループとは cron ジョブのことだ

Sequoia の講演が仕組みを提供してくれます。そしてそれは、わざと退屈にできています。

「やっていることはただ、Claude に cron を使わせて、未来のどこかの時点にジョブをスケジュールさせる、それだけです。そしてそれは繰り返しジョブなんです。1 分おき、5 分おき、1 日おきに走らせられます。」²

Sequoia の講演は、バズったクリップが置き去りにした機械的な細部をすべて補ってくれます。ループの節は 7:56 から始まります。

Cherny はこうしたループを何十も走らせています。彼が名前を挙げているのは、自分の PR の世話をするループ（CI を直し、自動でリベースする）、CI を健全に保つループ（不安定なテストを修復する）、そして 30 分おきに Twitter からフィードバックを引き出してクラスタリングするループです。² 5 月の Anthropic の Code with Claude イベントで発表された Routines は、同じパターンをサーバー側へ移し、ノートパソコンを閉じてもループが生き延びるようにします。² 基調講演をライブブログしていた Simon Willison は、Anthropic 自身が使う言い回しを書き留めています。Routines とは「高階のプロンプト」である、と。¹² Cherny は何か月も前から、/loop と /schedule がプロダクトの中でもっとも強力な機能の 2 つだと人々に語っていました。彼の定番の出発点は、PR の世話をする 5 分おきのループです。¹¹

このパターンには、もっと荒削りな先祖がいます。Geoffrey Huntley の Ralph Wiggum 手法は、彼自身の言葉で言えば「Ralph とは Bash のループだ」というものです。while true が同じプロンプトファイルを延々とエージェントに食わせ続け、反復のあいだは進捗がファイルと git 履歴に残っていきます。⁹ Anthropic は今や Ralph を公式プラグインとして同梱しており、それはエージェントの終了しようとする試みを横取りし、完了文字列が現れるか反復の上限に達するまでプロンプトを再投入し続けます。⁹ The Register は Cherny 自身が Ralph を使っていることを確認し、その経済的帰結についての Huntley の警告を引用しています。エージェント型のコーディングがおおよそ 1 時間 10 ドルで走るため、スタートアップはこの手法を使って既存の SaaS ビジネスをクローンし、価格で叩いてくるだろう、と。¹⁰ この系譜が大事なのは、このアイデアの実際の年齢を示してくれるからです。ループはコンピューティングで最も古い制御構造であり、この構造そのものには何ら新しいところはないのです。¹⁵

彼が名前を挙げるループは、どれも雑用係だ

ここに、この議論が飛ばしてしまった観察があります。Cherny のループをもう一度並べて、その終了状態を見てみてください。

それぞれが、機械でチェックできる成功条件を持っているか、あるいは間違いがあってもコストがゼロの出力を生み出すかのどちらかです。彼が名前を挙げた例の中に、「私が寝ているあいだに機能を作っておく」というものは一つもありません。毎晩数千のエージェントを走らせている男が、自分自身の自動化を CI の修復、リベース、フィードバックの仕分けだと説明しているのです。

一見した反例が、かえって規則を裏づけます。Anthropic 自身のエンジニアリングチームは、16 個のエージェントを 2 週間にわたって無限ループで走らせ、Rust で 10 万行の C コンパイラを作り上げました。計算資源にしておよそ 2 万ドルの費用です。⁸ コンパイラは、ソフトウェアの中で最も検証しやすい成果物です。膨大なプログラムのテストスイートが、正しくコンパイルされて動くか、動かないかのどちらかになるからです。チームは検証がほぼタダで済む標的を選んだわけですが、それでもなお、この実験を走らせた Nicholas Carlini は、自分で一度も検証していないソフトウェアをプログラマがデプロイすることは「現実的な懸念」だと書いています。⁸

この規律に「ループ・エンジニアリング」と名づけた Addy Osmani のエッセイも、デザインの側から同じ制約に行き着きます。「無人で走るループとは、無人で間違いを犯すループでもある」のです。⁷ 彼が提案するアーキテクチャ（作り手が自分の仕事を採点しないよう、検証役のエージェントを分ける）は、安い検証が自然には生じない場所で、それを人工的にこしらえようとする試みなのです。⁷

私自身のループが教えてくれたこと

私は 2 月に、夜通し走らせるエージェントシステムについて書きました。当時はまだ、この手法の上品な呼び名がシンプソンズのキャラクター名だった頃のことです。¹⁶ それ以来、私の環境で生き残ったループはどれも同じ形に収束しました。そして失敗したループのほうが、うまくいったループよりも多くを教えてくれたのです。

生き残ったのは、確認の形をしたループです。夜間に走るあるループは、その日のコミットを読み、変更されたファイルを稼働中の URL に対応づけ、影響を受けたページをすべて読み込んで、読み込み時間とともに合否を報告します。あるセキュリティのループは夜通しエンドポイントを監視し、朝の報告書を書きます。あるクロールのループは、私のプロパティ全体での Googlebot と Bingbot の動きを読み、インデックスのずれを報告します。これらはどれも、何も生み出しません。それぞれが観察し、期待される状態と照らし合わせ、報告するだけです。一つが誤作動しても、コストは古びたレポートであって、壊れたプロダクトではありません。朝の確認が数分で済むのは、出力が項目ごとに二択だからです――合格、不合格、ここを見ろ、と。

失敗したのは、行動するループでした。並列エージェントのために git の作業ツリーを自動作成する隔離機能は、二度にわたって、捨ててよいと判断した作業用ディレクトリを削除しました。その自動化の被害範囲には、自分が作ってもいなければ理解してもいないファイルが含まれていたのです。スケジュールされたキャッシュ削除は、あるときデプロイに対して間違った順序で走り、検索クローラーは存在するページに対して 11 時間ものあいだ 404 を受け取り続けました。削除処理が、オリジンが差し替え後の応答を返す前に、正しいキャッシュ応答を追い出してしまったからです。¹⁶ どちらの失敗も、モデルが悪かったわけではありません。どちらも、前提条件を私が固めきれていないループに、私が書き込み権限を与えたことから来ています。今ではそれぞれにガードがついています。作業ツリーの自動化は完全に封じ、削除処理はデプロイの検証が通ったあとにしか走りません。私が抽出した一般則はこうです――読むだけのループにはスケジュールがあればよい。だが書き込むループは、スケジュールを得る前に、順序の証明と被害範囲の上限を必要とする。

この規則は、Cherny の仕事ぶりの中で人々が最も信じがたく思う部分も説明してくれます。「実は今、私の仕事のほとんどはスマホからやっています」と彼は言い、Claude アプリのコードタブを通じてセッションを走らせています。² スマホはコードをレビューするにはひどい場所ですが、合否のレポートを読むには申し分のない場所です。このスマホの話は、姿を変えた検証の話なのです。彼のループは、ひと目で受け入れるか拒むかを判断できるほど読みやすい出力を吐きます。それが可能なのは、ループが走り始める前に成功条件が設計されていたときだけなのです。

検証コストのはしご

もしこの主張が正しいなら、何を自動化するかの選択は、たった一つの問いに帰着します――誰が結果を検証するのか、そしてその検証のコストはいくらか。次に挙げるのが、どんなタスクでもスケジュールを与える前に私が使うはしごです。

決め手になるのは 2 列目であって、タスクの難しさはそこに一度も現れません。タダの検証者がつく難しいタスク（不安定なテスト）のほうが、高くつく検証者しかない簡単なタスク（人間が承認しなければならない 1 行の文言変更）よりも先に自動化されるのです。Cherny のループ、Anthropic のコンパイラ、そして私の生き残りたちは、どれもこのはしごの上半分に座っています。バズったコメントは、下半分を前提にしていたのです。

このはしごを生き延びる形は、規模を問わず、一つの監督役パターンのように見えます。

スケジュールに値するループの解剖図。検証役を太く描いているのは、それが荷重を支える箱だからです。これを外してもループは走り続けますが、それが何をしたのかを誰も知りません。

走らせる価値のある最小のループは、読むだけで、自分自身を検証し、ひと目で判断できるものです。だからこそ、今日書いても安全で、明日眺めるには退屈なものになります。

# Nightly site check: observes and reports, never edits.
# Run it under a permission mode that blocks writes outside reports/.
while true; do
  claude -p "Read today's commits. For each changed file that maps to a live
    page, fetch the staging URL and confirm it returns 200 and renders its
    headline. Append PASS or FAIL per page, with the reason, to
    reports/site-check-$(date +%F).md. Write nothing outside reports/."
  sleep 86400
done

Claude Code の中なら、同じループはたった 1 行です。/loop 24h に続けて指示を書くだけ。昇格はあとから来ます。レポートが 1 か月退屈であり続けたあとで初めて、そのループははしごの次の段への検討に値するようになります――それより前ではありません。

残される仕事

Sequoia の講演で最も奇妙な一節は、それが生んだミームそのものを掘り崩します。Cherny は、新しいモデルが頼まれもしないのにループを始めるようになったと言うのです。彼がデータのクエリを頼むと、モデルはデータが時間とともに変わることに気づき、30 分おきの定期レポートを提案し、そのレポートを自ら Slack につないでしまう、と。⁵ 彼の結論はこうです。「道具をうまく握る方法を考え出すのはユーザーの仕事ではない……これは本当はプロダクトデザインの問題で、自分がうまくやれていないということなんです。」⁵ X 上で懐疑派が持ち出した無限後退の議論（今日は人間がループを書くが、明日はモデルがループを書く）は、結局のところ Anthropic のロードマップそのものであり、ミームの当の本人がそれを認めているわけです。

彼はさらに踏み込みます。「モデルが良くなるにつれて、ハーネスはだんだん重要でなくなっていく」と述べ、整合性が高まるにつれて、権限モード、プロンプトインジェクション対策、人間を介在させるチェックポイントは薄れていくと予測しています。³ 私は、この賭けの半分については逆の側に張ります。安全のための足場は縮むかもしれません。ですが、編成のための足場のほうは、彼自身の説明によれば、仕事のすべてになりつつあります。Anthropic のエンジニアのエージェントたちは、持ち主が働いているあいだ Slack 越しに互いを調整し合い、「もう社内のどこにも手書きのコードはありません。SQL はすべてモデルが書いています」。⁴ それらのエージェントが何に触れてよいか、何をもって完了とするか、2 体が食い違ったときに何が起きるか――それを誰かが決めています。その決める層こそが本当のエージェント・インターフェースであり、cron はそのうちの易しい部分にすぎません。

だから、長持ちするスキルはループの構文ではありません。それはモデルがすでに吸収しつつあります。プロンプトでもありません。それはループが先に吸収しました。長持ちするスキルは、その両方の下に座っている判断です――無人で自動化して安全なものは何かを見極めること。 その判断は、つねに検証コストについての問いなのです。CI の修復が真っ先に自動化されたのは、テストスイートがすでに検証者だったからです。フィードバックのクラスタリングが自動化されたのは、間違いがタダだからです。機能開発が抵抗するのは、検証に依然として人間が差分を読むコストがかかるからであり、Hacker News のあるベテランエンジニアは、そこから生まれる罠を率直に言い表しました。この道具は操舵に熟練した判断を要するのに、その道具を使うことが、まさにその判断を蝕んでいくのだ、と。¹⁴

Casey Newton による Platformer の Cherny インタビューは、「Claude Code の生みの親が語る、ソフトウェアエンジニアの終わり」という見出しで掲載されました。その中で Cherny は、「ソフトウェアエンジニア」という肩書が今年の終わりまでには「ビルダー」のような何かに溶けていく一方で、エージェントを通じてコードを書く人の数は 100 倍に増えると予測しています。¹³ その予測におけるビルダーとは、ループを選ぶ人たちのことです。うまく選ぶとは、何かが走り出す前に、それがうまくいったとどうやって知るかを知っているということなのです。

要点

コーディングエージェントを走らせるエンジニアへ： - 自動化の候補は、わくわくするかどうかではなく、検証コストで査定してください。CI の修復、リベース、監視、レポート生成には、今日すでにタダの検証者がいます。まずそれらを自動化しましょう。 - 読み書きの線引きを適用してください。読むだけのループにはスケジュールがあればよいが、書き込み権限を持つループは、無人で走る前に、明示的な順序の制約と被害範囲の上限を必要とします。 - ループより先にレポートを設計してください。ループの出力をスマホから 10 秒で却下できないなら、そのループは夜に走らせる準備ができていません。

チームリードへ： - 有用な並列度の天井は、エージェントの数ではなく、あなたのレビュー帯域です。その天井を越えてエージェントを足しても、スループットではなく、レビューされないままのマージが生まれるだけです。 - 作り手と確認役を分けてください。自分の仕事を検証するエージェントは正しさを主張するだけですが、別の視点を持つ分離された検証役なら、少なくともその主張を捕まえる見込みがあります。

道具を作る人へ： - Cherny はユーザー側のループ構築をプロダクトデザインの失敗だと呼んでおり、モデルはすでに自分でループを始めています。⁵ ループ作成の UX を作るとは、モデルのベンダーが吸収しようとしている層に向けて作るということです。より長く生き延びる面は検証です――証拠、トレース、そして受理／却下の使い心地なのです。

FAQ

References