verification-loops

検証ループ

googleadsagent.ai™ による Agent Skills™ の一部です

説明

検証ループは、実行の各段階でエージェントの出力を検証する、体系的な評価パイプラインです。自律型エージェントにおける根本的な課題は信頼です。エージェントが正しいことをしたと、どうすればわかるのでしょうか？検証ループは、エージェントの実行パイプライン全体にチェックポイント評価、継続的なアサーション、複数段階のレビューチェックポイントを組み込むことで、この課題を解決します。このスキルは、googleadsagent.ai™ の本番環境で使用されている評価手法を活用しています。ここでは、Buddy™ がユーザーに提示する前に、Google Ads のすべての推奨事項を過去のデータ、予算の制約、ドメインルールと照合して検証します。

チェックポイント検証と継続的検証の違いは重要です。チェックポイント検証では、定義されたステージの境界（コミット前、分析後、デプロイ前）で出力を評価します。継続的検証では、生成中にリアルタイムでアサーションを実行し、ずれやハルシネーションが広がる前に検出します。どちらのアプローチも、複数の候補出力を生成し、採点器の合意に基づいて最良のものを選ぶ pass@k 指標によって補完されます。

本番環境の検証システムでは、型付き採点器が使われます。スキーマと制約の検証には決定論的採点器、意味的な品質評価には LLM-as-judge 採点器、重要な判断には人間参加型の採点器を用います。これらを組み合わせることで、パイプライン内の最も早く、最も低コストな時点でエラーを検出する、多層的な検証網が構築されます。

使用する場面

• エージェントの出力がビジネス上の意思決定やユーザー向けコンテンツに直接影響する場合
• 規制やコンプライアンス要件により、AI 生成コンテンツの監査証跡が必要な場合
• 複数段階のワークフローで、各段階の間に品質ゲートが必要な場合
• エージェントの精度を長期的に測定し、改善する必要がある場合（pass@k ベンチマーク）
• 生成されたコードをコミットまたはデプロイする前に、テストに合格させる必要がある場合
• 分析結果を正解データやビジネスルールと照合して検証する必要がある場合

仕組み

graph TD
    A[Agent Output] --> B[Stage 1: Deterministic Grader]
    B -->|Pass| C[Stage 2: LLM-as-Judge]
    B -->|Fail| D[Reject + Feedback Loop]
    C -->|Pass| E[Stage 3: Confidence Scoring]
    C -->|Fail| D
    E -->|High Confidence| F[Accept Output]
    E -->|Low Confidence| G{pass@k Available?}
    G -->|Yes| H[Generate k Candidates]
    H --> I[Rank by Grader Consensus]
    I --> F
    G -->|No| J[Human-in-the-Loop Review]
    J --> F
    D --> K[Error Context Injection]
    K --> L[Re-generation with Feedback]
    L --> B

検証パイプラインでは、すべてのエージェント出力を3つのステージで処理します。ステージ1では、スキーマ検証、制約チェック、型の検証といった、高速かつ低コストな決定論的採点器を適用します。ステージ2では、LLM-as-judge を使って、意味的な正確性、完全性、一貫性を評価します。ステージ3では、採点器から得られたシグナルを組み合わせて信頼度スコアを算出します。信頼度の低い出力では pass@k 生成が実行され、複数の候補が生成されて、採点器の合意に基づいて順位付けされます。却下された出力には具体的なエラーフィードバックが付与され、再生成プロンプトに挿入されます。

実装

多段階検証パイプライン：

interface Grader {
  name: string;
  type: "deterministic" | "llm_judge" | "human";
  evaluate(output: string, context: VerificationContext): Promise<GradeResult>;
}

interface GradeResult {
  pass: boolean;
  score: number;
  feedback: string;
}

class VerificationPipeline {
  private stages: Grader[][] = [];

  addStage(graders: Grader[]): void {
    this.stages.push(graders);
  }

  async verify(output: string, context: VerificationContext): Promise<VerificationResult> {
    const stageResults: StageResult[] = [];

    for (const [idx, graders] of this.stages.entries()) {
      const grades = await Promise.all(
        graders.map(g => g.evaluate(output, context))
      );
      const stagePassed = grades.every(g => g.pass);
      const stageScore = grades.reduce((sum, g) => sum + g.score, 0) / grades.length;

      stageResults.push({ stage: idx, grades, passed: stagePassed, score: stageScore });

      if (!stagePassed) {
        return {
          accepted: false,
          stageResults,
          feedback: grades.filter(g => !g.pass).map(g => g.feedback).join("\n"),
        };
      }
    }

    const confidence = stageResults.reduce((sum, s) => sum + s.score, 0) / stageResults.length;
    return { accepted: true, stageResults, confidence };
  }
}

Pass@k による候補選択：

async def pass_at_k(task, generator, verifier, k=5):
    """Generate k candidates and select the best by verification score."""
    candidates = await asyncio.gather(*[
        generator.generate(task) for _ in range(k)
    ])

    scored = []
    for candidate in candidates:
        result = await verifier.verify(candidate, task.context)
        scored.append({
            "output": candidate,
            "accepted": result.accepted,
            "confidence": result.confidence,
            "feedback": result.feedback,
        })

    accepted = [s for s in scored if s["accepted"]]
    if accepted:
        return max(accepted, key=lambda s: s["confidence"])

    return max(scored, key=lambda s: s["confidence"])

LLM-as-judge 採点器：

class LLMJudgeGrader:
    JUDGE_PROMPT = """You are an expert evaluator. Assess the following agent output
against the given task requirements.

Task: {task}
Output: {output}
Criteria: {criteria}

Respond with JSON:
{{"pass": true/false, "score": 0.0-1.0, "feedback": "specific feedback"}}"""

    def __init__(self, judge_model, criteria):
        self.judge_model = judge_model
        self.criteria = criteria

    async def evaluate(self, output, context):
        prompt = self.JUDGE_PROMPT.format(
            task=context.task_description,
            output=output,
            criteria=self.criteria,
        )
        response = await self.judge_model.generate(prompt, temperature=0.0)
        return json.loads(response)

決定論的スキーマ採点器：

class SchemaGrader:
    def __init__(self, schema: dict):
        self.schema = schema

    async def evaluate(self, output, context):
        try:
            parsed = json.loads(output)
            jsonschema.validate(parsed, self.schema)
            return {"pass": True, "score": 1.0, "feedback": "Schema valid"}
        except jsonschema.ValidationError as e:
            return {"pass": False, "score": 0.0, "feedback": f"Schema violation: {e.message}"}
        except json.JSONDecodeError:
            return {"pass": False, "score": 0.0, "feedback": "Invalid JSON"}

ベストプラクティス

1. 採点器はコスト順に実行する — 決定論的（無料）採点器を LLM-as-judge（高コスト）採点器より先に実行します。ほとんどの失敗は低コストで検出できます。
2. 実行可能なフィードバックにする — 再生成プロンプトに挿入する採点器のフィードバックは、修正方法を導けるだけ具体的にします（「出力が間違っています」ではなく「フィールド X がありません」）。
3. 採点器ごとの合格率を追跡する — 一度も失敗しない採点器は、価値を生まずに遅延を増やします。常に失敗する採点器は、プロンプトまたはモデルに問題があることを示します。
4. Pass@k を戦略的に使う — 5つの候補を生成するとトークンのコストは5倍になります。精度がコストに見合う価値の高い出力に限って pass@k を使います。
5. 検証モデルと生成モデルを分ける — 判定に別のモデルを使うと、同じモデルが同じ誤りを犯し、見逃すことで生じる相関したエラーを減らせます。
6. 検証結果をキャッシュする — 同一タスクに対する同一の出力には、再評価せずキャッシュ済みの検証結果を返します。
7. ユースケースごとに信頼度のしきい値を設定する — コード生成には0.95の信頼度が必要な場合がありますが、創作文章では0.7でも許容されることがあります。

プラットフォームの互換性

機能	Claude Code	Cursor	Codex	Gemini CLI
決定論的な採点	✅ 完全対応	✅ 完全対応	✅ 完全対応	✅ 完全対応
LLM による判定	✅ 完全対応	✅ API 経由	✅ API 経由	✅ API 経由
pass@k 生成	✅ 完全対応	✅ サブエージェント	✅ 完全対応	✅ 完全対応
コミット前フック	✅ ネイティブフック	✅ Git フック	✅ Git フック	✅ Git フック
信頼度スコアリング	✅ 完全対応	✅ 完全対応	✅ 完全対応	✅ 完全対応

Mythos Preview の参考例

Anthropic の Mythos Preview パイプラインは、発見ではなくトリアージを目的とする2 回目のエージェントパスで締めくくられます。彼らは 「次のバグ報告を受け取りました。これが実在し、興味深いものか確認してもらえますか？」 といった形でプロンプトを入力し、事実ではあるものの影響の小さい問題を、深刻で広く関係する問題から選別します。

これを検証エージェントのパターンとして活用してください。プライマリエージェントが発見事項を出したら、その成果物と明示的な懐疑姿勢を示し、「実在する」「重要である」「実行可能である」ことの基準を含めて、新たなレビューを開始します。出典：Mythos Preview。

関連スキル

• 自己修復エージェント - 検証ループでエージェントの出力が却下された際に作動するエラー回復
• エージェント本能システム - 検証が必要になる前にエラーを防ぐ、アクション前の検証
• プロンプトアーキテクチャ - 検証の失敗率を低減する、プロンプト設計におけるスキーマの適用

キーワード

verification-loops, evaluation, graders, pass-at-k, llm-as-judge, confidence-scoring, checkpoint-verification, continuous-evaluation, quality-gates, agent-skills

---

© 2026 googleadsagent.ai™ | Agent Skills™ | MIT License