{“design_pattern”: “LLM-as-a-judge-optimization”, “techniques”: [“Rubric-based Scoring”, “Form-filling Pattern”, “Chain-of-Thought”, “Structured-Output”], “target_model”: “Gemini 1.5 Pro / GPT-4o”, “version”: “1.0”}
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
LLM-as-a-Judgeの精度を最大化する「評価用ルーブリック＋フォーム回答型」プロンプト設計
【ユースケース定義と課題】
LLMの回答品質を一定基準で自動採点したいが、評価がブレたり根拠が薄かったりする課題を、構造化された評価ルーブリックとフォーム入力形式で解決する。
入力型：評価対象のプロンプトと回答（Markdown/Text）
出力型：構造化された評価レポート（JSONまたはMarkdownフォーム）
【プロンプト設計のループ】
graph TD A["ルーブリック定義"] --> B["評価フォームの構築"] B --> C["CoTによる推論実行"] C --> D["出力のパースと検証"] D -->|不整合発見| A
ルーブリック定義: 採点基準を曖昧な言葉ではなく「1〜5点の具体的状態」として定義する。
フォーム構築: 評価者に「点数」を先に書かせず、「証拠」を先に書かせる構造を作る。
CoT実行: 評価の根拠となる思考プロセスを明示的に出力させる。
検証: 評価理由とスコアに矛盾がないか、JSONスキーマに従っているかを確認する。
【プロンプトの実装案】
以下のプロンプトは、評価のバイアス（中心化傾向など）を防ぐために「思考の順序」を強制しています。
# Role あなたは高品質な技術ドキュメントの校閲者であり、LLMの回答を客観的に評価するエキスパート評価者です。 # Evaluation Rubric (指標: 正確性) - 5点 (Excellent): 誤りが一切なく、最新の技術動向に合致し、補足情報まで完璧である。 - 3点 (Good): 主要な事実に誤りはないが、一部説明が不十分、または冗長である。 - 1点 (Poor): 明らかな事実誤認が含まれる、または質問の意図を理解していない。 # Task Instructions 以下の手順に従い、[Target Response] を評価してください。 1. **証拠の抽出**: 回答の中から、評価の根拠となる具体的な記述を抜き出す。 2. **分析**: ルーブリックの基準に照らし合わせ、証拠がどのレベルに該当するか論理的に説明する。 3. **最終スコア**: 1〜5の整数でスコアを付与する。 # Evaluation Form (この形式で回答してください) [Evidence]: [Reasoning]: [Final Score]: [Improvement Suggestion]: # Target Response (ここに評価対象のテキストを挿入)
【評価指標と誤り分析】
自動評価の信頼性を担保するために、以下の観点で評価プロセスを検証します。
| 評価指標 | 失敗パターン（リスク） | 対策 |
|---|---|---|
| 整合性 (Alignment) | 評価文では「ひどい」と言いつつスコア「4」をつける | 思考プロセス（Reasoning）をスコアの前に書かせる |
| 幻覚 (Hallucination) | 本文にない情報を根拠に減点する | [Evidence]セクションで本文の直接引用を強制する |
| フォーマット崩れ | JSON等の後続処理でエラーが出る | Few-shotで出力例を提示、またはスキーマ制御を行う |
【改良後の最適プロンプト】
最新LLMの「長いコンテキストの理解」と「構造化出力」の特性を最大限に活かした、実務向けの最終プロンプト案です。
# Role
Technical Content Auditor
# Task context
あなたはカスタマーサポートの自動回答精度を測定しています。
提示された「評価基準」に基づき、ステップバイステップで評価を実施してください。
# Output Schema (JSON)
{
"reasoning_steps": [
"step1: 文脈の理解度を確認...",
"step2: 技術的な正確性を検証..."
],
"criteria_check": {
"accuracy": {"score": 1-5, "evidence": "string"},
"politeness": {"score": 1-5, "evidence": "string"}
},
"overall_score": 0.0,
"action_item": "改善のための具体的アクション"
}
# Detailed Rubric
## Accuracy (正確性)
- Score 5: 全ての技術用語が正確で、推奨されるベストプラクティスに基づいている。
- Score 3: 事実誤認はないが、曖昧な表現が含まれる。
- Score 1: 致命的な誤情報（ハルシネーション）を含む。
# Constraints
- 回答の前に「なぜそのスコアになったのか」の内部推論(CoT)を必ず記述すること。
- スコアは四捨五入せず、ルーブリックに従って厳格に付けること。
- JSON以外のテキストは出力しないでください。
# Target Input
PROMPT: {user_prompt}
RESPONSE: {llm_response}
# Evaluation Output (JSON)
【まとめ】
LLM-as-a-judgeを運用するための3つの鉄則：
思考を先、スコアを後に: 先に点数を決めさせると、後付けの理由（正当化）が生成されやすいため、必ず「証拠→理由→スコア」の順で出力させる。
具体的ルーブリックの提示: 「良い・悪い」ではなく「XXが含まれていれば3点」という、誰が見ても同じ判断になる客観的な基準を書き込む。
Few-shotの活用: 特に「低い評価（1点や2点）」の例をFew-shotとして含めることで、LLMが陥りやすい「お世辞バイアス（高得点を付けすぎる傾向）」を抑制できる。
