Loop engineering: Designing loops you can actually walk away fromの意訳です。
いまXでは、新しい用語がエンジニアリングコミュニティの注目を集めています。それがループエンジニアリングです。
中心となる考え方はシンプルです。コーディングエージェントを手作業で操作する段階から一歩進みます。代わりに、実行を任せられる自律的なループを設計し、自分は他のタスクに集中したり、次のループを設計したりできるようにします。
Peter Steinberger（OpenClawの作成者）がこの議論の火付け役となり、Boris（Claude Codeの責任者）は有名な引用として「私は手動プロンプトの段階を越えました。いまは、Claudeに指示し、実行経路を進めてくれる自律サイクル（ループ）を設計しています。私の本当の仕事は、ループそのものをエンジニアリングすることです」と述べています。
業界は2023年初頭のプロンプトエンジニアリングからコンテキスト管理へ、さらに2025年後半に注目を集めたハーネスエンジニアリングへと移ってきました。2026年が「エージェントハーネスの年」と呼ばれるころには、焦点はすでに移り変わっています。
ループエンジニアリングはどこから始まったのか
このアイデアは新しいものですらありません。1月の時点で、Geoffrey Huntleyは自身がralph loopと呼ぶものを掲げていました。同じゴールをエージェントに何度も与え、何時間も実行させ、人間が席についていなくても、エージェント自身に作業を見つけ、計画し、解決させるというものです。
モデル内部のコンテキストに頼るのではなく、進捗はGitの履歴、ファイル、外部メモリ管理によって保持されます。ここが主要な技術的ハードルとして残っています。基本的なbashスクリプトを使えば、コンテキストウィンドウを使い切ったときでも、新しいエージェントが前任の停止地点からシームレスにタスクを再開できます。
Anthropicはそれより数か月前、研究側から同じような形を公開していました。エージェントがシフト制で作業し、それぞれが前回の記憶を持たずに現れ、ディスク上に残されたメモを頼りに続きの作業を進めるという形です。
ループはどのようなものか？
プロンプト、コンテキスト、ハーネスの各エンジニアリングでは、どのターンでもエージェントを手作業で導く必要がありました。一方で、ループエンジニアリングは全面的な転換を意味します。自律的に動作するシステムを設計することで、人間をループから完全に外し、作業から完全に手を離せるようにします。
根本的な違いは、誰が主導権を持っているかにあります。
- プロンプトは独立した指示です。AIは単一の応答を返して停止し、次の入力を待ちます。
- ループは再帰的なゴールです。目的が定まると、システムは回路全体を自律的に進み、目標が完全に達成されるまで継続します。
ループに必要なパラダイムとは？
具体的なアーキテクチャについては、Addy Osmaniによる整理がもっとも簡潔です。5つの中核的な構成要素に、専用のメモリレイヤーを加えたものです。用語はプラットフォームによって異なっても、その下にある機能は一貫しています。
- オートメーション：スケジュールに沿って動き、あなたがコーヒーを飲む前に作業を探し出してトリアージするものです。
- ワークツリー：並列に動く各エージェントがそれぞれ専用のチェックアウトを持つため、2つのエージェントが互いのファイルを上書きできません。
- スキル：プロジェクトの知識を一度だけ書き下ろします。規約、ビルド手順、苦労して得た「このやり方は避けるべき」というメモなどです。これにより、エージェントはセッションごとに推測し直さずに済みます。
- プラグインとコネクタ：MCPを基盤にした仕組みで、ループがファイルシステムの外に出て、普段使っているツールにアクセスするためのものです。課題管理システム、データベース、ステージング環境、Slackなどが該当します。
- サブエージェント：コードを書いたモデルに、そのコードの採点を任せません。自分の作業に対しては評価が甘くなりがちだからです。
- 状態：6つ目の要素であり、軽視されやすいものです。ディスク上のメモリです。ファイルやLinearのボードで、何が完了し、次に何をするかを追跡します。リポジトリは残っていても、モデルは実行のたびにリセットされるからです。
成功する完全なループをどう設計するか？
2月に、個人プロジェクト向けのループを組みました。主な目的は、自分が関与しなくてもどこまで動かせるかを確かめることでした。ループは本物のユーザーフィードバックから始まり、新しいリクエストを取り込み、トリアージし、取り組む価値のあるものごとに計画を作成しました。そこからClaudeが実装を書き、差分がきれいになるまでCodeRabbitがループ内でレビューし、Claudeがテストを実行しました。
すべてが問題なければ、ループはCIを待ち、自動でマージし、その後マージ後のデプロイチェックで結果を再確認しました。私の仕事は、何を実装する価値があるかを判断し、エージェントが作ったものを確認することだけでした。一度ループを設計すると、その後もリリースを続けてくれました。
それを支えていたものは地味ですが、そこが重要です。全体は1つのスケジュールジョブと状態ファイルで動いていました。状態ファイルは何をリリースし、何が失敗し、何がまだ未対応かを記録するプレーンなMarkdownログです。そのため、各実行はゼロから始めるのではなく、前回の続きから再開できました。プロジェクトの規約は、エージェントが毎回読むスキルにまとめられていたため、誰もセットアップを最初から推測し直す必要はありませんでした。
そして、私が放置できるようにしていたのは品質ゲートでした。テストが通り、CodeRabbitのレビューがクリーンになるまで、何もマージされません。つまり「完了」はClaudeによる自己評価ではなく、信頼できるシグナルでした。変更は小さく、確認可能な範囲に保ちました。注意深いジュニアエンジニアがチケットからリリースできるような種類の変更です。本当に判断が必要なものは自分で対応しました。ループはそうした判断をしません。私があらかじめコード化した判断を、何度も繰り返し実行するだけでした。
CodeRabbitはループエンジニアリングにどう組み込まれるのか？
CodeRabbit側では、Claude Codeと連携する3つの要素がありました。計画エージェントが生のフィードバックをコーディング計画に変換し、CLIがループ内で直接レビューを実行することで、PRになる前にClaudeが指摘を修正できるようにし、レビュー機能がPR自体の最終ゲートになりました。全体像は次のとおりです。
ループを作るべきか、作らないべきか
作る前に、そのタスクにループを組む価値があるのかを考えるべきです。ループは安定したターゲットに向いています。コードベースを書き換える場合、ゴールは動きません。そのため、1つの検証器、つまりビルドできるか、テストが通るか、振る舞いが変わっていないかを確認する仕組みを一度書けば、すべての反復で再利用できます。しかし条件が変わり続ける場合、計算は逆転します。
各実行ごとに「完了」の定義が変わるなら、リリースを進める代わりに検証器を書き直すことに時間を費やすことになります。その保守コストが、ループで節約できるはずだった時間を食いつぶします。ゴールが安定しているならループを作りましょう。ターゲットが動き続けるなら、手動プロンプトのままにしておきましょう。
