※記事公開時点（2026年6月）の内容をレポートしたものです。
登壇者はこの方
田中志樹
パーソルキャリア株式会社
カスタマープロダクト本部
ゼネラルマネジャー
日系電機メーカーのISカンパニーに新卒入社。2014年よりリクルートキャリア(現: 株式会社リクルート)にて、中途転職領域のWEBサービスデザインに従事。その後、電通デジタルにて、大手通信キャリア様のDX支援コンサルタント、楽天にて、ECならびにポイント領域におけるプロダクトマネージャー職を経験。 直近では組織開発や企業DX戦略の立案、生成 AI 活用、UX やデザイン思考による０→1 フェーズでのサービス設計に注力しており、2021年10月からは鉄道・不動産事業会社における内製開発組織の立ち上げに参画。2024年7月より現職にて、PM組織強化やプロダクト戦略の策定/推進に従事。
渡部愛美
パーソルキャリア株式会社
カスタマープロダクト本部
リードディレクター
2020年より株式会社IBJにて婚活パーティー集客サイト・アプリのディレクターとしてマーケから申し込みCVRの改善、業務ツールの改修まで幅広く経験。2023年よりパーソルキャリア株式会社にてdodaの求人紹介サービスにおける応募・決定増加をKPIとしたプロジェクトに携わる。直近ではdodaにおけるAIエージェントプロジェクトのプロジェクトリーダーとして中長期的なユーザー体験設計などを担当。
渡部： 皆さん、よろしくお願いいたします。パーソルキャリアの渡部と申します。私からは「正解のないAIプロダクトをどう導くか？ 『doda』が挑む、ユーザーの『本音』を構造化する評価設計と検証のリアル」というテーマでお話しさせていただきます。
私たちが日々AIプロダクトと向き合う中で、どんなことを踏まえてプロダクトを実現しているか、AI特有のプロダクトだからこそ行う最小限の検証や評価の現実を共有します。
私は現在、カスタマープロダクト本部サービスデザイン1部でリードディレクターを務めています。2023年にパーソルキャリアに入社し、dodaで主に転職希望者向け（ToC）のAIエージェント活用プロダクトの設計や、ユーザー体験設計のプロジェクトリーダーを担当しています。
田中： 同じくカスタマープロダクト本部でゼネラルマネジャーをしております、田中志樹と申します。私たちの組織は転職希望者向けのプロダクト開発を担う本部となります。
私は今の会社で6社目です。転職ビジネスに関わるのは2回目で、10年前に別の大手転職サービスで求人事業に携わりました。現在はパーソルキャリアで、10年ぶりにこの領域の戦略策定とPM組織の強化に取り組んでいます。
本日のアジェンダ
渡部： 本日は大きく3つのトピックスについてお話しします。
- HR業界におけるAIプロダクト事例
- dodaでのAIプロダクト開発・検証事例
- これからのAIプロダクトの価値評価について
doda全体というよりは、ユーザーに提供する価値のうち「この部分をこういう手法で検証した」という、現場発のリアルなトピックスをピックアップしてお伝えします。そして最後に、本カンファレンスの核心である「何をもって成功とするか」の評価設計について、田中からお話しさせていただきます。
HR業界におけるAIプロダクト事例
皆さんもご存知の通り、HR業界におけるAI活用の波はとにかく激しく、日々新しい機能がリリースされています。下記の表に一部をご紹介します。
国内では売り手市場なので、転職希望者向けの機能が充実している一方、海外は買い手市場のため、選考側の機能が充実している印象です。
特に海外の大手求人検索サービスや国内のビジネスSNS・採用プラットフォームなどの事例を見ると、AIが転職希望者の転職価値観や希望条件について対話形式でヒアリングし、最終的な求人提案へと繋げていくサービスのフローが出来上がってきている印象を受けます。これは、転職希望者の強みや潜在的な希望をAIによって整理・言語化することで、転職活動への行動促進に繋げることを目的としているのだと推察しています。
dodaとしても全く同じものを作るわけではありませんが、ユーザーが転職活動を検討する初期段階において、「キャリアアドバイザーに相談するのは少しハードルが高い」と感じる領域はまさにここにあると考え、開発を検討しています。
dodaでのAIプロダクト開発・検証事例
【doda事例1】職務内容生成機能（キャリアアドバイザー業務ツール）
求人紹介サービスにおいて、カウンセリング時に同意の上で記録したキャリアアドバイザーと転職希望者の面談音声を、AIが解析・要約して「職務内容」のサマリを自動生成する機能です。生成された文章をdodaのマイページ上で提案し、ユーザーが確認・修正した上でそのまま職務経歴書に反映・活用できるようにしました。
このリリースにあたり、私たちは3つの検証ステップを踏みました。
- STEP 01：初期技術検証（技術的実現可能性の担保、モデル・プロンプト・インプット型のFIX、基本品質の確認）
- STEP 02：リリース前技術検証（大規模データによる網羅的な品質の厳密判定、エッジケースの検証、人手による定量スコア判定）
- STEP 03：UAT/最終検証（本番同様の統合環境における業務担当者のUAT、UI/UXやレスポンス速度の確認、リリース判定）
特に「STEP 01：初期技術検証」では、同じインプットデータをいくつかのユーザーケース（型）に分け、異なるLLMモデルに差し込んで「コスト」「生成時間」「品質」の3軸で評価を並べました。コストはトークンあたりから年間コストを試算し、生成時間はユーザー体験に直結するため秒数単位で比較しました。
品質評価においては、本機能の特性上、生成された文章がそのまま応募書類として使われる可能性があるため、カウンセリングで話していない情報をAIが勝手に作らないことが最重要でした。そのため、以下の独自の7観点を定義し、LLM精度検証と人手のスコアリングで厳密に評価を行いました。
- 網羅性：全ての出力項目と内容が漏れなく記載されているか。
- 正確性：入力内容と異なる（根拠のない）情報がないか。また、音声データ内で矛盾する発言があった場合、より頻度の多い内容を事実として正しく採用できているか。
- 関連性：保有スキルや経験の中で、希望職種に必要な内容が重点的に書かれているか。
- 公平性・バイアス：性別、年齢、国籍など不当なバイアスの可能性がないか。
- コンプライアンス：個人情報や機密情報の漏洩リスクがないか。
- 具体性：成果や業務内容が具体的に記載されているか。
- 簡潔性：端的でわかりやすい文章となっているか。
【doda事例2】AIエージェント企画時のユーザー調査
AIによる伴走を行うにあたり、「どこをAIで代替し、どこを人間が担うべきか」を明確にするため調査を行いました。 まずアンケートによる定量調査でユーザーのAI活用度や伴走を希望するシチュエーションを可視化しました。その後、異なる状況のユーザー4名に対して過去のフォロー体験を深掘りする定性インタビューを行いました。 これにより、ユーザーが求める「パーソナライズ（自分だけに寄り添ってくれる感覚）」の要素がエピソードベースで明らかになり、AIの問いかけ方の要件に大いに活かすことができました。
【doda事例3】Difyを活用したプロトタイプ調査
会話ベースのAIモジュールがユーザーの「応募」などの行動促進に本当に繋がるのかを確かめるため、「Dify」を使ったミニマムな検証を行いました。 DifyはノーコードでAIアプリやチャットボットを作れるため、社内のエンジニアの工数を最小限に抑え、ディレクター陣だけでプロトタイプ画面を構築しました。これを用いて、直近で転職活動を行った社内ユーザーにインタビューを実施し、5段階評価と定性コメントを集めました。
評価項目としては、「納得感（自分でも気づいていなかったポイントを整理してくれるか）」や「自分のことを言っていると感じる（パーソナライズ）」を重視しました。また、「事業性」を見極めるために「お金を払ってでも使いたいと感じるか（1回あたり、月額あたりいくらか）」という利用意向をヒアリングできたことも大きな収穫でした。
さらに、AI特有の「毎回異なる流動的な受け答え」をエンジニアに要件書として言葉で説明するのは非常に難しいのですが、この動くDifyプロトタイプをそのまま開発チームに渡すことで、仕様のイメージをズレなく共通化させる上でも役立ちました。
これからのAIプロダクトの価値評価について
田中： ここからは「これからの話」として、私たちが今まさに構築している最中の評価設計の仮説を共有して、セッションを締めくくりたいと思います。
これからの話
LLMを活用した機能を開発していく中で、皆さんも「それって本当に事業価値を生んでいるの？」という疑問にぶつかるのではないでしょうか。
今回のイベントの匿名コメントでも、「LLMが作った綺麗すぎる職務経歴書のおかげで書類は通るけれど、実際の面接で本人がその通りに話せなくて失敗してしまう」というリアルなご指摘をいただきましたが、まさに私たちはその事象を認識していますし、それは決して良い状態ではないと考えています。転職希望者にとっても、私たちの事業価値にとっても、本当に「成功」とは言えません。
LLM品質「だけ」では事業価値に届かない
- 「答えは正しい（品質は高い）けれど、誰も使い続けない」
- 「1つの機能だけで利用が止まり、横に広がらない」
- 「ユーザーは満足しているけれど、応募数は伸びない」
なぜこのようなことが起きるのかというと、これまでのプロダクト評価は、一番下のベースにある「AI品質・利用・コスト（層1）」の話ばかりに議論が集中し、一番上にある「事業価値（層3）」へと直接結びつけようとしていたからです。この「層1」と「層3」の間にあるべき、ユーザーの「価値体験量（層2）」という中間層がごっそり欠落していたことこそが、最大の課題だと考えています。
AIの品質（INPUT）は、ユーザーの「価値体験量」を介してはじめて、応募数や継続利用といった「事業価値（KGI）」へと繋がります。
モジュール価値到達率（仮説）
私たちはここを繋ぐために、プロダクト内のAIモジュールがどれだけユーザーに価値を届けられたかを示す「Module Value Reach（モジュール価値到達率：MVR）」という指標を関数として定義しました。
MVR = f(Breadth, Depth, TTV, Outcome Rate)
- Breadth（利用幅）：プロダクト内の全AIモジュールのうち、どれだけ広く触れてもらえたか（利用モジュール数 / 全提供モジュール数）。
- Depth（利用深度）：そのモジュールをどこまで使い込んでもらえたか（モジュール内ステップ完了率の加重平均）。
- Time to Value（速度）：利用開始から、ユーザーが「これ良い！」と価値を実感するまでの時間がどれだけ短かったか。
- Outcome（成果到達率）：そのモジュールが掲げるゴール（成果）に到達したセッションの比率。
例えば、職務経歴書生成モジュールにおいて、AIが出力した後に「実際にマイページに反映した人」と「反映せずにやめてしまった人」がいます。後者は「なんか違うな」と思って離脱しており、価値を享受できていません。この成果を測る上で、私たちは「Containment Rate（チャットが終了したという、解決された『風』の割合）」ではなく、「Resolution Rate（ユーザーの課題が実際に解決した割合）」を厳格に採用しています。AIが勝手に会話を終わらせて「解決したとみなす」のではなく、ユーザーが本当に目的を達成したかどうかに徹底的にこだわっています。私たちからの発表は以上です。
パーソルキャリアのエンジニアリング組織の「技術」「人」「組織」については技術ブログ「techtekt（テックテクト）」でも発信しています。また、私たちの組織に興味をお持ちの方は、採用サイトもご覧ください。
▼▼ ぜひ他登壇者の発表レポートもご覧ください！
