プロンプトを少し書き換えて「なんとなく良くなった気がする」——その手応えは、本番では当てになりません。プロンプトやモデルを変えたら、良くなったのか悪くなったのかを数字で測る。これがプロンプト評価（evaluation、略してeval）です。テストを書かずにコードをデプロイしないのと同じで、評価なしにプロンプトを本番へ出さない、というのが今の作り方の前提になっています。
FIG.1 変更したプロンプトを同じ評価データで採点し、変更前後のスコアを並べて判断する
感覚に頼ると、たまたま手元で試した数件がうまくいっただけで「改善した」と思い込み、別のケースで静かに壊れていることに気づけません。評価は、その思い込みを事実で置き換えるための道具です。
01評価は4つの部品で組み立てる
プロンプト評価の仕組みは、難しく考えなくても次の4つの部品でできています。最初から完璧に揃える必要はなく、上から順に足していけば十分です。
評価データセット
実際に来そうな入力と、その「期待する出力」をセットで集めたもの。本番のログや問い合わせ履歴から代表例を抜き出すのが王道です。これが評価のすべての土台になります。
評価指標
何をもって「良い」とするかの物差し。正確さ、出力形式が守られているか、答えるべきものを拒否していないか、コスト、応答速度（レイテンシ）などを、用途に合わせて選びます。
自動採点
一件ずつ人が見ていられないので、機械的に点をつけます。完全一致、ルール照合、そして別のLLMに採点させる「LLM-as-judge（LLMを審査員にする）」の3通りが基本です。
回帰テスト
プロンプトやモデルを変えるたびに、同じ評価データで採点をやり直すこと。「前は通っていたケースが新しい変更で壊れていないか」を毎回確かめる、いわば品質の見張り役です。
02採点のやり方は3通り、得意分野が違う
自動採点には大きく3つの方法があります。どれか一つではなく、出力の性質に応じて組み合わせるのが実務的です。
