2026年6月ごろから、複数の識者がほぼ同時に言い出した言葉がある。ループエンジニアリングだ。Loop Engineering Orange Book や Addy Osmani の記事、Xでの14ステップのロードマップ投稿など、出どころはバラバラなのに言っていることが近い。自分のObsidian Vaultにも似た記事が何本かIn boxに溜まっていたので、今回は外部記事を読み直すのではなく、Vaultの中だけで棚卸しして、何が新しくて何がハーネスの延長で、どこに落とし穴があるのかを整理してみた。
ハーネスの一段上にある言葉
これまで自分が意識してきた「ハーネス」は、1回の実行を武装する仕組みだった。lint、型検査、テスト、AGENTS.md。モデルの性能そのものより、こうした「モデルの外側」の作り込みが成果を左右するという考え方だ。
ループエンジニアリングは、この武装を継続的に回る系へ拡張したものだと理解している。人間が毎回プロンプトを打つ代わりに、作業を見つけ、エージェントへ渡し、結果を確認し、記録し、次を決める。この一連の動作を自動で回すシステムを設計することがループエンジニアリングだ。
ループは4種類、まず分類から入る
いきなり「回そう」とする前に、自分がどのループを作ろうとしているのかを分類しておくと迷わない。
- ターン型：都度プロンプトを打って進める
- ゴール型：達成条件を満たすまで反復する
- 時間型：スケジュール駆動で動く
- プロアクティブ型：人間の監視なしに動く
普段Cursorに向かって「あれやって」と打っているのはターン型だ。ループエンジニアリングが指すのは、ここから一段抜け出したゴール型・時間型・プロアクティブ型の設計だと考えると、自分が今どこにいるかが見えやすくなる。
着手前に確認する4条件
回し始める前に、次の4つが揃っているかを確認してから着手する。
- 週1回以上の繰り返しがあるか
- 自動検証ができるか
- トークン予算は妥当か
- エージェントの実行環境は用意できるか
どれか1つでも欠けていれば、ループ化はまだ早い。特に「自動検証ができるか」は見落としがちだが、ここが弱いと後述する「静かな失敗」に直結する。
最小構成は4部品でいい
最小限のループは、オートメーション・スキル・ステートファイル・ゲート（テストや型検査）の4部品で組める。1つずつから始めて、足りない部品を後から足していくくらいでちょうどいい。
品質を安定させる鍵は、コードを書いたAI自身に自己評価させないことだ。コードを書いたAIは自分の宿題に甘い。メイカーとチェッカーを別エージェントに分離する発想はGAN（敵対的生成ネットワーク）に由来していて、自己批判を鍛えるより懐疑的な評価者を別に立てる方が効果的だとされている。
代償を先に知っておく
ループを回し続けることには代償が伴う。ここを楽観視すると、あとで痛い目を見る。
- 検証負債：ゲートが不十分なまま回り続けると、後で溜まった不整合の解消コストが膨らむ
- 理解負債：人間が出力を追えなくなり、認知そのものを放棄してしまう
- トークン暴走：終了条件が緩いと消費が青天井になる
- 静かな失敗：完了条件が曖昧なまま、失敗し続けるループに誰も気づかない
面白いのは、同じ部品で作ったループでも、運用する人間の姿勢しだいで結果が正反対になるという指摘だ。判断力を鍛える道具として使うか、理解を放棄する道具として使うか。この差が半年後の熟練度を分けるとしたら、ループエンジニアリングは自動化の技術である以前に、運用する人間の姿勢込みの設計だと捉えたほうがよさそうだ。
以前書いたDevin Auto-Triageは、いま振り返ると小さなゴール型ループだった。インシデントの監視から調査、PR作成までを一連の系として回す設計で、当時はそこまで意識していなかったが、今回の棚卸しで「あれはループエンジニアリングだったんだな」と後付けで名前がついた感じがある。
個人からエンタープライズまで、設計は共通している
実践規模には幅がある。一人で朝のトリアージを回す個人規模の例もあれば、企業が週1,300件超のPRを自動処理する例もある。共通しているのは、LLMに渡す前に決定論的な仕組みでコンテキストを整えておく設計だ。
エンタープライズ規模の例として分かりやすいのが、Devinを開発するCognition社が語っていた全社導入モデルだ。headcountをほぼ変えずにマージPR数だけを数倍に伸ばす「常時稼働エンジニアリング」への移行が核で、α（〜50名）→β（〜100名）→全社（2,000人以上）という3段階で広げていく。大規模なコードマイグレーションでは「Devinが80%を自律実装し、人間のペアプログラミングが15%を仕上げ、シニアエンジニアが最後の5%をレビュー・マージする」という80:15:5の法則で分業していた。
ここで語られていた「実装のHowはDevinに任せ、なぜそれで良いかという判断はエンジニア側に残す」という境界設計は、ループエンジニアリングが定義する「人間が設計し、エージェントが回す」という役割分担そのものだったんだな、と今回の棚卸しで気づいた。
追記：ループの次はグラフだった
この記事を書いた直後にAnatoli Kopadzeのスレッドを教えてもらった。読んでみると、上で整理した「ループ」がすでに一段先に進んでいて、グラフエンジニアリングという名前がついていた。
要点はこうだ。1つのループは「1エージェントが1つのことを試す・確認する・調整する」反復に過ぎない。みんなが次に移ったのは、より良いループではなく、ループのグラフ——複数のサイクルが互いを監視し、修正し合うネットワークだ。語彙は2つだけでいい。ノード（1エージェントが1つのタスクを行う箱）とエッジ（あるジョブが別のジョブの出力を実際に必要とする、という矢印）。
面白かったのが「偽エッジのテスト」だ。今のワークフローを1歩ずつ辿り、各ステップで「これは本当に1つ前の結果を必要としているか」と問う。不要なら、そこにエッジはない。無駄に待っているだけで、実は並列にできる。直列で書いた40ステップは40個の逐次故障点を持つが、本当の依存関係だけを残してグラフに描き直すと、最も遅い層の速度で終わるようになる。「AしてからB、C、D」と書いている時点で、実は自分もすでにグラフを描いていた、という指摘には笑った。ただし最悪の形——一直線のチェーンで。
覚えるパターンは1つ、ダイヤモンド（fan out → reduce → synthesize）。分岐して複数ワーカーが並行に集め、コードで圧縮し、最後に1エージェントが統合する。ここでもチェッカーの話は同じで、作業したエージェントに検証させてはいけない。同じチャットを与えると自己採点になり、衣装を変えただけの単一ループとして同じように壊れる。壊れる場所も3つに整理されていて、大量の出力を1ステップへ流し込む「コンテキストの崩壊」、プロンプト上は無関係でも同じファイルを共有する「偽の独立性」、200ノード中の1つが静かに死んでも気づかれない「静かなノード失敗」だ。
一番刺さったのは最後の警告だった。トポロジーだけでは誠実にならない。すべてのノードが互いを監視し合っていても、参照している数字が同じ元システムから来ていれば、何も検証していないのと同じ。実際に通ったテストや実際の収益のような「反論できないアンカー」を持たせておかないと、グラフは単一ループとまったく同じように失敗する。ただし、より後で、より高くつく形で。
グラフは幅（並行して片づく作業量）を買うものであり、判断力を買うものではない、という線引きも腹落ちした。タスクが小さい、逐次的に依存している、まだ何を探すか分からない探索的な作業。ここには向かない。偽エッジが1つも見つからないなら、それはループのままでいい。
Claude Codeにはこれを実装する「dynamic workflows」機能があるらしく、プロンプトの先頭に"workflow"と書くとオーケストレーションスクリプトを書いて実行してくれるそうだ。今度試してみる。
まとめ
- ループエンジニアリングは、ハーネス（1回の実行を武装する仕組み）を継続的に回る系へ拡張したもの
- まず4種類（ターン型・ゴール型・時間型・プロアクティブ型）に分類し、着手前に4条件（反復頻度・自動検証・トークン予算・実行環境）を確認する
- メイカーとチェッカーを分離し、品質責任を決定論的な検証系へ寄せる
- 検証負債・理解負債・トークン暴走・静かな失敗という代償を先に知っておく
- 個人の朝のトリアージから企業の全社導入まで、設計思想は規模を問わず共通している
- ループの次はグラフ。ノードとエッジで描き、偽エッジのテストで無駄な逐次実行を削り、チェッカーには必ず新しいコンテキストを与える
- グラフはトポロジーだけでは誠実にならない。反論できないアンカーを持たせて初めて信頼できる
外部記事を新しく読みに行かなくても、Vaultに溜めてきたメモを横断するだけでここまで整理できたのが今回の収穫だった。次は自分の作業のどれかを実際にゴール型か時間型のループに落として、体感として確かめてみたい。グラフの方は、まず自分のワークフローに偽エッジがないか探すところから始めようと思う。
参考