プロンプトの「評価方法」について学んでみた

プロンプトの評価方法を学んだ話

プロンプト、ちゃんと動いてますか？

プロンプトエンジニアリング、やってますか？ ChatGPTやClaudeを使って、いろんなプロンプトを作っている方も多いと思います。

でも、気づいたら...

  • 「なんとなく動いてるからOK」で終わっている
  • 本当にこれで大丈夫か不安
  • テストってどうやるの？

そんな経験、ありませんか？

今回、プロンプトの評価方法について調べてみたので、学んだことを書こうと思います。

自己紹介

こんにちは、MenuManagerチームでエンジニアをしている神谷です。

最近、業務でプロンプトを作る機会が増えてきました。 チームとしてもAI関連のツールを作成していくことが決まっています。

でも、作ったプロンプトが「本当にちゃんと動いているのか」を確認する方法がわからず、 なんとなくモヤモヤしていました。

そこで、プロンプトの評価方法について調べてみることにしました。

出会った論文

調べていく中で、こんな論文に出会いました。

「A Survey on Evaluation of Large Language Models」

この論文を読んで、評価には整理された考え方があることを知りました。

論文から学んだ「3つの軸」

論文では、LLMの評価を 3つの軸 で整理していました。

1. What：どんな能力を評価するか
2. Where：どんな問題・データで評価するか
3. How：どんな採点方法で評価するか

論文の原文では "three key dimensions"（3つの重要な軸）と表現されています。

1. どんな能力を評価するか（What）

論文では、LLMの様々な能力が紹介されていました。

能力 説明
正確性 正しい答えを出せるか
一貫性 毎回同じ答えを出すか
ロバスト性 プロンプトが少し変わっても安定するか
倫理・バイアス 有害な出力や偏りがないか
推論能力 論理的に考えられるか
知識 事実を正しく知っているか
信頼性 嘘をつかないか（ハルシネーション対策）

この中から、AIツールを作成する上で重要そうな 2つ に絞って意識することにしました。

能力 説明 なぜ重要か
正確性 正しい答えを出せるか 間違った情報を出すと困る
ロバスト性 プロンプトが少し変わっても安定するか ユーザーの入力はブレるので

特に「ロバスト性」は、調べる前は意識していませんでした。

ロバスト性について補足

ロバスト性が問題になるのは、ユーザーが自由にテキストを入力する場合です。

ユーザーの入力は「ブレ」ます。

同じことを聞きたくても...
- 「要約してください」
- 「要約して下さい」
- 「まとめて」
- 「簡潔に教えて」

これらすべてで安定した結果を出せるかがロバスト性です。

逆に言うと、固定のプロンプトが走る設計 なら、 そもそも入力のブレが発生しないので、ロバスト性を意識する必要は低くなります。

つまり、設計段階で「ユーザーに自由入力させるか」を検討することも、 ロバスト性対策の一つと言えそうです。

2. どんな問題・データで評価するか（Where）

「Where」は、どんなテストデータを使って測るか という意味です。

例え話で言うと：

「数学の力を測りたい」場合

- 小学校のテストで測る → 100点取れる
- センター試験で測る → 80点
- 東大入試で測る → 30点

同じ能力でも、使う問題で結果が変わる

プロンプト評価でも同じです。 どんな問題でテストするかで、評価結果が大きく変わります。

論文では MMLU、PromptBench、HELM など50以上のベンチマーク（テスト問題集）が紹介されていましたが、 正直なところ、まだ深く理解できていません。

実務では、自分の業務に合ったテストケースを自作する のが良さそうだと感じました。

例：社内FAQ用プロンプトなら
- 「有給の申請方法は？」
- 「経費精算のやり方は？」
など、実際に聞かれそうな質問をテストケースにする

3. どんな採点方法で評価するか（How）

論文では、様々な評価方法が紹介されていました。

論文で紹介されていた評価方法

方法 説明 用途
正解率（Accuracy） 正解した数 ÷ 全体の数 正確性を測る
F1スコア 精度と再現率のバランス 分類タスクでの正確性を測る
BLEU / ROUGE 生成文と参照文の類似度 翻訳・要約の品質を測る
LLM-as-a-Judge 別のLLMに採点させる 主観的な品質を測る
人間評価 アノテーターが主観で評価 品質の細かい判断

F1スコアやBLEU/ROUGEなど様々な方法がありますが、 まずはシンプルな「正解率」から始めるのが手軽に始められそうだと感じました。

実際にテストする方法

では、具体的にどうやってテストすればいいのか。

論文では自動評価・人間評価・LLM-as-a-Judgeなどの方法が紹介されていましたが、 実務で始めやすい方法として、以下の2つに整理してみました。

方法1：手動でテストする

シンプルに、以下の流れでやります。

Step 1: テストケースを作る（入力と期待する出力のセット）
Step 2: プロンプトを実行する
Step 3: 正解/不正解を記録する
Step 4: 正解率を計算する

テストケースの例

入力 期待する出力 実際の出力 結果
1+1は？ 2 2 ✅
日本の首都は？ 東京 東京です ✅
水の化学式は？ H2O H2O ✅

スプレッドシートで管理するだけでも十分です。

方法2：ツールで自動化する

Microsoftが作った PromptBench というツールがあることを知りました。

PromptBenchでできること

  • プロンプトの正確性を自動テスト
  • プロンプトを自動で「変形」してロバスト性をテスト（タイポを入れる、言い換えるなど）
  • 複数のプロンプトを比較

GitHub: https://github.com/microsoft/promptbench

テストケースが多い場合や、本格的に評価したい場合は、こういったツールを使うと効率的そうです。

どれくらいテストすれば良いか？

調べてみると、「〇〇ケース以上」「〇〇%以上なら合格」という明確な基準はありませんでした。

論文にも具体的な数字は書いていなかったので、AIに聞いて目安を整理してみました。

注意： この数字は論文に書かれているわけではなく、AIに聞いた一例です。

まず試すときの目安

  • 正確性テスト：10〜20個のテストケースで大まかな傾向を掴む
  • ロバスト性テスト：3パターン程度の言い換え（ユーザーが自由入力する場合のみ）

目標正解率の決め方

「何%なら合格」は用途によって異なります。 リスクが低いツール（雑談ボット等）なら70%程度、リスクが高いツール（医療・金融等）なら95%以上など、用途に応じて決めると良さそうです。

学んだこと・気づき

1. 評価には整理された考え方がある

「What / Where / How」という3つの軸で整理できることを知れたのは大きかったです。

漠然と「テストしなきゃ」と思っていたのが、構造化できました。

2. プロンプトは意外と不安定

論文では、PromptBenchの結果として、現在のLLMは敵対的プロンプトに対して脆弱であり、文字レベル・単語レベル・文レベルでの攻撃で性能が低下すると述べられていました。

つまり、ちょっとした言い換えやタイポで結果が変わる可能性がある。

ロバスト性のテストは思った以上に重要だと感じました。

3.「正解」は自分で決める

「何%なら合格」という絶対的な基準はない。 用途とリスクを考えて、自分で決める必要がある。

これは当たり前のようで、意外と見落としていた視点でした。

AIツールを作る上でやるべきこと

今回の学びを踏まえて、AIツールを作る際にやるべきことを整理してみました。

事前準備

  • [ ] テストケースを作成する（実際に使う場面を想定した入力と期待出力）
  • [ ] 評価基準を決める（正解率〇〇%以上など）

テスト実施

  • [ ] プロンプトを実行してテストする
  • [ ] 正解率を計算する
  • [ ] 必要に応じてロバスト性をテストする（入力を少し変えて実行）

改善

  • [ ] 結果を見てプロンプトを改善する
  • [ ] 基準を満たすまで繰り返す

ツール設計で決めておくべきこと

プロンプトのテスト以前に、設計段階で決めておくべきことも見えてきました。

決めること 選択肢 影響
ユーザーに自由入力させるか Yes / No ロバスト性テストが必要かどうか
失敗時のリスク 低 / 中 / 高 必要な正解率の基準
出力形式 自由文 / 固定形式 評価のしやすさ

特に「ユーザーに自由入力させるか」は重要で、 固定のプロンプトが走る設計にすれば、ロバスト性を気にしなくてよくなります。

まとめ

プロンプトの評価方法を調べてみて、整理された考え方があることを知れました。

学んだこと

  • 評価は「What / Where / How」の3つの軸で考える
  • 正確性だけでなく、ロバスト性も重要
  • ロバスト性は設計（ユーザーに自由入力させるか）でも対策できる
  • 「何%なら良い」は用途によって自分で決める
  • PromptBenchなどのツールで自動化もできる

まだ実際に自分のプロンプトで本格的なテストはしていませんが、 まずは手動テストから始めて、必要に応じてPromptBenchも試してみようと思います。

参考リソース