DeNAのヘルスケア事業領域の子会社であるDeSCヘルスケア（以下、DeSC）で、プロダクトデザインを担当しているトビーです。
先日、ヘルスケアエンターテインメントアプリ「kencom®」にて、AIを活用した食事記録機能を新たにリリースしました。
食事の写真をアップロードするだけで、AIが食材や栄養情報を解析し、その結果を踏まえたアドバイスまで行うことで、手軽に健康管理できる機能となっています。
kencomの食事記録機能の開発プロセスを例に、AIを組み込んだ新機能の体験検証を、どのような流れで進めていったのかを紹介します。
kencomは、DeSCが提供するB2B2C型のヘルスケアエンターテインメントアプリです。kencomを導入している団体（自治体や健康保険組合など）が定める条件を満たした方が、ユーザーとして利用できます。
アプリのコンセプトは「楽しみながら、健康に。」歩数や体重などのライフログ記録や健康診断結果の閲覧、イベント・ミッション・ポイントなど、楽しく健康になれる仕組みを備えています。
2015年のサービス開始以来、127団体、約840万人の健康維持に活用されており、継続率（登録から5年以上経過したユーザーの利用率））も約65％と高い水準となっています。
kencomでは以前から「食事管理機能を作れないか」という議論が社内で上がっていました。
それまでのkencomでは、歩数や体重などのライフログは入力できましたが、栄養情報は扱っていませんでした。健康行動を支援するアプリとして考えると、食事の情報も重要な要素であり、将来的には何らかの形で食事管理の機能を提供したいという構想がありました。
一方で、栄養情報を手入力で記録する方法では手間が大きく、継続が難しいという課題があります。十分なデータが蓄積されなければ、食事スコアや適切なアドバイスをアプリ上で返すことも難しくなります。
そうした中で、近年は画像解析などAIの技術が急速に進歩しており、「食事記録をより手軽な体験で実現できないか」という観点から、AIを活用した食事記録機能の開発にトライすることになりました。
想定していた食事記録機能の主要な利用フローは「食事写真の投稿 → AIが解析 → 結果表示」というシンプルな構成です。
一方、これが良い体験として成立するには、「AIによる画像解析精度が実用に耐える水準かどうか」が最初の論点になります。解析精度が低ければ、ユーザーが使いたいと思えない機能になってしまいます。
そこで、AIの解析精度と使い勝手をできるだけ短期間で検証する方法を検討し、社員が日常的に使っているSlackを検証環境として選びました。
食事写真を投稿するとAIが解析結果を返してくれるSlack Botを実装し、社内で使い込んでみました。
その検証の結果、AIによる食事内容の解析精度は約98％であり、十分に実用可能な水準であることが分かりました。
さらに、最低限の機能ではあるもののSlack上で動くプロトタイプができたことで、実際に触ってみたうえでの課題感も見えてきました。
Slack Botはあくまで技術検証が目的だったため、「いつ・誰が・なぜ・どう使うのか」といった体験の全体像は、まだ十分には検討されていない状態でした。
そこで改めてkencomのユーザー像に立ち返り、食事記録機能の体験設計に取り組みました。
kencomの食事記録機能では、コアユーザーを大きく3つに分類しています。これらのコアユーザーが抱える課題・ゴールを起点に、「食事記録機能でどんな価値提供ができるか」という視点で体験を設計していきました。
例えば、想定ユーザー層のニーズの一つに「漠然とした健康不安の解消」があるのですが、なぜ不安が漠然としているのかを改めて分析し、食事記録にどんな体験や機能があればこのニーズに応えるのか、といった思考ルートで必要な要素を洗い出しました。
そのうえで、MVP段階で実現するユーザーフローや必須機能、見送る機能などを整理し、要件として設計しました。
詳細な情報設計を進める段階では、AIを組み込んだ機能ならではの配慮が必要な場面もありました。
例えば今回のMVP版の食事記録機能では、「食事写真を選択 → 写真の確認 → 食事内容の解析（AI）→ 食事内容の確認 → カロリー・栄養素の解析（AI）→ 結果表示」という利用フローとしています。
その中で、特に考慮したポイントは以下の2つです。
社内検証ではAIの解析精度が約98％と分かっていましたが、その前提を理解しているのは社内メンバーだけです。
「AIが本当に正しく認識してくれているか」を不安に思うユーザーがいることも踏まえ、あえて「写真アップロード時（食事内容の解析前）」と「食事内容の解析後（カロリー・栄養素の解析前）」の2箇所で確認のステップを挟みました。
AI解析は、やり直しが増えるほどコストも膨らみます。そこで今回は、あえて「戻れない画面遷移」を採用し、再解析が発生しにくいフローにしました。その分、確認導線を丁寧に設けることで、UXの障壁になりすぎない折衷案を狙いました。
MVPの実装が完了した段階で、改善点の把握とユーザーゴールへの到達度を検証するため、社内テスト期間を設けました。
まず利用状況を確認し、使用回数10回以上のユーザーを「ヘビーユーザー」、3回以下のユーザーを「離脱ユーザー」と定義しました。次に、それぞれの利用動機と行動障壁、または「食事記録の継続化に向けた必要要素」を深掘りする目的でインタビューを実施していきました。
その後、継続要因や離脱要因を分析していきました。結果として、特に離脱要因として「撮り忘れ」が想定以上に多いことが分かりました。 MVPでの食事記録の手段が写真解析だけに限られていたため、AIで素早く解析できる便利さがある一方で、「忘れたときに挽回する手段がないと継続できなくなる」という点が盲点になっていました。
この検証を通じて、継続利用率を高めるための一つの方向性として、「記録のハードルを下げる」ことが重要だと分かりました。
社内テストの結果を踏まえ、改善デザインを作成しました。
改善例の1つ目は「多様なユースケースに合わせた記録方法の追加」です。 具体的には「テキストでの記録」「過去の食事履歴から記録」の2つを追加しています。食事写真を撮り忘れてしまった場合でも、別の記録方法を選択できるようにすることで、より手軽に、食事記録を続けやすくすることを意図しています。
2つ目は「とりあえず早く記録を終わらせたいケースへの対応」です。 写真確認画面から、内容確認をスキップしてすぐに解析できる導線を追加しました。
技術検証段階で解析精度が高いことが分かっていたことに加え、社内テスト経て、想像以上にサクッと登録を完了したいというニーズが強いことも分かったため、この改善を行いました。
これらは、ユーザーの利便性を高めることに加えて、食事写真の解析回数（APIコール回数と、それに伴うコスト）の軽減も期待できるため、良い改善となったと思います。
このようなプロセスを経て、AI食事記録機能をリリースすることができました。
今回のリリースでは、AIを活用することで、簡単に食事記録ができるということが実現できました。これからはユーザーが「楽しみながら、健康に。」というkencomのコンセプトをより体感できるような改善をしていくことで、より食事記録の習慣化を推進していきたいと思います。
kencomにおけるAI機能の開発は今回が初めてでしたが、チーム内でアイデアを出し合いながら、検証プロセスをうまく進めることができたと思います。
APIコール量の増加リスクや、AIによる解析結果をユーザーが信頼できるかなど、AIを組み込むことで生まれる論点に配慮しながら機能を設計していくプロセスは、私自身にとっても新鮮な経験でした。
一方で、AIを導入すること自体が今回の目的ではありません。
プロセス全体を振り返っても、最も重視していたのは「この機能によってユーザーの何が解決されるのか」「習慣や行動が変わるほどの体験を提供できているのか」といった点です。
技術が発展していき、開発プロセスも変化していく中でも、ユーザーの心理や行動を理解し、日常に自然と溶け込む体験を設計することは、デザイナーとして変わらず大切な役割だと考えています。