ループエンジニアリングとは何か？AIエージェント時代の開発プロセス設計

AIコーディングツールを使っていると、こんな経験をすることがあります。

• それっぽいコードは出てきたが、要件と少しずれている
• 既存の設計やコードの流儀に合っていない
• 修正を頼むほど差分が大きくなっていく
• テストや型チェックは通らない
• 最終的に、人間が全部読み直して直している

AIの性能が足りないからでしょうか。

もちろん、モデルの性能やツールの制約もあります。
ただ、それだけではありません。

多くの場合、問題は「AIへの頼み方」だけでなく、AIの出力をどう観察し、検証し、次の指示に戻すかが設計されていないことにあります。

このような考え方は、2026年ごろからAIコーディングやAIエージェントの文脈で Loop Engineering / ループエンジニアリング と呼ばれるようになってきました。

この記事では、筆者の造語としてではなく、AIエージェント時代の開発スタイルとして語られ始めている「ループエンジニアリング」を、日本語で整理します。

誰がループエンジニアリングを提唱したのか

現時点では、「この人が最初に提唱した」と断定できる単一の創始者がいるというより、AIコーディングツールの実務コミュニティで広がっている考え方として捉えるのが自然です。

特に、Claude Code の creator として知られる Boris Cherny 氏の発言や実践が、この言葉を広めるきっかけの一つとして紹介されています。Business Insider は、Cherny 氏が「自分でプロンプトを書くのではなく、Claude にプロンプトさせるエージェントとやり取りしている」という趣旨の発言をしたこと、また OpenAI の Peter Steinberger 氏が「coding agent にプロンプトするのではなく、agent にプロンプトする loop を設計すべきだ」と述べたことを紹介しています。¹

また、Google Cloud の Addy Osmani 氏も、ループには automation、worktree、skill、plugin/connector、sub-agent といった要素がある、という形で整理していると紹介されています。¹

さらに、2026年には "Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting" という論文も公開されており、ループエンジニアリングを「step-by-step prompting の代わりに、trigger、goal、verification、stopping rule、memory などを持つ loop specification を設計する実践」として整理しています。²

つまりこの記事で扱う「ループエンジニアリング」は、筆者が新しく作った用語ではありません。
Boris Cherny 氏、Peter Steinberger 氏、Addy Osmani 氏らの発言や、AIエージェント開発の実務上の議論を背景に広がっている概念を、開発プロセスの観点から整理したものです。

ループエンジニアリングとは

ループエンジニアリングとは、次のような開発手法です。

AIエージェントやAIコーディングツールに対して、人間がゴール・制約・検証方法・停止条件を与え、AIが自律的または半自律的に実装・検証・修正を繰り返せるループを設計し、成果物の品質を上げる開発手法

短く言うと、

AIと一緒に品質を上げるための反復構造を設計すること

です。

ポイントは、AIに「一発で正解を出してもらう」ことではありません。
AIの出力を検証し、その結果を次の行動へ戻す仕組みを設計することが重要です。

ここでいうループは、必ずしも人間が毎回手で回すものではありません。人間が確認して次の指示を出す場合もあれば、あらかじめ検証方法と停止条件を与え、AI自身が実装・テスト・修正を繰り返す場合もあります。

プロンプトエンジニアリングとの違い

似た言葉に、プロンプトエンジニアリングがあります。

プロンプトエンジニアリングは、主に 良い一回の入力を設計する技術 です。

一方で、ループエンジニアリングは、出力を観察し、検証結果や差分を次の入力に戻す反復プロセス全体を設計する技術 です。

たとえば、次のような違いがあります。

観点	プロンプトエンジニアリング	ループエンジニアリング
主な対象	1回の指示	指示から検証までの流れ
重視するもの	入力文の品質	反復プロセスの品質
成果物の見方	良い出力を得る	出力を改善し続ける
人間の役割	うまく頼む	目的・検証方法・自動化範囲・停止条件を設計する

もちろん、プロンプトは重要です。
ただ、実務の開発では一回の指示で終わることはほとんどありません。

むしろ重要なのは、出てきたものを見て、

• 何が良いのか
• 何が足りないのか
• 何を検証すべきか
• 次に何を頼むべきか

を判断することです。

基本サイクル

ループエンジニアリングは、次の6ステップで考えると理解しやすいです。

1. 目的・制約を決める
2. 指示を設計する
3. AIが出力する
4. 出力を検証する
5. フィードバックを整理する
6. 次の指示に変換する

図にすると、次のような流れです。

目的・制約
   ↓
指示設計
   ↓
AIの出力
   ↓
検証
   ↓
フィードバック
   ↓
次の指示
   ↺

ここで大切なのは、検証 と 次の指示 を分けて考えることです。

テストが落ちた。
UIが崩れた。
差分が大きすぎる。
既存設計と合っていない。

これらを見つけるだけでは、まだループは回っていません。
その観察結果を、AIが次に行動できる指示へ変換して初めて、ループになります。

ループはAIが自動で回すものなのか

結論から言うと、自動で回すこともできますが、すべてのループが完全自動である必要はありません。

ループの自動化には、おおむね次の3段階があります。

方式	ループの回し方	人間の関わり方
手動ループ	AIが出力するたびに、人間が確認して次の指示を出す	各ステップで判断する
半自動ループ	AIが実装・テスト・修正を繰り返し、重要な節目で止まる	設計変更やマージ前などで承認する
自動ループ	AIが合格条件を満たすか停止条件に達するまで反復する	最初にループを設計し、結果を監督する

たとえば、次のような指示は半自動または自動のループを作っています。

検索機能を実装してください。
実装後にテストと型チェックを実行し、失敗した場合は原因を調べて修正してください。
すべて成功するまで繰り返してください。
ただし、データモデルの変更が必要になった場合、または3回修正しても成功しない場合は作業を止め、状況を報告してください。

この例では、人間が修正のたびに指示を出す必要はありません。AIはテスト結果を観察し、次の修正を自分で決めます。一方で、データモデルの変更と反復回数には停止条件があり、判断リスクの高い箇所は人間に戻されます。

つまり、ループエンジニアリングで設計するのは、単なる作業手順だけではありません。

• AIが自動で繰り返してよい範囲
• AIが利用する検証手段
• 人間の承認が必要な地点
• ループを終了または中断する条件

まで含めて設計します。実務では、すべてを完全自動化するよりも、機械的に検証できる部分はAIに回させ、要件や設計に関わる判断では人間が承認する半自動ループから始めると扱いやすいでしょう。

人間の役割は何か

AIコーディングツールを使うと、人間の役割は「コードを全部書くこと」から少し変わります。

人間が設計するべきものは、たとえば次のようなものです。

• 目的
• 制約
• 観察ポイント
• 合格条件
• 次の問い
• ループを止める条件
• 人間の承認を挟む地点

これは、実装をすべてAIに丸投げするという意味ではありません。

むしろ、人間はより上流で、

• 何を達成したいのか
• どこまでAIに任せるのか
• 何をもって成功とするのか
• どの差分なら受け入れられるのか
• どの時点で人間が介入するのか

を決める必要があります。

人間は、すべての出力に逐次指示を返す必要はありません。機械的に判断できる範囲はAIに自動で回させ、要件変更や設計判断など、責任を伴う地点に承認を置きます。

AIに任せる範囲が広がるほど、人間には「ループを設計し、監督する力」が求められます。

検証はループの心臓部

ループエンジニアリングでは、検証をとても重視します。

検証には、大きく2種類あります。

自動検証

• テスト
• 型チェック
• Lint
• ビルド
• CI

人間の観察

• UI確認
• 差分レビュー
• 要件との照合
• 既存設計との整合
• ユーザー体験として自然か

AIの出力を信じるのではなく、検証可能な形で前に進める。
これが重要です。

自動検証だけでは、設計意図やユーザー体験までは見切れません。
一方で、人間の感覚だけでは再現性が弱くなります。

そのため、自動検証と人間の観察を組み合わせることが大切です。

具体例: 既存Webアプリに検索・絞り込み機能を追加する

例として、既存のWebアプリに「検索・絞り込み機能」を追加するケースを考えます。

一見すると小さな機能ですが、実際にはいくつもの観点があります。

• 既存の一覧画面がある
• キーワード検索を追加したい
• カテゴリ絞り込みも追加したい
• URLパラメータに状態を保持したい
• 既存の状態管理に合わせたい
• テストと型チェックを通したい

このとき、いきなりAIにこう頼むと危険です。

検索機能をいい感じに追加して

これでは範囲が広すぎます。
AIはそれっぽく実装してくれるかもしれませんが、既存設計に合わない変更や、不要なリファクタが混ざる可能性があります。

代わりに、ループを分けます。

ループ1: 仕様を小さく切る

最初は、実装ではなく分解を頼みます。

一覧画面にキーワード検索とカテゴリ絞り込みを追加したいです。
まず、実装範囲を小さなステップに分解し、受け入れ条件を提案してください。
まだコードは変更しないでください。

ここで見るべきポイントは次の通りです。

• 要件が小さく分かれているか
• 受け入れ条件が検証可能か
• 曖昧な点が質問として出ているか
• 実装範囲が広がりすぎていないか

最初から実装させるのではなく、作業単位と合格条件を作るところから始めます。

ループ2: 既存コードを調査させる

次に、既存コードを調査させます。

既存コードを調査して、検索機能を追加するために変更が必要なファイルと実装方針を提案してください。
まだコードは変更しないでください。

ここでの観察ポイントは次の通りです。

• 既存の状態管理を見ているか
• URLパラメータの扱いを見ているか
• 変更対象が広がりすぎていないか
• 不明点を勝手な仮定で埋めていないか

「まだコードは変更しないでください」と明示することで、調査ループと実装ループを分けられます。

ループ3: 小さく実装させる

方針を確認したら、小さな単位で実装させます。

提案された方針のうち、まずキーワード検索だけを実装してください。
既存の一覧取得ロジックは変更せず、表示側のフィルタリングで対応してください。

ここでは、AIに任せる範囲を絞ります。

• まずキーワード検索だけ
• 既存の取得ロジックは変更しない
• 表示側のフィルタリングで対応する

このように制約を置くことで、差分が読みやすくなります。

ループ4: テスト・型チェックを戻す

実装後は、検証結果を次の入力に戻します。

型チェックでこのエラーが出ています。
原因を説明したうえで、最小差分で修正してください。

ポイントは、単にエラーを貼るだけではなく、次の条件を付けることです。

• 原因を説明する
• 最小差分で修正する
• 関係ないリファクタをしない

これにより、エラー修正が別の大きな変更に化けることを防ぎやすくなります。

ループ5: UI確認と差分レビューを戻す

テストが通っても、まだ終わりではありません。

UI確認では、たとえば次を見ます。

• 検索できるか
• 空状態が自然か
• モバイルでも崩れないか
• URLに状態が残るか

差分レビューでは、次を見ます。

• 変更範囲は妥当か
• 既存パターンに沿っているか
• 不要な変更がないか
• 命名や責務が自然か

レビュー後の指示は、たとえばこうなります。

差分を見ると、フィルタ条件がURLに保持されていません。
既存のURLパラメータ管理に合わせて修正してください。

ここでは、観察結果がそのまま次の指示に変換されています。

これがループエンジニアリングの基本です。

よくあるアンチパターン

ループがうまく回らないときは、だいたい次のどれかに当てはまります。

1. 丸投げする

いい感じに実装して

この指示では、目的も制約も合格条件も曖昧です。

2. 巨大タスクにする

一度に要件定義、設計、実装、テスト、UI修正まで頼むと、差分が大きくなりすぎます。

3. 検証しない

AIの出力をそのまま受け入れると、見た目は動いていても設計や品質の問題が残ることがあります。

4. 曖昧な修正指示を出す

もっとちゃんとして

これではAIが何を直せばよいかわかりません。

5. 差分を読まない

AIが生成したコードでも、最終的に責任を持つのは人間です。
差分レビューは省略できません。

6. コンテキストを増やしすぎる

関係ない情報を大量に渡すと、AIが重要な制約を見失うことがあります。

必要な情報を、必要なタイミングで渡すことも設計の一部です。

大規模プロジェクトではどう使うか

大規模プロジェクトでは、1つの巨大なループを回すのではなく、工程ごとに小さなループを置きます。

たとえば、次のように分けられます。

ループ	目的
要件ループ	ユーザー要求、仕様、受け入れ条件を詰める
設計ループ	既存アーキテクチャとの整合、影響範囲を確認する
実装ループ	小さな変更単位でコード生成・修正する
レビュー・テストループ	CI、静的解析、人間レビューを戻す
運用フィードバックループ	ログ、問い合わせ、メトリクスを次の改善に戻す

大規模では、「AIエージェントを増やす」ことよりも先に、ループを分割して接続することが重要です。

各ループの出力が、次のループの入力になります。

要件ループ
   ↓
設計ループ
   ↓
実装ループ
   ↓
レビュー・テストループ
   ↓
運用フィードバックループ
   ↺

チームで運用する場合は、次のような境界も決める必要があります。

• AIに任せる範囲
• 人間がレビューする範囲
• 自動検証で止める条件
• PRに残すべき説明
• 次のループに渡す成果物

ツールは Codex、Claude Code、Cursor、GitHub Copilot Coding Agent など、いろいろあります。
ただし、主役はツール名ではありません。

重要なのは、目的・制約・検証・フィードバックが設計されているかどうかです。

ループ設計チェックリスト

最後に、明日から使えるチェックリストを置いておきます。

• 目的は一文で言えるか
• 制約は明示したか
• AIに任せる範囲を小さく切ったか
• 検証方法は先に決めたか
• AIが自動で反復してよい範囲を決めたか
• 人間の承認が必要な地点を決めたか
• 出力を見て次の指示に変換したか
• 差分をレビューしたか
• ループを止める条件を決めたか

このチェックリストを使うだけでも、AIコーディングの失敗はかなり減らせます。

まとめ

ループエンジニアリングは、AIにうまく頼むためだけの技術ではありません。

目的・制約・検証方法・停止条件を与え、AIが自律的または半自律的に実装・検証・修正を回せるようにする開発プロセス設計です。

ループは、人間が毎回指示して回すことも、AIが自動で回すこともできます。大切なのは、どこまでをAIに任せ、どこで人間が判断するかを意図的に決めることです。

AIに頼むだけでなく、品質を上げるループを設計することが、これからの開発では重要になります。

まずは、小さな機能開発で試してみるのがおすすめです。

いきなり大きなタスクを任せるのではなく、

1. 仕様を小さく切る
2. 既存コードを調査させる
3. 小さく実装させる
4. 検証結果を戻す
5. UIと差分をレビューする
6. 次の指示に変換する

この流れを意識すると、AIとの開発はかなり扱いやすくなります。

参考

1. Business Insider, "Forget prompt engineering: 'Loop engineering' is all the rage now" ↩ ↩²

2. Sandeco Macedo, "Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting" ↩