ループエンジニアリング完全ガイド：AIエージェントを安全に反復実行する設計
AIエージェントの実行・観測・評価・修正・停止を反復可能な仕組みにするループエンジニアリングを、コンテキスト・ハーネス・グラフとの違いから実践手順まで解説します。
ループエンジニアリングとは
ループエンジニアリングとは、AIエージェントが目標に向かって実行し、結果を観測し、評価し、必要なら修正して再実行する一連のサイクルを設計する考え方です。
2026年半ばから広がり始めた新しい呼称であり、現時点で単一の標準定義があるわけではありません。本記事では、IBMの整理、OpenAI Agents SDKの実行ループ、AnthropicのEvaluator-Optimizerや長時間エージェントの知見を基に、次のように定義します。
目標、状態、実行、観測、評価、再試行、停止、エスカレーションを、証拠に基づいて繰り返せる制御系として設計すること。
重要なのは「AIを何度も呼ぶこと」ではありません。何を成功と見なすか、失敗時に何を変えるか、いつ諦めるかまで決まって初めて、運用可能なループになります。
4つのエンジニアリングとの関係
| 領域 | 主に設計するもの | 代表的な問い |
|---|---|---|
| Prompt Engineering | 1回の指示 | どう依頼すれば意図が伝わるか |
| Context Engineering | モデルに見せる情報 | 今回の推論に何を渡すか |
| Harness Engineering | 1回の実行環境 | どのツール・権限・検証を与えるか |
| Loop Engineering | 反復する実行サイクル | 何を見て続行・修正・停止するか |
| Graph Engineering | 分岐・並列・合流を含む全体構造 | どの経路で処理を進めるか |
これらは世代交代ではなく、異なる設計面です。ループの1周ごとにコンテキストを組み立て、ハーネス内でエージェントを実行します。複数の分岐や専門エージェントが必要になれば、そのループをグラフの一部として配置します。
エージェントの内側と外側にある2つのループ
内側の実行ループ
OpenAI Agents SDKは、モデルを呼び出し、ツール呼び出しやハンドオフが返れば実行結果を追加して再度モデルを呼び出し、最終出力またはターン上限で終了する構造を持ちます。
推論 → ツール実行 → 結果を観測 → 再推論 → 最終出力これは1回のタスク内で動く内側のループです。モデルとツールの対話を成立させますが、成果物が業務上正しいかまでは保証しません。
外側の改善ループ
外側のループは、1回のエージェント実行が終わった後に成果物を評価し、再試行・承認・停止を決めます。
仕事を選ぶ
↓
エージェントを実行
↓
テスト・評価・レビュー
↓
合格 ─→ 完了または人間承認
不合格 → 修正情報を付けて再実行継続的な保守、日次調査、CI修復、コンテンツ更新などでは、この外側のループが品質と安全性を左右します。
ループを構成する9要素
1. Goal：目標
「改善する」ではなく、観測できる到達状態を定義します。
- 悪い例：テストを直す
- 良い例：失敗中のテストを最小変更で通し、全必須チェックが成功した状態にする
2. Trigger：起動条件
人間の依頼、スケジュール、Webhook、CI失敗、監視アラートなどです。同じイベントによる二重起動も考慮します。
3. State：状態
現在の目標、試行回数、直前の結果、変更対象、承認待ち状態などを永続化します。会話履歴だけを状態の正本にしないことが重要です。
4. Context：今回見せる情報
全履歴を詰め込むのではなく、現在の試行に必要な証拠、制約、差分、失敗理由を選びます。
5. Action：実行
モデル呼び出し、ツール使用、サブエージェント委譲などです。実行権限と変更可能範囲を明示します。
6. Observation：観測
終了メッセージではなく、ファイル差分、テスト結果、DB状態、API応答など実環境の結果を取得します。
7. Evaluation：評価
決定論的チェックとモデル評価を使い分けます。
- 決定論的：型チェック、テスト、スキーマ検証、件数照合
- 推論型：文章品質、設計妥当性、ユーザー体験、リスク評価
8. Control：続行判断
合格、修正可能、入力不足、権限不足、予算超過などに分類し、次の行動を決めます。
9. Stop / Escalate：停止と人間移管
完了だけでなく、安全停止も正常な終了です。試行回数、費用、時間、変更量、リスクの上限を超えたら人間へ戻します。
良いループの設計原則
証拠で状態を更新する
「エージェントが完了と言った」ことと、「完了条件を満たした」ことを分けます。テスト結果や実データの状態が確認できるまで、完了へ遷移させません。
同じ失敗をそのまま繰り返さない
再試行には、失敗分類と新しい情報が必要です。同じ入力・同じツール・同じ条件での無制限再試行は、コストを増やすだけです。
最小の閉じたループから始める
Anthropicは、必要になるまで複雑性を増やさない方針を推奨しています。まず1つの明確なタスク、1つの検証、少ない再試行回数で成立させます。
不可逆操作をループの外へ出す
本番公開、送金、削除、外部送信などは、人間承認または別の強い制御境界を設けます。
導入手順
- 繰り返している1つの作業を選ぶ
- 開始状態と完了状態を定義する
- 成功を判定できる証拠を決める
- 1回の実行に必要なコンテキストとツールを絞る
- 失敗を「再試行可能・入力不足・危険・恒久エラー」に分類する
- 試行回数・時間・費用・変更量の上限を決める
- 人間へ戻す条件を決める
- 実行履歴と評価結果を記録する
- 小さな対象で運用し、失敗例から制御を更新する
よくある誤解
「ループにすれば自律化できる」
ループは自律性を増やしますが、誤りも増幅します。評価器が弱い場合、間違った成果を繰り返し強化する危険があります。
「モデルが自己評価すれば十分」
自己評価は補助にはなりますが、独立した証拠の代わりにはなりません。コードならテスト、業務処理なら外部状態、公開物なら人間レビューを組み合わせます。
「成功するまで無限に回す」
停止条件がないループは障害です。最大試行回数、最大費用、期限、重複失敗、権限不足を明示的な停止理由として扱います。