Loop Engineering 2026年8月12日

評価と停止条件の設計：AIエージェントを正しく終わらせる

AIエージェントの反復を、自己申告ではなく証拠で完了判定する方法と、再試行・安全停止・人間へのエスカレーション条件を解説します。

#loop-engineering #evaluation #stop-condition #guardrails #evidence

難易度開発の実務経験がある方向けです種別リファレンス

停止条件はループの品質そのもの

エージェントが「完了しました」と出力しても、実環境が完了状態とは限りません。停止条件は、モデルの発言ではなく観測可能な証拠で定義します。

主張: テストを修正しました
証拠: 対象テストと全必須チェックの終了コードが0

OpenAIとAnthropicのエージェント評価ガイドも、実行過程の記録と最終的な環境状態を分けて扱います。

4種類の終了

終了種別	意味	例
Succeeded	完了条件を証拠が満たした	テスト・型・ビルドが成功
Exhausted	予算または試行上限に達した	3回修正しても同じ失敗
Blocked	外部入力なしでは進めない	権限、仕様、承認が不足
Unsafe	続行リスクが許容範囲を超えた	本番削除、秘密情報露出の疑い

ExhaustedやBlockedを失敗として隠さず、正常な制御結果として記録します。

評価器を階層化する

レベル1：構文・形式

JSON Schema
型チェック
必須フィールド
ファイル存在
リンク形式

レベル2：決定論的な動作

単体・統合・E2Eテスト
APIのステータスとDB状態
差分サイズや禁止ファイル
セキュリティスキャナー

レベル3：意味的品質

仕様との一致
文章の明瞭さ
UIの使いやすさ
リスクや例外の見落とし

レベル4：人間判断

公開可否
法務・ブランド判断
高額支出
不可逆変更

下位レベルで判定できるものをLLM評価だけに任せないことが原則です。

良い合格条件

合格条件には、対象、測定方法、閾値、証拠の鮮度を含めます。

gate:
  target: current_commit
  checks:
    - command: npm run check
      expected_exit_code: 0
    - command: npm test
      expected_exit_code: 0
  evidence_max_age_minutes: 10

古いコミットに対する成功結果は、現在の成果物の証拠にしません。

再試行ポリシー

再試行してよい失敗

一時的なネットワーク障害
修正箇所が特定されたテスト失敗
評価器から具体的な改善点が返った
コンテキスト不足を補える

すぐ止める失敗

権限や認証がない
仕様が矛盾している
禁止操作が必要
入力データが壊れている
同一原因が規定回数続いた
変更量や費用が上限を超えた

指数バックオフは一時障害には有効ですが、論理的な失敗を待ち時間で直すことはできません。

自己評価と独立評価

自己評価は高速で安価ですが、生成時の前提を引き継ぎます。重要な成果では、次を組み合わせます。

生成エージェントによる自己確認
機械的な検証
必要に応じて独立した評価エージェント
高リスク箇所の人間承認

Anthropicは、単一の評価方法で全問題を捕捉できないため、複数のgraderを組み合わせる考え方を示しています。

予算による停止

品質条件だけでなく資源条件も設定します。

最大モデル呼び出し回数
最大ツール呼び出し回数
最大経過時間
最大トークンまたは費用
最大変更ファイル数
最大並列数

予算超過時は成果を破棄するのではなく、現在の状態、試したこと、残課題、再開条件を保存します。

監査可能な証拠

最低限、次を記録します。

実行IDと入力版
使用したルール・モデル・ツール
各試行の開始・終了時刻
変更差分
評価結果と生データへの参照
続行・停止判断の理由
人間の承認または却下

思考過程の全文保存ではなく、再現と説明に必要なイベントと証拠を残します。