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