Evalsとは、AIおよびLLMの出力品質を測定するための体系的な手法です。 テスト自動化と同じ目的——システムが正しく動作しているという確信を与える——を持ちますが、根本的に異なります。

従来のテストは確実性を与えます。Evalsは確信を与えます。 ユニットテストは二値です：関数が4を返すかどうか、100%の精度で検証できます。AIの出力は非決定論的であり、同じプロンプトでも毎回異なる応答が生成され、「正解」は二値ではなくスペクトラムです。単一のEvalでシステムが完璧に動作していると判断することはできません。代わりに、複数の次元にわたる複数のEvalsが組み合わさって、システムの品質に対する確信のレベルを構築します——測定可能で追跡可能であり、情報に基づいた意思決定には十分ですが、決して100%ではありません。

これはリーダーやステークホルダーが理解しておくべき重要な区別です。Evalsが従来のテストと同じ合否の確実性を提供することを期待すると、誤った期待を設定し、偽の確信か不必要な失望をもたらします。Evalsは「システムがテストシナリオ全体で役立つ・正確な応答を生成することを85%の確信がある」と示します——そしてその確信のレベルを時間とともに追跡することが、リリースするか・ロールバックするか・品質にさらに投資するかを決める判断の材料になります。

適切な確信の閾値はユースケースによって異なります。 AIシステムが以前は不可能だったか非常にコストのかかったことをしている場合、わずかな確信であっても現状から大幅な改善かもしれません。しかし人間がすでにそのタスクをうまくこなしている場合、ハードルははるかに高く——そこに達するには、アンドレイ・カルパシーが「9の行進」と呼ぶパターンに従います：信頼性の9を一桁増やす（90%から99%、99.9%へ）のに、これまでの全ての9を合わせたほどの努力が必要です。あらゆるAIシステムがほぼ完璧でなければ価値がないという前提ではなく、ユースケースが実際に必要とするものと以前に存在したものに基づいて目標確信レベルを設定しましょう。

Evalの範囲：コンポーネント・セグメント・エンドツーエンド

AIシステムは多くのパーツで構成されており、異なる範囲でEvalを実施できます：

• コンポーネントEvalはシステムの個々の部分を単独で測定します。モデル自体（推論・事実性・指示追従）、検索パイプライン（取得ドキュメントの関連性・再現率）、プロンプトテンプレート、後処理ロジックなど。Evalの範囲を絞るほど、何が機能していて何を改善すべきかを特定しやすくなります。
• セグメントEvalは複数のコンポーネントが連携して動作する部分を測定します。例えば、検索+プロンプト+モデルをグループとして評価し、適切なコンテキストが取得・活用されているかを確認します。コンポーネントEvalでは見逃す統合の問題を検出します。
• エンドツーエンドEvalはユーザーが体験する完全なシステムを測定します——入力から最終出力までの完全なパイプラインです。最もリアルですが、何か問題が生じた際のデバッグが最も難しく、原因がどのコンポーネントにあるかわからないためです。
• 狭い範囲から始めて広げていきましょう。個々のコンポーネントの改善が属するセグメントを改善し、エンドツーエンドの結果を改善します。エンドツーエンドのEvalで回帰が見つかった場合、範囲を絞ったEvalが問題の正確な場所を見つけるのに役立ちます。

すべてのEvalsがあいまいなわけではない

Evalの議論の多くは主観的な品質判断に焦点を当てていますが、一部のEvalsは完全に決定論的です。必須フィールドが出力に存在するか、応答が有効なJSONか、サマリーがトークン制限内か、禁止コンテンツが現れていないかを確認するのは、従来のテストと同様の単純な二値チェックです。合格か不合格かです。

これらの決定論的Evalsはevalピラミッドの基盤を形成します（ステップ3参照）。高速・低コスト・信頼性が高いです。その上の層——モデルグレードのEvalsとヒューマンEvals——は、コードだけでは判断できない、応答が役立つか・正確か・トーンが適切かなどの判断を担います。良いEval戦略は決定論的なチェックから始まり、必要な場合にのみより高コストで不確実性の高いEvalタイプを重ねます。

オフラインEvalsとオンラインEvals

• オフラインEvalsはデプロイ前に静的データセットに対して実行されます。入力が固定されているため結果は再現可能であり、変更を並べて比較できます。反復が速く変数を完全にコントロールでき、日々の開発の主要ツールとなります。実際のユーザー行動や本番データの分布を反映しない場合がありますが、何もユーザーに届く前に回帰を検出します。
• オンラインEvalsはライブの本番トラフィックや実際のユーザーとのインタラクションに対して実行されます。ドリフト——静的データセットがユーザーの実際の使用方法を反映しなくなったためにオフラインEvalsが見逃す品質の徐々の劣化——を検出します。実際の条件（実際のクエリ・エッジケース・使用パターン）を捉えますが、フィードバックが遅く変数を切り離すのが難しいです。
• チームは両方が必要です。オフラインEvalsはデプロイをゲートし、オンラインEvalsは本番を監視します。

Evalsとスプリットテスト（A/Bテスト）

EvalsとA/Bテストは異なる質問に答えます。Evalsはルーブリックや基準に対して品質を測定します——ユーザーゼロで実行できます。A/Bテストはユーザー行動をスケールで測定することによって2つのバリアントを比較します——統計的有意性に達するためにかなりのトラフィックが必要です。

実際には、ユーザー数によって選択が決まることが多いです：トラフィックの少ないAI機能では意味のあるA/Bテストに十分な量が得られないため、EvalsがプライマリQ/Aシグナルになります。トラフィックの多い機能は両方を使うべきです。Evalsはまた、変更をユーザーに公開した後ではなく前に特定の基準に対して品質を証明する必要がある、高リスクまたは規制対象のユースケースにも不可欠です。

• 非決定論的な出力は新しい品質パラダイムを必要とします。 従来のテストは「動作している」か「壊れている」かを確実に伝えます。Evalsだけではそれはできません——そしてそうすることを意図していません。代わりに、複数の次元にわたるEvalsが組み合わさって、システムが品質のある出力を生成しているという確信の程度を与えます。その確信が意思決定を促します：出荷できる確信・スケールできる確信、またはまだ確信が足りず品質がどこで不足しているかが具体的にわかる。とはいえ、テストとEvalsは相互に排他的ではありません。AIがコードを生成したりエージェントシステムが決定論的な成果物を生成したりする場合、従来のテストは依然としてそれらの出力に適用されます。最良の戦略は両方を組み合わせます：決定論的なものにはテスト、そうでないものにはEvals。どちらもなければ、システムのパフォーマンスを知る信頼できる方法がありません。 * 変更による回帰の検出。 プロンプトの調整・モデルのアップグレード・検索パイプラインの変更・システムプロンプトの修正はいずれも出力品質を微妙に変える可能性があります。Evalsはユーザーよりも前に回帰を検出します。
• プロンプトエンジニアリングをヴァイブスではなくエンジニアリングに変える。 Evalsなしでは、プロンプトの変更は感覚頼りです。Evalsがあれば、変更が全ユースケースの範囲で実際に出力を改善したかどうかを示すデータがあります。
• 信頼とステークホルダーの確信。 数値化された確信レベルとその時間的トレンドをステークホルダーに示すことは、「うまく機能しているようだ」という逸話よりはるかに大きな信頼を構築します。Evalsは確実性ではなく確信を提供することを率直に伝えましょう。「先月の78%から今月は200件のテストケースで92%の確信」を見ているステークホルダーは、システムが保証されていると誤解しているステークホルダーよりも良い意思決定をするでしょう。
• 安全性と有害コンテンツの防止。 Evalsは有害・偏向・不適切な出力が発生しないことを祈るのではなく、体系的にテストできます。
• 規制とガバナンスの準備。 NIST AI RMF（MEASURE機能）やEU AI法などのフレームワークは、AIシステムが監視・測定されているという実証可能な証拠を要求します。Evalsがその証拠を提供します。
• コスト最適化（とコスト意識）。 同じEvalスイートをあなたの特定のタスクで異なるモデルに対して実行することで、どのモデルが最良のコストパフォーマンスを提供するかについてデータ駆動の意思決定が可能になります。ただし、Evals自体がコスト高になりうることに注意しましょう。モデルグレードのEvals（LLM-as-judge）は、最初のモデルの出力をレビューするために2番目のより高性能なLLMを使用し、そのレビューがアプリケーション自体の実行よりも高コストになる場合があります。これがまさにEvalピラミッド（ステップ3参照）が重要な理由です：機械的な問題をほぼゼロコストで検出するコードベースの安価で決定論的なチェックから始め、実際にそれが必要な判断にのみコストのかかるモデルグレードやヒューマンEvalsを予約しましょう。

ステップ1：「良い」とはどういうことかを定義する

3〜5の評価基準を持つルーブリックを作成するためにドメインエキスパートと協力しましょう。 各基準について、良い・許容できる・劣った出力の例を文書化します。 このルーブリックは他の全てが構築される土台です——なければ、Evalsは一貫性のない再現不可能な結果を生み出します。

ステップ2：代表的なデータセットを構築する

一般的なシナリオ・エッジケース・敵対的入力・過去の失敗をカバーする20〜50件のテストケースから始めましょう。 合成データ——モデル生成の例やニーズに合わせて変更された実際のデータ——から始めることは完全に合理的です。開始するために本番トラフィックは必要ありません。本番データとヒューマン・イン・ザ・ループレビューから時間をかけてデータセットを拡大しましょう。小さくてもキュレーションされたデータセットは、大きくても粗雑なものより価値があります。

ステップ3：Evalピラミッドでプライオリティを付ける

Evalのコストは急速に膨らむ可能性があるため（上記「コスト最適化」参照）、 Evalスイートを構築する順序が重要です。テストピラミッドと同様に、基盤では高ボリューム・低コストのEvalsから始め、上に向かって積み上げます。基盤層は決定論的でほぼ無料です。上の各層はニュアンスを追加しますがコストも増加します。ピラミッドにより、単純なフォーマットチェックで無料で検出できる問題に対してLLM-as-judgeの価格を払わずに済みます：

• 基盤 - 自動化/コードベースのEvals： フォーマットチェック・スキーマバリデーション・長さ制約・禁止コンテンツフィルター。高速・安価・決定論的。全ての変更で実行します。
• 中間 - モデルグレードのEvals（LLM-as-judge）： 言語モデルを使ってルーブリックに対して出力をスコアリングします。ジャッジモデルは評価されるモデルよりも高性能であるべきです——ジュニア開発者にシニアの仕事をレビューさせることはしないでしょう。コードチェックよりも微妙ですが遅くてコストが高い。一貫性・関連性・完全性を評価するのに有用。
• トップ - ヒューマンEvals： ドメインエキスパートがサンプルされた出力をレビューします。品質評価のゴールドスタンダードですが、高コストで時間がかかります。自動化されたモデルグレードEvalsを校正・検証するためにヒューマンEvalsを使用します。
• 別トラック - 敵対的Evals（レッドチーミング）： 安全性が重要なアプリケーションでは、ジェイルブレイク・有害な出力・ポリシー違反を体系的にテストします。
• 基盤から始め、上に向けて拡大します。機械的なチェックを自動化する前に高コストなヒューマンEvalsに飛びつかないようにしましょう。

ステップ4：Evalsを開発ワークフローに統合する

高速フィードバックのためにプロンプトエンジニアリング中にローカルでEvalsを実行します。 継続的インテグレーションパイプラインにEvalsを追加し、 プロンプト・モデル・検索の変更が全ての変更で自動的に評価されるようにします。 品質の閾値を定義し、テストの失敗と同様に扱います——問題が修正されるまでビルドはレッドです。これはテスト駆動開発の原則をAIシステムに適用したものです。Eval駆動開発というコンパニオンプラクティスが、TDDのred-green-refactorサイクルをEvalsに直接適用します。

ステップ5：オンラインEvalsで本番を継続的に監視する

ドリフトと回帰をリアルタイムで検出するため、サンプリングされたライブトラフィックでEvalsを実行します。オフラインEvalsはデプロイ前に検証し、オンラインEvalsは実際の環境で動作していることを確認します。オンラインEvalのスコアがオフラインスコアから乖離した場合、Evalデータセットが実際の使用方法を反映しなくなったシグナルです。

ステップ6：ユーザーフィードバックでループを閉じる

新しいEvalケースのソースとして明示的・暗示的なユーザーフィードバックを活用しましょう。 明示的なフィードバックにはサムアップ/ダウン・修正・エスカレーション・クレームが含まれます。暗示的なフィードバックには、ユーザーが質問を言い換える・フローを途中で離脱する・回答をコピーするかを無視するか・ヒューマンにエスカレートするなどの行動シグナルが含まれます。パターンを見つけるためにフィードバックをバケット化しましょう： 個々のクレームはノイズですが、類似のフィードバックのクラスターが評価する価値のある真のパターンを明らかにします。パターンを特定したら、新しいEvalテストケースとして体系化しましょう。これはジェネレーティブAIに適用されたMLOpsライフサイクルです：ユーザーが問題を表面化し、パターンが出現し、新しいEvalsが回帰を検出し、品質が向上します。

ステップ7：レビュー・報告・反復する

Evalのスコアを時点のスナップショットではなく時間的トレンドとして追跡しましょう。 可視性と信頼を維持するためにステークホルダーと結果を共有します。Evalスイートを生きたアーティファクトとして扱い——本番データやユーザーフィードバックから新しいケースを定期的にリフレッシュして陳腐化を防ぎます。

避けるべきアンチパターン

• Evalウォッシング： Evalsを実行しても結果を無視する。スコアが意思決定に影響しなければ、Evalsは演技に過ぎません。
• 単一のEvalタイプへの過度の依存： ピラミッドを使いましょう。コードチェックだけではニュアンスを見逃します。ヒューマンEvalsだけではスケールしません。
• テストの丸暗記： 狭いEvalデータセットに過度に最適化し、スコアは良く見えるが実世界の品質は改善していない状態。データセットを定期的にリフレッシュしましょう。
• ルーブリックなしでの評価： 異なるレビュアーやジャッジモデルが同じ出力を異なるスコアで評価するという一貫性のない再現不可能な結果を招きます。
• LLMジャッジの校正を無視する： モデルグレードのEvalsには既知のバイアスがあります——多弁バイアス・位置バイアス・自己優先バイアス。出力を生成するモデルよりも高性能なモデルを常にジャッジとして使用し、ジャッジモデルを人間の評価に対して校正しましょう。
• 古くなったEvalデータセット： プロダクトが進化するにつれてEvalデータセットを更新しないと、新しい障害モードが検出されない盲点が生じます。
• 100%の精度を期待する： EvalsはテストではありませんEvalや複数のEvalsの組み合わせでシステムが完璧だと判断することはできません。合否の確実性を期待するリーダーは、高スコアを過信するか、保証を提供できないとしてプラクティス全体を無視するでしょう。早い段階で期待値を設定しましょう：Evalsは確信を測定し、その確信が意思決定に使われます。
• フィードバックループをスキップする： ユーザーフィードバックと本番障害を新しいEvalケースに変換しないことは、Evalスイートが徐々に関連性を失うことを意味します。