Loop Engineering.
原文作者：Addy Osmani
編集：Peggy、BlockBeats

編集者注：AIコーディングエージェントの使用方法は、「人が手動でプロンプトを記述し、段階的にタスクを進める」から、「人がループを設計し、システムがエージェントを継続的にスケジューリングする」方向に移行している。Addy Osmaniが述べるループエンジニアリングの核心は、タスクを自動的に発見し、割り当て、結果をチェックし、進捗を記録して次に何を行うかを決定するワークフローを構築することである。

このループは主に5つのモジュールで構成されています：Automations（タスクの定时発見とトリアージ）、Worktrees（複数の並列開発環境を隔離）、Skills（プロジェクトの知識とチームの慣行を蓄積）、Plugins/Connectors（GitHub、Linear、Slack、データベースなどの実際のツールとの接続）、Sub-agents（実行者とレビュー者を分離）、さらに、状態と進捗を保存するための外部メモリ層（MarkdownファイルやLinearダッシュボードなど）。

ループエンジニアリングの意義は、「AIに複数回実行させる」ことではなく、エンジニアの判断をシステム設計の初期段階に組み込むことです。ループは開発者の生産性を大幅に高めますが、検証、理解、判断を置き換えるものではありません。真のリスクはループの使用自体ではなく、ループをコードやシステムの理解を避けるための口実として使うことにあります。AIと協力してプログラミングする未来において、優れたプロンプトを書く能力だけでなく、信頼性があり、検証可能で、持続可能なエージェントワークフローを設計する能力が鍵となるでしょう。

以下が原文です：

Loop engineering（循环工程）は、あなたが「エージェントにプロンプトを書く人」としての役割を置き換えており、エージェントにプロンプトを送るためのシステムを設計する必要があります。ここでいうloop（循環）は、再帰的な目標と捉えることができます：目的を定義すれば、AIはタスクが完了するまで繰り返しイテレーションを続けます。これは主に5つの構成要素で構成されており、Claude CodeとCodexはすでにこれらの5つの構成要素を備えています。

私は、これが私たちが今後コーディングエージェントと協力する方法の可能性があると考えています。しかし、これはまだ初期段階であり、私は疑念を抱いています。使用パターンによってコストの差が非常に大きくなるため、特に「トークンに余裕がある」か「トークンが限られている」かによって、トークンコストには慎重に対応する必要があります。また、品質が低下しないようにするための何らかのメカニズムも必要です。「AIの粗製濫造」（slop）に対する懸念も合理的です。とはいえ、これが実際にどのようなものなのかを見てみましょう。

@steipete は最近、次のような言葉を述べた。「あなたはコーディングエージェントにプロンプトを書くべきではない。エージェントにプロンプトを与えるループを設計すべきだ。」同様に、Anthropic の Claude Code チームリーダー @bcherny も、「私はもう Claude にプロンプトを書かない。複数のループが動作しており、それらが Claude にプロンプトを出し、次に何をすべきかを自ら判断している。私の仕事はループを書くことだけだ。」と語っている。

では、これは一体何を意味しているのでしょうか？

過去約2年間、コーディングエージェントに何かをしてもらいたい場合、基本的な方法は良いプロンプトを書くことと、十分なコンテキストを提供することでした。1文を入力し、返答を読み、次の文を入力するというプロセスを繰り返していました。エージェントはツールであり、あなたはそのツールを握り続け、1ラウンドずつそれを推し進めてきました。この段階は、ある程度終了したとも言えます。少なくとも一部の人々は、それが終わりに近づいていると考えています。

現在、あなたは小さなシステムを構築しています：このシステムは自ら仕事を発見し、タスクを割り当て、結果をチェックし、完了状況を記録した上で、次に何をすべきかを決定します。つまり、あなたが繰り返しプロンプトを送るのではなく、このシステムがエージェントを駆動するようにするのです。以前、私はその「近縁」——エージェントハーネスエンジニアリング（エージェント実行フレームワークエンジニアリング）、つまり単一のエージェントに実行環境を構築するもの——およびファクトリーモデル（工場モデル）、つまりソフトウェアを構築するシステム——を書きました。ループエンジニアリングは、ハーネスのさらに上位に位置します。これはハーネスに似ていますが、タイマーに従って動作し、小さなアシスタントを生成し、自己養成を行います。

驚いたことに、これはもはや「ツールレベル」の問題ではなくなっている。一年前、ループを実現するには、大量のbashスクリプトを書かなければならず、そのスクリプトを永遠にメンテナンスし続ける必要があった。それはあなた自身のもので、あなただけのものだった。しかし今や、これらのコンポーネントは製品に直接組み込まれている。Steinbergerが挙げた機能は、ほぼそのままCodexアプリに、またClaude Codeにも対応している。それらの形態が同じであることに気づけば、どのツールを使うべきかという悩みは消え、どんなツールに座っていようとも動作し続けるループを設計するようになるだろう。

五つの構成要素といくつかの説明

ループには五つの要素と、情報を記憶する場所が必要です。まず列挙し、その後それぞれに対応させます。

まず、Automations（自動化タスク）：計画に従ってトリガーされ、自動的に発見と振り分けを行います。

第二に、Worktrees（ワークツリー）：並行して作業する2つのエージェントが互いのファイルを上書きしないようにします。

第三に、スキル（スキル）：プロジェクトの知識を書き留め、エージェントが毎回推測する必要がないようにします。

第四、Plugins and connectors（插件とコネクター）：エージェントに、あなたがすでに使用しているツールを接続可能にします。

第五、サブエージェント：一つは案を提案し、もう一つは案をチェックします。

そして6番目は「memory（記憶）」です。これはMarkdownファイルでも、Linearボードでも、単一の会話を超えて「完了済みタスク」と「次に実行するタスク」を保存できる場所であれば何でも構いません。重要性が低そうに聞こえるかもしれませんが、これはすべての長期実行エージェントが依存する同じテクニックです。私は長期実行エージェントについても詳しく記述しています：モデルは各実行間で記憶を失うため、記憶はコンテキストではなくディスクに保存する必要があります。エージェントは忘れますが、コードリポジトリは忘れません。

現在、この2つの製品にはすべての5つの構成要素が備わっています。

名前はいくつか異なる点がありますが、機能は本質的に同じです。以下に一つずつ説明します。なぜなら、正直なところ、ループが安定して動作するか、それともこっそり至る所で漏れているかは、細部にかかっているからです。

オートメーションは、ループを単なる一度限りの手動実行タスクではなく、真正のループにするものです。Codexアプリでは、オートメーションタブでプロジェクト、実行するプロンプト、実行頻度、そしてローカルチェックアウト内で実行するかバックグラウンドのワークツリー内で実行するかを選択できます。問題を検出した実行結果はTriageインボックス（分流受信ボックス）に送られ、問題が見つからなかった実行は自動的にアーカイブされます。これは便利です。OpenAI内部でも、日々のイシューの分流、CI失敗の原因要約、コミット要約の作成、先週誰かが導入したバグの追跡など、退屈だが重要なタスクにこの機能を使用しています。オートメーションタスクはスキルを呼び出せるため、繰り返し実行するタスクを維持可能にできます：将来誰も更新しない計画タスクに一連の長い説明文を貼り付けるのではなく、$skill-nameをトリガーするだけです。

Claude Codeも同じ効果を達成できますが、実現方法は異なります：スケジューリングとフックを活用します。/loopを用いて固定間隔でプロンプトやコマンドを実行したり、cronタスクを設定したり、エージェントのライフサイクルの特定のノードでフックを使ってシェルコマンドをトリガーしたりできます。コンピュータを閉じた後も実行を継続させたい場合は、全体をGitHub Actionsにプッシュすることも可能です。考え方はまったく同じです：自律的なタスクを定義し、リズムを与え、結果が自分のもとへ届くようにし、自ら探し回る必要がないようにします。

さらに理解すべき対話内原語として、本文が真に議論している核心に近いものがあります。/loop はリズムに合わせて繰り返し実行され、/goal はあなたが記述した条件が実際に満たされるまで継続して実行されます。各ラウンドの後、別個の小さなモデルがタスクが完了したかを判断するため、コードを書くエージェントは自分自身でスコアを付けることはありません。たとえば「test/auth 内のすべてのテストがパスし、lint がクリーンである」という条件を指定して、あとは放置できます。Codex も同様の機能を持ち、これも /goal と呼ばれます。これはラウンドを跨いで継続的に作業し、検証可能な停止条件が満たされるまで実行され、一時停止、再開、クリアをサポートします。同じ原語が、この2つのツールに共通して存在します。これはまさに本文で繰り返し登場するパターンです。

したがって、Automations は作業を浮き彫りにします。loop の残りの部分は、これらの作業を処理します。

複数のエージェントを同時に実行すると、ファイルの競合が失敗の原因になります。2つのエージェントが同じファイルに同時に書き込むことは、コミュニケーションなしで同じ行のコードを2人のエンジニアが変更するのと同様に問題になります。git worktree はこの問題を解決できます。これは、独立したブランチ上の別々の作業ディレクトリであり、同じコードリポジトリの履歴を共有するため、1つのエージェントの変更が物理的に他のエージェントのチェックアウトに影響を与えることはありません。

Codex は直接 worktree サポートを内蔵しているため、複数のスレッドが同じリポジトリを同時に処理しても衝突しません。Claude Code も git worktree を使用して同様の隔離を実現できます：--worktree フラグを使用して独立したチェックアウトでセッションを開くか、subagent に isolation: worktree を設定することで、各サブエージェントに新しいチェックアウトを割り当て、終了後に自動的にクリーンアップできます。私は the orchestration tax でこの点について人間の側面を記述しました：worktrees は機械的な衝突を排除できますが、あなた自身が上限です。同時に何つのエージェントを実行できるかを決定するのはツールではなく、あなたの review bandwidth（レビュー帯域幅）です。

Skillは、毎回のセッションで金魚のように同じプロジェクトのコンテキストを再説明する必要がないようにする仕組みです。両方のツールは同じフォーマットを使用します：SKILL.mdファイルを含むフォルダで、説明とメタデータが保存され、オプションでスクリプト、参照資料、リソースファイルを追加できます。Codexは、$ や /skills を呼び出したときにskillを実行し、あなたのタスクがそのskillの説明と一致した場合にも自動的に実行します。そのため、洗練された華やかな説明よりも、簡潔で素朴な説明の方が優れています。Claude Codeも同じアプローチを取っており、私はagent skillsでこのパターンを記述しました。

スキルは、意図が繰り返しあなたを消耗しないようにするための手段でもあります。intent debt で述べたように、エージェントは毎回の会話で冷スタートします。あなたの意図に空白があると、それは自信を持って推測して埋めようとします。スキルとは、こうした意図を外部に書き出すことです。プロジェクトの約束、構築ステップ、「以前の事故があったため、私たちはこれをやりません」など、すべてをエージェントが実行するたびに読み取る場所に一度だけ記述します。スキルがなければ、ループの各ラウンドでプロジェクト全体をゼロから再推論しなければなりません。スキルがあれば、それは複利のように成長するようなものです。

明確に区別する必要があります：skill はフォーマットを記述するもので、plugin は配布方法です。複数のコードリポジトリ間で skill を共有したり、複数の skill をパッケージ化したい場合、それらを plugin としてラップします。Codex も、Claude Code も同様です。

ファイルシステムのみを表示するループは、非常に小さなループです。Connectors は MCP を基に構築されており、エージェントがイシュー追跡システムを読み取ったり、データベースを照会したり、ステージング API を呼び出したり、Slack にメッセージを送信したりできるようにします。Codex と Claude Code の両方が MCP をサポートしているため、一方のために作成した connector は、通常、もう一方でも使用できます。Plugins は、connectors と skills をパッケージ化し、チームメンバーが記憶に頼って一連の設定を再構築するのではなく、一度のインストールで完全な設定を適用できるようにします。

これは「エージェントが『これが修正案です』と伝える」ことと、「ループが自らPRを開き、Linearチケットを関連付け、CIが通過した後にチャンネルに通知する」ことの違いです。コネクターが重要なのは、ループが「もしできればやります」と言うだけでなく、あなたの実環境で行動できるようにするからです。

ループ内で最も有効な構造的設計は、「書く人」と「チェックする人」を分けることである。コードを書くモデルは、自分自身の課題に採点する際に過度に寛容になりがちである。異なる指示を持ち、時には異なるモデルを使用する別のエージェントは、最初のエージェントが自己説得後に見落とした問題を捉えることができる。

Codexは、要求された場合にのみsubagentsを生成し、それらは並列に実行された後、結果が1つの回答に統合されます。.codex/agents/ にTOMLファイルを使用して独自のagentsを定義できます：各agentには名前、説明、指示、およびオプションでモデルと推論強度が設定されます。したがって、あなたのセキュリティレビュー担当者は高強度推論の強力なモデルに、探索担当者は高速で読み取り専用の軽量モデルにできます。Claude Codeも.clause/agents/内のsubagentsとagentチームを通じて同様の機能を実現し、複数のagentが互いに作業を引き継ぎます。両方で最も一般的な役割分担は、1つのagentが探索し、1つのagentが実装し、1つのagentが仕様に基づいて検証することです。

私はこの見解をすでに2回述べてきた：1回はcode agent orchestraで、もう1回はadversarial code reviewで。これはloopにおいて特に重要である。なぜなら、loopはあなたが見ていなくても実行されるからだ。したがって、あなたが安心して離れられる唯一の理由は、本当に信頼できるverifier（検証者）である。Subagentsは確かにより多くのtokenを消費する。なぜなら、各agentが独自のモデル呼び出しとツール呼び出しを行うからだ。そのため、それらは「第二の意見に価値がある」と言える場所で使用すべきである。これは本質的にClaude Codeの/goalが下層で行っていることと同じである：作業を完了させたモデル自身ではなく、新しいモデルがloopが完了したかどうかを判断する。つまり、これは「製作者」と「検査者」の分離を、停止条件そのものに適用している。

ループはどのような形をしているでしょうか

これらの要素を組み合わせると、1つの独立したスレッドが小さなコントロールパネルになります。以下は私がよく使用する構造です。

毎日朝、自動化プロセスがコードリポジトリで実行されます。このプロセスのプロンプトは、トリアージスキルを呼び出し、昨日のCI失敗、開いているイシュー、最近のコミットを読み取り、その結果をMarkdownファイルまたはLinearボードに記録します。対応が必要な各問題に対して、スレッドは分離されたワークツリーを開き、サブエージェントを起動して修正案を草案し、その後、別のサブエージェントを起動してプロジェクトのスキルと既存のテストに基づいてその案をレビューします。

Connectors により、このループは自ら PR を開き、チケットを更新できます。ループが処理できないものはすべて triage inbox に送られ、私が対応します。ステータスファイルはこのシステム全体の脊梁です：試行した内容、成功した内容、まだ未完了の内容を記憶します。そのため、翌日の実行は今日停止した場所から再開されます。

あなたが実際にしたことは、ただ一度設計しただけです。そのステップは、あなたが一つずつ指示したわけではありません。これがSteinbergerの言葉の現実版です。そして、同じループをCodexでもClaude Codeでも実行できます。なぜなら、構成要素自体が同じだからです。

Loopはまだあなたのために何もしません

Loopの働き方は変わりましたが、あなたを仕事から削除することはありません。実際、loopが強くなるにつれて、3つの問題はより簡単になるのではなく、より尖鋭化します。

検証は依然としてあなたの責任です。無人で動作するループは、無人でエラーを犯している可能性もあります。あなたが verifier sub-agent と maker を分ける理由は、ループが「完了しました」と言う言葉に何らかの意味を持たせるためです。それでも、「完了」は証明ではなく主張にすぎません。私は AI の時代におけるコードレビューで常に同じことを繰り返しています：あなたの役割は、あなたが有効であると確認したコードを提供することです。

放っておくと、あなたの理解自体が腐ってしまう。Loopがより速くあなたが自分で書かなかったコードを提供するほど、あなたが実際に理解しているものとシステムに実際に存在するものとの間の差が広がる。これがcomprehension debt（理解債）だ。Loopが生み出すものを読まなければ、スムーズなLoopはこの債務をさらに速く増やしてしまう。

そして、はい、最も快適な姿勢はおそらく最も危険な姿勢です。ループが自分で動作できるようになると、あなたは自分自身で判断を形成することをやめ、返されるものをただ受け入れてしまう傾向があります。これを私は「認知的降伏」と呼びます。判断力をもってループを設計すれば、それは解毒剤になります。しかし、思考を避けるためにだけループを設計すれば、それは加速剤になります。同じ行動でも、まったく逆の結果をもたらすのです。

ループを構築するが、依然としてエンジニアである

これは、私たちの今後の仕事の進化の方向を示していると思います。しかし、私が自らコードを確認しない、または自動化されたループに完全に頼ってコードを修正すると、私の製品品質が損なわれます。私はますます深く陥る悪循環に陥る可能性があります。

したがって、自分でループを構築することはもちろんできますが、直接エージェントに指示を出すことも依然として有効であることを忘れないでください。重要なのは、適切なバランスを見つけることです。

Loopの結果は人によって異なります。二人がまったく同じLoopを構築しても、まったく異なる結果を得ることができます。一人は自分自身が深く理解している仕事のスピードを上げるためにそれを使用し、もう一人は仕事そのものを理解することから逃れるためにそれを使用します。Loopはこの両者の違いを知りません。あなたは知っています。

これが、ループデザインがプロンプトエンジニアリングよりも簡単ではなく、むしろ難しい理由です。チェルニーの意図は、仕事が楽になったということではなく、レバレッジポイントが移動したということです。

ループを構築せよ。しかし、単に「開始」ボタンを押すだけの者ではなく、依然としてエンジニアであるつもりで構築せよ。

[原文リンク]

クリックして、律动BlockBeatsが募集している職種を確認してください

律動 BlockBeats 公式コミュニティへようこそ：

Telegram サブスクライブグループ：https://t.me/theblockbeats

Telegram交流グループ：https://t.me/BlockBeats_App

Twitter公式アカウント：https://twitter.com/BlockBeatsAsia