こんにちは！SmartHRのタレントマネジメントプロダクト開発本部で PdE（Product Development Engineer）を務めるhoriyu、PdM（Product Manager）のabeto、QA（Quality Assurance）の3kiです。最近、急に寒くなりましたね。この記事は暖かいところで読んでください。
この記事を読んでくださっている皆さまは、生成AIと触れる機会が多いのではないかと思います。開発プロセスの改善だったり、開発しているアプリケーションの機能に組み込んだり様々な機会がありそうですね。 今回は、SmartHRの「HRアナリティクス機能」に生成AIを使った機能開発を行った際、どのようにアウトプットの評価に向き合ったかをお伝えします。
目次
前提知識
HRアナリティクス機能とは
HRアナリティクス機能とは、SmartHRで収集した従業員データを直感的に分析できる機能です。
分析スタートナビとは
分析スタートナビとは、HRアナリティクス機能に組み込まれた生成AIを活用した機能です。
2025/05/22 AIが分析の開始を支援してくれる「分析スタートナビ」を利用できるようになりました｜SmartHR
ユーザーが組織課題や組織の状況について知りたいことを自然言語で入力すると、次のようなアウトプットを出してくれます。
アウトプットは、入力された組織の課題に対して分析の示唆と、HRアナリティクスの分析機能に必要な軸の設定で構成されています。 また、分析スタートナビのおすすめ分析に表示されている分析の例をクリックすると、下の画像のような分析画面に遷移します。
アウトプットの評価に関する課題
記事のタイトルにもあるとおり、私たちはアウトプットの「揺らぎ」に関して向き合いました。
揺らぎとは、ユーザーの入力に対してこの機能が提案する分析の示唆の文章やおすすめ分析の種類が変わることを指しています。
例えば、LLMであればTemperatureなどのパラメーターを調整すればアウトプットを固定することができますが、今回の機能だとユーザーに対して柔軟に分析の示唆が出ることが価値です。
入力に対するアウトプットが固定である機能ならテストできますが、毎回変化するこの機能のアウトプットは一体どのように評価するとよいのでしょうか。
更に、この機能で利用している生成AIのモデルをアップデートすることがあったり、機能に追加仕様を反映することがあったりするかもしれません。 そういった場合にアウトプットが大きく変わったとして、何をもとに品質が保たれていることを担保できるでしょうか。
従来の仕様定義だけでは「品質」が測れない
このアウトプットの品質を評価しようとした場合、従来の仕様定義だけでは「どの程度の精度や回答内容ならよしとするか」の判断基準を言語化しきれません。
評価を行う前に、AIを活用した機能における「成功の定義」の明確化を進める必要がありました。
我々は解決したいユーザーの課題は大枠で理解できていたものの、実は「具体的にどういうアウトプットが出たら解決できた状態なのか」という詳細までは詰められていませんでした。
この成功の定義を明確化するために、ユーザーの利用シーンの解像度を高めることにしました。
ユーザーの利用シーン
テストケースを作成する前に「誰がどう使うか」を具体化することで、AIのアウトプットが「ユーザーにとって価値がある品質かどうか」を判断できるようになります。
※分析スタートナビのペルソナやユーザーシナリオは多く存在するため、一部抜粋して紹介します。
ペルソナの作成
まず、ユーザーの課題意識を言語化するために、以下の問いに答えながらペルソナを作りました。
- どんなユーザーが、分析スタートナビを使うのか？
- そのユーザーは、どんな課題意識を持っているのか？
- どんなデータや質問をするのか？
- 本当に解決したい困りごとは何か？
定義したペルソナの一例は次のとおりです。
佐藤さん
企業:従業員750名、60店舗のドラッグストアチェーン 職種:人事部 部長 特徴:IT業界の経験はない。人事データは扱うが、専門的な分析スキルに自信がない
ユーザーシナリオの明文化
ペルソナ佐藤さんをもとに「誰が、いつ、何に困り、何を期待するか」を言語化し、具体的なシナリオを作成しました。
法定資格の配置確認をするシナリオ
状況:店舗型ビジネスで、法定資格保有者の配置が法律で義務付けられている 課題:ある店舗の法定資格保有者が退職予定。他店舗から異動させられる候補者を探したい 入力:登録販売者の資格を持つ従業員が複数いる組織を見つけたい 期待するアウトプット:部署×資格取得状況のマトリクス 期待する価値:配置リスクの可視化、迅速な人材配置判断
ペルソナとユーザーシナリオが明確になったため、どういうアウトプットが出ればユーザーのニーズに応えられるか「成功の定義」の仮説を立てられるようになりました。 ここから、アウトプットに対する評価の観点を定義していきます。
評価軸の導出
佐藤さんのような人事部長にとって「良いアウトプット」とは何かを考え、ユーザーシナリオから評価軸を導き出していきます。 評価軸には次のような項目を考えました。
- 妥当性
- 提案された分析方法は、ユーザーの課題解決に適切である
- 例：資格保有者の配置確認に対して、部署×資格のマトリクスが提案される
- 有用性
- 実際にユーザーの意思決定を助け、次のアクションを取れる
- 例：佐藤さんが「どの店舗から異動させるべきか」を判断できる情報が含まれている
- わかりやすさ
- ユーザーが理解しやすい
- 例：分析初心者でIT経験のない佐藤さんでも、提案された分析軸の意味が理解できる
- 完全性
- 必要な情報が含まれている
- 例：資格保有者の配置状況だけでなく、分析の足がかりとなる情報も提示されている
- 一貫性
- 他のアウトプットと矛盾がない
- 例：同じ「資格保有者の配置確認」という課題に対して、毎回大きく異なる分析方法が提案されていない
評価方法の設計
評価軸が決まったら、具体的にどのような方法で評価するかを決めます。 分析スタートナビのアウトプットは一意にならないため、定性と定量の2つをバランスよく評価するアプローチを採用することにしました。
- 定性評価
- 重要なユーザーシナリオを実際のユーザー視点で詳細に評価する
- 人間が評価者となる「HUMAN as a Judge」を使用
- 定量評価
- 全体的な品質傾向を把握するために多数のケースを効率的に評価する
- LLMが評価者となる「LLM as a Judge」を使用
HUMAN as a Judge
HUMAN as a Judgeとは、実際のユーザー視点での品質を定性評価するために人間がアウトプットを評価する手法です。 LLM as a Judgeと対比させる形で、人間による評価を本記事では HUMAN as a Judge と呼ぶことにします。
この手法は、人間が手作業で行うため作業コストを加味してテストケースを20ケースほどに設定しました。 絶対に落としたくない主なユースケースを中心に分析スタートナビのアウトプットの妥当性、有用性、致命的な課題の有無をスコアにします。
LLM as a Judge
LLM as a Judgeとは、LLMを評価者として活用する評価手法です。 AIのアウトプットの品質やタスクの成果を、別のLLMに判定してもらうアプローチを指します。
従来では、HUMAN as a JudgeのようにAIのアウトプットを評価するには人間が一つひとつチェックする必要があり、時間がかかります。 LLM as a Judgeを使えば、大量のアウトプットを自動的に評価でき、開発サイクルを高速化できます。
- 回帰テストとして継続性の確保
- 新たなユーザーシナリオのカバー
それぞれの側面で100近くのテストケースを準備します。
中間まとめ
ここまでの流れを一旦まとめます。
- アウトプットの揺らぎを評価するために、ユーザーの利用シーンを具体化する
- ユーザーの利用シーンを具体化するためにペルソナを定義する
- ペルソナをもとにユーザーシナリオ（ユーザーの利用シーン）を明文化する
- ユーザーシナリオの評価軸を考える
- どのような方法で評価軸に基づいた評価をするかを決める
- 定量評価と定性評価を組み合わせる（LLM as a JudgeとHUMAN as a Judgeの併用）
では、次に6番の評価を可能にする評価基盤の実装についてお伝えします。
評価の基盤の実装
今回はGoogle Colabを使って評価基盤を実装しました。まずGeminiとColabを活用して理想の回答を含むテストケースを作成し、それをもとに「LLM as a Judge」と「HUMAN as a Judge」を実施しました。 さらに、プロンプトやロジックの変更があったタイミングで「LLM as a Judge」を実行し、品質を都度チェックできる体制を整えました。
テストケースの作成
まずはテストケースについてです。 分析スタートナビの回答は1つの入力に対して、2種類のアウトプットがあります。
- 分析をはじめるためのアドバイス
- おすすめの分析
機能開発やプロンプトの変更があった際に品質が担保できるように、2種類のアウトプットに対して期待値を作成しました。
入出力例は以下の通りです。
- 入力
- 若手がすぐ辞めてしまう、という課題感があります。
- 期待するアウトプット
- 分析をはじめるためのアドバイス
- 若手社員の早期離職という課題に対して、〜〜〜
- おすすめの分析
- 3年以内に早期離職した従業員の所属部署の傾向、年齢層ごとの役職者の人数、女性管理職の候補となりそうな従業員 など
- 分析をはじめるためのアドバイス
テストケースは以下の観点で用意しました。
- 課題の種類
- 離職防止、配置最適化、育成計画など
- 入力の表現方法
- 具体的な質問、抽象的な課題など
作成したテストケースはスプレッドシートでまとめていきました。
スプレッドシートにそれぞれの項目をまとめました。
- 入力
- テーマ
- 分析スタートナビで選べる分析のカテゴリ
- フリーテキスト
- ユーザーが入力する想定の文章
- テーマ
- 期待するアウトプット
- 回答
- 分析をはじめるためのアドバイス
- Geminiを使いながら人間が対話して作成
- おすすめの分析条件
- おすすめの分析
- Colabで作成
- 回答
このようにして、期待するアウトプットを作成しました。 特に、回答や分析条件の検証データの作成は、以下の手順で行いました。
1.分析をはじめるためのアドバイスの期待値作成
期待値を定義するため、Geminiで壁打ちしながら手動で回答データを作成しました。 このデータは、分析スタートナビのロジックやプロンプトを変更する際の検証で、変更後のアウトプットが理想から乖離していないかチェックするために使用します。 この理想に関しても、ペルソナの佐藤さんが読んだときに意味が伝わるかという観点で考えています。
2.おすすめの分析の期待値作成
次に、分析軸の検証データを作成しました。手順は以下の通りです。
- 最初に作成した分析スタートナビのロジックをColabに移植
- フリーテキストに対して実行し、軸の作成と選択を自動実行
- 人間がアウトプットをチェック
- 不足している軸があれば追加し、理想の軸セットを完成
LLM as a Judgeの実施
先程作成したテストケースをもとに、LLM as a Judgeを行いました。
今回はColabを活用して実施しました。
フリーテキストをColabに与えて、GitHub上で管理している最新の分析スタートナビのコードのロジックで判定させたらどう返ってくるかを見てみます。
- 理想の回答と、分析スタートナビの回答を出力
- 理想のおすすめの分析条件と、分析スタートナビが出力したおすすめの分析条件を出力
- それぞれを比較して評価
分析をはじめるためのアドバイスの評価方法は、LLMに人事データスペシャリストになってもらい期待する出力と分析スタートナビが出力した結果の差分を3段階評価（1:優れている、0:同等、-1:劣っている）でスコアリングしました。
また、おすすめ分析の評価方法は「期待するおすすめ分析の条件」が出力結果に含まれている場合に正解と評価するようにしました。
この評価により、客観的に定量的な傾向を把握することができました。
HUMAN as a Judgeの実施
さらに、定性評価のためのHUMAN as a Judgeも実施しました。
Notionに評価基準を明確に記載し、重要ユーザーシナリオをプロダクトチームメンバーで評価しました。
この評価により、定性的に実際のユーザー視点での品質を確認しました。
そして、プロンプトやロジックの変更があった際にLLM as a Judgeを実行し、都度チェックする体制を整えました。
結果を分析し、リリース可否の判定
ペルソナとシナリオを起点に設計した評価と、200ケースのLLM as a Judgeと、20ケースのHUMAN as a Judgeの結果が揃いました。
この結果を元にリリース可否の判断をしていきます。
リリースの判断基準
リリース可否は、以下の2つの基準で判断します。
- 必須条件（MUST）
- 必須ケースで過去の内容よりも劣っている評価がないこと
- ユーザーが困る致命的な問題がないこと
- 品質基準（SHOULD）
- 平均スコアが前回バージョン以上
- LLM as a Judgeを回帰テストとして活用して、継続的な品質向上を担保
どのような結果だったのか
LLM as a JudgeとHUMAN as a Judgeの評価結果を確認したところ、次のような結果となりました。
- 必須ケース
- 劣っているスコアなし
- 品質基準
- 前回バージョンから改善
基準はクリアできているため、ペルソナの佐藤さんのケースでも問題ないか確認しました。
法定資格の配置確認シナリオ
入力：「登録販売者の資格を持つ従業員が複数いる組織を見つけたい」 アウトプット：期待通りの「部署×資格取得状況」マトリクスを提案 評価：妥当性・有用性・わかりやすさ、すべて期待通り
もし佐藤さんがこの画面を見たら「なるほど、B店舗には複数いるのか。ではB店舗からの異動を検討しよう」と即座に判断できそうです。
リリース可否の判定に関して
今回の評価アプローチの特徴は、ペルソナとユーザーシナリオを起点に評価基準を設計したことにあります。評価基準・評価軸・テストケースはすべて佐藤さんというペルソナから導き出しました。そのため、最初から「佐藤さんのような人事部長が使える」ことを成功の定義としていました。
従来の「精度◯%」という数字だけの指標では、リリース判断の段階で十分な水準なのかという議論が生じたり、基準をクリアしてもユーザーにとっての使いやすさが保証されなかったりする課題がありました。
一方、今回のアプローチでは佐藤さんのような人事部長が配置リスクを見つけられるという具体的な価値を定義しました。この評価基準をクリアできたため、「佐藤さんが使える機能になった」と自信を持って言え、リリース判断を客観的に説明できるようになり、問題なくリリースの判断ができました。
まとめ
本記事では、生成AIを活用した「分析スタートナビ」の開発において、揺らぎのあるアウトプットをどのように評価し、リリースの判断を行ったかをご紹介しました。
評価の全体像としては、まず生成AI特有の「アウトプットが一意に定まらない」という課題に対し、ペルソナとユーザーシナリオを具体化することから始めました。そこから「妥当性」や「有用性」といった評価軸を導き出し、LLMによる大量データの定量評価（LLM as a Judge）と、人間による詳細な定性評価（HUMAN as a Judge）を組み合わせる仕組みを構築しました。最終的には、これらの評価結果をもとに、当初設定したペルソナが実際に課題を解決できるかという視点でリリースの判断をしました。
今回の機能開発を通じて得られた知見は、大きくわけて3つあります。
1つ目は、評価の基準を「精度の数値」から「ユーザー体験の質」に置くことの重要性です。単に正解率などの数字を見るのではなく、ペルソナが次の業務アクションに移れる情報が得られたかどうかを基準にすることで、技術的なスコアとユーザーへの提供価値を結びつけ、根拠を持ったリリース判断が可能になりました。
2つ目は、定量と定性の組み合わせが「アウトプットの揺らぎ」への対応に有効であることです。生成AIのアウトプットを完全に固定することは困難ですが、LLMによる全体的な傾向の把握と、人間による細かなニュアンスの確認を併用することで、AI特有の揺らぎを許容しつつ、品質を管理する現実的なアプローチを見つけることができました。
3つ目は、作成したシナリオが継続的な開発の基盤になるという点です。今回定義したユーザーシナリオとテストケースは、今後のモデル変更やプロンプト改善の際にも回帰テストとして機能します。これにより、継続的に機能を改善していくための土台が整いました。
生成AIを活用した機能開発では、プロンプトの調整だけでなく、こうした評価の設計まで含めてプロセスを組み立てることが重要だと実感しています。 本記事の内容が、同様の課題に向き合う方の参考になれば幸いです。
We Are Hiring!
SmartHRでは、AIの技術の活用だけでなく「ユーザーに価値を届けること」にこだわりたい方を募集しています。
評価手法もさまざまで突き詰めて考えると色々な種類があります。 評価の先にある「ユーザーにとって役に立つプロダクト」を目標にしたい方は、ぜひカジュアル面談でお話ししましょう。
