こんにちは、エムスリー AI・機械学習チームの氏家（@mowmow1259）です。
この記事はAI・機械学習チームブログリレーの10日目の記事です。9日目は苅野さんによる「Claude Code と進める Ingress から Gateway への移行」でした。 移行をゴリゴリ進めていただいている苅野さんによる解説記事です！
私は福岡に住んでいるんですが、最近同僚と大濠公園でお花見BBQをしてきました。 お花見と言いつつ桜はまだ咲いていなかったのでただBBQをしただけになりました。 お花見シーズンに限らず、大濠公園は落ち着いて過ごせるいいところなので福岡に来た際にはぜひ立ち寄ってみてください。
さて、生成AIの台頭により、画像・テキスト・コードとあらゆるコンテンツ生成が飛躍的に容易になりました。 エムスリーでも業務効率化だけでなく、生成AIの各種プロダクトへの組み込みを積極的に推進しています。 一方で、生成物を直接利用する場合には、低品質な生成物はユーザー体験の悪化や意図しない情報漏洩にも繋がるため、品質担保は避けて通れない課題です。
本記事では、LLMによる生成物をプロダクトに組み込む際の品質担保戦略として、エムスリーで実践しているLLM-as-a-Judgeを中心としたアプローチを紹介します。
なお、本記事は先月福岡で行われたPythonのコミュニティイベント Python Meetup Fukuoka #6 *1での登壇内容です。 ご興味がある方はぜひ登壇資料もご覧ください。
LLM as a Judgeとは
基本的な考え方
LLM-as-a-Judge とは、生成AI（LLM）自身に評価をさせるアプローチです。 近年ではレビュー論文*2も公開されるなど活発に議論されている分野です。
例えば、このブログについて、5点満点で評価してくださいのような形でプロンプトを作り、LLMの出力を直接評価に使います。
出された評価でフィルタリングをしてもいいですし、評価を元に改善のサイクルを回すこともできます。
人手による評価と比較して圧倒的にスケールするのが最大の利点です。
LLM-as-a-Judgeに潜むバイアス
ただし、先ほどの例のように素直に評価させても多くの場合うまくいきません。 LLMの生成にバイアスやハルシネーションがあるように、LLMを評価に用いる際にもさまざまなバイアスは避けて通れません。 例えば代表的なバイアスとして次のものがあります。
- Position Bias: 複数選択肢のうち最初のものを高く評価しがち
- Length Bias: 長く冗長な文章ほど高く評価しがち
- Self Enhancement Bias: 自身が生成した出力を高く評価しがち
これらのバイアスを踏まえた上で「どうやってLLMに公正・妥当な評価をさせるか」がLLM as a Judgeの研究分野であり実用上の肝になります。
バイアスを考慮した評価
では、どのようにしてバイアスを排除しながら評価させたら良いのでしょうか。 ここでは例として、プログラミングクイズを出題するプロダクトのために、LLMでクイズを生成したとします。
問題: 次のデータ型のうち、一度作成すると中身を変更できない（イミュータブルな）ものはどれ？
A. リスト (list) B. 辞書 (dict) C. タプル (tuple) D. セット (set)
当然答えはCです。
ここからはこのクイズに対して適切に評価させる方法を紹介していきます。
① 評価観点の明確化
「いい評価をしてください」という曖昧な指示では一貫性のある評価になりません。 まずは、何の観点で、どういう基準で評価するかを明示することが重要です。
次のPythonクイズを次の4つの観点から、5点満点（1〜5）で評価し、総合評価を同じく5点満点で評価してください。 評価項目： - 有用性: 実務や学習の初期段階で、知らなければ困る重要な知識か。 - 選択肢の罠: 誤答の選択肢に「他言語の癖」や「直感的な勘違い」を誘う説得力があるか。 - 意外性: 正解や解説を聞いたときに「なるほど！」という驚きや納得感を得られるか。 - 汎用性: その問題の答えが他の文法やライブラリの理解にも繋がる根本的なルールか。
評価観点を明示することで評価軸やスケールが揃い、妥当な評価になりやすくなります。 冒頭のクイズだと選択肢の罠の観点でGeminiに3をつけられてしまいました。 ここから、setの代わりにdataclassを選択肢に入れるなどの改善が考えられます（その場合Geminiの評価は5に上がります）。
② 複数モデルでのバリデーション
コストとの兼ね合いになりますが、単一モデルの評価はそのモデルのバイアスをそのまま反映してしまいます。 Gemini、GPT、Claude Sonnetなど異なるLLMに同じプロンプトで評価させ、複数の評価結果を統合することで、self enhancement biasを考慮したより頑健な評価が得られます。
モデルA: 5点 モデルB: 2点 → 平均: 2.7点 モデルC: 1点
また、スコアのばらつき自体も「評価が難しい問題かどうか」の指標になります。
③ 人間による生成との対決（ペアワイズ法）
ここまでは絶対評価を前提に紹介しましたが、絶対評価だけでなく相対評価も品質担保に有効です。 生成物と人間が作ったコンテンツを並べて比較させ、相対的に品質の高いクイズかを評価できます。
次の2つはPythonに関するクイズです。どちらがよりソフトウェアエンジニアが監修した クイズとして質が高いでしょうか。 クイズA: XXXXX クイズB: YYYYY
Position Biasへの対策として、クイズAとBの順番を入れ替えたパターンを実施するのもよいでしょう。
④ 評価理由やリファレンスを生成させる
スコアだけでなく評価理由も生成させることで、CoTの文脈で評価精度の向上が期待できますし、人手で後から確認する際の効率も上がります。
...
ただし、評価は次の形式で理由も含めて出力してください。
修正や批判を行う場合はそれが正しいと主張できる箇所を原文から抽出して併記してください。
{
"has_issues": true/false,
"issues": [
{
"category": "有用性" | "意外性" | "汎用性",
"description": "具体的な問題点の詳細説明",
"severity": "high" | "medium" | "low",
"details": "カテゴリ分析結果や具体的な指摘内容"
}
]
}
根拠を原文から抽出させる指示を加えることで、ハルシネーションのチェックの効率も上がります。
⑤ 人手評価によりプロンプトをチューニング
ここまで評価のためのTipsを紹介してきましたが、一発で実用に足る評価プロンプトを作ることは困難です。 解いている問題のドメインや難易度によってプロンプトの調整は必須だと思っています。 そのため、従来の機械学習と同様に人手評価 → プロンプト改善のサイクルを回すことが重要です。
プロンプトv1で評価 → 人手評価と比較 → ずれを修正したプロンプトv2を作成
「LLMが3点と評価したが人間は5点と評価した」というようなずれを収集し、そのずれのパターンに基づいてプロンプトを改善していきます。
⑥ プロンプトのチューニングもLLMにやらせる
人手評価を進めていく中で、プロンプトの修正案作成自体もLLMに任せるのもよく行っている方法です。
[正解例] 問題: XXXXX 人手評価: 5点、理由: 〇〇 LLM評価: 2点、理由: △△ → このずれを修正するプロンプトv2の改善案を生成してください
人手アノテーションのコストを抑えつつ、評価プロンプトの品質を継続的に向上させられます。
LLMの評価をプロダクトの一部としてとらえる
LLMによりいかにバイアスを排除した評価を実施しても、ドメインやプロダクトの特徴によっては生成物をそのまま利用することが難しい場合ももちろん多くあります。 LLMが高評価したから大丈夫だ、というような使い方ではなく、プロダクトによって適切に道具の一つとして使っていくのが重要です。
例えば、コンテンツを大量生成・評価させた上で人手による評価ができる程度にフィルタリングしたり、LLMによる評価をプロダクトそのものにすることも考えられます。
まとめ
LLM-as-a-Judgeを活用した生成物の品質担保戦略を紹介しました。 生成AIをビジネスに組み込む際、「生成できること」と「信頼できる品質で生成できること」の間には大きなギャップがあります。LLM-as-a-Judgeをそのギャップを埋める現実的な手段として、ぜひ活用してみてください。
We are Hiring!
エムスリーではエンジニアを絶賛募集しています！ 少しでもご興味をお持ちの方は、ぜひカジュアル面談等にご応募ください！
エンジニア採用ページはこちら
カジュアル面談もお気軽にどうぞ
エンジニア新卒採用サイト！
*1:LINEヤフーさん、GMOペパボさん、エムスリーの共同開催
*2:Jiawei Gu, et al. (2025). A Survey on LLM-as-a-Judge. arXiv:2411.15594. https://arxiv.org/abs/2411.15594
