第3章 評価の設計

学習目標

• 実際の利用分布を代表し、エッジケースやまれな高リスク事例を個別に扱う評価セットを構成します。
• コードによる採点、LLM採点、人間による採点の長所と短所を比較し、基準ごとに適した採点方式を選択します。
• LLM採点器を人間による採点と照合して補正し、スコアの上昇が実際の改善であるかを見極めます。
• 能力評価と回帰評価、オフライン評価とオンライン指標の役割を区別して共に設計します。
• 評価結果をタイプ別に読み解き、リリース、条件付きリリース、保留のいずれかを根拠とともに決定します。

はじめに

あるチームが問い合わせ対応ボットの新しいプロンプトをデプロイする際、このように言いました。「10個の例を試してみましたが、明らかに良くなりました」。1週間後、海外注文の問い合わせでのみ配送料を誤って案内する問題が発見されました。その10個の例には海外注文が1件も含まれていませんでした。OpenAIはこのような手法を「感覚に頼った評価（vibe-based evals）」と呼び、代表的な失敗パターンに挙げています。

評価は、AI機能の品質を数値で確認する唯一の方法であり、その数値がリリースの判断基準になります。そのため、評価の設計は開発者だけの仕事ではありません。何をもって成功とするか（第2章）を定めた企画者が、その成功をどのようなデータと採点で確認するのかまで責任を持つ必要があります。OpenAIは、評価を早期かつ頻繁に行う評価駆動開発を推奨しており、評価は終わりがあるタスクではなく継続的なプロセスであると述べています。

本章では、評価セットの構築方法から始め、3つの採点方式とその選択順序、LLM採点器を信頼できるようにする方法を見ていきます。続いて、能力評価と回帰評価、オフライン評価とオンライン指標を区別し、最後に評価結果を読み解いてリリースの可否を判断する方法を扱います。

重要な概念

評価とは何か

評価（eval）とは、モデルや機能の性能を測定する構造化されたテストです。OpenAIによる定義も同様です。評価は3つの要素で構成されます。試験問題に該当する評価セット、採点を行う採点方式、そして合格ラインに該当する成功基準です。

たとえるなら、評価は運転免許試験のようなものです。試験コース（評価セット）が実際の道路と似ていなければならず、採点官（採点方式）に一貫性があり、合格ライン（成功基準）があらかじめ定められていなければなりません。試験コースが駐車場だけであれば、合格しても実際の道路で事故を起こしてしまいます。採点官が気分によって点数を付ければ、同じ実力であっても評価が分かれてしまいます。

評価プロセスの5つのステップ

OpenAIは、評価プロセスを5つのステップで説明しています。

1. 評価目標の定義。 何を確認しようとしているのか。第2章の成功基準から導かれます。
2. データの収集。 その目標を確認するためにどのようなデータが必要か。
3. 指標の定義。 成功基準が満たされたかをどのように確認するか。
4. 実行と比較。 評価を実行し、バージョン間を比較します。
5. 継続的評価。 変更があるたびに評価を再実行します。

前のステップの結果が、次のステップの入力となります。目標なしにデータを集めれば何を集めるべきかわからず、データなしに指標を定めれば何に適用すべきかわかりません。最後のステップが抜けてしまうと、評価はリリース前の単なる一過性のイベントで終わり、その後の変更は再び感覚で判断することになってしまいます。

評価セットの代表性

Claudeのドキュメントにおける第1の評価設計原則は「タスクに合わせる」です。評価が実際の作業の分布を反映していなければならないという意味です。OpenAIも本番運用のトラフィックのパターンを忠実に再現できていない評価セットを、「偏った設計」という失敗パターンとして挙げています。

代表性を確認する最も簡単な方法は比較表です。

このような表で大きな差異が見られる場合、評価スコアは実際の性能を物語っているとは言えません。チームメンバーが頭の中で考えた質問は標準語の整った文が多くなりがちですが、実際のユーザーは略語や誤字、混ざった言語で質問してきます。評価セットのベースは、実際のリクエストから無作為に抽出したサンプルである必要があります。

エッジケースとまれな高リスク事例

代表サンプルだけでは不十分です。Claudeのドキュメントは、評価にエッジケースを必ず含めるよう求めており、4つの例を挙げています。無関係または存在しない入力、極端に長い入力、チャットであれば不十分・有害・無関係なユーザー入力、そして人間の間でも判断が分かれる曖昧な事例です。OpenAIも評価データに典型的な事例、エッジケース、敵対的な事例を共に含めることを推奨しています。

曖昧な事例は「採点が一貫しない」という理由で除外したくなる誘惑にかられます。しかし、実際の運用で最も頻繁に間違えるのが、まさにそうした事例です。除外せずに個別のタグを付けて含め、そのグループの結果を個別に確認します。

発生頻度は低いものの被害が大きい事例（緊急の要請、安全に関する質問、高額な取引）は、無作為サンプルからは数件程度しか現れません。0.4%のタイプの事例は、1,000件のサンプルでも4件程度しか含まれず、そのタイプの性能を判定することはできません。こうした事例は個別に収集して十分な件数の独立したグループを作成し、全体のスコアとは別に合格基準を満たしているかを判定します。

評価セットの出所と規模

評価データはさまざまなところから得られます。OpenAIは、本番の運用ログ、ドメインエキスパートが作成したデータ、合成データ、購入したデータを挙げており、開発中にログを残して優れた評価事例を掘り起こすよう推奨しています。

規模に関しては、「多ければ多いほどよい」と「まずは小さく始める」の両方を心に留めておきます。Claudeのドキュメントによれば、自動採点が可能であるならば、個々の採点の精度が多少低くても質問数が多いほうが、人間が手作業で採点した少数の高品質な評価よりも優れているとされています。Anthropicのエージェント評価に関する記事では、実際の失敗から抽出した20〜50個のシンプルなタスクがあれば、良いスタートになると述べられています。小さく始めて、本番運用で見つかった失敗をもとに規模を拡大していくのが現実的なアプローチです。

ホールドアウトセットと過学習

同じ評価セットを見ながらプロンプトを何十回も修正すると、プロンプトがそのセットに過剰に適合してしまい、スコアが実際の性能よりも高くなってしまいます。これは、試験問題をあらかじめ見て勉強した生徒の点数が、本当の実力を反映していないのと同じです。

Google PAIRガイドでは、テストセットをモデルが見たことのないデータにしておくことで、実際にどれだけ適切に動作するかを把握できると説明されています。また、Claudeドキュメントのベンチマーク例でも、ホールドアウトされたテストセット（held-out test set）上で性能を判定しています。実務では評価セットを2つに分割します。プロンプトを修正する際に見る開発セットと、修正時には見ずに最終判定にのみ使用するホールドアウトセットです。開発セットのスコアは大幅に向上したのにホールドアウトセットのスコアが変わらない場合、その改善はそのセットに特化した過剰適合の結果である可能性が高いと言えます。

3つの採点方式

Claudeのドキュメントでは、採点方式を3つに分類しています。

Anthropicのエージェント評価に関する記事でも同様に整理されています。コードによる採点は高速、安価、客観的かつ再現可能ですが、正解と表現が異なるだけの正しい回答に対して弱く、モデルによる採点は結果が毎回わずかに変動する可能性があるため人間による採点との補正が必要であり、人間による採点は正解基準（gold standard）であるものの高コストで低速です。

採点方式を選択する順序

Claudeドキュメントの原則は、「最も高速で、最も信頼でき、最も拡張性のある方法を選択せよ」というものです。基準ごとに、以下の順序で検討します。

1. 正解が決まっており、照合が可能か？ → コードによる採点。
2. 判断が必要であるが、ルーブリックとして記述できるか？ → LLM採点（人間と照合して信頼性を確認後）。
3. ルーブリックがまだないか、専門的な判断が必要か？ → 人間が代表サンプルを採点して基準（ルーブリックと基準データ）を作成する。ルーブリックに落とし込みにくい専門的な品質である場合は、専門家によるブラインド比較そのものをリリース前評価として使用する。

単一の機能内であっても、基準ごとに適した方式は異なります。返金案内の回答であれば、「金額が注文システムの値と一致しているか」はコードで、「ポリシーの解釈が正しいか」「口調がガイドラインに合致しているか」はルーブリックを与えたLLM採点器で判定し、その採点器の補正や曖昧な事例は人間が担当します。1つの方式ですべての基準を採点しようとすると、コストか信頼性のどちらかを失うことになります。

LLM採点器を信頼できるようにする

Claudeのドキュメントでは、LLM採点のコツとして3点を挙げています。詳細で明確なルーブリックを提供すること、「正解／不正解」や「1〜5点」のように具体的な出力を要求すること、点数を出す前に推論を行わせることです。同ドキュメントのサンプルコードには、結果を生成したモデルとは別のモデルで評価することが一般的に推奨されるという説明もあります。

[ルーブリックの例：返金案内回答のポリシー解釈]
正解（correct）：注文日・商品状態・決済手段に応じた返金の可否と期限を案内している。
不正解（incorrect）：返金の可否や期限がポリシーと異なっているか、ポリシーにない条件を付け加えている。
判定が難しい場合は「unsure」と判定する。
出力：まず判断根拠を1〜2文で記述し、最後の行に correct / incorrect / unsure のいずれか1つのみを記述する。

ルーブリックだけでは不十分です。OpenAIは、人間の評価によって自動採点を補正し、LLM採点器がより高速かつ安価でありながら、人間の判定と継続して一致するようになった段階で規模を拡大するよう推奨しています。その手順は以下のとおりです。人間が代表サンプルをルーブリックに基づいて採点し、同じサンプルをLLM採点器で採点して一致度を確認します。乖離がある基準についてはルーブリックを修正し、一致度が目標値を超えたら全体に適用しますが、定期的に人間のサンプルと再照合を行います。

LLM採点器には既知のバイアスが存在します。OpenAIはLLM採点器のバイアスとして、回答の提示順序による位置バイアスを挙げており、より信頼できる手法としてペア比較や合否判定を推奨しています。ペア比較を用いる際は、2つの回答の順序を入れ替えて2回採点を行うことで位置バイアスを軽減します。内容に関係なく長い回答をより高く評価する傾向（長さバイアス）もよく見られます。そのため、スコアが大幅に跳ね上がった場合は、まず採点ログを直接読んでみます。Anthropicは、数多くの試行のログとスコアを読み込まなければ、採点が適切に機能しているかどうかを把握することはできないと述べています。

人間による採点の位置づけ

人間による採点は避けられるなら避けるべきだという言葉は、人間による採点を完全になくすという意味ではありません。人間による採点は、次の3つの場面で必ず必要となります。最初にルーブリックを作成して基準データを確立するとき、LLM採点器を補正するとき、そして正解がなく専門的な判断が求められるリリース前の比較においてです。

人間による採点においても一貫性を管理しなければなりません。Google PAIRガイドでは、人間がラベルを解釈する方法の違いを見つけ出す作業が、モデル開発を現実の状況に適応させることにつながると説明されています。2人の評価者が同じサンプルを個別に採点して一致度を確認し、意見が分かれた事例を一緒に読み合わせながらルーブリックを修正します。2つのバージョンを比較する際は、評価者にどちらのバージョンかを伏せた状態で並べて提示するブラインド比較を行うことで、バイアスを軽減できます。

能力評価と回帰評価

Anthropicは、評価を目的に応じて2つに分類しています。

能力評価で十分にこなせるようになったタスクは、回帰テストセットへと「卒業」させ、継続的に実行して性能が低下していないかを監視します。能力評価において解決可能なすべてのタスクをクリアし、もはや改善の余地を示せなくなった状態を、Anthropicは「評価の飽和」と呼んでいます。飽和した評価は識別力を失ってしまうため、運用環境で見つかった新たな失敗事例から難易度の高いタスクを補充します。

オフライン評価とオンライン指標

オフライン評価とは、用意した評価セットを用いてユーザーに公開することなく結果を測定する評価です。高速で繰り返し実行できますが、評価セットに含まれていない状況やユーザーの行動までは把握できません。オンライン指標は、実際の運用環境で測定される指標です。再生成のクリック、オペレーターへの転送、離脱、通報、購買へのコンバージョンなどがこれに該当します。

Anthropicは、最も効果的なチームは複数の手法を組み合わせて使用していると説明しています。迅速なイテレーションには自動評価を、実際の結果確認には運用監視を、十分なトラフィックがある際の大きな変更の検証にはA/Bテストを、自動評価で見落とされる部分にはユーザーフィードバックやログのレビューを、そして補正には定期的な人間によるレビューを活用します。

オフラインのスコアは良好であるにもかかわらずオンライン指標が改善しない場合、評価セットに含まれていない状況が本番環境で起きているというサインです。実際のログを読み込んで欠落している状況を見つけ出し、評価セットに追加します。

1回の成功と毎回の成功

同じタスクを複数回試行する際、成功をカウントする方法も要件によって異なります。Anthropicは、k回の試行のうち少なくとも1回成功する確率をpass@k、k回すべて成功する確率をpass^kとして説明しています。試行ごとの成功確率がpで等しく互いに独立である場合、pass^kはpのk乗となるため、1回の成功率が90%であっても3回連続して成功する確率は約73%にとどまります。人間が複数の候補の中から1つを選ぶ機能（フレーズ候補の提案など）であればpass@kが、顧客が毎回同等の品質の回答を受け取る必要がある機能（自動応答エージェントなど）であればpass^kが適した指標となります。同じスコアであっても、何をカウントするかによってリリースの判断が異なってきます。

評価結果によるリリース可否の判断

評価結果を受け取ったら、数値を見る前にまず3つの点を確認します。

1. 評価セットが実際を代表しているか。 代表していなければ、スコアが高くても根拠にはなりません。
2. 採点が信頼できるか。 LLM採点器が人間と照合されているか、スコアの上昇が回答の長さといった無関係な要因によるものではないか。
3. ホールドアウトセットで確認したか。 開発セットでのみ上昇したスコアは、過学習である可能性があります。

これら3つをクリアしたら、結果をタイプ別に読み解きます。全体のスコアが基準を超えていても、特定のタイプが大幅に基準を下回っている場合があります。その際の選択肢は3つあります。

機能の中核となる価値（例：問い合わせ対応時間の短縮）をリリース前に確認する必要がある場合は、その基準を改善目標ではなくブロッカー基準に設定しておきます。NIST AI RMFでは、システムが意図した目的と目標を達成しているか、開発やデプロイを進めるべきかを判断するよう求めています（MANAGE 1.1）。この判断は、結果を見る前に合意された基準に基づいて下されなければなりません。結果を見た後に基準を決めると、数値に合わせて基準を都合よく変更してしまうことになります。

評価計画書

評価計画書は1枚（A4 1枚程度）にまとめます。

[評価計画書]
対象機能とバージョン：
成功基準（第2章より）：ブロッカー基準／改善目標
評価セット：出所、規模、タイプ別構成（実際の比率との対比）、エッジケースセット、高リスクセット、各セットから分離したホールドアウトセット
採点：基準別方式（コード／LLM／人間）、LLM採点器の補正方法と一致度目標
回帰テストセット：構成、実行タイミング（変更ごと）、合格条件
オンライン指標：リリース後に確認する指標とアラート基準
判定ルール：リリース／条件付きリリース／保留の条件
スケジュールと担当者：

さらに深く

スコアが上がれば改善したと言えるのか

評価スコアが上がったという報告を受けた場合、4つの可能性を順に消去していきます。第1に、採点器が見当違いな特徴を評価してしまった可能性があります。回答が長くなるとLLM採点器のスコアが上がる現象はよく見られます。ログの標本を人間が直接読んで確認します。第2に、同じセットに合わせて修正してしまった可能性があります。ホールドアウトセットでも上がっているかを確認します。第3に、評価セットが変わってしまった可能性があります。問題を追加したり除外したりするとスコアの意味が変わるため、バージョンを記録しておきます。第4に、ランダムな変動である可能性があります。同じ評価を複数回実行し、ブレの幅を把握しておきます。

この4つを排除した後に残る上昇こそが、真の改善です。この順序を守るチームは、「スコアは上がったのに顧客の不満はそのまま」という状況に陥ることがはるかに少なくなります。

評価セットの寿命

評価セットは作って終わりの資産ではありません。OpenAIは評価を終わりではなく旅路と呼び、評価セットを時間をかけて拡充していくよう勧めており、Anthropicは飽和した評価では改善の余地を示せないと警告しています。評価セットのライフサイクルは次のとおりです。

1. 実際の失敗20〜50件と代表標本から始める。
2. 運用で見つかった新たな失敗を回帰セットに加える。
3. 十分に対応できるようになったケーパビリティ課題は回帰セットへと卒業させる。
4. ユーザーや入力の分布が変わったら、代表標本を抽出し直す。
5. バージョンを残し、以前の結果と比較できるようにする。

「一度作ったら変更しない」という原則は、比較可能性を維持しようとする善意から生まれたものですが、分布が変化した世界において古い試験問題でテストを受け続けさせることになってしまいます。比較可能性はバージョン管理で維持し、セットは継続的に拡充していきます。

オンライン指標の帰属問題

リリース後に指標が向上したからといって、機能のおかげであるとは断定できません。同じ期間に季節、イベント、他の機能の変更が同時に起きているためです。Google SREは、時間が観測指標を変化させる最も大きな要因の1つであると指摘しています。リリース前後の比較では、平日と週末、イベント期間と平常時が混ざって比較されてしまうおそれがあります。

効果を機能に帰属させるには、同一期間内に機能を目にしたグループとそうでないグループを無作為に分けて比較する必要があります。そのため、ビジネス指標に対する効果はA/Bテストで測定します。トラフィックが十分でない場合は実験の検出力が不足するため、その際は運用指標、ログ確認、ユーザーインタビューを併せて参照し、結論の確実性を下げて報告します。

実務の場面

あおみち自転車の故障報告ボット

シェアサイクルサービス「あおみち自転車」は、故障報告を受け付ける対話型ボットを開発しました。開発チームはチームメンバーが作成した200件の質問で評価を行い、正答率95%と報告しました。企画者はその数字を見る前に、3つの点を確認しました。

まず代表性です。実際の報告ログを確認したところ、35%が写真1枚と「これ使えません」といった短い文章だったのに対し、評価セットにはそのような報告が含まれていませんでした。企画者は過去2か月の報告から無作為に400件を抽出し、評価セットを再構成しました。次は高リスクな事例です。ブレーキの故障報告は全体の1%に過ぎませんでしたが、該当する自転車は直ちに運行を停止させる必要がありました。ブレーキの報告80件を別途収集し、「運行停止案内の漏れ0件」を個別の合格基準として設定しました。

採点は基準ごとに分けました。故障箇所の分類は正解ラベルとコードで照合し、案内文の丁寧さはルーブリックを与えたLLM採点器で採点させつつ、事前に整備チームのリーダーが採点した100件と照合して検証しました。再評価を行った結果、全体の正答率は88%、ブレーキのセットでは運行停止案内の漏れが3件ありました。却下された案は「全体の正答率が基準の85%を超えているためリリースする」というものでした。ブレーキのセットが個別基準を満たせなかったため、チームはブレーキ関連の表現が現れた場合はボットによる応答ではなく即座に運行停止手順へと引き渡すルールを組み込み、再評価に合格した上でリリースしました。

別冊書斎の書籍紹介文

出版社「別冊書斎」は、新刊の紹介文をAIで作成する機能について、2つのバージョンのうちどちらか1つを選択しなければなりませんでした。正解ラベルは存在せず、優れた紹介文であるかどうかは編集者の判断が必要でした。リリース前であったため、読者に公開してテストすることもできませんでした。

企画者はコードによる採点が可能な部分から選別しました。著者名・刊行日・ページ数が書籍情報と一致しているかどうかはコードで確認しました。残る「本の本質を歪曲していないか」と「読みたくなるか」については、3人の編集者に新刊60冊の2つのバージョンをどちらがどのバージョンか伏せた状態で並べて比較させました。提示順序は書籍ごとに変更し、位置バイアスを低減させました。

編集者たちは60冊中41冊でBバージョンのほうが優れていると選択し、歪曲の事例はAが7件、Bが2件でした。チームはBを採用し、編集者3人の判定180件（60冊 × 3人）をルーブリックとして整理して、次回以降はLLM採点器をその判定と照合した上で使用することにしました。却下された案は「読者のクリック率によるA/Bテスト」でした。リリース前であったことに加え、クリック率からは歪曲があるかどうかまでは把握できないためです。リリース後のクリック率は、独立したオンライン指標として別途追跡することにしました。

間違えやすいポイント

1. 「数個の例で確認すれば十分だ。」 感覚に頼る評価は代表的な失敗パターンです。実際の分布を代表する評価セットが必要です。
2. 「曖昧な事例は除外したほうが採点がすっきりする。」 曖昧な事例こそ、実環境で最も間違えやすいエッジケースです。ラベル付けして含め、別途確認します。
3. 「全体の精度が高ければ、稀なタイプも問題ない。」 0.4%程度の高リスクなタイプは全体のスコアに埋もれてしまいます。個別のテスト群と独立した基準が必要です。
4. 「人手による採点はコストがかかるため使わない。」 人手による採点は全体に適用しないだけであり、グラウンドトゥルースの作成や採点器のキャリブレーションには不可欠です。
5. 「LLM採点のスコアが上がったから改善された。」 キャリブレーションされていない採点器は、回答の長さといった見当違いな特徴を過大評価してしまうことがあります。ログを直接読み、人手による採点と照合します。
6. 「同じ評価セットで修正を繰り返せば確実になる。」 そのセットに過学習するだけです。ホールドアウトセットで最終判定を行います。
7. 「評価セットは一度作ったら変更しない。」 比較可能性はバージョン管理で維持し、セットは運用で見つかった失敗例を取り込んで育てていきます。
8. 「リリース後に指標が改善したのだから機能のおかげだ。」 同一期間内の他の要因を切り離すには、ランダム比較が必要です。

ひと目でわかるまとめ

公式ドキュメントで確認する

• Claude Docs — Define success criteria and build evaluations: 評価設計の原則、エッジケース、3つの採点方式とLLM採点のポイント。
• OpenAI — Evaluation best practices: 評価プロセスの5段階、評価駆動開発、失敗パターン、人手によるキャリブレーション、位置バイアス。なお、このページではOpenAIのEvalsプラットフォームが2026年10月31日に読み取り専用となり、11月30日に終了することも併せて案内されていますが、原則はプラットフォームに関係なく通用するものです。
• Anthropic — Demystifying evals for AI agents: ケーパビリティ評価と回帰評価、pass@kとpass^k、採点方式のメリット・デメリット、評価の飽和、手法の組み合わせ。
• Google PAIR Guidebook — Data Collection + Evaluation: テストセット、代表性、ラベル解釈の差異。
• Google SRE Workbook — Canarying Releases: 対照群との比較と時間要因。
• NIST AI RMF — Core: MANAGE 1.1（目的達成とデプロイ進行可否の判断）、MEASURE 2.4（運用中のモニタリング）。

セルフチェック

3-1. OpenAIが説明する評価プロセスの5段階を順番に書いてください。

3-2. Claudeのドキュメントが評価に含めるよう推奨しているエッジケース4つを書いてください。

3-3. コード採点、LLM採点、人手採点の限界をそれぞれ1文で書いてください。

3-4. 図書貸出案内ボットの回答のうち、「返却期日」と「案内の言葉遣い」を評価しようとしています。2つの基準に適した採点方式をそれぞれ選び、その理由を書いてください。

3-5. ケーパビリティ評価と回帰評価の目的と期待される合格率を比較し、ケーパビリティ課題が回帰セットへと移行するタイミングを説明してください。

3-6. 開発セットのスコアは70%から93%に上がったのに対し、ホールドアウトセットのスコアは71%から73%にしか上がっていません。何を疑うべきか説明してください。

3-7. 人間が複数の候補の中から1つを選ぶ機能と、顧客が毎回同等品質の回答を受け取る必要がある機能のそれぞれに適した成功集計方式を書いてください。

3-8. （設計）現在担当しているAI機能の1つについて、本章のフォーマットに沿って評価計画書を作成してください。その際、成功基準（ブロッキング基準と改善目標）ごとに採点方式とその理由を1行ずつ添えてください。

実習課題