LLMの出力がなかなか安定せず、プロンプトを何度書き直しても良くなった実感がない。そう感じているなら、足りないのはプロンプトの工夫ではなく「出力の良し悪しを測る物差し」だ。この記事は、業務でLLMを使う事業者・開発担当者に向けて、プロンプトより先に作るべき評価基準(eval)の設計手順を、項目の決め方から運用への組み込みまで具体的に示す。
出力が安定しない根本原因は、プロンプトの巧拙ではなく「何を良い出力とするか」が決まっていないことにある。良し悪しの基準が言語化されていないと、変更が改善なのか改悪なのか判断できない。だから手は動くのに、品質は前に進まない。
評価基準が無いまま進めると、3つの問題が起きる。第一に、プロンプトを直すたびに勘で良し悪しを判断するため、改善が再現しない。第二に、ある事例が良くなっても別の事例が悪化する「もぐら叩き」に陥る。第三に、品質が定量化されず、現場に展開してよいかの判断ができない。
ここで多くの現場が打つ手は、プロンプトの言い回しを足したり、例を増やしたりする工夫だ。否定はしないが、これは物差し無しで長さを測ろうとする行為に近い。基準が無ければ、どの変更が効いたのかを切り分けられない。
私はAdobeやAppierといったAI企業でマーケの責任者を務め、いまは自分で生成AIのプロダクトを開発している。その経験から断言できるのは、出力品質を安定させた事例の多くは、プロンプトを磨く前に評価基準を先に作っていたという点だ。基準が先、プロンプトは後である。
評価基準(eval)とは、LLMの出力が要件を満たしているかを判定するための、明文化された物差しを指す。テストコードがプログラムの正しさを測るのと同じ役割を、AIの出力に対して果たす仕組みだ。これを先に作る理由は、改善の良し悪しを客観的に測れるようになるからだ。
評価基準を先に持つと、開発の進め方が根本から変わる。プロンプトを変更したら評価を回し、スコアが上がったかどうかで採否を決める。勘ではなく数字で判断するため、改善が積み上がる。これはソフトウェア開発のテスト駆動と同じ発想だ。
具体的に、評価基準が無い場合とある場合の違いは次のとおりだ。
| 観点 | 評価基準が無い場合 | 評価基準がある場合 |
|---|---|---|
| 改善の判断 | 担当者の主観で決める | スコアの増減で決める |
| 変更の影響 | 他の事例の悪化に気づけない | 全事例での増減を確認できる |
| 品質の説明 | 良くなった気がするとしか言えない | 数値で品質を提示できる |
| 展開の可否 | 現場投入の判断ができない | 基準達成で投入を判断できる |
注意したいのは、評価基準は「正解の文章」を1つ決めることではない点だ。LLMの出力は表現に幅があり、正解を1文に固定すると現実に合わない。測るのは表現の一致ではなく、満たすべき要件を満たしているかどうかである。
評価項目は、汎用の指標を借りてくるのではなく、自社タスクで「外してはいけない要件」から逆算して決める。タスクごとに守るべき点は違うため、他社の評価表を流用しても効かない。まず自分のタスクで失敗とは何かを言語化することから始める。
評価項目を洗い出すときは、次の5つの問いを埋める形で設計すると抜けが減る。各問いは、出力が業務で使えなくなる典型的な失敗に対応している。
| 評価の観点 | 確認する問い | 不合格の例 |
|---|---|---|
| 事実の正しさ | 事実誤認や捏造がないか | 存在しない数値を作る |
| 指示への忠実さ | 指定の形式や条件を守ったか | 文字数や項目を無視する |
| 過不足のなさ | 必要な情報が漏れていないか | 重要な前提が抜ける |
| 安全性 | 出してはいけない内容を避けたか | 不適切な断定をする |
| 体裁 | 求めた形式で出力したか | JSONが壊れる |
この5観点のうち、業務で致命傷になる項目から優先度を付ける。たとえば顧客向け文章なら事実の正しさと安全性を最優先にし、社内の下書き用途なら体裁の優先度は下げてよい。全項目を等しく重くすると、評価が重くなりすぎて回らなくなる。
評価項目は、最初から完璧を目指さない。3項目から5項目に絞り、まず回し始めることを優先する。実際に出力を採点していくと、想定していなかった失敗パターンが見えてくる。そのとき項目を足せばよい。
評価には、採点の対象となる入力と出力のセットが要る。理想を待つより、手元の実データから小さく始めるのが正解だ。完璧なデータセットを用意しようとして着手が遅れるより、20件でも30件でも代表的な事例を集めて回し始めるほうが学びが速い。
評価データを集める手順は次の4ステップで組める。
ここで外せない原則がある。評価データには、うまくいく事例だけでなく、壊れやすい事例を必ず混ぜることだ。簡単な事例ばかりだと、どんなプロンプトでも高得点になり、評価が機能しない。難しい事例こそが、改善の差を浮き彫りにする。
私が自社で生成AIプロダクトを開発するときも、最初に作るのは華やかなデモではなく、壊れやすい入力を集めた小さな評価セットだ。たたき台のプロンプトでも、評価セットがあれば「どこで壊れるか」が即座に見える。この見える化が、改善の速さを決める。
評価のやり方は、人が採点する方法と、AIに採点させる方法(LLM-as-a-judge)の2つがある。結論として、最初は人手で基準を固め、安定してきたらAI採点で量をこなす、という順番が現実的だ。いきなりAIに任せると、採点そのものがずれていても気づけない。
2つの方法には、それぞれ向き不向きがある。使い分けの目安は次のとおりだ。
LLM-as-a-judgeを使うときの注意点として、採点役のAIにも評価基準を明文で渡す必要がある。曖昧な指示で「良いか悪いか判定して」と頼むと、採点が安定しない。人に渡すのと同じ合格条件を、採点プロンプトにそのまま書くのが基本だ。
AI採点を導入したら、たまに人手の採点と突き合わせて、AIの採点が人の感覚とずれていないかを確認する。採点役がずれていれば、その上で測った品質も信用できない。物差し自体を時々校正する、という発想を持っておく。
評価は一度作って終わりではない。本当の価値は、プロンプトを変えるたびに評価を回す習慣を運用に組み込んだときに出る。変更と評価がセットになって初めて、品質は勘ではなく数字で積み上がっていく。
改善を回し続けるための運用の勘所は次のとおりだ。
ここで陥りやすい罠がある。スコアを上げること自体が目的化し、評価データに過剰に最適化してしまうことだ。評価セットだけで高得点でも、本番の未知の入力で壊れては意味がない。評価データは定期的に新しい事例で入れ替え、本番の現実とずれないようにする。
評価基準を持つ効果は、品質を測れることだけではない。何を良しとするかをチームで合意できるため、属人的だった「品質の感覚」が共有資産になる。評価の言語化は、AI実装の学習速度そのものを上げる投資である。なお、こうした評価設計やAIの業務実装の型は、研修で体系立てて学ぶこともできる。自社では法人向けのAI研修プログラム「AI-CODEMY」を通じて、現場へのAI実装を支援している。
LLMの出力品質を安定させる起点は、プロンプトの工夫ではなく評価基準(eval)を先に作ることにある。守るべき要件から評価項目を決め、壊れやすい事例を集めた小さな評価セットを用意し、変更のたびに評価を回す。この順番が揃うと、改善は勘から数字へ、属人から仕組みへ移る。
まず試すべきは、いま使っているプロンプトの「合格条件」を箇条書きで5つ書き出すことだ。書けない項目があれば、そこがあなたの出力が安定しない原因である。
発想は同じで、対象が違うだけです。テストはプログラムの正しさを決まった入出力で測りますが、LLMの出力は表現に幅があるため、1つの正解文では測れません。そこでevalは「正解文の一致」ではなく「満たすべき要件を満たしているか」を判定する物差しとして設計します。役割はソフトウェア開発のテストと同じく、変更が改善か改悪かを客観的に切り分けることです。
最初は3項目から5項目に絞ることをおすすめします。事実の正しさ、指示への忠実さ、過不足のなさ、安全性、体裁といった観点から、自社タスクで致命傷になるものを優先します。多くの項目を一度に置くと評価が重くなり、回らなくなります。運用しながら、想定外の失敗が見えたときに項目を足していくのが現実的です。
件数より、壊れやすい事例が入っているかが重要です。簡単な事例ばかり多く集めても、どんなプロンプトでも高得点になり評価が機能しません。まずは代表的な入力と例外的な入力を合わせて数十件から始め、本番で出た失敗事例を追加して育てる進め方が効果的です。少数でも難しい事例が入っていれば、改善の差は見えます。
基準が固まった量産段階では有用ですが、採点役のAIも誤ることがあるため任せきりは危険です。採点プロンプトに合格条件を明文で渡し、ときどき人手の採点と突き合わせて、AIの採点が人の感覚とずれていないかを確認します。とくに事実の正しさや安全性のような致命傷になる項目は、人の最終確認を残すのが安全です。
初期は評価データ作りの手間が増えますが、回すほど全体の工数は下がる傾向があります。評価が無いと、プロンプト変更のたびに勘で良し悪しを判断し、もぐら叩きで手戻りが続きます。評価があれば変更の影響を一括で確認でき、改善が積み上がります。手間ではなく、改善を再現可能にするための投資と捉えるのが適切です。
規模より、LLMの出力を業務で使うかどうかで判断します。出力をそのまま顧客や社内に出すなら、品質を測る物差しは規模に関わらず必要です。むしろ少人数のほうが品質の感覚が属人化しやすく、評価を言語化しておく価値は大きいです。まずは合格条件を箇条書きにするだけでも、チーム内の品質の認識が揃います。
LLMの出力品質を、勘ではなく評価基準で安定させたい方へ。サーチイレブンでは、営業とAI開発の両方を経験した立場から、自社のタスクに合う評価基準の設計とAIの業務実装を支援している。どこを評価すれば成果に効くか、論点を一緒に整理する無料診断から始められる。まずは気軽にご相談いただきたい。