AI News HubLIVE
サイト内リライト8 分で読了

ループエンジニアリング

ループエンジニアリングは、コーディングエージェントへの手動プロンプトを、再帰的に目標に向かって反復するシステムに置き換えます。自動化、ワークツリー、スキル、プラグイン/コネクタ、サブエージェントの5つのコアコンポーネントと外部メモリで構成されます。CodexやClaude Codeなどのツールは類似のループプリミティブに収束しており、サブエージェントがアイデア出しと検証を分離して信頼性を向上させます。

ソースO'Reilly AI & ML Radar著者: Addy Osmani

以下の記事は元々Addy Osmaniのブログに掲載されたもので、著者の許可を得て転載しています。

ループエンジニアリングとは、自分自身がエージェントにプロンプトを送る立場から、代わりにプロンプトを送るシステムを設計することです。ここでのループは、目的を定義し、AIが完了するまで反復する再帰的なゴールと考えることができます。私はこれがコーディングエージェントとの将来の働き方になる可能性があると考えています。ただし、まだ初期段階であり、私は懐疑的です。また、トークンコストに注意する必要があります(トークンが豊富か貧困かで使用パターンは大きく異なります)。そこで、これが何であり、何を意味するのかを詳しく説明します。

Peter Steinberger氏は最近こう言いました:「もうコーディングエージェントにプロンプトを送るべきではない。エージェントにプロンプトを送るループを設計すべきだ。」同様に、AnthropicのClaude Code責任者であるBoris Cherny氏は「私はもうClaudeにプロンプトを送っていない。Claudeにプロンプトを送り、何をすべきか決定するループが動いている。私の仕事はループを書くことだ」と述べています。

さて、それは一体どういう意味でしょうか?

約2年間、コーディングエージェントから何かを得る方法は、適切なプロンプトを書き、十分なコンテキストを共有することでした。何かを入力し、返ってきたものを読み、次のことを入力する。エージェントはツールであり、あなたが常にそれを操作し、ターンごとに進めていました。その部分は終わりました。あるいは、少なくともそうなるだろうと考える人もいます。

今では、作業を見つけ、割り当て、チェックし、完了したことを記録し、次のことを決定する小さなシステムを構築し、そのシステムにエージェントを操作させるのです。私は以前、このいとこである「エージェントハーネスエンジニアリング」について書きました。これは、単一のエージェントが実行される環境を作ること、そして工場モデル(ソフトウェアを構築するシステム)です。ループエンジニアリングはハーネスの一つ上の階層に位置します。ハーネスにタイマーが付き、小さなヘルパーを生成し、自分自身にフィードバックします。

私を驚かせたのは、これがもはやツールの問題ではないということです。1年前、ループを欲しければ大量のbashスクリプトを書き、それを永久にメンテナンスし、それはあなただけのものでした。今では、その部品は製品に組み込まれています。SteinbergerのリストはほぼそのままCodexアプリにマッピングされ、さらにほぼ同じようにClaude Codeにもマッピングされます。そして、形状が同じであることに気づけば、どのツールが優れているかという議論はやめ、どのツールを使っていても機能するループを設計するだけです。

5つの部品と補足

ループには5つのものと、状態を記憶するための場所が1つ必要です。まずリストし、その後マッピングします。

自動的にスケジュール実行され、発見とトリアージを自分で行う自動化

並列動作する2つのエージェントが互いに干渉しないようにするワークツリー

エージェントが推測するしかなかったプロジェクト知識を記録するスキル

すでに使っているツールにエージェントを接続するプラグインとコネクタ

アイデアを出すエージェントとそれをチェックする別のエージェントを持つサブエージェント

そして6つ目、メモリ。MarkdownファイルやLinearボードなど、単一の会話の外に存在し、何が完了し次に何をすべきかを保持するもの。馬鹿げているように聞こえますが、すべての長期実行エージェントが依存する同じトリックであり、私は「長期実行エージェント」で詳しく説明しました:モデルは実行の間にすべてを忘れるため、メモリはコンテキスト内ではなくディスク上になければなりません。エージェントは忘れますが、リポジトリは忘れません。

現在、両方の製品が5つすべてを備えています。

ループ内のPrimitiveJob Codexアプリ Claude Code

自動化 スケジュールによる発見+トリアージ 自動化タブ:プロジェクト、プロンプト、頻度、環境を選択;結果はトリアージ受信箱に;/goalで完了まで実行 スケジュールタスクとcron、/loop、/goal、フック、GitHub Actions

ワークツリー 並列機能の分離 組み込みのスレッドごとのワークツリー git worktree、--worktree、isolation: worktree(サブエージェントに設定)

スキル プロジェクト知識のコード化 エージェントスキル(SKILL.md)、$nameまたは暗黙的に呼び出し エージェントスキル(SKILL.md)

プラグインとコネクタ ツールへの接続 コネクタ(MCP)と配布用プラグイン MCPサーバーとプラグイン

サブエージェント アイデア出しと検証 .codex/agents/内のTOMLで定義されたサブエージェント .claude/agents/内のタスクサブエージェント、エージェントチーム

状態 完了したものの追跡 コネクタ経由のMarkdownまたはLinear Markdown(AGENTS.md、進行状況ファイル)またはMCP経由のLinear

名前は少し異なりますが、機能は同じです。詳細を一つずつ見ていきましょう。正直なところ、詳細こそがループをまとめるか、静かに漏れ出すかの分かれ目です。

自動化は鼓動

自動化はループを本当のループにし、単なる一度きりの実行でなくします。Codexアプリでは、自動化タブで自動化を作成し、プロジェクト、実行するプロンプト、頻度、ローカルチェックアウトで実行するかバックグラウンドワークツリーで実行するかを選択します。何かを見つけた実行はトリアージ受信箱に送られ、何も見つからなかった実行は自動的にアーカイブされます。これは素晴らしいです。OpenAIは社内で、毎日のイシュートリアージ、CI失敗の要約、コミットブリーフィングの作成、先週追加されたバグの追跡など、退屈なタスクにこれらを使用しています。また、自動化はスキルを呼び出すことができるため、繰り返し発生するタスクを保守可能に保てます。誰も更新しないスケジュールに巨大な指示を貼り付ける代わりに、$skill-nameを実行します。

Claude Codeも同じ場所に到達しますが、スケジューリングとフックを経由します。/loopで間隔を指定してプロンプトやコマンドを実行したり、cronタスクをスケジュールしたり、フックでエージェントライフサイクルの特定の時点でシェルコマンドを実行したり、ラップトップを閉じた後も実行し続けたい場合は全体をGitHub Actionsにプッシュしたりできます。全く同じアイデアです。自律タスクを定義し、頻度を指定し、結果があなたのところに届くので、あなた自身がチェックして回る必要はありません。

もう一つ、セッション内のプリミティブで知っておく価値があるものがあります。それはこの記事全体の核心に近いものです。/loopは一定間隔で再実行されます。/goalは、あなたが書いた条件が実際に真になるまで実行され続け、各ターンの後に別の小さなモデルが完了したかどうかをチェックするため、コードを書いたエージェント自身が評価することはありません。「test/authのすべてのテストが合格し、lintがクリーン」のような条件を指定して、その場を離れます。Codexにも同じ機能があり、同じく/goalと呼ばれています。検証可能な停止条件が成立するまでターンをまたいで動作し、一時停止、再開、クリアが可能です。同じプリミティブ、両方のツールにあり、これがこの記事全体のパターンです。

これが作業を表面化させる部分です。ループの残りの部分は、その作業に基づいて行動します。

ワークツリー、並列が混乱に変わらないために

2つ以上のエージェントを実行すると、ファイルの衝突が始まります。それが失敗の原因です。2つのエージェントが同じファイルに書き込むことは、2人のエンジニアが事前に相談せずに同じ行にコミットするのと同じ頭痛の種です。Gitワークツリーがそれを解決します。これは、同じリポジトリ履歴を共有する独立したブランチ上の別々のワーキングディレクトリであり、一方のエージェントの編集が他方のチェックアウトに物理的に影響を与えることはありません。

Codexはワークツリーサポートを組み込んでおり、複数のスレッドが同時に同じリポジトリにアクセスしても互いに衝突しません。Claude Codeは、git worktree、--worktreeフラグ(独立したチェックアウトでセッションを開く)、およびサブエージェントに設定するisolation: worktree設定(各ヘルパーが自動的にクリーンアップされる新しいチェックアウトを取得)によって同じ分離を提供します。(私は「オーケストレーション税」でこれの人間側について書きました。)ワークツリーは機械的な衝突を取り除きますが、あなた自身が依然としてボトルネックです。あなたのレビュー帯域幅が、実際に実行できるエージェントの数を決定し、ツールではありません。

スキル、毎回プロジェクトを説明するのをやめるために

スキルは、毎セッション同じプロジェクトコンテキストを説明し直すことを防ぎます。まるで金魚のようです。両方のツールは同じ形式を使用します:SKILL.mdを含むフォルダに指示とメタデータ、オプションのスクリプト、リファレンス、アセットが含まれます。Codexは、$または/skillsで呼び出したとき、またはタスクがスキル説明に一致したときに自動的にスキルを実行します。そのため、タイトで退屈な説明が賢い説明よりも優れています。Claude Codeも同じ方法で処理し、私はこのパターンを「エージェントスキル」で説明しました。

スキルはまた、意図を何度も支払うのを防ぎます。私は「意図の負債」で、エージェントは毎回コールドスタートし、あなたの意図の穴を自信に満ちた推測で埋めると主張しました。スキルはその意図を外部に書き留めたものであり、規約、ビルド手順、「あのインシデントのため、このやり方はしない」といったことが一度だけ書かれ、エージェントは実行のたびにそれを読みます。スキルがなければ、ループは毎サイクルプロジェクト全体をゼロから再導出します。スキルがあれば、一種の複利効果が得られます。

一つ注意すべきこと:スキルはオーサリング形式であり、プラグインはそれを配布する方法です。スキルをリポジトリ間で共有したり、複数をまとめてバンドルしたい場合、プラグインとしてパッケージ化します。CodexでもClaude Codeでも同じです。

プラグインとコネクタ、ループが実際のツールに触れる

ファイルシステムだけを見ることができるループは小さなループです。MCP上に構築されたコネクタにより、エージェントはイシュートラッカーを読んだり、データベースにクエリを実行したり、ステージングAPIにアクセスしたり、Slackにメッセージを送信したりできます。CodexとClaude CodeはどちらもMCPをサポートしているため、一方のために書いたコネクタは通常、もう一方でも動作します。プラグインはコネクタとスキルを一緒にバンドルするため、チームメイトは全てを一度にインストールでき、記憶から全体を再構築する必要はありません。

これは、エージェントが「修正方法はこちらです」と言うのと、ループが自動的にPRを開き、Linearチケットをリンクし、CIが成功したらチャンネルに通知するのとの違いです。コネクタこそが、ループが単に「できればこうする」と言うだけでなく、実際の環境内で行動できる理由です。

サブエージェント、書き手とチェッカーを分離する

ループの中で最も有用な構造は、間違いなく書き手とチェッカーを分離することです。コードを書いたモデルは自分の宿題を採点するには甘すぎます。異なる指示(場合によっては異なるモデル)を持つ第二のエージェントが、最初のエージェントが自分を説得してしまった誤りを捕まえます。

Codexは、要求されたときにのみサブエージェントを生成し、それらを同時に実行し、結果を一つの回答に統合します。.codex/agents/内にTOMLファイルで独自のエージェントを定義できます。各エージェントには名前、説明、指示、オプションのモデルと推論努力度があり、セキュリティレビューアーには高努力度の強力なモデルを、エクスプローラーには高速な読み取り専用のものを割り当てられます。Claude Codeも.claude/agents/内のサブエージェントと、それらの間で作業を受け渡すエージェントチームで同じことを行います。両方の一般的な分割は、一つのエージェントが探索し、一つが実装し、一つが仕様に対して検証するというものです。

私はこの主張を既に二度行いました。「コードエージェントオーケストラ」として一回、「敵対的コードレビュー」として一回です。特にループ内でこれが重要な理由は、ループがあなたが見ていない間に実行されるため、実際に信頼できる検証者だけが、あなたがその場を離れることができる唯一の理由だからです。サブエージェントは、各エージェントが独自のモデルとツール作業を行うため、より多くのトークンを消費します。したがって、第二の意見を払う価値がある場所にトークンを使ってください。これは基本的にClaude Codeの/goalが内部で行っていることでもあります。つまり、作業を行ったエージェントではなく、新しいモデルがループが完了したかどうかを決定します。これは、停止条件自体に適用された書き手とチェッカーの分離です。

一つのループの例

全てを組み合わせると、単一のスレッドが小さなコントロールパネルになります。私がよく使う形状の一つを紹介します。

毎朝リポジトリで自動化が実行されます。そのプロンプトはトリアージスキルを呼び出し、昨日のCI失敗、未解決のイシュー、最近のコミットを読み取り、結果をMarkdownファイルまたはLinearボードに書き込みます。実行する価値のある発見ごとに、スレッドは隔離されたワークツリーを開き、サブエージェントを送って修正案を作成させ、第二のサブエージェントがプロジェクトスキルと既存のテストに対してその案をレビューします。

コネクタにより、ループはPRを開き、チケットを更新します。ループが処理できないものは、私のトリアージ受信箱に送られます。状態ファイルが全体の背骨であり、何が試行され、何が合格し、何がまだ残っているかを記憶しています。