ループエンジニアリング入門。プロンプトを打つ人から、AI を動かす仕組みを設計する人へ

28 年 crond を触ってきた人間が考えた、エージェントループと cron の本当の違い。

Claude Code のウィンドウを 5 枚開いて、順番に指示を出して回る。CI が落ちるたびに人間が見に行く。レビューコメントが来るたびに、同じ説明を繰り返す。AI は速いのに、人間が監督席から離れられない。この働き方に疲れはじめた人へ向けて書きます。

この状態を一言で言うと、人間がループの内側にいる、です。指示を出し、結果を読み、次の指示を出す。その繰り返しの輪の中に、あなた自身が部品として組み込まれています。ループエンジニアリングとは、この輪の外へ出るための設計のことです。

2026 年 6 月、「もうエージェントにプロンプトを打つな。エージェントにプロンプトを打つループを設計しろ」という Peter Steinberger のツイートが 220 万ビューを超えて広まり、リプライ欄では「それはただの cron ジョブでは」という言い合いが起きました。crond に 1998 年から触れてきた身として、この論争を調べて出した結論を先に書きます。

ループは、中身に判断が入った cron です。

そしてループエンジニアリングとは、AI を何度も呼び出すことではありません。目標の状態を決め、現在との差を観測させ、次の行動を選ばせ、結果を検証し、安全に止める仕組みを設計することです。本記事では、その設計に使う 6 つの部品と、今日 30 分で試せる報告だけのループを紹介します。

結論。新しいのは繰り返しではなく、毎周の判断です

結論を分解しておきます。ループの構造そのもの、つまり同じ処理を繰り返す枠組みは、何も新しくありません。新しいのは、毎周の中で行われる判断、検証、記憶を、人間が書いた固定のコードではなくモデルが担当するようになったことです。すると人間の仕事は、指示を出し続けることから、目標、観測、検証、停止条件を設計することへ移ります。

移った先の仕事を具体的に言うと、こうなります。この作業の完了を、どのコマンドの戻り値で判定するか。エージェントにどのログとどのダッシュボードを見せるか。できたという判定を誰にやらせるか。何周、いくらまで走らせて、どうなったら止めるか。プロンプトの言い回しを磨く時間が、この 4 つの問いに答える時間に置き換わります。どれも、運用設計をやってきた人には見覚えのある問いのはずです。

この移り方を実際にやって見せているのが、Claude Code を作った Boris Cherny です。2026 年 6 月のイベントでこう語っています。

「わたしはもう Claude にプロンプトを打ちません。ループが走っていて、そのループが Claude にプロンプトを打ち、何をすべきかを判断しています。わたしの仕事はループを書くことです」

数字も出ていて、2025 年 12 月の時点で、直近 30 日の Claude Code への貢献は 100 % が Claude Code 製、マージしたプルリクエストは 259 本と本人が報告しています。ただし、この数字を見るときは中身が大事です。彼が名前を挙げて回しているループは、プルリクエストの子守、CI の健全性の維持、フィードバックの定期的な整理。どれも終了状態を機械で確認できる、言ってしまえば掃除仕事です。新機能を無人で作らせてはいませんし、エンジニアが不要になるとも言っていません。何を作るか決め、ループが何を目指すべきかを決める仕事は残る、と明言しています。

最小のループは、観測して報告するだけでいい

歴史の話に入る前に、いちばん小さい実物を見てください。Claude Code なら 1 行です。

/loop 5m デプロイが終わったか確認して、結果を報告して

5 分ごとに状況を見て、終わったら教えてくれる。それだけのループです。間隔を省けば、状況に応じて 1 分から 1 時間の間で Claude が自分で決めます。ビルドの完了が近そうなら短く、待ちが長そうなら長く、といった具合です。

ほかの例も挙げます。

/loop 30m CI が落ちていたら原因を調べて、修正案だけを報告して。コードは変更しないで

/loop 1d 依存パッケージの更新候補を調べて、影響範囲つきでプルリクエストの下書きを作って

共通点は、何も書き換えないか、書き換えても下書き止まりであることです。観測して報告するだけ。それでも受け取るものは変わります。CI が落ちたことを自分で見つけに行く朝と、失敗したジョブ名と原因の分類と次の一手の案が整理されて届いている朝。作業量は同じでも、監督席に縛られる時間が違います。人間がループの内側にいる状態から外へ出る、という冒頭の話は、まずこの粒度で実現します。

ループと聞くと、何十のエージェントが夜通しコードを書く巨大な自律開発システムを想像しがちですが、それはこの技術のいちばん派手な端っこにすぎません。入口はデプロイの見張り番で十分ですし、後で書くとおり、入口はそこであるべきです。

cron は「いつ」を決め、「何を」は決めなかった

ここで冒頭の論争に答えます。ただの cron ジョブでは、という指摘です。

cron の来歴を短く押さえます。1979 年の Version 7 Unix で生まれた最初の cron は、毎分律儀に起き上がって設定ファイルを読み直す作りで、「ああ、無頓着なアルゴリズムだね」と大学教授に評され、次のジョブの時刻まで眠って待つ方式に作り直されました。1987 年には Paul Vixie がユーザーごとの crontab を持つ Vixie cron を公開し、今わたしたちが知る 5 つのフィールドの形が固まります。以来 39 年、cron が磨いてきたのは「いつ走るか」の 1 点だけです。走った先で何をするかは常に人間のスクリプトに固定されていて、分岐があるとしても、それは事前に書かれた if 文でした。cron は、何が必要かを一度も判断したことがありません。

面白いのは、Claude Code の /loop の足元です。公式ドキュメントに、標準的な vixie-cron の文法に従う、と明記されています。/loop は内部で指示を 5 フィールドの cron 式に変換して登録します。つまり時刻を管理する層は、比喩ではなく文字どおり cron のままです。懐疑派は、ここについては完全に正しい。Docker の創業者 Solomon Hykes が「AI エージェントとは、ループの中で環境をめちゃくちゃにしている LLM のことだ」と言ったのも、構造の指摘としては当たっています。

違うのは中身です。並べて書きます。

cron は、実行時刻を決めます。実行内容は人間が事前に固定します。判断は、あらかじめ書かれた if 文が行います。

エージェントループは、起きたら現在の状態を読み取ります。目標との差を判断します。次の行動を選びます。結果を検証します。そして続けるかやめるかを決めて、必要なら次の周回へ進みます。

構造は古く、中身が変わった。だから、中身に判断が入った cron です。

同じ仕事で書き比べると、違いがはっきりします。依存パッケージの更新を cron でやるなら、毎週月曜の朝に更新コマンドとテストを走らせ、失敗したらメールを飛ばすスクリプトを書きます。失敗の後始末は人間です。ループでやるなら、目標を「テストが通る状態で依存が最新になっていること」と書き、失敗したらエージェントがログを読み、原因を切り分け、あるパッケージだけ更新を見送る判断をし、その理由を添えたプルリクエストを作ります。月曜の朝に届くのが、赤いメールか、理由つきの下書きか。この差が、if 文とモデルの差です。

かつて serverless は CGI の再発明だと言われ、コンテナは chroot だと言われました。構造の指摘としてはどちらも当たっていて、それでも使われ方は別物になりました。古い構造の中身が入れ替わったとき、古いと切り捨てると見誤ります。

ループを組み立てる 6 つの部品

ではその「中身」をどう設計するか。調べた実践例を整理すると、ループは 6 つの部品でできています。ここが本記事の中心です。

ひとつめは Goal。目標の状態と終了条件です。「コードをきれいにする」は目標になりません。「npm test が exit 0 になり、git status に未処理の変更がない」のように、機械で白黒つく形で書きます。Claude Code の /goal はこの部品を製品にしたもので、/goal 全テストが通ること。or stop after 20 turns のように、終了条件と周回上限をひとまとめに宣言できます。条件を数値やコマンドで書けるほど、ループは自分で自分を確かめやすくなります。

ふたつめは Observe。現在の状態を確認する手段です。テストの結果、CI の状態、GitHub の Issue、ログ、差分、ファイルの有無。ループは毎周ここから始まります。観測の手段が貧しいループは、判断の材料が貧しいループです。人間のエンジニアに新しい環境を渡すとき、ログの場所とダッシュボードを最初に教えるのと同じで、エージェントにもどこを見ればいいかを設計して渡します。

みっつめは Act。現在と目標の差を縮めるためにエージェントに許す行動です。修正、調査、プルリクエストの作成、コメント、再実行。どこまで許すかは権限の設計そのものです。読むだけ、下書きまで、限定的な修正まで、と段階があり、どの段階から始めるかは後の失敗例の節でそのまま答えが出ます。

よっつめは Verify。終わったかどうかを判定する仕組みです。できれば、作業したモデルとは別のモデルか、決定的なテストで判定します。/goal の内部では、本体とは別の小さくて速いモデルが 1 ターンごとに条件の充足だけを独立に判定していて、判定役はコードを書き換えられません。見せるのはテスト結果や差分といった動かぬ証拠だけ。この分離の理由は後述します。

いつつめは Persist。周回をまたいで残す状態と学びです。会話の履歴に頼らず、計画、仕様、学んだこと、失敗の理由をファイルや Issue に保存します。ループは記憶を持ちませんが、ファイルは残ります。後で紹介する ralph ループでは、計画を fix_plan.md に、正しかった手順を AGENT.md に書き戻させていて、ファイルが周回をまたぐ申し送りノートの役を果たします。

むっつめは Guard。暴走を防ぐ停止条件です。最大周回数、最大費用、最大トークン量、連続失敗の回数、差分が出ない周回の回数、触ってよいファイルの範囲。これらはモデルの外に、ただのカウンターとして置きます。止める判断までモデルに任せると、ループは自分で自分を説得して走り続けるからです。暴走対策をスクリプト本人の良心に任せた運用者が過去にいなかったのと同じ理屈です。

この 6 つが書けない仕事は、まだループに載せる段階ではありません。逆に 6 つが書けるなら、その仕事はもうループに載ります。

見覚えのある部品ばかりだと感じたなら、その感覚は正しいです。時刻の管理は cron がやってきたことで、Verify は CI がやってきたことです。Observe は監視とダッシュボードの設計で、Persist は障害対応の申し送りや手順書の文化で、Guard はレート制限やサーキットブレーカーの発想です。ループエンジニアリングという名前は新しくても、部品の 1 つ 1 つは、運用の現場が何十年もかけて育ててきた道具の言い直しです。ゼロから覚える技術ではなく、手持ちの経験を並べ直す技術だと捉えたほうが、実態に合っています。

系譜は年表ではなく、設計原則として読む

この 6 部品は、誰かが頭の中で考え出したものではなく、4 年分の試行錯誤から残ったものです。出来事を並べるのではなく、それぞれから何を設計に持ち帰るべきかを書きます。

2022 年の ReAct 論文は、考えて、道具を使い、結果を読み、繰り返すという型を定式化しました。持ち帰るのは型そのものです。Observe と Act の交互運転は、ここで発明されました。

2023 年の AutoGPT は、ゴールを与えて自走させる需要を証明し、同時に、止まり方を知らないループは何もしないまま回り続けることも証明しました。持ち帰るのは Guard の必然性です。エージェントはおもちゃだという数年分の空気は、Guard を欠いた設計への評価だったと今なら分かります。

2025 年 7 月、Geoffrey Huntley が公開した ralph ループは、bash の 1 行です。

while :; do cat PROMPT.md | claude-code ; done

同じプロンプトファイルを流し込み続けるだけ。ただし周りの決まりごとに発明があります。会話を伸ばさず、毎周、計画の fix_plan.md と仕様の specs/ を読み直すところから始める。1 周につき 1 つの仕事しかさせず、何が大事かの選択までモデルに任せる。学んだ手順は AGENT.md にモデル自身が書き戻す。Huntley はこの方式で、5 万ドル相当の開発契約を 297 ドル分の API 利用料で納品したと報告しています。ただし本人がはっきり条件を付けていて、既存のコードベースには絶対に使わない、まっさらな新規開発を 9 割まで持っていく技術だ、と言っています。数字に飛びつく前に、この適用条件のほうを持ち帰るべきです。

実戦投入の記録もあります。2025 年 8 月の YC ハッカソンで、あるチームが claude -p --dangerously-skip-permissions を while ループで回し、一晩で 1,000 を超えるコミットを生み、Python 製のライブラリを TypeScript へほぼ移植し終えました。API 代は 600 ドルほど。-p は画面なしで動かす指定、--dangerously-skip-permissions は 1 回ごとの人間の承認を飛ばす指定です。名前に dangerously と入っているとおり確認を全部外す宣言なので、隔離された環境で回すことと引き換えの速度でした。600 ドルという数字も、承認という Guard を 1 枚外した対価として読むべきです。

ralph から持ち帰る原則は 4 つです。長い会話より、毎周同じファイルを読む。1 周で 1 つの仕事に集中させる。学びをファイルに残して次の周回へ渡す。そして、新規開発と既存システムでは許容できるリスクがまったく違う。

現在の最前線は、ループがループを監督する段階です。Steve Yegge の Gas Town は、元締めのエージェントが 20 から 30 の Claude Code を統率する実験で、変更を量産する使い捨てのワーカー、マージ待ちの列を 1 件ずつさばく係、ワーカーがさぼっていないか見張る係、といった役割分担があり、状態はすべて git に保存されるので途中でプロセスが落ちても作業が残ります。作者自身が本番で使うなと警告している実験段階のものですが、検証者の報告では 1 時間あたりおよそ 100 ドルかかります。この数字が教えるのは、並列数を増やす判断には、処理の速さだけでなく監督と統合の費用を含める必要がある、ということです。もっと大きい例では、GitButler の Scott Chacon が Git を Rust で書き直す実験を並列エージェントでやり、2 から 3 週間で 36 万行、費用は 1 万から 1 万 5 千ドル、消費トークンは約 450 億でした。本人の振り返りが実務的で、タスクの範囲を狭くすればトークンは減る、エージェント間の調整の手間は数に比例では済まない、共有のチェックリストファイルは取り合いになるから調整は GitHub Issues のような安定した場所でやれ、と書いています。

監督型から持ち帰る原則も 4 つ。ワーカーを増やすほど統合と監督の費用が増える。並列数は生産性ではなく競合とマージの費用で決める。共有ファイルを複数エージェントに同時に触らせない。状態の保存先は安定した外部システムに置く。

向いているのは、安く機械で検証できる仕事

6 部品の Goal と Verify が書けるかどうかで、仕事は自然に二分されます。

向いているのは、CI の修復、依存パッケージの更新、lint や型エラーの解消、形式の決まったコード移行、デプロイ状況の監視、レビューコメントの分類、再現手順のあるバグの修正、形式の決まったドキュメントの更新。どれも、成否をコマンドの戻り値や数値で判定でき、判定が安い仕事です。CI の修復が筆頭に来るのは偶然ではなく、CI そのものがすでに検証器だからです。目標は「全部緑」、観測は実行結果、判定は機械。6 部品のうち 3 つが最初から揃っています。

向いていないのは、終了条件が曖昧な新機能の開発、プロダクトの方向を決める仕事、顧客の要望を解釈する仕事、セキュリティ上の影響が大きい変更、自動テストのない基幹システムの変更、失敗したら巻き戻せない作業、そして「いい感じにする」としか言えない仕事です。技術的にできるかどうかではなく、Goal と Verify が書けない、Guard を置いても失敗の被害が戻せない、という部品の欠けで判断しています。テストのない基幹システムが不向きなのは、モデルの能力の問題ではなく、検証器が存在しない環境だからです。

線を引く基準は、自動化できるかではありません。安く、機械的に検証できるか、です。Cherny のループが掃除仕事に徹しているのは、最前線の本人がこの線を守っているからだと、わたしは読んでいます。

失敗例は、そのまま設計チェックリストになる

調査で集まった事故は、怖い話として読むより、対策と 1 対 1 で対応させたほうが役に立ちます。

壊れたツールを 5 分で 400 回呼び続け、レート制限に達したループがありました。対策は、同じ失敗が 3 回続いたら止める、です。周回数の上限が 3 なら初回で止まっていた事故でした。

モデル同士の確認合戦という失敗もあります。2 つのモデルに「相手に確認してから出力せよ」と指示したところ、60 往復の確認だけが続き、有用な出力はゼロだったという実験の記録があります。被害額は 0.16 ドルで済みましたが、進んでいないのに止まらない、という構図は 400 回の事故と同じです。対策は、失敗回数ではなく進捗のなさを数えること。差分が出ない周回が続いたら止める、という条件を Guard に入れておきます。

テストを通すために、モデルがテストのほうを書き換えた例があります。対策は、変更禁止のファイルを決めて、差分に含まれたら不合格にする、です。日本語圏の検証記事で実際に効くことが確認されています。

エージェントが自分の作業を甘く採点する問題があります。海外の実践者の言い回しを借りると、コードを書いたモデルは、自分の宿題を採点するには優しすぎる。対策は、実行役と判定役を分離する、です。Claude Code の /goal はこれを製品に組み込んでいて、終了条件を満たしたかどうかを、本体とは別の小さなモデルが 1 ターンごとに独立に判定します。判定役には書き換えの権限を渡さず、テスト結果や差分という動かぬ証拠だけを見せます。

費用が想定を超えて膨らむ問題があります。Uber では社内 5,000 人のエンジニアの Claude Code 利用率が数か月で 32 % から 84 % に跳ね、年間の AI 予算を 4 か月で使い切り、1 人 1 ツールあたり月 1,500 ドルの上限が入りました。浪費を加速させた一因として、社内で使用量の順位表を作って競わせていたことが報じられています。使った量を成果のように扱えば、使う量は増えます。Simon Willison はこの上限を、順位表よりずっとまともな対応だと評しました。持ち帰るべきは金額そのものではなく、上限がモデルの外側の、組織のルールとして置かれたことです。周回数、金額、トークン量の上限は、ループの中の良心ではなく外側のカウンターに担当させます。

自動マージで壊す問題があります。Gas Town の検証中、統合テストが落ちているプルリクエストをループが勝手にマージし、reset --hard と force push で復旧した記録が公開されています。対策は、段階的な権限付与です。最初は報告だけ、次にプルリクエストの作成まで、その後に限定的な自動修正へ。マージの権限は最後まで渡さないくらいでちょうどいいと思います。

並べて分かるとおり、どの対策も新技術ではありません。回数を数える、触ってよい範囲を決める、作った本人に検査させない、予算を切る、権限を段階的に渡す。組織とシステムを守るために使ってきた手立てを、エージェントという新しい働き手に適用し直しているだけです。失敗例を読んで怖くなったら、それは Guard の設計材料が 1 つ増えたということです。

ループの価値は、回数ではなくスキルで決まる

同じ推論を毎周ゼロからやり直すループは、回すたびに同じだけお金を燃やします。一度成功した手順を、スキル、コマンド、チェックリスト、ルールファイルとして保存すれば、次からは安く、速く、安定して動きます。

流れはこうです。人間が作業する。手順を言語化する。エージェントに実行させる。失敗から手順を直す。スキルとして保存する。ループから呼び出す。保存の形は大げさでなくてよく、Claude Code ならスキルやスラッシュコマンドのファイル、素の構成ならリポジトリに置いた手順書のマークダウンで足ります。/loop 20m /review-pr 1234 のように、育てたコマンドをそのまま定期実行に載せられるので、スキルの置き場所とループの入口が最初からつながっています。

実例もあって、あるエンジニアはループにコーディング規約のファイルを 30 分で書かせ、今度はその規約に合わせろという指示でループを回し直し、6 時間でコードベース全体の体裁をそろえました。規約という再利用できる資産を先に作ったから、2 度目からは指示が 1 行で済んだわけです。

これは費用の話であると同時に、理解の話でもあります。Google の Addy Osmani は、システムに存在するコードの量と人間が実際に理解している量の差を、理解の借金と呼びました。ループを回すほどコードは増え、放っておけばこの差は開きます。手順をスキルとして言語化することは、この借金の返済でもあります。ループに蓄積される本当の資産は、実行回数ではなくスキルの束です。

最初のループは、報告だけでいい

ここまでの原則を、今日の 30 分に落とします。手順は 5 段階です。

毎日か毎週、繰り返し確認している作業を 1 つ選びます。CI の失敗確認、デプロイの見張り、依存の更新チェック、エラーログの分類あたりが定番です。選んだら、その完了や異常を、コマンドや数値で判定できる形にします。判定の書き方に詰まったら、その作業を同僚に引き継ぐときのチェックリストを想像してください。人間に引き継げない仕事は、ループにも引き継げません。エージェントには変更の権限を与えず、確認と報告だけをさせます。最大 3 周、または少額の費用上限を設定します。そして 1 週間分の結果を見てから、次の権限を渡すかどうかを決めます。

書き起こすと、たとえばこうなります。

目的: CI の失敗を早く把握する
観測: GitHub Actions の最新の実行結果を確認する
行動: 失敗原因を分類し、関連するログを要約して報告する
検証: 報告に、失敗したジョブ名、エラー箇所、推奨する次の一手が含まれている
停止: 成功していれば終了。同じエラーが 3 回続いたら終了。費用が上限に達したら終了
権限: コードの変更、push、merge は禁止

Goal、Observe、Act、Verify、Guard が 6 行に収まっています。Persist が要るほどの仕事ではないので省いていますが、周をまたいで学ばせたくなったら、気づいたことをファイルに書き足させれば足ります。これを /loop に載せるか、GitHub Actions の定時実行から claude -p を呼ぶ形にするかは好みです。後者なら、手持ちの CI と cron の知識がそのまま使えますし、権限の管理もリポジトリの設定に寄せられます。

1 週間の観察で見るのは 3 点です。報告は正確だったか。誤検知や見当違いの要約はどのくらいあったか。そして、自分がその報告をどれだけ信用して動けたか。この 3 点が良ければ、次はプルリクエストの下書きまで権限を広げます。悪ければ、観測の手段か判定の条件を直します。権限は、測ってから渡すものです。

最初から完全な自動化を目指さないでください。報告だけのループでも、朝いちばんに CI の状況が整理されて届くだけで、監督席に座り続ける時間は目に見えて減ります。焦って権限を渡す理由は、どこにもありません。

柵を先に作ってから、ループを回す

まとめは未来予測ではなく、手順で締めます。

最初からコードを書き換えさせる必要はありません。機械で確認できる仕事を 1 つ選びます。終了条件と停止条件を先に書きます。報告だけのループを 1 本動かします。ループの中身より先に、柵を作ります。

1998 年に crontab を覚えたとき、5 つのフィールドの次に教わったのは、失敗したら知らせて止まるようにしておけ、でした。止まり方を設計してから動かすことを、わたしたちは夜間バッチと CI の運用で何十年も練習してきました。ループエンジニアリングで新しく覚えることは、思っているより少ないはずです。cron が 47 年守ってきた「いつ」の管理に、目標と観測と検証と停止の設計を足す。それが、プロンプトを打つ人から、AI を動かす仕組みを設計する人への移り方です。