Addy Osmani氏の「ループエンジニアリング」　エージェントに指示を出す仕組みを作る

Addy Osmani氏が、自身のブログで「ループエンジニアリング」を解説した。コーディングエージェントに人が1回ずつ指示を出すのをやめ、仕事を見つけ、渡し、確かめ、記録し、次を決める仕組みを作る考え方で、そのための部品はCodexにもClaude Codeにも既にそろっている。ところが、ループは回るだけでは目標に近づかない。同じ形のループを自社の開発で回すSAGUSでは、11月8日までの7日間に、成果が増えないまま開き直したセッションが54回あった。

指示を出す人から仕組みを作る人へ

Osmani氏は、この2年はよい指示文と十分な文脈を渡し、返ってきた答えを読んで次を打つ使い方だったと振り返る。これからは、定期的に動いて仕事を見つける仕組み、並行の作業が互いを壊さない作業場所、プロジェクトの知識を書いた手順書、課題管理やチャットにつなぐ部品、作る役と確かめる役を分ける子のエージェントの5つと、会話の外に置く記録で組むと整理した。

氏は、これらの部品が今はCodexにもClaude Codeにも製品の機能として入っており、どちらの道具でも同じ形のループを組めると指摘する。中でも重く見るのが、作る役と確かめる役を分けることだ。書いたモデルに自分の採点をさせると甘くなるからである。一方で、トークンの費用には注意が要り、確かめる責任は人に残ると念を押し、「ループを作れ、エンジニアであり続けよ」という趣旨の言葉で結んだ。

氏が示すループの例はこうだ。毎朝、定期の実行が前日のCIの失敗と未処理の課題と最近の変更を読み、見つけた物をファイルか課題管理に書く。手を付ける価値がある物ごとに作業場所を分け、子のエージェントが直しの下書きを作り、別の子のエージェントが手順書と既存のテストに照らして確かめる。扱えない物だけが人の受け箱に届き、記録が翌朝の続きを支える。

氏は、ループがうまく回るほど重くなる問題も3つ挙げた。人が見ていない間の誤りを確かめる責任、自分が書いていないコードへの理解が追いつかなくなること、出てきた物をそのまま受け取ってしまう姿勢である。

ループの5段のどこに効くか

ループを発見・引き渡し・検証・永続化・スケジュールの5段に分けると、Osmani氏の部品は次のように当たる。

1. 発見: 定期の自動実行が、失敗したCIや未処理の課題を集める。
2. 引き渡し: 作業場所を分け、子のエージェントに下書きを渡す。
3. 検証: 作った役とは別の役が、手順書と既存のテストに照らして確かめる。
4. 永続化: 何を試し、何が通り、何が残るかを会話の外の記録に書く。
5. スケジュール: 定期の実行と、条件が満たされるまで続ける実行で回す。

5段すべてに部品がある。新しいのは部品そのものより、5つを1つの形として設計する視点だ。

SAGUSで試した結果

SAGUSの開発では、課題管理のLinearに置いた依頼を1分ごとに拾い、作業用のエージェントのセッションを開く仕組みを動かしている。変更は作った文脈とは別のレビュー役を通し、記録はLinearとgitに残す。定期の処理はMacの常駐の仕組みで回す。Osmani氏の言う形を、ほぼそのまま組んだことになる。作る役と確かめる役の分離は、変更の重さで人数を変えている。通常の変更は別の文脈のレビュー役1者が見て、本番や取り消せない削除に触れる変更は、別の会社のモデルを含む2者が見る。

11月8日までの7日間に、この仕組みはセッションを931回開き、663件の依頼を扱った。一方で、成果が増えないまま3回以上開き直された依頼が24件あり、そのうち3回目以降の成果の無い開き直しは54回だった。最長は11回続いた。ループが回ることと、ループが目標に近づくことは別だと、数字で分かった。

その前の10月30日から11月4日の記録では、依頼の受け付け114回のうち、状態を変えずに終わったセッションが6.1%、終わった後に閉じなかったセッションが11.4%あった。数字は、ループの終わり方にまだ揺れがあることを示している。

この失敗を受けて、SAGUSは成果が2回続けて増えなければ別の役に監査させ、それでも増えなければ人に回す出口を足した。効果の判定は11月15日ごろで、今は未測定だ。成果の増えない開き直しが、入れる前の半分以下になるかを見る。振る舞いを確かめる評価の試験も30件用意したが、製品の品質の物差しには、まだ目標に届かないものがある。

自分のループに入れる手順

1. 今の作業を、発見・引き渡し・検証・永続化・スケジュールの5段に書き出し、人が手で回している段を見つける。
2. 検証の段は、作った役と別の役か、別のモデルに任せる。
3. 何を試し何が通ったかを、会話ではなく課題管理かファイルに残す。
4. 同じ依頼を何回開き直したかを数え、成果が増えない時に止めて人に回す出口を作る。
5. 定期の実行は、Claude Codeのフックや予定の実行で、小さく1つから始める。

ループの価値は部品の数ではなく、回るたびに目標に近づくかで決まる。指示を出す人から仕組みを作る人に移っても、確かめる仕事は人に残る。

編集部の見方

編集部は、ループエンジニアリングの要点を、部品をそろえることより、確かめる工程と止まる条件を先に設計することにあると見る。部品は製品が用意してくれるが、何を確かめ、いつ止めるかは、使う側にしか決められないからだ。読者は、ループを足す前に、今の作業で誰が何を確かめているかを書き出すとよい。止まる条件を足した後に開き直しが本当に減るかは、まだ分からない。ループの設計を自社で試したい時は、スプリント0で相談を受けている。