プロンプト評価の基本：再現性と精度

プロンプトを少し書き換えて「なんとなく良くなった気がする」——その手応えは、本番では当てになりません。プロンプトやモデルを変えたら、良くなったのか悪くなったのかを数字で測る。これがプロンプト評価（evaluation、略してeval）です。テストを書かずにコードをデプロイしないのと同じで、評価なしにプロンプトを本番へ出さない、というのが今の作り方の前提になっています。

FIG.1　変更したプロンプトを同じ評価データで採点し、変更前後のスコアを並べて判断する

感覚に頼ると、たまたま手元で試した数件がうまくいっただけで「改善した」と思い込み、別のケースで静かに壊れていることに気づけません。評価は、その思い込みを事実で置き換えるための道具です。

01評価は4つの部品で組み立てる

プロンプト評価の仕組みは、難しく考えなくても次の4つの部品でできています。最初から完璧に揃える必要はなく、上から順に足していけば十分です。

02採点のやり方は3通り、得意分野が違う

自動採点には大きく3つの方法があります。どれか一つではなく、出力の性質に応じて組み合わせるのが実務的です。

機械的な採点（完全一致・ルール）	LLM-as-judge（LLMによる採点）
分類ラベル・数値・JSON形式など、答えが一意に決まるものに強い	要約・説明・対話など、表現が揺れて正解が一つに定まらないものに強い
速くて安く、結果がぶれない	人間の判断に近い柔軟さがあるが、コストがかかり、ぶれやすい
「言い回しが違うだけの正解」を誤って不正解にしがち	審査員役のLLM自身が間違える・偏ることがある

まずは完全一致やルールで測れるものは機械的に測り、それで測れない「文章の良し悪し」だけをLLM-as-judgeに任せる、という切り分けが無駄がありません。形式が守られているか（例：必ずJSONで返す、指定の見出しを含む）は、LLMに聞くまでもなくプログラムで検証できることが多い点も覚えておくと得です。

03LLM-as-judge の落とし穴

「採点も結局AIにやらせればいい」と思うと足をすくわれます。審査員役のLLMには、繰り返し報告されているクセ（バイアス）があるからです。代表的なものは次の4つです。

もう一つ「権威のクセ」もあります。断定的・専門的な口調の回答を、正しさと無関係に高評価してしまうものです。これらは運用で消すべき設計上の前提であって、放置すると評価そのものが信用できなくなります。対策の基本は、採点基準（ルーブリック）を具体的な文章で渡すこと。「役割（公平な評価者である）」「評価軸とその尺度」「出力フォーマット（点数と理由を構造化して返す）」を明示すると、審査員のブレが大きく減ります。

04再現性 ── 同じ入力なら同じスコアが出るように

評価でいちばん見落とされがちなのが再現性です。同じプロンプトを同じ評価データで採点したのに、回すたびにスコアが変わっては、改善したのか運が良かったのか区別できません。再現性を保つ勘所は次の通りです。

• 採点役の温度（temperature）を下げる：審査員LLMの温度を0〜0.2程度に設定すると、出力のばらつきが大きく減り、A/B比較や回帰検知に耐える安定したスコアになります。
• 条件を固定して記録する：使ったモデルのバージョン、採点プロンプト、各種設定を毎回そろえ、結果と一緒に残す。比較する候補はすべて同じ審査員・同じ設定で採点します。
• 評価データを版管理する：評価セット自体を更新したらバージョンを切る。データが変わればスコアが動くのは当然なので、いつの版で測ったかを必ず紐づけます。

プロンプトの良し悪しは、勘ではなく「同じ条件で測り直せる数字」で語る。

05点数のつけ方：1件ずつ vs 2つを比べる

採点には、1件ごとに点をつけるポイントワイズと、2つの回答を並べてどちらが良いか選ぶペアワイズの2系統があります。性質が違うので、目的で使い分けます。

FIG.2　ポイントワイズは速く全体傾向向き、ペアワイズは安定するが手間と費用がかかる

ポイントワイズは点数が回ごとに少しずつ動きやすい一方、ペアワイズ（どちらが良いかの一騎打ち）はより信頼できる結果になります。ただしペアワイズは、位置のクセを打ち消すため順序を入れ替えて両方向で測る必要があり、組み合わせの数だけ採点回数が増えてコストがかさみます。「全体の傾向はポイントワイズで広く見て、最終判断はペアワイズで詰める」といった併用が現実的です。

06最小から始める ── 20〜50件で十分効く

「立派な評価基盤を整えてから」と構える必要はありません。まずは代表的なケースを20〜50件、入力と期待値のセットで用意し、変更前後で回すだけ。これだけで、思わぬ後退（リグレッション）を本番に出す事故が大きく減ります。慣れてきたら、本番ログから1つの用途あたり100〜300件規模のゴールデンデータセット（人がレビューして版を切った正解集）へ育てていくと、誤検知が減って判断が安定します。

FIG.3　小さく始め、本番ログを材料にゴールデンデータセットへ育てる

07変更のたびに自動で回す ── CI と回帰テスト

評価の真価は、人が思い出したときではなく変更のたびに自動で走ることで発揮されます。プロンプト・モデルのバージョン・検索設定のいずれかに手を入れた変更（プルリクエスト）が出たら、ゴールデンデータセットで評価を回し、スコアが基準を下回ったらマージを止める——これが今の標準的なやり方です。

• 合格ラインを決めておく：例として「正解率が基準を下回ったら」「ハルシネーション率が許容を超えたら」自動でブロックする、というしきい値を設定します。具体値は用途次第なので、自分たちのデータで calibrate（較正）するのが前提です。
• 変更があった経路だけでなく全体を見る：一部を直したつもりが別の用途を壊す「もぐらたたき」を防ぐため、回帰テストは関連範囲をまとめて回します。
• 差分を見える化する：プルリク上に変更前後のスコア比較を出すと、レビューで「どこがどれだけ動いたか」が一目で分かります。

08注意：評価そのものも疑う

• 少数の手応えで判断しない。数件うまくいったは「うまくいった証拠」ではなく、データで比較してはじめて言えます。
• LLM-as-judge も間違える。重要な指標は、審査員LLM任せにせず人手でサンプルを抜き取り確認（スポットチェック）を併用します。
• モデル更新で性能は変わる。使っているモデルがアップデートされると、同じプロンプトでも挙動が変わります。評価は一度きりではなく継続的に回し続けます。
• 「良くしたつもりが悪化」は普通に起きる。プロンプトを丁寧にしたら別のケースで後退した、というのは珍しくありません。だからこそ評価で確かめます。

09道具立て ── まず手を動かせるものから

評価を支援するツールも揃ってきています。最初から導入しなくても、表計算とAPI呼び出しの手書きスクリプトで十分始められますが、規模が増えたら専用ツールに移ると楽になります。タイプ別に主なものを挙げます。

• 評価・テスト中心：promptfoo（ターミナルとYAML設定で動かすオープンソース。CI/CDに組み込みやすく、2026年3月にOpenAIが買収を発表したが引き続きOSSとして公開）、DeepEval など。
• 観測（トレース）中心：Langfuse（自前ホスト可能なオープンソース。トレース・評価・プロンプト管理・コスト追跡を一体で扱う）、LangSmith など。
• 両方を一気通貫で：Braintrust（ローカルでの実験からCIでの品質チェック、本番監視までを1つでカバー。プルリクにスコア比較を自動投稿するGitHub連携を持つ）など。
• RAG向け：RAGAS など、検索つき生成の品質を測る専用の指標群。

料金・機能は変動が激しい領域です。具体的なプランや対応範囲は必ず各公式情報で確認し、ここでの位置づけは出発点として捉えてください。

10まとめ ── プロンプトは「コード」

プロンプトは、書いて終わりの文章ではなく、品質を管理すべきコードです。テストなしにデプロイしないのと同じく、評価なしに本番へ出さない。まずは代表ケースを20〜50件用意し、変更前後で同じ条件で採点してみる——その一歩だけで、見えていなかった後退を捕まえられるようになります。再現性（同じ条件なら同じ数字）を保ち、審査員のクセを意識し、変更のたびに自動で回す。ここまで来れば、プロンプトの改善は感覚ではなく事実の上で進められます。次章では、こうした評価や管理を支えるツールをもう一歩踏み込んで扱います。