ループエンジニアリングとは、コーディングエージェントに一ターンずつ直接プロンプトを与えるのではなく、自分に代わってエージェントにプロンプトを与えるシステムを設計する実践である。通常のエージェント利用では、人が指示を入力し、結果を読み、次の指示を入力する。これに対してループとは、作業を見つけ、それをエージェントに渡し、返ってきたものを確認し、行ったことを記録し、次のステップを決める小さなシステムであり、人はそれを継続的に操作するのではなく、一度設計するだけである。ループエンジニアリングは ハーネスエンジニアリング の一段上に位置するものとして説明される。ハーネスは単一のエージェントが動作する環境を形づくり、ループはそのハーネスをスケジュールに沿って動かし、補助的なエージェントを起動し、自らに新しい作業を供給する。二つ目の説明は、同じ関係をハーネスそのものの観点から述べている。ハーネスとは、モデルそのものを除いた、モデルの周囲にあるすべて、すなわちシステムプロンプト、ツール、権限、コンテキスト管理、検証ループ、ログであり、ループエンジニアリングは、そのハーネスが停止条件やスケジューラーに照らして自律的に動き続けるように設計する、一段上のコントロールプレーンだという。どちらの説明でも、名指しされている転換は同じである。自分でモデルにプロンプトを与えるのをやめ、モデルにプロンプトを与えるループを設計し始める、ということである。
探索的な学術研究である ループエンジニアリング：構成要素、採用、影響 は、実務家の言説を集約して作業上の定義を示している。それによれば、ループエンジニアリングとは、スケジュールまたはイベントを契機としてコーディングエージェントを繰り返し呼び出し、各実行が機械的に確認可能な停止条件によって区切られる、自動化された制御構造を設計する実践である。さらに、よく設計されたループは、実行をまたいで状態を永続化し、実装を担うエージェントとは独立に結果を検証し、推論コストに上限を設け、無人の実行が承認なしに変更できる範囲を制限し、人間が介入すべきタイミングを定める。同研究はその系譜を、関心の単位によって区別される四つの層として整理している。プロンプトエンジニアリング（一つの指示）、コンテキストエンジニアリング（一回のモデル呼び出し）、ハーネスエンジニアリング（一回のエージェント実行）、ループエンジニアリング（繰り返される実行）である。また同研究は、このレベルの反復を、単一の実行の内部にあるエージェントループ、つまりモデルがツールを呼び出してその結果に基づいて行動するという繰り返しのサイクルとは区別している。
用法
ループは、繰り返し現れる五つの部品と、状態を記憶しておく場所から構築される。五つの部品とは、スケジュールに沿って動作して作業を発見・トリアージする自動化、並行して動くエージェントが同じファイルを編集しないようにする Git ワークツリー（それぞれ独自のブランチを持つ隔離された作業ディレクトリ）、エージェントが毎セッションそれを導き直さなくて済むようにプロジェクト固有の知識を記録するスキル、一般に MCP の上に構築され、ループが課題トラッカーやチャットチャンネルといった実際のツールに届くようにするプラグインとコネクタ、そして作業を書く者とそれを確認する者が同一にならないように分けたサブエージェントである。最後の点は、自分の出力を採点するモデルは甘くなりがちだからである。六つ目の部品は外部メモリで、どの会話にも属さずその外側にある Markdown ファイルや Linear のボードがこれにあたる。基盤となるモデルは実行と実行の間ですべてを忘れるため、この状態は代わりにディスク上に置かれなければならない。Codex アプリと Anthropic の Claude Code はいずれも、名前は異なるものの、今ではこの五つの部品をすべて提供していると説明されており、これはループエンジニアリングが、各チームが手作りしなければならないものではなく、製品そのものの性質になったことの証拠として示されている。
コーディング以外の作業での実例が ループエンジニアリング実践：プロンプトチューニングをClaude Codeに任せてみた で報告されている。そこで自動化されているループは、視覚言語モデルのためのプロンプトチューニングである。その構築方法は、人が手作業ですでに行っていたことを分解し、各ステップにそれぞれ専用のコンポーネントを割り当てるものとして述べられている。失敗例を見る、原因を診断する、プロンプトを書き直す、再評価する、何が効いたかを記録する、というステップのうち、再評価は単純なスクリプトが担い、残りはサブエージェントが担う。さらに、純粋にオーケストレーターとして働くスキルファイル、すべてのサブエージェントが従う改善の優先順位・採否のルール・停止条件をまとめた単一のポリシーファイル、そして人間のチューナーの蓄積されていく記憶に意図的に相当するものとして、ループが反復ごとに追記していく教訓ファイルがある。この説明によれば、比較対象が存在した一つのタスクで、自動化されたループは手作業のチューニングと同等かわずかに上回り、それを取り巻く評価サイクルを約 3.5 週間から約 1 週間に短縮した。ただしこれは、繰り返し測定したものではなく一回の実行によるものである。
実務家が管理するパターンライブラリである GitHub 上の cobusgreyling/loop-engineering リポジトリは、この実践に、名前が付いてすぐに導入できるループのカタログを与えている。このリポジトリは自らを「コードベースの周囲でエージェントを運用するための」パターンライブラリと称し、モジュールを書き換えるためのボタンではないと明言している。そして実践を「Stop prompting. Design the loop. Get a score.（プロンプトを与えるのをやめ、ループを設計し、スコアを得よ）」とまとめている。つまり、作業を発見し、それをエージェントに渡し、結果を検証し、状態を永続化するシステムを設計することである。そのパターンには、日次のトリアージ、状態ファイルを持たずに GitHub Actions から実行する薄いループ、プルリクエストの子守り役、CI と依存関係のスイーパー、変更履歴の下書き作成、マージ後のクリーンアップ、課題のトリアージなどがあり、それぞれに実行間隔（5〜15 分ごとから日次まで）と相対的なコストが記されている。各パターンは開始時の自律レベルも指定しており、このライブラリの段階的導入のルールは、検証役が一週間正しく機能した後に限って、L1（報告のみ）から L2（支援付き）、さらに L3（無人）へと進むというものである。そのツールは準備状況を判断する際にディスク上のファイルよりも最近の実行を重視するため、一か月前の STATE.md があっても L3 とはみなされない。CLI（npx @cobusgreyling/loop）は、Claude Code、Codex、Grok、OpenCode 向けにパターンを初期化し、セットアップを確認し、コストを見積もる。リポジトリには、失敗モード、アンチパターン、安全性に関するページが、成功と失敗の両方の事例とともに置かれている。出典として、Addy Osmani の記事（ループエンジニアリング）、メンテナー自身による同名の記事、そして ループエンジニアリング：構成要素、採用、影響 を挙げており、自らがその研究でレビューされたコミュニティのリファレンスであると述べている。このリポジトリ自身の警告は後述のものと一致する。ループエンジニアリングは判断力を増幅する、トークンのコストは爆発しうる、そして無人のループは無人のまま誤りを犯す、というものである。
この実践が実際にどの程度広く採用されているかについての証拠は、同じ研究が行った、エンジニアリングされた 36,710 のオープンソースリポジトリのマイニングから得られている。自律的なエージェントループが確認されたのはそのうち 217 件で、ほぼすべてが GitHub Actions のワークフローによって起動され、大半はスケジュールではなくリポジトリのイベント（典型的には新しく開かれたプルリクエストのレビュー）に応じて動作しており、スケジュール実行のループは主に課題のトリアージだった。これらのループのコミットされた設定は見えていたが、実務家の情報源が推奨する状態ファイルをコミットしていたリポジトリはほとんどなかった。著者らは、確認されたループの大半では、実行間で永続化すべきものが何もなかったか、課題トラッカーがすでにその状態を保持していたと述べている。
適用される場面
この実践が適用されるのは、繰り返し発生する作業や長時間続く作業で、そうでなければ人がサイクルごとにエージェントにプロンプトを与え直し続けなければならないもの、たとえばトリアージ、定期的な発見、無人で続く作業である。前提となるのは、実際に確認できる停止条件（たとえば検証役のモデルによって確認できるもの）と、ループが実行の合間に読み書きできる永続的な外部状態である。基盤となるモデル自体は実行をまたいで何も保持しないからである。ループがうまく回るようになった後も、検証は人間の責任であり続けると説明されている。無人のループはやはり無人のまま誤りを犯すし、この実践は他の二つの問題を解決するのではなく、むしろ深刻にすると述べられている。ループが生み出すものを読まなくなれば、出荷されたコードに対する人の理解はより速く劣化しうるし、うまく回っているループは、その出力を無批判に受け入れる誘惑を生みうる。ループエンジニアリングは、他の実務家が独立に述べてきた実践の統合として提示されている（Peter Steinberger と Boris Cherny はいずれも、エージェントに直接プロンプトを与えるのではなくループを設計する方向への同じ転換を語った言葉が引用されている）。上に挙げた五つの部品の列挙は Steinberger によるもので、著者自身の貢献は、それを Codex アプリと Claude Code の両方に対応づけ、各部品を順に検討した点にある。
プロンプトチューニングの事例は、独自の注意点を二つ加えている。いずれも、うまく動いているときに無人のループが何をするかに関するものである。一つ目は、各反復でデータセット全体に対して推論をやり直したため API の料金がかさんだことで、設計の悪いループはバックグラウンドで推論を続け、予想外にコストを押し上げかねないと指摘し、変更はまず小さなサンプルで試し、その結果に見込みがある場合に限ってデータセット全体で評価することを勧めている。二つ目は、ループは採点の基準となるものに向けて最適化を行うため、精度が上がるにつれて編集対象の成果物がどんどん長くなっていったことである。この説明は、最も注意深く監視した対象として過学習を挙げ、その理由として、文言が学習データに寄れば寄るほど過学習のリスクが高まると述べ、最低限テスト用のデータ分割を取り分けておくことを勧めている。
この実践がどれほど新しいものかについては、議論が分かれている。同研究がレビューした言説の中では、批判者はループを名前を変えただけの cron ジョブ、あるいは非決定的なワーカーを使ったイベント駆動の自動化だと評する一方、明示的なループは、繰り返し実行や目標駆動のコマンドといったツールの組み込み機能に吸収されていくと予想する者もいる。同研究自身の読みは、両方の立場をそれぞれ部分的に支持している。スケジューラー、イベントトリガー、自己管理型の制御ループはこの用語よりも前から存在しており、同研究が新しいとみなすのは開発者の実践としての採用である。すなわち、非決定的なワーカーを自然言語による目標条件と検証に支配された終了判定の背後に置くことであり、これによってエンジニアリングの労力は、ガードレール、予算、検証役、エスカレーション方針でそれを制約することへと移る。同研究はまた、主張されている利点は主に自己申告と逸話に基づいていること、レビューした情報源は暴走するコスト、終わらない修正ループ、実際の確認をせずに承認してしまう検証役といった失敗モードを列挙していること、そしてそれらの情報源に共通する段階的導入の助言、すなわちまず独立した検証ステップを設計し、次に報告のみの運用から無人の運用へと移るという助言は、著者らの知る限り検証されていないことを報告している。
関連用語
プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング、エージェントハーネス、サブエージェントアーキテクチャ、Claude Code