Claude Media
医療情報システム安全管理ガイドラインで生成AI入力はどう扱われるか

医療情報システム安全管理ガイドラインで生成AI入力はどう扱われるか

厚生労働省の企画Q&A26は、AIの学習に使われないことが契約で担保されればサーバーの所在国は問わないと回答しています。ClaudeのZDR・BAAで何が担保されるかを整理しました。

厚生労働省が公表している「医療情報システムの安全管理に関するガイドライン第6.0版」に関するQ&Aの企画Q-26は、生成AIサービスへの医療情報入力について明確な回答を示しています。プロンプトに入力した情報がAIの学習等のために保存されないことが契約等で担保されているなら、サーバーが国内法の適用を受けている必要はない、というものです。医療機関の情報システム担当者にとっては、クラウド事業者選定の可否判断に直結する回答です。ClaudeでこのQ-26が問う「担保」に相当するのは、Zero Data Retention(ZDR)とBusiness Associate Agreement(BAA)の組み合わせです。

Q-26は何を、なぜ問うているか

ガイドライン企画管理編第7章「安全管理のための人的管理」の遵守事項⑤は、外部保存を委託する場合、保存された情報を格納する情報機器等が国内法の適用を受けることを確認するよう求めています。この遵守事項をそのまま読むと、海外にサーバーを置く生成AIサービスは使えないように見えます。Q-26はこの疑問に対する公式回答で、「医療情報が保存されないことが契約等で担保されている場合は、国内法の適用を受けていないサーバーを利用可能」と明記しました。

この論点が生まれた背景には、生成AIサービスの多くが海外の事業者によって提供されており、データセンターの所在国が国内とは限らないという事情があります。厚生労働省は「保存されない」という状態そのものを国内法適用の代替担保として認めた形です。つまり、サーバーの所在地を問題にするのではなく、医療情報がそこに残らないことを問題にする考え方への転換です。

Claudeで「保存されない」を担保する2つの経路

Q-26が求める「AIの学習等のために保存されない」という契約上の担保に対応するAnthropicの仕組みは、ZDRとHIPAA readiness(BAAの適用)の2つです。両者は目的が異なるため、どちらか一方を選ぶ設計になっています。

ZDRは、APIレスポンスを返した時点でプロンプトと生成結果を一切保存しない契約です。組織単位で有効化し、Anthropicの営業チームへの申請を経て設定されます。プロンプトが学習にも監視にも使われないという意味で、Q-26が想定する「保存されないことの契約上の担保」に最も直接的に対応します。ただし対象範囲には注意が必要で、利用面によって対象・対象外が分かれます。

利用面ZDR対象備考
Messages API・Token Counting APIZDR対象対象(一部機能)備考機能単位のeligibility tableで判定
Claude Code(Commercial組織のAPIキー)ZDR対象対象備考Claude Enterprise+ZDRの構成も対象
Claude Platform on AWSZDR対象対象備考
Claude Console・Claude Managed AgentsZDR対象対象外備考
コンシューマープランZDR対象対象外備考
Claude Team/Enterpriseの製品インターフェースZDR対象対象外備考Claude Codeを除く

ZDRとHIPAA readinessの対象機能・保持期間の違いはClaude APIのZDRとHIPAAのデータ保持ポリシー比較で詳しく整理しています。

もう一方のHIPAA readinessは、PHI(保護対象の保健情報)を扱う組織がBAAを締結した上で、Claude APIの一部機能を使えるようにする仕組みです。ZDRとの決定的な違いは、即時削除を必須にしていない点にあります。暗号化・アクセス制御・監査ログといった安全策を敷いた上で、データの保持自体(標準は30日)は許容されます。Q-26が問うのは「保存されないこと」なので、HIPAA readiness単体はこの回答が想定する担保の形とは性質が異なります。医療機関がQ-26の論点に沿ってサーバー所在地の確認を省きたいなら、ZDRを有効化する経路を選ぶ必要があります。

Claude Enterprise・Claude CodeでのBAA適用範囲

Claude Enterpriseの標準プランはBAAカバレッジを含みません。組織のPrimary Ownerが組織設定の「Data and privacy」でHIPAA compliance(HIPAA readiness)を有効化し、AnthropicのBAAに同意する操作が必要です。有効化すると、Chat・Projects・Artifacts・ファイル作成とコード実行(ネットワークアクセスと外部サイト利用を除く)・Voice・Web Search・Research・Skillsが「BAA対象のEligible Services」に入ります。一方でMCP/Connectorsは利用できても、そこを通じて第三者にデータが送られる部分はBAAの対象外です。管理者はこの機能を有効化する場合、利用実態がBAAの適用範囲に収まっているかを組織側で管理する責任を負います。

Claude Codeの扱いは特に注意が必要です。HIPAA readinessを有効化しただけではClaude CodeはBAAの対象になりません。Claude CodeがBAA対象になるのは、ZDRが有効な状態でかつ対象アカウントである場合に限られます。ZDRを有効にしないままEnterpriseシートにClaude Codeがバンドルされていても、利用自体はできてもBAAの対象外という状態が生じます。Cowork(業務エージェント機能)は、Anthropicの案内ではまだBAA対象に含まれていません。これらの適用状況の詳細は、Anthropic Trust Centerで配布されているHIPAA対応組織向けImplementation Guideが正式な一次情報源とされており、Anthropicは同ガイドをBAA対象機能の判断基準として案内しています。

Covered Modelsとの排他関係も確認する

Claude Fable 5のようなCovered Modelsは、安全性の取り組みの一環として、提供されるすべての面で30日間のデータ保持を必須としています。そのためZDRが有効な組織・ワークスペースからはCovered Modelsにアクセスできません。医療機関がQ-26の論点に沿ってZDRで「保存されない」ことを担保しつつ、同時に最新のCovered Modelsを使いたい場合、この2つの要件は両立しないことを理解しておく必要があります。BAA対象かつCovered Modelsにアクセスできる組み合わせは、HIPAA readyなChatや1P APIのHIPAA-ready API経由に限られ、Claude CodeやCoworkでBAA対象かつCovered Models利用という組み合わせは現状存在しません。

HIPAA readinessの有効化は後戻りできない

医療機関がQ-26の担保を確保する手段としてHIPAA readinessを検討する場合、有効化の性質を理解しておく必要があります。Anthropicの案内によれば、HIPAA readinessを有効化できるのはEnterprise組織のPrimary Ownerのみで、他のOwnerやAdminはこのフローを完了できません。手続き自体はセルフサーブで、組織設定の「Data and privacy」からBAAをクリックで受諾する形で完結し、別途契約書を取り交わす必要はありません。

重要なのは、この有効化が一方向の決定である点です。一度HIPAAを有効化してBAAを受諾すると、組織設定から元に戻すことはできません。また有効化に伴い、組織内の一部設定が既定値にリセットされる場合があるとされており、何が変わるかはオンボーディング画面とImplementation Guideに詳細が示されます。Anthropicは、この不可逆な組織変更を行う前に、BAAとImplementation Guideの両方を確認するよう明記しています。Q-27・Q-29が求める「事業者選定時の資料確認」を、有効化ボタンを押す前に完了させておく必要がある、という実務上の制約です。

2025年12月2日より前にClaude API向けのBAAを締結していた組織については、その契約はAPI利用のみをカバーし、HIPAA-ready Enterpriseプランには適用されません。Enterpriseプランでの利用を追加する場合は、アカウントチームと新たにBAAを締結し直す必要があります。既存のAPI向け契約があるからといって、Enterpriseプランの利用がそのままカバーされるわけではない点は、契約見直しのタイミングで見落としやすいポイントです。

医療機関の選定判断にどう落とし込むか

Q-26は「担保されていればサーバー所在地を問わない」という条件付きの許容であり、担保されていることの確認責任は医療機関側にあります。企画Q-27・Q-28が示すように、外部保存を委託する事業者の選定では、総務省・経済産業省の安全管理ガイドラインが求める要求事項を満たしているかや、サービス仕様適合開示書に相当する資料の提供を求めることが基本動作です。ClaudeでこれにあたるのはAnthropic Trust CenterのImplementation Guideであり、機能ごとのBAA対象可否が一覧化されています。ISMS認証取得の有無だけで判断せず、審査対象を定めた言明書の中身を確認すべきとする企画Q-29の考え方は、Anthropicの資料確認にもそのまま当てはまります。

実務上のチェック順序は次の3点です。

  1. ZDRを有効化するか、HIPAA readinessでBAAを締結するかを利用目的に応じて選ぶ
  2. Claude Codeを使うなら、BAA対象にするためにZDRの併用が必須であることを確認する
  3. 使いたいモデルがCovered Modelsに該当する場合はZDRと両立しないため、利用面をChat/APIのHIPAA-ready経路に絞る

医療機関向けのClaude活用全般(事前承認審査やカルテ作成の実務)はヘルスケア業界のClaude活用ガイド、導入事例の横断比較はClaude医療導入事例で扱っています。

まとめ

企画Q-26は「学習等のために保存されないことの契約上の担保」があれば、生成AIサービスのサーバーの国内法適用は問わないと回答しています。Claudeでこの担保に対応するのはZDRで、HIPAA readiness(BAA)は保持自体を許容する別の仕組みです。Claude CodeをBAA対象にするにはZDRの併用が必須で、Covered ModelsはZDRと両立しません。医療情報システムの外部保存先としてClaudeを選定する情シス担当者は、Q-26の条件を満たす経路がZDR側にあることを踏まえて、利用したい機能とモデルの組み合わせを先に決めてから設定を選ぶ順序が実務的です。

この記事を共有:XはてブLinkedIn