評価運用の成熟段階 — Braintrust フィル・ヘッツェル氏

AI エージェント評価の成熟：バイブスチェックから「状態再現」へ、Braintrust 氏が語る実運用への道筋

AI エージェントの実装において、「品質保証」はもはや後回しにできない最重要課題です。BrainTrust のフィル・ヘッツェル氏は、評価プロセスが単なる直感（バイブス）チェックから始まり、最終的に複雑なシステム状態を扱う高度な自動化へと進化すると説きます。本記事では、人間のドメイン知識をどう自動化に取り込むか、そして外部システムとの相互作用下でいかに信頼性の高い評価を行うかという、実務家が直面する核心課題と解決策を解説します。

評価の目的は「リスク管理」と「開発速度」の両立

まず大前提として、AI エージェントの評価（Eval）がなぜ必要なのかを明確にしておく必要があります。多くの組織が陥りがちなのは、「テストを完璧にすること」自体が目的化してしまう点です。

評価を行う理由は、エージェントの品質向上に尽きます。それはリスクに対する防御策であり、同時に開発速度を高める攻撃的な手段でもあります。

ヘッツェル氏は、評価には二つの側面があると指摘します。

1. 防御的役割: ブランドの評判毀損やコスト超過、コンプライアンス違反といったリスクを防ぐこと。本番環境で顧客に無礼な回答をさせたり、過剰なトークン消費を引き起こしたりしないための安全装置です。
2. 攻撃的役割: 微調整（Fine-tuning）やプロンプト変更が、実際にアプリケーション全体の性能を向上させているかを検証すること。単なる「バグ発見」ではなく、「どの改善が効果があったか」を定量的に把握し、開発の方向性を決めるための羅針盤です。

重要なのは、評価は「単体テスト（Unit Test）」とは異なるという点です。単体テストでは網羅的なケースを想定してすべて通すことが求められますが、AI エージェントの失敗モードは無限に存在します。すべての可能性を網羅しようとすれば、開発は止まってしまいます。

評価結果は完璧である必要はありません。時には方向性を示すだけでも十分です。LLM を用いた非確定的な手法でも、正しい方向へ進んでいれば問題ありません。

成熟度モデル：バイブスチェックから LLM 判定器へ

エージェント開発における評価プロセスは、単純な直感から複雑な自動化へと段階的に進化します。ヘッツェル氏はこの進化を「4 つの成熟段階」として整理しています。

1. バイブスチェック（Vibe Check）

プロジェクト初期では、何もしないよりはマシです。「雰囲気」で判断するバイブスチェックから始めます。ただし、単に「いいね・悪いね」を付けるだけでは不十分です。重要なのは記録することです。

推奨するのは、バイブスチェックを行う際に同時に記録も残すことです。専門家が出力を分析し、「なぜ良いのか」「なぜ悪いのか」という根拠（正当化）を残すことが、次の段階への鍵となります。

2. 人間の注釈と失敗モードの特定

次に、人間のアノテーター（評価者）が「親指を立てるか下げるか」だけでなく、その理由を記述するフェーズです。ここで抽出されるのは、ドメイン固有の知識です。

その理由は、ドメイン固有の知識を人間アノテーターから多く抽出し、最終的にスケーリングできるようにするためです。

専門家が「この回答は不適切だ」と判断した背景にある理由（例：事実と矛盾している、トーンが不適切など）を記録することで、エージェント特有の「失敗モード」が見えてきます。この人間による注釈データが、自動化への布石となります。

3. LLM 判定器（LLM as a Judge）の活用

蓄積された人間の判断と理由付けを元に、LLM を評価者として使うフェーズです。これにより、大規模な評価が可能になります。

しかし、ここで注意が必要です。「LLM で LLM を評価する」こと自体が信頼できるかを検証する必要があります（Eval the Eval）。

LLM を評価者に使う際、単に LLM にローブやマントを着せても、それが本質的に信頼性が高まるわけではありません。LLM の判断を盲目的に信じてはいけません。

LLM 判定器が人間の判断と整合しているかを確認する「正解データセット」を用意し、評価者自体を評価する必要があります。また、ツール呼び出しの回数やトークン使用量など、コードで決定論的に判定できる項目については、LLM に任せず直接スコアリング関数で処理すべきです。

複雑なシステム状態の再現：実運用への最大の壁

評価が成熟するにつれ、直面するのが最も難しい課題です。それは「外部システムとの相互作用」を伴う評価です。

エージェントが単にテキストを返すだけでなく、データベースの更新（CRUD）や外部 API の呼び出しを行う場合、オフラインで評価を実行するのは極めて困難になります。本番環境の状態を再現せずには、真の評価ができないからです。

評価はテストの実行だと考えず、本番環境を再実行するものとして捉えてください。

ヘッツェル氏は、この課題に対する具体的な解決策を2つ提示しています。

1. モック API と状態の近似化

実際の生産環境を汚染したくない場合や、オフラインでテストしたい場合は、モック API を使用して外部システムとの相互作用をシミュレートします。評価実行中に、エージェントが触れるべき「システムの状態」をトレース内に埋め込み、インフラストラクチャとして構築することで、本番環境に近い挙動を再現します。

2. タイムスタンプクエリによる状態の復元

より高度な手法として、「タイムスタンプクエリ」があります。例えば、あるタスクが実行された時点でのベクトルデータベースの状態を、その時のバージョンで問い合わせる技術です。

入力データがある時点で追加された場合、バージョンクエリを実行し、特定の時点でのデータベースを問い合わせることができます。こうすることで、そのタスクが最初に実行された時点の状態を適切に表現できます。

このようにして、本番環境のトレース（Flying Wheel）を収集・保存し、オフラインで正確な状態を再現した上で再評価を行うことで、開発者は本番投入への自信を持てるようになります。

まとめ：人間の知恵を自動化へ、そして信頼へ

AI エージェントの評価は、直感から始まり、人間のドメイン知識を抽出して LLM 判定器としてスケールさせ、最終的に複雑なシステム状態まで再現可能な高度な自動化へと進化します。このプロセスの核心は、単に「バグを見つける」ことではなく、人間の専門知見をどう自動化プロセスに組み込み、リスク管理と開発速度の両立を実現するかにあります。

評価自体を評価する（Eval the Eval）という姿勢を持ち、本番環境の状態をいかに再現して信頼性を高めるかが、エンタープライズレベルでの AI 導入成功への鍵となります。