評価基準(rubric)の設計
何をもって「臨床的に妥当」とするかを、用途と想定読者に合わせて評価軸へ分解し、 配点と重大度の基準を明文化します。
Medical AI quality assurance
医療AIの回答、AI生成の医療コンテンツ、患者向け説明文を、現役医師が評価基準(rubric)の設計から行い、 1ケースずつ評価します。合否だけでなく、どこで、どう間違えたかを型と重大度で分類して返します。
内科専門医/消化器病専門医/消化器内視鏡専門医 — 専門は消化器内視鏡と肝胆膵領域、とくに膵癌
現場の入口
モデルの出力が医学的に妥当か、社内で判定できる人がいない。
医師レビューはあるが、基準が言語化されておらず、担当者ごとに判断がばらつく。
英語圏のベンチマークをそのまま使っており、日本の診療文脈で成立しているか確かめていない。
AI生成の医療記事や患者説明文を、公開前に点検する体制がない。
モデルを更新するたびに、品質が上がったのか下がったのか比較できない。
Service
何をもって「臨床的に妥当」とするかを、用途と想定読者に合わせて評価軸へ分解し、 配点と重大度の基準を明文化します。
実際の出力を1ケースずつ評価し、判定の理由を残します。 担当者が変わっても同じ判定が再現できる形にします。
誤りを個別の指摘で終わらせず、繰り返し起きる型に分類し、 患者に届いたときの重大度で並べ替えます。
評価結果、頻度の高い失敗の型、優先して直すべき箇所、 次回以降も同じ基準で測るための手順をまとめます。
Targets
Outcomes
Process
プロダクトの用途、想定利用者、リスクの所在、評価したい観点を確認します。
評価軸、配点、重大度の基準を作り、数ケースで試して調整します。
合意した件数を評価し、判定と理由を記録します。
失敗モードの分類、重大度順の優先順位、改善案をまとめて共有します。
必要に応じて、更新後のモデル・コンテンツを同じ基準で測り直します。
Pilot
いきなり全件を評価するのではなく、限られたケース数で基準を作り、 その基準が自社の判断に使えるかを先に確かめる形をおすすめしています。
評価パイロット
rubric設計、ケース評価、失敗モード分類、レポートまでを一度にまとめた最小単位です。
継続評価
モデル更新やコンテンツ追加のたびに、同じ基準で測り直し、変化を記録します。
料金は、評価対象、ケース数、rubricの粒度、レポート形式、納期によって個別にお見積もりします。
Background
Ubie「ユビー病気のQ&A」にて、消化器・肝胆膵領域を中心に、病名・症状ページおよび 1,000件超、20万字超の個別Q&Aの医学監修に携わっています。
医療AIの評価も、判断の基準を言語化し、同じ物差しで大量に読み続ける仕事という点で地続きです。 架空症例を使った公開評価サンプルで、採点、失敗モード分類、改善方針をご確認いただけます。
Ubie supervisor page 今までに監修したページを見る 監修者ページ掲載の病名・症状ページ 66件、確認済み個別Q&A 1,000件超。 執筆・監修実績を見る 異なる失敗型を扱った公開評価サンプル5件を見るFAQ
評価基準(rubric)の設計、ケース単位の評価、失敗モードの分類、レポートと改善提案の4つです。何をもって臨床的に妥当とするかを評価軸へ分解し、実際の出力を判定理由とともに評価します。
ありません。患者氏名、生年月日、診察券番号、カルテ本文、検査結果、実症例の詳細は扱いません。評価には、AIの出力と、必要であれば匿名化・仮想化した入力をご用意ください。
その場合は基準づくりから始めます。用途と想定利用者を伺い、評価軸と重大度の基準を設計したうえで、数ケースで試して調整します。
その場合は、既存のレビュー基準そのものを評価対象にできます。判定がばらつく箇所、抜けている観点、日本の診療文脈と合っていない項目を整理します。
いいえ。臨床的な妥当性の評価を行うもので、適法性の判断は行いません。公開前に確認が必要な場合は、別途専門家確認を前提としてください。
現状は医師1名(石川)が担当します。複数名での評価一致度の測定が必要な場合は、設計の段階でご相談ください。
そのままでは成立しない項目が出ます。診療体制、受診導線、保険制度、利用できる薬剤や検査の事情が異なるため、日本の診療文脈で評価基準が無効になる箇所や危険な誘導になる箇所を確認し、代替基準を検討します。
Boundary
個別症例への診断・治療助言、診療行為の代替、薬機法・医療広告・法務上の適法性判断、 モデルの安全性についての認証や保証は行いません。評価は、提示されたケース範囲についての 臨床的な妥当性の判断であり、プロダクト全体の品質を保証するものではありません。
Contact
ご相談時点では、プロダクトの用途、想定利用者、評価したい観点、希望するケース数の目安があるとスムーズです。 出力例の共有は、秘密保持の取り決めのあとで問題ありません。