ループエンジニアリング：自律ループの設計

ループエンジニアリングは、AIコーディングの分野で新たに注目される概念です。従来のプロンプトエンジニアリング（2023年初頭）、コンテキスト管理、そして2025年後半に台頭したハーネスエンジニアリングに続き、現在は自律ループの設計に重点が移っています。この用語はX（旧Twitter）で話題となり、Peter Steinberger（OpenClawの創設者）が議論を始め、Claude Codeの責任者Borisも「今はもう手動プロンプトはしない。自律サイクルを設計し、Claudeを指示して実行経路をナビゲートさせている。本当の仕事はループ自体のエンジニアリングだ」と述べています。

このアイデア自体は新しいものではありません。今年1月、Geoffrey Huntleyは「ralphループ」を提唱しました。これは、エージェントに同じ目標を繰り返し与え、git履歴やファイル、外部メモリを使って進捗を保持し、人間の介入なしに数時間実行させるというものです。Anthropicも数ヶ月前に同様の研究を発表しています。

ループと従来のプロンプトの違いは、制御権にあります。プロンプトは孤立した指示で、AIが応答すると停止します。ループは再帰的な目標で、システムが自律的に回路をナビゲートし、目標が達成されるまで持続します。

実際のアーキテクチャについて、Addy Osmaniは5つのコアビルディングブロックと専用のメモリレイヤーを挙げています：

• 自動化：スケジュールに基づいてタスクを探し、優先順位付けする。
• ワークツリー：並列エージェントがそれぞれ独自のチェックアウトを持ち、ファイルを上書きしない。
• スキル：プロジェクトの知識（規約、ビルド手順、注意点など）を一度記述し、エージェントが毎回再推測しないようにする。
• プラグインとコネクタ：MCP上に構築され、ファイルシステムを超えて実際のツール（イシュートラッカー、データベース、ステージング環境、Slackなど）にアクセスする。
• サブエージェント：コードを書いたモデルとそれを評価するモデルを分け、自己評価の甘さを回避する。
• 状態：ディスク上のメモリ。何が完了し、次に何をすべきかを記録したファイルやLinearボード。モデルがリセットされても、リポジトリはリセットされないため。

著者は今年2月、個人プロジェクトでループを構築しました。ループは実際のユーザーフィードバックから始まり、新しいリクエストを取得、トリアージし、各リクエストに計画を立てます。次にClaudeが実装を書き、CodeRabbitがレビューして差分がクリーンになるまでループし、Claudeがテストを実行します。CIが通れば自動マージし、マージ後のデプロイチェックで再確認します。著者の仕事は、何を実装するか決めることと、エージェントの成果を検証することだけでした。

成功の鍵は、退屈なほどシンプルな仕組みにありました。スケジュールジョブ1つと、状態ファイル（何が出荷され、何が失敗し、何が未完了かを記録したプレーンマークダウン）だけです。プロジェクトの規約はスキルとして保存され、エージェントは毎回それを読み込むため、毎回ゼロからセットアップを再導出する必要がありません。品質ゲート（テスト合格とCodeRabbitのレビュー完了）が信頼できる「完了」シグナルとなり、Claudeの自己評価に頼る必要がなくなりました。著者は小さな変更に限定し、本当に判断が必要なものは自分で行いました。

CodeRabbit側では、プランニングエージェントが生のフィードバックをコーディング計画に変換し、CLIがループ内でレビューを実行してClaudeが修正できるようにし、レビュー製品がPRの最終ゲートとなります。

ループを構築する前に、タスクが価値があるかどうかを検討すべきです。ループは安定した目標に対して効果的です。例えば、コードベースの書き換えのように目標が変わらない場合、検証器（ビルドが通るか、テストが通るか、動作が一致するか）を一度書けば全てのイテレーションで再利用できます。しかし、条件が絶えず変化する場合、各実行ごとに「完了」の定義を書き直す必要が生じ、ループの節約効果が相殺されます。安定した目標にはループを、変化する目標には手動プロンプトを使うべきです。