保育AIプロダクトの UXデザインで考えてきたこと / hoiku-ai-ux-design

25.08.21 AIで変わるUXデザイン【デザナレコレクション2025 Vol.3】
KYOTO CREATIVE COLLECTION 2025 サイドイベント 資料
https://vivivit.connpass.com/event/364576/
#KCC2025

Transcript

1. 保育AIプロダクトの UXデザインで考えてきたこと Takahiro YAMAGUCHI / @hiro93n 25.08.21 AIで変わるUXデザイン - デザナレコレクション2025 Vol.3 1
2. 発表者 is 誰 山口 隆広 HCD-Net 評議委員 ユニファ株式会社 執行役員CPO プロダクトデベロップメント本部 本部長 兼 AI開発推進部 部長 1981年生、福島県出身、子(5歳)の父。 HCD-net認定 人間中心設計専門家。 ねこ大好き。ベーススキルは企画職。 @hiro93n 2
3. 3 人間中心設計(HCD)について 引用：https://www.hcdnet.org/organization/news/hcd-1076.html
4. 4 ルクミー：園・施設向けの写真販売、連絡帳、午睡チェック等を提供する プロダクト群 「保育AI」に関わる プロダクトに2年ほど 関わっています
5. 5 保育AIとは？ 各社定義は色々あるが、保育園や幼稚園向けの AIによる課題解決プロダクト全般のこと
6. 今日お話しすること 保育AIプロダクトを作るとき、技術先行過ぎ ず利用者の課題解決につなげるには何を意識 すれば良いんだっけ？のひとつの事例紹介。 6 ぱっと見た感じの良さを頑張るのも分かるけど、使って良かったと思ってもら えるプロダクトを作りたいという人の手がかりになれれば嬉しいです。
7. 期間モデルとサービス設計 7
8. 8 ともすると「瞬間的UX」のことばかり考えてしまう私たち https://www.slideshare.net/slideshow/ux-76610590/76610590
9. 9 AIならではのサービス設計の難しさ プロダクトそのものの有用性の手前に AIそのものに対する「人の気持ち」がある 「AIはイヤなんです」という人に強制して使ってもらうモノではない。 ただ、それがなぜイヤなのかをリサーチの中で分解することはできる。
10. 10 個人的に感じている重み付け プロダクト そのもの プロダクトを どう語るか AIの進化により機能そのものは磨かれていく未来が見えるが、自分たちの スタンスが受け入れられなければその先に何を作ってもだめ。 プロダクトのことだけ考えていても、そのサービスは成長できない。
11. 11 まず大事なこと 誤解を生まないために 具体的にかつ丁寧に 自分たちの考えを発信する。 反射的に「こういうことをしようとしてるんだよね？」と思われがち。 自分たちのスタンスを明示することが重要。
12. 12 保育AIプロダクトが生み得る嫌悪感 • 育ちに対する記録をAIに任せるなんて保育の専門性をバカにしている • AIが保育記録を書くようになったら自分の仕事がなくなってしまう • AIなんか覚える余裕はない。事業者の自己満足に付き合わせないでほしい • 周囲からAIを使って楽してると思われたくない などなど… 「AIプロダクト」を推進することについては社内でもかなり意見が割れた。 既存顧客からの信頼を失い、既存事業を揺るがす可能性があると考えられた。
13. 13 プロダクトより先に保育AI自体がどこまで受容されているかを検証 • 本格的に動き出していた2023年後半はAIモデルの実力もまだそこまで • 保育AIカテゴリそのものの受容性がどこまで来ているのか、受容していい という空気をどのように作りあげていくのかを検証 ◦ 定期的に自分たちの考え方を園・施設や国に当ててみてフィードバッ クを受けることを繰り返した • AIの理解とプロダクトの理解があるPMががマーケターやコミュニケー ションデザイナーと連携することで、AIの期待値がズレないメッセージン グを探り続けた これらの動きをとる中で、社内外で「保育AIを推し進めていいんだ」という空 気感の醸成にも繋がった
14. 14 利用者向けコミュニケーションの例（連絡帳作成）
15. 15 既存顧客に閉じないコミュニケーションを幅広く実施 既存顧客向けレター 保育AI解説サイト 国の実証実験 セミナーでの脳内共有
16. 16 このコミュニケーション設計は「予期的UX」の一部 「こんなもの認めちゃダメでしょ」と なってしまうと、その後どんな技術的 に優れたプロダクトを生み出せたとし てもゼロ。
17. （これでやっと） プロダクトディスカバリー編 17
18. 18 AIプロダクトにおける「予期的UX」は期待値調整が大事 期待値調整できている？
19. 19 AIプロダクトは予期的UX・つまりは期待値調整が難しい 利用者に勘所が少なく、期待値の振れ幅も大きい。 • ありがちなのは「なんでも思い通りにできる」というコミュニケーションを しつつ、実際は色々と期待外れの結果が出る • 生成AIを普段から使っている人の「6-7割は合っているけど爆速で選択肢を 提示されることに価値がある」という認識は、一般的には共有されていない • これは利用者だけで無く、社内でGo To Marketしてくれる関係者について も同様。「できること」「できないこと」「（技術的・倫理的判断で）敢え てやらないこと」を言語化し、認識合わせしてておく重要性
20. 20 そもそも園や施設ってそんなにAI活用されてるの？ 活用されてます。 ◦ 日本の中小企業平均は上回るレベル ◦ 生成AI以前からAIの関わる機能が導入されている（写真関連） ◦ 日々の忙しさもあり、便利なものは率先して使っていただける ◦ 元々やりたかったこと(will)が少なく、やらないといけないこと(must) ばかりに追われてしまうことで若手の退職に繋がってしまうことも
21. 21 ルクミーで提供している保育AIソリューションの例 文書作成・修正 文書翻訳 写真の顔認識* (検索・分類) 自動写真チェック テキスト中心 画像中心 一定期間における文書・写真の要約 2023年〜 2016年〜 2024年〜 2024年〜 *2016~AWSモデル、2022~内製モデルでの顔認識 2025年〜
22. 22 今回の事例：すくすくレポート 園内の大量の写真・文書記録を要約し こどもの育ちを簡単に振り返られるよ うにするプロダクト。 先行利用開放中。
23. 23 結構主観でスタートしたプロジェクト • 先生達が時間がとられて大変なのは「書類作成」なのは認識済み • 社内で「AIで課題解決を考える」という方針が立ち上がり、簡易的な文書生 成機能などは出していたがもっと本質的な解決手法はないか悩んだ • AIでRAGしてみるような実験もしていて、当時のモデル（gpt-3.5）性能は 正直イマイチではあった。ただ、その際に大量の書類を横断で検索できる便 利さを感じていた。 • 社内で大変な書類作成といえば評価フィードバックで、これは様々な書類や チャットログを探しながらテキストを作成するになる定期イベント。 ◦ 結局の所は記憶頼りになる部分が多くあった。園の先生に取っても同じ なのではないかと感じた＆RAGっぽく解決できるのでは？と思ったとこ ろがスタート。
24. 24 ディスカバリーのステップ そもそもこんな課題解決手段に受容性はある？のヒアリング ・ヒアリング結果からユーザーストーリーマッピング スプレッドシートプロトタイプでの技術検証 ・ある程度意味のあるまとまりになりそうということを把握 Webプロトタイプ結果を使ったヒアリング ・ヒアリング先のデータを使ってレポートを作成し、直接意見を伺う クローズドβ版のリリース ・より広い園の利用状況を把握し、仮説検証を進める 概念の受容性 モノの満足度 リサーチ対象
25. 25 リサーチプロセス • リサーチ設計 ◦ リサーチ目的、得たい結果の整理 ◦ リサーチ園の特定 • リサーチ実施(PM+プロダクトデザイナーで連携） ◦ リモートでのヒアリング ▪ Nottaやzoom、meetなどでの録音録画と文字起こし • リサーチ分析 ◦ meet文字起こしをCursorを利用し整形、要約 ▪ 要約を見つつリサーチャーの感じる温度感を元に整理 • AsIs~ToBeの整理 ◦ 園別整理の上、ユーザーストーリーマッピングで要求要件の整理 概念の受容性
26. 26 リサーチ設計のポイント まずは関係者間で整理し、インタビューガイドを事前作成。 • 致命傷になるポイントは何か • どういう傾向が見えたらプラスか • 次のアクションに繋げるために聞くべきポイントは何か • 「いつも話してくれる人」だけでなく遠慮なしにネガティブな意見も出して くれる人も確保できているか ◦ 社内「元先生」のグループインタビューも実施 • ヒアリング候補が各クラスタに分散しているか ◦ 自社サービス利用/ 未利用 ◦ 日常写真撮影の多寡 ◦ 園長・現場 / 本部担当 / 経営者 概念の受容性
27. 27 リサーチ実施のポイント / 当時意識して聞いていた質問群 • その方向に行ったら絶対にイヤだと感じる機能はありますか ◦ AI嫌悪感の元になる要素を明らかにしたい • この機能を人に説明するならどのように伝えますか ◦ 今までにない概念だったので、率直にどういう要素で説明すると先生方 に伝わりやすいのかを把握したい ◦ 人に説明できないようであればまだ複雑すぎるので要素を減らしたい • （私たちはこういう用途に活きると思っていますが）先生なら他にどのよう に使いますか ◦ まだ認識していない有用性を理解し、最悪の場合に備えてピボットの可 能性も探りたい 概念の受容性
28. 28 AsIs 園別の整理の例 / まずKJ法に近い形で整理 概念の受容性
29. 29 ToBe 要求要件整理の例 / ユーザーストーリーマッピングで整理 こういうことを達成したい / 要求 具体的にこういう機能で実現できる / 要求 その機能の実現に必要な要素はこれ / 要件 概念の受容性
30. 30 リサーチの結果、「やらないこと」を決めた • 生成AIが利用者の確認をとらず特定のタスクを完了できること ◦ ex. 勝手に連絡帳を作成して送付する • 生成AIが「独自の専門性らしきもの」を発揮して、先生に代わり保育記録 を作成すること • 普段生成AIを使ったり保育記録を積極的に作成している園が希望する機能 を作り込むこと（個別プロンプト編集、園・施設の方針RAGなど） 今の技術ではできるけど、いらないものはいらない。 一見良さそうだけど、それがあることで利用ハードルが上がってしまう。 将来的には必要でも、現時点でこれは時期尚早では？と判断していった。 概念の受容性
31. 31 この判断の背景にあるプロダクトのスタンスと過去の失敗事例 • 過去「ふつうの園」を置いてけぼりにしたプロダクト開発の事例 ◦ 提供側の「こういう風な保育記録であるべき」が強くあり、一部の園 を除き実際利用がなかなか広がらなかった • 保育ICT全般としても「まずは目の前の業務負荷」というニーズが高くあ り、これの解決を今回のAI系プロダクトディスカバリーで重視 ◦ このためにだけ新たなタスクが発生するのではなく、いつも通りのこ とをやっているだけでも恩恵を受けられる状態を作ることが重要 ◦ いつもの努力が報われるという設計 保育領域について、新しい概念こそアーリーアダプター向けに作らないことが 重要だと感じ、今回のディスカバリーに活かした。 概念の受容性
32. 32 ディスカバリーのステップ そもそもこんな課題解決手段に受容性はある？のヒアリング ・ヒアリング結果からユーザーストーリーマッピング スプレッドシートプロトタイプでの技術検証 ・ある程度意味のあるまとまりになりそうということを把握 Webプロトタイプ結果を使ったヒアリング ・ヒアリング先のデータを使ってレポートを作成し、直接意見を伺う クローズドβ版のリリース ・より広い園の利用状況を把握し、仮説検証を進める 概念の受容性 モノの満足度 リサーチ対象
33. 33 AIが生成する文章における、良し悪しの考え方 保育記録としての有用性は、保育記録の作成者しか分からない。 • 元先生などN=1的な印象は分かりつつ、実際それが園内で意味がある要約な のかは自分たちでは分からない • Webアプリケーションとしての操作UIがどうかなどの話より、まずこの要約 は本当に意味があるのか？の検証が必須 ◦ ただ要約のレイアウトや要素の必要性検証自体は重要 • テストデータではなく実際の園・施設の要約を、その元データを日々書いて いる先生に見てもらうのが一番の仮説検証 モノの満足度
34. 34 検証に使ったプロトタイプの割り切り方 「要約ジェネレーター」に振り切り、利用者の使い勝手は検証外とした • 新規登録もログインもなし。細かなエラーハンドリングも後回し ◦ リサーチに関わるメンバーへのアクセス制限のみ ▪ こちら側で園の情報をセットして、要約作成 • リサーチャーが操作し作成したレポートを提示し、評価いただく ◦ 画面を共有しながらヒアリング モノの満足度 結論、これだけで十分にリサーチが成り立った。
35. 35 リサーチで得られたこと • 「思っていたよりもよくまとまっている」という感想を得られ、方向性の 正しさが確認できた。 ◦ データが少ない園は予想通り要約の質が安定しなかったが、データを 増やすことの重要性を感じていただき、既存機能の利用促進に繋がっ たケースも現れた。 • 今のプロダクトでは解決できない課題も明確になった ◦ 解決できない前提で期待値コミュニケーションに反映した • 「これ良いと思うので1クラス分のpdf全部出して」という声があり、手 ごたえと「アプリケーション化しておいて良かった」と感じられた 実サービス全部がある必要はなく、コアとなる体験だけ提示できれば十分リ サーチに活かせることが分かった。 モノの満足度
36. プロダクトデリバリー編 36
37. 37 AIプロダクトにおける「瞬間的UX」はとっつきやすさが大事 事前知識不要で、すぐ試せる
38. 38 使うハードルを下げるための設計 キーは「①覚えることを最小限＋②他人の利用に気づける」 • 皆さんも普段使っている勤怠や稟議のサービスの新機能のリリースを追いか けたり、マニュアルをリリース直後に読み込んだり使ったりはしないはず • 他の先生に「ちょっと触ってみてよ」と言われてノリで使えるくらいの単純 さが重要 • 知らないサービスのボタンを押す心理的ハードルは（我々IT民とは異なり一 般的には）高く、これ押したらどうなるのか？押してる人はそもそもいるの か？が分からないと積極的に使えないことは多い • 興味の高さと使いやすさを両立するところからスタートする
39. 39 レポートに必要な操作は対象を選んで作成ボタンを押すだけ ①覚えることを最小限 • プロンプト不要 • モデル不要 • パラメーター調整不要 →「存在だけ紹介して特に 何も教えてないけど、他の 先生が勝手に使ってる」と 言う声を多くいただけた。
40. 40 サービスを開いて最初に見えるのは園・施設全体での作成履歴 ②他人の利用に気づける • 自分がボタン押すのが 怖くても、すでに他の 人の作成レポートは見 られる • 作成することだけでな く「見る」ことも価値 の体感上重要 → 安心して使っても良い、 という気持ちの後押し
41. まとめ 41
42. 42 もう人間か書かなくてもある程度まとめてくれますね…の時代
43. 43 今日の「人間による」まとめ AIに対するスタンスを言語化し、繰り返し伝え、 誠実にプロダクトを提供し続けることが大事。 • 利用者に受け入れられるスコープになっている？ • 必要以上に期待値が膨らんでない？ • 必要以上のプロトタイプになってない？ • 常に利用者とAIの関係性を探りつづけられている？そしてあなた自身もAIに 興味を持ち続けて、定期的に「これは他でも役立つかも」と思えている？ AIにより「つくること」自体のハードルは大きく下がりましたが、それは本当 に課題解決に繋がること？に悩み、AIプロダクトを実現していきましょう。
44. 44 KYOTO CREATIVE COLLECTION HCD-net 登壇あります お知らせ 13:20-13:40
45. 45 ユニファ開発チーム、仲間を探しています お知らせ ユニファ株式会社 会社紹介資料（開発チーム版） / Unifa inc information for dev team - Speaker Deck
46. ありがとうございました！