⚠️ この記事について
この記事はAI（Claude）を活用して作成しています。
以下の点にご注意ください：
- 情報の鮮度: 記事作成時点（2026年7月26日）の情報です。この分野は動きが非常に速く、内容が古くなる可能性があります
- 動作確認: 本記事で触れるコマンドや機能名は各ツールの公式ドキュメントで最新仕様を必ず確認してください
- 出典の確認: 重要な判断は本文中の参考リンクや一次情報で必ず確認をお願いします
- 誤りの可能性: AI生成コンテンツには誤りが含まれる場合があります。お気づきの点はコメントでご指摘ください
はじめに
コーディングエージェントを毎日使っていると、こんなサイクルに陥っていないでしょうか。
「これをやって」→ 結果を確認 → 「ここを直して」→ また確認 → 「もう一度試して」……
このプロンプトの往復自体をシステムに肩代わりさせようという考え方が、2026年6月に急速に広がった「ループエンジニアリング（Loop Engineering）」です。この記事では、この概念の由来、構成要素、既存ツールでの実装対応、そして提唱者自身が指摘する限界までを、一次情報に基づいて整理します。
ループエンジニアリングとは
ループエンジニアリングは、Googleでエンジニアリング/デベロッパーリレーションズを率いるAddy Osmani氏が2026年6月7日に自身のブログで命名した概念です1[^2]。のちにO'Reilly Radarにも著者本人の許諾のもと転載されています1。
その核となる考え方は、開発者がエージェントに一手ずつ指示を出す役割を、システムそのものに置き換えるというものです。人間が達成したいゴール（目的）を1つ定義すれば、完了条件を満たすまでAIが試行を繰り返す「再帰的なゴール」という発想がベースになっています1。
この用語が広まるきっかけとして、Peter Steinberger氏の「コーディングエージェントに逐一プロンプトを打つのではなく、エージェントにプロンプトを送り続けるループを設計すべきだ」という趣旨の発言と、Anthropicで Claude Code を率いる Boris Cherny 氏の「自分はもうClaudeに直接プロンプトを打っておらず、ループがClaudeにプロンプトを送り、判断も行っている。自分の仕事はループを書くことだ」という趣旨の発言が、Osmani氏の記事内で紹介されています1[^3]。
Osmani氏自身は、この概念を「まだ初期段階であり、自分自身も懐疑的な部分がある」「特にトークンコストには注意が必要」と留保を付けている点も、記事の中で明言しています1。
位置づけ：プロンプト→コンテキスト→ハーネス→ループ
国内の解説記事では、AI駆動開発の進化を次のような世代として整理しているものがあります[^4]。
| 世代 | 名称 | 時期（目安） | 設計対象 |
|---|---|---|---|
| 第1世代 | プロンプトエンジニアリング | 〜2024年 | AIへの「聞き方」 |
| 第2世代 | コンテキストエンジニアリング | 2025年 | AIに「何を渡すか」 |
| 第3世代 | ハーネスエンジニアリング | 2026年初頭 | エージェントが動く環境（ルール・ツール・検証ゲート） |
| 第4世代 | ループエンジニアリング | 2026年6月〜 | AIが自律的にプロンプトを生成し続ける仕組み |
Osmani氏自身も、以前に「エージェントハーネスエンジニアリング」（1つのエージェントが動く環境の設計）について書いており、ループエンジニアリングはそのさらに1段上の抽象度に位置づけられると述べています1。ループは、いわばタイマーで動き、小さなヘルパーを生成し、自分自身にフィードバックを与え続けるハーネスだという説明です1。
ループを構成する5つの要素＋1つの記憶装置
Osmani氏の記事では、ループには次の5つの要素と、それらの状態を覚えておくための仕組みが必要だとされています1。
- オートメーション（Automations）: スケジュールに従って発見とトリアージを自律的に行う仕組み
- ワークツリー（Worktrees）: 複数のエージェントが並行して作業しても互いのファイルを壊さないための分離環境
- スキル（Skills）: エージェントが本来なら推測に頼ってしまうプロジェクト固有の知識を書き残したもの
- プラグイン／コネクタ（Plugins and connectors）: MCP（Model Context Protocol）を通じて既存のツールにエージェントを接続する仕組み
- サブエージェント（Subagents）: 発案するエージェントと、その成果を検証する別のエージェントを分ける仕組み
そして6つ目の要素として、Markdownファイルや課題管理ボードのような「会話の外側に存在する状態（外部状態）」が挙げられています。モデルは実行のたびに文脈を忘れてしまうため、この記憶は会話の中ではなくディスク上に置く必要がある、という説明です1。
主要ツールでの実装対応
Osmani氏の記事では、Codex（OpenAI）とClaude Code（Anthropic）の両方が、記事執筆時点でこの5要素すべてを備えていると整理されています1。
| 要素 | 役割 | Codex app | Claude Code |
|---|---|---|---|
| オートメーション | スケジュールでの発見・トリアージ | Automationsタブでプロジェクト・プロンプト・頻度・実行環境を設定。/goalで完了まで実行継続 |
スケジュールタスクやcron、/loop、/goal、フック、GitHub Actionsとの連携 |
| ワークツリー | 並行作業の分離 | スレッドごとに組み込みのワークツリー |
git worktree、--worktreeフラグ、サブエージェント向けのisolation: worktree設定 |
| スキル | プロジェクト知識の明文化 |
SKILL.mdによるAgent Skills。$呼び出しや暗黙起動 |
同じくSKILL.md形式のAgent Skills |
| プラグイン／コネクタ | 既存ツールとの接続 | MCPベースのコネクタとプラグイン配布 | MCPサーバーとプラグイン |
| サブエージェント | 発案と検証の分離 |
.codex/agents/にTOMLで定義 |
.claude/agents/のタスクサブエージェント、エージェントチーム |
| 状態 | 進捗の記録 | Markdownまたはコネクタ経由のLinear連携など |
AGENTS.mdなどのMarkdownやMCP経由のLinear連携 |
※ 上記は2026年6月時点の記事内容に基づくものです。両ツールの機能名・仕様は変更される可能性があるため、必ず各社の公式ドキュメントで最新情報を確認してください。
各要素の補足
オートメーション：ループの心臓部
オートメーションは、ループを「1回きりの実行」ではなく「本当のループ」たらしめる部分です。Codex appのAutomationsタブでは、対象プロジェクト・実行するプロンプト・実行頻度・ローカルかバックグラウンドのワークツリーかを設定でき、何かを見つけた実行結果はトリアージ用の受信箱に送られ、何も見つからなかった実行は自動的にアーカイブされる、とされています1。OpenAI社内では、日次の課題トリアージやCI失敗の要約、コミットの概要作成、直近のバグ探しなど、地味だが繰り返しの多い作業に使われているとのことです1。
Claude Code側では、/loopによる一定間隔での再実行や、cronタスクのスケジューリング、エージェントのライフサイクルの特定タイミングでシェルコマンドを発火させるフック、GitHub Actionsへの委譲といった形で同様の仕組みが実現されています1。
セッション内のプリミティブとしては、/loopが一定間隔で再実行するのに対し、/goalはあらかじめ書いた条件が満たされるまで実行を続け、各ターンの後に別の小さなモデルが完了判定を行う、つまり作業したエージェント自身に採点させない設計になっている点が紹介されています1。Codexにも同名の/goalがあり、検証可能な停止条件が満たされるまで複数ターンにわたって動作し続け、一時停止・再開・クリアができるとされています1。
ワークツリー：並行実行を壊さないための分離
複数のエージェントを同時に動かした瞬間、ファイルの競合が最大の問題になります。Gitのワークツリーは、同じリポジトリの履歴を共有しつつ別ブランチで独立した作業ディレクトリを持てる仕組みで、これによって一方のエージェントの編集が他方のチェックアウトに物理的に触れられなくなります1。
Codexはこのワークツリー機能を組み込みで提供し、Claude Codeはgit worktreeや--worktreeフラグ、サブエージェントに付与するisolation: worktree設定などで同様の分離を実現しているとされています1。ただし、ワークツリーが解決するのは機械的な衝突だけであり、実際に並行して回せる数の上限は人間側のレビュー可能量が決めるという指摘も記事内でなされています1。
スキル：プロジェクトを毎回説明し直さないために
スキルは、SKILL.mdというファイルにプロジェクト固有の規約やビルド手順、過去のインシデントに基づく「なぜこうしないか」といった知識を書き残す仕組みで、CodexとClaude Codeの両方が同じフォーマットを採用しているとされています1。スキルがなければループはサイクルのたびにプロジェクトを一から推測し直すことになり、あればその知識が積み上がっていく、という説明がなされています1。
なお、個々のスキルを他のリポジトリで共有したり複数まとめて配布したりする単位が「プラグイン」であり、スキル自体は執筆フォーマット、プラグインはその配布手段という整理がされています1。
プラグイン／コネクタ：実際のツールに手を届かせる
ファイルシステムしか見えないループはごく小さな価値しか持ちません。MCPを基盤とするコネクタによって、エージェントは課題管理ツールを読んだり、データベースに問い合わせたり、ステージング環境のAPIを叩いたり、Slackにメッセージを送ったりできるようになります1。CodexとClaude CodeはともにMCPに対応しているため、一方向けに書いたコネクタがもう一方でもそのまま動くことが多いとされています1。
サブエージェント：作った本人に採点させない
ループの中で構造的に最も効果が大きいのが、コードを書くエージェントと、それを検証するエージェントを分離することです。自分が書いたコードを自分で採点するのは、どうしても甘くなりがちだという理由からです1。
Codexは.codex/agents/にTOML形式でサブエージェントを定義し、名前・説明・指示・使用モデル・推論の強度などを個別に設定できます。Claude Codeも.claude/agents/のサブエージェントやエージェントチームという形で同様の仕組みを提供しているとされています1。典型的な役割分担は、1体が調査し、1体が実装し、1体が仕様と照らして検証する、という三分割です1。
具体的なループの例
Osmani氏が記事内で挙げている例を要約すると、次のような流れになります1。
- オートメーションが毎朝リポジトリに対して実行される
- そのプロンプントがトリアージ用のスキルを呼び出し、前日のCI失敗・オープンな課題・直近のコミットを読み込んで、状態を記録するMarkdownファイルや課題管理ボードに書き出す
- 対応する価値のある項目ごとに、独立したワークツリーを開き、1体のサブエージェントが修正案を作成する
- 別のサブエージェントが、そのプロジェクトのスキルと既存のテストに照らして修正案をレビューする
- コネクタを通じてPRを開き、チケットを更新する
- ループが処理しきれなかったものはトリアージの受信箱に残る
- 状態ファイルが「何を試し、何が通り、何が未解決か」を記録し続け、翌朝の実行がそこから再開する
ここでのポイントは、人間はこの一連の手順を1回設計しただけであり、個々のステップを逐一プロンプトしたわけではない、という点です1。
ループエンジニアリングが解決しない3つの問題
Osmani氏は、ループが優れるほど逆に鮮明になる課題として、次の3点を挙げています1。
- 検証は依然として人間の仕事である: 無人で回るループは、無人でミスも起こす。サブエージェントによる検証を分離するのも、ループの「完了」という判定に意味を持たせるためであり、それでも「完了」はあくまで主張であって証明ではない、という指摘です
- 理解の負債（comprehension debt）が拡大する: 自分が書いていないコードが速く出荷されるほど、実際に存在するコードと自分が把握している内容とのギャップが広がる
- 「認知的降伏（cognitive surrender）」の危険: ループが自走するようになると、自分の意見を持つことをやめて出てきたものをそのまま受け入れたくなる誘惑が強まる
また、国内の解説記事でも、生成が自動化されてもレビューと責任は自動化できないという構造的な制約が指摘されており、トークンコストが単発利用の数倍から数十倍に膨らむ可能性や、判断を伴うタスクや一回限りのタスクには向かないといった限界が整理されています[^5]。
まとめ
- ループエンジニアリングは、Addy Osmani氏が2026年6月7日に命名した、AIエージェントに逐一プロンプトを打つ代わりに「プロンプトを送り続けるループ」を設計するという考え方
- ループは①オートメーション、②ワークツリー、③スキル、④プラグイン／コネクタ、⑤サブエージェント、⑥外部状態、という5要素＋1つの記憶装置で構成される
- CodexとClaude Codeは、名称は異なるもののこの5要素すべてを既に備えているとされる
- 提唱者自身がまだ初期段階であり懐疑的な部分もあると明言しており、検証・理解負債・認知的降伏という3つの課題は自動化されない
- 「ループを作る。ただしゴーボタンを押すだけの人間ではなく、エンジニアであり続けるつもりで作る」というのが、提唱者の結びのメッセージです1