医療機関で生成AIを使うときの注意点｜法的整理・サービス選定・セキュリティの実践ガイド

医療機関における生成AIの利用は、一般企業のそれとは決定的に異なる難しさがあります。診療情報という要配慮個人情報を扱うため個人情報保護の論点が、誤出力が患者安全に直結するため医療安全の論点が、そして使い方によっては**薬事（医療機器規制）**の論点が、同時に立ち上がるからです。実務では、この三層のリスクを法令・ガイドライン・技術の三点で接続して設計する必要があります。

本記事では、①法律上の整理（条番号・公式ガイドライン付き）、②サービス選定の勘所（契約論点を含む）、③セキュリティ設計の考え方、の順で、医療機関の実務・法務・情報システム担当者向けに専門的に整理します。

免責：本記事は一般的な情報提供であり、法的助言ではありません。条番号やガイドラインの版数は改正により変わり得ます。実際の導入判断にあたっては、必ず最新の一次情報（法令・公式ガイドライン）と、顧問弁護士・情報セキュリティ責任者等の確認を得てください。

前提となる三層のリスク構造

生成AIを医療で使うとき、次の3つのリスクは同時に検討する必要があります。

1. 個人情報保護のリスク — 診療情報は個人情報保護法上の「要配慮個人情報」（同法2条3項）に該当し、取得・提供・二次利用のいずれにも一段厳しい規律がかかります。
2. 医療安全のリスク — 生成AIは事実と異なる内容をもっともらしく生成する（ハルシネーション）ため、検証を経ない出力は患者安全に直結します。最終的な診断・治療の責任は医師にあります（医師法20条：無診察治療等の禁止）。
3. 薬事のリスク — 診断・治療の意思決定に用いるプログラムは、薬機法上の医療機器（同法2条4項）に該当し、承認・認証が必要となる場合があります。

「便利だから使う」ではなく、「三層のどこに触れるユースケースなのか」を切り分けてから設計するのが専門的なアプローチです。

1. 法律上の整理

1-1. 個人情報保護法：委託か、第三者提供か

医療機関の生成AI利用で最も重要な論点は、入力した患者データが「委託」の範囲にとどまるのか、「第三者提供」に当たるのかの切り分けです。

• 委託（同法25条・27条5項1号）：生成AI提供者が、医療機関の利用目的の達成に必要な範囲でデータを処理するだけであれば、それは「委託」であり、提供自体に本人同意は不要です。ただし医療機関には委託先の監督義務（25条）が生じます。
• 第三者提供（同法27条）：提供者がそのデータを自らの目的（典型的にはモデルの学習・品質改善）に利用する場合、もはや委託の枠を超え、要配慮個人情報の第三者提供として原則本人の事前同意が必要になります。要配慮個人情報はオプトアウトによる第三者提供が認められていません（20条2項の趣旨）。

個人情報保護委員会は2023年6月、この点について「生成AIサービスの利用に関する注意喚起等」を公表し、本人同意なく個人データを含むプロンプトを入力し、それが応答生成以外の目的（学習等）で取り扱われれば個人情報保護法違反となり得ると明示しています。したがって、契約上「入力データを学習に使用しない」ことを担保できるかが分水嶺になります。

1-2. 越境移転：クラウドの保管・処理が国外にある場合

生成AIの多くはクラウドで提供され、保管・処理が国外リージョンで行われることがあります。この場合、外国にある第三者への提供（同法28条）の規律がかかります。適法化の根拠は概ね次の3つです。

• 本人の同意（外国第三者提供を前提とした同意）
• 提供先が基準適合体制（我が国の個人情報保護法に相当する体制）を整備し、必要な措置を講じていること
• （国・地域が指定されている場合の例外 等）

「国内リージョンで完結するか」「国外なら28条の根拠は何か」を、導入時に必ず整理します。

1-3. 3省2ガイドライン：安全管理の実務基準

医療情報システムの安全管理の実務基準が、いわゆる3省2ガイドラインです。

• 医療機関側：厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」（2023年5月）。第6.0版は経営管理編・企画管理編・システム運用編に再構成され、リスクベースアプローチのもと、電子保存の三基準である真正性・見読性・保存性の確保を求めています。
• 事業者側：経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」。

生成AIサービスも、この枠組みの中で医療機関・事業者双方の責務に照らして評価します。責任分界点（どこまでが事業者の責務で、どこからが医療機関の運用責任か）の文書化が要点です。

1-4. 薬機法：プログラム医療機器（SaMD）該当性

薬機法2条4項の医療機器の定義に照らし、診断・治療の意思決定に直接用いるプログラムはプログラム医療機器（SaMD）に該当し得ます。該当性は、厚生労働省「プログラムの医療機器該当性に関するガイドライン」（令和3年策定・令和5年一部改正）で、①医療機器としての目的性、②意図どおり機能しない場合に生命・健康に影響を及ぼすおそれ（クラスⅠ相当を除く）の2要件を軸に判断されます。

記録・要約・事務作業の効率化にとどまる用途は原則非該当ですが、診療判断に踏み込む使い方は該当性の検討が必要です。「支援」と「判断への関与」の線引きを、ユースケースごとに明確にします。

1-5. 次世代医療基盤法：データの二次利用

収集した診療データを研究・AI開発等に二次利用する場合は、次世代医療基盤法の枠組み（匿名加工医療情報・仮名加工医療情報、認定事業者、本人への通知・オプトアウト等）を確認します。「診療で使う」ことと「データを二次利用する」ことは、適用法令が異なる別論点として整理します。

2. サービス選定の勘所

生成AIサービス、または生成AIを組み込んだ医療系プロダクトの選定は、機能の派手さではなく「安全に使い続けられるガバナンスがあるか」を軸に評価します。

契約面では、責任共有モデル（IaaS/PaaS/SaaSで責務範囲が異なる）を明確にし、データ処理契約（DPA）に学習不使用・保持期間・削除・監査権・インシデント通知を落とし込むことが実務の要諦です。

3. セキュリティ設計の考え方

ツール選定と並行し、院内の運用（設計）でリスクを構造的に下げます。

適用範囲を脅威モデルから線引きする

「事務文書の下書き・情報整理には積極活用し、確定診断・個票の外部入力といった高リスク領域は対象外」といったように、ユースケースごとに脅威と影響を評価して適用範囲を明文化します。

非識別化と「匿名加工」の法的差を理解する

プロンプト投入前に氏名・IDなどの識別子を除去する（非識別化・マスキング）ことは有効ですが、これは運用上の低減策であって、法的な「匿名加工情報」とは要件・効果が異なります。運用上のマスキングと、法的な匿名加工／仮名加工を混同しないことが専門的な注意点です。

プロンプトインジェクションと権限境界

RAGやエージェント構成では、外部文書やツール経由の間接的プロンプトインジェクションにより、AIが意図しないデータ参照や操作を行うリスクがあります。AIが参照・実行できる範囲を明示的に制限し（最小権限）、マルチテナントで医療機関ごと・利用者ごとにデータを分離します。AIを「万能の管理者」にしないことが要点です。

監査ログの完全性と暗号化・鍵管理

「誰が・いつ・どの情報を・どのモデルに入力し・どう使ったか」を改ざん防止された形で記録します。保存時・転送時の暗号化と鍵管理を分離し、アクセスは認証・認可で厳格に制御します。

継続的再評価

生成AIはモデルや仕様が更新されます。ガイドライン改定・仕様変更のたびに、安全性・該当性・データ取り扱いを再評価するサイクル（範囲を絞る→記録する→検証する→見直す）として運用します。

まとめ：ガバナンスを先に、導入は段階的に

医療機関の生成AI活用は、技術の導入以前にガバナンス（誰が・何を・どこまで・どう記録し・誰が責任を負うか）を先に設計し、安全に使える範囲から段階的に広げるのが現実的かつ専門的なアプローチです。

1. 三層のリスク（個人情報・医療安全・薬事）でユースケースを分類する
2. 委託／第三者の別、越境移転、学習利用の可否を契約で確定する
3. 3省2ガイドライン準拠・第三者認証・データレジデンシでサービスを選ぶ
4. 権限境界・監査ログ・暗号化・インシデント対応を設計する
5. 医療者による最終確認と、変更時の再評価をワークフローに組み込む

ポテックは、AIネイティブな医療情報システムの開発と、ISMS認証取得・3省2ガイドライン対応の支援を提供しています。「生成AIを、制度対応とセキュリティ設計まで含めて安全に組み込みたい」というご相談があれば、お気軽にお問い合わせください。

参考

• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について（令和5年6月2日）」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」／「（外国にある第三者への提供編）」
• 厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版（概説編）」
• 厚生労働省「医療機器プログラムについて」／「プログラムの医療機器該当性に関するガイドライン」

※本記事は一般的な情報提供であり、法的助言ではありません。条番号・版数は改正され得るため、導入判断の際は最新の一次情報と専門家の確認を得てください。