Google、ヘルスケアAIを評価する複数手法のフレームワークを公開

Googleは発表しました。2026年11月4日に白書を公開し、ヘルスケア分野の汎用生成AIをどのように評価しているかを示しました。このフレームワークでは、クローズド形式の質問によるベンチマーク、AIによる自動評価、専門家による人手でのレビューを組み合わせ、一般的なシナリオからリスクの高いシナリオまで、正確性、安全性、有用性を評価します。

著者のSarah Montgomery-Taylor医師は、Google for Healthの臨床評価責任者です。Elizabeth McGlynn医師とDana Gelb Safran医師も、この取り組みに協力しました。Googleによると、この手法は同社が開発したもので、モデルが有用かつ正確な回答を提供し、安全なヘルスケア上のやり取りを支援できるかを評価するため、現在も活用されています。この方法論の公開は、透明性を高め、開発者、研究者、臨床医が人々から信頼されるツールを構築できるよう支援することを目的としています。

評価を実際の臨床利用に対応させる

著者らは、個別のタスク向けに構築された評価手法では、汎用モデルを十分に評価できないと論じています。例として挙げられているのは、CT画像から肺がんを検出できても、マンモグラムから乳がんを検出したり、会話を要約して記録にまとめたりすることはできない、生成AI以前のAIモデルです。1つのモデルが数百、数千、あるいはそれ以上のタスクを担えるようになると、開発者や医療機関には、やり取りやリスクの優先順位を決める方法が必要になります。

テストケースを選ぶ前に、評価担当者は「クリティカル・ユーザー・ジャーニー」を整理します。つまり、誰がシステムを使い、何を達成しようとしているのか、また、そのためにどのような手順を踏むのかを明らかにします。ユーザーには、患者、家族、臨床医、事務担当者などが含まれます。この整理をもとに、代表性のあるテストデータと評価指標を設定します。また、意図された使用方法だけでなく、適応外での過度な依存や安全フィルターを回避しようとする試みなど、よくある誤用も対象に含めます。

続いて、各アプリケーションを3つの領域で評価します。正確性の評価では、医学的コンセンサス、エビデンスによる裏付け、事実性、臨床推論、文脈への適切さを確認します。医療情報の要約などのタスクでは、情報源に基づいているかどうかも評価に加えます。安全性については、記述が正しいかどうかだけでなく、回答を解釈して行動した場合、あるいは行動しなかった場合に、どのような害が生じ得るかを検討します。その害の深刻度と発生可能性の両方を評価します。有用性の評価では、ヘルスリテラシーへの配慮、関連性、網羅性、そして回答を受け取った人が実際に行動に移せるかどうかを確認します。そのため、回答は正確でも安全ではない場合や、正確で安全であっても、複雑すぎたり行動に結びつかなかったりして、ユーザーの役に立たない場合があります。

論文の例は、タスクによって主なリスクがどう変わるかを示しています。症状を確認する一般ユーザーの場合、緊急の受診が必要な危険な兆候を強調できないことが、中心的な安全上の懸念となります。一方、過度に不安をあおる回答は不必要な不安を招く可能性があり、自己評価の手引きが不明確だと、適切な次の行動を妨げるおそれがあります。臨床医向けにAIが作成した退院時要約では、幻覚、情報の欠落、事実誤認が正確性を損ないます。アレルギーや禁忌薬の見落としは安全上の危険を生み、分かりにくい書式や一貫性のない時系列は有用性を低下させる可能性があります。

自動化による規模と人間の判断を組み合わせる

最初の評価手法では、多肢選択式問題のように明確な正解があるテストを用います。これにより、基礎知識を大量に確認する際のコストを比較的低く抑えられます。しかし、固定されたテストでは、実際のやり取りの複雑さや代表性を再現できません。データ汚染も別の課題です。テスト問題が学習データに含まれていると、結果が汎用的な医学的推論能力ではなく、テスト対策を反映している可能性があります。そのため、このフレームワークではベンチマークを使って基準を確立し、その後の評価の目標を定めます。実環境での性能を検証するには、さらに別の手法が必要です。

2つ目の手法では、別のAIシステムに採点を任せます。こうしたAI自動評価器は、記述式の回答に明文化された評価基準を適用するため、専門家が現実的に採点できる数を大幅に上回るシナリオを評価できます。たとえば、ユーザーが最初に臨床情報を明かさない模擬的な複数ターンの会話を評価し、モデルが助言を提示する前に確認の質問をするかどうかを検証できます。ただし、自動評価器も専門家が作成した参照データと照合して検証する必要があります。冗長な回答に高い評価を与えたり、自らと同じモデル系列の回答を好んだり、ノイズを含む人手の注釈を引き継いだりする可能性があるためです。

その後、臨床医やその他の分野の専門家が、複雑な症例、例外的なケース、臨床的コンセンサスが限られているテーマなど、自動評価基準の弱点が表れやすい事例を検討します。また、出力が地域の臨床慣行や、さまざまな患者集団に適合しているかも評価します。これとは別に、レッドチームテストでは、感情に訴える、架空の設定を用いる、医療従事者になりすますといった手法を使い、安全上の境界を検証します。こうした手法は、製品の意図された範囲を超える出力を引き出すことを狙います。人によるレビューにも誤りはあります。著者らによると、評価タスクでは2人の医師の評価が30～40％、あるいはそれ以上異なることがあります。そのため、評価者間のばらつきを抑える対策と、適切な分析が必要です。

導入後も評価を継続

評価は製品が存在する前から始まり、基盤モデルの一般的な能力と安全性をテストします。モデルをアプリケーションに組み込み始めると、評価の対象はその製品のユーザーやワークフローに合わせたものになります。リリースが近づいた段階では、サイレント・シャドートライアル、臨床パイロット、段階的な展開など、管理された導入を行うことがあります。その際は、広く提供する前に、人間工学とユーザビリティのテストも実施します。

臨床チームと開発チームは、普遍的な数値基準や恣意的な数値の足切りラインではなく、アプリケーションの臨床リスクプロファイルに基づき、各製品ゲートで合格基準と評価基準の重み付けを共同で設定する必要があります。導入後は、開発者がアルゴリズムのドリフトとシステムの安定性を追跡します。導入する組織は、専門家向けツールについては臨床ワークフローの安全性を、一般消費者向け製品についてはユーザーの安全性と利用パターンを監視します。

著者らによると、ユーザーからの苦情やセンチネルイベントのような事後対応型のシグナルだけでは、導入後のモニタリングを担いきれません。テストセットは実際のやり取りとは異なり、ユーザーは経験を積むにつれて、プロンプトや期待する内容を変えていきます。モニタリングで得られた知見は、要件やトレーニング、以後の評価の優先事項に反映させる必要があります。やり取りや健康上のアウトカムを長期的にモニタリングするには、データのサイロ化に加え、プライバシー、技術、組織面の障壁があります。この論文はさらに、開発者と医療システムが担う共同責任、導入コスト、独立した検証、科学的コンセンサスを、今後取り組むべきガバナンス上の課題として挙げています。

開発者や医療システムにとって、このフレームワークは、モデルが静的なベンチマークに合格したかどうかという問いから、開発から導入までの全過程で、精度、安全性、有用性を実証できるかという問いへと視点を移します。中心となる課題は実務面にあります。責任の所在を定め、取り組みに必要な資金を確保し、組織やデータの境界を越えて結果を独立に検証しながら、モニタリングを説明責任に結び付けることです。