『寄り添うラジオ』をAIで作る 体験価値から逆算した、会話しないUXと品質設計

Product Engineering TalksのLT登壇「『寄り添うラジオ』をAIで作る
体験価値から逆算した、会話しないUXと品質設計」
https://upsider.connpass.com/event/401501/

1. 『寄り添うラジオ』をAIで作る 体験価値から逆算した、会話しないUXと品質設計 2026/09/08 Product Engineering Talks テオリア‧テクノロジーズ株式会社 内⼭ ⼤悟
2. ⾃⼰紹介 • 内⼭ ⼤悟 • 2025/08 ソフトウェアエンジニア としてテオリアに⼊社 • 「わたしのラジオ」開発担当。 Webアプリからサーバーサイド、 インフラまで幅広く担当 • 最近、電動昇降デスクを導⼊しま した 2
3. 「わたしのラジオ」とは ユーザーが送ってきた「今⽇の振り返り」と「明⽇の予定」をもとに、翌朝そのユー ザーだけのラジオ番組をAIで⽣成して届ける⾳声プロダクトです 音声サンプル https://www.my-radio-app.com/ 3
4. 「わたしのラジオ」のしくみ 「今日の振り返り」 「明日の予定」 を送る AIがその人だけの番組を 生成する 翌朝、番組が届く 4
5. 開発初期：プロトタイプ開発と価値検証を並⾏ • プロトタイプ開発と同時に、プロダクトの価値検証を⾏う活動を⾏った • 通称「⼈⼒⽣成ラジオ」 ◦ ⼈間がAIを⼿動で操作してユーザーごとの番組⾳声を⽣成する ◦ ユーザーとは⼈間がLINEでやりとり 5
6. ⼈⼒⽣成ラジオで得られたフィードバック 前日に書いたアンケート全て の内容に寄り添って優しい言 葉をかけてくれました 共感だけでなく、自覚していなかった 角度から褒めてもらったり、励まして もらったりと日常では感じない喜びが 満載でした 共感、寄り添い 、承認欲求を 満たすことでいい気分にしてく れていますね 私の行動や計画を 好意的に受け止め て下さり、応援してもらっているよう で、自己肯定感が増しました 番組の「寄り添い感」を評価するコメントを多くいただけた 6
7. 課題と取り組み • この「⼈⼒⽣成ラジオ」の結果から「寄り添い感」を⾼めることがプロ ダクトの価値につながると理解した • そのために実施した取り組みを紹介 1. 会話しないUX 2. 3. プロンプト開発の分担 音声の品質評価 7
8. 1. 会話しないUX 8
9. 質問スタイルの違い • LINEのチャットUIでユーザーに「振り返り」「予定」を⼊⼒してもらう のはプロトタイプも⼈⼒⽣成ラジオも同じ • 環境的な都合から、ユーザーへの質問スタイルに差異が⽣まれた プロトタイプ：会話 AIとやりとりする中で、ユーザーに「振り 返り」「予定」を回答してもらう 人力生成ラジオ：アンケート リアルタイムに応答できないため、先に 質問を投げておき、ユーザーのペース で回答を書いてもらう 9
10. スタイルの差が、質の差を⽣んだ • ⽣成された番組をチェックすると、⼈⼒⽣成ラジオの⽅が深くユーザー に寄り添った内容になっていると感じた • これは質問スタイルの違いから、どのようなUXが導かれたか、に起因 していると考えた プロトタイプ：会話 聞かれたことに答えるだけになりやすい 短文かつ一問一答 になりがち 人力生成ラジオ：アンケート 自分のペースで回答を考えられる 作文が促される 10
11. 作⽂が寄り添い感を⾼める理由 自分のペースで作文ができる 時間をかけて、自分の気持ちや 考えを書きやすくなる 番組中で気持ちの記述に触れられることで、 「気持ちを肯定してもらえる」という体験になる 11
12. 判断：会話をさせないようにする • 会話をさせると、回答が短⽂になり、番組の寄り添い感が薄くなる • そこで⼈⼒⽣成ラジオと同様に、ユーザーが⼊⼒しても回答を⾏わない ようにした ◦ 何も応答しないとユーザーが不安になるので、ごく短い応答⽂だけを返すようにした ◦ プロンプトに「会話にならないような応答」をわざわざ指⽰している 12
13. 気づき：AIだからといって会話させる必要はない • AIに応答させると、つい会話させたくなりがち ◦ • チャットがあるからといって、チャットをがんばる必要はなかった プロダクトの価値に照らし合わせて必要な機能を判断する ◦ 「わたしのラジオ」は番組を聴いてもらうことがメイン ◦ 番組の質を⾼めるための選択を⾏う ◦ 会話で満⾜できてしまうなら、チャッピーさんで⼗分 13
14. 2. プロンプト開発の分業 14
15. プロンプトはドメイン理解の結晶 • ⾃分が作った台本⽣成プロンプトより、PdMが作ったプロンプトの⽅ が、圧倒的に寄り添い感の⾼い番組を⽣成できていた ◦ • この差はドメインに注ぎ込んできた時間と熱量の違い プロダクトの魂であるプロンプトは理解度の⾼いPdMが担当した⽅がよ い結果になると判断した ◦ 「エンジニアリングの問題はエンジニアが解決すべき」という思い込みがあった ◦ ⾃分の役割はPdMのやりたいことを最良の形に具現化すること、と理解して腑に落ち た感覚があった 15
16. Difyを⽤いたプロンプト作成の分業 • PdMにプロンプトを効率よく実装してもらうには、⼊出⼒を⾼頻度で試 ⾏錯誤できる環境が必要 • そこで、実サービスの台本⽣成ワークフローと同等のものをDify上で再 現し、PdMにはそこでプロンプトを試⾏錯誤してもらうようにした • 簡易的なプロンプト管理場所にもなった ◦ プロダクトへはここからコピペすればよい 16
17. 3. ⾳声品質の検証 17
18. ⾳声品質の問題 • ⼈⼒⽣成ラジオで実際に番組⽣成を⾏うと、配信できる品質の⾳声は⼀ 発では⽣成できないことに気づいた • ◦ ⾳声が途中で切れたり、無⾳区間が発⽣したりする ◦ 読み間違えが発⽣する 読み間違えは寄り添い感を下げる ◦ ユーザーは読み間違えに気づくと「あ、機械がしゃべっているんだな…」と現実に戻 されてしまう 18
19. 対策：⾳声品質評価の実⾏ • • 台本テキストには読みがなを⼊れておく ◦ AIに台本テキストを⽣成させる際に、漢字などに読みがなを振らせるようにする ◦ これだけでかなり読み間違いが減らせる 台本テキストと⾳声を突き合わせて評価を⾏うようにする ◦ 無⾳や読み違い、おかしな発⾳などを検出できる ◦ これで配信可能なレベルまで品質が安定する https://note.com/theoriatec/n/nc7b24766b036 19
20. まとめ 20
21. まとめ：寄り添い感を⾼めるための取り組み 1. 会話しないUX 2. プロンプト開発の分担 3. 音声品質の評価 作文を促し、より深い文章を入 力させる ドメイン理解度が高い PdMが 試行錯誤できる環境 台本と音声を突き合わせて読 み間違いを検出 「寄り添うラジオ」という固有の価値 21
22. おまけ：Note記事もあります！ https://note.com/theoriatec/n/nc7b24766b036 22
23. ご清聴ありがとうございました！ 23