Atsushi Nakatsugawa
June 25, 2026
2 min read
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はそれより数か月前、研究側から同じような形を公開していました。エージェントがシフト制で作業し、それぞれが前回の記憶を持たずに現れ、ディスク上に残されたメモを頼りに続きの作業を進めるという形です。
プロンプト、コンテキスト、ハーネスの各エンジニアリングでは、どのターンでもエージェントを手作業で導く必要がありました。一方で、ループエンジニアリングは全面的な転換を意味します。自律的に動作するシステムを設計することで、人間をループから完全に外し、作業から完全に手を離せるようにします。
根本的な違いは、誰が主導権を持っているかにあります。
具体的なアーキテクチャについては、Addy Osmaniによる整理がもっとも簡潔です。5つの中核的な構成要素に、専用のメモリレイヤーを加えたものです。用語はプラットフォームによって異なっても、その下にある機能は一貫しています。
2月に、個人プロジェクト向けのループを組みました。主な目的は、自分が関与しなくてもどこまで動かせるかを確かめることでした。ループは本物のユーザーフィードバックから始まり、新しいリクエストを取り込み、トリアージし、取り組む価値のあるものごとに計画を作成しました。そこからClaudeが実装を書き、差分がきれいになるまでCodeRabbitがループ内でレビューし、Claudeがテストを実行しました。
すべてが問題なければ、ループはCIを待ち、自動でマージし、その後マージ後のデプロイチェックで結果を再確認しました。私の仕事は、何を実装する価値があるかを判断し、エージェントが作ったものを確認することだけでした。一度ループを設計すると、その後もリリースを続けてくれました。
それを支えていたものは地味ですが、そこが重要です。全体は1つのスケジュールジョブと状態ファイルで動いていました。状態ファイルは何をリリースし、何が失敗し、何がまだ未対応かを記録するプレーンなMarkdownログです。そのため、各実行はゼロから始めるのではなく、前回の続きから再開できました。プロジェクトの規約は、エージェントが毎回読むスキルにまとめられていたため、誰もセットアップを最初から推測し直す必要はありませんでした。
そして、私が放置できるようにしていたのは品質ゲートでした。テストが通り、CodeRabbitのレビューがクリーンになるまで、何もマージされません。つまり「完了」はClaudeによる自己評価ではなく、信頼できるシグナルでした。変更は小さく、確認可能な範囲に保ちました。注意深いジュニアエンジニアがチケットからリリースできるような種類の変更です。本当に判断が必要なものは自分で対応しました。ループはそうした判断をしません。私があらかじめコード化した判断を、何度も繰り返し実行するだけでした。
CodeRabbit側では、Claude Codeと連携する3つの要素がありました。計画エージェントが生のフィードバックをコーディング計画に変換し、CLIがループ内で直接レビューを実行することで、PRになる前にClaudeが指摘を修正できるようにし、レビュー機能がPR自体の最終ゲートになりました。全体像は次のとおりです。
作る前に、そのタスクにループを組む価値があるのかを考えるべきです。ループは安定したターゲットに向いています。コードベースを書き換える場合、ゴールは動きません。そのため、1つの検証器、つまりビルドできるか、テストが通るか、振る舞いが変わっていないかを確認する仕組みを一度書けば、すべての反復で再利用できます。しかし条件が変わり続ける場合、計算は逆転します。
各実行ごとに「完了」の定義が変わるなら、リリースを進める代わりに検証器を書き直すことに時間を費やすことになります。その保守コストが、ループで節約できるはずだった時間を食いつぶします。ゴールが安定しているならループを作りましょう。ターゲットが動き続けるなら、手動プロンプトのままにしておきましょう。
