生成AIを活用した開発では、近年「ループ（loop）」という考え方が重要視されるようになっています。AnthropicはClaude Codeに関するドキュメントや技術ブログで、エージェントが「停止条件を満たすまで自律的に作業を繰り返すループ」を基本的な実行モデルとして説明しています。

Anthropic の Claude Code チームは、エージェントの活用について「プロンプトを書くこと」から「ループを設計すること」への移行が起きていると表現しています。

一方で、「ループエンジニアリング（Loop Engineering）」という名称自体が広く定着した業界標準用語というわけではありません。本記事では、こうしたループの設計・改善という考え方を整理するための呼称として、「ループエンジニアリング」という言葉を用います。

本記事では、この「ループエンジニアリング」という考え方を解説します。特定のツールの使用方法ではなく、生成AIを活用した開発に取り組むすべての組織に共通する設計原則として整理していきます。

1. なぜ今「ループ」なのか
2. ループエンジニアリングの定義
3. 進化の過程
4. ループの基本構造：生成 → 検証 → 修正
5. ループの3つのスケール
6. ループ設計の実践原則（一次情報より）
7. おわりに：ループは「作って終わり」ではない

1.なぜ今「ループ」なのか

生成AIによるコーディング支援は、この2年で「補完」から「自律的な作業」へと段階を変えました。Anthropic は Claude Code のドキュメントで、この違いを次のように説明しています。

チャットボットが質問に答えて待つのに対し、エージェント型のコーディング環境は「ファイルを読み、コマンドを実行し、変更を加え、自律的に問題を解決していく」

（出典：Claude Code Best Practices, https://code.claude.com/docs/en/best-practices ）

自律的に動くということは、人間が1手ずつ指示するのではなく、AIが繰り返し作業するサイクル全体を設計ということです。Claude Code チームはループを「停止条件が満たされるまで、エージェントが作業のサイクルを繰り返すこと」と定義しています。

（出典：Getting started with loops, https://claude.com/blog/getting-started-with-loops ）

ループエンジニアリングを可能にした技術的背景を以下の表に整理しました。

つまり、生成AIネイティブ開発の質は、個々のプロンプトの品質ではなく、このサイクルがどう設計されているかで決まる段階に入っています。これが「ループエンジニアリング」という言葉が使われるようになった背景です。

エージェント時代では、生成能力よりも「自分で誤りを検出できるか」が品質を左右します。つまり、ループエンジニアリングの中心課題は、生成そのものではなく「検証」の設計にあります。

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

本記事では、ループエンジニアリングを次のように定義します。

AIを含む作業サイクル（生成 → 検証 → 修正 → 学習）が、人の介在を最小限に、かつ品質を落とさずに回り続けるよう、サイクル全体を設計・改善する技術

ポイントは、人間が手を加える対象が「AIへの指示文」ではなく「サイクル全体」であることです。プロンプトの改善は1回の出力を改善しますが、ループを改良することはすべての出力を継続的に改善します。

なお、本記事では運用を通じた評価基準やコンテキストの改善まで含めた継続的な改善サイクルも扱いますが、これはループそのものというより、ループを進化させる上位の学習サイクルとして整理しています。

3. 進化の過程

「ループエンジニアリング」は、突然現れた概念ではありません。生成AIとの協働の仕方が段階的に変化してきた延長線上にあります。ここでは、その系譜を4つの段階で整理します。

第1段階：プロンプトエンジニアリング（2022年頃〜）

この時期、開発者の関心は「いかにAIへ命令を下すか」という一点に集中していました。Anthropicは、かつてのAI開発において指示文の作成が業務の圧倒的多数を占めていたと回顧しています。Few-shotやChain-of-thoughtといった技法が確立され、出力の成否はプロンプトの完成度次第であるという認識が一般化しました。

第2段階：コンテキストエンジニアリング（2024年頃〜）

AIが連続的なタスクを担うようになると、設計の焦点は単発の指示から「AIが取り巻く情報環境」へと移り変わりました。Anthropicはこの変化を、プロンプト技術が自然に昇華した形と位置づけています。一方で、過剰な情報を与えることで想起能力が損なわれる現象も指摘され、情報の選別、すなわち「何を提示しないか」が重要な設計課題となりました。

第3段階：ハーネスエンジニアリング（2026年前半〜）

エージェントが自律的に動き続けるようになると、ツールの呼び出しやリトライ、状態の管理といった「実行基盤そのもの」の設計が不可欠となりました。Claude Codeを主導するBoris Cherny氏は、すでに個別のプロンプト作成からは脱却していると語っています。設計の領域は情報の提供を超え、非決定的な挙動を示すAIを安定して制御するためのオーケストレーションへと拡大しました。

（出典：Context vs prompt vs loop vs harness engineering（explainx.ai）／Cobus Greyling, Loop Engineering）

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

Peter Steinberger氏の提言を端緒に、Addy Osmani氏がその概念を体系化したことで、生成・検証・修正という「サイクル全体」の設計が主題となりました。Anthropicもエージェントを「ループ内で道具を自律的に操るLLM」と再定義しており、モデルの進化に伴ってこの自律性はさらに強化されると見込んでいます。

（出典：What Is Loop Engineering?（tosea.ai）／Effective context engineering for AI agents）

これら4つの段階は、過去の技術を否定するものではなく、層のように積み重なるものです。ループを中心とした設計思想に移行した後も、プロンプトの精度やコンテキストの構成、そして堅牢な実行環境は、システムの根幹を支える要素としてその重要性を保ち続けます。

4. ループの基本構造：生成 → 検証 → 修正

最小単位のループは、3つの要素で構成されます。

1. 生成：AIがコード・テスト・ドキュメント等を作る
2. 検証：生成物が基準を満たすかを判定する
3. 修正：検証に失敗した場合、AIが自ら修正する

このうち、ループの成否を決めるのは（2）検証です。Anthropic のベストプラクティス文書では、明確な成功基準がない場合「開発者が唯一のフィードバックループになり、すべてのミスが人間の注意を必要とする」と指摘し、生成AIが行うべき検証内容として次を挙げています。

（出典：https://code.claude.com/docs/en/best-practices ）

• テスト：テストスイートがあればAIに実行させる。テストを先に書き、実装を後にする
• 型チェック：型付き言語では、編集のたびに自動診断を走らせる
• リンター：スタイル・規約の機械的な遵守
• スクリーンショット：フロントエンドでは、AIが画面を撮影して視覚的に検証する
• 期待出力：データ処理では、入力と期待出力のペアを与える

検証をAIが自分で実行できるようにすると実装（生成物）に対して、「人が間違いに気づく」から「AIが自分で間違いに気づく」へと変わります。Anthropic の社内チームの事例集では、エンジニアが「Claudeがコードを書き、テストを実行し、継続的に反復する自律ループ」を構成し、8割程度まで完成した解を人がレビューする使い方が報告されています（出典：How Anthropic teams use Claude Code, https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf ）。

なお、注意点もあります。AIは「実装を直す」代わりに「テストを変えて通す」ことがあるため、テストを先にコミットして変更を検知できるようにする、といった運用上の工夫が推奨されています（出典：DataCamp, Claude Code Best Practices, https://www.datacamp.com/tutorial/claude-code-best-practices ）。検証そのものが破られないようにする設計も、ループエンジニアリングの一部です。

5. ループの3つのスケール

ループは1つではありません。範囲を変えて、少なくとも3つのループが回ります。

1：タスク内ループ（分〜時間）

1つのタスクの中で、AIが生成 → 検証 → 修正を繰り返すループです。前章で述べた基本構造がこれに当たります。Claude Code チームはループを、ユーザーの指示で動くターンベース型から、目標を与えて完了まで走らせるゴールベース型、時間トリガーで繰り返す時間ベース型まで分類し、「すべてのタスクに複雑なループが必要なわけではない。最もシンプルな解決策から始めるべき」としています（出典：https://claude.com/blog/getting-started-with-loops ）。

2：開発フローのループ（日〜週）

タスク単位ではなく、要件定義 → 設計 → 実装 → テスト → レビューという開発フロー全体を1つのループとして見るスケールです。ここでの論点は、フローの各工程にAIをどう組み込み、人の承認ポイントをどこに置くかという設計になります。

DORA の研究は、小さいバッチで頻繁に統合し、フィードバックを速く回すことが、デリバリー性能と品質の両方を向上させることを示してきました（出典：https://dora.dev/guides/dora-metrics/）。AIが生成速度を引き上げた分、人が費やす時間は「書く時間」から「検証と承認の時間」に移ります。従って、開発フローのループ設計とは実質的に、検証の自動化と、人が判断すべきポイントの最小化の設計です。

3：組織学習のループ（週〜月）

最も見落とされやすいのが、このスケールです。AIの出力で見つかった問題を、個別に直して終わりにするのではなく、AIに与えるコンテキストや検証基準そのものに反映するループです。

OpenAI は評価（eval）に関するガイドで「評価は目的地ではなく旅である（It's a journey, not a destination）」とし、本番データから継続的に評価セットを育てること、ユーザーの修正やフィードバックを体系的にプロンプトや再学習に還元することを推奨しています（出典：OpenAI Evaluation best practices, https://developers.openai.com/api/docs/guides/evaluation-best-practices および OpenAI Cookbook: Eval Driven System Design, https://developers.openai.com/cookbook/examples/partners/evaldrivensystemdesign/receiptinspection）。

Anthropic も Agent Skills（AIに与える手順書・ノウハウのパッケージ）の設計指針として、「評価から始める：代表的なタスクでエージェントを走らせ、つまずく箇所を特定してからスキルを段階的に構築する」「実際のシナリオでスキルがどう使われるかを監視し、観察に基づいて反復する」ことを挙げています（出典：Equipping agents for the real world with Agent Skills, https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills）。

つまり、AIに持たせる知識（コンテキスト）も、AIを検証する基準（ハーネス）も、一度作ったら終わりではなく、運用から得た学びで更新され続けることが前提とされています。この更新サイクルが組織学習のループであり、ループエンジニアリングの最終的な対象です。

6. ループ設計の実践原則

各社の公開文書から、ループ設計の実践原則として共通して読み取れるものを5つに整理します。

原則1：検証手段を先に用意する

「検証を堅牢にすることに投資せよ」（Anthropic）。テスト・型チェック・期待出力など、AIが自分で答え合わせできる手段がないループは、人がボトルネックになります（出典：https://code.claude.com/docs/en/best-practices ）。

原則2：何を「良い」とするかを明文化する

「あなたとチームにとっての『良い』をスキルとしてエンコードする」（Anthropic）。暗黙の基準は、AIには伝わりません。コーディング規約・設計原則・ドメインルールを、AIが参照できる形式にすることがループの前提になります（出典：https://claude.com/blog/getting-started-with-loops ）。

原則3：評価データを本番から育てる

「本番データは、評価データセットを進化させる最も真正なソース」（OpenAI）。作りっぱなしの評価セットは現実から乖離します。実運用で見つかったエッジケースを評価に還元し続けます（出典：https://developers.openai.com/cookbook/examples/partners/evaldrivensystemdesign/receiptinspection ）。

原則4：レビューには独立した視点を使う

「新しいコンテキストを持つレビュアーはバイアスが少ない」（Anthropic）。生成した本人（同じコンテキストのAI）にレビューさせると、自分の出力に引きずられます。別セッション・別エージェントによるレビューが推奨されています（出典：https://claude.com/blog/getting-started-with-loops ）。

原則5：シンプルなループから始める

「すべてのタスクに複雑なループが必要なわけではない」（Anthropic）。ゴールベースの長時間ループや並列エージェントは強力ですが、まずターンベースの小さなループで検証手段と基準を固めることが先です（出典：https://claude.com/blog/getting-started-with-loops ）。

7.おわりに：ループは「作って終わり」ではない

プロンプトエンジニアリングが「AIに何を指示するか」を設計する技術だったとすれば、ループエンジニアリングは「AIがどう仕事を進め、どう失敗から回復するか」を設計する技術です。

エージェントが開発の主体となるにつれて、品質を左右するのは単発のプロンプトではなく、生成・検証・修正が自律的に回り続ける仕組みそのものになります。今後の生成AIネイティブ開発では、このループをいかに設計・改善し続けられるかが、開発体験と成果の両方を大きく左右するでしょう。

ループエンジニアリングは、逆説的ですが「完成しないもの」です。検証基準は本番の学びで更新され、AIに与える知識は運用の観察で改訂され、ループそのものの回し方も改善され続ける。OpenAI の言う通り、これは目的地ではなく継続した旅なのです。

当社は、生成AIを活用すること前提の開発体制づくりを支援しています。自社の開発手法をどこから設計すべきか整理したいなどの場合は、お問い合わせフォームからご相談ください。

出典一覧

1. Anthropic「Claude Code Best Practices」https://code.claude.com/docs/en/best-practices
2. Anthropic「Getting started with loops」https://claude.com/blog/getting-started-with-loops
3. Anthropic「How Anthropic teams use Claude Code」https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf
4. Anthropic「Equipping agents for the real world with Agent Skills」https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
5. OpenAI「Evaluation best practices」https://developers.openai.com/api/docs/guides/evaluation-best-practices
6. OpenAI Cookbook「Eval Driven System Design」https://developers.openai.com/cookbook/examples/partners/eval_driven_system_design/receipt_inspection
7. DORA「Capabilities: Continuous delivery」https://dora.dev/capabilities/continuous-delivery/
8. DORA「DORA's software delivery performance metrics」https://dora.dev/guides/dora-metrics/
9. DataCamp「Claude Code Best Practices」https://www.datacamp.com/tutorial/claude-code-best-practices
10. Anthropic「Effective context engineering for AI agents」https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
11. Anthropic Claude Cookbook「Context engineering: memory, compaction, and tool clearing」 https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools