Peter Steinbergerは最近、「あなたはもうコード代理にプロンプトを送るべきではない。代理をプロンプトするループを設計すべきだ」と言いました。AnthropicのClaude Code責任者Boris Chernyも似たようなことを言っています：「私はもうClaudeにプロンプトを送らなくなった。ループを走らせてClaudeにプロンプトさせ、そのループ自身が何をすべきか決める。」
Claude Codeも同じ仕組みを使いますが、経路が少し異なり、スケジューリングとhooksを通じて実現します。/loopを使えば、promptやコマンドを間隔を空けて再実行でき、cronを設定したり、hooksを使って代理のライフサイクルの特定ポイントでシェルコマンドを実行したり、GitHub Actionsに連携させて、ノートPCを閉じた後も動かし続けることも可能です。基本的な考え方は同じ：自動タスクを定義し、リズムを与え、自動的に結果を提示させる。あなたは手動で翻訳しなくて良い。
Googleエンジニアが教えるループエンジニアリングとは何か？五つの積み木＋外部記憶、2026年のAI必修科目
ループエンジニアリングは、自分でプロンプト代理を行う仕組みを、あなたが設計したシステムに置き換えることです。ここでいう「ループ」は、目的を定義し、AIが繰り返し改善を続けて完了するまでの再帰的な目標と理解できます。これがおそらく、私たちが未来においてコーディング代理と協働する方法になると信じています。
ただし、前置きとして言えば、これはまだ非常に初期段階です。私自身も疑問を持っており、またトークンコストには絶対に注意を払う必要があります。これについて分解して話します：それは何か、そして何を意味するのか。
Peter Steinbergerは最近、「あなたはもうコード代理にプロンプトを送るべきではない。代理をプロンプトするループを設計すべきだ」と言いました。AnthropicのClaude Code責任者Boris Chernyも似たようなことを言っています：「私はもうClaudeにプロンプトを送らなくなった。ループを走らせてClaudeにプロンプトさせ、そのループ自身が何をすべきか決める。」
過去約2年、コード代理から結果を得るには、良いpromptを書き十分なコンテキストを提供する必要がありました。あなたは一文を書き、応答を読み、次の一文を書き足す。代理はツールであり、あなたは最初から最後までそれを握り、何度も繰り返す。そうした段階はほぼ終わりつつあり、少なくともそう考える人もいます。
今あなたがやることは、小さなシステムを構築することです：それは仕事を探し、割り当て、検査し、完了したものを書き留め、次に何をすべきか決める。これを、あなたが直接代理を操作するのではなく、そのシステムに任せるのです。私は以前、「エージェントハーネスエンジニアリング」という近縁の概念について書きましたが、それは単一の代理を動かす環境、すなわちソフトウェアの「工場モデル」を構築することでした。
ループエンジニアリングは、そのハーネスの一段上の概念です：ハーネスはそのままに、定期的に動き、小さな助手を生み出し、自分自身にフィードバックを与える。
驚いたことに、これはもはやツールのレベルを超えています。1年前は、ループを作るにはbashスクリプトを積み重ねて自分で管理しなければならず、それは個人の作業でした。今や、これらの部品は製品に直接組み込まれています。Steinbergerのリストはほぼ完全にCodexアプリに対応し、さらにClaude Codeにもほぼ完全に対応しています。形状が実は同じだと気付けば、「どのツールを使うか」で揉めることはなくなり、どのツールに座っていても動作するループを設計するだけです。
五つの積木といくつかの備考
一つのループには五つの要素と、記憶の場所が必要です。まず列挙し、それを対応させます。
そして第六の要素：記憶です。MarkdownファイルやLinearの看板など、単一の対話外に存在し、「何をしたか」「次は何をするか」を記録するものなら何でも良い。馬鹿げていると思われるかもしれませんが、長時間動作する代理はこれに依存しています。長期的なエージェントについても触れましたが、モデルは実行の間にすべてを忘れるため、記憶はディスク上に保存し、コンテキスト内に置かない必要があります。代理は忘れるが、リポジトリは忘れない。
今、二つの製品はこの五つの要素をすべて備えています。
| 原語 | | --- | | ループ内の役割 | | Codex app | | Claude Code | | --- | --- | --- | --- | | Automations | | スケジュールによる発見と振り分け | | Automationsタブ：プロジェクト選択、プロンプト、頻度、ローカルチェックアウトかバックグラウンドワークツリーかを設定；結果はトリアージの受信箱へ；/goalは完了まで実行 | | スケジュールタスクとcron、/loop、/goal、hooks、GitHub Actions | | Worktrees | | 並行開発の隔離 | | 各スレッドに内蔵されたworktree | | git worktree、--worktree、サブエージェントの隔離設定：worktree | | Skills | | プロジェクト知識のコード化 | | Agent Skills（SKILL.md）、$nameまたは暗黙呼び出し | | Agent Skills（SKILL.md） | | Plugins / connectors | | ツールへの接続 | | MCP上のConnectorsと配布用プラグイン | | MCPサーバーにプラグイン追加 | | Sub-agents | | 構想と検証 | | .codex/agents/内にTOML定義 | | .claude/agents/内のTask subagents、agent teams | | State | | 完了状態の追跡 | | MarkdownまたはLinear連携のコネクタ | | Markdown（AGENTS.md、進捗ファイル）またはMCP経由のLinear連携 |
名前や場所は少し異なるが、本質的な能力は同じです。一つずつ展開して説明します。なぜなら、正直なところ、魔の細部に潜むのはこれらの詳細だからです：ループが安定して動き続けるか、こっそり抜け落ちるかは、これらの細部次第です。
Automations：ループの心臓部
Automationsこそ、「ループ」を本当にループたらしめる仕組みです。単なる一度きりの処理ではなく、継続的に動き続ける仕組みです。Codex appでは、Automationsタブにて、プロジェクト、実行するprompt、頻度、ローカルチェックアウトか背景ワークツリーかを設定します。発見があればトリアージの受信箱に入れ、なければ自動的にアーカイブされる仕組みです。
OpenAIの内部でも、日々のissue振り分け、CI失敗の要約、コミットブリーフィング、先週のバグの追跡などに使われています。Automationはskillを呼び出すこともできるため、周期的なタスクの管理も容易です：$skill-nameをトリガーするだけで、複雑なコマンド群をスケジュールに貼り付ける必要はありません。
Claude Codeも同じ仕組みを使いますが、経路が少し異なり、スケジューリングとhooksを通じて実現します。/loopを使えば、promptやコマンドを間隔を空けて再実行でき、cronを設定したり、hooksを使って代理のライフサイクルの特定ポイントでシェルコマンドを実行したり、GitHub Actionsに連携させて、ノートPCを閉じた後も動かし続けることも可能です。基本的な考え方は同じ：自動タスクを定義し、リズムを与え、自動的に結果を提示させる。あなたは手動で翻訳しなくて良い。
また、セッション内の原語も重要です。/loopはリズムに合わせて再実行、/goalはあなたが設定した条件が真になるまで実行し続ける。各ラウンドの終了時に、小さなモデルが完了判定を行います。つまり、「コードを書いたモデル」ではなく、「検査を行うモデル」が完了判定を担います。
例えば、「test/authのすべてのテストが通り、lintも問題なし」といった条件を与えると、その条件が成立するまで何度も実行されます。Codexにも同じ/goalがあり、複数ラウンドにわたって停止条件が成立するまで実行され、pauseやresumeも可能です。同じ原語が二つのツールに存在し、これがこの文章のパターンの基本です。
これらは「仕事を見える化する」仕組みです。残りは「これらの仕事に対して何かを行う」部分です。
Worktrees：並行性の混乱を防ぐ
複数の代理を同時に動かすと、ファイルの衝突が起きやすくなります。二つの代理が同じファイルを書き、まるで二人のエンジニアが同じコード行にコミットし、事前に打ち合わせしなかったのと同じ痛みです。git worktreeはこれを解決します：別の作業ディレクトリを持ち、独自のブランチを持ち、同じリポジトリの履歴を共有します。これにより、一つの代理の編集は物理的に他の代理のチェックアウトと干渉しません。
Codexはworktreeのサポートを内蔵しており、複数のスレッドが同じリポジトリを同時に操作しても衝突しません。Claude Codeはgit worktreeや--worktreeフラグ（セッションごとに独立したcheckoutを開く）、およびサブエージェントに貼るisolation: worktree設定（各助手に新しいcheckoutを割り当て、完了後に自動的に消す）を使って同じ隔離を実現しています。私の「オーケストレーションの負担」についての文章では、人間の観点からこの仕組みを説明しています：worktreeは機械的な衝突を解決しますが、あなたのレビュー能力が実際に動かせる代理の数を決めるのです。
Skills：もう毎回プロジェクトを説明しなくて良い
Skillは、セッションごとに同じプロジェクトの脈絡を何度も繰り返し説明する必要をなくします。両ツールとも、同じフォーマットを採用：一つのフォルダにSKILL.mdを置き、コマンドやメタデータ、必要に応じてスクリプトやリファレンス、アセットを格納します。Codexは$や/skills呼び出し時にskillを実行し、タスクがスキルの記述に合致すれば自動的に実行します。これにより、正確でつまらない記述が、見た目の良い賢い記述に勝つ理由となります。Claude Codeも同様の仕組みを採用しています。
Skillは、「意図を一度書けば何度も使える」仕組みでもあります。私は「意図の負債」についても言及しました：代理は毎回セッション開始時にゼロから始めるため、自信を持って推測し、あなたの意図の穴を埋めていきます。Skillは、その意図を外部に書き出すことです—慣例やビルドステップ、「前回のイベントを踏まえる」など。これを一度書けば、代理は毎回それを読み込み、蓄積していきます。Skillのないループは毎回ゼロからプロジェクト全体を推し進めるが、Skillがあれば、徐々に複利的に蓄積されていきます。
一つ注意点：Skillは書式であり、Pluginは配布方法です。複数リポジトリ間でSkillを共有したり、複数のSkillをまとめてパッケージ化したい場合は、Pluginとしてまとめます。Codexもそうですし、Claude Codeも同じです。
Pluginsとconnectors：ループがあなたの本当のツールに手を伸ばす
ファイルシステムだけを見るループは、小さなループです。ConnectorsはMCPの上に構築され、代理がissue trackerを読む、データベースを参照する、ステージングAPIを叩く、Slackにメッセージを送るといったことを可能にします。CodexもClaude CodeもMCPを語っているため、あなたが一つのコネクタを書けば、もう一つもほぼそのまま使えます。Pluginsは、connectorsとskillsをまとめてパッケージ化し、チームメンバーが一度に設定をインストールできるようにします。
これが、「代理が『これを修正すれば良い』と教える」だけではなく、「ループが実環境で実際にPRを作成したり、Linearのチケットを更新したり、CIが成功したら通知したり」できる理由です。connectorsは、ループがあなたの実環境で実際に動作し、手を動かすための根拠となるものです。
Sub-agents：作る人と検査する人を分離
ループの中で最も重要な構造的手段は、「書く人」と「検査する人」を分離することです。コードを書いているモデルが自分に点数をつけるのは甘すぎる。別の指示を出す、時にはモデル自体も異なる二つ目の代理を用意し、最初の自己説得を検証させるのです。
Codexは、呼び出したときだけサブエージェントを生成し、並行して動かし、その結果を一つの答えに折りたたみます。あなたは.codex/agents/内に代理をTOMLで定義し、name、description、instructions、必要に応じてmodelやreasoning effortを設定します。安全審査用の強力なモデル、探索用の高速・読み取り専用モデルなどを使い分けることも可能です。Claude Codeも同様に、.claude/agents/内のサブエージェントやエージェントチームを使って、作業を代理間で伝達します。一般的な分離法は：探索と実装、そして仕様に対する検証です。
私は以前、「コードエージェントオーケストラ」や「敵対的コードレビュー」などを提唱しました。ループ内でこれらが特に重要なのは、ループはあなたが見ていない間に動くからです。信頼できる検証者は、「安心して進める」唯一の理由です。サブエージェントはトークンを多く消費しますが、その分「第二の意見」を得るために使います。Claude Codeの/goalは、基本的にこうした仕組みです：新たなモデルがループの完了を判断し、コードを書いたモデルではなく、「検査を行うモデル」が完了判定を行います。
一つのループの形
これらを組み合わせると、一つのスレッドは小さなコントロールパネルのようになります。私がよく使う形は次の通りです。
毎朝、Automationsがリポジトリ上で動きます。promptはトリアージスキルを呼び出し、昨日のCI失敗、未解決issue、最近のコミットを読み取り、それらをMarkdownファイルやLinear看板に記録します。重要な発見ごとに、そのスレッドは隔離されたworktreeを開き、サブエージェントに修正案を草案させ、次に別のサブエージェントがプロジェクトのスキルと既存のテストを使ってその草稿を検査します。
コネクタはPRを作成したり、チケットを更新したりします。処理できないものはトリアージの受信箱に入れ、状態ファイルは全体の脊椎です。何を試し、何を通過し、何がまだ開いているかを記録します。これにより、翌朝のループは前回の続きから始められます。
振り返れば、あなたは一度だけ設計すれば良いのです。どのステップもあなたがpromptする必要はありません。これがSteinbergerの言葉の具体的な実現です。同じループはCodexとClaude Codeの両方で動きます。なぜなら、部品は同じだからです。
ループが未だにやってくれないこと
ループは仕事の形を変えましたが、あなたを排除したわけではありません。さらに、ループが改善されるにつれて、より鋭くなる問題もあります。
検証は依然あなたの仕事です。 監視されていないループは、誤りを見逃すループでもあります。Verifierサブエージェントと作成者を分離する理由は、「完了」の意味を持たせるためです。とはいえ、「完了」はあくまで主張であり、証明ではありません。私は「AI時代のコードレビュー」でも同じことを繰り返しています：あなたの仕事は、「自分で確認したコードを出荷」することです。
理解は腐り続ける可能性がある。 ループの出荷が「あなたが書いたものではない」ほど、実際に存在するものとあなたが持つもののギャップは拡大します。これが「理解負債」です。スムーズなループはこれをより早く増大させるだけです—ただし、あなたがループの中身を読むなら別です。
快適な姿勢は危険な姿勢です。 ループが自動で動いているとき、あなたは何も意見を持たずに受け入れたくなるでしょう。それを「認知的降伏」と呼びます。ループを設計するときは、判断力を持っているときにこそ有効です。思考を避けたいときには逆に加速させる仕組みです—同じ動作でも結果は逆になります。
ループを構築しつつ、エンジニアとしての立場を保つ
これが私たちの未来の働き方の予告だと思います。もちろん、コードを自分でレビューしない、または完全に自動ループに任せて修正すれば、製品の品質は落ちます。私は沈み込みのスパイラルに陥り、どんどん深く掘り進めてしまうでしょう。
つまり、ループを構築することは重要ですが、同時に代理に直接promptを送ることも依然として有効な方法です。すべてはバランスを見つけることに尽きます。
また、ループは「人」によって大きく結果が変わります。二人が全く同じループを使えば、全く逆の結果を得ることもあります。一人は深く理解している仕事を加速させるために使い、もう一人は理解を避けるために使う。差異を見極められるのは、そのループの使い方次第です。
だからこそ、prompt engineeringよりもループ設計の方が難しいのです。Chernyのポイントは、仕事が簡単になったのではなく、レバレッジのポイントが移動したことです。
ループを構築してください。ただし、「エンジニアとして続けるつもり」のように設計し、「ただスイッチを押すだけ」のように作らないことです。