※記事公開時点（2026年6月）の内容をレポートしたものです。
- dodaダイレクトの理解とLLM化ポイント
- セッション概要
- AI施策の価値指標（施策単位）
- AIシステム価値（モデル性能）／PoC検証
- AIシステム価値（モデル性能）／PoC検証（AI施策特有の価値）
- ユーザーテスト段階の価値検証
- 落とし穴（後続のユーザーテストにて⋯）
- この落とし穴から得たPdM視点での学び
- プロダクト価値（顧客体験・行動・効率）
- まとめ
登壇者はこの方
鳥居 俊介
パーソルキャリア株式会社
クライアントプロダクト本部
プロデューサー
2018年パーソルキャリア入社。Webディレクター／PdMとして、スクラムチーム運営やプロジェクトマネジメントを経験。人材業界歴は10年以上。現在は「dodaダイレクト」にて、AI・LLMを活用した機能開発のPOとして、実装の推進や価値判断に取り組んでいる。プライベートではレコードコレクター／DJとして活動。日本ではまだ十分に紹介されていないブラジル北東部音楽〈Forro（フォホー）〉の研究・紹介に力を注ぎ、2026年4月にディスクガイド(※)を刊行予定。あわせて、1970年代日本ジャズの未発表音源の発掘にも取り組んでいる。
鳥居：皆さん、こんばんは。パーソルキャリアの鳥居と申します。
本日は「そのPoC、何を検証したつもりでしたか？ AIプロダクトの価値検証で陥った落とし穴」と題して、私たちがAIプロダクトを作っていく中で、検証時に見ていた指標や、進め方のところで陥ってしまった落とし穴の実例を交えながら、知見の共有をさせていただければと思っております。
私は現在、パーソルキャリアでクライアントプロダクト本部という法人向けのプロダクトを作る部署に所属しており、Webのディレクターやプロダクトマネージャー（PdM）としての仕事をしています。パーソルキャリアには2018年に入社しましたが、その前も人材系の会社で働いており、人材業界でのキャリアは10年以上になります。直近1年は、AIやLLMを活用した機能開発のプロダクトオーナー（PO）として、実装推進や価値判断に取り組んでいます。
私の勤めるパーソルキャリアは、人材紹介サービスや求人メディアの運営、転職・就職支援など、多様化する「はたらく」ニーズに応じて幅広く人材サービスを展開しています。
中途採用から副業・兼業支援まで幅広く展開する中、私は法人向けスカウトサービス「dodaダイレクト」に携わっています。
dodaダイレクトの理解とLLM化ポイント
dodaダイレクトの概要とAI（LLM）機能の導入
dodaダイレクトは、スカウト会員データベースを活用したダイレクトリクルーティングサービスです。人材紹介サービスや求人情報サービスと異なり、企業の方が直接データベースを見て、そこに自らスカウトを出すという能動的な採用サービスになっているため、利用企業側の積極的なアクションが必要となるのが特徴です。
企業のサービス利用フローを簡単に紹介します。まず求人票を作成し、その求人票を基にデータベースから求職者を検索します。スカウトしたい方が見つかれば文面を作成してメールを送信し、応募があれば面接を行います。
dodaダイレクト内のAI（LLM）機能
このdodaダイレクトの中で、AI（LLM）機能を使っている部分が2つあります。
まず、2025年にリリースした「スカウト対象者の検索条件設定」機能です。求人票があれば、その情報をもとにAIが居住地、年収、スキル、資格などの検索条件を自動設定します。ここにLLMの機能を使っています。
もう一つ、2026年夏にリリース予定の「スカウト文面生成」機能です。作成済みの求人票と求職者のレジュメ情報から、その人に合わせた最適なスカウト文面をLLMの機能で自動生成します。
セッション概要
それではセッションの本題に入ります。今回は、AI施策単位で価値をどのように検証したかの経験談をお話しします。
AI施策の価値指標（施策単位）
まず、AI施策の価値検証を施策単位で行うときに、どうやって指標を見ていくべきかを整理しました。ビジネスの成果を最終的な「価値」と置いたとき、私たちのdodaダイレクトの場合、以下の連鎖によってビジネス成果が生まれると定義しています。
- AI機能の場合：新しいAI機能の導入 → 業務改善（スカウト送信業務の効率化など） → ユーザー行動の変化 → ビジネス成果
- AIではない通常の新規機能開発（Not AI機能）の場合であっても、基本的な考え方は全く同じです。新しい機能によって業務改善が行われ、ユーザー行動に変化があり、それがビジネス成果につながってきます。
そのため、AI施策だからといって特別に見るべき価値が変わるわけではなく、最終的なビジネス成果やユーザー行動の変化といった価値の多くは、通常の機能開発と変わらないと私は考えています。
ただし、機能としての性能を評価する最手前の部分、つまり「AIの性能そのもの」を評価する部分においては、AI特有の独自の指標を持って評価していく必要があり、ここに通常開発との違いが生じてきます。
今お話しした内容を、違う角度から整理したのが上記の表です。私たちは価値を大きく「ビジネス」「プロダクト」「モデル」という3つのレイヤーで定義しています。
開発時は、そのアイデアや技術がそもそも成立するのかを検証する「PoC」と、作ったプロダクトが本当にユーザーに受け入れられるのかを検証する「ユーザーテスト」を明確に切り分け、これらの指標を確認しながら開発を進めました。
AIシステム価値（モデル性能）／PoC検証
PoC、ユーザーテストの違い
AIシステム価値（モデル性能）／PoC検証（AI施策特有の価値）
ここからは、私たちがPoC検証の段階で行った、AI施策特有の評価についてお話しします。
選択するLLMのモデルや、プロンプト（ステップを分割するなどの手法を含む）の組み合わせによって、アウトプットの品質や、APIの利用料金（コスト）が大きく変動します。企業として開発する以上は予算がありますので、「予算を超えてしまったから機能を提供し続けられなくなりました」ということが起きないよう、コストが見合うかどうかの実現性をしっかり見定める必要があります。
アウトプット品質評価指標例
また、アウトプットの品質評価についてですが、私たちの施策では求人票を読み込んで長文を読解するという処理があり、回答のブレが非常に起きやすいという課題がありました。そこで、そのブレも含めてしっかりと品質や一貫性を評価するために、AIの回答を大きく以下の4つに分類して発生確率をチェックするという工夫を独自に行いました。
- 期待の回答：求めていた正解が返ってきた
- 期待の一部のみ回答：正解ではあるが必要な要素の一部しか網羅していない
- 期待＋期待外の回答：必要な情報も入っているが、余計な外れ値も混ざっている
- 期待外のみ回答：完全に的外れな回答が返ってきた
これらを何度も繰り返し実行しテストを行い、どの回答がどの程度の確率で返るかを品質として評価しました。PdMだけで判断が不安な部分は、実際のユーザーに近い社内の立場の人を巻き込み評価を進めました。
補足
今回この資料をまとめるにあたり改めて調べて分かったのは、私たちが独自に「期待の回答」などと分類していた内容が、機械学習の分野で一般的な指標として既に用意されていたことです。
全体のうち正解した割合を示す「Accuracy（全体正解率）」、AIがYesと判断した中で実際にYesであった割合を示し無駄撃ちを減らす「Precision（的中率）」、本来Yesのものをどれだけ取りこぼさずに拾えたかを示し見逃しを防ぐ「Recall（再現率）」、そしてこれらのバランスをまとめた「F1スコア」です。もし私と同じように知らなかった方がいれば、これらの指標を活用するとスムーズかと思います。
ユーザーテスト段階の価値検証
私たちは、この回答品質の評価と合わせて、作業時間がどれくらい削減できそうか、リードタイムが短縮できそうかといった部分も、体感として削減につながりそうかをユーザーにヒアリングしながら評価を進めていきました。
こうして検証を重ねていく中で、AIシステム価値、つまり回答の精度や安定性については問題なく「OK」という状態を確認することができました。さらに、ユーザーへのヒアリングからも「今回の回答精度なら確実に効率化につながる」というお声をいただき、LLM部分をリリース可能な品質まで磨き上げることができました。
この段階では、プロジェクトは非常に順調で、いよいよリリース間近だなと思って進んでいました。しかし、そんな中で今回、大きな落とし穴に直面することになります。
落とし穴（後続のユーザーテストにて⋯）
回答精度もバッチリで、これはもういけるだろうと思って進めていたのですが、その後のステップである「顧客体験やユーザーの行動」をチェックするために、さらに一歩踏み込んだユーザーテストを実施したときに課題が発生しました。
具体的に起きたのは、ユーザーが業務を行う際、「必須項目A」と「必須項目B」の2つを埋めて送信する設計でしたが、今回の機能で自動生成されたのは「項目A」のみでした。
ユーザーテストの中で、実際のユーザーから以下のようなフィードバックをいただきました。
「必須項目AとBのうち、項目Aだけが自動生成されても、項目Bが自動生成されないままで自分で埋めなければいけないのなら、このAI新機能はわざわざ使わないかな」
最初の企画段階での検討不足と言われてしまえばもちろんその通りなのですが、私たちが今回深く反省した点としては、直前のフェーズで「AIシステム価値（モデルの性能や精度）」を磨き込むこと、その評価指標を検証することにばかり、チームのパワーと集中力を注ぎすぎてしまっていたということです。
その結果として、ユーザーの体験や行動に関わるテストがどうしても後回しになってしまいました。そして、いよいよリリースが見えてきたというプロジェクトの後半戦になってから、この致命的な体験上の見落としが発覚したのです。
最終的には、途中で開発のスコープを急遽変更して項目Bの対応も入れることになり、結果としてスケジュールの遅延が発生してしまいました。
この落とし穴から得たPdM視点での学び
今振り返れば、AIの精度検証と、このユーザー体験のテストは、もっと早い段階から並行して実施することが十分に可能だったなと感じています。
どうしてもAIやLLMを活用した施策になると、その技術の新しさや「本当に正しい答えが返ってくるのか」という精度の部分にばかり、PdMもエンジニアも、そして周囲のメンバーも注目が集まりがちになります。そこに目がいってしまうのはある種仕方のないことかもしれませんが、そこをPdMが冷静にコントロールしなければなりませんでした。
「精度」を磨き込むことと同時に、「体験」のテストも並行して進められる部分をしっかり見つけ出して、早い段階から検証を回しておく。そうすることで、今回の私たちのような大きな手戻りやスケジュールの遅延は防げたはずだと、身をもって学びました。
プロダクト価値（顧客体験・行動・効率）
手戻りの話から少し指標の整理に戻りますが、後半のユーザーテストやリリース後に見ていく「プロダクト価値（顧客体験・行動・効率）」については、一般的な指標を設定しています。
具体的には、価値到達時間（Time to Value）や利用継続率、DAU/MAU、タスク成功率、提案採用率、リードタイム短縮、作業時間削減率などです。これらはAIを搭載していない通常の機能開発でも日常的に確認している指標が中心になります。
AI施策におけるこれらの指標の捉え方としては、AIを入れたことによって「ユーザーがこれらの指標の成果をより出しやすくなったか、目標に届きやすくなったか」という観点で評価するのが良いのではないかと考えています。
そして最終レイヤーである「ビジネス価値（最終価値）」についても同様です。売上や利益、コンバージョン率（CVR）、解約率・継続率、コスト削減額、ROIなど、AIが最終的に生み出した事業成果を見ていきますが、こちらもAI施策の外側で追っている通常の指標と変わりはありません。
まとめ
今回の内容をまとめます。今回は「AIの施策単位」で導入した場合の価値検証について説明しました。
まず、モデルレイヤーの「AIシステム価値（モデル性能）」では、AI特有の価値指標（Accuracy、Precision、Recall、F1スコアなど）を正確に把握し、性能検証を行う必要があります。
次に、AI施策で注目する「プロダクト価値」や「ビジネス価値」の指標は、AIを使わない他の施策でも共通する指標が中心です。自社プロダクトの特性に合わせて適切に設定することが重要です。
最後に、私たちの大きな学びである落とし穴です。AI施策では「AIシステム価値（精度）」の検証に偏りがちですが、手戻りを防ぐために、早期から「プロダクト価値（顧客体験・行動）」のテストも並行して行ってください。
最後に・・・AIプロダクトの価値検証（非経験談）
これは私の経験談ではなく、現在の私の考察、非経験談としての話になりますが、一口に「AIプロダクト」と言っても、大きく2つのアプローチがあると考えています。
1つは、私たちが今回実践したような「既存サービスの一部をAIに置き換える」というアプローチです。これは短期的なROIが見えやすく、リスクも低いですが、他社との大きな差別化という面では少し弱くなる特徴があります。
もう1つは、「最初からAI前提でサービスを設計する」というアプローチです。こちらは中長期的な価値や圧倒的な競争優位性を生み出す可能性がありますが、その分リスクも非常に高くなります。
自分が今作ろうとしているプロダクトがどちらのフェーズ、どちらのアプローチにあたるのかによって、追うべき指標の設計や検証の進め方も変わってくるのではないかと思います。今後そういった開発にも挑戦していきたいと考えつつ、私からの発表を終了とさせていただきます。
最後にもう一つ紹介します。パーソルキャリアのエンジニアリング組織の「技術」「人」「組織」については、技術ブログ「techtekt（テックテクト）」で発信しています。私たちの組織に興味がある方は、採用サイトもご覧ください。
▼▼ ぜひ他登壇者の発表レポートもご覧ください！
