ループ・エンジニアリング：AIを「操作」する段階から「システム」を設計する段階へ

ループ・エンジニアリング：コーディングAIを「操作」する段階から「システム」を設計する段階へ Addy Osmani

「ループ・エンジニアリング」とは、自分自身がAIエージェントにプロンプトを出す役割を卒業し、代わりにプロンプトを出し続ける「システム」を設計することです。ここでのループとは、目的を定義すればAIが完了まで反復（イテレーション）し続ける、再帰的なゴールのようなものだと考えてください。これには大きく分けて5つの構成要素があり、現在「Claude Code」と「Codex」のどちらも、そのすべてを備えています。

これが、コーディングエージェントと共に働く未来の姿だと私は信じています。ただし、まだ初期段階であるため、私は慎重な姿勢を崩していません。特にトークンコスト（予算の有無で使い方が激変します）には細心の注意を払う必要がありますし、品質の低下や、いわゆる「AIによる粗製濫造（slop）」への懸念ももっともです。それを踏まえた上で、この概念の正体を探っていきましょう。

先日、@steipete はこう述べました。「もうコーディングエージェントにプロンプトを出すべきではない。エージェントにプロンプトを出す『ループ』を設計すべきなのだ」。同様に、AnthropicのClaude Code責任者である @bcherny もこう語っています。「私はもうClaudeにプロンプトを出しません。Claudeを叩いて何をすべきか判断させるループを回しています。私の仕事はループを書くことなのです」。

さて、これはいったいどういう意味でしょうか？

ここ2年ほど、コーディングエージェントから成果を引き出す方法は、優れたプロンプトを書き、十分なコンテキスト（文脈）を共有することでした。人間が何かを入力し、返ってきた内容を読み、次の指示を出す。エージェントはあくまで道具であり、人間がつきっきりで一歩ずつ操作していました。しかし、その時代は終わりつつある、少なくとも一部の人々はそう考えています。

これからは、仕事を見つけ、それを割り振り、チェックし、進捗を記録して次の行動を決定する「小さなシステム」を構築します。人間ではなく、そのシステムがエージェントを突き動かすのです。私は以前、これに類する概念として、単一エージェントの動作環境を作る「エージェント・ハーネス（馬具）・エンジニアリング」や、ソフトウェアを構築するシステムである「ファクトリー・モデル」について書きました。ループ・エンジニアリングは、その「ハーネス」の一段上に位置します。タイマーで起動し、小さなヘルパーを生成し、自ら学習し続けるハーネスのようなものです。

驚いたのは、これがもはや特定の「ツール」の話ではなくなったことです。1年前なら、ループを作ろうと思えば大量のBashスクリプトを書き、それを延々とメンテナンスする必要がありました。それは自分専用の秘伝のタレでした。しかし今では、その構成要素が製品そのものに組み込まれています。Steinberger氏が挙げたリストはCodexアプリの機能とほぼ一致し、Claude Codeとも酷似しています。共通の形が見えてくれば、どのツールを使うかという議論は重要ではなくなります。どの環境にいても機能するループを設計すればいいだけだからです。

ループを構成する5つの要素（と1つの記憶） ループには5つの要素と、情報を記憶する1つの場所が必要です。まずはリストアップし、それぞれ解説します。

オートメーション：スケジュールに従って起動し、自律的に課題の発見とトリアージ（優先順位付け）を行う。 ワークツリー：並行して働く複数のエージェントが、互いの作業を邪魔しないようにする。 スキル：放っておくとエージェントが勝手に推測してしまう「プロジェクト固有の知識」を明文化したもの。 プラグインとコネクタ：エージェントを既存のツール（SlackやGitHubなど）と連携させる。 サブエージェント：アイデアを出す役と、それをチェックする役を分ける。 そして6つ目が、メモリ（記憶）です。MarkdownファイルやLinearのボードなど、単一の会話の「外」に存在し、完了したことと次にやるべきことを保持する場所です。単純すぎて重要に見えないかもしれませんが、これは長期稼働するエージェントに不可欠なトリックです。モデルは実行のたびにすべてを忘れてしまうため、記憶はコンテキスト（チャット履歴）内ではなく、ディスク上に置かなければなりません。エージェントは忘れても、リポジトリは覚えているのです。

現在、両方の製品がこれら5つの機能を備えています。名称は多少異なりますが、できることは同じです。詳細を見ていきましょう。

1. オートメーション：ループの「鼓動」

オートメーションこそが、単発の実行を「ループ」へと変える心臓部です。Codexでは、プロジェクト、実行するプロンプト、頻度、ローカルかバックグラウンドのワークツリーかを選択して作成します。何かを発見した実行結果はトリアージ用の受信箱に送られ、何もなかった場合は自動でアーカイブされます。OpenAIの内部では、日々のIssueトリアージやCI失敗の要約、コミットの概要作成、バグ探しなどの退屈な作業に使われています。

Claude Codeも、スケジューリングとフックを通じて同じことを実現しています。/loop で一定間隔ごとにコマンドを実行したり、cronタスクを設定したり、あるいはGitHub ActionsにプッシュしてPCを閉じた後も動かし続けることができます。どちらも「自律的なタスクを定義し、リズムを与え、結果が自分の元に届くようにする」という考え方は共通しています。

また、/goal というコマンドも重要です。これは設定した条件（例：「すべてのテストが通り、Lintがクリーンであること」）が満たされるまで、エージェントが自律的に試行錯誤を繰り返す機能です。別の小さなモデルが完了判定を行うため、コードを書いた本人が採点するようなミスも防げます。

1. ワークツリー：混乱を防ぐ並行処理

複数のエージェントを走らせた瞬間、ファイルの競合が始まります。2つのエージェントが同じファイルを書き換えるのは、2人のエンジニアが相談なしに同じ行を編集するのと同じ頭痛の種です。これを解決するのが git worktree です。履歴を共有しつつ別々のブランチ・ディレクトリで作業させるため、エージェント同士の編集が干渉することはありません。

Codexにはこの機能が組み込まれており、Claude Codeでも --worktree フラグや設定によって、サブエージェントごとに独立した環境を割り当てることができます。ただし、物理的な衝突はツールが防いでくれますが、それをレビューする人間のキャパシティがボトルネックになるという「オーケストレーション税」については忘れてはいけません。

1. スキル：説明の繰り返しをなくす

「スキル」とは、金魚のように毎セッション同じプロジェクトの説明を繰り返さなくて済むようにするための仕組みです。両ツールとも、SKILL.md ファイルに指示やメタデータを記述する形式を採用しています。

スキルがあれば、エージェントが勝手な推測で動く（意図の負債）を防げます。「このプロジェクトでは、過去のトラブルからこういう書き方はしない」といった暗黙のルールを一度書いておけば、エージェントは実行のたびにそれを読み込みます。スキルがなければ毎サイクル知識がリセットされますが、スキルがあれば知識は「蓄積」されていきます。

1. プラグインとコネクタ：現実のツールへの接続

ファイルシステムしか見えないループは、ごく小さな世界でしか機能しません。MCP（Model Context Protocol）ベースのコネクタを使えば、エージェントはIssue管理ツールを読み、データベースにクエリを投げ、Slackにメッセージを送れるようになります。

これにより、「修正案はこれです」と言うだけのエージェントが、「プルリクを出し、チケットを紐付け、CIが通ったらSlackで通知する」という実務をこなすループへと進化します。

1. サブエージェント：作る役とチェックする役の分離

ループの中で最も有用な構造は、コードを書く役とチェックする役を分けることです。自分で書いたコードの採点は、どうしても甘くなりがちです。別の指示（あるいは別のモデル）を与えられた第2のエージェントがチェックすることで、思い込みによるミスを防げます。

CodexやClaude Codeでは、.codex/agents/ や .claude/agents/ に設定を置くことで、セキュリティ担当、実装担当、検証担当といった役割分担をさせることができます。ループは人間が見ていないところで回るため、信頼できる「検証役」がいて初めて、安心して席を外すことができるのです。

ループの具体的な形 これらを組み合わせると、一つのスレッドが小さな制御パネルになります。私がよく使うパターンはこうです。

毎朝、リポジトリでオートメーションが実行される。 そのプロンプトが「トリアージ・スキル」を呼び出し、昨日のCI失敗やIssue、コミットを読み込み、結果をMarkdownに書き出す。 対応が必要な項目ごとに、ワークツリーを開いて「サブエージェント」に修正案を作成させ、別のサブエージェントが「プロジェクト・スキル」に照らしてレビューする。 コネクタがPRを作成し、チケットを更新する。 手に負えないものだけが、私の受信箱に届く。 「状態管理ファイル（記憶）」がすべてを記録しているため、翌朝は前日の続きから再開できる。 ここで重要なのは、あなたはシステムの設計を一回しただけで、個々のステップでプロンプトを打ってはいないということです。これがSteinberger氏の言う「ループを設計する」ことの実体です。

ループが解決してくれないこと ループは仕事の性質を変えますが、人間の役割を消し去るわけではありません。むしろ、ループが優秀になるほど、次の3つの問題が先鋭化します。

検証の責任：放置されたループは、放置されたままミスを犯します。「完了した」というエージェントの主張は、あくまで主張であり証明ではありません。最終的に動作を確認し、デプロイの責任を持つのは人間です。 理解の減衰：自分が書いていないコードが高速で量産されると、現実のコードと自分の理解の間に大きな溝が生まれます。これを放置すると「理解の負債」が積み上がります。 認知的降伏：ループが勝手に回っていると、思考を停止して「AIが出した結果でいいや」と妥協したくなります。ループの設計は、意志を持って行えば強力な武器になりますが、考えるのを避けるために行えば、破綻を早める加速装置になってしまいます。 ループを築き、エンジニアであり続けろ これは私たちの働き方がどう進化するかを示す予兆です。しかし、私自身がコードをレビューしなくなったり、自動ループだけに修正を頼り切ったりすれば、製品の品質は間違いなく低下し、負のスパイラルに陥るでしょう。

ループを構築するのは素晴らしいことですが、直接プロンプトを出すことが有効な場面も依然としてあります。大切なのはバランスです。

同じループを作っても、使い手によって結果は真逆になります。一方は、深く理解している領域でさらに加速するために使い、もう一方は、理解することを避けるために使います。ループはその違いを区別しませんが、あなたにはわかるはずです。

だからこそ、ループ・エンジニアリングはプロンプト・エンジニアリングよりも難しいのです。仕事が楽になったのではなく、「レバレッジ（梃子）をかける場所」が変わっただけなのです。

ループを築きましょう。ただし、単に「実行ボタンを押す人」ではなく、エンジニアであり続ける意志を持って。