Evalの設計と仕組み——プロンプト品質を測るパイプラインを作る【CCA Foundations対策】
CCA Foundations対策 · Claude API編 第4回（全17回）
Anthropic Academyの「Claude APIを使用した構築」コースをもとに解説しています。
プロンプトを書いたあと、どうやって「これでいい」と判断しているだろうか。1〜2回テストして感触がよければOK——そのやり方で本番トラブルを経験したことがある人は多いはず。
この記事では、プロンプトの品質を客観的なスコアで測る**Eval（プロンプト評価）**の考え方と、改善サイクルを回すための5ステップのワークフローを整理する。グレーダー設計の落とし穴まで踏み込んで解説する。
この記事でわかること：
- プロンプトエンジニアリングとEvalの役割の違い
- 5ステップのEvalワークフローの流れ
- 良いテストデータセットの条件
- グレーダーの3種類と、それぞれの使いどころ
- グレーダー設計でよくある落とし穴（曖昧な基準・自己採点問題）
プロンプトを書いたあと、どうしてますか？
プロンプトを書き終えたとき、次にとる行動はおおよそ3つに分かれる。
Option 1：1〜2回テストして「よさそう」なら本番投入
手軽だが、リスクが高い。自分が想定した入力ではうまく動いても、本番ユーザーは想像の斜め上の聞き方をしてくる。本番で初めて問題が発覚するパターン。
Option 2：気になるケースを手動で試して微調整
Option 1よりはマシだが、確認できるケース数に限界がある。コーナーケースを1つ潰したら別のコーナーケースが生まれる、というイタチごっこになりやすい。
Option 3：Evalパイプラインで客観スコアを取ってから改善
手間はかかるが、プロンプトの性能を数値で把握できる。「v1よりv2の方がスコアが高い」という根拠を持って改善を進められる。
エンジニアはOption 1・2に陥りやすい。手元でうまく動いたプロンプトへの過信と、テストインフラを整える工数を惜しむ気持ちが重なるからだ。しかし本番ユーザーの入力の多様さは、開発時の想定をはるかに超える。
プロンプトエンジニアリングとプロンプト評価——2つの役割
混同しやすいが、役割が異なる。
| プロンプトエンジニアリング | プロンプト評価（Eval） | |
|---|---|---|
| 問い | どう書くか | どれくらい効くか |
| アプローチ | XMLタグ・マルチショット・役割設定など | 自動テスト・スコアリング |
| 目的 | Claudeに意図を伝える | 品質を数値で把握する |
プロンプトエンジニアリングで「より伝わるプロンプト」を書き、Evalで「どれくらい改善したか」を測る。2つはセットで機能する。
Evalがあることで初めて、プロンプトの変更が「改善」なのか「劣化」なのか「ただの変化」なのかを客観的に判断できる。
ユニットテストとの違いも押さえておきたい。 ユニットテストは「この入力に対してこの出力が返る」という決定論的な検証。一方Evalは、確率的な生成モデルに対して「全体的にどの程度の品質か」を統計的に評価するもの。合格・不合格ではなく、スコアの分布で判断する。
Evalワークフローの5ステップ
Evalに決まった手法はない。ただし核となるステップは共通している。
プロンプト v1
│
▼
テストデータセット ─── 入力の集合（多様なケースを含む）
│
▼
Claude ─────────────── プロンプト + テストケース → レスポンス生成
│
▼
グレーダー ─────────── 各レスポンスを 1〜10 点でスコアリング
│
▼
平均スコア ─────────── 数値で比較 → プロンプト改善 → v2 へ
Step 1：プロンプトを書く
まず評価対象となるベースラインプロンプトを用意する。シンプルな出発点でいい。
商品についてのお問い合わせに、丁寧に回答してください。
お問い合わせ：{question}
このプロンプトの何が問題か——Evalを回すまでわからないのが現実。
Step 2：テストデータセットを用意する
プロンプトに流し込む入力の集合を作る。件数は3件でも始められるが、多いほど評価の信頼性が上がる。
良いテストデータセットの条件：
- 典型的なケース：よく来る普通の質問
- エッジケース：曖昧な質問・情報が不足している質問・意図が読み取りにくい質問
- 本番に近いケース：実際のユーザーが使う言い回し（丁寧・砕けた・誤字あり）
ECサイトのFAQbotを例にすると、こんなデータセットになる：
test_cases = [
{"question": "商品の返品方法を教えてください"}, # 典型
{"question": "送料はいくらかかりますか"}, # 典型
{"question": "在庫切れの場合、入荷予定はわかりますか"}, # 典型
{"question": "昨日買ったやつ返したいんですけど"}, # 砕けた表現
{"question": "壊れてた"}, # 情報不足
{"question": "他のサイトの方が安いんですが"}, # 想定外のケース
]
典型的なケースだけ入れるのは避けたい。 典型ケースでスコアが高くても、エッジケースで破綻する可能性がある。
Step 3：Claudeに回答させる
各テストケースをプロンプトに埋め込んで、Claudeに回答を生成させる。
商品についてのお問い合わせに、丁寧に回答してください。
お問い合わせ：商品の返品方法を教えてください
これを全テストケース分繰り返し、レスポンスを収集する。
Step 4：グレーダーでスコアリングする
収集したレスポンスをグレーダーに渡し、スコアを付ける。グレーダーの実装方法は3種類ある：
| 種類 | 向いているケース | 例 |
|---|---|---|
| コードベース | 決定論的に検証できるもの | JSONのバリデーション・特定ワードの有無・フォーマット確認 |
| モデルベース | 主観的な品質評価 | 回答の適切さ・トーン・網羅性の評価 |
| 人手 | 最終的な品質確認 | 重要なケースの人間によるレビュー |
グレーダーが各レスポンスを採点し、平均スコアがプロンプト全体の「成績」になる。
返品方法の質問 → スコア: 8
送料の質問 → スコア: 4（曖昧な回答になった）
在庫の質問 → スコア: 9
砕けた表現 → スコア: 7
情報不足の質問 → スコア: 3（内容を誤って補完してしまった）
想定外ケース → スコア: 5
平均スコア v1 = 6.0
送料と情報不足の質問でスコアが低い。プロンプトに具体的な指示が足りないのかもしれない。
Step 5：スコアを見て改善し、繰り返す
スコアをもとにプロンプトを修正して、同じデータセットで再評価する。
商品についてのお問い合わせに、丁寧に回答してください。
具体的な手順や金額がある場合は、箇条書きで明示してください。
情報が不足していて回答できない場合は、不足している情報を質問してください。
お問い合わせ：{question}
返品方法の質問 → スコア: 9
送料の質問 → スコア: 8（改善）
在庫の質問 → スコア: 9
砕けた表現 → スコア: 8（改善）
情報不足の質問 → スコア: 8（改善：不足情報を質問するようになった）
想定外ケース → スコア: 6
平均スコア v2 = 8.0
v1（6.0）→ v2（8.0）と数値で改善を確認できた。「なんとなく良くなった気がする」ではなく、スコアという根拠を持って次の判断ができる。
グレーダー設計の落とし穴
Evalの精度はグレーダーの設計に大きく依存する。ここを疎かにすると、スコアが高くても本番で問題が起きる。
落とし穴①：グレーダーの基準が曖昧
グレーダーに「良い回答かどうか評価してください（1〜10点）」と聞いても、採点基準がブレる。
曖昧な基準（避けたい）：
この回答の品質を1〜10点で採点してください。
丁寧で、役に立つ回答なら高得点にしてください。
具体的な基準（推奨）：
この回答を以下の基準で1〜10点で採点してください。
【高得点（8〜10点）の条件】
- 質問に直接答えている
- 具体的な手順や金額が含まれる場合は箇条書きで示している
- 情報が不足している場合は、必要な情報を質問している
【低得点（1〜4点）の条件】
- 質問と無関係な回答をしている
- 情報を誤って補完・推測している
- 曖昧な回答で質問が解決しない
採点結果のみを数字で返してください。
「丁寧に」「役に立つ」といった言葉はClaudeの解釈に委ねることになる。何点をどう定義するかを具体的に書くほど、採点結果が安定する。 プロンプト本体と同じで、グレーダーにも明示的な基準が必要。
📋 試験ガイドより
公式試験ガイドのDomain 4 Task 4.1では、曖昧な指示より明示的な評価基準を設計することの重要性が取り上げられている。グレーダー設計はプロンプト設計と同じ原則が当てはまる。
落とし穴②：自分の出力を自分で採点する問題
モデルベースのグレーダーでよくある設計ミスが、生成に使ったのと同じセッションや文脈でレスポンスを採点させること。
モデルは生成時の推論文脈を保持しているため、自分が生成した回答に対して批判的になりにくい。同じプロンプト・同じ文脈で採点させると、スコアが高めに出る傾向がある。
# 問題のある設計
response = generate_response(prompt, question) # 生成
score = grade_in_same_session(response) # 同じ文脈で採点 ← 甘くなる
# より信頼性が高い設計
response = generate_response(prompt, question) # 生成
score = grade_with_fresh_instance(response) # 文脈を引き継がない別のリクエストで採点
採点用のリクエストは生成とは独立したリクエストとして送る。これだけで採点の客観性が上がる。
本番に近い重要なEvalでは、Claudeの採点に加えて人間のレビューも組み合わせるのが堅牢な設計。
📋 試験ガイドより
公式試験ガイドのDomain 4 Task 4.6では、生成とは独立したレビューインスタンスを使う設計が取り上げられている。同一文脈での自己採点は採点が甘くなりやすいという問題意識が背景にある。
よくある誤解まとめ
| 誤解 | 実際 |
|---|---|
| 手元で動いたプロンプトは本番でも動く | 本番ユーザーの入力は開発時の想定を超える |
| 典型ケースだけでテストすれば十分 | エッジケースで破綻する可能性を見落とす |
| グレーダーに「良い回答を高得点に」と書けば機能する | 曖昧な基準は採点のブレを生む。具体的な条件が必要 |
| 同じClaudeに生成と採点の両方をやらせていい | 生成文脈が残るため採点が甘くなりやすい |
| Evalはユニットテストと同じ | Evalはスコアの分布で判断する統計的な評価。合格・不合格ではない |
まとめ
- プロンプトを「1〜2回テストして本番」は罠。本番ユーザーの入力は開発時の想定を超える
- プロンプトエンジニアリング（どう書くか）とEval（どれくらい効くか）は役割が違う。2つはセット
- Evalの基本は5ステップ：プロンプト → データセット → 生成 → グレーダー → 改善
- テストデータには典型・エッジ・本番に近いケースを混ぜる
- グレーダーの基準は具体的な条件・点数の定義まで書く。曖昧な指示は採点のブレを生む
- 採点は生成と独立したリクエストで行う。同じ文脈での自己採点は甘くなりやすい
次回はこのワークフローを実際に実装する。テストデータセットの自動生成・Evalの実行・モデルベースとコードベースの採点方法をコードで示す。