1. はじめに
この記事を作成する背景は、生成 AI アプリケーションや AI エージェントが「デモでは動くのに、本番で品質を説明できない」という問題を抱えやすいことです。プロンプト、モデル、検索、ツール、データのどれかを変更すると、ある失敗を直した代わりに別の振る舞いが劣化することがあります。出力が自然文で毎回変わるため、数件の目視確認だけでは改善と偶然を区別できません。
本記事の目的は、Eval Engineering の用語上の位置付けを誇張せずに整理し、評価を継続運用できる品質基盤へ変えるための実践方法を示すことです。特定ベンダーの評価製品の操作方法ではなく、評価対象の分解、失敗分類、データセット、評価器という設計側を Part 1 で扱い、LLM-as-a-judge の統制、CI/CD、本番モニタリング、ガバナンスという運用側を Part 2 で扱います。
Microsoft Foundry の具体的な評価機能は、既存の 想定 QA と実回答の差分を測る手順ガイド で解説しています。本記事はその上位概念として、ベンダーに依存しない評価設計に焦点を当てます。
2. Eval Engineering とは何か
2.1 標準用語ではなく、形成途上のラベル
2026 年 7 月 31 日時点で、Eval Engineering（評価エンジニアリング）が ISO、IEEE、NIST などで標準化された用語であることは確認できません。確認できた明示的な用例には、次の 2 つがあります。
- Galileo AI の教育コンテンツは、Eval Engineering を「本番グレードの評価システムを構築し、大規模な AI の振る舞いを統治する規律」と定義しています。同ナレッジベースのトップページでは
emerging disciplineと表現しています。商用評価ベンダーによる定義である点には注意が必要です。[^galileo] - 2026 年 5 月のプレプリント Towards Evaluation Engineering は、評価ハーネスを運用する際のソフトウェア工学上の関心事を
evaluation engineeringと呼んでいます。57 の評価ハーネスを調査し、16,560 件の Issue を分類していますが、査読前であり、タイトルのTowardsが示すとおり確立済み分野の報告ではなく提案です。[^evaleng-paper]
一方、Google Cloud は evaluation-driven development、Anthropic は eval-driven development という表現を使っています。[^google-eval][^anthropic-evals] したがって、「新しい標準職種が確立した」と説明するより、評価駆動の開発を支える実務領域に名前を付けたものと捉えるのが安全です。
2.2 本記事での定義
本記事では、複数の一次情報を横断した独自の整理として、Eval Engineering を次のように定義します。
Eval Engineering とは、確率的に振る舞う生成 AI・AI エージェントの品質と安全性を、再現可能なデータセット、評価器、統計的判定、CI 品質ゲート、本番モニタリング、失敗の還流によって継続的に維持するエンジニアリング実践である。
重要なのは、評価を「リリース前に一度実施する採点」から、次の性質を持つ保守対象のシステムへ変える点です。
| 一度きりの評価 | Eval Engineering としての運用 |
|---|---|
| 数件を人が試す | 代表ケースをデータセットとして版管理する |
| 平均スコアだけを見る | 失敗分類、分布、試行回数、コスト、遅延も見る |
| リリース直前だけ実行する | PR、定期実行、本番サンプリングで継続する |
| 評価器を正しい前提で使う | 評価器自体を人間ラベルで検証・較正する |
| 本番障害をその場で直す | 失敗を回帰データセットへ追加して再発を防ぐ |
| ツールの画面に設定を閉じる | データ、ルーブリック、閾値、結果を持ち運べる形にする |
2.3 最低限そろえる用語
Anthropic はエージェント評価を説明する際に、タスク、試行、評価器、トレース、結果、評価ハーネス、評価スイートを区別しています。[^anthropic-evals] 本記事でも次の意味で使います。
| 用語 | 意味 |
|---|---|
| タスク（task） | 入力と成功条件を持つ 1 件のテストケース |
| 試行（trial） | 同じタスクを 1 回実行したもの |
| 評価器（grader / evaluator） | 出力、軌跡、最終状態などを採点するロジック |
| トレース／軌跡（trace/trajectory） | モデル呼び出し、ツール利用、中間応答を含む実行記録 |
| 結果（outcome） | 「予約が存在する」など、実行後の環境で確認できる最終状態 |
| 評価ハーネス（evaluation harness） | タスク実行、記録、採点、集計を一貫して行う基盤 |
| 評価スイート（evaluation suite） | 共通する能力やリスクを測るタスク群 |
この区別がないと、「最終回答は正しそうだが、禁止されたツールを使った」「成功と返答したが、実際にはデータが更新されていない」といった失敗を見落とします。
3. 従来のテストだけでは足りない理由
3.1 同じ入力でも出力が変わり得る
ホストされた LLM API は、同じ入力とパラメーターでも異なる応答を返し得ます。Azure OpenAI の公式ドキュメントも、seed と system_fingerprint が同じ場合でも決定性は保証されず、応答のばらつきが観測されることは珍しくないと明記しています。[^nondeterminism]
この性質により、自然文全体を固定文字列と比較するだけのテストは、次の両方を起こします。
- 偽陰性: 内容は正しい言い換えなのに、文字列が異なるため失敗する
- 偽陽性: 指定語句は含むが、事実関係、根拠、ツール実行、最終状態が誤っている
ただし「生成 AI は非決定的だからテストできない」という結論も誤りです。JSON 構文、禁止語、計算結果、SQL 実行結果、ツール引数、権限境界など、決定的に検証できる部分は従来どおり厳密に検証します。
3.2 eval はソフトウェアテストを置き換えない
Google ADK は、従来のユニットテストや結合テストがコードの安定性に必要である一方、LLM エージェントでは最終出力と軌跡の定性的評価が追加で必要だと説明しています。[^adk-eval]
| 対象 | 第一選択となる検証 | eval で補うもの |
|---|---|---|
| 通常コード | ユニットテスト、型検査、静的解析 | 原則として不要 |
| API・データ更新 | 結合テスト、契約テスト、状態検証 | ツール選択や説明品質 |
| RAG | 検索 Recall、ACL、引用 URL の機械検証 | 根拠性、回答の完全性、回答不能判断 |
| 会話エージェント | スキーマ、必須／禁止ツール、最終状態 | 対話品質、意図解決、方針遵守 |
| 自由記述 | 長さ、形式、必須要素などのコード検証 | 正確性、明瞭さ、トーン、洞察 |
| セキュリティ | 認証認可、入力検証、侵入テスト | プロンプトインジェクション等の敵対的シナリオ |
厳密に判定できるものを LLM に採点させないことが、精度、再現性、コストのすべてで有利です。
3.3 エージェントは最終回答だけでなく軌跡と結果を測る
Google ADK はエージェント評価を「軌跡とツール利用」と「最終応答」の 2 要素に分けています。[^adk-eval] さらに Anthropic は、トレースと環境の最終状態を分けています。[^anthropic-evals]
たとえば経費精算エージェントが「申請しました」と答えても、次の検証が必要です。
- 正しい申請 API を選んだか
- 金額、通貨、部門コードを正しく渡したか
- 承認が必要な金額で勝手に確定しなかったか
- データベースに申請が 1 件だけ作成されたか
- ユーザーへの説明が実際の状態と一致するか
この分解により、プロンプト、ツール定義、認可、バックエンド、最終文面のどこで失敗したかを切り分けられます。
4. 評価対象を 4 レイヤに分ける
「AI の品質」という一つの平均値では、改善場所が分かりません。本記事では評価対象を次の 4 レイヤに分けます。これは Google ADK、Anthropic、Microsoft Foundry の評価対象をベンダー中立に並べ直した本記事独自の整理です。[^adk-eval][^anthropic-evals][^microsoft-observability]
| レイヤ | 評価対象 | 代表的な問い | 例となる指標・検証 |
|---|---|---|---|
| L1 | モデル | このタスクに必要な能力、品質、安全性があるか | 正答率、拒否品質、レイテンシ、token、費用 |
| L2 | コンポーネント | 検索、ルーター、ツール呼び出しが正しく働くか | Recall@K、引数一致、スキーマ、権限、再試行 |
| L3 | E2E ワークフロー／エージェント軌跡 | 最終結果へ安全かつ効率的な経路で到達したか | タスク完了、軌跡、最終状態、ターン数 |
| L4 | プロダクト／事業成果 | ユーザーや業務に価値を生み、許容リスク内で運用できるか | 解決率、再問い合わせ率、処理時間、事故率 |
たとえば RAG の最終回答が低品質でも、原因は L1 のモデル能力ではなく、L2 の検索失敗かもしれません。コンポーネント評価を飛ばしてモデルやプロンプトだけを変更すると、原因を直さないまま結果が偶然改善する状態になります。
L4 は eval スコアだけでは完結しません。オフラインで高得点でも、利用者がタスクを完了できない、処理時間が伸びる、問い合わせが増えるならプロダクトとしては改善していません。十分なトラフィックがある段階では、A/B テストや業務 KPI と接続して確認します。Anthropic も自動 eval、本番モニタリング、A/B テストを補完関係として位置付けています。[^anthropic-evals]
5. Eval Engineering のライフサイクル
Eval Engineering は「データセットを作って採点する」工程ではなく、開発と運用をつなぐ閉ループです。
図の要点は、本番の失敗が評価データセットへ戻り、次の変更を CI で検証することです。Microsoft Foundry はモデル選定、本番前評価、本番後モニタリングを一つのライフサイクルとして説明し、本番トラフィックのサンプリング評価も示しています。[^microsoft-observability] LangSmith の公式ドキュメントも、失敗した本番トレースをデータセットへ追加し、オフライン評価で修正を検証して再デプロイする流れを示しています。[^langsmith]
| フェーズ | 実施内容 | 主な成果物 |
|---|---|---|
| 1 | 利用目的、失敗時の影響、成功基準を定義する | Eval Spec、KPI、禁止事項 |
| 2 | 実トレースと障害を読み、失敗を分類する | 失敗タクソノミー |
| 3 | 通常、境界、否定、敵対ケースをデータセット化する | 評価データセット |
| 4 | 決定的評価器を優先し、必要箇所だけモデル・人間評価を加える | 評価器、ルーブリック、人間ラベル |
| 5 | 同一条件で複数回実行し、基準値とばらつきを記録する | ベースライン、実験レポート |
| 6 | 回帰、安全性、費用、遅延の閾値で変更を判定する | CI 品質ゲート |
| 7 | 本番をサンプリングし、品質低下や未知の失敗を検知する | ダッシュボード、フィードバックキュー |
| 8 | 失敗を再現可能なケースに変え、スイートを更新する | 回帰ケース、変更履歴、監査記録 |
各フェーズの設定には、モデル、プロンプト、ツール、データセット、評価器、閾値のバージョンを残します。スコアだけを保存しても、後から同じ条件を再現できなければ比較できません。フェーズ 5 以降の実装は Part 2 で扱います。
6. 失敗タクソノミーを先に作る
6.1 「何を測るか」を主観から抜け出させる
評価の議論が止まる典型的な原因は、いきなり指標名から入ることです。「根拠性を測ろう」「有用性をスコア化しよう」と始めると、何点なら合格かも、その指標がどの障害を防ぐのかも決まりません。
ライフサイクルのフェーズ 2 に失敗分類を置いたのはこのためです。先に「このシステムはどう壊れるか」を列挙し、その分類に対して指標と評価器を割り当てると、議論の対象が「好み」から「実際に起きた事象」へ移ります。Anthropic もエージェント評価の出発点として、バグトラッカーやサポートキューを挙げています。[^anthropic-evals]
6.2 実トレースからボトムアップで作る
失敗タクソノミーは、一般的な分類表を持ってくるのではなく、自分たちのトレースから作ります。次は本記事が示す進め方の例です。
- 直近の実トレースを 50〜100 件、機能や利用者が偏らないように抽出する
- 2 人以上で独立に読み、「望ましくない」と判断した箇所へ短い自由記述のラベルを付ける
- ラベルを突き合わせ、意味が重なるものをまとめて分類名を付ける
- 各分類に重大度（軽微・要修正・重大）と、検知手段（コード／モデル／人間）を割り当てる
- 1 件も実例がない分類は、想定リスクとして別枠に置き、実データが出るまで数えない
3 で分類が 30 も 40 も出るなら、粒度が細かすぎます。最初は 8〜15 個程度にまとめ、運用しながら分割するほうが扱いやすくなります。
6.3 分類には検知手段まで書く
分類名だけの一覧は、そのままでは評価器へ落ちません。次は説明用の例として、生成 AI 業務アシスタントを想定した記述例です。
| 分類 ID | 失敗の説明 | 重大度 | 主な検知手段 |
|---|---|---|---|
| F-01 | 検索結果にない事実を断定する | 重大 | モデル評価器（根拠性）＋ 引用 URL の照合 |
| F-02 | 質問の一部にしか答えない | 要修正 | モデル評価器（完全性） |
| F-03 | 権限のないドキュメントを引用する | 重大 | コード（ACL 照合） |
| F-04 | 承認が必要な操作を確認なしで実行する | 重大 | コード（ツール呼び出しと引数の検証） |
| F-05 | 答えられない質問に無理に回答する | 要修正 | 否定ケースの期待結果と比較 |
| F-06 | 指定した出力形式（JSON・見出し）を守らない | 軽微 | コード（スキーマ検証） |
| F-07 | 同じ質問で結果が大きくぶれる | 要修正 | 複数試行の分散 |
| F-08 | 注入された指示に従い方針を逸脱する | 重大 | 敵対ケース＋禁止ツールの検証 |
この表があると、次の 3 つが自動的に決まります。第一に、データセットへどの分類を何件入れるべきか。第二に、その分類をコードで測れるのかモデルへ委ねるのか。第三に、品質ゲートでどれを絶対条件にするのか。重大度が「重大」の行は、平均スコアに混ぜず単独で判定します。
7. 評価データセットを設計する
7.1 実際の失敗から 20〜50 タスクで始める
Anthropic は、初期のエージェント評価は 20〜50 タスクから始められ、バグトラッカーやサポートキューを良い出発点として挙げています。[^anthropic-evals] 網羅的な架空ケースを大量生成する前に、次の順で集めます。
- 本番または検証環境で実際に失敗したケース
- 頻度が高い主要タスク
- 誤ると損失が大きいタスク
- 曖昧、長文、欠損、矛盾を含む境界ケース
- 実行してはいけない操作を含む否定ケース
- プロンプトインジェクションなどの敵対ケース
各ケースには、入力と期待回答だけでなく、なぜ重要か、どの失敗分類を覆うか、期待するツール利用、禁止操作、最終状態を含めます。
7.2 capability と regression を分ける
Anthropic は評価スイートを次の 2 種類に分けています。[^anthropic-evals]
| スイート | 問い | 合格率の考え方 |
|---|---|---|
| Capability / Quality | 現在どこまで難しい課題を解けるか | 低い合格率から始め、改善余地を測る |
| Regression | 以前できたことを今も安定してできるか | ほぼ 100% を目指し、リリースを止める保護網にする |
実務では、これに adversarial / safety と production sample を加えると管理しやすくなります。高い合格率へ到達した capability ケースは regression へ移し、新しい難問を capability へ追加します。全ケースが簡単になって飽和したスイートは、改善能力を測れません。
7.3 代表性、リーク、版管理を設計する
評価データは、製品が実際に受ける言語、長さ、利用者属性、ツール、エラー条件の分布を反映させます。平均的なケースだけでなく、低頻度でも影響が大きいケースを別枠で持ちます。
また、プロンプトや few-shot 例へ評価ケースをそのまま入れると、実力ではなく暗記を測ることになります。開発用、調整用、最終確認用を分離し、生成した合成データだけで結論を出さないようにします。
7.4 ケースは構造化して保存する
ケースを自然文のスプレッドシートで持つと、評価器がパースできず、再現もできません。次は説明用の例として、1 件のケースに持たせるフィールドを示したものです。
case_id: EVAL-0142
taxonomy_id: F-03 # 6.3 の失敗分類と対応させる
suite: regression # capability | regression | adversarial | production
source: incident # incident | support | expert | synthetic
created_at: 2026-07-18
rationale: 部門外の人事資料を引用した本番障害の最小再現
input:
user: 来期の営業部の評価制度を教えて
actor_role: sales_member
expected:
must_contain_citation_from: [sales-handbook]
must_not_cite_scope: [hr-confidential]
allow_refusal: true # 権限外なら回答不能が正解
forbidden_tools: [hr_document_search]
final_state:
audit_log_entries: 1
grading:
- type: code # ACL 照合は決定的に検証する
name: citation_acl_check
- type: model # 説明の妥当性だけモデルへ委ねる
rubric: refusal_quality_v3
locale: ja-JP
risk: high
pii: none
version: 3
このように taxonomy_id で失敗分類へ、grading で評価器へ、suite で品質ゲートへ、それぞれ機械的に接続できる形にしておくと、後からケースを増やしても運用が破綻しません。version を持たせるのは、期待結果を変えたときに過去のスコアと比較してよいかを判断するためです。
8. 評価器を設計する
8.1 客観的な評価器から積み上げる
Anthropic はコード、モデル、人間の評価器を組み合わせる方法を示し、同社のテスト設計ガイドは exact match、コード、LLM、人間という段階的な選択を示しています。[^anthropic-evals][^anthropic-tests]
| 評価器 | 向く対象 | 強み | 主な弱点 |
|---|---|---|---|
| 文字列・数値・スキーマ | 分類、JSON、ID、計算結果 | 高速、安価、再現可能 | 言い換えに弱い |
| コード・環境状態 | SQL、API、副作用、ツール引数、権限 | 実際の成功を直接検証できる | テスト環境の構築が必要 |
| モデルベース | 正確性、根拠性、トーン、説明品質 | 自由記述を大量に採点できる | バイアス、誤判定、費用 |
| 人間・専門家 | 高リスク判断、曖昧さ、価値判断 | 文脈と責任を持って判断できる | 遅い、高価、評価者間でずれる |
| 安全性・レッドチーム | 攻撃、越権、情報漏えい、有害出力 | 通常ケース外のリスクを探索 | 網羅性を証明できない |
順序は「安いものから」だけでなく、最も直接的に成功を観測できるものから決めます。予約エージェントなら、完了メッセージの自然さより、予約レコードが正しく存在することを先に検証します。
8.2 ルーブリックは測りたい概念を一つずつ書く
Anthropic の公式ガイドは、成功基準を具体的、測定可能、達成可能、関連性のある形にし、実タスク分布とエッジケースを反映するよう推奨しています。[^anthropic-tests]
悪いルーブリックは「回答が良いこと」のように、複数の観点を一文へ詰め込みます。代わりに、次のように分離します。
- 主張が与えられた根拠で支持される
- 質問の主要な要求をすべて満たす
- 根拠がない事項を断定しない
- 禁止されたツールを呼び出さない
- 指定された形式と長さを守る
モデル評価器には、合格・不合格の境界、反例、判断不能時の扱いを明記します。評価理由も保存し、誤判定を直す材料にします。
8.3 1 回の成功ではなく再現性を測る
Anthropic は、モデル出力が試行ごとに変わるため複数 trial を実行し、pass@k と pass^k を使い分ける方法を説明しています。[^anthropic-evals]
- pass@k: k 回のうち少なくとも 1 回成功できるか。探索型・補助型の能力を見る
- pass^k: k 回すべて成功できるか。毎回の信頼性が重要な業務を見る
コード生成支援のように再試行できる用途と、送金や外部公開のように 1 回の失敗が重大な用途では、同じ指標を使うべきではありません。各レポートには試行回数、平均だけでなく分布や信頼区間を記録します。
9. まとめ
Eval Engineering は、現時点で確立した標準用語というより、生成 AI・AI エージェントの評価を継続運用する実務領域を表す形成途上のラベルです。本記事では、評価をデータセット、評価器、統計、CI 品質ゲート、本番フィードバックとして維持するエンジニアリング実践と定義しました。
設計側の要点は 4 つです。第一に、決定的に検証できるものはコードで測り、自然言語や軌跡だけをモデル・人間評価で補うこと。第二に、モデル、コンポーネント、E2E／軌跡、プロダクト成果の 4 レイヤへ分けて、改善場所を切り分けられるようにすること。第三に、指標名より先に失敗タクソノミーを作り、各分類に重大度と検知手段を割り当てること。第四に、ケースを構造化して保存し、失敗分類・評価器・品質ゲートへ機械的に接続できる形にすることです。
評価器は最も直接的に成功を観測できるものから積み上げ、必要な範囲だけモデル評価器と人間評価へ上げます。ここまでで「何をどう測るか」は決まりました。Part 2 では、モデル評価器をどう統制するか、その判定を CI 品質ゲートと本番モニタリングへどう接続するか、そして 30/60/90 日でどこまで進めるかを扱います。
10. 参考情報
- Eval Engineering とは — 評価を運用する（Part 2／全 2 回）
- Anthropic: Demystifying Evals for AI Agents
- Anthropic: Define success criteria and build evaluations
- Google ADK: Why evaluate agents
- Google Cloud: Gen AI evaluation service overview
- Microsoft Foundry: Observability in Generative AI
- LangSmith Evaluation
- Microsoft Foundry の評価機能で想定 QA と実回答の差分を測る方法
- AI エージェント開発のライフサイクル全体像
[^galileo]: Pratik Bhavsar / Galileo AI, What is Eval Engineering?（2026-03-06）: https://evalengineering.galileo.ai/eval-engineering-book/what-is-eval-engineering、同ナレッジベースのトップページ: https://evalengineering.galileo.ai/eval-engineering-book（いずれも 2026-07-31 確認）。商用ベンダーの教育コンテンツです。
[^evaleng-paper]: Zhao et al., Towards Evaluation Engineering: An Empirical Study of ML Evaluation Harnesses in the Wild（arXiv:2605.24213、2026-05-22、査読前プレプリント）: https://arxiv.org/abs/2605.24213（2026-07-31 確認）。
[^anthropic-evals]: Anthropic, Demystifying Evals for AI Agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（サイトマップ最終更新 2026-03-18、2026-07-31 確認。本文に公開日表示なし）。
[^anthropic-tests]: Anthropic, Define success criteria and build evaluations: https://platform.claude.com/docs/en/test-and-evaluate/develop-tests（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 確認）。
[^adk-eval]: Google, Why evaluate agents - Agent Development Kit: https://adk.dev/evaluate/（2026-07-31 確認）。
[^nondeterminism]: Microsoft Learn, How to generate reproducible output with Azure OpenAI in Microsoft Foundry Models (classic)（ms.date 2025-11-26、更新 2026-06-05）: https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/reproducible-output（2026-07-31 確認）。記載内容は Foundry classic portal が対象です。
[^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 確認）。
この記事の執筆にあたり、AI の支援を受けています。
