はじめに
LLMの出力の評価について調べていて、Hamel Husainという元Airbnbのデータサイエンティストで、いまはフリーランスとしてLLM評価のコンサルティングや講座を提供している方のブログに行き当たりました。
Hamel氏は「LLM-as-a-Judge を組む前に、まず人間が対話ログを読み込め。評価基準は LLM ではなくドメイン専門家が決めるべきだ」。LLM 評価というと、自分はつい自動化から手を付けたくなる側です。Hamel氏の主張はその逆向きで、しっくりきたので論点を 5 つにまとめてみました。
なぜ LLM-as-a-Judge から作り始めるとうまくいかないのか
Hamel氏が繰り返し主張しているのは「Error analysis is the most important activity in evals（エラー分析こそ評価で最も大事な作業）」という一文です。基準が固まる前に Judge を組んでしまうと、「有用性スコア」のような汎用的な指標ができあがり、プロダクト固有の壊れ方を取り逃します。合格率（pass rate）の数字は積み上がっても、ユーザー体験は良くなりません。
具体例 — Nurture Boss のケース
「プロダクト固有の壊れ方」と言われてもイメージしにくいので、Aakash Gupta氏のポッドキャストに出てくる事例を引いておきます。題材は不動産管理向けの AI アシスタント Nurture Boss（チャット・SMS・音声で物件案内や内見予約を捌くサービス）です。
Generic metrics like 'helpfulness score' won't catch the bathroom being connected instead of disconnected.
（「有用性スコア」のような汎用メトリクスでは、バスルームが直結（connected）か非直結（disconnected）かの取り違えは捕まえられない。）
不動産用語で「コネクテッドバスルーム」は寝室と直接つながっている浴室、「ディスコネクテッド」は廊下からアクセスする浴室を指します。
- 例 1 — バスルームの connected/disconnected: ユーザーが「バスルームが直結していない 1 ベッドルームを探して」と頼んだのに、AI は直結タイプの物件を返してしまう。仕様違反だが、helpfulness score のような汎用判定は「親切に物件を出した」として pass を出してしまう。
-
例 2 — SMS なのに Markdown: AI が SMS 返信で
**重要**のような Markdown を使い、ユーザーには生のアスタリスクが届く。一方 conciseness score は「短く簡潔だ」として pass を出す。
どちらも「直結バスルームは含めない」「SMS では Markdown を使わない」といったプロダクト固有のルールを守れているかが論点で、それを測るには Nurture Boss 専用の判定基準が要ります。汎用メトリクスでは絶対に拾えません。
同じ AI 応答でも、評価軸が違えば結論が逆になる。汎用 Judge を導入するだけでは、左の経路（PASS）しか見えなくなる、という構図です。
評価の出発点は、ダッシュボードや Judge ではなく、人間が対話ログを 1 件ずつ読むこと。Hamel氏が強調するのはこの順序です。
エラー分析は「眺めて勘で直す」ではなく、手順化されている
エラー分析と聞くと「眺めて勘で直す」イメージがありますが、Hamel氏は質的研究の手法を借りて2段階に分けています。
- Open Coding（自由記述）: 1 件ずつ自由なメモを書き、気になる挙動を言葉にする
- Axial Coding（分類整理）: 似たメモを束ねてカテゴリ名を付ける
Hamel氏は前者を「日記をつけるような感覚」と表現し、後者で「Missing User Education（ユーザーへの説明不足）」「Authentication / Access Issues（認証・権限の問題）」のような名前付きカテゴリへ昇格させます。社会学のグラウンデッド・セオリーに由来する手法で、ふわっとした気付きを再現できる「分析」へ変えるのが狙いです。
Open Coding はどう書くか — Hamel氏のサンプルトレース
llm-judge 記事に出てくるサンプルトレースで雰囲気が掴めます。注文照会ボットの 1 件です。
User Input: "Where's my order #ABC123?"
Function Call: search_order_database("ABC123") → "not_found"
Context Retrieved: "Order numbers follow format XXX-XXX-XXX"
LLM Response: "I cannot find that order #. Please check the number and try again."
ドメイン専門家がこれを読むと、「注文番号のフォーマット（XXX-XXX-XXX）をシステムは取得しているのに、応答に含めずユーザーに伝えていない」と気付きます。この自由メモが Open Coding です。Axial Coding 段階で同様の事例を束ねると、「Missing User Education」というカテゴリ名へ昇格します。
Hamel氏はカテゴリを件数で並べた表まで作るのを推奨しています。例えばこんな分布です。
| カテゴリ | 比率 |
|---|---|
| Missing User Education | 40% |
| Authentication / Access Issues | 30% |
| Poor Context Handling | 20% |
| Inadequate Error Messages | 10% |
ここまで来てはじめて「次に手を入れるべき場所」がデータで決まります。表を作る前に Judge を組むと、この優先順位付けが効かなくなる、というのが Hamel氏の警告です。
誰が、どれだけやるのか
エラー分析の主役はエンジニアではなく、ドメイン専門家です。Aakash Gupta氏のポッドキャストでの Hamel氏の発言が分かりやすいです。
PMs need to own error analysis, not engineers. This is product work, not engineering work.
（エラー分析の責任者は PM であって、エンジニアではない。これはプロダクトの仕事で、エンジニアリングの仕事ではない。）
ここで言うPMは「ドメインを理解している人」を指していて、PM以外でも弁護士・心理士など領域の判断ができる人なら職種は問いません。Hamel氏はこの 1 人を「benevolent dictator（優しい独裁者）」と呼んでいます。最終的な判断を 1 人に集めるのが薦められる形です。
役割の境界は次のように整理できます。
Hamel氏の主張は「左から右へ流す」 = ドメイン専門家が決めた基準をエンジニアが実装し、Judge が自動化する。逆向き（Judge を先に作って基準を後追いする）にすると、ドメイン固有の壊れ方を取り逃す、ということです。
レビュー件数の目安は出典で揺れがあるので、Hamel氏の発言を並べておきます。
- 30 件くらいから始め、新しい失敗パターンが出なくなるまで続ける（llm-judge 記事）
- 目標は 100 件以上（FAQ）
- 1 時間で 100 件、おおむね 40〜50 件のエラーが出る（Aakash ポッドキャスト）
実務で使うときは、こんな流れになります。
100 件読んでエラーがほぼ出ないなら、それは「品質が高い」のではなく「評価が緩い」サイン。これが Hamel氏の感覚です。
Judge を作るタイミングと、合格率 70% の意味
人間がログを読み終えたら、ようやくLLM-as-a-Judgeの出番です。ただし対象は絞ります。明らかなバグやプロンプトの不備はコード側で直し、Judge で測るのは「人間でも判断が割れるグレーゾーン」だけ。Hamel氏はllm-judge記事の「Step 4」で釘を刺しています。
Instead of plowing ahead and building an LLM judge, you want to fix any obvious errors.
（Judge を作り進める前に、明らかなエラーを直しなさい。）
Judge プロンプトはどう書くか — Honeycomb の例
Hamel氏が llm-judge 記事で示している Judge は、Honeycomb の自然言語クエリ生成機能を判定するものです。骨格は次の 3 点に尽きます。
-
指示文:
"You are a Honeycomb query evaluator with advanced capabilities to judge if a query is good or not."のような単純な役割宣言から始める -
出力形式は binary:
{"critique": "[判定理由を文章で]", "outcome": "good" or "bad"}のような JSON に固定する。1〜5 のスコアにはしない（Hamel氏は「数値スコアは Judge 同士で揺れる」として明確に否定） -
Few-shot は人間がラベル付けした実例を埋め込む:
<example-1><nlq>[ユーザー入力]</nlq><query>[生成されたクエリ]</query><critique>[人間が書いた判定]</critique></example-1>のような構造で、エラー分析で集めたメモをそのまま流用する
critique を必ず文章で書かせるのが要点です。Hamel氏はこれを「新人が読んで判断を再現できるレベルで」と表現しています。critique の文章はそのまま新しい few-shot 例に回せるので、Judge を回せば回すほど精度が上がる仕組みになります。
Judge を書いたら、人間ラベルとの一致率（TPR/TNR や Cohen's kappa）で校正します。Hamel氏は「100 件以上の人間ラベルで Judge を測定しないなら作る意味がない」とまで書いています。
運用へ移したあと、気をつけるのは合格率です。
If you're passing 100% of your evals, you're likely not challenging your system enough. A 70% pass rate might indicate a more meaningful evaluation.
（評価で 100% 合格しているなら、問いが緩すぎる可能性が高い。70% くらいの方が意味のある評価になっている。）
100%は「Judgeが甘い」サインで、作り直すきっかけです。70% 前後を健全な目安として、評価そのものを継続的に難しくしていく前提で設計します。Judgeの合格率はプロダクトの信頼性を測る指標ではなく、Judgeの難易度を測る指標。この区別が大事です。
読んで考えたこと — PM の役割について
Hamel氏の主張する「エラー分析はPMが所有すべき」というルール。これは当然、「PMがドメインを理解している」ことが前提になっています。
逆に言えば、ドメインを判断できず社内調整しかしない PM は、LLM プロダクトの評価設計では出る幕がありません。AI時代のPMは「社内を調整する人」から「ドメインの良し悪しを言える人」へ重心が移っていく。最近の肌感覚と重なる話でした。
従来の業務がなくなるわけではなく、上に「ドメイン判断」レイヤーが乗ってくる、という変化です。社内調整は AI が肩代わりしにくい一方、ドメイン判断は人間にしかできないので、PM の希少価値はそちらに移っていく。