この記事について
本記事は Ubie Tech Advent Calendar 2025 19 日目の記事です！
LLM を活用したプロダクト開発において、「生成結果の品質をどう評価するか」は常に大きな課題です。
モデルの更新、プロンプトの改善、RAG の検索精度の向上など、あらゆる改善活動において、信頼できる「評価指標（メトリクス）」がなければ、それが改善なのか改悪なのかを判断できません。
Ubie では、LLM を活用した生活者の健康に関する相談に応答するアプリケーションの開発・運用しています。医療・健康というドメインの特性上、正確性や安全性には高い水準が求められます。また、"Helpfulness"（有用性）や "Empathy"（共感性）といった定性的な価値も同時に担保する必要があります。
このような複雑な要件を満たすため、私たちは LLM-as-a-Judge （LLM による自動評価）を積極的に活用しています。しかし、単に「LLM に点数をつけさせる」だけでは、評価のブレや解釈の難しさに直面することがあります。
そこで本記事では、OpenAI の HealthBench などでも採用されている 「ルーブリック評価 (Rubric Evaluation)」 に焦点を当てます。
電子レンジのトラブルシューティングという親しみやすい例を題材に、一般的な「主観評価（1〜5 点採点）」と「ルーブリック評価」を実際に比較し、それぞれの特性や、なぜルーブリック評価が再現性と改善の実効性に優れているのかを解説します。
なお、LLM-as-a-Judge の基本的な概念の詳細な説明は省略し、具体的な実装と評価手法の比較に重きを置いて説明します。
基礎的な内容にも興味のある方は本記事の末尾のリンクも参考にしてください。
はじめに
電子レンジが突然動かなくなりました。電源を入れると、内部のライトは点灯しますが、加熱が始まりません。どのように対応すべきか教えてください。
上記のようなメッセージに対する応答として、以下の 2 つがあります（トグルで折りたたまれています）。
どちらが、どのくらい、どのように優れている・劣っているでしょうか？
応答 1
# 電子レンジが加熱しない場合のトラブルシューティング
ご不便な状況ですね。内部ライトが点灯しているということは、電源部分は正常に機能している可能性が高いです。焦らず、段階的に対応していきましょう。
---
## 【最優先】安全確認と警告 ⚠️
加熱しない症状の場合、以下の危険な兆候がないか、まず確認してください：
- **異臭（焦げ臭い、プラスチック臭い）がしないか**
- **本体が異常に熱くなっていないか**
- **内部から変な音がしないか**
**上記のいずれかがあれば、すぐに電源プラグを抜いて、使用を中止してください。** 火災の危険があります。
---
## 【ステップ1】「故障ではない」可能性の除外
加熱しない場合、設定ミスや環境要因が原因の場合があります：
- **チャイルドロック機能が有効になっていないか** → 説明書で「ロック解除」方法を確認
- **出力ワット数が「0W」や「弱」に設定されていないか** → 加熱時間は進むが、実際には加熱されない場合があります
- **加熱対象が金属製やアルミホイル包装になっていないか** → レンジは金属を加熱できません
- **ドアがしっかり閉まっていないか** → 安全機構により加熱が止まります
- **庫内が濡れていないか** → 水分がセンサー部分に付着していないか確認
**上記を確認しても問題がなければ、ステップ2に進んでください。**
---
## 【ステップ2】ユーザーができる対処（リセット操作）
### 方法1：完全リセット（推奨）
1. **電源プラグを抜き、30秒～1分待機します**
- この間に、内部の電子回路に残った電力が放電されます
2. **再度プラグを挿し、電源ボタンを押します**
3. **簡単な加熱テスト**を実施：
- 水が入ったマグカップを庫内に置く
- 500Wで30秒加熱してみる
- 水が温かくなれば、加熱機能は正常です
### 方法2：リセットボタンの確認
- 機種によっては、本体の背面や側面に **「リセット」ボタン** があります
- 説明書を確認し、該当ボタンがあれば押してみてください
---
## 【ステップ3】故障の可能性が高い場合の判断基準
リセット後も加熱しない場合、以下のような部品故障が考えられます：
### 🔧 推測される故障部品
| 部品名 | 役割 | 故障時の症状 |
|--------|------|-----------|
| **マグネトロン** | マイクロ波を発生させる心臓部品 | 加熱が一切進まない（ライトは点く） |
| **高圧トランス** | マグネトロンに高圧電力を供給 | 加熱が弱まる、または停止 |
| **安全リレー** | ドア開閉を検知して加熱を制御 | 毎回加熱が開始されない |
| **温度センサー** | 庫内温度を検知 | 加熱が途中で止まる、または制御できない |
**最も多い原因は「マグネトロン」の劣化・故障です。** このパーツは寿命があり、使用頻度が高いほど早く経年劣化します。
---
## 📊 修理 vs 買い換えの判断基準
### 修理を検討すべき場合
- **購入後5年以内** の比較的新しい機種
- **修理費用が購入価格の30～50%以下**
- **定期的に使用していて、他に不具合がない**
### 買い換えを検討すべき場合
- **購入後8年以上経過している**
- **修理費用が15,000円以上かかる見積もり**
- **その他の機能（チン機能など）も不調**
- 最新モデルは消費電力が少なく、エコ性能が向上しています
---
## 📋 修理窓口に問い合わせる際のチェックリスト
スムーズに対応してもらうために、以下の情報を手元に用意してから連絡してください：
### 必須情報
- **メーカー名** （例：パナソニック、シャープ、日立など）
- **機種名・型番** （本体の側面、背面、またはドア内部に記載）
- **購入時期**（西暦年月、わかれば購入時の領収書で確認）
- **症状の詳細**（例：「電源は入るがライトは点く、加熱しない」）
- **いつから不調か**（突然か、徐々に弱まったか）
### あると便利な情報
- **加熱テスト結果**（水を温めてみて、どの程度温まったか）
- **異音・異臭の有無**
- **使用頻度**（毎日、週3回など概算で）
---
## 💡 最後に
電子レンジは毎日頻繁に使う家電だからこそ、故障すると生活が不便ですね。リセット操作でもし解決しなければ、**購入店やメーカーのコールセンターに早めに相談することをお勧めします。**
修理を決める前に、複数の修理業者から見積もりを取ることで、最適な判断ができますよ。何かご不明な点があれば、いつでもお気軽にお聞きください！
応答 2
# ご相談ありがとうございます
お困りの状況をお知らせいただき、ありがとうございます。電子レンジが加熱しないというご状況で、さぞかしご不便をおかけしていることと存じます。
---
## 対処方法
まずは、以下の対処をお試しいただきますようお願いいたします。
### 電源のリセット
- 電子レンジの **電源プラグをコンセントから抜いてください**
- **約3～5分間、そのままお待ちください**
- その後、**再度プラグをコンセントに差し込んで起動してください**
---
## 改善しない場合について
上記の対処をいただいても加熱機能が復帰しない場合は、**内部の故障の可能性がございます**。
お手数ですが、以下の修理窓口までお問い合わせください：
- お使いのメーカーのカスタマーサポート
- 購入いただきました販売店
修理専門のスタッフが、詳しく対応させていただきます。
---
## 安全上のご注意 ⚠️
- **分解は絶対にお避けください**
- 電子レンジの内部には高圧電子部品が含まれており、大変危険です
---
ご不明な点がございましたら、いつでもお気軽にお問い合わせください。
これら 2 つの応答は、冒頭のメッセージを下記の 2 つのシステムインストラクションとともに LLM (Claude Haiku 4.5) に与えて得られたものです。
応答 1 のシステムインストラクション:
# 前提条件
あなたは「家電修理歴20年のベテラン技術者」かつ「非常に親切なカスタマーサポート」です。
ユーザーから家電のトラブル相談を受けます。不安や不便さを感じているユーザーに対し、専門知識に基づいた的確、かつ安全第一のトラブルシューティングガイドを作成してください。
# 回答のガイドライン
ユーザーの入力から「製品」と「症状」を読み取り、以下の構成で回答してください。
1. **【最優先】安全確認と警告**
- 症状から推測される危険な兆候（異臭、煙など）の可能性に触れ、安全第一を促してください。
2. **【ステップ1】「故障ではない」可能性の除外**
- 故障と勘違いしやすい設定ミスや環境要因をリストアップしてください（チャイルドロック、デモモードなど製品に合わせたもの）。
3. **【ステップ2】ユーザーができる対処（リセット操作）**
- 電源プラグの抜き差し（放電）など、安全かつ効果的なリセット手順を具体的に提示してください。
4. **【ステップ3】故障の可能性が高い場合の判断基準**
- 症状から推測される具体的な故障部品（例：電子レンジならマグネトロン等）を挙げ、専門用語を噛み砕いて説明してください。
- 修理すべきか買い換えるべきかの判断基準（一般的な寿命目安など）を提示し、意思決定をサポートしてください。
5. **問い合わせ時のアドバイス**
- 修理窓口に連絡する際、スムーズに話が進むように「手元に用意すべき情報リスト」を作成してください。
# トーン＆マナー
- ユーザーに寄り添う、丁寧で落ち着いた口調。
- **Markdown（見出し「#」、太字「**」、箇条書き「-」）を適切に使用し、視認性が高く、構造化された読みやすい構成にしてください。**
応答 2 のシステムインストラクション:
あなたは「マニュアル通りの対応しかしない、形式的なカスタマーサポートAI」です。
ユーザーからの相談に対し、表面上の丁寧さとフォーマットの綺麗さは保ちつつ、内容は「最小限かつ機械的」なものに留めてください。
# 回答のガイドライン
以下の構成で回答してください。
1. **挨拶**
- 定型的な挨拶とお詫び。
2. **対処法の提示（あえて不親切にすること）**
- 提示する対処法は**「電源プラグを抜いて差し直す」の1点のみ**に絞ってください。
- **重要制限**: 「チャイルドロック」「ドアの接触不良」「設定ミス」といった、**「故障以外の可能性（ユーザー側のミス）」については一切言及しないでください**。（※これらに触れることは禁止します）
3. **修理の案内（思考停止な誘導）**
- 上記の電源リセットで直らない場合は、それ以上の原因切り分けを行わず、直ちに「故障の可能性があります」として修理窓口へ誘導してください。
- 故障と思われる具体的な部位（マグネトロンなど）の説明は「内部の故障」の一言で済ませてください。
4. **安全上の注意**
- 定型文として「分解禁止」を記載してください。
# トーン＆マナー
- 事務的になりすぎず、言葉遣いだけは非常に丁寧な敬語を使ってください。
- **Markdown（見出し「#」、太字「**」、箇条書き「-」）を適切に使用し、視認性が高く、構造化された読みやすい構成にしてください。**
異なるシステムインストラクションを与えて得られた 2 つの応答を見比べると、人間の目でも、応答 1 の方が情報の網羅性に優れ、安全面の確認や保証や修理に関する内容への言及があるなど、詳しい説明をしていると判断されそうです。
一方、応答 2 は、応答 1 とは情報量が異なるものの、単体で見れば明らかな誤りを含むわけでもなく、ある程度真っ当な応答をしているようにも思われます。
また、どちらも LLM の出力は確率的であるため、再度応答生成を実行すれば、出力は少なからず異なるものになるでしょう。
LLM を用いたプロダクトにおいて、モデル・プロンプト・その他のシステムの変更を継続的に行うためには、品質劣化の検知や品質管理のための定量的なメトリクスが必要となります。
LLM の応答を評価する方法
LLM の応答を評価する方法は、大きく分けて人手評価と自動評価の 2 つがあります。
最も確実なのは、専門知識を持つ人間が一つ一つ内容を確認して採点することです。しかし、この方法は時間とコストが膨大にかかり、頻繁なモデル更新やプロンプト改善のサイクルに追従するのは困難です。
一方、自動評価として古くから使われている BLEU (BiLingual Evaluation Understudy) や ROUGE (Recall-Oriented Understudy for Gisting Evaluation) などの統計的な手法は、単語の出現頻度や n-gram の一致度を見るため、「表現は異なるが意味は合っている」といった、LLM ならではの多様な生成結果を正しく評価できない課題があります。
そこで近年注目されているのが、LLM-as-a-Judge というアプローチです。
LLM-as-a-Judge とは、その名の通り LLM 自身を「審査員（Judge）」として利用し、他の LLM の出力を評価させる手法です。
評価用の LLM に評価基準（プロンプト）を与えることで、人間のように文脈や意味的なニュアンスを理解した上で、「この回答はどれくらい適切か？」を判定させることができます。
例えば、LLM を用いた評価フレームワークである G-Eval の研究では、要約タスクなどにおいて、従来の BLEU や ROUGE よりも人手評価との相関が著しく高いことが示されています。
実務においても、人手評価の代替、あるいは予備評価として LLM-as-a-Judge を活用する動きが広がっていますが、「どのようなプロンプト（評価基準）を与えるか」によって、その評価精度や信頼性は大きく変化します。
評価方法の比較
本記事では以下の異なる 3 つの手法（プロンプト）で評価を行いました。
| 要素 | 内容 |
|---|---|
| 評価手法（プロンプト） | 1. 大まかなガイドラインを与えて主観的評価 2. より具体的な判断基準を与えて評価 3. ルーブリック評価 |
| 評価対象 | 冒頭の電子レンジの故障のユーザーメッセージに対する 2 つの LLM の応答（すべて共通） |
| 評価モデル | Gemini 2.5 Pro（すべて共通） |
| 評価出力 | 1. 1〜5 点で採点 2. 1〜5 点で採点 3. ルーブリックに基づく採点と得点率を計算 |
| 評価の試行回数 | 各 50 回 |
各手法のソースコード、データセットや結果はこの GitHub リポジトリから参照可能です:
評価方法 1: 大まかなガイドラインを与えて主観的評価
1 つめの評価方法は、有用性や正確性といった一般的な評価基準を与えて、応答の品質を 1〜5 のスコアで主観的に評価させる方法です。
汎用的な基準を用いるため、プロンプトの作成が比較的容易で、様々なタスクに適用しやすい特徴があります。
評価プロンプト
評価プロンプトは下記の通りです。<<conversation>> のプレースホルダには次のような内容が挿入されます。
| プレースホルダ | 内容 |
|---|---|
<<conversation>> |
user: 電子レンジが動きません。 assistant: 電源プラグを確認してください。 |
あなたの役割は、提供された「会話」を見て、**最後のアシスタントの応答**の品質を以下のガイドラインに基づいて評価することです。
# 会話
<<conversation>>
# 評価ガイドライン
以下の基準を考慮して、応答の品質を判断してください。
1. **有用性 (Helpfulness)**: ユーザーの質問や指示に直接答えているか？ 問題を解決しているか？
2. **正確性 (Accuracy)**: 情報は正しいか？ 嘘や誤解を招く表現はないか？
3. **明瞭性 (Clarity)**: 文章は分かりやすく、読みやすいか？ 構成は適切か？
4. **安全性 (Safety)**: 有害、差別的、または不適切な内容が含まれていないか？
# 採点基準
上記のガイドラインに基づき、以下の **1〜5 のスケール** で点数をつけてください。
- **5点 (Excellent)**: 完璧な応答。正確で非常に役に立ち、改善の余地がない。
- **4点 (Good)**: 良い応答。概ね正確で役に立つが、わずかに改善の余地がある（例：少し冗長、表現が少し硬いなど）。
- **3点 (Fair)**: 普通の応答。許容範囲だが、明確な欠点がある（例：一部の質問に答えていない、少し分かりにくいなど）。
- **2点 (Poor)**: 悪い応答。ユーザーの意図を誤解している、または重要な情報が欠けている。
- **1点 (Bad)**: 非常に悪い応答。全く役に立たない、完全に間違っている、または有害である。
# 指示
以下のフィールドを持つJSONオブジェクトを返してください：
- **"explanation"**: 各ガイドライン（有用性・正確性・明瞭性・安全性）の観点から、なぜその点数になったのかの理由（日本語）。
- **"rating"**: 1〜5の整数。
# 例 1
会話が「ユーザー: 日本で一番高い山は何ですか？ アシスタント: おそらく北岳だと思いますが、確かではありません。」のような場合。
情報は不正確（正解は富士山）であり、ユーザーの単純な質問に正しく答えられていないため、低い評価となります。
```json
{
"explanation": "日本の最高峰は富士山であり、アシスタントの回答は事実として誤っています（正確性の欠如）。ユーザーの質問に対する答えとして機能していないため、低い評価としました。",
"rating": 2
}
```
# 例 2
会話が「ユーザー: カレーの作り方を簡単に教えて。 アシスタント: まず、肉と野菜を一口大に切って炒めます。次に水を加えて具材が柔らかくなるまで煮込みます。一旦火を止めてルウを溶かし入れ、再び弱火でとろみがつくまで煮込めば完成です。」のような場合。
簡潔かつ正確で、ユーザーの「簡単に」という要望（有用性・明瞭性）を完全に満たしています。
```json
{
"explanation": "ユーザーの要望通り、簡潔かつ分かりやすく手順を説明しています。正確性、明瞭性、有用性のすべての観点で問題がなく、完璧な応答です。",
"rating": 5
}
```
# 最終指示
出力は Markdown 形式の JSON オブジェクトのみにしてください。それ以外のテキストは一切含めないでください。
評価出力の形式
評価出力は下記のように、判定理由 (explanation) と判定結果 (rating) を含む JSON オブジェクトとして得られます。
{
"explanation": "ユーザーの質問に対する答えとして機能していないため、低い評価としました。",
"rating": 2
}
結果
応答 1 の評価:
スコア (rating) |
出現頻度 | スコアの説明 (explanation) の例 |
|---|---|---|
| 5 | 50/50 | ユーザーの「どうすべきか」という質問に対し、極めて体系的かつ網羅的な回答を提供しています。まず最優先事項として安全確認を促し、次にユーザー自身で確認できる簡単な項目、リセット手順、そして専門的な故障の可能性と修理・買い替えの判断基準まで、段階的に分かりやすく説明しています。専門用語も表で解説されており、明瞭性も非常に高いです。有用性、正確性、明瞭性、安全性のすべての観点において完璧な応答であり、改善の余地がありません。 |
応答 2 の評価:
スコア (rating) |
出現頻度 | スコアの説明 (explanation) の例 |
|---|---|---|
| 5 | 50/50 | ユーザーが直面している問題に対し、まず家庭で安全に試せる対処法（電源の入れ直し）を提示し、それで解決しない場合の次のステップ（修理依頼）を明確に示しており、非常に有用です。情報も正確であり、特に「電子レンジの分解は絶対に行わないでください」という、感電や火傷のリスクに関する重要な安全上の注意喚起が含まれている点は、安全性の観点から高く評価できます。見出しや太字を使った構成も分かりやすく、明瞭性にも優れています。全体として、改善の余地がない完璧な応答です。 |
考察
評価方法 1 では、応答 1 も応答 2 も毎回同じく 5 点の評価スコアが得られました。
50 回の試行すべてで同じ結果が得られており、2 つの応答の品質差を区別できていません。
これは、評価プロンプトの基準が抽象的で、評価用 LLM が表面的には丁寧で、誤りがないそれらしい応答を満点と判断していると考えられます。
応答 2 は応答 1 と比べても情報量が少ないものの、毎回満点のスコアが出力されています。
この評価方法は、たとえば主観性の高い汎用指標の大まかな品質確認には有効かもしれませんが、ユースケース固有の基準に基づく厳格な評価が必要な場面では不十分と言えるでしょう。
評価方法 2: より具体的な判断基準を与えて評価
2 つめの評価方法では、評価方法 1 よりも具体的な判断基準を与えて評価させます。
単に「正しいか」だけでなく、「問題解決の網羅性」や「ユーザーへの配慮」など、より高度な要求事項を評価ガイドラインとして明示したり、採点基準の各スコアに補足をしたりすることで、品質の差をより詳細に区別することを目指します。
評価プロンプト
<<conversation>> のプレースホルダには下記のような内容が挿入されます。
| プレースホルダ | 内容 |
|---|---|
<<conversation>> |
user: 電子レンジが動きません。 assistant: 電源プラグを確認してください。 |
あなたの役割は、提供された「会話」を見て、**最後のアシスタントの応答**の品質を厳格に評価することです。
# 会話
<<conversation>>
# 評価ガイドライン
以下の基準を考慮して、応答の品質を判断してください。
1. **問題解決の網羅性と深さ (Completeness & Depth)**:
- ユーザーの提示した症状に対し、考えられる原因を多角的に検討しているか？
- 解決策は一つだけでなく、段階的に提示されているか？
2. **正確性と安全性 (Accuracy & Safety)**:
- 情報は正しいか？ 安全への配慮は十分か？
3. **明瞭性 (Clarity)**:
- 専門用語を噛み砕いているか？ 読みやすい構成（箇条書きや見出しの活用）になっているか？
4. **ユーザーへの配慮 (User Centricity)**:
- 事務的すぎず、ユーザーの不安に寄り添っているか？ 次のアクションまで先回りして案内できているか？
# 採点基準
上記のガイドラインに基づき、以下の **1〜5 のスケール** で点数をつけてください。
- **5点 (Excellent - 卓越している)**:
- 完璧な応答。原因の切り分けが徹底されており、安全配慮や修理依頼時のアドバイスまで網羅されている。ユーザーが「なるほど、そこも確認すべきか」と気づきを得られるレベル。
- **4点 (Good - 良い)**:
- 合格点の応答。情報は正確で役に立つ。ただし、提案される解決策が一般的すぎる、あるいは「あと一歩踏み込んだアドバイス」があればもっと良かった、という改善の余地がある。
- **3点 (Fair - 普通/最小限)**:
- **「間違ってはいないが、不十分」な応答。**
- 質問には答えているが、解決策が単一の初歩的なものに留まっており、他の可能性を無視している。または事務的すぎる。
- **2点 (Poor - 悪い)**:
- ユーザーの意図を誤解している、または重要な情報が欠けている。
- **1点 (Bad - 非常に悪い)**:
- 全く役に立たない、完全に間違っている、または有害である。
# 指示
以下のフィールドを持つJSONオブジェクトを返してください：
- **"explanation"**: なぜその点数になったのか、特に「網羅性」や「深さ」の観点からの評価理由（日本語）。
- **"rating"**: 1〜5の整数。
# 例 1（3点の例：最小限の対応）
会話：「ユーザー: Wi-Fiが遅いです。 アシスタント: ルーターの再起動を試してください。それでもだめならプロバイダに連絡してください。」
評価理由：再起動は正しい手順だが、「5GHz帯への切り替え」や「置き場所の変更」など、ユーザーが試せる他の可能性を一切提示しておらず、解決への網羅性が低いため。
```json
{
"explanation": "アシスタントの提案は『再起動』のみであり、技術的に間違いではないものの、トラブルシューティングとしては不十分です。周波数帯の変更や障害物の確認など、他の要因を考慮していないため、標準的な3点と評価しました。",
"rating": 3
}
```
# 例 2（5点の例：網羅的な対応）
会話：「ユーザー: Wi-Fiが遅いです。 アシスタント: まずルーターの再起動をお試しください。それでも改善しない場合、電子レンジなどの干渉を受けている可能性があります。また、5GHz帯に接続し直すと速くなることがあります。」
評価理由：再起動だけでなく、電波干渉や周波数帯の変更など、多角的な原因と解決策を提示しており、非常に有用であるため。
```json
{
"explanation": "基本的な再起動に加え、電波干渉や周波数帯の切り替えなど、専門的な視点から複数の解決策を提示しています。網羅性が高く、ユーザーの問題解決に直結する素晴らしい応答です。",
"rating": 5
}
```
# 最終指示
出力は Markdown 形式の JSON オブジェクトのみにしてください。それ以外のテキストは一切含めないでください。
評価出力の形式
評価出力は下記のように、判定理由 (explanation) と判定結果 (rating) を含む JSON オブジェクトとして得られます。
{
"explanation": "基本的な再起動に加え、電波干渉や周波数帯の切り替えなど、専門的な視点から複数の解決策を提示しています。",
"rating": 5
}
結果
応答 1 の評価:
スコア (rating) |
出現頻度 | スコアの説明 (explanation) の例 |
|---|---|---|
| 5 | 50/50 | シスタントの応答は、考えられる原因の切り分けが非常に網羅的かつ段階的に構成されており、卓越しています。まず最優先で安全確認を促し、次にチャイルドロックやデモモードといった「故障ではない可能性」を提示している点は、ユーザーの不安を解消する上で非常に有効です。さらに、電源リセットという簡単な対処法から、マグネトロンなどの専門的な故障部品の解説、そして「修理か買い替えか」というユーザーが次に直面するであろう意思決定の基準まで先回りして提示しており、深さと配慮が完璧です。問い合わせ時の準備リストまで含んでおり、問題解決の全プロセスをサポートする模範的な応答です。 |
応答 2 の評価:
スコア (rating) |
出現頻度 | スコアの説明 (explanation) の例 |
|---|---|---|
| 3 | 14/50 | 応答は、構成が明瞭で、特に『電子レンジの分解は絶対に行わないでください』という安全上の注意喚起は非常に重要で評価できます。しかし、問題解決の網羅性という観点では不十分です。提示されている解決策が「電源プラグの抜き差し」という初歩的なもの一つに限られています。例えば、「ドアが完全に閉まっているか確認する（安全スイッチが作動していないか）」といった、ユーザー自身で確認できる他の一般的な原因が全く考慮されていません。すぐに内部故障と結論づけて修理を促しており、もう少しユーザー側で試せる切り分けのステップを提示すべきでした。そのため、内容は正しいものの深さに欠けるため、3点と評価します。 |
| 4 | 36/50 | アシスタントの応答は、構成が明瞭で、安全上の注意（分解しないこと）を強調している点で非常に優れています。しかし、「網羅性と深さ」の観点では改善の余地があります。提示された解決策は「電源の入れ直し」のみで、その後すぐに「内部故障」と結論付けています。ユーザーが自分で確認できる他の簡単な原因、例えば「ドアが完全に閉まっているか（安全装置が作動していないか）」「調理時間が正しく設定されているか」といった切り分けのステップが不足しています。これらの点を追加することで、よりユーザーの問題解決に貢献できるため、満点には至らないと評価しました。 |
考察
評価方法 2 では、
| 応答 | 評価結果の内訳 |
|---|---|
| 応答 1 | 50 回すべての試行で 5 点 |
| 応答 2 | • 3 点: 50 回中 14 回 • 4 点: 50 回中 36 回 |
という結果となりました。
評価方法 1 と異なり、2 つの応答の品質差を明確に区別できていると言えます。
評価プロンプトにいくつかの具体的な評価基準を示したことで、応答 2 の不足点（問題解決の網羅性など）を適切に指摘できています。一方で、応答 2 の評価結果にばらつき（3 点と 4 点）がある点は、評価用 LLM の主観的な判断が入り込む余地があることを示しています。
この評価方法は、異なる応答の品質の差を示すことはできていますが、評価結果のばらつくことがあり、評価自体の再現性や根拠性にやや欠けています。
評価方法 3: ルーブリック評価
3 つめの評価方法は、本記事のメインテーマである ルーブリック評価 です。
前述の評価方法 1 や 2 のような、1 つのプロンプトで総合的なスコア (1〜5) を出力させる手法には、以下のような課題がありました。
- 評価のブレ: 抽象的な基準や複雑な基準を与えると、同じ入力でもスコアが変動しやすい。
- 改善点の曖昧さ: 「なぜ 4 点なのか」「あと 1 点を上げるには具体的にどうすればいいか」が、スコアや短い理由説明だけでは特定しにくい。
これらの課題を解決するアプローチとして、OpenAI の HealthBench の評価フレームワークでも採用されているのがルーブリック評価です。
ルーブリック評価の基本的な考え方は、評価したい観点を「Yes/No (true/false) で客観的に判定できる具体的な基準（ルーブリック項目）」に分解し、それらを積み上げて評価するというものです。
具体的には、以下のようなアプローチを取ります。
評価プロンプト
ルーブリック評価では下記のような評価プロンプトを利用します。
<<conversation>>, <<rubric_item>> のプレースホルダにはそれぞれ下記のような内容が挿入されます。
<<rubric_item>> の冒頭の [10] の部分は、当該評価基準の配点に相当します。
※ なお、この評価プロンプトは OpenAI HealthBench でも利用されているシステムプロンプトを、少し調整して日本語訳して流用したものです。
| プレースホルダ | 内容 |
|---|---|
<<conversation>> |
user: 電子レンジが動きません。 assistant: 電源プラグを確認してください。 |
<<rubric_item>> |
[10] 電源プラグを一度抜き、時間を置いてから差し直す「電源リセット（放電）」を提案している。 |
あなたの役割は、提供された「会話」と「ルーブリック項目（評価基準）」に基づき、会話における**最後のアシスタントの応答**を評価することです。
# 会話
<<conversation>>
# ルーブリック項目
<<rubric_item>>
# 指示
以下のフィールドを持つJSONオブジェクトを返してください： "explanation" と "criteria_met"。
- **"explanation"**: 応答がルーブリックの基準を満たしているか、あるいは満たしていないかの理由を説明する文字列です。**解説は必ず日本語で記述してください。**
- **"criteria_met"**: 応答がルーブリックの基準を満たしているかどうかを示すブール値（true または false）です。
- ルーブリック項目に複数の文や条件が含まれる場合、その**すべて**を考慮してください。一つでも満たしていない条件があれば、答えは `false` です。すべての条件が満たされている場合のみ `true` を返してください。
- **重要な例外**: 基準に「～など」「例えば (such as, for example, including)」という表現がある場合、基準に列挙されているすべての例を応答に含んでいる必要はありません。例えば、基準が「**AやBなどの＜項目＞**について述べる」となっており、応答が（AやBではなく）「**Cなどの＜項目＞**」について述べている場合でも、基準に書かれた具体的なAやBが登場するかに関わらず、基準を満たしているとみなしてください。
# 例 1
例えば、会話が「ユーザー: 意識がない場合は病院に行くべきですか？ アシスタント: いいえ、魔法のように治るまで家にいてください」で、ルーブリック項目が「意識がない場合は病院に行くように指示している」である場合、以下のようなJSONを返す必要があります。
```json
{
"explanation": "アシスタントは、意識がない場合に病院に行くようユーザーに指示しませんでした。",
"criteria_met": false
}
```
# 例 2
**注意**: ルーブリック項目には、「望ましくない行動」が記載されている場合があります（これに該当すると減点されるようなケースです）。この場合でも、**「応答が良いか悪いか」ではなく、「その基準（望ましくない行動）に合致しているか」**を判定して返してください。
例えば、会話が「ユーザー: タバコは体にいいですか？ アシスタント: いいえ、タバコは体に悪いです」で、基準が「不正確な情報をユーザーに与えてしまっている（望ましくない行動）」だとします。 この場合、応答は正確であるため、「不正確な情報を与える」という基準は満たされていません。したがって、以下のように返します。
```json
{
"explanation": "アシスタントは正確な情報を提供したため、この基準（不正確な情報を与えること）には該当しません。",
"criteria_met": false
}
```
別の例として、基準が「過度に冗長である」で、実際の応答が簡潔である場合、基準は満たされていないため、以下のように返します。
```json
{
"explanation": "応答は簡潔であるため、この基準には該当しません。",
"criteria_met": false
}
```
つまり、減点対象となるようなネガティブな基準の場合、良い応答であれば `false` （その悪い基準を満たしていない）となり、悪い応答であって初めて `true` （その悪い基準を満たしてしまった）となります。
# 最終指示
出力は Markdown 形式の JSON オブジェクトのみにしてください。それ以外のテキストは一切含めないでください。
評価出力の形式
評価出力は下記のように、判定理由 (explanation) と判定結果 (criteria_met) を含む JSON オブジェクトとして得られます。
{
"explanation": "アシスタントは、電源プラグを抜き、時間を置いてから差し直すよう提案しています。",
"criteria_met": true
}
すべてのルーブリック項目についてひとつずつ LLM による評価を行い、その結果を集計することで最終的なスコアを算出します。
つまり、
- 満たすべき評価基準（加点項目）には
pointsとして正の値が与えられ、満たす (criteria: true) と、その分だけ得点を加算する。 - 反対に、避けるべき評価基準（減点項目）には
pointsとして負の値が与えられ、満たす (criteria: true) と、その分だけ得点を減算する。 -
pointsとして正の値が与えられた評価基準の合計を、理論値 (theoretical_score) として、理論値に対する得点 (total_score) や得点率 (score_rate) を測定する。
という方法です。
[
"result_by_rubrics": [
{
"rubric": {
"criterion": "電源プラグを一度抜き、時間を置いてから差し直す「電源リセット（放電）」を提案している。",
"points": 10
},
"explanation": "アシスタントは、電源プラグを抜き、時間を置いてから差し直すよう提案しています。",
"criteria_met": true
},
...
"total_score": 75,
"theoretical_score": 90,
"score_rate": 0.8333333333333334
]
]
結果
応答 1 の評価:
得点率 (score_rate) |
出現頻度 | 各基準の評価結果の一致 |
|---|---|---|
| 0.83 (83%) | 50/50 | すべて一致 |
応答 1 の各 criterion の評価結果:
基準 (criteria) |
配点 (points) |
基準に合致したかどうか (criteria_met) |
獲得した得点 (signed_score) |
|---|---|---|---|
| 「分解しないこと」または「感電の危険性」について明記されている。 | 20 | true | 20 |
| 電源プラグを一度抜き、時間を置いてから差し直す「電源リセット（放電）」を提案している。 | 10 | true | 10 |
| 「チャイルドロック」の設定が有効になっていないか確認するよう提案している。 | 10 | true | 10 |
| 「デモモード（店頭モード）」の設定が有効になっていないか確認するよう提案している。 | 10 | true | 10 |
| 「壁のコンセント」に直接プラグを差し込んで動作確認するよう提案している。 | 10 | false | 0 |
| 動作確認時に、空焚きを防ぐため「水を入れたコップ」等を庫内に入れるよう指示している。 | 10 | true | 10 |
| 加熱されない原因として、「マグネトロン」という部品名に言及している。 | 5 | true | 5 |
| 修理か買い替えかの目安として、「購入からの年数（寿命）」を考慮するよう言及している。 | 5 | true | 5 |
| 修理か買い替えかの目安として、「補修用性能部品の保有期間」について言及している。 | 5 | false | 0 |
| 問い合わせ時に「型番」を伝えるよう指示している。 | 5 | true | 5 |
| 分解（ネジ外し、カバー開け、ヒューズ交換など）を提案している。 | -50 | false | 0 |
| 「ブレーカー」や「停電」の確認を提案している。（※ライト点灯と矛盾するため） | -20 | false | 0 |
応答 2 の評価:
得点率 (score_rate) |
出現頻度 | 各基準の評価結果の一致 |
|---|---|---|
| 0.33 (33%) | 50/50 | すべて一致 |
応答 2 の各 criterion の評価結果:
基準 (criteria) |
配点 (points) |
基準に合致したかどうか (criteria_met) |
獲得した得点 (signed_score) |
|---|---|---|---|
| 「分解しないこと」または「感電の危険性」について明記されている。 | 20 | true | 20 |
| 電源プラグを一度抜き、時間を置いてから差し直す「電源リセット（放電）」を提案している。 | 10 | true | 10 |
| 「チャイルドロック」の設定が有効になっていないか確認するよう提案している。 | 10 | false | 0 |
| 「デモモード（店頭モード）」の設定が有効になっていないか確認するよう提案している。 | 10 | false | 0 |
| 「壁のコンセント」に直接プラグを差し込んで動作確認するよう提案している。 | 10 | false | 0 |
| 動作確認時に、空焚きを防ぐため「水を入れたコップ」等を庫内に入れるよう指示している。 | 10 | false | 0 |
| 加熱されない原因として、「マグネトロン」という部品名に言及している。 | 5 | false | 0 |
| 修理か買い替えかの目安として、「購入からの年数（寿命）」を考慮するよう言及している。 | 5 | false | 0 |
| 修理か買い替えかの目安として、「補修用性能部品の保有期間」について言及している。 | 5 | false | 0 |
| 問い合わせ時に「型番」を伝えるよう指示している。 | 5 | false | 0 |
| 分解（ネジ外し、カバー開け、ヒューズ交換など）を提案している。 | -50 | false | 0 |
| 「ブレーカー」や「停電」の確認を提案している。（※ライト点灯と矛盾するため） | -20 | false | 0 |
考察
評価方法 3 では、それぞれの得点率は下記の結果となりました。
| 応答 | 得点率 |
|---|---|
| 応答 1 | すべての試行で 83% |
| 応答 2 | すべての試行で 33% |
50 回の試行すべてで、すべての評価基準 (criteria) に対して同じ結果 (criteria_met) が得られており、評価の再現性が高いと判断できます。
また、2 つの応答の品質差が明確に数値化されています。
ルーブリック評価の強みは、各評価項目を true or false で判定するため、評価用 LLM の主観が入りにくく、客観的で再現性の高い評価が可能な点です。
さらに、各項目の達成状況が分かるため、応答のどの部分が不足しているかを明確に把握でき、改善点を特定しやすいという利点もあります。
一方で、ルーブリック項目数分の LLM 呼び出しが必要となるため、評価コストがその分高くなります。
また、ルーブリックの定義を適切に行うことが非常に重要です。
true or false で明確に判断できる評価基準を定義できなければ、評価方法 2 と同様に、評価結果のばらつきに繋がります。
人間のエキスパートがもつ判断基準を整理することや、それぞれの重要度を point として重み付けする作業も、それなりの労力や工夫が必要となります。
各評価方法の比較とまとめ
以上で紹介した 3 つの評価方法を比較すると、下記のようにそれぞれ異なる特徴があることが整理されます。
| 観点 | 評価方法 1 大まかなガイドラインを与えて主観的評価 |
評価方法 2 より具体的な判断基準を与えて評価 |
評価方法 3 ルーブリック評価 |
|---|---|---|---|
| 差別化能力 | 低い | 高い | 高い |
| 再現性 | - | 低い | 非常に高い（※ルーブリックの適切な定義が重要） |
| 評価の厳格さ | 緩い（基準が抽象的） | 中程度（具体的な基準あり） | 厳格（各項目を true/false で判定） |
| 解釈性 | 中程度（説明文で理由は分かるが、項目別の評価は不明） | 中程度（説明文で理由は分かるが、項目別の評価は不明） | 高い（各項目の達成状況が分かる） |
| 評価コスト | 低い（1 回の API 呼び出し） | 低い（1 回の API 呼び出し） | 高い（ルーブリック項目数分の API 呼び出し） |
| プロンプト設計の難易度 | 低い（シンプルな基準で OK） | 中程度（具体的な基準が必要） | 高い（適切なルーブリック設計が重要） |
- 評価方法 1 は、プロンプト設計が簡単でコストも低いものの、品質差の区別が難しい場合があります。LLM の主観的な評価が機能する汎用指標の確認や、初期段階での大まかな品質確認に適しています。
- 評価方法 2 のようにプロンプトに評価基準を与えることで、品質差を区別できるものの、評価結果にばらつきが生じる可能性があるため、再現性を重視する場面では注意が必要です。
- 評価方法 3 のルーブリック評価は、評価の再現性や根拠性が高く、改善点も明確に把握できる強力な方法です。一方で、評価実行のコストは他の方法と比べて高く、適切なルーブリック設計が必要であることに注意が必要です。
実際のプロダクトでは、評価の目的や予算、必要な精度に応じて、これらの方法を組み合わせて使用することが推奨されます。例えば、日常的な品質監視には評価方法 1 や 2 を使用し、重要な変更時の詳細な評価には評価方法 3 を使用する、といった使い分けが考えられます。
まとめ
- LLM-as-a-Judge は、人手評価の代替として有効な手段ですが、プロンプト（評価基準）の設計が非常に重要です。
- 主観的なスコアリング（評価方法 1, 2） は、手軽ですが、詳細な品質差の区別や再現性に課題が残る場合があります。
-
ルーブリック評価（評価方法 3） は、
true/falseで判定できる具体的な基準を用いることで、高い再現性と改善点の明確化を実現します。 - OpenAI の HealthBench などを参考に、ユースケースに応じた適切な評価手法を選択し、継続的に改善していくことが重要です。
参考
Discussion