# Loop Engineeringとは — Agentの反復・検証・停止条件を設計する

> Loop Engineeringを、Agentへ作業を反復させるだけでなく、進捗判定・検証・予算・停止・人間への移譲を制御する設計として整理します。

Canonical URL: https://labs.eastbraver.com/guides/loop-engineering
Published: 2026-07-01
Updated: 2026-07-24
Category: field-guide
Tags: ai-agent, software-engineering, evaluation

Agentを`while`で囲み、「成功するまで続けて」と渡すだけでは、Loop Engineeringにはなりません。進捗がなくても費用を使い、同じToolを繰り返し、止める判断までAgent自身へ任せることになります。

Loop Engineeringは、AI Agentが「観測する、判断する、実行する、結果を検証する」という反復を、どの条件で続け、止め、人間へ戻すか設計することです。

Goal、進捗、検証、Retry、Budget、停止条件、状態の引き継ぎを一つの制御系として扱います。

この呼称は2026年に広がり始めた新しい実践用語です。標準化された定義ではありません。このGuideは2026年7月1日時点の一次情報を基準に、長時間Agentで共通する設計課題を整理します。

## LoopはAgentの外側で制御する

### 終了条件を持つAgent loop

AgentはGoalとSuccess criteriaに基づいて行動し、観測結果をVerifierまたはEvaluatorで判定します。回復可能なら次のTaskへ戻り、完了なら終了し、BlockedまたはUnsafeならHuman handoffへ切り替えます。

- GoalとSuccess criteriaを受けてAgentが行動します。
- 結果を観測し、VerifierまたはEvaluatorがDoneか判定します。
- 回復可能ならStateまたはTaskを更新してAgentへ戻します。
- 完了ならCompleteへ進み、BlockedまたはUnsafeならHuman handoffへ渡します。

*検証結果とBudgetで継続、完了、人間移管を決めるloop*

Model自身へ「終わるまで続けて」と書く方法では、停止と費用を外から保証できません。Orchestratorや[Harness](/guides/harness-engineering)が、Step数、Deadline、Tool権限、検証結果を見てLoopを制御します。

## Agent LoopとLoop Engineeringは範囲が違う

[AI Agent](/guides/ai-agent)の基本Loopは、ModelがToolを呼び、結果を受けて次の行動を選ぶ実行構造です。

Loop Engineeringは、そのLoopを本番や長時間作業で維持するための設計を扱います。

| Agent Loop | Loop Engineeringで追加する設計 |
| --- | --- |
| Modelを呼ぶ | Model、Prompt、ContextのVersionを固定する |
| Toolを呼ぶ | 権限、Idempotency、Retryを制御する |
| 結果を返す | Outcomeを独立に検証する |
| 続行を選ぶ | 進捗、Budget、Deadlineで続行可否を決める |
| 終了する | 完了、失敗、停止、人間移譲を分ける |

## 完了条件をAgentの自己申告にしない

長時間Agentは、見た目の整った成果物を作り、「完了」と回答できます。実際の機能、外部状態、受け入れ条件が満たされたかは別です。

- Testが通った
- Browserで主要Flowを完了できた
- API ResponseとDatabase状態が一致した
- 指定したFileが生成された
- 安全性Checkを通過した
- Evaluatorが閾値を満たした

[AnthropicのHarness Design](https://www.anthropic.com/engineering/harness-design-long-running-apps)は、GeneratorとEvaluatorを分け、各SprintのContractと検証を使う反復を示しています。生成と合否判定を同じ出力だけに任せないことが要点です。

## 進捗がないLoopを止める

同じErrorに対して文言だけを変え、何度も再試行する場合があります。回数上限だけでなく、進捗を判定します。

- 同じTool引数とErrorの反復
- 同じTest failureの継続
- 成果物Diffがない
- 評価Scoreが改善しない
- Context取得だけを繰り返す
- 費用または時間が上限へ近づく

状態Fingerprintや失敗分類を使い、同じ状態へ戻ったら別Strategy、人間へのHandoff、失敗終了へ切り替えます。

## BudgetはTokenだけではない

LoopのBudgetには複数の上限があります。

- Model call回数
- Input / Output Token
- Tool call回数
- 外部API費用
- Wall-clock time
- 同時実行数
- 書き込み操作数
- 人間のReview時間

一つのTaskがBudgetを使い切らないよう、User、Tenant、Workflow単位でも上限を持ちます。途中停止時に再開できるよう、状態とArtifactを外部へ保存します。

## Retry、Reflection、Replanを分ける

同じRequestをそのままやり直すRetry、結果を評価して修正するReflection、前提やTask分解を変えるReplanは別の操作です。

- 一時的なNetwork error: Backoff付きRetry
- Test failure: ErrorとDiffを渡して修正
- Goalの解釈違い: Planから見直す
- Permission denied: Retryせず権限確認へ戻す
- Safety violation: 即時停止または人間へ移譲

すべてを「もう一度考えて」で処理すると、原因と費用を追えません。

## 新しい用語として範囲を明示する

[2026年7月のLoop Engineeringに関するPreprint](https://arxiv.org/abs/2607.00038)は、Prompt、Context、Harness、Loopを異なる設計層として位置付けています。ただし、Preprintであり、業界標準の定義が確定したことを意味しません。

[OpenAIのHarness Engineering](https://openai.com/index/harness-engineering/)でも、AgentがReviewと修正を繰り返すFeedback loopや、環境側のConstraintが扱われています。Loop Engineeringは新しい名前ですが、State machine、Workflow、Retry、Queue、Circuit breaker、Evaluationといった既存のSoftware Engineeringを土台にします。

## よくある誤解

### Loopを長く回せば品質が上がる

Verifierが誤っている、Contextが不足している、進捗がない場合は、費用と誤操作が増えます。改善を測れないLoopは止めます。

### Agentが完了と言えば停止してよい

成果物、Test、外部状態を独立に確認します。自己申告は停止候補のSignalに留めます。

### Retry回数だけ決めれば安全に止まる

一回のTool callでも取り消せない影響があります。権限、Approval、操作回数、費用、Deadlineを合わせて制御します。

### Loop EngineeringがPrompt Engineeringを置き換える

Promptは各StepのInstructionに必要です。Loopは複数Stepをどう制御するかを扱い、置き換えではありません。

## EastBraver Labsの判断基準

EastBraver Labsでは、Loopを自律性の高さではなく、**止められるか、再開できるか、検証できるか**で評価します。

完了条件はAgentの外側に置き、同じ失敗の反復、Budget超過、権限不足、安全性違反を停止条件にします。更新系Toolは、Loop回数に関係なく一回ごとの認可とIdempotencyを確認します。

長く回ること自体に価値はありません。

人間が付きっきりにならなくても、途中状態と判断理由を後から追える。その状態を作れてから実行時間を伸ばします。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [エージェント基盤は非同期運用へ](/digest/ai-digest-20260708)
- [GPT-5.6とAI実行基盤の境界](/digest/ai-digest-20260710)
- [AIエージェント運用は堅牢性と統制へ](/digest/ai-digest-20260716)

## 検証範囲

- 一次情報: 公式ドキュメント / 研究論文 / 設計面からの分析
- ローカル検証: 手元で再現しています
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開