llm-as-judge

LLM-as-Judge

概要

品質基準には、声のトーン、視覚的な美しさ、UX の印象、ドキュメントの明瞭さ、コードの読みやすさなど、本質的に主観的なものがあります。これらは決定論的なテストでは検証できません。LLM-as-judge パターンでは、評価基準を定義した LLM レビュアーを使って、構造化された再現性のある評価を行い、主観的な品質を一貫して測定します。

開始時に宣言してください：「主観的な品質を評価するために、llm-as-judge スキルを使用しています。」

---

フェーズ 1：評価方法を決める

目標： LLM-as-judge が適切なツールかどうかを判断します。

判断表：LLM-as-Judge と決定論的テストの比較

基準の種類	方法	例
客観的、測定可能	決定論的テスト	「応答時間が 200ms 未満」
構造的、検証可能	決定論的テスト	「有効な JSON を返す」
主観的、定性的	LLM-as-judge	「エラーメッセージが親しみやすく、役に立つ」
美的、知覚的	LLM-as-judge	「UI がすっきりとしていて、モダンな印象を与える」
言語的、トーンに関するもの	LLM-as-judge	「初心者にもわかりやすいドキュメントである」
全体的、体験的	LLM-as-judge	「オンボーディングの流れが直感的に感じられる」

経験則： ブール値のアサーションを書ける場合は、決定論的なテストを使用します。評価に判断が必要な場合は、LLM-as-judge を使用します。

停止 — 次の条件を満たすまで、フェーズ 2 に進まないでください：

• 基準が本当に主観的であることを確認した
• 決定論的なテストでは対応できないことを確認した
• 評価対象となる具体的な成果物を特定した

---

フェーズ 2：評価基準を定義する

目標： 重みと基準点を備えた評価項目を作成します。

アクション

1. 3～5 個の評価項目を定義します
2. 重みを割り当てます（合計は 1.0 にする必要があります）
3. 各項目の基準点を定義します（1＝最低、5＝十分、10＝最高）
4. 合格しきい値を設定します

評価基準の構成

項目	重み	尺度	基準点：1	基準点：5	基準点：10
[名前]	0.X	1-10	[最悪のケース]	[十分]	[優秀]

しきい値の選択表

品質レベル	しきい値	用途
最低限実用可能	5.0	社内ドキュメント、ドラフトコンテンツ
本番品質	7.0	ユーザー向けコンテンツ、公開 API
卓越性	8.5	マーケティング、重要な UX フロー

停止 — 次の条件を満たすまで、フェーズ 3 に進まないでください：

• 3～5 個の項目が明確な説明とともに定義されている
• 重みの合計が正確に 1.0 である
• 基準点が具体的である（曖昧ではない）
• 評価を開始する前に合格しきい値が設定されている

---

フェーズ 3：評価する

目標： 評価基準とともに成果物を LLM レビュアーに提出します。

レビュー依頼の構成

{
  criteria: "Description of what to evaluate and the quality standard",
  artifact: "The content to be evaluated (code, text, UI markup, etc.)",
  rubric: [
    { dimension: "Clarity", weight: 0.3, description: "Is the content easy to understand?" },
    { dimension: "Tone", weight: 0.3, description: "Is the tone appropriate for the audience?" },
    { dimension: "Completeness", weight: 0.2, description: "Does it cover all necessary points?" },
    { dimension: "Engagement", weight: 0.2, description: "Does it hold the reader's interest?" }
  ],
  passing_threshold: 7.0,
  intelligence: "opus"
}

レビュー結果の構成

{
  scores: [
    { dimension: "Clarity", score: 8, reasoning: "Well-structured with clear headings..." },
    { dimension: "Tone", score: 7, reasoning: "Professional but occasionally too formal..." },
    { dimension: "Completeness", score: 9, reasoning: "Covers all key topics..." },
    { dimension: "Engagement", score: 6, reasoning: "Could use more examples..." }
  ],
  weighted_score: 7.4,
  pass: true,
  summary: "Overall good quality with minor tone and engagement improvements suggested.",
  suggestions: [
    "Add a real-world example in section 3",
    "Use more conversational language in the introduction"
  ]
}

停止 — 次の条件を満たすまで、フェーズ 4 に進まないでください：

• 完全な評価基準とともに成果物が提出されている
• 各項目が個別に採点されている
• すべてのスコアに理由が示されている
• 重み付けされた合計スコアが計算されている

---

フェーズ 4：改善または採用する

目標： 評価結果に基づいて対応します。

結果と対応の表

結果	対応	最大反復回数
合格（スコア >= しきい値）	成果物を採用し、次に進む	完了
惜しくも不合格（しきい値との差が 1 点以内）	提案を適用し、1 回再評価する	1
明確な不合格（しきい値を 1 点超下回る）	大幅に改訂し、すべての提案を適用する	2
不合格の繰り返し（3 回以上の試行）	エスカレーションする — 評価基準またはアプローチの調整が必要な可能性があります	エスカレーション

停止 — 次のいずれかに該当したら評価完了です：

• 成果物がしきい値に合格した、または
• 3 回の反復が完了し、エスカレーションの判断が行われた

---

よく使われる評価基準のテンプレート

ドキュメントの品質

Clarity (0.3): Is the content easy to understand for the target audience?
  1=incomprehensible  5=adequate but requires re-reading  10=crystal clear
Accuracy (0.3): Is the information technically correct?
  1=factually wrong  5=mostly correct  10=perfectly accurate
Completeness (0.2): Does it cover all necessary topics?
  1=missing critical info  5=covers basics  10=comprehensive
Examples (0.2): Are there sufficient, relevant code examples?
  1=no examples  5=some examples  10=rich, varied examples
Threshold: 7.0

エラーメッセージの品質

Helpfulness (0.4): Does the message help the user fix the problem?
  1=no help at all  5=vague direction  10=exact fix steps
Clarity (0.3): Is the message easy to understand?
  1=cryptic  5=understandable  10=immediately clear
Tone (0.2): Is the tone empathetic and non-blaming?
  1=hostile/blaming  5=neutral  10=empathetic and supportive
Actionability (0.1): Does it suggest a concrete next step?
  1=no suggestion  5=vague suggestion  10=specific actionable step
Threshold: 7.5

コードの読みやすさ

Naming (0.3): Are variable/function names descriptive and consistent?
  1=single letters everywhere  5=adequate  10=self-documenting
Structure (0.3): Is the code logically organized?
  1=spaghetti  5=functional  10=elegant and clear
Simplicity (0.2): Is the code as simple as possible (but not simpler)?
  1=over-engineered  5=reasonable  10=minimal and clear
Documentation (0.2): Are complex sections adequately commented?
  1=no comments where needed  5=some comments  10=well-documented why
Threshold: 7.0

UX コピー

Clarity (0.3): Is the copy easy to understand?
  1=confusing  5=understandable  10=immediately clear
Brevity (0.2): Is it concise without losing meaning?
  1=verbose  5=adequate length  10=perfectly concise
Tone (0.2): Does it match the brand voice?
  1=off-brand  5=neutral  10=perfectly on-brand
Actionability (0.2): Do CTAs clearly communicate what happens next?
  1=unclear  5=adequate  10=crystal clear action
Accessibility (0.1): Is the language inclusive and jargon-free?
  1=exclusionary  5=neutral  10=fully inclusive
Threshold: 7.5

---

アンチパターン／よくある間違い

アンチパターン	誤りである理由	正しいアプローチ
測定可能な基準に LLM-as-judge を使用する	トークンを浪費し、アサーションより信頼性が低くなります	定量化できる項目にはすべて、決定論的なテストを使用します
曖昧な評価項目（「良いか？」など）	信頼性と一貫性に欠けるスコアが生成されます	基準を明確にし、判断の拠り所となる例を示します
合格基準が定義されていない	合格か不合格かを客観的に判断できません	評価の前に必ずしきい値を設定します
不合格のコンテンツを合格させるために評価基準を調整する	品質ゲートの目的が損なわれます	評価基準ではなく、コンテンツを修正します
理由を示さずに一度だけ評価する	理由がわからなければ改善できません	項目ごとの理由を必ず求めます
評価に性能の低いモデルを使用する	判断の質が低下します	利用可能な中で最も性能の高いモデル（Opus）を使用します
変更後の再評価を省略する	変更によって品質が向上したか検証できません	修正後は必ず再評価します

---

統合ポイント

スキル	関係
acceptance-testing	LLM-as-judge が主観的な受け入れ基準を評価します
spec-writing	仕様に主観的な品質基準が含まれる場合があります
code-review	コードレビュー中に読みやすさを評価します
verification-before-completion	完了前の主観的な検証ゲートです
senior-prompt-engineer	プロンプトの品質評価に LLM-as-judge を使用します
tech-docs-generator	ドキュメントの品質を評価します

---

下流ステアリングパターン

+----------+     +----------+     +----------+     +----------+
|  SPECS   |---->|   CODE   |---->|  TESTS   |---->| LLM-AS-  |
|          |     |          |     |(determin)|     |  JUDGE   |
|          |     |          |     |          |     |(subject) |
+----------+     +----------+     +----------+     +----+-----+
                      ^                                  |
                      |          backpressure             |
                      +----------------------------------+

決定論的なテストで客観的な基準を検証します。LLM-as-judge で主観的な基準を検証します。両方に合格する必要があります。

---

スキルの種類

FLEXIBLE — 評価項目としきい値は状況に応じて調整します。パターンの構造（評価基準を定義し、評価し、採点し、反復する）は固定です。しきい値は必ず評価前に設定し、評価後に設定してはいけません。