Epicの敗血症アラートエンジンは、2021年にミシガン大学医学部（Michigan Medicine）で行われた検証において、失敗に終わった。後に敗血症を発症した患者の3分の2を見逃した一方で、全入院患者の18%に対してアラートを発報していた。この誤りは、典型的な「データ漏洩（data leakage）」エラーに起因する。モデルが、すでに感染症の疑いがあることを示す指標である「医師による抗菌薬の処方」を予測因子としてカウントしており、実質的に臨床医がすでに行った決定を繰り返していたのである。
なぜモデルは失敗したのか
ミシガンのチームは、一般的な数年間にわたる品質改善プロジェクトの規模に相当する38,455件の入院事例を調査した。Epicの内部ベンチマークでは高い精度が約束されていたが、独立したテストの結果はその逆を示した。モデルの「高リスク」アラートは患者の約5分の1で発報されたが、実際の敗血症症例の3分の2は見逃されていた。実際には、システムは本来捉えるべき事象を見逃しながら、あまりにも頻繁に「注意」を叫んでいたのである。
根本的な原因は、機械学習アルゴリズム自体の欠陥ではなく、入力されたデータにあった。抗菌薬の処方の有無を入力として使用したことで、モデルは臨床医がすでに行った選択を予測することを学習してしまった。アルゴリズムが患者をフラグ立てした際、それは患者の生理学的状態が敗血症の兆候を示していたからではなく、医師がすでに抗菌薬を処方していたからであることが多かった。
病院AIにおけるより広範な問題
Epicの敗血症モデルは何年も前から数百の病院に導入されているが、このデータ漏洩のエラーは、集中的な検証作業が行われるまで隠れたままだった。この事例は、システム的な弱点を浮き彫りにしている。ほとんどの医療システムにおけるAIプロジェクトには、このような問題を早期に発見するために必要な運用チェックが欠けているのである。
- 外部テストの欠如 – 病院には外部テストが行われていなかった。
- 継続的なモニタリングの欠如 – モニタリングが行われていなかった。
- 明確な責任所在の欠如 – データの品質やモデルのパフォーマンスに責任を持つ指定されたチームがないため、問題が見過ごされてしまう。
これらのギャップにより、多くのAIイニシアチブは「パイロット地獄（pilot purgatory）」に陥り、概念実証（PoC）の段階から先に進めなくなっている。
断片化されたデータがもたらす隠れたコスト
敗血症の事例は、断片化されたヘルスITエコシステムがいかにAIを妨害するかをも示している。一般的な障害には以下が含まれる：
- データの自動交換ができないレガシーなEHRモジュール内に閉じ込められた患者記録。
- 画像システムと検査システムが連携できず、手動でのファイル転送を強いる状況。
- 単一の人物のデータが複数のチャートに分散してしまう、重複した患者識別子。
- モデルのトレーニングのために統合されることのない、別々のサイロに保存された臨床ノートやバイタルサイン。
クリーンで精査されたデータセットでトレーニングされたモデルであっても、その後に投入されるデータが実運用における乱雑なものである場合、パフォーマンスは静かに低下していく。臨床医の信頼はすぐに失われる。複数の画面を通じてアラートを追いかけなければならない看護師は、たとえ基礎となるアルゴリズムが技術的に健全であっても、それらを無視するようになるだろう。
信頼できるAIのための4つの「退屈な」基盤
機能的なAIの導入は、ニュースの見出しになることはめったにないが、実用的な4つの能力に基づいている：
- 相互運用性（Interoperability） – データは、手動のエクスポート・インポート手順を踏むことなく、EHR、検査、画像プラットフォーム、および意思決定支援ツールの間で流れる必要がある。
- ガバナンス（Governance） – 責任ある個人またはチームがデータの品質を所有し、時間の経過とともにモデルの出力を監視しなければならない。
- ワークフローへの統合（Workflow integration） – アラートは臨床医の既存のワークキュー内に表示される必要がある。余分なクリックや画面の切り替えは、導入の妨げとなる。
- スケーラブルな運用（Scalable operations） – モデルを本番環境に投入する前に、自動化されたモニタリング、アラート疲れ（alert-fatigue）の分析、および定期的な再学習パイプラインが不可欠である。
これらのステップのいずれかをスキップすると、プロジェクトはEpicの敗血症モデルで見られたような「静かな失敗」に対して脆弱なままとなる。
AIソリューションを購入する前に確認すべき質問
病院は、具体的な回答を求めることで、コストのかかる誤りを回避できる：
- モデルが使用するすべてのシステムにわたって、単一の患者のデータを追跡できますか？
- データの品質を維持し、モデルのパフォーマンスを監督する責任者は、具体的に誰ですか？
- アラートは、サンドボックス環境だけでなく、実際のシフト中の臨床医を対象にテストされていますか？
- パフォーマンスのドリフト（性能の変化）をどのように特定し、対処するかを明記した、文書化されたモニタリング計画はありますか？
ベンダーが特定の人物、プロセス、またはモニタリングダッシュボードを提示できない場合、組織は一旦立ち止まって再評価すべきである。
まとめ
Epicの敗血症モデルが失敗したのは、機械学習が病院に適していないからではありません。周囲のデータパイプラインとガバナンス体制が欠如していたことが原因です。医師自身の判断を予測するようなモデルは、アルゴリズムではなく、データエンジニアリングのレイヤーにこそ改善が必要であることを警告しています。ヘルスケアにおいて信頼できるAIを構築するには、あらゆる重要なITシステムを稼働させ続けるための、あの「退屈な」インフラストラクチャが必要です。すなわち、クリーンで連携されたデータ、明確な責任の所在、ワークフローに組み込まれたアラート、そしてプロアクティブなモニタリングです。これらがなければ、たとえ最も洗練されたモデルであっても、結局は間違った警告を、間違った相手に発し続けることになってしまいます。