本論文は、ループエンジニアリング を実務家の用語から、実証的な裏付けを持つ研究対象へと移すことを目指している。本論文はこの用語を、開発者がエージェント型コーディングツールを指示するやり方の変遷の終着点に位置づける ── 単一の指示の言い回し（プロンプトエンジニアリング）から、1 回の呼び出しでモデルが目にするすべてのもの（コンテキストエンジニアリング）、そして 1 回のエージェント実行の周囲に構成される仕組み（ハーネスエンジニアリング）へ。そして、実務家の言説で特徴づけられているとおり、ループエンジニアリングをハーネスより 1 段上の抽象化レベルとして説明する。ハーネスが 1 回のエージェント実行を装備するのに対し、ループは時間をまたいだ多数のそうした実行を統御し、何が各実行を開始するか、その結果をどのように検証し永続化するか、いつ人間にエスカレーションするかを決める。
この用語は実務家によってわずか数週間前に作られたばかりだったため、著者らはまずグレーリテラチャー（ブログ記事、ニュースレター、ディスカッションスレッド、コミュニティのリポジトリ、自費出版の総括ノート）をレビューし、それを作業定義にまとめた。ループエンジニアリングとは、スケジュールまたはイベントを契機として、コーディングエージェントを繰り返し呼び出す自動化された制御構造を設計する実践であり、各実行は機械的に検査可能な停止条件によって区切られる。よく設計されたループはさらに、実行をまたいで状態を永続化し、実装を担うエージェントとは独立に結果を検証し、推論コストに上限を設け、無人の実行が承認なしに変更できる範囲を制限し、人間が介入すべきタイミングを定める。続いて著者らは、36,710 のエンジニアリングされたオープンソースリポジトリからなる既存のサンプルを、コミットされたループのアーティファクトと Git 履歴上のシグナルを求めてマイニングし、ヒューリスティクスに合致したすべてのリポジトリを手作業で検証した。さらに、ジャーナル拡張版に向けて計画しているエージェントの自律性レベルに関する対照実験についても述べている。
中心的な発見は、ループがすでにオープンソースプロジェクトで稼働しており ── 大半はプルリクエストのレビューと定期的なイシューのトリアージのため ── その設定はコミットされた痕跡を残す一方、実行時の状態は残さないということである。実務家の情報源が規定する状態ファイルをコミットしているリポジトリはほぼ皆無だった。
主なポイント
- 本論文は、AI コーディングエージェントを指示する 4 つの層を、それぞれが扱う単位によって区別している。プロンプトエンジニアリング（1 つの指示）、コンテキストエンジニアリング（1 回のモデル呼び出し）、ハーネスエンジニアリング（1 回のエージェント実行）、ループエンジニアリング（繰り返される実行）であり、各層は前の層を包含する。ここでのハーネス層は、ユーザーがエージェントの上に組み立てる外側のハーネスを指す。
- レビューの結果、実務家による定義は 1 つの核心に収束していることがわかった。開発者はエージェントが次に何をするかを決めるのをやめ、代わりにそれを決めるシステムを設計する、というものである。
- レビューした情報源は、よく設計されたループの構成要素についておおむね一致している ── トリガーと停止条件、コンテキストウィンドウの外にある永続的な状態、エンコードされたプロジェクト知識（スキル）、並列作業のための分離、実装者から切り離された独立の検証者、外部システムへのコネクター、実行中のループを一時停止する手段を伴う予算、無人の実行が変更できる範囲に対する拘束的な制約、そして定義されたエスカレーションポイントである。ただし著者らは、これらの情報源は互いに独立していないため、その一致の多くは 1 つの起源にさかのぼると指摘している。
- 作業を行うエージェントと独立した検証者との分離（「maker/checker」分割）は、レビューした情報源で最も強調されている構成要素とされている。
- この実践の新規性は、レビューした言説の中で争われている。批判者はループを名前を変えただけの cron ジョブやイベント駆動の自動化だと評しており、著者らは、ループエンジニアリングが新しい分野なのか、過渡的な技法なのか、マーケティング上のラベルなのかについて、言説はまだ決着していないと結論づけている。
- 主張される利点は大きいものの、自己申告と逸話に基づいている。本論文は、言説の中で流布している最も大胆な数値を裏付ける公表済みの研究やデータセットを、著者らの知る限り 1 つも見つけていないと述べている。
- 失敗モードはレビューした情報源で網羅的に記録されており、コストの暴走、終わりのない修正ループ、実際の検査を行わずに承認する検証者（「検証者の芝居（verifier theater）」）、通知疲れ、ループのコミットされた指示とその状態との乖離などが含まれる。無人の実行はチームがレビューできる以上のプルリクエストを開きうるため、レビュー能力が実際上のボトルネックとされている。
- マイニング研究では、条件を満たすエージェントを呼び出すスケジュールまたはイベントのトリガーが、スキャンした 36,645 のリポジトリのうち 253 で見つかり、記録されたトリガーの出現は 1 件を除いてすべて GitHub Actions のワークフローだった。
- 手作業による検証の結果、256 の候補リポジトリのうち 217（スキャンしたリポジトリの 0.59%）で自律的なエージェントループが確認され、不明瞭なラベル 6 件を除いたヒューリスティクスの適合率は 0.868 だった。そのうち 21 はスケジュールのみ、180 はリポジトリイベントのみ（大半はプルリクエストの自動レビュー）、15 は両方で動作していた。
- スキャンしたすべてのリポジトリを通じて、本研究の状態ファイル基準を満たすファイルは 2 つしか見つからず（どちらも精査の結果、「loop」という語の無関係な用法として除外された）、固定されたルールのもとでは、コミットされた停止条件、予算ファイル、ループの検証者サブエージェント、測定値を含むコストログは 1 つも見つからなかった。著者らはこれを、ループの状態がバージョン管理に存在しないか、別の場所 ── 多くの場合はイシュートラッカー ── に保持されていることを意味すると解釈している。
- 確認されたツールの帰属は Claude Code が大半を占め（217 のうち 189）、OpenAI Codex、OpenCode、Gemini CLI、Cursor、GitHub Copilot が続いた。
- ワークフローの実行が成功したことだけでは、エージェントが実行された証拠としては弱いとされている。アーカイブされた履歴では、成功と記録された実行のうちいくつかは、エージェントのステップが一度も実行されないまま終了していた。
補足
本論文は、同じグループによるハーネス設定メカニズムについての先行する探索的研究 エージェント型 AI コーディングツールのためのハーネスエンジニアリング：探索的研究 を土台としている。本論文によれば、その分類体系にはエージェントがいつ、どのくらいの頻度で実行されるかを統御するメカニズムが含まれておらず、本研究はそのギャップに取り組み始めるものである。計画中の実験は 3 つの条件（エージェントの対話的な利用、機械的に検査可能な停止条件を伴うゴール駆動の実行、スケジュールされたループ）を比較し、停止条件を委ねることの効果と、繰り返しの効果を別々に測定できるようにする。
著者らはいくつかの限界を挙げている。文献レビューは網羅的ではなく解釈的なものであり、その情報源は、数週間前に始まったばかりで少数の目立つ声に支配された言説を追いながら 1 人の著者が選んだものである。256 のリポジトリのラベルは、独立したダブルコーディングではなく、LLM によってアノテーションされ 1 人の著者が裁定したものである。マイニングは公開のオープンソースリポジトリと 8 つのツールだけを対象としているため、社内でのデプロイ、プラットフォーム固有のスケジューラー、動的に作成されるワークフローは痕跡を残さない。また、リポジトリがスキャンされたのはこの用語が作られてから約 10 週間後であり、この実践が広まる時間はほとんどなかった。本論文は、LLM ベースのエージェントが文献検索とリポジトリの証拠のアノテーションを支援し、最終著者がその結果を確認・裁定したことを開示している。