ヘルスケア AI の設計：メンバー対応を最優先するエンジニアリング

ヘルスケア AI の設計：安全は「後付け」ではなく、アーキテクチャの根幹に

生成 AI が医療現場に導入される中で、「誤ったアドバイス」や「緊急事態の見落とし」という致命的なリスクが現実のものとなっています。単なるプロンプトの調整で解決できる問題ではなく、機密情報の保護や生命に関わる判断を、確率的モデルに頼らずコード層とアーキテクチャレベルで設計し直す「ガードレールファースト」のアプローチが不可欠です。

医療 AI が抱える「本番環境の現実」

現在、4,000 万人以上の人が健康問題のトリアージに生成 AI を利用しています。しかし、その実態は決して順風満帆ではありません。過去 1 年間で起きた深刻な事例を振り返れば、AI の危険性が浮き彫りになります。

ある 60 歳の健康な男性が、AI に「食塩の摂取量を減らす方法」を尋ねたところ、「臭化ナトリウム（bromide）に置き換える」という誤ったアドバイスを受けました。その指示に従った結果、彼は 3 ヶ月後に精神錯乱と幻覚を起こし、救急搬送されました。体内の臭化物濃度は安全基準の 200 倍を超え、3 週間もの入院を余儀なくされたのです。

また、別の研究では、消費者向け医療 AI が命に関わる緊急事態（糖尿病性ケトアシドーシスや呼吸不全など）を 50% の確率で見逃し、「数日以内に医師の診察を受けるよう」指示していたことが判明しています。正解は即座に救急搬送だったはずです。

これらの事例は「特殊なケース」ではありません。患者安全を評価する ECRI が、2026 年の医療技術リスクランキングで「AI チャットボットの誤用」を第 1 位に選定したように、これはすでに本番環境の基準値（production baseline）として認識されている問題です。

「信頼できる患者に AI を提供する際、どうすれば安全を担保できるのか。その答えは、3 つの譲れない土台から始まります。」

1. PHI 保護：ポリシーではなく「アーキテクチャ」で守る

医療 AI の設計において最も重要なのは、機密個人情報（PHI）の保護です。多くのチームが PHI を「ランタイムの問題」、つまりログに書き込まれたデータを後から削除する課題として捉えています。しかし、これは反応的なアプローチに過ぎません。

真のアプローチは、データ ingestion（取り込み）直前のパイプライン境界で PHI を除去する設計です。データがデータレイクに保存される段階では、すでに PHI は存在しない状態にする必要があります。開発者がダッシュボードを開いても削除すべき情報など最初からないため、漏洩のリスク自体をゼロにできます。

さらに、本番環境と非本番環境（開発・テスト）は物理的に完全に分離する必要があります。1 本の配管（パイプ）が繋がっているだけで、患者データが開発環境に漏れる可能性があります。HIPAA や FDA のガイドライン、州法などは「後付けのルール」ではなく、システム設計の根幹となる入力情報です。

「HIPAA を既存のシステムの上に貼り付けるのではなく、HIPAA から始めて、その周囲にアーキテクチャを成長させるのです。」

アクセス権限も同様に厳格に管理されます。役割と地理的な地域（リージョン）が鍵となります。規制対象外の地域のエンジニアが、生データ（raw PHI）にアクセスすることはできません。これはポリシーの適用というより、システム自体が特定の失敗を起こせないように設計されている状態です。

2. コード層による決定の上位配置：確率モデルに任せてはいけない

生成 AI は文章作成や長文の対話には優れていますが、「絶対に間違えられない」判断においては信頼性が低すぎます。緊急対応、身份確認（アイデンティティ検証）、トリアージなど、失敗が許されない行為は、プロンプト実行前に動作するコード層で決定する必要があります。

これは「モデルの上にコードを置く」というスタック構造を意味します。すべての会話ターンはまずコード層を通り、そこで不可逆的な判断（911 への転送、臨床医の介入要請など）が下されます。その後、初めて確率的なモデルが処理を行います。

「モデル自体も、システムプロンプトで構成されたものも、ガードレールではありません。コード層こそが、最も近い安全装置です。」

なぜなら、大規模言語モデル（LLM）のベンチャーさえも、権限階層において「ユーザー」の上位にある「ルート」「システム」「開発者」などの層を信頼していないからです。プロンプトは 1 つの入力攻撃で上書きされてしまう可能性があるため、セキュリティ境界として信頼してはいけません。

具体的なコード層の実装例としては以下の 3 点が挙げられます。

• 緊急エスカレーション: ユーザーが自傷行為や急性の医療的危機を訴えた場合、モデルにその文を見せる前に、コードが即座に 911 や 988（自殺予防ホットライン）へルーティングします。
• 意図の経路指定（Intent Routing）: クリニカルな質問が、誤って一般的なテクニカルサポートや教育コンテンツのエージェントに流れていかないよう、高リスクなパスを確定的に決定します。
• 身份確認: メンバーデータに触れる前に、認証チェックを行い、プロンプトではなくセキュリティ境界として機能させます。

3. 継続的な評価：安全は「一度きりのゲート」ではない

安全性は、製品リリース前のテストで合格すれば終わりではありません。それは本番環境全体を走る継続的な評価レイヤーです。

多くのチームが評価（evals）をリリース前のチェックリストと捉えがちですが、実際には以下の 3 つのソースからリアルタイムにスコアリングを行う必要があります。

1. 自動化された判定器（Automated Judges）: クリニカルな正確性、安全性、エスカレーションの適切さ、ドリフト検知など、複数の次元で常に自動評価を行います。これにより、品質の低下や回帰を即座にキャッチします。
2. ユーザーフィードバック: ユーザーからの「いいね」「悪いね」は、モデルが捉えられないトーンの問題や文脈のズレを検知する唯一の真実信号です。
3. サンプリングによる監視: 高リスクケースについては 100% サンプリングし、ランダムに抽出された会話ログを人間が確認します。

「ボトルネックは計算能力でもモデルの性能でもなく、これらの信号を読み取り、行動を起こせる人間の数です。」

本番環境で新たな失敗が見つかれば、それは単なるバグではなく「新しい監視基準（judge）」が必要になったサインです。アーキテクチャは、このように新たな監視基準を常に追加し、スケーリングできる設計である必要があります。

4. 人間中心の意思決定：最悪ケースが勝つ

しかし、アーキテクチャや監視だけでは解決できないジレンマも存在します。リリース直前に残された課題に対し、臨床チーム（安全性）、法務・コンプライアンス（規制リスク）、プロダクト（採用リスク）、エンジニアリング（速度リスク）など、5 つのステークホルダーが異なる視点から対立する場合があるのです。

このような状況で意思決定を行う際、Rashi 氏は以下のルールを提案します。

• 最悪ケースが勝つ: 深刻度は「平均的な結果」ではなく、「最も可能性のある最悪の結果」によって設定されます。医療現場では、100% のユーザーに軽微な不快感を与えるバグよりも、0.1% のユーザーに重篤な危害をもたらすバグの方が遥かに重大です。
• 深刻度は容量ではない: バグの深刻度は、誰が担当しているか、チームに修正する余力があるか、修正の難易度によって決まるものではありません。それは「引き起こされる害」のみで決まります。

最終的な選択肢は、「修正してリリースする」「リリースを延期する」「リスクを許容し、明示的な承認を得てリリースする」の 3 つです。政治的な駆け引きではなく、患者の安全と最悪ケースへの備えが常に優先されます。

まとめ

ヘルスケア AI の信頼性を高めるには、プロンプトレベルの調整に頼るのではなく、PHI 保護をアーキテクチャで設計し、生命に関わる判断をコード層で決定し、本番環境での継続的な監視と人間による最悪ケースの意思決定を組み込む必要があります。これが、患者の命を守るための唯一の実践的な指針です。