発見的推理は最終的で厳密なものではなく,（中略）その目的は当面する問題の解を求めることである.ジョージ・ポリア 著、柿内 賢信 訳：いかにして問題をとくか より
はじめに
どうも！
AI開発推進部でQA（品質保証）エンジニアをしています、"たかだ"です！
どうにも、寒暖差があるせいか体調が崩れがちな時期ですが、いかがお過ごしでしょうか？
今日は、絶賛構築中の「LLM-as-a-Judge」について、書いていこうと思います！
LLM-as-a-Judgeって、なに？
LLM-as-a-Judgeを初めて知る方のために、ちょっと解説しますね。
端的にいうと、「LLM（大規模言語モデル）で生成したものを、LLMで"自動的に評価する”手法」のことを言います。
2023年の研究*1によると、GPT-4による評価が、人間による評価*2と比較した結果、人間との一致率が80%を超えることを示したことによって、LLM-as-a-Judgeの有効性を示したとのことです*3。
そこから、「LLMが生成したものを、LLMで評価させよう」という流れになり、今のLLM-as-a-Judgeがあるそうです。
もうちょっと、わかりやすい例えでLLM-as-a-Judgeを解説しましょうか。
たとえば、
というように、「チキンカレーに必要な具材を、LLMにインプットさせて作ってもらう」としたとき、LLM上では以下のようなイメージで動いて生成されます。
.....「へっ！？」って思いますよね？
LLMがブラックボックスで動く様子を、モザイクで表してみました。
このように、生成する成果物（チキンカレー）はLLMによって「インプットする（材料）はわかってるけど、作ってる過程（手順）はその順番や分量も含めてわからない状態」で生成されていきます。
こうなると、生成する成果物（チキンカレー）は、
のように、「チキンカレー"っぽい"もの」が生成されることになります*4。
そこで、LLMを使って、
と、「色んな角度から、"チキンカレーであるか？"」を評価していきます。
これが、LLM-as-a-Judgeによる評価になります。
これを、弊社のプロダクトである「すくすくレポート®*5」に置き換えると、
というように、LLM-as-a-Judgeという手法で、生成された文章に対して「色んな角度から、園児・クラスのレポートとして生成しているか？」を評価することになります。
はじめの一歩
なんとなくLLM-as-a-Judgeのイメージがついたところで、本筋に入ります。
LLMを使った評価で、最初に躓いたのは、
でした。
そこで、まず決めたのが、
「軸を決める」ことでした。
「軸」を決める
AI開発推進部のメンバーから、以下の「非常に良いインサイト」をいただきました。
ということで、「軸」を決めるのに考えたことを以下に書いていきます*6。
背景や目的：以下の2つ
- 背景：LLM出力は確率的に揺れるため、従来のテストケースだけでは判定がぶれる
- 目的：評価者間の判断の差を最小化し、評価を迷いなく判断できる基準を定める
期待アウトカム：最終的な期待アウトカムは何？
- AIを使ったプロダクトが、「保育の専門性を高める業務に、集中するための時間を創り出す “頼れる存在”（役に立つパートナー）」であること
NG（絶対回避）：絶対に避けたい「振る舞い・出力」は何？
- 安全性・配慮面
- プライバシー・倫理面
- 信頼性・正確性面
- 保育理念面に反する振る舞いや出力 etc…
大枠のアウトラインを決めてから、今度は「評価軸」を決めていきました。
「評価軸」を決める
アウトラインとなる「軸」をベースに、必要な評価軸とその評価内容を決めていきました。
共通：「生成されたものは、どのような状態が望ましいか」を言語化
- バイアス（思い込み、勘違い）を生むような文章になっていないこと。
- 認知の歪みにつながるような文章にならないこと。
優先順位を決める：以下の、3つ
- 1位：妥当性/一意性（ゲート条件）
- 誤読の余地や曖昧さがないか。
- 文章構成などから読みやすい文章になっているか。
- 2位：正確性/信頼性
- 入力（事実・元データ）と乖離がないか。
- 事実に基づいているか。
- 3位：有用性/一貫性
- 園の先生向けに有用な情報になっているか。
- 文脈や内容の一貫性があるか。 etc…
「妥当性/一意性」をゲート条件に設けた理由としては、「文章を評価するうえで、最低限担保すべきもの」だったからであり、「読みやすさ」が担保されなければ、「文章の内容、構成、文法などを評価するのが難しい」と考えたからです。
評価軸を一旦決めたら、いよいよ「技術選定」に入りました。
技術選定
LLM-as-a-Judgeを実行できるツールとして、Langfuse*7やDeepEval*8といったものが挙げられます。
高田がフィジビリティでやってみたのは、AWSの「Bedrock AgentCore Runtime + Application Signalsによる、LLM-as-a-JudgeとObservabilityの自動実行」でした。
上記については、「たよれるくん*9」にて、そのフィジビリティを確認しつつ構築を進めていきました。
フィジビリティでやってみたLLM-as-a-Judgeの機能としては、以下の通りになります。
- 文章生成: 保育士の入力から保護者向け連絡帳文章を自動生成（Amazon Nova Lite使用）
- 品質評価: 生成文章を3つの評価軸で10点満点評価し、合否判定を実施（Amazon Nova Pro使用）
- 可観測性: Application Signalsによる実行トレースとGenAI Observability Dashboardでの可視化
LLM-as-a-Judgeの流れは、以下の通りです。
権限確認
└─ Bedrockログの権限設定確認文章作成タスク実行
└─ Nova Liteが各機能の文章作成タスクを実行
└─ 出力:各機能に合わせた、文章LLM Judge評価
└─ Nova Proがタスク実行の出力を評価
└─ 評価結果: 「有用性/一貫性」「正確性/信頼性」「妥当性/一意性」の各評価軸をスコアリングObservability（OpenTelemetryベース）
└─ ゼロコード計装により、自動的にTrace
└─ Tree表示で、生成内容と評価内容のTrace情報を表示
また、上記を実行するために、Claude Sonnet 3.5を「文章生成〜評価〜観測をオーケストレーションする」ように計装していきました。
「軸」「評価軸」「技術選定」からのインサイト
LLM-as-a-Judgeを構築する時の「軸」「評価軸」「技術選定」といったアクティビティから、得たインサイトを以下に掲載していきます。
軸を細かく決めすぎると、「方針転換する時の負荷が、高くなる」
- 同時に、「バイアスが働かないか（これで、いいか）」心配だった。
逆に、粗すぎると「自由度が高くて、次の行動のチョイスに迷う」
- 色んなことをチャレンジできるといった「ポジティブな面」がある反面、色々チャレンジして「時間がかかりすぎる」ってことになる。
入力（プロンプトやデータ）を意識する。あとは、手を動かして確認してみる。
- 入力プロンプトが、「AWS Bedrockのプロンプト管理」からだったり、「実装に埋め込まれていたり」するので、LLM-as-a-Judgeの技術選定をする際には、入力プロンプトの場所を意識したほうがいいと思う。
- 実際に構築するときとか、アーキテクチャなりデータなりが「こんがらがってしまって」訳わかんなくなりそう（Bedrock AgentCore Runtimeベースで構築するときに、困りそう）
軸を決めて行動することで、ある程度動きやすく、LLM-as-a-Judge構築をする上でやるべきことにフォーカスして行動できました。
ただとはいえ、「軸の粒度（バランス）」は、現場次第で変わってくると思うので、軸の取り方・決め方のバランスは考えて「一旦、ここにして決める（打ち止める）」くらいにして置くのがベストかなと思いました。
あとは、技術選定に関しては「入力（プロンプトやデータ）を意識する。とにかく、手を動かして確認してみる」といったことをすると良いかなと考えています。
実際に動くところを見て、「見えてくるもの」もあるでしょうし。
おわりに
いかがでしたでしょうか？
今回の記事は、QA engineer at a Startup vol.27*10にてお話した内容をベースに、追記分含めて記事を書きました！
LLM-as-a-Judge構築の参考になれれば、幸いです！
また、Amazonの公式ブログにて、
aws.amazon.com
が、掲載されていました。
これらを参考にしつつ、LLM-as-a-Judge構築を進めていきたいと改めて思う今日この頃です。
「具体⇄抽象のための思考力を決定的に分けるのは「能動性」だと思います。「水は低きに流れる」ために、これを上下運動に変えるためには意志の力が必要になるからです。」細谷 功著：「具体⇄抽象」トレーニング 思考力が飛躍的にアップする29問 より
今回も、最後まで読んでいただき、ありがとうございます！
では、また！
ユニファでは家族の幸せを生み出すあたらしい社会インフラを一緒につくっていく仲間を大募集しています！
気になる方はぜひこちらのサイトもチェックしてみてください！！
*1:Lianmin Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena", 2023.
*2:約3,000件の専門家による投票（MT-bench）と、3万件の一般ユーザーによる投票（Arena）を「どちらが優れているかを決める」「 1つの回答に対して直接スコアをつける」「正解がある問題に、「参照となる解答」を提示した上で採点させる」方法で評価を採点
*3:「評価のバイアス」。特に「単に”最初に提示された方”を高く評価してしまう傾向」「ただ文章が長く詳細に書かれている回答を好んでしまう傾向」「自分自身（または自モデルのファミリー）が生成した回答を、他モデルの回答よりも高く評価してしまう身内びいきの傾向」や、「推論・数学能力の限界」といった課題が、あるようです。
*4:ここが、LLMが「確率的に変動する＝決定的に決められないトークン分類器」である所以だと、高田は考えます
*5:「AIが埋もれていた記録の価値を再発見し、保育者が子どもと向き合う時間を増やす。"過去の記録が未来の育ちに活きる"循環を生み出す」プロダクト。詳しくは、https://lookmee.jp/hoikuai/sukusuku-report.html をご覧ください
*6:一部、抜粋したものを掲載しています
*9:弊社AI機能の一つ。連絡帳やおたより、帳票管理の文字入力をサポートする機能。詳しくは、https://lookmee.jp/hoikuai/function.html#tayoreru をご覧ください
*10:2026/03/02に行われたコミュニティイベントにて、LT登壇しました：https://qaengineeratastartup.connpass.com/event/384699/
