「学習オフにすればOK」は通用しない

医療現場での生成AI活用を巡る議論が、2025年5月を境に大きく変わった。厚生労働省が「医療情報システムの安全管理に関するガイドライン Q&A」に企Q-26を追加し、「生成AIサービスのプロンプトとして医療情報を入力する場合」の条件を初めて公式に示したのだ。

この告示以前、医療現場でChatGPTなどを業務利用するかどうかは各医療機関の判断に委ねられていた。2023年頃から「議事録の作成に使っている」「電子カルテの要約に試している」という声が散発的に上がり始め、グレーゾーンのまま実態が先行していた。企Q-26はその曖昧さを終わらせた——少なくとも法解釈の出発点として。

結論から言えば、「学習オフ設定」だけでは医療情報を入力することはできない。これがどういうことかを順番に整理する。

医療情報は「要配慮個人情報」という大前提

まずここを押さえないと、以後の話が意味をなさない。医療情報は個人情報保護法上の**「要配慮個人情報」**に分類される。「不当な差別、偏見その他の不利益が生じないようにその取扱いに特に配慮を要するもの」という定義が法律に明記されており、通常の個人情報より取り扱いのハードルが高い。取得には原則として本人同意が必要であり、オプトアウトによる第三者提供は不可、漏えい時の影響範囲も広い。

その上に、個人情報保護法だけでなく、医療法施行規則、医師法・医療法、薬機法、厚労省の「医療情報システムの安全管理に関するガイドライン 第6.0版」、経産省・総務省のガイドラインと、複数の法令が重なって適用される。

技術者が最初に引っかかりやすいのが仮名化と匿名化の混同だ。「患者名をIDに変換したから個人情報じゃない」という理解は法的には誤りで、対応表が存在する限り「再特定できる」とみなされ、個人情報保護法の規律がそのまま適用される（仮名化）。完全に特定不可能なレベルまで加工して初めて「匿名化」になり、個人情報ではなくなる。「PT_A001に置き換えた」は仮名化に過ぎない。対応表の管理を別システム・別権限で行わないと、仮名化の意味をなさない点も実装上の重要な注意点だ。

生成AI利用の3択：何がOKで何がNGか

企Q-26が整理したのは、医療情報を生成AIに入力する際の選択肢だ。要約すると以下の3択になる。

設定 法的にOK? 理由
「学習オフ」設定だけ ❌ NG ログが30日〜5年残る
ZDR契約 ✅ OK 入力データをその場で廃棄
院内ローカルLLM ✅ OK データが院外に出ない

なぜ「学習オフ」だけではNGなのか。エンジニアには直感的にわかる話だが、整理しておく。「学習オフ（opt-out）」はモデルのファインチューニングに使わないという設定であって、ログを保存しないこととは別物だ。多くのSaaSでは、学習オフにしても30日から5年のログが残る。APIリクエスト・レスポンスの監査用ログ、不正検知用ログ、課金集計用ログなどは、不正利用対策や法令対応のために保持される。医療情報がそこに残っている時点で、要配慮個人情報の不適切な外部委託になる。

ZDRとは何か、どう確認するか

ZDR（Zero Data Retention）は「入力データを保存しない」という契約上の約束だ。リクエストはメモリ上で処理され、レスポンスを返したら破棄される。ログにも残らない（または極めて短時間で消去される）という仕組みで、ベンダー側のデータ復元義務もない。

主なプロバイダーの対応状況として、元記事が挙げているのはOpenAI APIのEnterpriseや一部APIプラン、Anthropicのエンタープライズやベッドロック経由（AWS Bedrock経由ならHIPAA BAA締結可能）、Google Cloud Vertex AIなどだ。

ここで実務担当者が注意すべき点がある。「Webサイトに書いてある」だけでは不十分で、企Q-26は「契約による担保」を求めている。契約書やデータ処理同意書（DPA）にZDRが明記されているかを確認することが必要だ。「サービスの利用規約に似たような記述がある」「サポートの担当者がそう言っていた」は担保にならない。

ここはかなり重要な運用上のポイントで、IT部門や法務と医療情報管理の担当者が連携して確認する必要がある。ZDRを謳っているように見えても、契約書の文面で「ログは一定期間保持する」などの例外が書かれていることがある。

ローカルLLMという選択肢の現実

データを院外に出さないという意味では最も保守的な選択が、院内にLLMを立てることだ。「ローカルLLMなんて大病院にしかできない」という印象を持つ人もいるが、元記事が指摘するとおり、中規模のオープンウェイトモデルが実用レベルに達しており、20〜200床規模の病院でも現実的に運用できるフェーズに入っている。

Ollamaを使えばLinuxサーバー上で比較的簡単に起動できる。ハードウェア要件の目安は、7B〜9Bモデルで8〜16GBのVRAM（文書要約・簡単な質問応答に対応）、14B〜32Bモデルで24〜48GB（医学文献の処理・複雑な要約）、70B以上では80GB超（高度な推論・専門領域）という整理だ。

ただし「立てれば終わり」ではない。院内運用で必ず考慮すべき事項がある。モデルのライセンス確認（Gemma、Llama、Qwen等は商用利用可否の確認が必要）、ハルシネーション対策（医療情報では事実誤認が直接リスクになるため、RAGや出典明示が前提）、院内LAN内でも認証を設けるゼロトラスト原則の適用、誰がいつ何を入力したかの責任追跡性のためのログ管理——これらを抜かすと、データ漏洩とは別のリスクが生まれる。

SaMDと薬機法——「社内ツール」が規制対象になる瞬間

「自前で診断AIを作りたい」「医療画像から異常を検出するモデルを院内で動かしたい」という話は、薬機法の規制対象になる可能性がある。SaMD（Software as a Medical Device）、いわゆるプログラム医療機器の話だ。

医療機器はリスクに応じてクラスI〜IVの4段階に分類される。SaMDも同じ基準で評価される。実務的に覚えておくべき分類をいくつか挙げると、CT画像から肺がんを検出する診断補助AIはクラスIII、治療判断・自動投与の判断を伴うAIはクラスIV相当となり、前者は第三者認証または承認、後者はPMDAによる承認が必要になる。

技術者が特に注意すべきポイントが2つある。

1つ目は**「意図する用途（intended use）の定義が全て」**という点。「診断補助」と「診断」では規制が全く変わる。学術研究目的であれば薬機法の対象外になるが、個人情報と倫理審査の論点は別途残る。

2つ目は**「院内ツールから他病院への展開」がもたらす変化**だ。「うちの病院内で使う社内ツールだから関係ない」と思っていても、他病院に展開した瞬間に「製造販売」とみなされる可能性がある。これはプロダクト担当者や医療スタートアップが本当に踏み抜きやすい落とし穴で、規制対応に数年・数千万円から億単位のコストが発生するという現実がある。

実務担当者が持つべき判断軸

ここからは少し引いた視点で見ると、今起きていることの構造がわかる。

医療×AIの現場は今、「技術的に可能かどうか」と「法的に許容されるかどうか」のギャップを埋める作業の途中にいる。企Q-26の登場でルールの輪郭が見えてきたが、まだZDRを担保できるベンダーの選定方法の整備、院内ローカルLLMの標準的な導入ガイド、SaMDのアジャイル開発との整合性（モデルを更新するたびに承認が必要になるのかという問題）など、実務的に解決されていない論点が残っている。

実務担当者として次のニュースや文書を読むとき、見ておくべき軸は3つだ。

① 「学習オフ」と「ZDR」を混同していないか——生成AI活用の文脈で「セキュリティ対策済み」と言われたとき、それが何を根拠にしているかを確認する習慣。

② ローカルLLMの文脈でライセンス・ハルシネーション・ログ管理が語られているか——「オープンソースだから安心」は起点でしかない。運用設計が伴っているかを見る。

③ AIの「用途定義」が医療機器該当性を決める——医療AIの開発・導入を検討する際、「何のために使うか」を曖昧にしたまま進めると、あとから規制の網がかかる。意図する用途を最初に明文化する習慣が、最終的にコストを下げる。

法的なフレームワークが整備されてきたことは前進だ。ただし「ガイドラインが出た＝現場でそのまま動く」ではない。運用の実態が追いつくまでには、地道な契約確認・システム設計・スタッフへの周知が必要で、そこに近道はない。

参考元: 医療現場で生成AIを使うときに知っておくべき法律と技術 〜企Q-26・ZDR・ローカルLLM・SaMDを技術者目線で整理〜