1. はじめに
この記事を作成する背景は、評価の設計まではできても、それを日々の開発と本番運用へ接続できずに終わる例が多いことです。データセットと評価器を用意しても、実行が手動のままなら変更のたびに劣化を見逃します。逆に自動化しても、モデル評価器の誤りを測らずに閾値へ使えば、誤った合否で意思決定することになります。
本記事の目的は、Part 1 で設計した評価資産を、統制されたモデル評価器・CI 品質ゲート・本番モニタリング・チーム体制・導入計画として運用へ落とし込む方法を示すことです。
Part 1 の結論を短く振り返ります。生成 AI の評価は従来のテストを置き換えず、決定的に検証できる部分はコードで厳密に測ります。評価対象はモデル、コンポーネント、E2E／軌跡、プロダクト成果の 4 レイヤへ分けます。指標名より先に失敗タクソノミーを作り、各分類へ重大度と検知手段を割り当てます。ケースは構造化して保存し、失敗分類・評価器・品質ゲートへ機械的に接続できる形にします。ここから先が、その資産を回し続けるための運用です。
2. LLM-as-a-judge の限界と統制
2.1 有用だが、正解そのものではない
自由記述を大規模に評価するうえで LLM-as-a-judge は有用です。しかし研究結果は、評価モデルにも系統的な誤りがあることを示しています。
| 研究 | 主な示唆 |
|---|---|
| MT-Bench / Chatbot Arena | GPT-4 と人間の高い一致を報告する一方、位置、冗長性、自己強化バイアスを確認[^mtbench] |
| Judging the Judges | 最良クラスの評価モデルでも人間評価を下回り、スコアが最大 5 点ずれる例を報告[^judging-judges] |
| JudgeBench | 難しい客観問題のペア比較では、強力な評価モデルもランダム推測をわずかに上回る程度と報告[^judgebench] |
| Who Validates the Validators? | LLM で生成した評価基準も対象モデルの問題を継承し、人間による検証が必要と指摘[^validators] |
この結果は「LLM 評価器を使うべきでない」という意味ではありません。どの条件でどれだけ間違うかを測ってから使うことが必要です。
2.2 実務で入れる統制
次の統制は、上記研究、Anthropic の人間較正の推奨、OpenAI の評価ガイドを踏まえた本記事の実務的な整理です。OpenAI のガイドはモデル採点にもエラー率があるため大規模実行前に人間評価で検証し、生成側とは別のモデルで採点する方法を推奨しています。なお、OpenAI のホスト型 Evals プラットフォーム自体は廃止予定です。[^anthropic-evals][^openai-evals]
- コード優先: 正解を計算、実行、参照できる部分はモデルへ委ねない
- 人間整合セット: 専門家が独立に付けたラベルで一致率と誤り方を測る
- 観点分離: 正確性、完全性、トーン、安全性を別々に採点する
- 順序テスト: ペア比較では A/B の提示順を入れ替える
- 別モデル採点: 可能なら生成モデルと異なる評価モデルを使う
- 設定固定: 評価モデル、バージョン、プロンプト、ルーブリック、閾値を記録する
- 判断不能を許す: 根拠不足時に無理に合否を出さず、人間レビューへ送る
- 定期再較正: モデルやルーブリックを変更したら人間整合を再測定する
人間評価にも評価者間差があります。評価者ごとの傾向、判断理由、不一致率を記録し、合意できないケースを「モデルの失敗」と決めつけないことが重要です。
2.3 判定プロンプトは 4 ブロックに分ける
統制 3 と 7 を実装に落とすと、判定プロンプトの形が決まります。「この回答は良いですか」と尋ねる形は、観点が混ざり、判断不能を表現できず、理由が残らないため避けます。次は説明用の例として、根拠性を測る判定プロンプトの構造を示したものです。
【役割】提示された根拠だけを使って、回答の根拠性を判定する
【観点】この判定では「根拠性」のみを見る。文体、長さ、丁寧さは判定に含めない
【入力】質問 / 提示された根拠 / 評価対象の回答
【合格条件】
- 回答中のすべての事実主張が、提示された根拠から確認できる
- 根拠にない事項は、推測であることが明示されている
【不合格の例】
- 根拠にない数値・日付・固有名を断定している
- 根拠の一部を反転・誇張して述べている
【判断不能とするケース】
- 根拠が壊れている、または回答と対象領域が一致しない
【出力】{ "verdict": "pass" | "fail" | "unknown",
"unsupported_claims": [...], "reason": "..." }
要点は 4 つです。第一に、観点を 1 つに限定して他の観点を明示的に除外します。第二に、合格条件を主張単位まで下ろします。第三に、不合格の例（反例）を書きます。第四に、unknown を許可し、根拠不足を無理に合否へ丸めさせません。unsupported_claims のようにどこが問題だったかを構造化して返させると、誤判定のレビューが目視の読み比べではなく差分確認になります。
観点ごとにプロンプトを分けると呼び出し回数は増えますが、1 つの判定が壊れたときに他の観点のスコアが巻き添えにならない利点があります。費用が問題になる場合は、コード評価器で足切りしたケースだけをモデル評価器へ渡します。
2.4 人間整合は「一致率」だけで見ない
統制 2 の人間整合セットは、一致率 92% のような 1 つの数字にすると、肝心の情報が落ちます。見るべきは次の 3 つです。
| 見るもの | 具体的に記録すること | 分かること |
|---|---|---|
| 一致率 | 人間ラベルと評価器判定が一致した割合 | 全体的な使用可否の目安 |
| 誤りの向き | 人間が不合格としたものを合格にした件数と、その逆の件数 | 評価器が甘いのか厳しいのか |
| 不一致の理由 | 不一致ケースごとの、人間の判断理由と評価器の出力理由 | ルーブリックの欠陥か、評価器の能力不足か |
とくに誤りの向きは判定に直結します。人間が不合格としたものを評価器が合格にする誤り（見逃し）は、品質ゲートをすり抜けます。逆向きの誤り（過検知）は開発を止めますが、事故にはなりません。同じ一致率でも、見逃しに偏っている評価器は重大度の高い分類へ使えません。
不一致の理由を読むと、多くの場合はモデルではなくルーブリック側に原因があります。「完全性」の定義が人によって違う、根拠の粒度が決まっていない、といった曖昧さは、評価器を変えても解消しません。人間整合セットは評価器の成績表であると同時に、ルーブリックの不具合検出器として使います。
3. オフライン評価、オンライン評価、CI 品質ゲート
3.1 オフラインとオンラインは役割が違う
LangSmith は、出荷前の curated dataset に対するオフライン評価と、本番の実ユーザー操作を対象にするオンライン評価を分けています。オンラインでは参照回答がないため、ルール、ヒューリスティック、reference-free なモデル評価器を使い、フィルターとサンプリング率で費用を制御します。[^langsmith]
| 観点 | オフライン評価 | オンライン評価 |
|---|---|---|
| 主目的 | 変更比較、回帰検知、リリース判定 | 未知の失敗、ドリフト、実利用品質の検知 |
| データ | 版管理された代表・境界・敵対ケース | サンプリングした本番トレース |
| 正解 | 参照回答、期待状態、ルーブリックを持てる | 多くの場合は正解がない |
| 実行時点 | PR、モデル変更、定期、リリース前 | リリース後に継続 |
| 主な出力 | 比較レポート、品質ゲート、失敗差分 | アラート、失敗クラスタ、追加すべき評価ケース |
Microsoft Foundry も、CI/CD の自動品質ゲート、本番トラフィックのサンプリング評価、定期評価、定期レッドチーミングを一つの観測モデルに含めています。[^microsoft-observability]
3.2 CI ゲートは一つの総合点にしない
品質ゲートは、重大な失敗を平均値で隠さないように設計します。次は説明用の例であり、普遍的な推奨値ではありません。
required:
critical_safety_failures: 0
unauthorized_tool_calls: 0
regression_pass_rate: ">= 0.98"
guardrails:
groundedness_drop: "<= 0.02"
p95_latency_increase: "<= 0.10"
cost_per_task_increase: "<= 0.15"
manual_review:
- low_judge_confidence
- high_risk_policy_change
閾値は業界の一般値からコピーせず、現在のベースライン、失敗時の影響、人間整合セット、許容予算から決めます。Capability スイートは改善観測に使い、Regression と重大安全性ケースをマージ可否へ使うと、挑戦的なケースの低得点で常に開発が止まることを避けられます。
3.3 実行の重さを段階で分ける
すべての評価を毎 PR で回すと、時間と費用が理由で無効化されます。実行をトリガーごとに段階化すると継続しやすくなります。次は説明用の例です。
| トリガー | 実行するスイート | 目安の規模 | 判定 |
|---|---|---|---|
| PR（プロンプト・コード変更） | Regression + 重大安全性ケース、決定的評価器中心 | 数分・1 試行 | マージ可否を止める |
| PR（モデル・検索設定の変更） | 上記 + Capability + モデル評価器 | 数十分・3 試行 | マージ可否を止める |
| 毎日の定期実行 | 全スイート + 敵対ケース | 時間単位・5 試行 | 劣化検知とアラート |
| リリース前 | 全スイート + 人間レビュー対象の抽出 | 半日規模 | リリース判定 |
| 本番（継続） | reference-free なオンライン評価 | サンプリング率で制御 | アラートと失敗キューへ投入 |
判定を止めるゲートに使うのは、上 2 行の決定的評価器と重大度の高い分類に限定します。モデル評価器の結果は、確信度が低いケースを manual_review へ送る形で使うと、2.4 で見た見逃しの影響を限定できます。
また、失敗した実行は再実行して緑にするのではなく、失敗ケースの一覧・行単位スコア・評価理由・トレースへのリンクを成果物として残します。原因が「評価器の誤判定」だった場合は、その事実自体を人間整合セットへ追加します。
3.4 本番の失敗でループを閉じる
オンライン評価で見つけた失敗は、その場のプロンプト修正で終わらせません。
- トレースと最終状態を保存する
- 個人情報・機密情報を除去または置換する
- 既存の失敗分類へ割り当てる。なければ分類を追加する
- 再現可能な最小ケースにする
- 適切な評価器と期待結果を付ける
- 修正前に失敗し、修正後に合格することを確認する
- Regression スイートへ追加する
この流れが、運用ログを組織の品質資産へ変えます。6 を省くと、実際には再現していないケースが増え、スイートの信頼性が下がります。
4. 成果物、チーム、リポジトリ構成
4.1 最低限の成果物
| 成果物 | 内容 | 主なオーナー |
|---|---|---|
| Eval Spec | 目的、対象外、成功基準、リスク、評価レイヤ | Product、Domain、AI/ML |
| 失敗タクソノミー | 失敗分類、重大度、検知方法、対応方針 | QA、Support、Domain |
| 評価データセット | 入力、期待結果、境界・否定・敵対ケース、由来 | Domain、QA、Data |
| 評価器・ルーブリック | コード、モデル、人間評価の基準 | Software、AI/ML、Domain |
| 人間整合セット | 専門家ラベル、不一致、評価理由 | Domain、Safety、QA |
| 実験レポート | 条件、試行数、分布、費用、遅延、失敗差分 | AI/ML、Software |
| 品質ゲートポリシー | 必須条件、閾値、例外承認、ロールバック条件 | QA、SRE、Security、Product |
| 本番フィードバックキュー | 失敗トレース、分類、担当、データセット化状況 | Operations、Support、Engineering |
Eval Engineering は一人の「Eval Engineer」だけに閉じる仕事ではありません。ドメイン専門家が「何が正しいか」を定義し、ソフトウェアエンジニアが再現可能なハーネスを作り、AI/ML エンジニアがモデルと評価器を検証し、QA・セキュリティが境界と攻撃を設計し、運用担当が本番の失敗を戻す共同作業です。
4.2 最小リポジトリ構成
次は特定ツールへ依存しない本記事の推奨例です。
evals/
├── SPEC.md
├── TAXONOMY.md
├── datasets/
│ ├── regression/
│ ├── capability/
│ ├── adversarial/
│ └── human-alignment/
├── graders/
│ ├── deterministic/
│ └── judges/
├── runners/
├── policy/
│ └── gates.yaml
├── reports/
└── CHANGELOG.md
モデル評価器のプロンプトもコードと同様にレビューし、変更理由と人間整合への影響を残します。生成側のプロンプトだけを版管理し、評価側を管理画面に閉じ込めると、過去のスコアを再現できません。
5. 隣接領域との違いとツール選定
5.1 既存の実践をつなぐ役割
| 領域 | 主な問い | Eval Engineering との関係 |
|---|---|---|
| ソフトウェアテスト／QA | コードと契約が期待どおり動くか | 決定的検証を再利用し、確率的品質を追加する |
| ML 評価／MLOps | モデルとデータの性能・ドリフトを管理できるか | アプリ、ツール、軌跡、事業成果まで対象を広げる |
| オブザーバビリティ | 本番で何が起き、どこで失敗したか | トレースを評価ケースと改善へ接続する |
| レッドチーミング | 敵対者がどのように安全性を破れるか | 敵対ケースを継続スイートへ組み込む |
| プロンプトエンジニアリング | 指示をどう書けば望ましい出力になるか | 改善案を比較し、回帰なく出荷できるかを判定する |
| プロダクト分析／A/B テスト | 実利用で価値や行動が改善したか | eval 指標と利用者・業務 KPI の乖離を確認する |
Eval Engineering はこれらを置き換える新しい縦割りではなく、成功基準、変更、観測、判定、学習を一つのループへ接続する横断的な実践です。
5.2 ツールより持ち運べる評価資産を優先する
公式ドキュメントで確認できる実装例には、Microsoft Foundry のライフサイクル評価、Google Cloud の rubric ベース評価、LangSmith のオフライン／オンライン評価があります。[^microsoft-observability][^google-eval][^langsmith] 各製品の機能、プレビュー状態、対応リージョン、料金は変化するため、採用時点で再確認してください。
OpenAI のホスト型 Evals プラットフォームは 2026 年 6 月 3 日に廃止が告知され、2026 年 10 月 31 日に既存 eval が読み取り専用、11 月 30 日にダッシュボードと API が停止予定です。[^openai-deprecation] この例が示すように、ツールは入れ替わります。
したがって、選定時は UI の多機能さだけでなく、次を確認します。
- データセット、トレース、行単位スコア、評価理由を出力できるか
- 評価器、ルーブリック、モデル、閾値をコードまたは設定として版管理できるか
- ローカル、CI、定期、本番サンプリングで同じ定義を使えるか
- 再試行、キャッシュ、並列数、費用上限を制御できるか
- PII、権限、保持期間、監査ログを組織要件に合わせられるか
6. 30/60/90 日の導入ロードマップ
次のロードマップは、Anthropic、Google、Microsoft、LangSmith の実践を統合した本記事の導入案です。組織の規模ではなく、評価ループがどこまで閉じているかで進捗を測ります。
| 期間 | 目標 | 実施内容 | 完了条件 |
|---|---|---|---|
| 1〜30 日 | 失敗を再現可能にする | 実トレース 50〜100 件を確認、失敗分類 v0.1、20〜50 タスク、決定的評価器 | 同じ失敗をローカルで再現し、行単位で理由を説明できる |
| 31〜60 日 | 変更を自動判定する | LLM 評価器を必要箇所だけ追加、人間整合、複数試行、Regression を CI 接続 | PR ごとに回帰・重大安全性・費用・遅延の差分を判定できる |
| 61〜90 日 | 本番から学習する | サンプリング評価、失敗キュー、敵対ケース、専任オーナー、変更履歴 | 本番失敗がケース化され、修正前失敗／修正後合格を証明できる |
最初の 30 日で避けるべきなのは、評価ツールを選んだだけで完了とすることです。最初の成果はダッシュボードではなく、チームが合意した失敗分類と、再現できる小さなスイートです。
60 日目には、すべてを LLM-as-a-judge へ寄せないことが重要です。スキーマ、ツール、状態、権限をコードで検証し、自然言語品質だけをモデル評価器へ残します。
90 日目には、本番から評価データへ戻る経路とオーナーを固定します。誰もケースを追加しない評価スイートは、製品の変化から取り残されます。
7. ガバナンスとよくある失敗
NIST AI RMF 1.0 は、AI 製品・サービス・システムの設計、開発、利用、評価へ信頼性の観点を組み込むための任意利用フレームワークです。2026 年 7 月時点で AI RMF 1.0 は改訂中です。[^nist] Eval Engineering の成果物は、リスク管理に必要な測定、文書化、説明責任を実装へ落とし込む材料になります。
ただし、評価基盤を作るだけでガバナンスが成立するわけではありません。次のアンチパターンを避けます。
| アンチパターン | なぜ危険か | 対策 |
|---|---|---|
| 平均スコアだけを最大化する | 重大な少数失敗や特定利用者の劣化を隠す | 重大度、分類、分布、最悪ケースを別にゲートする |
| 1 回の実行でモデルを順位付けする | 確率的なばらつきを改善差と誤認する | 複数 trial と不確実性を報告する |
| 同じ LLM に生成と評価を任せる | 自己選好や共通の弱点を見逃す可能性がある | 別モデルと人間整合セットを使う |
| 正例だけを大量生成する | 拒否、欠損、越権、敵対入力を測れない | 否定・境界・敵対ケースを独立管理する |
| 本番トレースをそのまま評価データにする | 個人情報、秘密、契約上の制約を持ち込む | 最小化、秘匿化、アクセス制御、保持期間を設計する |
| 閾値を理由なく固定する | モデル、利用分布、リスクが変わっても古い判断を続ける | ベースラインと人間判断で較正し、変更理由を記録する |
| 評価スイートを更新しない | 高得点でも新しい失敗や製品範囲を覆わなくなる | 飽和、未分類失敗、カバレッジを定期レビューする |
| eval だけで安全性を証明する | 未知の攻撃や実装脆弱性を網羅できない | 脅威分析、コード監査、権限設計、レッドチームを併用する |
安全性ケースの分類には OWASP Top 10 for LLM Applications 2025 などを参照できますが、チェックリストへ適合しただけで個別システムの安全性が保証されるわけではありません。[^owasp]
8. まとめ
運用側の要点は 4 つです。第一に、LLM-as-a-judge は「正解」ではなく統制して使う測定器として扱います。観点を分離した判定プロンプトを書き、判断不能を許し、人間整合セットで一致率だけでなく誤りの向きと不一致の理由まで見ます。見逃しに偏る評価器は、重大度の高い分類へは使いません。
第二に、オフライン評価とオンライン評価は役割が違うため、どちらか一方では代替できません。オフラインで変更を比較し、オンラインで未知の失敗を見つけ、その失敗を回帰ケースへ戻してループを閉じます。第三に、CI 品質ゲートは総合点 1 本にせず、必須条件・許容差・手動レビューへ分け、実行の重さもトリガーごとに段階化します。第四に、Eval Spec、失敗タクソノミー、データセット、評価器、人間整合セット、品質ゲート、フィードバックキューをチームで分担して保守します。評価資産はツールより長く残るため、持ち運べる形で版管理します。
導入は 20〜50 件の実失敗から始められます。30 日で再現可能な小さなスイート、60 日で CI ゲート、90 日で本番の失敗を回帰ケースへ戻すループを作ることが、評価を一度きりのレポートから継続的な品質資産へ変える最短経路です。
9. 参考情報
- Eval Engineering とは — 生成 AI・AI エージェント評価を設計する（Part 1／全 2 回）
- Anthropic: Demystifying Evals for AI Agents
- Google Cloud: Gen AI evaluation service overview
- Microsoft Foundry: Observability in Generative AI
- LangSmith Evaluation
- NIST AI Risk Management Framework
- OWASP Top 10 for LLM Applications 2025
- Microsoft Foundry の評価機能で想定 QA と実回答の差分を測る方法
- AI エージェント開発のライフサイクル全体像
[^anthropic-evals]: Anthropic, Demystifying Evals for AI Agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（サイトマップ最終更新 2026-03-18、2026-07-31 確認。本文に公開日表示なし）。
[^google-eval]: Google Cloud, Gen AI evaluation service overview: https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview（2026-07-31 確認）。
[^microsoft-observability]: Microsoft Learn, Observability in Generative AI - Microsoft Foundry（ms.date 2026-04-03、更新 2026-06-02）: https://learn.microsoft.com/en-us/azure/foundry/concepts/observability（2026-07-31 確認）。
[^langsmith]: LangChain, LangSmith Evaluation: https://docs.langchain.com/langsmith/evaluation（2026-07-31 確認）。
[^mtbench]: Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（NeurIPS 2023 Datasets and Benchmarks）: https://arxiv.org/abs/2306.05685（2026-07-31 確認）。
[^judging-judges]: Thakur et al., Judging the Judges: Evaluating Alignment and Vulnerabilities in LLMs-as-Judges（GEM² Workshop at ACL 2025）: https://arxiv.org/abs/2406.12624（2026-07-31 確認）。
[^judgebench]: Tan et al., JudgeBench: A Benchmark for Evaluating LLM-based Judges（ICLR 2025）: https://arxiv.org/abs/2410.12784（2026-07-31 確認）。
[^validators]: Shankar et al., Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences（2024-04-18）: https://arxiv.org/abs/2404.12272（2026-07-31 確認）。
[^openai-evals]: OpenAI, Getting Started with OpenAI Evals: https://developers.openai.com/cookbook/examples/evaluation/getting_started_with_openai_evals（2026-07-31 確認）。同ページが案内するホスト型 Evals プラットフォームは廃止予定のため、実装基盤としての推奨ではなく、モデル採点の設計上の注意だけを参照しています。
[^openai-deprecation]: OpenAI, Deprecations - Evals platform（2026-06-03 告知）: https://developers.openai.com/api/docs/deprecations（2026-07-31 確認）。
[^nist]: NIST, AI Risk Management Framework（AI RMF 1.0 は 2023-01-26 公開）: https://www.nist.gov/itl/ai-risk-management-framework（2026-07-31 確認）。
[^owasp]: OWASP Foundation, OWASP Top 10 for LLM Applications 2025: https://genai.owasp.org/llm-top-10/（2026-07-31 確認）。
この記事の執筆にあたり、AI の支援を受けています。
