Evaluator-Optimizer（評価器・最適化器）

生成を担うLLMと評価を担うLLMをシステムとして分離し、明確な合格基準に対する評価→フィードバック→改善のループを合格まで反復する。誤出力の損害が大きいドメインで単一エージェントへの依存を断つパターンである。

別名

呼称	出典
Maker-Checker Loop	Azure
Generator-Verifier、Critic Loop	Azure記載の別称
LLM-as-a-Judge	評価器の実装手法としての慣用名

Azureは「reflection loops」も別称に挙げるが、本カタログでは同一エージェント内の自己批評を Reflection として区別する。

問題

融資判断・法務レビューのように誤出力の損害が非対称に大きいドメインでは、生成者自身の自己評価は信頼できない。生成時と同じ文脈・バイアスを共有するため、系統的な誤りを自分では見つけられない。

コンテキスト

適用する:

明確な評価基準を言語化でき、反復改善に実測的な価値があるタスク。人間のフィードバックでLLM出力が明確に良くなる文芸翻訳などが該当する
誤出力のビジネス・安全リスクが高いタスク

適用しない（不要な）ケース:

評価基準が曖昧で、評価器が一貫した合否判定を下せないタスク
機械的な検証（テスト・スキーマ）で足りるタスク（→ Prompt Chaining のゲート）
時間予算が秒単位のタスク

解決

生成器と評価器を分離し、評価器には生成文脈を共有させず、別モデルまたは別プロンプトで独立した判定を行わせる。(1)生成器が成果物を生成、(2)評価器が合格基準に照らして合否と具体的なフィードバックを返す、(3)不合格なら生成器がフィードバックを反映して再生成、(4)合格または反復上限まで繰り返す。

反復上限に到達した場合のフォールバックとして、人間へのエスカレーション、または品質警告付きで最良結果を返す処理を必ず定義する。評価器が合否だけでなく、次の生成に利用できる具体的な指摘を返すことが改善ループの実効性を左右する。

python

def evaluate_and_optimize(task, criteria, max_iterations=5):
    artifact = llm("成果物を生成せよ", task=task)

    for _ in range(max_iterations):
        verdict = llm(                     # 評価器: 別モデル・別プロンプト
            "合格基準に照らして独立に評価し、合否と具体的な指摘を返せ",
            artifact=artifact,
            criteria=criteria,
            context=None,                  # 生成器の推論過程は共有しない
        )
        if verdict.passed:
            return artifact
        artifact = llm(                    # 生成器: 指摘を反映して再生成
            "指摘をすべて反映した改善版を生成せよ",
            task=task,
            artifact=artifact,
            feedback=verdict.feedback,
        )

    return escalate(artifact, warning="反復上限到達。未合格のまま返却")

実装の要点:

評価器を生成器から分離する。 別モデル・別プロンプトを選び、生成時の推論過程や自己正当化を評価器へ渡さない
合格基準を仕様として固定する。 判定可能なルーブリック、必須条件、重大な違反を明文化し、評価結果とともに具体的な改善指示を記録する
上限到達時の扱いを先に決める。 無限反復を許さず、人間へのエスカレーションまたは品質警告付きのベスト結果返却を選択可能にする

トレードオフ

✅ 生成バイアスから独立した評価により、生成者が系統的に見逃す誤りを発見しやすい
✅ 合格基準が明文化され、品質を仕様として管理できる
⚠️ 呼出数が2倍以上になり、コストとレイテンシが増える
⚠️ 評価器自体の精度が新たなボトルネックになる。甘い評価器は誤りを素通しし、厳しすぎる評価器は反復を増やすため Budget Guard が必須である

クラウドパターンとの対応

クラウドパターン	本パターンでの再定義
Gatekeeper	「要求を検証専任コンポーネントが仲介する」から「検証対象をリクエストの正当性から、生成物のセマンティックな品質へ広げる」へ。ゲートキーパーが要求ではなく成果物を評価し、不合格時は生成器へ戻す

これは、CI/CDのQuality Gateや金融のMaker-Checker（四眼原則）という、クラウド以前から続く検証分離の系譜にも位置付けられる。

出典・参考

Anthropic — Building Effective Agents（Evaluator-optimizer ワークフローの定義と適用条件）
Microsoft — AI Agent Orchestration Patterns（Maker-checker loop の要件: 合格基準・反復上限・フォールバック）
Azure Architecture Center — Gatekeeper pattern（系譜元のクラウドパターン）

Evaluator-Optimizer（評価器・最適化器） ​

別名 ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

クラウドパターンとの対応 ​

関連パターン ​

出典・参考 ​

Evaluator-Optimizer（評価器・最適化器）

別名

問題

コンテキスト

解決

トレードオフ

クラウドパターンとの対応

関連パターン

出典・参考