曖昧なLLMの出力をプロダクト価値へつなげる、要求の具体化と評価

https://lycorptech-jp.connpass.com/event/369777/

Transcript

1. 曖昧なLLMの出力をプロダクト価値へつなげる、 要求の具体化と評価 Kokoro Higuchi/ ML PM Talk #1 2025/12/05 2025 | © Commune Inc. All rights reserved 1 / 47
2. コミューン株式会社 Product Manager / Data Scientist これまでの略歴 Wantedlyのデータサイエンティスト 推薦システムの改善・実装 コミューンのデータサイエンティスト コミュニティのデータ分析・LLMを使った社内ツール作成 コミューンのプロダクトマネジャー(1年3ヶ月目) 新規事業Commune Voice のプロダクトマネージャー Xのアカウント @zerebom_3(ひぐ) 自己紹介 樋口 心 2 / 47
3. LLMを中心に据えた 新規プロダクトの立ち上げ・開発を 1年強おこなってきました 3 / 47
4. 発表にあたり... LLMを新規プロダクトに入れる中
 での失敗と成功を振り返った 4 / 47
5. LLMをプロダクトに価値ある形で
 組み込むには何が大切だったか？ 本日のテーマ 5 / 47
6. プロダクトに価値ある形でLLMを組み込む上で必要だったこと Principle 1 ペインの解決に
 必要な仕様と制約を
 言語化する Principle 2 要求を
 ロジックと評価指標 に落とし込む Principle 3 指標に基づく短い フィードバック
 ループを回し続ける 6 / 47 機械学習PJと同様、メトリクスの決定・計測・改善が重要
7. 会社・プロダクト紹介 7 / 47
8. 会社紹介 コミューンについて 目指す姿 顧客・従業員との信頼関係を築き、
 その信頼をてこに持続的な事業成長を 実現する 事業の広がり 祖業であるコミュニティSaaSから、
 顧客の可視化・理解・育成・創造を 支援するプロダクト群の開発を展開 何をしている会社か 信頼起点経営を実現するために
 コミュニティSaaSを中心とした
 プロダクト群と支援を提供 8 / 47
9. プロダクト紹介 Commune Voiceについて どんな製品か コミュニティやSNSに寄せられた
 膨大なユーザーの声を生成AIで
 分析するサービス できること 大量の声から事業改善につながる
 課題や期待を抽出し、深い顧客理解が できる コミュニティやSNSに寄せられた
 膨大なユーザーの声を生成AIで
 分析するサービス 解決したい問題 ユーザーが発信する声も
 ニーズも多様になっている中で、
 届けたい人に正しく価値を伝え、
 サービス提供するのが難しくなっている 9 / 47
10. プロダクト紹介 Commune Voiceについて 大量の声から事業改善につながる課題や期待を抽出し、深い顧客理解ができる 10 / 47
11. 今回のテーマ 11 / 47
12. プロダクトの立ち上がり (当初のコンセプトシートより引用) ユーザーとの距離が近くなった現代では、
 複数のチャネルからユーザーの意見が寄せられている しかし、その意見をまとめ、理解し、部門内外へ共有することは困難

 Voiceはさまざまなチャネルからのデータを取り込み、
 自然言語処理技術を駆使して、誰でも簡単にユーザーの声を理解できる 12 / 47 顧客理解ができるSaaSの開発として立ち上がった
13. 誰でも簡単に
 ユーザーの声を理解できるようにしたい 13 / 47
14. 大量の声(VoC)から 真の顧客の課題や要望を理解したい！ ※ VoC = Voice of Customer = 顧客の声 14 / 47
15. どうしたら生のVoCが 理解しやすい形になるか? 15 / 47
16. 顧客の声(VoC)を
 LLMに与え、タグを付けて 定量化する 全文を読まずとも概略を理解できる 全文を読まずとも、事業インパクトになりそうな声を
 LLMに抽出させれば、小さい労力で価値につなげられる 読みやすく、解釈しやすい形に定量化できる 従来のキーワードの頻出順などに比べて、
 文脈を理解しやすく、示唆につながりやすい タグにすることで、
 定量比較・トレンド確認ができる タグでVoCをまとめて、量の多寡や変化を見ることで どのような声からアプローチすれば良いのか優先度を付けられる 最初のアプローチ このアプローチを選択した理由 16 / 47
17. 開発時のイメージ(Commune = コミュニティSaaSの例) 全文を読まずに、 どんな声が 届いているか 定量的に
 理解できる 17 / 47
18. 最初のアプローチの具体的な処理手順 各VoCに紐付く”タグ”を生成 毎日のコミュニティの新着投稿(VoC)の 本文とプロンプトをLLMに与え、
 要約したタグを生成させる 生成したタグをベクトル化 生成したタグをベクトルにし、
 距離を計算できるようにする 類似度によるクラスタリング コサイン類似度で近いタグを同じ
 クラスタとしてまとめて種類数を減らす 18 / 47 シンプルな方法でVoCをまとめ、顧客の理解に繋げる！
19. 結果: 全然ダメだった.... シンプルな方法でVoCをまとめ、顧客の理解に繋げる！ 19 / 47
20. 開発時のイメージ(コミュニティSaaSの例) 全文を読まずに、 どんな声が 届いているか 定量的に
 理解できる 20 / 47
21. 実際に生成されたタグのイメージ(コミュニティSaaSの例) コミュニティの声が参考になる コミュニティの声が参考になった 投稿が参考になった コミュニティを始めた 内容が追えない 21 / 47
22. 実際に生成されたタグのイメージ(コミュニティSaaSの例) 22 / 47 少量多数で 比較出来ない コミュニティの声が参考になる コミュニティの声が参考になった 投稿が参考になった コミュニティを始めた 内容が追えない 抽象的で解釈
 しづらいタグ 似たような
 タグが重複してる
23. “LLMでタグをまとめる”だけではなぜダメだったのか 「声が見切れないこと」を解決すれば、顧客を理解でき、そしてサービスを使ってもらえると思っていた 本当のペインは、顧客から事業改善につながるはずの良質な声をもらっているのに 本当に重要な情報を見つけられない チーム内外で説得力あるかたちで共有できない その結果、顧客が求めている形にサービスを改善・提供できない 23 / 47 声が見切れないことは事実ではあるが、本当のペインではなかった
24. 毎日生成されるタグがブレる 適切な粒度にまとまらない 示唆がでないタグが生まれる テナントごとにタグの
 まとまり方が完全に変わる 直近3日の新着投稿に対してバッチで生成していたが、
 過去のタグと微妙にずれ、時系列変化が追えない ex) 箱が潰れていた / 箱の破損 / 箱が潰れている 具体的な示唆を出すためにタグを長文にすると、少量多数に。
 短くすると”味が美味しい”のように自明なタグばかりに コミュニティのVoCからは、ドメインと全く関係ないタグが生成された ex) よい天気できもちが良い データ量が違うテナントに同じ類似度閾値を適応すると、
 あるテナントでは全て団子状に、別テナントでは全てバラバラに これまで作ったタグがどのようにダメだったのか? 24 / 47
25. Principle 1 ペインの解決に
 必要な仕様と制約を
 言語化し切る Principle 2 要求を
 ロジックと評価指標 に落とし込む Principle 3 指標に基づく短い フィードバック
 ループを回し続ける 25 / 47 プロダクトに価値ある形でLLMを組み込む上で必要だったこと
26. 本当のペインはどこにあったか？ 短くするだけでなく、事業判断につながる示唆をだすことが必要 情報の圧縮ではなく判断の支援が必要 本当のペインは『意思決定に使えない』こと 26 / 47
27. ペインを解決するために本当に必要なアウトプットとは? “まとめる”だけでなく、下記を満たした事業成果につながるタグを作る 一貫性 表記揺れがなく、同じ意味の声には同じタグがつくこと 集約性 近い意見がバラバラに散らず、
 適切な粒度でまとまっていること 変化検知性 新しいトレンドが出てきたときに、
 それを検知して新しいタグが立ち上がること コスト効率性 これらを毎日回しても、
 生成コストが現実的な範囲に収まること 示唆性・事業関連性 事業にとって重要な声が拾え、かつ具体的な示唆に つながるインサイトになっていること 可読性 タグが長すぎず、人間が直感的に読める短い
 フレーズになっていること 27 / 47
28. 実は求められる要求と品質はかなり高いことがわかった 28 / 47
29. 場当たり的に進めるのではなく、 正しいアプローチを選択した上で、 品質を満たせたことがわかるようにする必要がある 29 / 47
30. プロダクトに価値ある形でLLMを組み込む上で必要だったこと Principle 1 ペインの解決に
 必要な仕様と制約を
 言語化し切る Principle 2 要求を
 ロジックと評価指標 に落とし込む Principle 3 指標に基づく短い フィードバック
 ループを回し続ける 30 / 47
31. 正しいアーキテクチャを選択する 先行事例を参考に、高品質なタグの生成アプローチを見つける Qualitative Insights Tool (QualIT): LLM Enhanced Topic Modeling 【地上波世界初】都知事選で使ったブロードリスニングの技術で
 衆院選を解析してみた https://note.com/annotakahiro24/n/ndd21a8ba3eec https://arxiv.org/abs/2409.15626 テキストからトピックを抽出する手法 LLMでキーフレーズを抽出し､クラスタリングをした後に クラスタのメインテーマを抽出 都知事選におけるブロードリスニング手法 HDBSCANでクラスタリングした後に メインテーマを抽出 31 / 47
32. 正しいアーキテクチャを選択する 多段階の要約と全体最適なクラスタリングにより高品質なタグを作成する 32 / 47 　　↑ 後段のLLMへの入力量を
 抑えつつ均質にする ↑　　　 cos_simのような局所ではなく 全体の分布を見て クラスタを作成
33. 要求を評価に落とし込む 成功した状態を評価指標としてピン留めする 33 / 47 機械学習モデル & LLMの活用するため、かなりの変数が存在する 行き当たりばったりの改善にならないような工夫が必要
34. クラスタリングの指標 クラスタ数 どれくらいの“まとまり
 （トピックの塊）”に分かれたか シルエットスコア 「違うクラスタ同士がちゃんと離れて いるか？」を数値化 カバレッジ 全体の VoC のうち、どれくらいが
 どこかのクラスタにきちんと
 入っているか 要求を評価に落とし込む 最適なクラスターの分離・数・カバー範囲になっているかを確認する 35 / 47
35. タグ品質の精度 名前の形・表記の適切さ スタイルガイドを守れているか （ex. 文体・文字数・NGワード） 原文忠実さ 元の声の内容と矛盾していないか
 （ハルシネーションがないか） ビジネス上の有用性 事業者にとってアクションのヒントに なるか 論点カバー率 VoCから抽出するべき論点が抜けもれ なくタグになっているか 要求を評価に落とし込む 生成されたタグが事業成果につながるものになっているか確認する 36 / 47
36. このような基準を満たしつつ、 新規事業で求められるスピード感で リリースしていくにはどうすれば良いか? 37 / 47
37. プロダクトに価値ある形でLLMを組み込む上で必要だったこと Principle 1 ペインの解決に
 必要な仕様と制約を
 言語化し切る Principle 2 要求を
 ロジックと評価指標 に落とし込む Principle 3 指標に基づく短い フィードバック
 ループを回し続ける 38 / 47
38. 大きく分けて3つ タグの生成 これまでの実験結果を基に
 パラメータやモデルを調整し、タグを生成する 定量評価 定量的な指標による実験結果の確認。
 バグの有無や大雑把に実験がうまくいっているかを比 較する 定性評価 定量評価でうまくいってそうなタグを実際のUIに近い形で確認。
 ビジネス上で利用出来そうか、指標に現れない違和感がないかを チェック 分析と改善 評価の結果から改善点を特定し、生成精度の改善に生 かす 指標に基づく短いフィードバックループを回し続ける 評価指標を短いスパンで何度も計測し、改善することで事業に使える形にする 39 / 47
39. 定量評価: LLMを用いてリリース前に自動評価し、チューニングする 生成したタグを自動評価する仕組みを作り、複数の実験を比較する 生成されたタグを入力に評価値を出力するスクリプトを実装 スプレッドシートで比較出来るようにcsvで出力する 40 / 47
40. 定性評価: 人の目と現場の声で磨き込む デモアプリで タグの分布・量の順序など“数値化しづらい違和感” を人がチェック 実験後との結果を本番のUIと近い形で確認出来る ビジネスメンバーに共有し、お客さんに近い形でフィードバックをもらう 41 / 47
41. 結果 42 / 47
42. 事業として必要な声の抽出に利用できる精度に改善 レポーティングでの活用・事業における課題の抽出などへの利用が進んでいる 43 / 47
43. こんなに面倒なことを新規事業で リソースを割いて行って良いのか? 44 / 47
44. 事業において中核をなす要素であればリソースを割いて改善すべき(と考えている) Voiceにおいてタグの精度は他の機能の前提になる上、競合との差異になり得る ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法　1章より引用 著:Vlad Khononov, 増田 亨, 綿引 琢磨 タグの精度 Commune Voiceの今後の価値や機能 RAG リッチな
 可視化 AI Agentによる
 施策の支援 45 / 47
45. 曖昧なLLMの出力をプロダクト価値へ繋げるには ペインの解決に必要な仕様と制約を言語化する 求められる解決策は、最初に思いついたものよりきっと複雑 要求をロジックと評価指標に落とし込む 解決した状態を定義し、それを実現する方法を選ぶ 指標に基づく短いフィードバックループを回し続ける 成功までの距離を理解できるようにし、頻度高く改善する 46 / 47
46. エンジニアを募集しております！ 47 / 47 ソフトウェアエンジニア(LLM 新規プロダクト) Commune Voiceの更なる事業への活用をめざして挑戦したいことが多くあります やりたいこと 多くのチャネル・モーダルでのデータを収集し、意思決定の基盤にしていく 経営戦略など重要な意思決定に利用出来るほど高品質なデータにしていく グロースに備えた、スケーラブルなデータ収集･加工基盤を作る タグなどメタデータを活用したAIによる分析や示唆だし・施策の提案の自動化 マーケティングなど、ユースケースに特化した加工やUXの開発