ループエンジニアリングとは？既存の手法との違いからAIエージェント時代の開発組織マネジメント・導入ステップまでを解説

「もうコーディングエージェントにプロンプトを打つな。エージェントにプロンプトするループを設計するんだ」――2026年6月、この一言がエンジニアリングコミュニティで約150万インプレッションを集めました。

Anthropicで Claude Code の開発を率いるBoris Cherny氏は「私はもうClaudeにプロンプトを出していない。ループが走っており、そのループがClaudeにプロンプトを出している。私の仕事はループを書くことだ」と語ります。GoogleのAddy Osmani氏はこの動きを「ループエンジニアリング（Loop Engineering）」と命名し、定式化しました。

本記事では、ループエンジニアリングの定義・背景から、ハーネスエンジニアリングとの違い、チームが整備すべき6つのインフラ、組織として向き合うべき4つの課題と対処法まで、開発組織を率いるエンジニアリングマネージャー・技術リーダーの方に向けて整理します。

本記事のサマリー

ループエンジニアリングとは：人間がAIにプロンプトを打つのではなく、AIにプロンプトを自動投入して自律的に開発サイクルを回す「ループ」を設計・構築する手法。2026年6月にAnthropicのClaude Code責任者Boris Cherny氏の発言を起点に、GoogleでGoogle Cloud AIのディレクターを務めるAddy Osmani氏が整理・定式化した。
ハーネスエンジニアリングとの違い：ハーネスがエージェントの実行環境を整えるのに対し、ループはそのハーネスを継続的に起動・検証・制御する制御レイヤーにあたり、1つ上の階層に位置する。
チームが整備すべき6つのインフラ：Automations・Worktrees・Skills・Connectors / MCP・Sub-agents・Memoryの6要素を、個人の設定ではなくチームの共有インフラとして管理することがカギ。
組織として向き合う4つの課題：自律化が進むほど検証の死角・理解の負債・認知的降伏・コスト増のリスクが高まる。品質ゲートとHuman-in-the-loop（HITL）の設計が急務。

ループエンジニアリング（Loop Engineering）とは何か

2026年6月に生まれた、現在進行形の概念

“Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore.
You should be designing loops that prompt your agents.”

（もうコーディングエージェントにプロンプトを打つな。エージェントにプロンプトするループを設計するんだ）
— Peter Steinberger（OpenClaw, Creator）※1

2026年6月、開発者のPeter Steinberger氏（OpenClawの作者）がX（旧Twitter）に投じた一言が、公開直後に約150万インプレッションを記録、その後もインプレッションは伸び続けており、エンジニアリングコミュニティで大きな注目を集めました。

同じ頃、AnthropicでClaude Codeの開発を率いるBoris Cherny氏（以下、Cherny氏）が、招待制イベント「Acquired Unplugged」（WorkOS主催、2026年6月2日）でこう語っています。

“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

（私はもうClaudeにプロンプトを出していません。ループが走っており、そのループがClaudeにプロンプトを出して何をすべきかを判断しています。私の仕事はループを書くことです）
— Boris Cherny（Anthropic, Claude Code Lead）※2

続いて、GoogleでGoogle Cloud AIのディレクターを務めるAddy Osmani氏（以下、Osmani氏）が2026年6月7日、これを「Loop Engineering（ループエンジニアリング）」という名称でブログ記事にまとめ、概念を定式化しました。※3

これらの発言や記事を読んでいくと「別にそれって当たり前のことでは？」と感じる方もいるかもしれません。しかし彼らが言っていることの本質は、「AIにプロンプトを打つ作業を、AIが自動でやるシステムに代替させた」という点にあります。

この変化の本質は、「AIをより上手く使えるようになった」という単なるスキルの話ではありません。AIに任せる仕事量が増えたという量的変化でもなく、便利なツールの使い方を習得するという個人の習熟の話でもありません。「AIを操作する主体が、人間からシステムへ移行した」という構造的かつ質的な転換であり、エンジニアが価値を生む抽象化の層が一段上がったという、仕事の構造そのものの変化だといえます。

ループエンジニアリングの定義

Osmani氏はループエンジニアリングをこう定義しています。

“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

（エージェントにプロンプトを打つ自分自身を置き換えること。代わりにそれをやってくれる仕組みを設計することだ）
— Addy Osmani（Google, Engineering Director）※3

これをもう少し噛み砕くと、ループエンジニアリングとは「人間がAIエージェントに都度プロンプトを打つのをやめ、AIにプロンプトを自動投入して目標達成まで自律的に回り続けるシステム（ループ）を設計・構築する手法」となります。

Cherny氏は自身の開発スタイルの変化を3つのフェーズで説明しています。※2

1年前（2025年頃）：IDEを開き、AIの自動補完を使いながら1文字ずつコードを書いていた
2025年11月頃：IDEをアンインストール。5〜10個のClaudeを並行して走らせ、自分がプロンプトを出してコードを書かせるスタイルへ
現在（2026年6月）：Claudeにプロンプトすら打たない。自動でClaudeにプロンプトを投入し、何をすべきかを判断し続けるループを稼働させている

Cherny氏は、この変遷をプログラミングの歴史における抽象化の進化（パンチカード→アセンブリ→C言語→Python）と同じ流れの、現代における最新の到達点だと表現しています。

なぜ「ループ」という概念が今のタイミングで出てきたのか？その3つの背景とは？

ループエンジニアリングの概念自体は突然生まれたものではありません。ですが、「いつか実現すべき理想的な考え方」ではなく「現実に今動かせるもの」として成立できるようになったのは、以下の3つの大きな変化が重なったからだと考えます。

① AIモデルの自律性が向上した

2025年から2026年にかけてAIモデルの能力が飛躍的に向上し、1つの指示に対して複数ステップを自律的に判断・実行できるようになりました。以前のモデルでは「次に何をすべきか」を人間が毎回補足する必要がまだありましたが、今のモデルでは指示の曖昧さをAI自身が解釈しながらタスクを進められるようになりました。

② AIコーディングエージェントにループの機能が標準搭載された

Claude Code（Anthropic）やCodex（OpenAI）といった、エンジニアが日常的に使うAIコーディングエージェントが、ループを成立させるための仕組みを標準機能として搭載するようになりました。以前はループを動かすにはbashスクリプトを自前で書いてメンテナンスし続ける必要がありましたが、今ではそのようなインフラがツールに最初から組み込まれているため、利用のハードルが大きく下がりました。

③ プロンプト・コンテキスト・ハーネスが積み上がり、ループの素地が整った

プロンプトの作り方が体系化され、コンテキスト設計でAIに渡す情報環境が整い、ハーネスでエージェントの実行環境が安全に動くようになりました。これらの3つの層が積み上がったことで、「ここまで揃ったなら、もう人間が毎回操作しなくてもいいのでは？」という発想が自然に生まれるようになりました。

開発組織は「労働集約型」から「プラントエンジニアリング型」へ

これまでのソフトウェア開発組織は、良くも悪くも「労働集約型」の側面を残していました。なぜなら「何人のエンジニアが、どれだけの時間をかけて、何本のPRを出したか」がベロシティの基準だったからです。

一方、ループエンジニアリングが進んだ世界ではこの前提が根本からガラリと変わります。エンジニアの主業務が「コードという製品を直接生産すること」から「24時間自律的に実行されるループシステムを設計・保守・監査すること」へと変わるからです。Boris Cherny氏の「私の仕事はループを書くことだ」という言葉は、まさにこの転換を象徴しています。

そのため、組織のリーダーが見るべき指標も変わってきます。「誰がどれだけ実装したか」という個人の生産量から、「自組織のループがいかに手戻りなく、自律的に機能拡張やバグ修復を行えるか」といった、いわば「ループの設計品質」が新たなケイパビリティになります。

Findyでは、ループエンジニアリングの到来に先立って、AI時代に求められる開発生産性の新たな捉え方として「開発資本」を策定し、Speed（速く作り、出し、学べているか）・Quality（手戻りなく前に進めているか）・Control（変更を制御できているか）の3つの観点で開発組織の状態を把握することを提唱しています。

開発組織を率いる立場の方にとっては、今後、マネジメントで見るべきポイントが大きく変わっていくという認識が必要となってきそうです。

AI活用の進化を「チームの役割変化」として理解する

ループエンジニアリングを正しく理解するには、ここに至るまでのAI活用の流れを整理しておく必要があります。なお、以下の「4世代」は厳密な年代区分ではなく、AI活用における抽象化レイヤーの変化を整理するための便宜的な区分けとなります。

図1 AI活用の4世代モデル

第1世代：プロンプトエンジニアリング（〜2024年）

AIとのやり取りの質を上げる工夫としてプロンプトエンジニアリングが登場しました。言い回しを整え、例を示し、出力フォーマットを指定することで期待する回答に近づける手法で、「Few-shot prompting」「Chain of Thought」「Role prompting」などのテクニックが研究・実践されました。ここでは「いかに良い指示を出せるか」という個人スキルが価値の中心にありました。

プロンプトエンジニアリングの詳細についてはこちらの記事で解説しています。

チームへの意味：「AIを上手く使える個人」が希少価値を持ち、個人のスキル差がそのままアウトプット差になっていた時代です。チームとして取り組む課題というよりも、個人の習熟度に依存していました。

第2世代：コンテキストエンジニアリング（2025年）

AIに渡す情報環境全体（システム指示・ツール定義・記憶・過去の履歴・検索結果まで）を設計する考え方としてコンテキストエンジニアリングが登場しました。Anthropicではこれを「プロンプトエンジニアリングの自然な発展形」と位置づけています。単発の問いを磨くのではなく、AIが推論時に目にするコンテキスト全体を最適化する視点へシフトしました。

コンテキストエンジニアリングの詳細についてはこちらの記事で解説しています。

チームへの意味：「AIに何を見せるか」がコードベースのドキュメント整備や仕様の明文化と直結するようになりました。AIの精度はチームの情報管理の質と切り離せなくなり、個人の工夫から「チームとしての情報設計」へ視点が移り始めました。

第3世代：ハーネスエンジニアリング（2026年初頭）

エージェントが安全かつ効果的に動くための「実行環境（ハーネス）」を設計する手法としてハーネスエンジニアリングが登場しました。また、ハーネスエンジニアリングの登場によって下記のような考え方が生まれました。

「エージェント＝モデル＋ハーネス」

ハーネスとは、モデルを包む実行環境のすべて（プロンプト設計・ツール群・制約・フィードバック機構・検証ゲートなど）を指します。同じモデルでもハーネスを変えるだけでパフォーマンスが大きく変わる事例が複数報告されており、「モデルに問題があるのではなく、ハーネスの設計に問題がある」という発想の転換が起きました。

ハーネスエンジニアリングの詳細についてはこちらの記事で解説しています。

チームへの意味：「モデルではなくハーネスが性能を決める」という気づきは、CLAUDE.mdやAGENTS.mdといったファイルをチームの資産として管理する議論を生みました。

第4世代：ループエンジニアリング（2026年6月〜）

そしてOsmani氏は、ループエンジニアリングを「ハーネスのさらに1つ上の階層」と表現しています。ハーネスがタイマーで自分から動き出し、必要なら助手を生成し、自分自身に仕事を供給するといった、複数のエージェントを継続的に回し続けるオーケストレーション（複数のツールやシステムの統合的な制御・連携）を行います。※3

そのため、これまでの3つの世代（プロンプト・コンテキスト・ハーネス）のAI活用の考え方は無くなるのではなく、ループの部品のひとつとして組み込まれます。※3

チームへの意味：「人間がいなくても開発サイクルが自律的に回る」状態が視野に入ってきます。チームの役割が「AIを操作する人」から「AIを操作するシステムを設計・管理する人」へと変わります。これはチームの評価軸・採用要件・育成方針に波及する、根本的な変化です。

ループとハーネスの違いと関係性

概念として近しい「ハーネスエンジニアリング」との違いを、改めて整理します。

ハーネスエンジニアリングとは何か

ハーネスとは、AIモデルの外側にある環境のすべてです。使えるツール、与える制約、フィードバックの仕組み、検証のゲートが含まれます。エージェントとは「ツールをループの中で使ってゴールを達成するシステム」とシンプルに表現することができ、その「ツールとループの設計」こそがハーネスエンジニアリングの対象です。

ハーネスエンジニアリングの詳細はこちらの記事もご参照ください。

ループはハーネスの「1つ上の階層」である

図2 ハーネスとループの階層関係（レイヤー構造）

以下の比較表で整理すると分かりやすいかと思います。

観点	ハーネスエンジニアリング	ループエンジニアリング
対象	エージェントが仕事を安全・確実に遂行するための実行環境	ハーネスを継続的に起動し、状態を記録・検証・供給する制御レイヤー
レイヤー	実行環境レイヤー	ハーネスの1つ上の階層
起動方法	人間がプロンプトで起動	時刻・イベント・条件で自律起動
終了判断	エージェントが完了を宣言	検証ゲートが「合格」を判定

（※3※4をもとに整理）

ハーネスはループの前提・土台であり、ループがハーネスを置き換えるわけではありません。ループを組む前にまずハーネスが整っていることが大前提になります。

開発チームが整備すべき6つのインフラ

ループをきちんと機能させるには、以下の6つの要素をチームのインフラとして整備する必要があります。個人が設定するのではなく、チームとして設計・共有・維持すべきものとして捉えることが重要です。Osmani氏はループに必要なものを「5つのパーツ＋1つの記憶」として整理しています。※3

図3 ループを構成する6つのインフラ関係図

1. Automations（自動化）

スケジュール実行（cronやGitHub Actions）やイベントトリガーで、自律的にタスクを発見・トリアージする仕組みです。これがなければ、ループは「1回きりの処理」で終わり、継続的な自律サイクルになりません。

毎朝のCI失敗の確認、積み上がったIssueの洗い出し、最近のコミットへのバグ混入検出などを、人間がいちいちチェックしなくてよくなります。Claude Codeでは以下の機能が対応します。

/loop：指定したインターバルでタスクを繰り返し実行
/goal：定義した条件が達成されるまで継続実行。終了判断は実行エージェントとは別のモデルが行う
hooks：セッション開始時やツール実行の前後などのライフサイクルポイントで処理を実行

チームとしての整備ポイント：誰がAutomationを設計・管理するかオーナーシップを決めましょう。定期実行のトリガー・通知先・エスカレーション先をチームのワークフローに組み込み、「誰かが個人的に動かしているAutomation」ではなくチームの公式プロセスとして管理することが重要です。

2. Worktrees（ワークツリー）

複数のAIエージェントが並行して作業してもコードが衝突しないよう、Gitの機能で作業環境を物理的に隔離する仕組みです。

「2つのエージェントが同じファイルを同時に書き換えてコンフリクトが発生する」という事故は、Worktreesがなければほぼ確実に起きます。複数の人間エンジニアが同じブランチの同じファイルを同時に編集するのと同じ問題です。Claude Codeでは git worktree・--worktree フラグ・isolation: worktree オプションで対応します。

チームとしての整備ポイント：複数メンバーがそれぞれループを走らせる場合のブランチ命名規則・管理ルールをチームで決めておく必要があります。設計しておかないと、人間エンジニアが気づかないうちにAIが生成したコードがリポジトリを混乱させます。

3. Skills（スキル）

なお、ここで示す「Skills」とは、Claude Codeの特定機能名ではなく、Osmani氏がループインフラの一要素として定義した概念です。CLAUDE.md・AGENTS.md・SKILL.md といったファイルを通じて、プロジェクト知識をAIが参照できる形で明文化する取り組み全体を指しています。

プロジェクト固有のルール・ビルド手順・禁止パターン・過去の意思決定をファイルに明文化しておく仕組みです。代表的なファイルとして CLAUDE.md・AGENTS.md・SKILL.md が使われますが、それぞれ役割が異なります。

CLAUDE.md / AGENTS.md：毎セッション自動でインジェクトされる「常時参照ルール」。プロジェクト全体の規約・禁止事項・過去の意思決定を書く
SKILL.md：/スキル名 で明示的に呼び出す「再利用可能なタスク定義」。「$triage」「$code-review」のように、繰り返し実行する手順をパッケージ化する

Skillsがない状態でループを回すと、AIが毎セッション「このプロジェクトのルールは何か」をゼロから推測します。推測が外れれば意図とずれた実装が繰り返されます。Osmani氏はこれを「意図の負債（Intent Debt）」と呼んでいます。Skillsは一度書いたら毎ループで参照されるため、知識が蓄積・複利的に効いていきます。※3

CLAUDE.md / AGENTS.mdの記載例：

各ルールに「なぜそのルールが存在するか」の根拠を書いておくことで、AIが文脈を理解して判断の精度が上がります。

チームとしての整備ポイント：Skillsはいわばチーム共有のAIへの申し送り書です。リポジトリで管理してチーム全員がアクセス・更新できる状態にしましょう。個人のローカルに置くと、他のメンバーのループが同じ推測ミスを繰り返すことになります。

4. Connectors / MCP（外部連携）

MCP（Model Context Protocol）経由でGitHub・Slack・Linear・社内データベースなどにAIエージェントを接続する仕組みです。

Connectors（コネクタ）がなければ、ループはファイルシステムの中だけで完結し「修正案を出す」ことしかできません。コネクタがあれば、「PRを作成して、Linearのチケットを更新して、CIが通ったらSlackに通知する」という一連の動作まで自律的に行えるようになります。これがあるかないかで、ループが「提案ツール」になるか「実行エージェント」になるかが決まります。

チームとしての整備ポイント：どのツールをAIに接続するかはセキュリティポリシーに直結します。Slackへの投稿・GitHubへのPR作成・DBへのクエリ実行、それぞれの権限をAIに与えることの是非をチームで判断し、接続可否の基準を事前に定めておきましょう。MCPサーバーの説明文はモデルのプロンプトに含まれるため、信頼できないMCPサーバーはプロンプトインジェクションのリスクも持ちます。

5. Sub-agents（サブエージェント）

コードを書くAI（Maker）と、それを検証するAI（Checker）を別々のエージェントとして分離する構造です。

同一モデルは自分が書いたコードを甘く評価する傾向があります。生成と評価を同じ推論パターンで行うため、生成時の見落としが評価時にも共通して再現されるからです。別モデル・別指示の検証エージェントを使うことで、制作者が見落とした問題を独立した視点で発見できます。

典型的な3つの役割構成は以下の通りです。

役割	仕事	モデルの傾向
Explorer	コードベース調査・前提収集	調査内容が軽量・探索的な場合、高速・低コストなモデルが向いている（調査範囲が広い場合や複雑な場合は主力モデルを利用推奨）
Implementer	実装案の起草	内容が標準的な実装範囲であれば、主力モデルが向いている（複雑な設計判断を伴う場合や難易度が高い場合は、より高性能なモデルの利用も検討）
Verifier	テスト・仕様への照合	同じ盲点を持たせないため、別モデル推奨

Claude Codeでは .claude/agents/ ディレクトリにサブエージェントを定義します。/goal コマンドも内部的にこの仕組みを使い、実行エージェントとは別の独立したモデルが終了条件を判定します。

チームとしての整備ポイント：AIのVerifierはあくまで一次チェックであり、人間のレビューを完全に代替するものではありません。AI検証とヒューマンレビューの役割分担を明示的に設計することが重要です。

6. State / Memory（外部記憶）

AIはセッション間でコンテキストを忘れます。そのため、進捗・試行錯誤の履歴・完了済みタスクを外部ファイルに記録・保持する仕組みが必要です。

Osmani氏はこれを「一番過小評価されている要素」と表現しています。外部記憶がないと、毎日のループが「ゲームを最初からやり直す」状態になります。昨日直したバグを今日また踏む、というループになりかねません。※3

実践的な選択肢として AGENTS.md・Markdownファイル・Linearボード・GitHubのIssueなどがあります。

チームとしての整備ポイント：記憶ファイルはチームの知識資産です。個人のローカルに置くのではなく、リポジトリで管理してチーム全員がアクセス・更新できる状態にしましょう。何が完了し、何が試みられ、何が残っているかをAIもチームも同じ場所から読める状態にすることが、ループを「チームのインフラ」として機能させる前提条件です。

「ループ」はcronと何が違うのか

ここで「それって既存のcronと何が違うの？」という疑問が浮かぶ方もいると思います。

cronとの決定的な違いは「判断」の有無にあります。cronのジョブは、周囲の環境がどうであれ毎回同じスクリプトを実行します。一方ループは、その瞬間の状況を見てAIが次の一手を選びます。判断するのはあなたが書いたif文ではなく、モデル自身です。

両者の違いを図にすると、以下の通りです。

図4 cronとループの動作の違い

cronは「トリガー→固定スクリプト実行→完了」という一方向の流れで終わり、結果や状況を振り返ることはありません。それに対してループは「状態を観察→AIが判断→実行→結果を観察→継続/停止を判断」という円環的なサイクルを繰り返しながら、状態を次のループへ引き継いでいきます。この「状態を引き継ぎながら判断し続ける」という点が、cronにはない構造です。

ループエンジニアリングが抱える4つの課題と組織ガバナンス

ループが便利に動くほど、組織として向き合うべき課題も増えます。Osmani氏は「ループの問題は、スムーズに回るほど怖い」と表現しています。※3

これらの課題は個人の注意喚起ではなく、組織として設計で対処すべき問題として捉えるべきです。

図5 4つの課題：自動化の進展とともに累積する

課題1：検証の死角（Verification Gap）

ループが無人で動くということは、無人のままミスが生産され続けるということでもあります。「完了（done）」はAIの自己申告であり、タスクが正しく終わったことの確認ではありません。Osmani氏は「あなたの仕事は、自分が確認したコードを出荷することだ」と言い切っています。※3

組織としての対処法：品質ゲートを仕組みとして組み込みましょう。

サブエージェントによる独立した検証を構造として持つ
テスト結果・CI・ログ・スクリーンショット等の客観的証拠を合否の必須条件とする
「証拠が出ない限り次に進まない」というルールをhooksや停止条件として実装する

「AIが完了と言ったから完了」という判断をチームの文化として認めない設計が必要です。

課題2：理解の負債（Comprehension Debt）

ループが高速にコードを量産するほど、チーム全体で「誰も理解していないコード」が蓄積していきます。「動いているから問題ない」という意識が組織に広がり、ある日バグが起きたときに「どこで何が壊れたか」を誰も追えなくなってしまいます。これは従来の技術的負債とは別の新たな種類の負債です。※3

組織としての対処法：理解の維持をプロセスとして組み込みましょう。

AIが生成したコードをレビューする習慣・文化を崩さない。速度だけを評価指標にしない
スプリントの振り返りで「AIが生成したが理解できていないコードがあるか」を問う
AI生成コードのレビュー負荷を考慮してチームの能力開発をする

課題3：認知的降伏（Cognitive Surrender）

これが最も根深い課題です。「AIがそう判断したならそれが正しい」という思考停止が、チーム全体に広がるリスクです。個人レベルでは「AIがそう言うので…」が口癖になること。また組織レベルでは、技術的な意思決定の根拠が「AIがそう判断した」になっていくこと。これが進むと、組織全体の技術判断力・意思決定の質が気づかないうちに低下します。※3

組織としての対処法：ループは人間によるエンジニアリングの「代替」ではなく「エンジニアの仕事や能力を拡張するもの」だという文化をマネージャーが作りましょう。

レビューの場で「なぜそう判断したか」をエンジニア自身が説明できることを求める
「AIの判断」と「エンジニアの判断」を分けて議論できるチームの文化を維持する
「Build the loop. Stay the engineer.（ループを構築せよ。しかし、エンジニアであり続けろ）」をチームの規範として言語化する

課題4：コスト管理（Cost Explosion）

マネジメント観点で見落とされがちなのが、トークン消費コストの問題です。人間が都度操作していたときは、意識的に手を止めればコストも止まりましたが、ループでは違います。/goal コマンドで「条件達成まで継続」させると、AIは止まる理由がない限り動き続けます。複数のサブエージェントが並列で走れば、気づかないうちに1日分の想定予算を数時間で使い切ることもあります。

実際に、Uberは2026年にClaude CodeやCursorの年間AI予算をわずか4か月で使い切り、エンジニア1人・ツール1つあたり月1,500ドルの利用上限を設定する事態になっています。※5

また、従来のCI/CDと異なり、ループは進捗に応じて入力トークンが累積していくため、コストが非線形に膨らむ可能性があります。Microsoft ResearchとStanford Digital Economy Labが共同で行った調査によると、同じ開発タスクをAIエージェントに与えた場合でも、総トークン消費量に最大30倍のバラつきが生じることが報告されています。また、Falconer Guidesはこの調査結果を踏まえ、ばらつきの大半は「最初に読み込むコンテキストの質」によって決まると整理しています。例えば、クリーンなコンテキストを読んだエージェントは1〜2ターンで完了するのに対し、古かったり矛盾している情報を読み込んでしまったエージェントは、読み込み直しと検証を何度も繰り返すことになり、結果としてトークン消費が膨らんでしまうというメカニズムです。※6※7

上記のような例では、初手で古いドキュメントや矛盾したコードを読み込んでしまうかどうか、すなわち「最初の情報検索（First Retrieval）の品質」による差の影響が大きいとされています。Falconer Guidesによると、読み込み直しと検証を繰り返すことになったエージェントは、6ターン以上かかるケースもあると指摘されています。これらのことから、Skillsや外部ナレッジの整備は、品質のためだけでなく、コスト管理においても最も効果が大きい施策になり得るといえます。（本記事「3. Skills」セクションで解説しているCLAUDE.mdの整備が、コスト削減の観点からも直接効いてきます）

組織としての対処法：コスト管理と可観測性をガバナンスの一部として設計しましょう。

ループ1回あたりのトークン上限をツール設定または停止条件として組み込む
月次・週次のAI利用コストを可視化するダッシュボードをチームで共有する
「ループを本番稼働させる前にコスト試算をする」をリリースプロセスに組み込む
ループの実行ログ・ツール呼び出し履歴を記録し、「どのループが・何ターンで・何をしたか」を後から追跡できる状態を整える。コストの異常を発見したとき、原因を特定できなければ対処もできない
ループが生成したコードのテスト結果を自動で記録し、合否の根拠を残す。「AIが完了と言った」だけでなく「テストが通った証跡がある」状態を標準にする

4つの課題に共通する本質：Human-in-the-loop の再設計

4つの課題を並べてみると、ある共通点が見えてきます。それはすべて「人間がループから外れることで起きる問題」として読めるということです。

逆説的ですが、「人間がAIを直接操作しなくなる」からこそ、人間が介在すべき箇所を意図的に設計することがより重要になります。これを「Human-in-the-loop（HITL）」と呼びます。ループエンジニアリングはHITLを否定するものではなく、むしろHITLをどこに配置するかをより精緻に設計することを求めます。

Boris Cherny氏の変遷を改めて振り返ると、「人間がループから消えた」のではなく、「人間が1つ上の抽象化レイヤーに移動した」と解釈できます。実行（プロンプト→実行→繰り返し）の層からは外れる一方で、目標の定義・停止条件の設計・最終判断という層には人間が残り続けることになります。

レイヤー	人間の役割
実行層（プロンプト→実行→繰り返し）	自動化。人間は外れる
検証・品質ゲート	HITLが必要な要所
目標定義・停止条件の設計	人間にしか決められない
例外処理・最終判断	人間が責任を持つ

ループエンジニアリングはこれからどうなるか

ツールとエコシステムの成熟が進む世界の動向

Claude Code（Anthropic）・Codex（OpenAI）といった主要なAIコーディングエージェントでは、2026年6月時点でループを支える6つの要素をすでに標準機能として搭載しています。

また、MCP（Model Context Protocol）の普及によって、ツール連携の標準化・相互互換性も進んでいます。「Harness-as-a-Service（HaaS）」という考え方も注目されており、ループ構築の土台がサービスとして提供され、チームはループの設計に集中できる環境が整いつつあります。

ただし、これらプロダクトの動きだけをもって、ループエンジニアリングがすでに成熟し安定した手法だと捉えるのはまだ早計です。概念の提唱者であるOsmani自身もループエンジニアリングに関して「まだ初期段階であり、自分も懐疑的だ。トークンコストには本当に注意しなければならない」と釘を刺しています。また、XにおけるAI開発者間の議論でも評価は一様ではなく、「次の抽象レイヤーだ」という評価と「帽子をかぶったcronにすぎない」という批判的な見方の両方が見られます。後者への反論としては、「cronは固定スクリプトを実行するだけだが、ループは状態を観察し、判断し、実行し、結果を確認して継続を判断する」という構造的な違いが挙げられます。

注意すべきなのは、これらの領域はまだ黎明期にあるため、現時点の情報やツールの仕様・用語・ベストプラクティスは今後大きく変わる可能性が高いことです。そのため、基本的には自チームで小さく試して体験から学ぶことが最も確実なアプローチだといえます。

開発組織への示唆

AI駆動開発を推進する日本国内企業にとって、ループエンジニアリングは無視できない潮流です。これらを組織として取り組むには、以下の3点が先行要件になると考えられます。

1. ガバナンス設計を先行させる：品質管理・コスト管理（トークン費用は想定外に膨らむことがある）・セキュリティポリシー（どのツールをAIに接続するか）の基準を、ループを本格稼働させる前に整備しましょう。

2. 採用・育成戦略を更新する：「プロンプトが書ける人」から「ループが設計できる人」へ、組織が求めるスキルセットの見直しが必要になります。この変化は現時点ではまだ広く認知されていないため、採用・育成戦略を先行して更新できた組織が採用競争で有利になる可能性があります。

3. まずは小さく始めてみる：CI修復・テスト補完・ログ点検など、定量的に検証できる小さなタスクからループ化を試みましょう。大きく始めると、ガバナンスよりも先にリスクが顕在化してしまいます。

まとめ：ループを設計する。しかし、エンジニアであり続けることが重要

Osmani氏はブログ記事をこう締めくくっています。

“That’s what makes loop design harder than prompt engineering, not easier. Cherny’s point isn’t that the work got easier. It’s that the leverage point moved.”

（ループを設計することは、プロンプトを打つことよりも難しい。なぜなら、価値を生む”テコの支点”が一段上に移動したからだ）
— Addy Osmani（Google, Engineering Director）※3

より速く・より深く押し進めるエンジニアと、ループに判断を委ねて自分で考えることを少しずつ手放していくエンジニアとでは、同じループを組んでも出てくる結果は大きく異なります。

前者こそがループを真の意味で活かせるエンジニアであり、ループという仕組みを自分の判断力を増幅させる道具として使いこなします。一方、後者は「ループエンジニアリングが抱える4つの課題」の中で挙げた「認知的降伏」が一層進む結果となり、組織全体の技術判断力・意思決定の質の低下につながります。

開発組織を率いる立場においても同じことが言えます。ループという仕組みを整備することはスタートラインであり、ゴールではありません。ループを導入した上で、エンジニアとしての判断力・主体性を手放さない（引き続き持ち続ける）組織文化をつくることがこの変化の中で求められています。

FAQ：ループエンジニアリングについてよくある質問

Q1. ループエンジニアリング（Loop Engineering）とは何ですか？

ループエンジニアリングとは、人間がAIエージェントに都度プロンプトを打つ役割をやめ、AIにプロンプトを自動投入して目標達成まで自律的に回り続けるシステム（ループ）を設計・構築する手法です。

Q2. ループエンジニアリングとプロンプトエンジニアリングの違いは何ですか？

プロンプトエンジニアリングは「良い指示文を書く個人スキル」を磨く手法です。一方、ループエンジニアリングは「AIが自律的に指示を生成・実行し続けるシステムを設計する」手法です。人間がAIを操作するのではなく、仕組みがAIを操作する点が本質的な違いです。

Q3. ハーネスエンジニアリングとループエンジニアリングの違いは何ですか？

ハーネスエンジニアリングは単一エージェントが動く「実行環境」を設計する手法です。ループエンジニアリングはその1つ上の階層で、複数エージェントをスケジュール・イベント駆動で自律的に動かす制御レイヤーを設計します。

Q4. ループエンジニアリングの導入はどこから始めればいいですか？

まず CLAUDE.md にプロジェクトのルール・ビルド手順・禁止パターンを書くこと（Skillsの整備）から始めるのが現実的です。次に、CI修復・テスト補完・ログ点検など定量的に検証できる小さなタスクを1つ選んで試してみましょう。最初から大きなループを組もうとすると、ガバナンスより先にリスクが顕在化します。

Q5. ループ化に向いているタスクはどんなものですか？

CI失敗の自動修復、テストの補完・生成、ログ巡回点検、ドキュメント同期（API・README）、依存関係アップグレードなどが向いています。共通する特徴は「自動で検証できる」「失敗時にロールバックできる」「停止条件を数値で定義できる」の3点です。逆に広範囲のリファクタリング・本番環境の権限操作・セキュリティ関連の変更などは慎重なアプローチが必要です。

Q6. ループエンジニアリングの主な課題は何ですか？

主に4つの課題があります。
①検証の死角（Verification Gap）：無人で動くため、AIのミスも無人のまま量産される。
②理解の負債（Comprehension Debt）：AIが大量生成したコードの理解がチームから失われていく。
③認知的降伏（Cognitive Surrender）：AIの判断に思考停止してエンジニアや組織としての判断力が失われる。
④コスト増（Cost Explosion）：ループが自律的に動き続けることでトークン消費が非線形に増加し、想定外の費用が発生する。
いずれも個人の注意だけでなく、組織の設計・文化レベルで対処する必要があります。

Q7. ループエンジニアリングはClaude Code以外でも実践できますか？

はい。Claude Code（Anthropic）やCodex（OpenAI）が代表的ですが、ループエンジニアリングは特定ツールに依存した概念ではありません。Automations・Worktrees・Skills・Connectors・Sub-agents・Memoryという6つのインフラを備えたエージェント環境であれば実践できます。MCP（Model Context Protocol）はAnthropicが策定したオープン標準であり、対応ツールは今後さらに増える見込みです。

Q8. ループエンジニアリングとcron・GitHub Actionsは何が違いますか？

cronやGitHub Actionsは、定められたスクリプトを定刻・定条件で実行します。「何をするか」はあらかじめ人間が書いたコードで決まっています。一方で、ループは、トリガーは同じく時刻やイベントで動きますが、「その瞬間の状況を見てAIが次の一手を判断する」点が根本的に異なります。cronは状況に関わらず同じ処理を実行しますが、ループはコンテキストに応じてAIが動き方を変えます。固定スクリプトで済む定期処理はcron・GitHub Actionsで十分です。状況判断を伴う継続的なタスクにはループが適しています。

Q9. ループ化してはいけないタスクはありますか？

広範囲のリファクタリング・本番環境への直接デプロイ・セキュリティポリシーの変更・認証や課金に関わる処理は、ループ化には慎重なアプローチが必要です。共通する判断基準は「失敗時にロールバックできるか」「停止条件を明確に定義できるか」「客観的な合否判定ができるか」の3点です。これらを満たせないタスクは、まず人間のレビューを必須とする設計にしてください。

Q10. Claude Codeでループを実装するには何を準備すればいいですか？

最低限の準備として、① CLAUDE.md にプロジェクトルール・ビルド手順・禁止パターンを書く（Skills）、② /goal や /loop コマンドで実行できる明確な完了条件を定義する（Automations）、③複数エージェントを並行させる場合は git worktree を設定する（Worktrees）の3点があります。外部ツールとの連携（GitHub・Slack等）はMCP経由で後から追加できます。