2025年3月24日に開催された「舞台裏を覗く！生成AIプロダクト開発のリアル」に、Sansan株式会社技術本部 研究開発部 SocSciグループの中尾遼太が登壇しました。
本イベントでは、生成AIを活用したプロダクト開発の事例や、社内外での導入・運用ノウハウを、3名の登壇者がそれぞれ15分のLT（ライトニングトーク）で披露。最後には会場からの質問に答えるパネルディスカッションが行われました。
登壇者は、Ubie株式会社の八木俊広さん、株式会社リクルートの桐生佳介さん、Sansan株式会社の中尾遼太の3名。
「実際にどう開発を進めているの？」「どんなツールを使っている？」「ユーザーの課題は？」といった、生成AI活用の“リアルな舞台裏”が垣間見えたイベントの内容をお届けします！
※ 本記事の内容は、イベント開催当時のものです。
LT①「生成AI以外が9割、社内生成AIプロダクト開発のリアル」
スピーカー：八木 俊広さん
Ubie株式会社でソフトウエアエンジニアとして、toCのモバイルアプリの開発運用に従事。並行して社内向けの生成AIアプリケーションの開発や運用も担当。
社員の85%が利用！Ubieの社内向けLLMポータル
最初の登壇はUbieの八木さん。Ubie社内で開発・運用されている社内ツールで、社員の約85%が利用しているというLLMポータルを紹介。さまざまな機能がある中で、本日は約50%の社員が日々利用しているというリアルタイム文字起こし機能に焦点を当て、その開発の裏側や活用事例を紹介いただきました。
リアルタイム文字起こし機能のコアな価値は「議事録を書かなくていい」こと
このリアルタイム文字起こし機能のコアな価値は、「議事録を書かなくていい」という点だと八木さんは話します。自身も開発後にその利便性を強く感じ、頻繁に利用しているとのこと。
実際の利用シーンとして、以下が紹介されました。
・リアルタイムな情報抽出：会議中に聞き逃した部分や、話されている内容の全体像を把握できる。
・ファシリテーションの支援：設定したプロンプトに基づいて議論をアシスト。
・設定とアクションの加速：フィードバックを即座に受け、ネクストアクションにつなげる（例：スクラムマスターからの辛辣なフィードバック）。
・デイリーミーティングでの活用：話した内容から、自身のタスクを抽出。
・全社会議での理解度テスト：議事録からクイズを作成し、内容の理解度を確認。
・永続化と再利用：音声と文字起こしデータを保存し、後から内容を振り返る。
・1on1フィードバック：メンターがメンバーの言動に対して具体的なアドバイス。
・商談のまとめ：ロールプレイングのためのデータ作成。
・オンラインイベントでの活用：複数トラックの音声を同時に文字起こしをして視聴。
開発の裏側：生成AIの利用はごく一部
タイトルにもあるように、このリアルタイム文字起こし機能の開発において、生成AIが関連する部分はわずかだそうです。
機能実現までの要素を分解すると、直接的な技術要素としては音声の文字起こし、周辺技術としてはセキュリティーやUI/UXなどが挙げられましたが、生成AIが直接的に関わるのは主に、音声の文字起こし部分や、文字起こしの文章を要約する部分とのことです。
音声の文字起こし自体も、ChatGPTなどのLLMが登場する前からGoogleのトランスクリプションなどの技術で実現可能であったと指摘されました。
実現に必要な4つの要素
実際にリアルタイム文字起こし機能をWebアプリとして実現するための要素として、以下の4つが挙げられました。
- 録音：ブラウザのAPI（MediaRecorder）を利用し、マイクやブラウザのタブ（Google Meet、YouTubeなど）からの音声を入力。
- 音声の区切り：NPMライブラリ「Harp」などを使用して音声の区切り目を検出し、音声チャンクを作成。
- 文字起こし：APIに音声データを送信し、文字起こしを実行。現在はGemini 2.0 Flashを利用しており、将来的にはGPT-4oのトランスクライブモデルの利用も検討中。
- 永続化：音声と文字起こしデータを保存し、後から利用できるようにする。
このように、核心となる音声認識の部分でこそAIモデルが活用されているものの、それ以外の大部分は既存の技術や一般的なWebアプリケーション開発の知識で実現されていることが強調されました。
リリース後もユーザーの声に真摯に向き合う
機能リリース後には、以下のようなユーザーからのフィードバックに基づいたさまざまな改善が行われたそうです。
・音声入力設定の改善：マイクのパーミッションや入力デバイスの選択に関する問題に対し、波形表示機能を追加し、視覚的に確認できるように改善。
・サーバー負荷対策：長時間録音によるアウトオブメモリーの問題に対し、音声データをストリーム処理する方式に変更。
録音開始までのステップ簡略化：定型ミーティング向けに、ブックマーク機能や録音元の自動選択機能などを追加。
文字起こし中のプロンプト処理：ユーザーの要望に応じ、文字起こし中に特定のプロンプトで処理する機能を追加（議事録の論点整理などに活用）。
これらの改善事例からも、ユーザーの課題に真摯に向き合い、地道な改善を積み重ねていくことの重要性がうかがえます。
ユーザーの課題へのフィットと地道な開発が、成功の要因
ツール開発において最も重要なのは、「ユーザーの課題にフィットしているかどうか」だと八木さんは話します。大規模な技術投資や最新のAI技術の導入よりも、ユーザーが本当に困っていることを解決できるかどうかが鍵となります。
実際に、今回紹介されたリアルタイム文字起こし機能は、高度なAI技術を全面的に活用しているわけではありませんが、議事録作成の負担軽減という明確なニーズに応えたことで、多くの社員に利用されるツールへと成長しました。
八木さんは、「ユーザーは別に生成AIで使いたいと思っていない」とも話し、業務効率化や課題解決といった本質的な価値が求められていると指摘。まずはユーザーの課題を深く理解し、それを解決するための最適な手段を検討することの重要性を改めて認識させられました。
LT②「Sansan Labsが挑む！AI営業ロールプレイングの開発事例」
スピーカー：中尾 遼太
新卒で転職エージェントの営業職を経験した後、バックエンドエンジニア、AIエンジニアへとキャリアチェンジし、2023年7月にSansan株式会社へ入社。現在はSansan Labsの開発に従事している。
実験的な機能を提供する「Sansan Labs」
「Sansan Labs」では、未来の働き方を体験してもらうための実験的な機能を、営業DXサービス「Sansan」のユーザーに無料で提供しており、社内外からの「こんな機能を作れないか」という相談に対して、プロトタイプを迅速に作成し、検証を行う場として活用されているという。現在、33の機能が提供されており、生成AIが活用されている機能もいくつかある中で、今回は「AI営業ロールプレイング」という機能の開発の裏側が紹介されました。
AI営業ロールプレイング開発の背景
AI営業ロールプレイングの開発の背景には、以下の要因があったそうです。
・会社の成長にともなって、営業職の新入社員数が増加していた
・営業職の研修に課題があった
- メンターとなる先輩社員の時間が取りづらい
- 準備時間の不足で、ロールプレイングのバリエーションが制限されてしまう
- 新入社員同士での練習では質が担保できない
これらの課題に対し、生成AIを活用することで時間的・質的な問題を解決できないかと以前から考えていたとのことです。
技術的なきっかけとしては、中尾がLangChainの練習として、インサイドセールスを自動化するチャットアプリを開発していたことが挙げられました。これをマネジャーに見せたところ、「役割を入れ替えればロールプレイングになるのではないか」というアドバイスを受け、PoCを開始するに至りました。
ローコードツール「Dify」を活用した高速PoC
PoCの開発には、ローコードツールのDifyが活用されました。Difyは、ブロックにプロンプトなどを記述し、線でつなぐだけでチャットアプリを開発できるツールであり、ログから中間生成テキストを確認できるためデバッグも容易です。また、簡単なチャット欄などのフロントエンドも自動で作成されるため、UI開発の時間をプロンプト設計に集中させることができ、約2週間でプロトタイプの開発が完了しました。
ユーザーフィードバックと改善サイクル
プロトタイプ開発後、社内の研修チームや新入社員、イベントに参加したユーザーなどから積極的にフィードバックを収集しました。特に、AI営業ロールプレイングのような機能においては、正解が人の感覚に依存する部分が大きいため、高速なフィードバックサイクルを回し、ユーザーからのリアルな意見をアプリに実装していくことが重要です。このサイクルを経て、約カ月で運用に耐えうる品質まで到達できたとのことです。
4つの「不」で自然なロールプレイングを実現
営業のロールプレイングをより自然に見せるための工夫として、ロールプレイングのトレーナーからのヒアリングに基づいた4つの「不」（不信・不要・不適・不急）というパラメーターを導入。これは、営業活動がうまくいかない要因を集約したもので、ユーザーのチャットでの発言内容からこれらのパラメータを推定し、AIの応答に反映させることで、リアルタイムかつ自然な対話を実現しています。例えば、ユーザーが強引な提案を行った場合には「不信」のパラメータが上昇し、AIがより慎重で冷たい反応を示すといった具合です。
フィードバック表示とプロンプトエンジニアリングの工夫
生成されたテキストをそのまま表示するのではなく、営業アプローチのフェーズごとに注目すべきポイントを構造化して表示することで、フィードバックの見やすさを向上させました。
プロンプトエンジニアリングにおいては、以下の点に工夫が凝らされていると言います。
・AIが勝手に営業トークを進めないように指示
・ユーザーの習熟度（Easy、Normal、Hard）に応じた難易度調整
・メンターが新入社員に教えるように、愛情のある表現を用いたフィードバック
リリース後の成果とユーザーの声
中尾は主な成功の要因として以下の3点を強調しました。
- ローコードツール「Dify」を活用した高速なPoC開発とフィードバックサイクルの実現
- 研修トレーナーへの緻密なヒアリングによる、実際の営業ロールプレイングに沿ったフローの構築
- ユーザーからのフィードバックを重視し、継続的な改善を重ねたこと
実際にリリースした後、ユーザーからは「リアルなロールプレイングができる」「フィードバックが的確で役立つ」といった肯定的な意見が多く寄せられました。特に、「AI相手なので失敗を恐れずに試行錯誤できる」という点が、練習時間不足の課題解決に大きく貢献していると評価されました。
ビジネス側の課題と技術側の取り組みを密接に結びつけ、ロールプレイングという形で具現化できたことが成功の要因として挙げられました。
▼ 当日の中尾のLT資料はこちらからご覧いただけます。 画面イメージも一部掲載されているので、ぜひチェックしてみてください。
▼ 中尾が、自身の少し変わった経歴や、AI営業ロールプレイングの開発について話す記事もぜひあわせてお読みください！
Sansan Labsが実現する「新しい働き方」——営業職 × エンジニアのキャリアで挑む、AI・ML活用の最前線｜Sansan株式会社 公式メディア「mimi」
LT③「LLM評価を簡単にするために社内OSSを開発している話」
スピーカー：桐生 佳介さん
株式会社リクルート データ推進室に所属。前職で生命保険会社のシステムエンジニアやR&Dの部署で自然言語処理の研究開発に従事し、BERTやGPT-2の研究開発にも携わる。リクルート入社後は、LLM開発、特に継続的学習、ファインチューニング、性能評価といったオープンLLMに関する業務に注力。
LLM出力評価の重要性
ここではLLMを活用したプロダクト開発における出力評価の重要性と、その課題を解決するために開発された社内OSS「whalify-lib」についての発表内容をレポートします。
まず、LLMを活用する際に出力結果を評価・強化する必要性について言及。その理由として、主に以下の2点が挙げられました。
- 安全性の担保：LLMは原理上あらゆる出力が可能であるため、プロダクト利用時に不適切な出力がエンドユーザーに届くリスクを事前にチェックし、継続的にモニタリングする必要がある。
- タスク品質の担保：プロダクトにLLMを導入する目的は特定のタスクを実現することであり、そのタスクに対する要求品質を満たしているかを評価し、確認する必要がある。
また、プロダクトの開発フェーズによって評価の観点は異なります。初期開発（0→1）では最低限の品質と大きなリスクの抑制を目的とし、エンハンス開発では前バージョンからの品質向上や特定のタスク品質の向上を確認し、KPIやサブ指標の改善を評価することが重要になるとのことでした。
LLM評価を容易にするための社内OSS「whalify-lib」
しかし、LLMの出力評価手法の調査や実装は煩雑で難しいと感じる開発者が多いのが現状です。そこで桐生さんは、LLMの安全性、タスク品質、利用環境に関するさまざまな評価手法を簡単に実行できるPythonライブラリ「whalify-lib」を開発しました。
whalify-libの概要と特徴
・主要な評価環境と手法を一つにまとめ、使いやすさを追求。
・シンプルなインターフェースにより、利用者の学習コストとリードタイムを削減。
・評価したいテキストを入力として、安全性やタスク品質などの観点に基づき、実装済みの評価手法（LLM-as-a-Judge、NGワード検出、カスタム評価モデルなど）を用いて評価を実行。
・評価結果として、対象テキストのスコアとその理由をシンプルに出力。
評価例：Groundedness
タスク品質の評価観点の一つである「Groundedness」、つまり対象文が参照情報に基づいているかどうかの評価例が紹介されました。
例えば、「リクルートが提供するAir ビジネスツールズは現在10種類提供されています」という評価対象文に対して、前提情報として「Air ビジネスツールズは20個ある」という情報が与えられた場合、「whalify-lib」はスコア0点（誤り）と評価し、その理由として「リクルートが提供するAir ビジネスツールズは約20種類存在していて、10種類という記述は誤りです」と出力します。
社内OSS開発の意義
桐生さんは、類似のサービスやライブラリが存在する中で、自社で「whalify-lib」を開発する意義として以下の3点を挙げました。
1. どこでも動くシンプル設計：特定のクラウドベンダーなどに依存せず、誰でも簡単に評価を実行できる環境を提供し、評価にかかるリードタイムを短縮する。
2. LLM評価のナレッジ共有基盤：各部署で個別に取り組んでいるLLM評価の事例をライブラリに取り込み、コードベースで再利用可能にすることで、組織全体での横展開を促進する。
3. LLM評価の尺度を自ら握ることの重要性：自社開発であるため、評価の理由や基準が明確であり、ブラックボックス化を防ぎ、評価結果を自信を持って解釈し、プロダクトのリリース判断につなげることができる。
『リクルートダイレクトスカウト』での活用事例
実際に桐生さんが関わった案件として、『リクルートダイレクトスカウト』をはじめとした、リクルートグループの求職活動支援サービス共通で利用できる職務経歴書機能『レジュメ』の職務要約自動生成機能のエンハンス開発事例が紹介されました。ビジネス要求として生成品質の向上が求められていましたが、具体的な定義がないという課題がありました。
そこで「whalify-lib」のカスタム評価モデル機能を利用し、過去のユーザーフィードバックデータを学習させた評価モデルを構築。以前のプロンプトと新しいプロンプトで生成された職務経歴をそれぞれ評価し、定量的に品質が向上していることを確認しました。
この定量評価の結果を踏まえてプロンプトの変更を行い、ABテストを実施したところ、実際のユーザーフィードバックの改善が確認され、定量評価の有効性が示されました。
LLM出力評価と内製ツールの可能性
LLMを活用したプロダクト開発において、出力評価が安全性とタスク品質を担保するために不可欠であること、そしてその評価を効率的に行うための社内OSS「whalify-lib」の重要性が示されました。特に、ユーザーのフィードバックデータを用いたカスタム評価モデルの構築と、それによる定量的な品質改善の実証は、非常に示唆深い内容でした。 LLMを活用したプロダクト開発における出力評価の考え方や、内製化という選択肢について考える良い機会になったのではないでしょうか。
パネルディスカッション
3名のLTの後は、パネルディスカッションが行われました。 その模様は、Q&A形式のダイジェストでお届けします。
Q. AI プロジェクト開発で特に意識していることは？また、他社製品と差別化する際に重視しているポイントはどこでしょうか。
・公開された LLM/API はコモディティと捉え、データやユーザー独自の価値を活用することが重要。
・プロダクト開発では、金額的インパクトやコスト削減効果を明確に示す。
・他社との差別化は、既存の人気機能との連携によるシナジーや、もともと強かった点を強化することを目指す。
Q. 生成 AI の進化が速過ぎて、「開発中にもう不要になってしまった／やらなくてよくなった」という経験はありますか？
・生成 AI の進化が速く、開発中のものが不要になる経験はある。
・しかし、状況によっては既存技術でも戦える可能性を考慮し、ユーザーニーズに合わせて判断する。
Q. 社内向けに PoC やツールを作っても浸透しないことがある。その壁をどう乗り越え、どんな工夫をしていますか？
・「社内驚き屋」のようなアーリーアダプターを見つけ、その課題解決につながるソリューションを提供する。
・誰もが価値を理解できるような分かりやすいインパクト（アハ体験）を示す。
・社内のキーマンを見つけてアプローチし、その人に広めてもらう。
・成功事例を作り、徐々に利用者を増やす。
Q. プロンプト作成スキルの差で出力品質が大きく変わる現状について──将来的には AI 側が最適化して “誰でも同じ品質” になるのでしょうか？
・プロンプト作成スキルの差による出力品質のばらつきはあるが、将来的には AI 側が最適化する方向に向かうと予想される。
・プロンプトオプティマイザーのような機能も登場している。
・最新のモデルでは、詳細なプロンプトよりも曖昧な指示の方が良い結果につながる傾向がある。
・マジョリティー層に対しては、プロンプトを意識させずに使えるインターフェースが重要になる。
Q.「生成 AI で何かやろう」とトップダウンでミッションだけ与えられたとき、アイデア出しからプロダクト化までを効率化できる“おすすめツール” はありますか？
・Cursor: 多機能連携可能なエディター。
・GitHub Copilot Agent: AI コーディング支援。
・社内 OSS: 既存機能の活用。
・Datastream: 社外向け UI 構築。
・GitHub Copilot: コード生成。
・MCP: Figma から React コードへの変換。
・LangSmith: ユーザーフィードバック収集と改善。
・GPTs: アイデア段階での概念実証。
Q. 生成 AI 領域は短期的にも中長期的にも変化が激しい。API 新機能など短期の動向と、2〜3 年先を見据えた動向をどうキャッチアップし、戦略に反映していますか？
・短期的な動向は、驚き屋のソーシャルネットワークの反応からキーワードを拾い、論文などで詳細を確認する。
・中長期的な動向は、Meta や Google などの大手リサーチ機関のブログや論文、国立情報学研究所のLLM-jpによる発信内容 などを参考にする。
・ただし、短期的な情報キャッチアップに注力し、今ある技術をどう活用するかに重点を置いているという意見もある。
イベントを終えて
生成AI開発の現場には、華やかな技術トピックの裏で、地道な工夫や試行錯誤が存在しています。本イベントでは、そうした“リアルな舞台裏”を通じて、技術選定よりも「ユーザーの課題にどう向き合うか」が鍵であることが浮き彫りになりました。
進化の早いAI領域だからこそ、足元を見据えた開発と継続的な改善が、これからの価値を形作っていくのかもしれません。
