![見出し画像](https://assets.st-note.com/production/uploads/images/123520977/rectangle_large_type_2_9d49466cbb618fc9054448ad109999e9.png?width=1200)
生成AIを活用した新機能開発を通して医師PdMが得たものとは
「テクノロジーで人々を適切な医療に案内する」をミッションに医療プラットフォームを提供しているUbieの原瀬です。この記事は#Ubieアドベントカレンダー2日目にエントリーしています。
Ubie株式会社ではプロダクトマネージャー(PdM)・医師をしています。専門は脳神経内科で、非常勤で臨床を続けながらヘルステックベンチャーであるUbieを主体に医療機関向けプロダクト開発に携わっています。
先日、ChatGPT等で話題になっている大規模言語モデル(LLM)を活用したプロダクトに関するプレスリリースを弊社より出ました。
2022年11月にChatGPTが公開されたのを皮切りに、様々な業界で幅広くLLMが浸透してきていますが、LLMが数百もの医療機関で実際に活用される事例はまだ少ないと思われます。
これは、私がPdMとして主体的にかかわり、医師として真正面から問診体験に向き合って開発したプロダクトです。入力する患者側の体験だけでなく、出力されるテキストを見る医師の体験を見つめ直すだけでなく、法的、医療倫理的なissueなど様々な課題と向き合い悪戦苦闘しながらプロジェクトを推進しました。この記事では、いち医師がPdMとして生成AIを既存問診プロダクトに活用し、数百もの医療機関に展開、一定PMF(Product Market Fit)することができた経験について共有できればと思います。
なぜ生成AIの技術を既存の問診システムに組み込む必要があったのか
なぜ今、弊社医療機関向けプロダクトである「ユビーメディカルナビ」に生成AI技術の活用が必要だったのでしょうか?
![](https://assets.st-note.com/img/1701244234464-zrMX8666Np.png?width=1200)
ユビーメディカルナビの問診機能は、一般的にわかりやすい用語や適切なUI/UXで患者に問診を行ってもらい、その結果を専門用語に変換し医師に提示します。特に来院前であれば、患者はスマホで問診を行い、医師は患者が来院する前に、ある程度完成した「カルテ情報」を閲覧することができます。
![](https://assets.st-note.com/img/1701244284359-WX1yFfHH0d.png?width=1200)
これは医師の業務効率化というVP (Value Proposition, 価値提案)を生み出しています。Ubieが出力するカルテ情報は、網羅的で、医学教育的に見ても型通りに記載された情報を出力します。ところが、医師の業務は多忙であり、膨大な認知負荷の元に日々の診療を行っています。この中で、患者は何を伝えたく、医師には何がどのように伝わることで、より本質的な業務効率化に貢献できるかを検討する必要が出てきました。つまり、医学的に必要な情報と「読みやすさ」のバランスの最適化が一つの課題でした。その解決howの一つとして生成AIが活用できる可能性が出てきました。
0-1開発、一次情報でひたすら仮説検証サイクルを回す
仮説検証は患者側と医師側でそれぞれ行い、積極的に一次情報を取りに行きました。患者も医師も多種多様な考えを持っており、最適な体験を構築するためには単純に最大公約数を取るだけでなく、潜在的ニーズを考慮した上での設計が必要でした。
患者体験を考える
特に患者側はゼロベースでUI/UX変更も視野に入れて検証したため、検証項目が多くなりました。入力体験は既存の選択式だけでなく、チャット形式、完全自由入力形式など様々な仮説がでましたが、既存の選択式が好まれる結果になりました。質問の粒度も「closed question」になるほど好まれる傾向も判明しました。その反面、患者が問診体験に求めるものとして「自分の症状をもれなく伝えたい」であったり「問診を読む・入力する手間を省きたい」など、矛盾する様々な要望がありました。つまり患者は「楽をして多くを伝えたい」という事が見えてきたわけです。
別論点で生成AIによる「傾聴」機能も検討されました。傾聴とは患者の不安や心配事に対して文字通り耳を傾けるという事です。事前問診のタイミングである程度傾聴されることで、患者の受診満足度を上げられないか仮説があがりました。事実、生成AIによるsympathyは医師によるそれを上回るという報告もあります*。ところが、スマホ問診ユーザーという顧客層においては、あまり有効ではないという結果になりました。
このように一つ一つの仮説検証を経て、新価値のROIを精査し、0-1検証に足るMVP (Minimal Viable Product)を設定し、プロトタイプの開発がいよいよ始まりました。
医師体験を考える
先述の通り、医師は常に膨大な認知負荷にさらされながら迅速に意思決定を行っています。医師は問診からどのような情報を優先的に得たいのでしょうか?通常、問診から得られる情報は、患者が最も困っている症状である「主訴」、その主訴の経過を時系列にまとめた「現病歴」、事実に基づいた「既往歴」(過去に罹患した疾患)、「内服歴」(今内服している薬)、「社会歴」(生活状況、ADL、飲酒、喫煙など)などが続きます。これらは客観的に記載されることが求められ(患者の主観的訴えも、医師として客観的に記載する必要があります)、患者の要望や不安、心配事等は記録されていません。
SDM(Shared Decision Making、共有意思決定支援)が浸透しつつある昨今、患者の疾患、検査、治療に対する温度感は非常に重要な情報です。つまり、医師は端的に「患者はどういう経過で来ていて、何を求めているのか(何を不安に思っているのか)」を知りたいのではないかと仮定しました。
![](https://assets.st-note.com/img/1701244495437-SBNh9uhfzT.png?width=1200)
よくある話として、診断後に一般的な説明をした後に「あれも、これも」と質問が来てしまうことは良くあります。具体例で見てみましょう。最終診断が同じ片頭痛患者においても、Aさんは「新しい注射薬を試してみたい」と思っており、Bさんは「過度な不安から画像精査を希望している」場合、Aさんには治療薬の話を、Bさんには画像検査の必要性について限られた説明の時間を適切にアロケーションすることができます。
つまり、生成AIで単純にカルテ情報を要約するだけでは事足りないわけで、医師が本質的に求めている情報を生成AIで適切に処理し、医師認知負荷の軽減に貢献するプロダクト開発が必要と判断しました。
実際、0-1検証では多くのクリニック医師にご好評を頂きました。当初はPoCであったため、2週間の期間限定で実施しましたが、90%以上の医療機関が「この機能を使い続けたい」と話し、NPS*は平均8.8(中央値10.0)と極めて高い状況でした。興味深いことに、既存カルテ生成ロジックではカバーできなかった文章と文章の繋ぎがLLMを通す事により、より自然な日本語となり、さらに読みやすくなったという声を頂きました。LLMの自然言語処理のレベルの高さを痛感した瞬間でした。
* NPS=Net Promoter Score: 顧客ロイヤルティー(企業やブランド、サービスなどに対する愛着や信頼)を数値化するための指標のこと。
この初期検証で多くの医師からポジティブな温度感を得られたことを踏まえ、既存医療機関へのスケールを行うことを決定しました。
生成AI活用のピットフォール(特に医療ドメインにおける活用の注意点)
LLM技術を中心とした生成AIモデルをプロダクトに活用する際に、考慮すべきピットフォールがいくつかあります。詳細は他書に譲りますが、主に
①ハルシネーションリスク
②アウトプットに一貫性がない事がある
③生成における説明可能性が低い(ブラックボックス問題)
①は当然「嘘」をついてしまうリスクです。ハルシネーションリスクを抑える方法は複数ありますが、ゼロにすることは困難です。②は①に近いですが、仮にハルシネーションがなかったとしても、文体や文章の表現、要約の仕方が異なることがあります。つまりアウトプットにゆらぎが生じるということです。③はなぜこういう出力になったのか誰も説明できないという事です。
医療ドメインにおける生成AIの活用ピットフォールについてはどうでしょうか。2023年時点で生成AIを治療・診断(いわゆるCDS, Clinical Decision Support)などの医学的判断に使用すべきではないと私は考えています。openAI社の規約にも同様に記載されています。(Google社のMed-PaLMなどはCDSへの活用が期待はされていますが、エビデンスが蓄積されていない現在は同様に積極的に使用すべきではないと考えます)
本プロダクトは上記のlimitationを十分に理解した上で設計する必要がありました。つまり、①Ubieの既存カルテ生成ロジックで得られた出力と②LLMで加工した出力を交互に行ったり来たりできるUIにしました。
![](https://assets.st-note.com/img/1701244594755-Rg54UTIRQn.png?width=1200)
①は患者が入力した内容を忠実に出力したものであり、網羅的でやや文章量が多い、対して②は端的に「どういう経過の患者が何を求めに来た」がわかります。ハルシネーションリスクがゼロの既存ロジックをあえて残し、スムースな切り替えを実現することで、正確性の担保を実現しました。また、外部サービスを使う性質上、フェイルセーフとして既存機能を残したという背景もあります。
もう一つ大事な観点は個人情報保護です。openAIをはじめとする生成AIの多くは入力情報を学習データとして使わないEnterprise版があります。UbieにはLLMや生成AIを専門としているエンジニアが複数在籍しており、LLMの様々な課題に対応してもらったことが迅速な開発に繋がったのは言うまでもありません。
最後に
開発者は生成AIという強力なhowを手に入れたわけですが、プロダクトのwhy/whatを再定義して適切な箇所で活用する事が重要です。今回も初期仮説検証から複数のfeature開発のseedsが生まれましたが全てに生成AI技術を使ったわけではありません。生成AIの特徴、リスクの前提を十分に理解した上で、ユーザー体験、リターンを明確化することが重要であると感じました。
また、医師個人としての先入観、直感ではなく一時情報を優先した事もスムーズな開発に繋がったと実感しています。
プロダクトライフサイクルの成熟期を迎えつつある問診機能のさらなるGiant Leapに向けて探索を続けていきたいと思います。
Ubieでは一緒に働きたいメンバーをまだまだ募集しています!
興味を持っていただけた方はカジュアル面談もご用意しています。お気軽にご登録お待ちしています!
【提供するサービス一覧】
▽生活者向け 症状検索エンジン「ユビー」
日本版:https://ubie.app/
US版:https://ubiehealth.com
▽医療機関向け「ユビーメディカルナビ」
https://intro.dr-ubie.com/
参考文献
*Ayers JW, Poliak A, Dredze M, et al. Comparing Physician and Artificial Intelligence Chatbot Responses to Patient Questions Posted to a Public Social Media Forum. JAMA Intern Med. 2023;183(6):589–596. doi:10.1001/jamainternmed.2023.1838
この記事が気に入ったらサポートをしてみませんか?