症状チェッカーからスマートチャットボットへ：AIが果たすバーチャルケアにおける役割

InfoQ ホームページ プレゼンテーション 症状チェッカーからスマートチャットボットへ：バーチャルケアにおける AI の役割 プレゼンテーションを見る 所要時間：48:28 概要 アンドレ・リベイロは、Healthily の AI による症状チェッカーのアーキテクチャについて解説します。彼は、ベイズ推論（Bayesian inference）と RAG モデルが、医療的洞察と確信を持って行動する患者との間のギャップをどのように埋めるかを説明します。 Bio アンドレ・リベリオは、データエンジニアリング分野で 10 年以上の経験を持ち、現在イギリスの Healthily で最高技術責任者（CTO）を務めています。インペリアル・カレッジ・ロンドンで神経画像処理に関する博士号を取得し、リスボン大学では生物医学工学および生体物理学の修士号を保有しています。彼の専門分野は、多様な領域における現実世界の課題解決のために高度な技術を応用することです。 About the conference ソフトウェアが世界を変えています。QCon London は、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を強化します。実践者主導の会議である QCon は、チーム内でイノベーションに影響を与える技術チームリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャーを対象に設計されています。 INFOQ EVENTS 2026 年 5 月 12 日 午後 1:30（EDT） アジェンティック AI のためのデータレイヤー設計：スケールにおける状態、メモリ、調整のパターン 登壇者：Karthik Ranganathan - YugabyteDB 共同 CEO & 共同創業者、および Aditi Gupta - AWS GTM Data and AI シニア GenAI/ML スペシャリスト ソリューションアーキテクト 2026 年 5 月 21 日 正午（EDT） 設計によるポータビリティ：マルチクラウドシステムのためのデータ移動性と回復のパターン 発表者：Liore Shai - Eon のソリューションアーキテクト 2026 年 5 月 28 日 午後 1 時 EDT（東部夏時間） AI の時代における配送システムの再考：より迅速な配送と、より多くの破壊 発表者：Eric Minick - Harness の DevOps ソリューション担当シニアディレクター、および Aaron Newcomb - Harness のシニアプロダクトマーケティングマネージャー 転記内容 Andre Riberio: Healthily に関する内容、すなわち症状チェッカーからスマートチャットボットへの移行についてご説明いたします。まずは物語から始めましょう。午前 2 時、7 歳の男の子が頭痛と発熱で目を覚ましました。救急（A&E）の状況には見えないものの、両親は依然として心配しています。彼らは Google で検索し始めます。すると不安が増幅し、 Meningitis（髄膜炎）だと信じ込みます。これは Google で検索した際に表示される上位結果の一つです。10 分後、彼らはそれを確認しようと救急部（A&E）へ向かいます。しかしすぐに、これは自宅で自己治療が可能な副鼻腔炎だったと気づきます。 彼らは時間を失い、ストレスを抱え、自分自身の判断に対する信頼を失いました。これはある一つの家族の話に過ぎません。もう一つの事例を見てみましょう。68 歳の男性が娘に電話をかけ、言葉につまっています。彼は少し混乱していましたが、突然正常な状態に戻りました。彼は娘に自分は問題ないし、おそらく単なるストレスのせいだろうと、本当に心配することはないと言いました。娘はオンラインで検索しましたが、特定の理由を見つけられず、二人とも朝まで待つことにしました。父親が経験したのは一過性脳虚血発作（TIA）または微小脳卒中でした。これは基本的に、今後 48 時間以内に本格的な脳卒中が発生する可能性を示す警告サインであり、恒久的な状態や最悪の場合の死を避けるために、直ちに行動を起こす必要があります。 これらは表裏一体の二つの側面です。一方には、救急外来（A&E）受診につながったセルフケアのシナリオがあり、これが NHS のコスト増、ストレス、そして自信の喪失をもたらしました。他方では、父親と娘の両者によって見落とされた緊急事態があり、それが長期的な影響を招く可能性がありました。これらのケースにおける問いは常に同じです。「私は何をすべきか？」「私の特定の状況において、今すぐ何をすべきか？」これは決して特殊な問題ではありません。この二つの事例に限った話でもありません。英国だけでも年間約 5,000 万件の健康関連検索が行われており、すべての年齢層で増加傾向にあります。 オンライン上で健康に関する質問を検索する人が増えています。ここで本当に問われているのは何でしょうか？情報を得ること自体の問題なのか、それともどう行動すべきかという問題なのでしょうか。私たちが実際に解決しようとしているのは、人々を潜在的な結果から、実際に行動に移せる状態へと導く方法です。ユーザーの視点から全体の流れを追ってみましょう。ユーザーは症状から始めます。それはユーザー自身が報告した症状でもあれば、別の人物で観察された症状でも構いません。頭痛や発熱、あるいは言葉が不明瞭になることなどが該当します。 次に、それが何である可能性があるのかを特定します。髄膜炎かもしれないし、副鼻腔炎かもしれないし、単なるストレスかもしれません。しかし、自分たちが取るべき行動はまだ分かりません。何が起きる可能性があり、複数のバリエーションがあることは分かっていますが、具体的にどう行動すべきかは不明です。これが現在の状況です。これは私にとって今すぐ何を意味するのか、私の特定のシナリオにおいて何が必要なのか。それが知りたいことです。それを実現したいのです。彼らが本当に求めているのは、自信を持って行動できる能力です。洞察から行動へと最後の一段階を踏み出しましょう。ユーザーの質問は「私は何をすべきか」でした。これはもちろん非常に重要なニーズに基づいているだけでなく、利用可能な医療へのアクセスや自分が対象となる制度に基づいて equally 決定されるべきものです。例えば、イギリスにいる場合とアメリカにいる場合では、対応が異なります。これらすべてを考慮に入れる必要があります。これが私たちが現在健康保険会社と提携し、彼らが持っているものと実際にできることの間の欠けているリンクを作成しようとしている理由の一つです。 背景 私はアンドレ・リベリオです。AI および機械学習システムにおいて10 年以上の経験があります。医療分野だけでなく、アート分析などの他の分野でも活動してきました。生物医学工学を専攻し、その後インペリアル・カレッジで臨床医学研究の博士号を取得しました。現在はヘルスリー（Healthily）の最高技術責任者（CTO）として、これからご紹介するシステムの全体統括を担当しています。 理想的なシナリオ 問題についてお話ししましたが、今度は解決策についてもう少し詳しくお話しましょう。この特定のケース、つまりこの娘さんの場合における理想的なシナリオとは何でしょうか？彼女が真に望んでいるのは、正確にアドバイスし、人間のミスを減らすシステムです。彼女は刺激から行動に至るまでの時間を最小限に抑えたいと考えており、それによって対応時間の短縮を図っています。また、このケースでは脳卒中という完全な発症という将来のリスクを最小化したいと考えています。さらに、自分が取っている行動が正しいものであるという安心感も得たいのです。ヘルスリーではこれをどのように実現しているのでしょうか？ ヘルスリーでは、まずスマート症状チェッカーの作成から始めました。このスマート症状チェッカーは、臨床医、すなわち医師によってゼロから開発されたツールに基づいています。これは当社が自社で構築した医療データベースに基づくものであり、臨床的に検証済みであり、AI ツールでもあります。さて、ここで疑問が生じるかもしれません。「では、AI ツールの精度をどう保証するのか？」と。その点については後ほど詳しく説明しますが、基本的にはベイズモデルと呼ばれる手法に依存しています。これは数学や統計学に深く根ざしたものです。最後に、先ほどお話しした通り、私たちは医療保険会社と連携し、この欠けていたリンクを作成しました。 システムアーキテクチャ 背後で何が行われているのかを把握していただくために、システムのアーキテクチャについて少し概説させていただきます。他のすべてのアプリケーションと同様に、私たちはユーザーインターフェース、Web アプリ、API、あるいはその他の要素から始めます。今回の場合、ユーザーは自然言語処理（Natural Language Processing）からスタートします。「体調が悪い」「熱があるし腹痛もある」といった表現で入力できます。このシステムは、私たちが「自然言語処理およびチャットエンジン」と呼ぶ部分を経て処理されます。このエンジンは、3 つの異なる他のシステムへとルーティングします。すなわち、臨床推論エンジン（Clinical Reasoning Engine）、セマンティック検索エンジン（Semantic Retrieval Engine）、そしてフロー駆動型臨床ロジックです。最初の「臨床推論エンジン」は、特に基本ロジックを処理し、評価のケースの大部分を担当するものです。 2 つ目は、ユーザーが情報を検索している場合です。これは後ほど詳しく説明しますが、BM25 と密なエンコーディング（dense encoding）を活用して機能します。要するに、ユーザーとデータベース間のすべての意味的な関係を処理する役割を担います。 3 つ目は、どの症状チェッカーでも対応できないケースです。これらは自殺念慮など、ユーザーが陥りかねない危険な状況に該当します。これらのケースはすべて、個別のケアガイダンスとして統合されます。基本的には、医療保険と連携し、ユーザーが必要とするサービスを提供します。これはまさにその人のニーズに特化したものです。 単に「医師を受診してください」と伝えるのではなく、「MSK パスウェイ（MSK pathway）を利用してください」「24 時間対応の看護師に連絡してください」など、具体的な行動を指示します。これが真にユーザーが求めていることです。彼らが知りたいのは、現在の症状や課題に基づいて、どのような行動を取るべきかという点です。 自然言語処理とチャットエンジン システム自体を詳しく見ていきましょう。自然言語処理（NLP）とチャットエンジンについて掘り下めます。これは主に 3 つのマイクロサービスから構築されています。実際にはもう少し複雑な要素もありますが、要約すればこのようになります。 最初のモデルは意図検出モデルです。ユーザーが情報を求めているのか、評価を求めているのか、あるいは何を求めているのか不明確なのかを検出するモデルです。 次に「ワークアラウンド分類器」と呼ぶものがあります。これは危険なトピックに関連するトピックと整合性を取るモデルで、ユーザーが「自殺願望がある」のような発言をしているかどうかを特定します。通常の症状チェッカーでは対応できず、非常に特定のフローに従う必要があります。 また、症状エンティティ抽出も行います。ユーザーの生のクエリ（例：「頭痛と発熱があります」）に対して、この場合であれば「頭痛」と「発熱」を検出し、これらを他のサービスへ引き渡す潜在的な症状として扱います。 最後に、このシステムは評価が可能かどうかを検出するために用いられ、これによって次に取るべきステップを決定します。私がここで伝えたい核心は、これが医療製品であり、現在クラス I 医療機器に分類されている点です。私たちは各システムの安全性と制御に非常に注力しています。マイクロサービスとして設計され、独立して動作するのは、適切に検証可能にするためです。 特に意図検出モデルは、前年に手動でラベル付けされたデータを用いて訓練されました。前年にはそのデータセットを見直し、それが情報提供、評価、あるいはその両方ではないかを判断しました。 その後、インターフェースには動的なボタンを追加し、ユーザーが情報提供を望むか評価を望むかも選択できるようにしました。私たちはこの二つの情報を組み合わせて独自のトランスフォーマーモデルを微調整し、意図検出機能を実現しています。 一方、ワークアラウンド分類器は、双子型ニューラルネットワーク（Siamese Neural Network）を用いて訓練されました。このネットワークは、ユーザーのクエリとシードクエリの埋め込みベクトルを比較します。シードクエリはトピックに関するものであり、自殺念慮のようなメンタルヘルスの状況や火傷、あるいは異なるシナリオなどが含まれます。 これら二つの埋め込みベクトルに基づいてコサイン類似度（cosine similarity）を算出します。これは本質的に、これらの埋め込みベクトル間の類似度を意味しており、それによって閾値を設定することが可能になります。 当社の臨床チームは、各トピックの精度と正確性をバランスさせ、閾値を定義しました。また明確にしておきたいのは、モデルを構築するだけでなく、そのようなモデルのガバナンスや規制についても重要だということです。我々には、初期から終末まで検証し、レビューし、さらに継続的にモデルを見直して精度を保証するための一連のプロセスが備わっています。 次に紹介するのは、UQML モデルの最終段階である症状エンティティ抽出です。実際にはこれを「Mediterm モデル」と呼んでいますが、若干の違いはあれど同じ領域に属するものです。このモデルは Stanford CoreNLP を基盤としており、独自のデータセットによって強化されています。我々は独自の中医学概念と類義語を追加して拡張しており、これらは機密情報です。このシステムには2 つの主要なポイントがあります。1 つ目はラベルベースの概念活性化です。例えば「頭痛」から始めると、「頭」という概念と「痛み」という異なる概念の 2 つが同時に活性化されます。 これら 2 つは特定のシナリオにおける頭痛という単一の概念に統合されます。システムは単なる単語や複数の単語を拾い上げるだけでなく、それらをより高次レベルの症状へと組み合わせることが可能です。 2 点目は階層的な症状伝播です。私たちは足の裏の痛みから始め、これを一つの概念として特定しましたが、その親概念である「足の痛み」も同時に活性化させることができます。なぜ这样做するのかというと、論理的に考えて、足の裏に痛みがあれば当然足全体にも痛みがあるためであり、これにより症状チェッカーの信頼性と網羅性が向上するからです。これは後ほど詳しく説明します。 臨床推論エンジン NLP の部分については説明しました。すべてを解説するわけではありませんが、上位 2 つについてのみ説明します。この NLP は、これら 3 つのシステムへルーティングするためのエンジンであり、モデルである臨床推論エンジンが使用する症状を提供するエンジンでもあります。このエンジンとは何かというと、先ほど説明した通り、ベイズ推論、安全性ルール、そしてレッドフラグ（危険信号）を取り込み、これらをすべて組み合わせることで、最終的にユーザーに次に質問すべき一連の問いを提示します。NLP モデルによって提供された構造化された症状入力を受け取り、それをベイズ推論、安全性ルール、レッドフラグへと渡します。実際に着手するのはまずレッドフラグからです。例えば、ユーザーが胸痛を報告したケースを考えてみましょう。これはレッドフラグ症状です。なぜなら、多くのレッドフラグに関連する病態と結びついており、それらは危険だからです。したがって、システムは直接「最近の怪我」について質問します。その理由は、胸痛と関連する複数の病態が存在し、かつ最近の怪我も関与している可能性があるからです。 もし直近の怪我を除外できれば、したがって特に危険な状態も除外できることになります。これが私たちがまず行うことです。私たちは安全なトリアージに非常に焦点を当てようと努めます。その後、ベイズ推論部分が担う大規模モデルへと移行します。これらは2つの簡略化された数式ですが、基本的に必要な情報はすべてここに含まれています。仕組みとしては、次の質問ラウンドで得られる情報を最大化しようとするものです。ユーザーは胸痛があると言いました。また混乱しているとも伝えてきました。今、私たちはシステムの不確実性を減らすために、彼らに尋ねるべき最適な症状のセットは何なのかを問う必要があります。これはベイズ推論を通じて、特定の症状セットが与えられた場合の病気の確率を計算し、さらにその確率分布も算出することで実現します。エントロピーを計算し、それを最小化することにより、エントロピー最小化の観点から尋ねるべき上位の症状セットを特定します。 したがって、複数の質問ラウンドを行うことができます。システムの前向きな確率を継続的に改善し、システムが保有する知識と、特定の病態である可能性に対する自信度を高めていきます。これにより、あらゆる時点で可能な病態のリストを順位付けし、関連するトリアージレベルも提示できます。 このようにできるため、各病態の後向き確率（事後確率）を計算することが可能です。これは前述と同じ数式です。ここで重要なのは、特定の閾値が設定されている点です。複数の質問を跨いで行うことで、それが潜在的な病態であるという確信は次第に高まります。 医療チームはこの閾値を90%と定義しました。これは少なくとも12ラウンド（質問のやり取り）を通じて達成されるものであり、システムが結果を提供して完了するのに十分な自信を持っていると判断する基準となります。後ほど示す病態は、この特定の閾値だけでなく、ユーザーとの関連性の度合いにも依存します。 症状からその結果に至るまで、すべてを説明します。しかし、これは私がこのカンファレンスの冒頭から言いたいこととは異なります。重要なのは、推奨されるトリアージと実行可能な次のステップです。私は何をすべきか？ここが健康保険との連携において非常に重要な点となります。これにより、彼らが何ができるのかという具体的なリンクが得られるのです。 これは単なる例ですが、ユーザーは腰痛から始めました。これは筋骨格系（MSK）のシナリオであり、理学療法パスウェイを推奨するに至りました。この場合、保険会社は直接紹介を行う手段を持っています。医師と直接話すことを飛び越え、必要な場所に直接つながるのです。 あるいは不安の場合、メンタルヘルスへと導かれます。自己ケアで済む場合もあれば、システムがセラピストの必要性を判断する場合もあります。その際、保険会社がカウンセリングアプリをカバーしている可能性もあります。 胸痛の場合は緊急性が高いです。これは救急（A&E）シナリオである可能性を検知したため、直接 999 に電話するよう案内します。あるいは、保険会社にオプションがある場合は、保険会社にも連絡するよう案内します。 最も一般的なケースとして、通常の一般開業医（GP）への相談があります。これはあらゆる症状チェッカーで目にする典型的なシナリオです。状況に応じて、ビデオ通話による GP 受診や対面での受診を案内することもできます。これもまた、保険会社と直接予約できる仕組みとなっています。 デモ - Healthily のスマート症状チェッカー これは、医療提供者と現在トライアル中の非常に簡単な例です。ユーザーには保険関連情報に関する多くのナビゲーションツールが表示されています。彼らは症状チェッカーに入ることにしました。年齢と性別を入力し、安全に症状チェッカーを利用できないような稀な疾患は持っていないことを確認します。そして、当初の訴えである「言葉が不明瞭になる」という症状を伝えます。システムはその情報を基に判断し、実際にその症状があるかどうかを確認する質問を行います。これは非常に重要です。私がここで伝えたい本質的な点は、常に確実性を確保したいという点です。承認ポイント（ratification point）は、私たちが検出した内容が実際に正しいことを保証するため、極めて重要なポイントとなります。その後、評価を継続することを選択します。その症状は数時間だけ続いたと述べています。高血圧があり、肥満でも喫煙者でもありません。わずかな混乱があり、それは新しい状態の混乱でした。怪我はありませんでしたが、言語や発話に若干の困難があるとのことです。 その後、システムは異なる質問セットを繰り返し提示します。先ほど説明した通り、これはトリアージ（選別）や危険信号の検出、そして患者が抱えている可能性のある病態に関連するものです。このプロセスは数ラウンド行われますが、あまり長くならないことを願っています。これにより、現在の状況についてかなり正確な理解を得ることができます。また、確率モデルを用いる際、イエスと答えたことだけでなく、ノーと答えたことも同様に重要であることを覚えておいてください。なぜなら、それによって特定の病態を除外したり、その発生確率を下げたりできるからです。 システムが十分な自信を持てるまでには数セットの質問が必要ですが、その段階でレポートを提供します。 このケースでは、救急車が必要な状況であるため 999（緊急通報番号）を推奨しました。なぜそうなるのかは後ほど詳しく説明します。これらは除外された事象です。最も可能性が高いのは、ここに直接示されている一過性脳虚血発作（TIA）と、脳卒中を意味する虚血性障害です。また、ユーザーが他の選択肢を選択することも可能です。これらの推奨を行いますが、医師の診察を受けたい場合はもちろんそうすることもできると伝え、111（非緊急医療相談番号）へ電話することも案内します。さらに、ユーザーが入力した内容に関する情報も提供し、自分の症状が正確に反映されているか確認できるようにしています。これらすべてを説明しており、症状から病態、そして具体的な行動指針に至るまで解説しています。 対話型チャットボットへの進化 次に皆さんにお見せするのは何でしょうか？まだカバーしきれていない、欠けているものがあります。それは、ユーザーが単なる質問から始める場合があるということです。彼らはまだ明確な症状を持っていないか、あるいは症状はあるものの、どこに向かうべきか本当に分かっていないこともあります。最初は単純な健康に関する質問からです。これをどう扱うべきでしょうか？また、こうした人々にもターゲットを絞ってアプローチできることをどう保証すればよいのでしょうか？そこで私たちは、会話型チャットボットの活用、つまり症状チェックから完全な会話型チャットボットへの移行を検討し始めました。では、具体的に何をするのかというと、ここでは詳細に立ち入るつもりはありません。これは現在構築中の全く新しい製品ですが、その仕組みを正確にご説明します。このシステムは RAG（Retrieval-Augmented Generation：検索拡張生成）モデルに基づいています。私は、これが医療分野においてどのように適用されるかについて解説いたします。 まず、質問意識型トランスフォーマー（question aware transformer）から始めます。これは、ユーザーが「COVIDとは何か」と問いかけ、続いて「症状は何か」と尋ねた場合、「COVID の症状は何ですか？」という質問を生成できることを意味しています。これにより、過去の文脈を統合した質問意識型のトランスフォーマーによる質問を作成します。なぜこれが重要なのかというと、この質問を使って、英国で最大級の健康データベースを検索するからです。データはリトリーバーモデル（retriever model）によってチャンク化されエンコードされた上で、ユーザーの問い合わせに対して検索が行われます。さらに精度を高めるために、「リーダーモデル」（reader model）と呼ばれる技術も活用します。これは各チャンクを確認し、問い合わせに最も一致するスニペットを抽出するとともに、それらのランク付けも行います。これらのすべてのモデル、つまりこの2つと以前のモデルは、すべて独自の独自データを用いてファインチューニングされています。これは、当社のシナリオにおいて可能な限り高い性能を発揮させるためです。また、各機能を個別に制御し、どこで失敗が発生するかを把握できるようにするため、これらは特定のマイクロサービスとして実装されています。 そして最後に、誰もがそうするように、LLM（大規模言語モデル）の世界における回答生成へと進みます。ここでは商用利用可能なモデルを使用しています。また、以前と同様に、独自のファインチューニング済みモデルの開発にも取り組んでいます。状況は非常に急速に進化しており、言語モデルの性能も著しく向上しています。私たちは、可能な限り最良のソリューションを提供できるよう努めています。現在、入手可能な中で最も優れたモデルを採用していますが、単に LLM を採用してそのまま使うだけではありません。実際には、システムが安全であることを確保するために、多くのガードレール（安全装置）を構築する作業を進めています。 RAG（検索拡張生成）モデルに基づき、制限された知識領域への対応を検討しています。つまり、モデルが回答するのは健康に関連し、かつ当社のデータに基づく質問のみとするよう保証します。事実確認を行い、LLM が提供する回答が実際に与えられたコンテンツに基づいていることを確認します。不確実性の推定も重要です。これは本当にハルシネーション（幻覚）を起こしているのか、それとも正しい答えなのか？そして安全なのか？おそらくこれが最も重要な点で、いかに安全であるかが問われます。例えば、「アレルギーに対して抗ヒスタミン薬を服用しても大丈夫ですか？」とユーザーが尋ねた場合、単に「はい、全く問題ありません」と答えることはできません。なぜなら、妊娠中の場合は特定の抗アレルギー薬を服用できない可能性があるからです。文脈がないため、これは直接的に安全ではない回答となります。現在、私たちはまさにこの課題に取り組んでいます。もちろん膨大な作業が必要ですが、安全なチャットボットの構築を目指しています。 デモ - Healthily のチャットボット 非常に速い例を一つご紹介しましょう。これは現時点では製品化されていません。現在、トライアルを実施中ですが、この内容の多くは変更される予定です。ここでは、先ほどお話しした内容とどのように連携するかを具体的に示します。 この場合、ユーザーは頭痛と発熱について質問しました。システムはそれに関する情報を提供し、さらに今回の場合は、私たちが提供するコンテンツである特定の URL についても案内しています。 その後、ユーザーは「なるほど、実はこれが娘の症状に似ている」と考えました（例では息子でしたが、ここでは娘として説明します）。彼らは髄膜炎ではないかと疑っています。この時点から、モデルは UQML モデル、あるいは私たちの意図検出モデルを自動的に認識し、直接症状チェッカーへ誘導します。 最後に確認できる内容は、以前ご紹介した症状チェッカーと同等の安全性を保証しています。質問の内容は依然としてベイズネットワークに基づいており、安全性を最優先に設計されています。ただ、対話型チャットボットという全く異なるシナリオで提示されている点が異なります。 今後の取り組み：症状チェッカーとチャットボットの連携 ここからどこへ向かうべきでしょうか。やるべきことはたくさんあります。例えば、症状チェッカーについては現在、クラス II 医療機器の認定を取得する取り組みを進めています。これは、当社のシステムに対する信頼性と臨床的な信頼性を確保するためです。すでにクラス I の医療機器として認定されています。チャットボットの側では、規制ガイドラインとの整合性を確保し、すべてのガードレールを構築しています。これにより、ある程度の安全性が保証されることを明確に言えるようになります。モデルの改善は継続しており、症状チェッカーおよびチャットボットの両方において行っています。 アーキテクチャについては、データの質向上に取り組んでいます。また、症状チェッカーがそのデータをどのように活用するかについても改善を進めています。これを実現するためのさまざまなプロジェクトを進行中です。一方、チャットボットでは、モデルの検索機能をより良くし、過去の発言内容をより意識させるよう努めています。さらに、症状チェッカーから得られる結果やレポートをチャットボットに直接組み込み、ユーザーがそれらについて質問できるようにすることを目指しています。 最後に透明性です。オンライン上で閲覧可能な透明性文書を用意しており、そこで私たちが何を行っているかすべてを確認できます。私たちは常にこの方針を堅持し、毎回そのように努めています。症状チェッカーの根拠（rationale）の改善にも取り組んでおり、なぜ特定の症状について質問するのかを明確にしています。チャットボットの側では、ハルシネーション（幻覚的生成）の低減、安全性の向上、出典の明示化に取り組んでいます。 要約 Healthily では、エンドツーエンドのシステム構築を目指しています。ユーザーからの質問や症状から始まり、最終的にその情報に基づいて実際に何ができるかというアクションに至るまでをカバーします。可能な限り会話形式で、自然な対話を実現することに取り組んでいます。ここがチャットボットの登場する理由です。確率モデルと安全性を意識したトリアージを用いた推論知能によって、システムを可能な限り安全かつ信頼性の高いものにするよう努めています。また、医療提供者や保険会社との連携を通じて、提供されるサービスが実際に適用可能で現実的なものであることを保証しています。ガードレールの作成やシステムの検証・監査可能性の向上により、臨床現場に可能な限り適合したシステムを目指しています。究極的には、私たちは人々のためにこのシステムを構築しており、ユーザーがより自信を持ち、適切なタイミングで行動できるよう誠実に支援することを目指しています。 質疑応答 クレインダー医師：これは大規模言語モデルが重要な役割を果たす主要な領域の一つです。クリック可能なリンクを経由するのではなく、実際に適切にチャットできるような保険適用可能なクラス II 製品が実現するのは、いつ頃になるとお考えですか？ アンドレ・リベリオ：私たちはまさにそれを探っています。もちろん、症状チェッカーについてはクラス II 医療機器から始めます。それが最初の部分です。それを基に段階的に構築しています。最後に示した対話型 UI は、ユーザーがその対話形式に徐々に慣れるための手段を提供します。規制当局に対して、「これは依然として同じ質問を全く同じ方法で行っているため、単なるフォーマットの違いであり、クラス II 医療機器であり続ける」と主張するのは容易です。 次に、そこから適切な自然言語へと移行できることを証明する必要があります。すでに、私たちはそれができるとお伝えできます。例えば、自然言語を使用することも可能です。私たちの NLP モデル（自然言語処理モデル）を使って、「これはあなたが言ったことですか？これはあなたが言ったことですか？」と繰り返し質問することもできます。ユーザー体験としては必ずしも最適ではないかもしれませんが、機能します。なぜなら、私たちが特定した内容に対してユーザーが「はい」または「いいえ」と回答し続ける限り、それは安全だからです。彼らが私たちの質問を確認していることになるからです。 目指すべきは、ある一定の確率（X 量）で安全であると確信できる点に到達することです。その X の値が具体的に何であるかはまだ不明ですが、私たちが許容でき安全だと判断できる数値です。それが目標となるポイントです。私たちは現在、症状チェッカーをクラス II 医療機器として扱っています。また、保険会社と連携してこれらのチャットボットを構築しており、人々がそれらを必要としているか、実際に利用しているかを検証しています。 そこから先は、境界線を押し広げ、さらに進んでいくことになります。そして、最終的にはクラス II の認定を目指すのです。 Dr. Kreindler: チャットとボタンをクリックすることの間に、使いやすさの違いに関する研究はすでに実施されていますか？ Andre Riberio: 最近、チャットボットの使いやすさを理解し、人々がそれを好むかどうかを明らかにする研究を行いました。例えば、評価の最後に統合される機能について、より古典的なアプローチであるフォームベースのアプローチと比較して、どちらを好むのかを検討しました。人々は、チャット形式が質問に組み込まれており、システムとの対話がより自然な方法のように感じられるため、チャット形式を好む傾向があるようです。 Dr. Kreindler: 公式見解ではありませんが、直感的にお考えください。臨床医としての私たちにとって、声のイントネーションやものの視覚的外観といった多様な情報（multimodal）を評価することは、どれほど重要でしょうか。「息切れしているようですが、声に少し喘鳴があり、それ以外は元気で明るく、頬も赤らんでいて健康そうに見えますね。おそらく、これは最悪の種類の息切れではないでしょう」。このような多角的な評価は、あなたのシステムのようなものにおいて、今後どの程度不可欠なものになるとお考えですか？ アンドレ・リベリオ：はい、もちろん。いずれその方向に進む必要があります。現時点では、例えばユーザーが皮膚の悩みを伝える場合、それについて質問することはできます。「赤いですか？」「均一ですか？」と尋ねることもでき、対応を試みることは可能ですが、依然として焦点はユーザーが何を知っているか、そしてどのように回答できるかに置かれています。その問題点は、システムがまだ画像を取得し、「これはこれである」と自信を持って断定する精度に達していないことです。そのため、この領域はまだ難しいのですが、いずれ確実にそこへ到達することになるでしょう。再び考えられるのは、画像から直接理解を試み、その後ユーザーの承認を得て、見ているものが一致しているかどうかを確認するようなシナリオです。現状とこれらのシナリオの間にはまだギャップがありますが、確かにそのようなケースが生まれることになります。 クレインドラー医師：少なくとも、その情報を収集し、テキストベースの情報よりも多くのデータを含む紹介状を提示することは可能です。それは今日でも実現できます。 アンドレ・リベリオ：はい。 参加者 1：承認（ratification）について言及されましたが、データ品質に関するさらなる課題や、それに対してどのような対策を講じたかについてお伺いしたいです。 アンドレ・リベリオ：承認のことですか？ 参加者 1：はい、その件についてです。他にご存知のものはありますか？ アンドレ・リベリオ：はい。いくつかの制御システムがあります。承認（ratification）はその一つで、先ほどお話ししたものです。これはまさに、ユーザーからテキストによる質問があり、それを症状に変換する時点からのプロセスです。私たちは常に確認を求めます。ある時点で、「90% の確信があればそれでよい」という方針も検討しましたが、採用しませんでした。この特定のシナリオにおいては、少なくとも現時点では、常に「これが私たちが特定した正しい内容ですか？」と確認することが最善であると判断しました。また、システムは継続的に学習しており、データが蓄積され続けています。現在の数値に関する統計資料は手元にありませんが、将来の展望を示すスライドを最後に用意しており、現在の大規模言語モデル（LLM）と比較して、実際にどれほど優れているかを検証しようとしています。現在、データセットは整備されていますので、これから分析を進めていきます。もう一つの制御ポイントとして、「確認（clarification）」という仕組みがあります。これは、ユーザーが提示した症状が複数の意味を持つ可能性がある場合に用いられます。 ユーザーが複数の意味を持つ特定の症状を尋ねた場合、その中からどの症状を指しているのかを質問し、単なる確認だけでは不十分となるよう対応します。なぜなら、ユーザーは「はい」と答える可能性があり、それが異なる意味を持つことになるからです。私たちは別の選択肢のセットを提供し、ユーザーがそれを選択して進めることができます。これが制御ポイントです。これにより、私たちが行うすべてのテキストが、ユーザーの知識に基づいて正確であることを保証しています。その後、私たちが質問するすべての質問は、症状チェッカーで生成されたものではなく、私たちのデータセットから非常に具体的なものとなっています。これらは完全に管理されています。最後に、ユーザーに彼らが言ったことを正確に記したレポートを提供し、何か見落とされていないか常に検証できるようにします。実際には見落としがあってはなりませんが、もし見落としがあった場合でも、ユーザーがそれに気づくか、あるいは医師が気づくようにしています。なぜなら、私たちはそのレポートを医師にも提供できるからです。これらが制御ポイントです。 参加者 2: 複数の症状がある場合はどう対応しますか？例えば、足の痛みと頭痛があります。 アンドレ・リベリオ：はい。いいえ、確かに複数の症状を検出できます。存在するすべての症状を検出可能です。単一単語や複数単語の両方に対応しています。ただし、それらが非常に近接している場合、異なる概念を指す場合に混同することがあります。これは一般的ではありません。通常、裏側では、主要な概念とその関連する類義語を手動で作成したデータセットを使用しています。例えば、「頭痛」の場合、「頭蓋痛」「頭部疼痛」などが該当します。これらそれぞれが独自の概念となります。「頭蓋」は「頭」の類義語であり、「頭」は何らかの概念の類義語です。ユーザーが選択する任意の組み合わせでも、最終的に「頭痛」として認識されます。この仕組みは検索機能にも適用されており、どの組み合わせでも正しく動作します。いいえ、同じクエリ内での複数の症状や、各症状における複数単語にも対応しています。 参加者 2：それらは別々のものとして扱われるのでしょうか？ アンドレ・リベリオ：はい。 参加者 2：もしそれらが同一の問題の一部であれば、正しく認識できない可能性がありますか？ アンドレ・リベリオ：先ほどの例では、頭痛と発熱が別々の症状として検出されます。私たちが行うのは、これら両方を組み合わせて一つの病状を説明することです。実はここで指摘すべき点があり、それはユーザーが多すぎる症状を報告していないかということです。実際には持っていない症状や、自分が気づいていない症状を報告してしまい、適切な評価につながらないケースがあるかもしれません。なぜなら、私たちが評価を行うためにはこれらの症状が必要だと判断しているからです。実際には、私たちは複数の取り組みを行っています。これまでの観察では、ユーザーは通常、最初のクエリで1.5個程度の症状を入力することが多いことが分かっています。 一般的に、評価は常に可能ですが、稀に5〜10個もの症状を入力してしまうケースや、逆に頭痛だけを最初から最後まで報告してしまい、真の評価を提供できないケースもあります。そのような場合は、ユーザーをいくつかのフォールバック（代替手段）へ誘導します。具体的には、「頭痛についてのみお話しいただいた場合、これは信頼できる評価とは言えません。原因は様々考えられます」といった情報を提供し、説明を行います。ご指摘の通り、私たちはこれらを別々の症状として扱いますが、それらすべてを一つの病状として統合して説明するように努めています。 参加者3：もしユーザーがワークフローを完了できない場合、どうなるのでしょうか？例えば、ワークフローを進めている最中に腕にしびれを感じて、スマホを落としてしまったとします。 クレインドラー医師：その場合は意識を失います。 参加者3：その通りです。電話の向こう側に人間がいれば、何かおかしいと気づくでしょう。ユーザーが軌道から外れたことに気がつくはずです。どうやってバリデーターを信頼すればよいのでしょうか？また、そのバリデーターが実際には予後への適切なガイドラインとなっていることを、どのように確認できるのでしょうか？ アンドレ・リベロ：ユーザーが途中で止めてしまった場合、どうなるのでしょうか？現時点では、何も起こりません。私たちは健康保険提供者と連携しています。必ずしも手続きを進めるという決定は下されていません。進めることも可能ですが、タイマー機能を持っていますし、相談が中断された時刻も把握しています。また、ユーザーの身元も特定可能です。ただし、匿名データで運営している当社の「Healthily」ではなく、健康提供者側が把握しています。潜在的には、何かが発生したことを伝え、追跡させることも可能ですが、現時点ではそのような計画はありません。 どうやってバリデーターを信頼すればよいのでしょうか？あなたが仰るバリデーターとは、私たちの臨床医のことですか、それともモデルのことでしょうか？ 参加者3：即座に回答を提供するモデルのことです。 アンドレ・リベリオ：それには2つの側面があります。1つはQ&A機能であり、これはチャットボットがモデルを使用して検証を行うものです。はい、私たちはこれらを継続的に改善しています。臨床データを用いてこれらのモデルをさらに向上させ、前述したように、第II類医療機器として認定されるレベルに到達することを期待しています。 症状チェッカーについては、さまざまなテストを実施しています。モンテカルロ法と呼ばれる一連のテストがあります。モンテカルロ法をご存知の方も多いかと思いますが、これは基本的に、対象とする疾患に基づいて症状のサンプルを生成する手法です。私たちはその組み合わせを100通り作成し、それらをチェッカーに通して、どのような結果が得られるかを確認します。その後、医療チームがその結果を検証します。 これに加えて、医師によって手動で定義された症例（ビネット）も用意されています。合計2,200の症例が作成されており、そのうち460は中核となるものです。これらすべてに合格する必要があります。これはつまり、特定の症状セットに対して、該当する疾患が存在していなければならないことを意味します。もし不合格となった場合、システム内で何らかの変更が行われたことを示し、修正が必要となります。あるいは、本来そうあるべきではないことが証明された場合は、症例自体を修正します。 テストにはいくつかの種類があります。実行される手動による症例テスト、モンテカルロ法に基づく自動テスト、さらにUI体験に関する手動テスト（ボタンが存在しているか、そしてそれらが意図する対象を正しくターゲットとしているかの確認など）もあります。私たちは包括的なテストのセットを持っています。 クリンドラー医師：患者のトリアージを行う者にとって、最も恐ろしいことのひとつは、ある症状を抱えた患者に対して「帰宅して大丈夫です」と言えるかどうかです。常に、「あの判断で本当に良かったのか？」という疑問が付きまといます。他の情報や血液検査の結果などを持っていても同様です。誰に対しても何らかのことで「問題ありません」と伝えることは、決して簡単なことではありません。 参加者 4：あなたのシステムを利用した場合と、実際に医師に診てもらう場合を比較したデータはありますか？何か数値やパフォーマンスに関する具体的な情報はありますか？ アンドレ・リベリオ：以前、インペリアル・カレッジ（Imperial College）から得たデータがあります。他社製品との比較における当社のパフォーマンスについてもご説明できます。他の競合他社と比較しても、当社が提供するツールは最も安全なものでした。誤解しないでください。私が言いたいのは、私たちを含めすべての競合他社は、過剰にトリアージを行っているという点です。また、ジャック氏の指摘された点にも通じます。私たちは常に最善の選択肢を提供することに注力しており、それが精度を若干下げる結果になっても構わないと考えています。これが私たちの最大の焦点です。「自己ケアで十分です」とお伝えするときは、確かに自己ケアであると確信していますし、その逆も同様です。例えば、緊急事態と判断されたケースが実際には一般開業医（GP）の診察で済むものだったとしても、私たちは正確性を確保するためにそう判断します。そのため、多くの警戒すべき兆候（red flags）を設けています。安全性においては当社が最も優れています。精度については、一部の競合他社よりもわずかに低い結果となりました。医師との比較も非常に興味深い点があります。医師 3 人を集めても、彼らが全員一致するとは限らないからです。 クレインドラー博士：4 つの意見を得ることができます。 アンデレ・リベリオ：まさにその通りです。この数値を取得するのは非常に難しいですが、現在その方向に向けて取り組んでいます。当社の医療チームは、健康保険パートナーの一つを通じて送付したデータのいくつかを検証しています。デジタル GP を確認するために誰がアクセスしクリックしたかという情報から、そこからどのような結果が得られたかまで、すべて把握しています。現在はこれらを検討中であり、正確性がどの程度であるか、またどのように改善できるかについて全体像を把握しようとしています。 通訳付きの他のプレゼンテーションを見る 録画日時： 2026 年 3 月 11 日

症状チェッカーからスマートチャットボットへ：AIが果たすバーチャルケアにおける役割

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト