Loop Engineering - Addy Osmani

AIコーディングエージェントの次の段階として提示された「ループエンジニアリング」

この記事は、Addy Osmani が書いた「Loop engineering」を中心に、コーディングエージェントを人が毎回直接指示する方式から離れ、エージェントに仕事を見つけさせ、分割させ、検証させ、次の作業を決めさせる反復システムを設計する方式へ移行しうるという見方を扱います。ここでいうループは、「定められた目標に向かってAIが何度も繰り返し実行する作業フロー」に近いものです。ただし、この記事はこれを万能の解決策とは見ていません。トークンコスト、検証責任、開発者の理解度低下といった現実的なコストもあわせて強調しています。

要点のまとめ

ループエンジニアリングの意味

従来は、開発者がコーディングエージェントにプロンプトを書き、結果を読み、再び指示していました。記事でいうループエンジニアリングは、この過程を自動化された構造へ置き換えるアプローチです。つまり、人が毎回指示する代わりに、「何を探し、どう処理し、いつ止めるか」をシステムとして設計します。

構成要素

著者は、ループを作るための要素として、自動実行、ワークツリー、スキル、プラグインとコネクタ、サブエージェント、そして外部メモリを挙げています。ワークツリーは、同じリポジトリを複数の作業空間に分けて衝突を減らす Git の機能です。スキルは、プロジェクトのルールや知識を文書化し、エージェントが毎回推測しなくて済むようにする仕組みです。コネクタは、Linear、Slack、データベースのような外部ツールと接続する経路です。

利点

反復業務の削減という面では、CI失敗の要約、イシュー分類、最近のコミットレビューのような作業を自動化できます。並列処理の面では、複数のエージェントがそれぞれ別のワークツリーで作業し、ファイル衝突を減らせます。知識再利用の面では、プロジェクトの慣行やビルド手順をスキルとして保存することで、毎セッション同じ説明を繰り返す必要がなくなります。

欠点とリスク

検証の負担はなくなりません。ループが作った結果は、依然として人が確認する必要があります。トークンコストも大きくなりえます。サブエージェントが増えると、各エージェントが個別にモデルとツールを使うためです。理解度の負債も問題です。開発者が結果を読まずに受け入れてしまうと、コードベースは大きくなっても、人間が理解している範囲はむしろ狭まる可能性があります。

差別化ポイント

一般的なプロンプトエンジニアリングが「一度きりの良い質問」に焦点を当てるのに対し、ループエンジニアリングは「再現可能な作業システム」を設計する方向に近いものです。著者は、Codex と Claude Code が、自動化、スキル、MCPベースの接続、サブエージェントといった類似の構成要素を備えるようになり、ツールそのものよりループ設計のほうが重要な関心事になりつつあると見ています。

特長

作成者と検証者の分離が重要な特徴です。コードを作ったエージェントが自分で結果を評価すると甘くなりうるため、別のサブエージェントがレビューする構造が提案されます。外部メモリの維持も重要です。Markdownファイルやイシューボードのように、会話の外に状態を残しておくことで、次の実行時に引き継げるようになります。

ループエンジニアリングは、開発者を置き換える話というより、開発者が介入する地点を変える話として読めます。直接プロンプトを書き続ける作業から離れ、反復構造、検証条件、作業分担、記録方法を設計する方向へ重心が移ります。ただし、良いループが良い判断を代替するわけではありません。コードを読み、検証し、システムの限界を理解するエンジニアリング能力がなければ、自動化は速度より先にリスクを増幅させる可能性があります。