【CCA Foundations対策 / Claude API編 #4】Evalの設計と仕組み——プロンプト品質を測るパイプラインを作る
Anthropic Academyの「Claude APIを使用した構築」コースをもとに解説しています。
プロンプトを書いたあと、どうやって「これでいい」と判断しているだろうか。この記事では、プロンプトの品質を客観的なスコアで測る**Eval（プロンプト評価）**の考え方と、改善サイクルを回すための5ステップのワークフローを整理する。
プロンプトを書いたあと、どうしてますか？
プロンプトを書き終えたとき、次にとる行動はおおよそ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ワークフローの5ステップ
Evalに決まった手法はない。ツールも自前実装からオープンソースまで多様にある。ただし核となるステップは共通している。
プロンプト v1
│
▼
テストデータセット ─── 入力の集合（数件〜数千件）
│
▼
Claude ─────────────── プロンプト + テストケース → レスポンス生成
│
▼
グレーダー ─────────── 各レスポンスを 1〜10 点でスコアリング
│
▼
平均スコア ─────────── 数値で比較 → プロンプト改善 → v2 へ
Step 1：プロンプトを書く
まず評価対象となるベースラインプロンプトを用意する。シンプルな出発点でいい。
商品についてのお問い合わせに、丁寧に回答してください。
お問い合わせ：{question}
Step 2：テストデータセットを用意する
プロンプトに流し込む入力の集合を作る。手動で書いてもいいし、Claudeに生成させることもできる（#5で扱う）。件数は3件でも始められるが、多いほど評価の信頼性が上がる。
ECサイトのFAQbotを例にすると、こんなデータセットになる：
[
{"question": "商品の返品方法を教えてください"},
{"question": "送料はいくらかかりますか"},
{"question": "在庫切れの場合、入荷予定はわかりますか"}
]
Step 3：Claudeに回答させる
各テストケースをプロンプトに埋め込んで、Claudeに回答を生成させる。
商品についてのお問い合わせに、丁寧に回答してください。
お問い合わせ：商品の返品方法を教えてください
これを全テストケース分繰り返し、レスポンスを収集する。
Step 4：グレーダーでスコアリングする
収集したレスポンスをグレーダーに渡し、1〜10点でスコアを付ける。グレーダーの実装方法は3種類ある：
- コードベース：JSONのバリデーション・特定ワードの有無など、プログラムで検証できるもの
- モデルベース：別のClaudeを使ってレスポンスの品質を評価させる
- 人手：人が直接評価する（最も柔軟だが時間がかかる）
グレーダーが各レスポンスを採点し、平均スコアがプロンプト全体の「成績」になる。
返品方法の質問 → スコア: 8
送料の質問 → スコア: 4（曖昧な回答になった）
在庫の質問 → スコア: 9
平均スコア v1 = (8 + 4 + 9) ÷ 3 = 7.0
送料の質問でスコアが低い。プロンプトに具体的な指示が足りないのかもしれない。
Step 5：スコアを見て改善し、繰り返す
スコアをもとにプロンプトを修正して、同じデータセットで再評価する。
商品についてのお問い合わせに、丁寧に回答してください。
具体的な手順や金額がある場合は、箇条書きで明示してください。
お問い合わせ：{question}
返品方法の質問 → スコア: 9
送料の質問 → スコア: 8（改善された）
在庫の質問 → スコア: 9
平均スコア v2 = (9 + 8 + 9) ÷ 3 = 8.7
v1（7.0）→ v2（8.7）と数値で改善を確認できた。「なんとなく良くなった気がする」ではなく、スコアという根拠を持って次の判断ができる。
このサイクルを繰り返すことで、プロンプトを体系的に改善できる。
まとめ
- プロンプトを「1〜2回テストして本番」は罠。本番ユーザーの入力は開発時の想定を超える
- プロンプトエンジニアリング（どう書くか）とプロンプト評価（どれくらい効くか）は役割が違う。2つはセット
- Evalの基本は5ステップ：プロンプト → データセット → Claude → グレーダー → 改善
- スコアがあることで「この変更は改善か劣化か」を客観的に判断できる
次回はこのワークフローを実際に実装する。テストデータセットの自動生成・Evalの実行・モデルベースとコードベースの採点方法をコードで示す。