医療AI導入前に潰す五つの盲点　監査ログから人の最終判断まで

医療AIの合規性は、モデルの精度ではなく、患者情報が入ってから出力を人が確定するまでの運用全体で決まる。監査ログを残す、氏名を伏せる、回答に出典を付けるといった個別機能がそろっていても、互いの境界に穴があれば安全管理は成立しない。2026年6月に厚生労働省が医療情報システムの安全管理に関するガイドラインを第7.0版へ改めた現在、日本の医療機関が導入前に確かめるべき論点を五つに分けた。

監査ログ──残すほど漏えい面も広がる

最初の盲点は、証跡を多く残せば安全になるという思い込みだ。操作履歴は不正利用や障害の追跡に欠かせない一方、患者名、問診文、生成AIへの入力、回答全文まで無条件で複製すれば、ログ基盤が新たな医療情報の保管場所になる。

厚生労働省の第7.0版システム運用編は、アクセスログに少なくとも利用者のログイン時刻、アクセス時間、操作した医療情報を特定する記録を求める一方、ログ自体に個人情報が含まれる可能性があるため、アクセス制限と削除・改ざん・追加の防止が必須だとしている。ここから導くべき設計は、全文保存を既定にすることではない。誰が、いつ、どの情報に、どの処理をしたかを追跡できる最小限の項目を先に定め、入力・出力の本文が必要な場面は保存期間と閲覧権限を別に設定することだ。

同ガイドラインの企画管理編は、証跡を目的と特性に応じて選び、過大な収集で運用を圧迫しないようリスク評価を踏まえることを求めている。件数を増やすことと、監査の実効性を高めることは同じではない。取得項目、保管先、保存期間、閲覧者、定期レビューの周期まで決まって初めて、ログは統制として働く。

加工情報──氏名を消しても管理は終わらない

二つ目は、「匿名化」という一語で異なる状態をまとめることだ。日本の個人情報保護法には仮名加工情報と匿名加工情報があり、要件も利用範囲も同じではない。個人情報保護委員会のガイドラインは、仮名加工情報について、加工後の情報だけでは個人を識別できなくても、別の情報との照合で識別できる状態を否定しないと明記する。匿名加工情報も、元のデータの性質に応じて追加の加工が必要になり、希少な属性や蓄積された行動履歴が復元の手掛かりになりうる。

生成AIを組み込む場合、保護対象は入力文だけではない。検索拡張生成（Retrieval-Augmented Generation、RAG）に使う文書、検索用の索引、入力履歴、評価用データにも患者を推測できる情報が残りうる。院内とクラウドを分ける構成は有力な選択肢だが、院内に索引を置いただけで適法性や安全性が確定するわけではない。データの一覧を作り、各保存先へのアクセス権、削除手順、委託先への送信範囲をそれぞれ決める必要がある。

出典と版──RAGを付けても誤生成は消えない

三つ目は、RAGを導入すれば回答が正しくなるという前提だ。検索結果が質問と無関係なら、モデルは誤った資料を根拠らしくまとめる。資料が更新されても古い索引が残れば、回答の文章は自然でも参照した規範は失効している可能性がある。

米国立標準技術研究所（NIST）の生成AIリスク管理プロファイルは、導入前と運用中に出力の出典・引用を検証し、RAGに使うデータが根拠に結びついているかを確認するよう提案している。同文書は生成AIが誤った内容や架空の引用を確信的に示す危険も挙げる。したがって、画面にリンクを表示するだけでは足りない。回答中の各主張が参照文書の該当箇所に対応しているか、文書の版と取得日時が残るか、参照できない場合に回答を止めるかを試験項目に入れる必要がある。

規範、検索索引、モデル、プロンプト、出力判定ルールの版を一組で記録すれば、後日の再検証が可能になる。どの版の文書をどの索引が参照し、どのモデルと判定ルールが回答を作ったかを一件ごとにたどれる形が要る。

最終判断──AIの判定欄と責任者を分ける

四つ目は、AIの出力を組織の決定と同一視することだ。「通過」「要確認」「不適合」という状態表示は審査を助けるが、診療記録や患者向け情報の確定者にはなれない。どの条件で自動処理を止め、誰に回し、誰が最終承認するかを業務規程に落とす必要がある。

NISTのAIリスク管理枠組みは、人とAIの役割・責任を区別する方針を置き、人による監督の手順を定義、評価、文書化するよう示している。日本の医療情報管理でも責任者を消す方向には進んでいない。厚生労働省の第7.0版は、電子カルテの記録に入力者と確定者の識別情報を含め、確定操作を権限のある利用者に限り、代行入力後も内容を確認して確定するよう求める。

この原則を医療AIに当てはめると、AIは根拠と状態を提示し、人が業務上の決定を確定する形になる。人を画面上の承認ボタンに置くだけでは監督にならない。確認に必要な原文、参照箇所、警告、モデルの限界を同じ画面で読めること、差し戻しと訂正が記録されることが要る。

認証情報と委託先──境界ごとに責任を置く

五つ目は、患者データの保護に集中し、APIキーや管理者アカウントを二次的に扱うことだ。入力文を伏せても、ログやエラー通知に認証情報が出れば、攻撃者は同じ接続権限を得る。鍵をソースコードや通常ログに置かず、権限を用途別に絞り、漏えいの疑いが出た時点で失効・再発行する手順を用意する必要がある。

厚生労働省のシステム運用編は、IDとパスワードを本人しか知り得ない状態に保ち、推測しにくい設定と使い回しの禁止を求めるほか、委託事業者との間でログの管理方法と提供方法を明確に取り決めるよう示している。クラウド事業者、モデル提供者、検索基盤の運用者が分かれる構成では、障害時の連絡先、ログを渡す主体、データ削除の実施者を契約と運用表の双方に置く必要がある。

稼働判定は機能一覧ではなく一連の試験で

五つの論点は個別のチェック欄では終わらない。監査のために増やしたログが個人情報を複製し、誤生成を抑えるために追加した検索索引が新しい情報資産になり、人の確認を加えた結果として責任の境界が曖昧になる。対策を足すたびに、別の境界が動くためだ。

本番移行の判定では、患者情報を含む試験データを使わずに、入力から削除までの流れを通す必要がある。確認項目は、ログに残る値、加工後に推測可能な属性、出典と版の対応、AIが回答を止める条件、人の差し戻し、認証鍵の失効、委託先から返る証跡である。設計書の記載と実際の挙動が一致しなければ移行を止める。医療AIの安全管理は、機能の有無より、その機能が連結したときの挙動で評価すべきものだ。

よくある質問

監査のために生成AIへの入力と回答をすべて保存すべきか
一律の全文保存は避けるべきだ。厚生労働省の第7.0版は、必要な証跡を目的と特性、リスク評価に応じて選ぶ考え方を示す。追跡に必要な識別子や時刻、処理状態を定め、本文を保存する場合は目的、期間、閲覧権限を分ける必要がある。

氏名を削除すればクラウドの生成AIへ送ってよいのか
氏名の削除だけでは判断できない。病歴、希少な属性、日付、所属先などの組み合わせから個人を推測できる場合がある。仮名加工情報と匿名加工情報のどちらに当たるか、委託か第三者提供か、利用目的と安全管理措置を個別に確認する必要がある。

RAGで出典を表示すれば人の確認は省けるのか
省けない。検索が誤った文書を選ぶ場合や、表示した出典が回答を支えていない場合がある。主張と参照箇所の対応を試験し、医療上または組織上の決定は権限を持つ人が確定する運用が要る。