AI / LLM

ループエンジニアリングの難所は「回し方」ではなく「止め方」— 108ラウンドの実測が示したもの

AIエージェントループエンジニアリングClaude CodeコードレビューLLM

はじめに

エージェントを自律ループで走らせる話は、2026年前半にかなり整理された。プロンプトを打つ人間を仕組みで置き換える——この考え方に「ループエンジニアリング」という名前が付いてから、2ヶ月ほどが経っている。

そして8月に入り、日本語圏でも実践レポートが上位に並ぶようになった。はてブ381を集めた実践記録では、Maker-Checker構成でエラー検知から修正までを回し、実際にバグを1件見つけている。ループは、もう概念ではなく手を動かす対象になった。

ただし同じ日、まったく別の角度からの記事も出ている。運用手順書を2つのLLMに108ラウンドかけてレビューさせ続けた実測記録だ。結論を先に言うと、108ラウンドを通して、2つのモデルが同時に「指摘なし」になった回は一度もなかった。ループは回る。問題は、放っておくと止まらないことのほうにある。

ループエンジニアリングとは何を指すのか

この用語を名付けたのは、Google Chrome のエンジニアリングリードである Addy Osmani だ。起点は Peter Steinberger（PSPDFKit / Nutrient 創業者）の主張——「本当のスキルはエージェントにプロンプトを打つことから、エージェントのループを設計することに移った」——であり、Osmani はその翌日にエッセイとして構造化した。

Osmani が挙げる構成要素は5つある。

  1. Automations — スケジュール実行で、発見とトリアージをエージェント自身にやらせる
  2. Worktrees — 並行して動く複数エージェントが互いを踏まないようにする
  3. Skills — エージェントが推測で埋めてしまうプロジェクト知識を、明文化して渡す
  4. Plugins and connectors — 既存のツール群にエージェントを接続する
  5. Sub-agents — 一方が案を出し、別の一方がそれを検証する

これに加えて、会話の外に進捗を残す永続メモリ（Markdown ファイルや Linear ボード）が6つ目の要素として挙げられている。Claude Code と Codex は、2026年半ばの時点でこの5つを一通り備えている。

問われているのは「どう指示するか」ではなく、**「エージェントが自分で仕事を見つけ、実行し、検証し、やったことを記憶するために、どんなシステムを組むべきか」**である。人間はループの中ではなく、ループの外側の設計者に移動する。

実践側：役割分離を「お願い」ではなく「権限」で保証する

前述の実践レポートで一番効いているのは、Maker と Checker を分けたことそのものではなく、分離を権限で強制した点だと読める。

構成はこうだ。Maker が Cloud Logging からエラーを検知し、原因を調べ、修正を当てる。Checker はその判定を独立したコンテキストで再検証する。ここで Checker サブエージェントには Write / Edit ツールを与えない。検証しかできない状態を、プロンプトの言い回しではなくツール構成のレベルで作っている。

これは自己採点バイアスへの対処として素直だ。「客観的にレビューして」と書いても、同じコンテキストで自分の修正を評価する限り、承認方向のバイアスは残る。ツールを外せば、その選択肢が物理的に消える。

もう一つ、記事が本質的価値として挙げているのが性質判定のステップである。ログに出たエラーがすべてバグとは限らない。入力バリデーションが正しく弾いた結果のエラーは想定内の異常系であり、修正対象ではない。「エラーを検知したら直す」という素朴なループは、正常な防御機構を壊しにいく。バグと判定した場合にのみ修正フローへ進む、という分岐が挟まっている。

実際に検出したバグも紹介されている。仕様は半角数字のみ許可だが、実装は Python の str.isdigit() を使っていた。このメソッドは全角数字も True を返す。修正は isascii() との組み合わせ。仕様書とコードの突き合わせでしか見つからない種類の欠陥で、ループの検証側が機能したことの証拠になっている。

実測側：ループが収束しないのは「修正のせい」ではなかった

では、そのループはいつ止まるのか。

108ラウンドの実験は、運用手順書を2つのLLMに繰り返しレビューさせ、指摘を検証して修正し、また同じ2つにレビューさせるサイクルを回したものだ。素朴な仮説は「edit drift」——修正が新しい欠陥を生み、それがまた指摘され、だから終わらない、という筋書きである。

最初に見えた数字は、その仮説を支持しているように見えた。編集した節が次のレビューで指摘される確率は59.2%、編集していない節は19.5%。差は39.7ポイントある。

ここから著者は交絡因子を2つ剥がしていく。

比較方法編集あり編集なし差
全節まとめて59.2%19.5%+39.7pt
同じ節内で比較45.4%30.4%+15.0pt
同じ節＋前回の指摘有無を揃える56.3%56.3%0.0pt

1つ目の交絡は「もともと指摘されやすい難しい節ほど、編集回数も多い」。同一節内で比較すると差は15.0ポイントまで縮む。2つ目は「前回すでに指摘された節ほど、今回も編集されている」。この条件を揃えると、差は0.0ポイントになる。

指摘内容の分類も同じ方向を向いている。編集した節を指す60件のうち、「今回の変更そのものが問題になった」（A分類）はわずか6件。最多は「既存の記述がもともと問題だった」（B分類）の26件だった。他部との整合性喪失（C）が6件、判定不能（D）が22件。

つまり、ループが終わらない理由は「直すと壊れるから」ではない。もともと難しい箇所を、何度も同じように指摘し続けているだけだった。レビュー後半で修正起因の指摘が増える傾向も確認されていない。

この結論は実務的にかなり重い。edit drift が原因なら「修正の質を上げれば収束する」が処方箋になる。だがそうでないなら、いくら丁寧に直しても、そのモデルにとって難しい節は指摘され続ける。収束しない箇所は、修正で解決するのではなく、停止条件の側で扱うしかない。

エンジニアへの影響：ループに何を組み込むか

以上を踏まえると、自律ループを組むときに実装すべきものはかなり具体的になる。

停止条件は「指摘ゼロ」に置かない。 108ラウンドの実測が示すとおり、2モデル同時のゼロ指摘は現実的に来ない可能性がある。実践レポート側が採用している「High指摘0件で完了」「要確認が1件でもあれば即エスカレーション」「試行回数上限」という三段構えは、深刻度と回数の両方で打ち切る設計になっており、この問題への実用的な回答になっている。

検証可能性を上げる記録を残す。 108ラウンドの記事が実務的な示唆として挙げているのは、停止条件の精緻化よりもむしろ「指摘時に逐語引用や行番号を記録する」ことだった。同じ節が繰り返し指摘されているのか、別の問題が出ているのかを後から切り分けられるかどうかが、ループの健全性判定を左右する。

長時間走行の周辺装備を先に用意する。 同日には、コンテキスト使用率を監視して UserPromptSubmit / Stop hook で引き継ぎノートを自動生成する仕組みや、レートリミット到達時に Codex へ自動フェイルオーバーする仕組みの報告も出ている。ループを長く回すほど、モデルの賢さではなくこうした運用の穴が律速になる。

そして Osmani 自身が最も強く警告しているのは、この点だ。「無人で走るループは、無人でミスを犯すループでもある」。検証責任は依然として人間側にあり、自分が書いていないコードが速く積まれるほど、自分のシステムに対する理解は失われていく。彼の結びは「ループを作れ。ただし、ボタンを押す人ではなく、エンジニアであり続けるつもりの人間として作れ」だった。

まとめ

  • ループエンジニアリングは、プロンプトを打つ人間を仕組みで置き換える設計論。Osmani は Automations / Worktrees / Skills / Plugins / Sub-agents の5要素と、永続メモリを挙げている
  • 実践面では、Checker サブエージェントから Write / Edit を外して役割分離を権限で強制する手法が有効。「エラー＝バグ」と即断せず、想定内の異常系と切り分ける判定ステップも必須
  • 108ラウンドの実測では、レビューが収束しない原因は edit drift ではなく「もともと難しい節の反復指摘」。交絡を揃えると編集有無による差は0.0ポイントだった
  • したがって停止条件は「指摘ゼロ」ではなく、深刻度と試行回数で切るべき。逐語引用や行番号の記録が、収束判定の材料になる

ループを回すための部品は出揃った。次に設計対象になるのは、どこで止めるか——そしてループの外側に残る人間が、何を見て判断するかのほうだ。

今日のその他のニュース

Firebase AI Logic に Gemini 新モデルが追加 gemini-3.6-flash と gemini-3.5-flash-lite が Firebase AI Logic 経由で利用可能になった。Gemini Developer API と Agent Platform Gemini API の双方にモバイル・Web から到達できる。Flutter SDK も v4.18.0 がリリースされており、モデル切り替えのために自前バックエンドを挟まずに済む構成が維持されている。

UnYOLO — エージェント向け認証情報ブローカ コーディングエージェントに GitHub トークンを直接渡すのではなく、認証情報ブローカとポリシーエンジンを間に挟む仕組み。同日 Hacker News には、エージェント編集下のテキストで行単位に人間/AI の来歴を追跡する「Human vs. AI」も上がっており、権限を渡した後の統制層のツールが立ち上がりつつある。

Struts 47万行の AI 移行を単価まで実測 レガシー Struts コード47万行の AI 移行コストを実測し、見積もりレンジとして提示した記事。「AI で移行できる」という定性論ではなく、現実的な規模で単価に落としている点が受託・支援案件の見積もり根拠として参照しやすい。

ソース

Back to articles