リクルートのプロダクト制作におけるナレッジをシェアするイベント「プロデザ！ BY リクルート」。第19回目となる今回のテーマは「PdM×AI 活用　社内のAI活用事例と活用促進のための取り組みを大公開！」。

プロダクトデザイン室では近年、業務やサービスにおける生成AIの活用推進に取り組んでいます。個々が自身の業務に導入するだけでなく、組織全体にAI活用を広げる取り組みや、実際のサービスに一部、生成AIを組み込む動きも出てきました。

そこで今回は、「組織全体に生成AIの活用を広げる取り組み（登壇者：夏目大地）」、「個人の業務における生成AIの活用事例（登壇者：黒羽健人）」「具体的なサービス（じゃらんnet）への導入事例（登壇者：三浦泰嗣）」について、それぞれの取り組みの一部を紹介します。

 ※2024年5月28日に開催したオンラインイベント「プロデザ！ BY リクルート　PdM×AI 活用　社内のAI活用事例と活用促進のための取り組みを大公開！」から内容の一部を抜粋・編集しています。

夏目大地「生成AI活用を推進している『プロダクトデザイン室AI活用PJ』の取り組み」

プロダクトデザイン室AI活用プロジェクトのコンテンツ推進チームリーダーをしています、夏目大地と申します。

AI活用プロジェクトの主な目的は、組織の業務生産性向上です。そのなかで私が所属するAIコンテンツ推進チームでは、「生成AIの活用人数を最大化すること」に注力してきました。私からはその具体的な取り組みについて紹介したいと思います。

まず、取り組みを行う前のプロデザ室の生成AI活用状況からお話ししますと、2023年の10月時点では「少し使ったことがある人」を含めた経験者は28%ほどでした。私たちはこれを45%まで引き上げることを目標に、前期の取り組みを進めました。
 
取り組みを進めるにあたり、はじめに3つの「属性分解」を行いました。まずは生成AIを全く使ったことがない「生成AI未経験者」。次に、少しだけ使ったことがある「生成AI試行者」。そして、積極的に使っている「生成AI活用者」です。
 
この属性分解をふまえ、私たちAIコンテンツ推進チームがとったアプローチは主に以下の２つです。

1. 生成AIの「試行者」を増やす施策

2. グループ単位で「ハブとなるAI人材」の育成をする

まずは（1）の施策について説明します。当時は未経験者が70%以上もいたため、まずは「試行者」の割合をより増やしていこうと考えました。そのために、具体的には次のような施策を行っています。

このうち特に効果的だったのは、まず「各グループ・組織への行脚」です。とにかくいろいろな組織を回り、ひたすら生成AIについてレクチャーしました。時間と手間はかかりますが、これはめちゃくちゃ効果があったと思います。ちなみに、各組織へレクチャーするにあたっては、組織ごとにカスタマイズした内容にすることも大事なポイントです。
 
また、「生成AIについてのイベント」も効果的でした。イベントには生成AIの界隈で有名なインフルエンサーや有識者を講師にお招きするなど、関心を持ってもらうよう努めました。結果、イベントを重ねるごとに生成AIに対する熱が高まっていった実感があります。
 
それから「生成AIの勉強会」も定期的に実施しました。ポイントは、あくまで初心者に興味を持ってもらえるテーマや内容にすること。たとえば「音楽生成AI」などの面白い生成AIを紹介する勉強会は、かなり好評でしたね。

次に、2つ目のアプローチである「グループ単位でハブとなるAI人材の育成をする」について紹介します。先ほどは「生成AI未経験者」から「試行者」の割合を増やすための施策でしたが、こちらは「試行者」から「活用者」へと昇華させるための施策になっています。

どんな施策か簡単に説明すると、最初のフェーズでは各組織から「ハブ」となるエバンジェリスト候補を選定します。そして、選定したエバンジェリスト候補に対して個別に生成AIのスキルやナレッジをレクチャーしていきます。

次のフェーズでは、その人たちと一緒に「業務で使えそうなプロンプト」を磨き込み、プロンプト以外の有効な活用筋を提案し、実践してもらいます。そうやってある程度のレベルに到達したら、あとはエバンジェリストとして自分が所属する組織のメンバーや案件に伝播させていく。これが大まかな流れです。
 
なお、この「ハブとなるAI人材を育成する施策」（伴走支援施策）で大事にしていたポイントは以下の3つです。

まずは「熱意のある人を案件主担当（エバンジェリスト候補）として配置してもらうこと」。熱意がないと、どうしてもおざなりになってしまい、あまり良い成果は得られません。「本気で生成AIを使いたいんだ」という、熱い思いを持つ人をアサインすることが大事です。

次に、「業務・ビジネスプロセスが可視化されていること」です。僕らがサポートするにあたって、支援対象者の業務が可視化されているとアドバイスがしやすくなります。そして、「案件インパクト（＝ROIインパクト）が大きい案件を選ぶこと」。これはエバンジェリストたちが各組織にスキルやナレッジを持ち帰った際に、より効果がある案件のほうが生成AI活用の価値を実感してもらえるためです。

これらの取り組みにより、生成AIの経験者が28%から65%まで増加。当初、目標としていた45%を大きく上回る結果でした。また、伴走支援施策によって業務効率化につなげることもできました。たとえば、生成AIの活用によって企画案の作成業務は約23%短縮、タイトル作成業務は約44%短縮できた事例があるなど、かなりの成果を残せています。
 
最後に、今後の展望です。今回の取り組みによって生成AI経験者を増やすことはできました。しかし、そこから先、「生成AI試行者→生成AI活用者」に昇華させるのは大きなハードルがあります。そこで、今期はこのハードルを超えるために活動していきたいと思っています。私の発表は以上です。

黒羽健人「生成AIでUXリサーチ業務を効率化」

黒羽健人と申します。夏目からは組織としての生成AI活用について説明してもらいましたが、私からは個人が業務のなかでどう生成AIを使っているかについて、わりと入門編になるかと思いますがお話しします。ちなみに、私自身は会社のUXリサーチ業務で生成AIを活用しているほか、副業でアバターを使った習慣化アプリをつくっていたりします。

では、実際に私が日々のUXリサーチ業務のなかで生成AIをどう使っているのか。かなりざっくりとですが、次のようにまとめました。

こちらはUXリサーチ〜プロダクト企画のプロセスにおける、生成AIの活用場所をまとめたものです。このなかで特にお話ししたいのは「リサーチの必要物の作成」と「事前リサーチ」「リサーチ用プロトタイプの作成」の3つです。
 
まず「リサーチの必要物の作成」ですが、具体的には「リサーチのクエスチョン」「仮説」「仮説検証の基準」「それをユーザーにどう質問するか？」「各質問に割ける時間」それぞれの一次案を作成したり、原案をブラッシュアップしてもらったり、といったところで、生成AIを活用しています。

特におすすめの使い方としては、たとえばインタビューのスプリクトなどをスプレッドシートやNotionで作る方は多いと思いますが、その際に「どの質問に何分かかるか？」も含めて設計しますよね？その際、質問のリストを変えるたびにいちいち「この質問は5分くらいかな？この質問は3分くらいかな？」と、スプシの数字を変えながらやるのはしんどいじゃないですか。そこで生成AIを活用します。質問を変える時に「この質問表の時間配分を考えて？」と投げると、生成AIがぴったりの時間を設定してくれるので、かなり便利ですね。

次に「事前リサーチ」ですが、このプロセスで言いたいのはPerplexity というツールがとにかく最強だということ。ざっくり言うと、リソース付きで回答を返してくれるAIです。なおかつ、「あなた、この質問をしたってことは、この質問も興味あるんじゃない？」という感じで、どんどんリサーチクエスチョンを辿ってくれるため、勝手にリサーチが進んでいくんです。本当に便利なので、まだ使ったことがない方はぜひ試してほしいです。
 
そして、3つ目が「リサーチ用のプロトタイプをAIで作成」。テキスト系ならGPTのBuilder、動画系ならVrewという動画生成系のAIを使うと便利ですが、たとえば「リサーチ用のプロトタイプを15分で１つ作る」みたいなこともできます。

これは今回の発表のためにGPTのBuilderで作ったものです。インタビューの後って、面倒な工程が多いですよね。インタビューの音声を文字起こししたり、QAの形にまとめたり、示唆を出したり、課題を構造化したり。どれも大事なことですが、かなりの労力がかかる。
 
そこで作ったのがこの「インタビュー後工程助けるくん」です。PDF化した文字ファイルをこちらにアップロードするとQA形式の表に直してくれたり、それを課題の構造化みたいな形にKJ法で出してくれたり、そこからアクションアイテムを出してくれたりします。
 
具体的な活用イメージとしては、たとえば、プロダクトについてのインタビュー中に「新しくこういう機能があるといいんだけど」といったフィードバックをもらったときに、これまではいったん持ち帰って検討しなければいけなかった。ただ、GPT Builderでのプロトタイプを使えばその場でプロンプトを打ち直して「こういうことですか？」とそのユーザーに再提案することができる。バージョン0.2、バージョン0.3くらいの提案をすぐにでき、プロダクトの開発スピードも加速した実感があります。
 
また、メンバー間で「今から1時間使って、PRD（プロダクト要求仕様書）をもとにみんなが思うプロトタイプを作ってみよう」となったときにも、プロトタイプに落とすことで「君はそこを大事だと思っていたんだね」みたいなことが分かる。Figmaを使えなくても、コードを書けなくても、プロンプトさえ書ければ、つまり自然言語さえ書ければできてしまうわけです。
 
最後に、生成AI活用の心構えのようなものを共有して終わりたいと思います。

わりと当たり前のことばかり書いていますが、特に言いたいのは最後の「試行の質を上げる」ことです。

試行の質を上げるためにおすすめなのは、（休日の個人活動として）自分が担当するプロダクト領域のサービスを簡易的にトレースしたものにChatGPTのAPIを組み込んでみて、挙動を知ること。そうすると「生成AIってどこまで使えるんだろう？」みたいな部分の解像度も上がるので、学習として有効です。私の発表は以上です。

三浦泰嗣「生成AIを活用したプロダクト『じゃらんnet』の紹介とAI活用までの検討プロセスについて」

三浦泰嗣と申します。2019年にSlerからリクルートへ中途入社して以降、『じゃらん』のサービス改善のための基盤開発を行っています。私からは、『じゃらんnet』における生成AI活用の取り組みについてお話しします。

『じゃらんnet』では、2023年5月から生成AIを用いた「対話型UI」を試験的にユーザーに提供開始しています。対話型UIの機能について簡単にご紹介しますと、ユーザーとの対話を通して宿のニーズを掘り下げたうえで宿を検索し、実際に予約をするというものです。

この画面上でユーザーが「大人2名で部屋一つお願いします」とか、「箱根で宿を探しています」というふうに発話をします。すると、その発話内容を生成AIが解析し、検索条件に変換します。そして、検索条件がまとまったら「じゃあ宿を探しますね」ということで、バックで生成AIが宿を探しまして、最終的に「こちらの宿が見つかったのでご提案させていただきます」といった形で、検索条件をもとにしてユーザーに宿をご提案する、といった機能になっております。

画面だけ見ても分かりづらいと思うので、具体的に内部ロジックでどのように生成AIを使っているかを少し紹介します。サービスとしては、ユーザーが発話した要望をバックで生成AIのほうに流してユーザーの発話を理解し、もろもろの処理をしていくのですが、この際にユーザーの発話内容と対話のフェーズに応じて大きく三つの機能があります。それが「エリア誘発」「エリアのアピール文の生成」「宿のアピール文の生成」です。
 
順番に説明していきます。まず、「エリア誘発」はユーザーから具体的に行きたいエリアが指定されなかった場合に発動する機能です。例えばユーザーが「どこかの温泉に行きたいんだよね」と発話した場合は、まだ具体的なエリアが指定されていません。そこで、サービス側から「だったら箱根の温泉エリアはどうですか？」といった感じで、発話をもとにしてユーザーに対してエリアの方向を進める。それによって、ユーザーのエリア探しをスムーズにしていくための機能になっています。
 
２つ目が「エリアのアピール文の生成機能」。ユーザーとキャッチボールをして、最終的にユーザーに提案するエリアの方向が複数存在する場合に発動する機能です。例えばユーザーが「東京から車で2時間ぐらいで行ける温泉郷に行きたいです」と発話した場合に、サービス側が提案するエリアの候補が複数あるとします。そうなると、ユーザーとしてはどちらを選べばいいか迷いますよね。その際に、生成AIが「エリアの魅力」を訴求するアピール文を作成し、ユーザーの決断を後押し。納得感を持ってエリアを選択できるようになります。例えばさっきの条件でいうと、アピール文としては「このエリアは近くに高速道路も通っているので、車でのアクセスがいいですよ」や、「このエリアは周辺にアクティビティがあるので、温泉旅行のついでに遊びに行くこともできますよ」など、ユーザーが指定した条件に合わせてこのエリアの魅力を伝えるアピール文を生成します。
 
３つ目が「宿のアピール文の生成機能」です。エリアのアピール文と同様に、ユーザーとサービスがキャッチボールをし、条件を指定して宿を検索しますと、最終的にサービス側から複数の宿を提案します。この際に宿の魅力を伝えるようなアピール文を生成して、ユーザーの宿選びをサポートします。以上が内部ロジックの説明でした。
 
次にプロダクトを作っていく上で意識したことを紹介します。

1つ目は「トークフローを定義し、そのポイントポイントでユーザー体験を引き上げるような機能を提供する」。これは「ユーザーがどんなふうにサービスと対話をしながら宿を探しているか」のフローを一つひとつ[足真1] ユーザー面で定義し、その上で、「じゃあ、どういうポイントで生成AIを機能として介入させていけば、ユーザーの対話を通しての宿の検索体験を引き上げられるか」を意識しながら、必要なポイントで機能を開発して提供するといったことを行いました。
 
２つ目は「プロンプトインジェクションの対策」です。これは生成AIを使っているサービスではよくあることですが、「ユースケースに沿った発話（今回の場合は旅行に関する発話）かどうか」を生成AIでスコアリングしまして、仮に「これは今回のユースケースとは関係ありませんよね」と判断した場合には、定型文を返すという形でプロンプトインジェクションの対策を行っています。
 
最後は、プロダクトづくりの苦労話をさせていただければなと思います。

まず、生成AIはプロンプトを修正すると内部の振る舞いが変わってしまうので、回帰テストを回して望ましい品質になっているかどうかのチェックが必要でした。

とはいえ、プロンプトをちょっと修正したり、あるいはコードを改修するたびに生成AIの出力結果を全部チェックして回帰テストを回したりするのは、とても工数がかかる作業です。今回の開発では、生成AIの出力結果の確認自体も生成AIにやらせようとしましたが、精度面をクリアできずに挫折してしまいました。
 
そこで、今回は開発フェーズで評価面のデータを作成し、その内容と著しくずれていないかをチェックするような形にしています。仮に生成AIの出力結果がこの評価用のデータセットと大きくずれている場合には、その部分を人力でチェック。これによって回帰テストの工数を削減しつつ、サービスとしての品質を担保していきました。私からの発表は以上です。

質疑応答

Q.生成AIで業務の効率化につながる一方で、品質面に問題はないのでしょうか？　また生成AIを活用したことによる副作用的な事象は発生しませんでしたか？

夏目：品質面を担保するために大事なのは、最初のチューニングをしっかりと行うことだと思います。私が発表した「社内でハブとなるAI人材を育成する施策」（伴走支援施策）でいうと、まずは講師と受講生が密にコミュニケーションを取りながらチューニングをして、最低限の品質を担保していました。その上で、受講者の方が各チームに持ち帰った際にも引き続きフィードバックをもらい、さらに品質を上げていくというフローを踏んでいたため、かなり高い品質が担保できたんじゃないかと思いますし、実際にそういう声をもらっています。

副作用的な事象に関しても、チューニングの時点でものすごい量のテストをしているので、僕の知る限りでは何か問題が発生したということはありません。ただ、100%生成AIに代替できているわけではなく一部は「人の力」を使わないといけなくて、そこはどうしても手間になる。強いて挙げるならそれが副作用かなと思います。
 
三浦：『じゃらんnet』のケースでいうと、現状は品質面を加味して生成AIを組み込む箇所を限定的にしています。というのも、全体のフローの中の大部分で生成AIを使ってしまうと、生成AIの出力に問題があった場合に業務フローのやり直しが必要になったりと、影響がかなり大きくなる。そのため、現状ではあくまで部分的に、なおかつ生成AIの真価が発揮される形に限定して取り入れることで、品質面を担保しています。

また、副作用的な事象ですが、エンジニアリング観点でいうと生成AIで出力した結果って、結構変わってしまいやすい。ちょっとプロンプトを変えるとか、ちょっとパラメータを変えると、それによって振る舞いが変わってしまうというところがやはり、生成AIを使う難しさではあります。この点はかなり意識しながら開発フローを回してプロダクトに装着していきました。

Q.『じゃらんnet』において「対話型UI検索」の浸透が進んだことで、キーワード検索による宿検索行動を上回る様子は見られますか？　また、検索行動の総ユーザー数は増加しましたか？
 
三浦：具体的な数字はお答えできませんが、「対話型UI検索」の浸透が進むことで既存の検索とどう変わっていったかについて、少しお話しします。『じゃらんnet』にはエリアを指定して宿を絞り込んでいく検索UIと、キーワードで検索していくUIがありますが、キーワード検索の場合、ユーザーが自分で検索したキーワードが宿のどういう部分にヒットしているかが分かりづらかったりするんです。例えば「露天風呂」でキーワード検索をした場合、プランや宿のキャッチコピーにそういう文章が入っているかどうかは分かりますが、それ以外の口コミだったりフォトギャラリーだったりに露天風呂の情報があったとしても検索のUI上、ユーザーに示すことができません。そのため、サービス制約的にキーワード検索だけだとどうしても、ユーザーのニーズに対して適切な情報をお伝えできていないという問題がありました。
 
一方で、対話型UIは先に「露天風呂」という検索ワードを入れた場合、そこから口コミなどの宿の文章を元にして「この宿は露天風呂が有名ですよ」や「露天風呂が魅力ですよ」といった文章を合わせてユーザーに送信することができます。結果、通常のキーワード検索と違って、「こういう情報があなたにマッチしているからご提案するんですよ」と、より適切な情報を伝えられる。これによってユーザーの満足度が高まっていく。これはキーワード検索と対話型UIのユーザーログを見ても明らかでして、対話型UIを作って良かった点の一つですね。

お知らせ｜プロデザ室は仲間を募集しています

プロダクトデザイン室の募集情報は〈こちら〉のサイトからご確認いただけます。ぜひご一読ください☆
https://blog.recruit-productdesign.jp/

お願い｜できればX(旧twitter)もフォローをお願いします

プロダクトデザイン室の公式X（旧twitter）ではイベントの見どころやオリジナルコンテンツを更新しています。ぜひフォローしてください。
https://twitter.com/Recruit_PD_PR