ヘルステックに残された”発症領域”という成長スペース
こんにちは Ubie の共同代表の久保です。昨今、ヘルステック領域はVCからの投資も活況で盛り上がりを見せています。その中でも、当社が取り組んでいる領域である「発症」という領域のポテンシャルについてお伝えできればと思います。新型コロナウイルス感染拡大の影響もあり、遠隔診療などのサービスを提供する企業も増えています。一方で、Ubie も同様のサービスと混同されることが多い実情です。そこで、我々がチャレンジしているマーケットについてご説明していきます。
医療におけるユーザージャーニーとテクノロジーの参画
様々なサービスにおいて「ユーザージャーニー」があります。それと同様に医療・ヘルスケアにおいても良く使われるものがあります。それは健康・予防、診断、治療、ホームケアというフェーズです。
健康・予防領域への参入と課題
各フェーズにおいて、様々なサービスが参入しています。特に健康・予防領域ではtoC向けサービスや法人をクライアントとして、例えば福利厚生として社員や被保険者に健康・予防のためのサービスを提供するケースが多く見られます。この領域は診断・治療の領域と比べたときに、いわゆるデジタル・ネイティブな若者世代も含むため、ソフトウェアテクノロジーとの相性が良く、事業者に取って魅力的なマーケットに見える一方で、エンドユーザーのモチベーションをいかに保つかは難しく、継続してもらうための課題を抱えているサービスが数多く見られます。例えば Fitbitも、マネタイズに苦戦してGoogleに買収され今年のヘルスケア業界における大きな話題の一つになりました。
発症領域にあるチャンス
本稿で“発症領域”と呼ぶものは上記フローの中でも、予防と診断の間に位置します。ヘルステックの文脈においては、発症した生活者に対して適切な受診行動を促したり、医師に診察前に必要な情報を伝えて適切な診療を支援したり、多くのテクノロジーが介入できる余地があります。一方で、サービスとして浸透しているものはまだ存在しないのが現状です。特に症状を聴取してユーザーを適切に導く部分は大きなポテンシャルがあるのものの、今まで多くのプレーヤーが挑んでは撤退してきました。
発症領域におけるAIの取り組みのこれまで
実はこうしたコンセプトの祖は1970年代にまで遡り、Mycinという推論エンジンとされています。その後も様々な取り組みがなされてきました。そして昨今の機械学習ブームも相まって、とりわけ自然言語処理技術や計算機の処理能力の向上によって、自然言語処理で電子カルテなどの臨床データをソースとした症状と病気の紐付けのデータを使った試みが活発に行われましたが、技術的な問題もありプロダクトレベルで使うことはできていませんでした。
自然言語処理での症状×病気のデータをつくる課題
臨床現場の電子カルテなどのソースから自然言語処理でデータをつくる際の障壁はデータの正規化です。機械学習における説明変数である症状（発熱、頭痛など）と、目的変数である病気（インフルエンザ、風邪など）の関係性が重要な要素になります。もっとも、医師が記入する電子カルテの内容は一様でなく、同じ説明変数を示していても臨床現場で違う表現（例: 頭痛、頭が痛いなど）によって記入されているものから意味を抽出するのに限界があったり、人によって書き方が違うので構造上の意味抽出にも限界があったりします。さらに、世界中にある様々な症状と病気の出現確率のまとまったデータはまだこの世に存在しておらず、ゼロからつくりあげるには膨大な労力がかかります。
データを取得する際の「ニワトリタマゴ問題」
こういったデータを生成する際にエンドユーザーから得られたデータで機械学習等の方法を使って精度を向上させていくアプローチもありますが、何もサービスがないところからだと症状という特徴量だけで膨大な量があり途方もない時間がかかるため最初にデータを取得するフレームを作れないという「ニワトリタマゴ問題」がありました。また、仮にドメインエキスパートである医師の工数を使って症状と病気の関係性のデータを完成させたところで、大きなビジネスになる保証がなくビジネス上の意思決定がしづらいためにこうしたデータが作られてこなかったと私は考えています。蛇足ですが、今年に始めた podcast でもこのデータの話については触れています。
Ubie がやったチャレンジ
こうした高いハードルがある領域にUbieは実際にチャレンジし、サービスを利用してもらえるユーザーが存在します。こうした状況の要因には、医師というドメインエキスパートと一緒にチームが構成できていた点や、創業時にROIをほとんど度外視して不確実性が高い状態で問診の可能性を信じて投資した点が挙げられます。創業前にはおよそ4年弱、データを貯めることのみに時間を使っていました。Ubieにはこのような背景もあり、フレームがない状態、つまりデータをエンドユーザーが入れられないならそのデータをテクニカルな手法ではなく人間のドメインエキスパートがそのまま作り出すという手法が当社では常套手段で、最初はスケールしない方法でデータの型をつくり出す文化が根付いています。
データ収集を継続し続けることでプロダクトをさらに磨く
また、機械学習を組み込んだサービスにおいて重要なことはデータ収集のフレームをつくった上で継続的にデータを収集し続け、ユーザー体験の向上などプロダクトに還元させることです。それによってサービスの独自の強みをつくり上げることに大きく貢献することができます。当社ではプロダクトを進化させるという意味でもデータの扱いに非常に気を使っており、症状と病気のデータフレームができたあとには常にプロダクト上でどの部分でデータを収集するかの議論をしています。常にプロダクト改善に還元できるかをプロダクトチームとともにデータサイエンスのチームが議論するフェーズを用意しており、データのチームの中にはドメインエキスパートである医師も所属することで、より高いレベルのデータ価値の議論をできるようにしています。
個人の医療データが秘めた可能性
こうして得られた症状と病気の正規化されたデータにはプロダクトそのものの成長に使えるという価値もあれば、第三者から研究に利用したいなどの二次利用のニーズが創薬の分野などでは存在します。上述したとおり、症状と病気のデータは正規化が難しく、それを電子カルテなど臨床現場で収集していくことに従来までは限界があったからです。今までは創薬の領域では治験などの研究開発においては、データを限られた母集合の中から収集しなければなりませんでしたが、近年RWD (Real World Data) と呼ばれる膨大な量の研究以外の世界で生まれるデータを製薬企業の業界でも使おうとする動きが出てきており、当社が取得しているようなエンドユーザーが生むデータもRWDとして、周辺領域にりようできる可能性を秘めています。
まとめ
ヘルステックの中でも発症領域におけるデータの課題と、それに対して今まで当社が取ってきたアプローチを紹介しました。ヘルステックにおいては、様々なチャンスが多くの領域で存在しつつ、スタートアップも含めてまだまだチャンスがあるということや、Ubieとして狙っているポイントが少しでもお伝えできればと思っています。今後もデータの活用も含めて様々な領域にチャンスがありますので、一緒に事業をつくっていける人材を募集しているのでぜひご連絡ください。
エンジニア向けpodcast #devchat .fm
この記事が気に入ったらサポートをしてみませんか？