こんにちは。
HR forecasterでエンジニアをしている鈴木です。
アドベントカレンダー14日目の記事では、最近実装した大規模言語モデル（LLM）を用いた機能と、これによる生成結果をLLM自身で評価するLLM-as-a-Judgeの取り組みについて紹介します。
サービスへのLLMの組み込みと課題
2025年10月に、HR forecasterに「求人票AIアドバイザー」という機能をリリースしました。
この機能は、求人情報（求人票の職務内容部分）を類似求人と比較し、改善のためのアドバイスを提示したり、そのアドバイスを反映した職務内容を生成するというものです。
このうち「アドバイスを反映した職務内容を生成する」部分に、LLMのGeminiを利用しています。
具体的には、GeminiのAPIに対して、HR forecasterの利用ユーザーが入力した元の職務内容と別システムで作成した改善アドバイスを渡し、
このアドバイスを反映した職務内容を生成してほしい
といった内容のシステムプロンプト（実際にはもう少し複雑です）を送る、といったシンプルな構成です。そのため、LLMの組み込み自体は比較的容易に実装できました。
一方で、事前に行った人力でのテストの時から、システムプロンプトで指定している一部の制約（文字数制限など）を満たさない出力が一定の頻度で発生していました。
致命的な制約違反はなかったものの、運用しながらLLMの性能を定量的に評価し、その結果をもとにプロンプトを改善していく必要性を感じ、評価基盤の整備に取り組むことにしました。
評価方法の検討
LLMがシステムプロンプトをどの程度守って出力しているのかを評価するため、実際の運用環境で継続的に品質を測定できる「オンライン評価」を中心に検討しました。
検討した手法は以下の4つです。
1. A/Bテスト
LLMを導入したパターンと導入していないパターンを比較し、ユーザーの行動の違いから有用性を検証する手法です。
ただし、今回のケースでは求人票という性質上LLMを使わない場合の代替文章を同条件で大量に用意することが現実的ではないという問題がありました。
求人ごとに前提条件や背景が大きく異なるため、A/Bテストに耐えうる比較対象を準備するのは難しく、実運用での評価には不向きと判断しました。
2. Good/Badボタン（明示的フィードバック）
ユーザーに対して「この生成結果は良かったか・悪かったか」を直接選択してもらう手法です。
実装コストが低く、主観的な満足度を直接取得できる点は魅力的でした。
一方で、実運用では評価数が安定しないことや、評価のバイアスが入りやすい点が課題でした。
満足度の参考指標としては有用であるものの、プロンプト改善に直接活かせるほど精度の高いデータを得るのは難しいと判断しました。
3. 暗黙的フィードバック
生成結果が実際にどの程度使われたかといった、ユーザーの行動ログから品質を推定する手法です。
例えば、GitHub Copilotなどでは補完内容をどの程度採用されたかといった情報から評価が可能です。
今回のシステムでも「全文コピー」ボタンの押下率などが候補となりましたが、コピー後に大きく変えられる可能性も高く、品質の直接的な指標として使うには不十分と判断しました。
4. LLM-as-a-Judge
LLMが生成した文章の品質を、別のLLMに評価させる手法です。
人が1件ずつ目視で確認する代わりに、「この文章は良いか・悪いか」「どこに問題があるか」といった判断をLLMに委ねることで、すべての入出力に対して継続的かつ定量的な評価が可能になります。
以上の検討から、
- A/Bテストは前提条件を満たすのが難しい
- Good/Badボタンや暗黙的フィードバックは満足度把握には使えるものの、プロンプト改善に直結するほどの詳細さは得にくい
という結論に至りました。
一方でLLM-as-a-Judgeはすべての入出力を機械的に評価できたり、問題点を理由付きで取得できるという点から、今回のユースケースに最も適した手法だと判断しました。
評価ツールの選定 & 採用した構成
LLM-as-a-Judgeを実装するにあたり、はじめに既存の評価ツールを調査しました。
Langfuse、LangSmith、DatadogのLLM Observabilityなどのトレース・評価・ダッシュボードまで揃ったSaaSは非常に魅力的でした。
一方で、
- 新規のSaaS導入には、社内での個人情報保護などの観点からの審査が必要で一定の時間がかかる
- 調査時点では、LLM-as-a-Judgeに利用できるモデルがOpenAI系に限定されており、Geminiなどを使えない制約があった
などの理由から、今回は既に利用しているGoogle Cloud上に自前で評価基盤を構築する方針としました。
元々Goで書かれたアプリケーションからVertex AIを呼び出してGeminiを利用していたため、Geminiによる生成結果をその都度BigQueryに保存し、日次バッチで前日のログをまとめて評価して結果を別テーブルに保存するという構成を採用しました。
LLM入出力の保存方法
次に、Geminiによる入出力をBigQueryに保存する方法について検討しました。
Vertex AIには、モデルのリクエスト・レスポンスを自動的にBigQueryに保存する仕組みがあります（リクエストとレスポンスをログに記録する）。
しかし、調査時の仕様ではログのフォーマットが固定で、求人票の職種や業種などの任意のメタ情報を追加できない制約がありました。
そのためこの機能は利用せず、アプリケーション側からBigQuery APIを直接呼び出し、必要なデータのみを保存する方式を選択しました。
これにより、後続の評価処理で必要となるメタ情報を柔軟に持たせることができるようになりました。
実際の評価方法について
実際の評価は、BigQueryに蓄積された生成ログに対して、日次バッチでまとめて実行します。
前日に生成されたデータを対象に、評価用のジョブを回してLLM-as-a-Judgeによるスコアリングと理由づけを行います。
評価には、Google Cloudが提供しているGen AI Evaluation ServiceのAPIを利用しています。
生成結果そのものを評価用LLMに渡し、
この出力がどの程度要件を満たしているか
をスコアと理由の形で返してもらいます。
実際に評価に渡しているデータは、
- 生成時に使用したプロンプト（元の職務内容や別システムで生成した改善アドバイスを含む）
- Gemimiから返ってきた実際の生成結果
です。これらをまとめて評価用プロンプトに組み込み、各観点で採点させています。
評価プロンプトについては、Google Cloudが公開しているGen AI Evaluation Serviceのモデルベース評価の指標プロンプトテンプレートを参考にしつつ、独自に作成しています。
具体的には下記のような複数の観点をそれぞれ用意して、1つの生成結果に対して複数の評価を実施しています。
- 文字数・形式など、プロンプトで指定した制約を守れているか
- 元の職務内容に含まれていない内容を勝手に追加していないか
- 固有名詞や数値を書き換えていないか
- 日本語として意味の破綻や不自然な表現がないか
評価結果は、評価した観点名・0〜5の評価スコア・評価理由を別テーブルに保存しています。
スコアだけでなく理由も保存することで、後続のプロンプト改善に利用できるようにしています。
実際のフィードバックとしては、固有名詞を書き換えてしまっている指摘や、元々書かれていない内容を追加してしまっているものなどが見られました。
このように、すべての生成結果に対して機械的に評価が回る仕組みを用意したことで、評価の属人性を極力排除しつつ、継続的に品質をモニタリングできるようになりました。
評価結果を使った改善
現段階では、評価結果は人がプロンプトを改善するための補助として活用しています。
具体的には、評価スコアが一定値を下回ったものだけを抽出し、担当者が内容を確認したうえで生成用プロンプトの修正を行うという運用です。
LLM-as-a-Judgeを導入しなければ、これらをすべて人力でチェックし続ける必要があるため、評価の自動化によって改善サイクルのスピードを大きく向上できると考えています。
また、どの制約が特に破られやすいのかといった、LLMの特性に対する知見も蓄積できるようになりました。
将来的には、評価から改善までをより自動化したいとも考えています。
例えば、DSPyなどのプロンプト最適化ツールを活用し、属人的な改善プロセスから脱却して評価と改善を継続的・機械的に回せる仕組みを目指しています。
もっとも、求人票というドメインの特性上、法令・倫理・ブランドトーンといった人による最終判断が不可欠な要素も多く存在します。
今後は、AIで自動化できる部分と人間が判断すべき部分を適切に分離したハイブリッドな運用を目指していきたいと考えています。
鈴木 健太 Kenta Suzuki
クライアントプロダクト本部 テクノロジー統括 プロダクト開発1部
2022年4月に新卒でパーソルキャリアへ入社。現在はHR forecasterのフロントエンドを担当している。
※2025年12月現在の情報です。
