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

厚生労働省の「医療情報システムの安全管理に関するガイドライン第6.0版」に関するQ&A(令和7年5月)は、企画Q-26で生成AIへの医療情報入力を取り上げています。入力情報が「AIの学習等のために保存されないこと」が契約等で担保されていれば、生成AIサービスのサーバーが国内法の適用を受けている必要はない、という回答です。

Claudeでこの「保存されない」に直接対応するのはZero Data Retention(ZDR)です。Business Associate Agreement(BAA)によるHIPAA readinessは別の仕組みで、同じ組織に両立しない組み合わせもあります。医療機関の情報システム担当者が、どの面でどちらを選ぶかを決めるための材料を並べます。

Q-26が認める範囲と、Q-26だけでは決まらないこと

ガイドライン企画管理編第7章の遵守事項⑤は、外部保存を委託する場合に、保存された情報を格納する情報機器等が国内法の適用を受けることを確認するよう求めています。Q-26はこの条文について「よい」と答え、医療情報が保存されないことが契約等で担保されているなら、国内法の適用を受けていないサーバーを利用できるとしました。

注意したいのは、Q-26が緩めたのは「国内法の適用」の確認だけだという点です。直後の企画Q-27は、外部保存を委託する事業者の選定で、国内法の適用があることに加えて、行政機関の調査への提出を阻害する国外法の適用がないことも確認するよう求めています。Q-27は外部保存の委託全般への回答で、生成AIを名指しした問いではありません。

「保存されない」と言えるかどうかは、契約の書き方で決まります。Anthropicの文書では、ZDRが有効でも法令上必要な場合は保持されることがあります。不正利用の自動検知でフラグが付いた場合は、入出力が最長2年保持されることがあるとされています。Q-26の条件を満たすかを判断する担当者は、この例外を契約書の文面と照らして読むことになります。

ZDRとHIPAA readinessは、定義が違う

二つの仕組みは、約束している内容そのものが違います。

ZDRの1P API組織は、次の節の表でBAAのEligible Serviceにも入っています。保存しない契約とBAAは択一ではなく、ZDR側に両方が付く構成があります。

ZDRの対象になる面とならない面

ZDRの対象は利用面で分かれます。API系はほぼ対象ですが、製品のインターフェースは対象外が多くなります。

Claude Code on Enterpriseの別枠ZDRには、運用で効く条件が二つあります。一つは、ZDRが効くのはZDR有効な組織にログインしたセッションだけという点です。個人アカウントや別組織のAPIキーでサインインした開発者のセッションは対象外です。組織ログインを強制するmanaged settingsとして、forceLoginMethod と forceLoginOrgUUID があります。もう一つは、ZDR有効時にサーバー側で止まる機能です。クラウドセッション、Claude Tag、Artifacts、/feedback /bug /share、Remote Controlが無効化され、使おうとするとエラーが返ります。

PHIを扱う組織について、platformのドキュメントはHIPAA readinessを選ぶ取り決めとし、ZDRも併せて持つ必要はないとしています。HIPAA-ready API accessは、ZDRの代わりとして設計されたものです。HIPAAの観点ではHIPAA readinessがZDRの代替になり、Q-26の「保存されない」を担保するのはZDRです。見ている観点が違います。

ZDRとHIPAA readinessの機能別の違いはClaude APIのZDRとHIPAAのデータ保持ポリシー比較にまとめています。

構成ごとに、BAAとCovered Modelsはこう分かれる

Covered Modelsは、提供される面すべてで30日間のデータ保持を条件にしています。対象は、2026年6月9日に指定されたClaude Fable 5とMythos 5、同年8月31日に指定されたClaude Fable 5.1とMythos 5.1です。Mythosは承認パートナーに限られます。Anthropicが個別に認めた場合を除き、ZDRが有効な組織・ワークスペースからは使えず、リクエストはエラーになります。例外として、適格な顧客には、社内の業務アプリケーション向けにFable 5と5.1をZDRで使える選択肢が期間限定で案内されています。Anthropicのサポート記事は、構成ごとにBAA対象かとCovered Modelsに届くかを次のように示しています。

BAA対象外の行(Claude CodeとClaude APIの標準保持、Cowork)は、医療情報を入れられない構成です。Claude Codeは、1P APIの組織でもZDR有効のときだけBAA対象です。Coworkは保持設定や使うモデルを問わずEligible Serviceではありません。BAAは、サードパーティのクラウド経由で買ったサービスにも及びません。Claude CodeをGoogle Vertex経由で使う構成が対象外なのは、この理由です。

一つの組織に両立しない組み合わせ

読み違えやすいのは、組織単位の制約です。1P APIの組織では、HIPAA readinessとZDRを同じ組織に同居させられません。HIPAA-readyな本番APIとClaude CodeのZDRの両方が要るときは、組織IDを分けます。

もう一つは、ZDR組織でCovered Modelsを使いたいときの回避策です。ワークスペースごとに30日保持を有効にする方法があり、他のワークスペースはZDRのまま残ります。ただし、30日保持にしたワークスペースは、Q-26が前提にする「保存されない」状態ではなくなります。また、標準のAPI組織はBAAのEligible Serviceではないので、そこにPHIを入れない運用が前提です。

この設定は、既定以外のワークスペースで操作します。既定ワークスペースの保持は組織レベルで管理されます。保持をオンにした変更は、オンにした後のリクエストにだけ適用されます。対象はAPIのリクエストとレスポンスで、Batch API・Files API・Claude Managed Agentsのセッションなど、動作に保存が要る機能は含みません。操作できるのはAdmin、Owner、Primary Ownerです。

入口の名称は、公式ページごとに違います。サポート記事の一つは「Workspace > Manage > Privacy Controls」と書いています。platformのドキュメントは、Claude Console > Settings > Workspacesでワークスペースを選び、Privacy controlsタブを開く手順です。別のサポート記事は、Organization settings > Workspacesからワークスペースを選び、左サイドバーのManage > Privacy controlsと書いています。行き着く先はどれも同じPrivacy controlsです。

実際に出るエラー文言

対象外の機能やモデルを指定すると、APIは黙って通さずエラーで返します。文面は面ごとに違います。

HIPAA有効な組織のAPIが、対象外の機能を含むリクエストを受けたとき(invalid_request_error、HTTP 400)です。

The requested features are not available for HIPAA-regulated organizations without Zero Data Retention: code_execution.

文中の「without Zero Data Retention」はAPI自身の言い回しで、解決策は変わらず、対象外の機能をリクエストから外して再送します。

ZDRの組織やワークスペースからCovered Models(Claude Fable 5)を呼んだときは、次のエラーです。

In order to access this model, your organization or workspace must have data retention enabled.

どちらも 400 invalid_request_error です。院内で試験導入するときは、エラーがどちらの制約から出たかを切り分けると、設定の見直し先が分かります。

Claude EnterpriseでBAAを有効にする手順と、戻れない点

標準のClaude Enterpriseは、BAAのカバレッジを含みません。有効にできるのはEnterpriseプランだけで、Team・Free・Pro・Maxはこの設定を持てません。手順は次のとおりです。

Primary Owner以外のOwnerやAdminは、この操作を代行できません。有効化は一方向で、BAAを受諾した後は組織設定から元に戻せません。有効化に伴って、一部の設定が既定値に戻ります。何が変わるかはオンボーディング画面とImplementation Guideに載るため、BAAと併せて、押す前に読みます。

APIの側は経路が違います。Claude Console > Settings > Data retentionのHIPAA complianceカードで、HIPAA管理の権限を持つ組織管理者が進められます。BAAとHIPAA Implementation Guideをダウンロードして受諾すると、即座に有効になり、こちらも管理者は無効化できません。交渉済みの個別BAAが要る場合や、セルフサーブが使えない組織は、営業チームとの契約になります。

Messages APIでBAAの対象になる機能は6つです。Prompt Caching・Structured Outputs・Memory・Web Search・Bash tool・Text Editor toolが該当します。ただし2026年4月1日より後に受諾したBAAが条件です。Structured Outputsでは、JSON schemaの定義にPHIを入れません。

既存契約の注意が一点あります。2025年12月2日より前に締結したClaude API向けのBAAは、API利用だけが対象で、HIPAA-ready Enterpriseプランには及びません。Enterpriseプランも使うなら、アカウントチームと新しいBAAを結びます。同日より後に締結したBAAは、APIとEnterpriseを一つの契約で扱えます。

Claude EnterpriseでBAAの対象になる機能は、Chat・Projects・Artifacts・Voice・Web Search・Research・Skillsです。ファイル作成とコード実行も対象ですが、ネットワークアクセスと外部サイトの利用は除きます。MCPやコネクタ、Enterprise Search、Claude in Chromeは使えても、第三者に送られるデータはBAAの外です。Claude Design・Slides・Docsは、HIPAA-ready組織でもOwnerが規約に同意すればオンにできますが、BAAの対象外なのでPHIは入れません。APIのHIPAA-ready組織では、Batch API・Files API・Skills APIが使えません。Code Execution・Computer Use・Web Fetchも同じです。

医療機関が選ぶときの切り分け

Q-26の条件を軸にすると、判断は「何をしたいか」で分かれます。

Q-27が示すとおり、事業者選定では、総務省・経済産業省の「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」の要求事項を満たしているかを確認します。サービス仕様適合開示書などの提供を求めることも、有効な手段として挙がっています。Claudeでこれに近い役割を持つのは、Anthropic Trust Centerで配布されるImplementation Guide for HIPAA Entitiesです。機能ごとのBAA対象かどうかの一覧があり、アクセスの申請が要ります(既存の顧客アカウントと一致するドメインからの申請は自動で承認されます)。

認証があれば足りるわけでもありません。Q-28はISMS認証について、事業者として最低限の適格性を示す手段にとどまるとし、管理しているリスクに応じて適合性を示す資料を求めるよう答えています。Q-29はISMAPやCSゴールドマークのサービスリスト掲載だけでは足りず、審査対象を定めた「言明書」の確認を求めています。さらにQ-30は、データ修復などの緊急時を除き、原則として委託元の医療機関だけがデータ内容を閲覧できることの担保を求め、Q-31は暗号化などで管理者でも通常はアクセスできない制御を求めています。外部保存を伴う使い方を選ぶ場合、これらも契約の確認項目になります。

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

まとめ

先に決めるのは、使う面(Chat / API / Claude Code)と、使いたいモデルが保持を求めるかどうかです。有効化ボタンを押すのはその後です。