Claude APIのZDRとHIPAAのデータ保持ポリシー比較

Claude APIのデータ保持ポリシーには、Zero Data Retention(ZDR)とHIPAA readinessという2つの取り決めがあります。どちらもPHI(保護対象の保健情報)を扱う組織向けの仕組みですが、目指す方向がまったく逆です。ZDRはAPIレスポンスを返した後にプロンプトと生成結果を一切保存しない設定であるのに対し、HIPAA readinessは暗号化・アクセス制御・監査ログという安全策を敷いた上でデータの保持自体は許容します。PHIを扱う予定があるなら、両方を有効にする必要はなく、どちらか一方を選ぶ設計です。

Zero Data Retentionが前提にしていること

ZDRは、APIレスポンスが返った時点でプロンプトと応答をAnthropicが保存しないという契約です。組織単位で有効化し、Anthropicの営業チームへの申請を経て個別に設定されます。ZDRが対象とするのはMessages APIとToken Counting APIの一部機能、Commercial組織のAPIキーで使うClaude Code、Claude Platform on AWSです。Claude Console・Claude Managed Agents・コンシューマープラン(Free/Pro/Max)・Claude TeamとEnterpriseの製品インターフェース(Claude Codeを除く)は対象外です。

ZDRの設計は「保存されるデータそのものを無くす」ことに寄っています。そのため、ファイル保存が前提のBatch APIやFiles API、コンテナ状態を保持するコード実行系のツールは、機能の性質上ZDRの対象になりません。これらを使うことは、そのリクエストに関してZDRの枠外に出る選択そのものだと捉える必要があります。具体的には、Files APIにアップロードしたファイル本体、Code executionのコンテナ内で生成した中間ファイル、Batch APIのジョブ結果はAnthropic側に保存され、ZDRが約束する「即時削除」の対象から外れます。PHIを含むファイルをこれらの機能に渡すと、プロンプトと応答は削除されてもファイル自体は残るため、ZDR組織では入力経路そのものを設計時点で分ける必要があります。

HIPAA readinessが前提にしていること

HIPAA readinessは、PHIを扱う組織がBAA(Business Associate Agreement)を締結した上で、Claude APIの一部機能を使えるようにする仕組みです。ZDRとの決定的な違いは、即時削除を必須にしていない点にあります。暗号化・アクセス制御・監査ログといった、PHIのライフサイクル全体を守る安全策を敷いた上で、データの保持自体は許容されます。

対象はClaude API(api.anthropic.com)のみで、Claude Console経由の利用・Amazon Bedrock・Google Cloud・Claude Platform on AWS・Microsoft Foundry・Claude Codeは対象外です。標準のBAAであればConsoleのSettings > Privacyから自己申請で有効化でき、個別交渉が必要なBAAはアカウントチーム経由になります。一度有効化すると管理者による無効化はできず、恒久的な設定として組織に適用されます。

対象機能の重なりと違い

ZDRとHIPAA readinessは対象機能の一覧が完全には一致しません。公式の機能適格性表を突き合わせると、次のような差が見えます。

HIPAA readinessの方がZDRより対象外の機能が多く見えますが、両者の「対象外」の意味は違います。ZDRで対象外の機能を使ってもリクエスト自体はブロックされません。そのデータに関してZDRの枠外に出るという扱いになるだけです。一方HIPAA readinessが有効な組織でHIPAA非対象の機能を含むリクエストを送ると、APIは400エラーを返してリクエストを拒否します。

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "The requested features are not available for HIPAA-regulated organizations without Zero Data Retention: code_execution."
  }
}

エラーメッセージに「without Zero Data Retention」という文言が入りますが、これはAPI側の固定表現であり、ZDRを追加で有効化すれば解決するという意味ではありません。対象外の機能をリクエストから外して再送するのが唯一の対処です。

PHIをスキーマに書いてはいけない理由

HIPAA readinessが有効でも、機能の使い方次第でPHI保護の対象から外れる場所があります。代表例がStructured outputsとstrict tool use(strict: true)です。これらはJSONスキーマをグラマーとしてコンパイルし、メッセージ本体とは別にキャッシュします。このキャッシュされたスキーマは、プロンプトや応答と同じPHI保護の対象にはなりません。プロパティ名・enum値・const値・patternの正規表現にPHIを含めてはいけないという制約は、この技術的な理由から来ています。患者固有の情報はメッセージ本体にだけ書き、スキーマ側には構造の定義だけを置く必要があります。この制約の実装レベルの詳細はClaudeのstrict tool useとHIPAA/PHIで扱っています。

ワークスペース単位のデータ保持設定との関係

Claude Fable 5.1・Fable 5・Claude Mythos 5.1・Mythos 5はCovered Modelsに指定されており、30日間のデータ保持が必須です。ZDR組織がこれらのモデルにリクエストを送ると400エラーになりますが、ZDRを維持したまま特定のワークスペースだけ30日保持に切り替えることができます。他のワークスペースはZDRのまま残せるため、組織全体でZDRを崩さずに一部の業務だけCovered Modelsを使う設計が可能です。HIPAA readiness側にはこの種のワークスペース単位の例外は用意されておらず、組織全体に一律で適用される点も両者の運用面での違いです。ZDRがどの契約形態で有効になるかという切り分け自体はClaude Zero Data Retentionが有効になる契約形態の切り分けで扱っています。

この例外を実務で使うなら、ワークスペースを「機能」ではなく「保持ポリシー」を軸に分けるのが安全です。Covered Modelsを使う業務用のワークスペースを1つ切り出し、それ以外はZDRのまま維持する構成にすれば、Covered Models切り替えの影響範囲を組織全体ではなく該当ワークスペースだけに閉じ込められます。逆に、既存のZDRワークスペースの中で一部のリクエストだけCovered Modelsに切り替えるといった細かい制御はできません。切り替えの単位は常にワークスペース全体であり、ワークスペース内でZDR適用とCovered Models適用が混在することはない、という粒度を先に押さえておく必要があります。

フラグ付きコンテンツは両方の取り決めの外側にある

ZDRとHIPAA readinessのどちらを選んでも、例外なく保存されないわけではありません。法令上の要請がある場合や、Anthropicの自動化された安全性・不正利用検知システムがコンテンツにフラグを立てた場合、Anthropicはそのやり取りを最長2年間保持することがあります。これはどちらの取り決めにも共通する「取り決めにかかわらない保持」の枠であり、ZDRを選んでいるから安全、HIPAA readinessを選んでいるから安全、という単純な話にはなりません。コンプライアンス担当者がこの点を見落とすと、「ZDRなのになぜ一部のやり取りが残っているのか」という問い合わせにつながります。フラグが立つのはポリシー違反が疑われた場合に限られるため、通常利用のトラフィックがこの例外に触れることはまれですが、設計時点で「例外なくゼロ保持」ではないことは前提に入れておく必要があります。

Amazon BedrockとGoogle Cloud経由では前提が変わる

ここまでの内容は、Anthropicがデータ処理者になる経路(Claude API本体・Claude Platform on AWS・Microsoft Foundry)を前提にしています。Amazon BedrockやGoogle CloudのAgentプラットフォーム経由でClaudeを呼び出す場合は、クラウド事業者側がデータ処理者になるため、ZDRとHIPAA readinessという2つの枠組みそのものが適用されません。この経路を使う場合は、各クラウドプラットフォームが提供するデータ保持・コンプライアンス文書を確認する必要があり、Anthropicのこのページで定義されている用語や表はそのまま持ち込めません。自社がどの経路でClaudeを呼んでいるかによって、参照すべきドキュメントの出発点自体が変わる点は、ZDRとHIPAA readinessのどちらを検討する場合でも最初に確認しておくべき事項です。

HIPAA readinessはZDRの代替であって上乗せではない

PHIを扱う組織が「ZDRとHIPAA readinessを両方有効にすれば一番安全ではないか」と考えるのは自然ですが、公式ドキュメントはこれを明確に否定しています。PHIを扱う組織はHIPAA readinessを使えばよく、ZDRを追加で有効化する必要はありません。さらに、HIPAA readinessは組織単位で強制適用される設定のため、同じ組織でHIPAA対応ワークロードと一般用途のAPI利用を両立させることはできません。HIPAA対応が必要な業務と、それ以外の業務は別組織に分ける設計が前提になります。

これは「ZDRが厳格でHIPAA readinessが緩い」という単純な序列ではありません。ZDRは削除を保証する代わりに、状態を持つ機能をほぼ使えなくします。HIPAA readinessは監査可能性を保証する代わりに、保持そのものを許容します。PHIを扱う実務では、削除の保証よりも「誰がいつアクセスしたかを追跡できること」の方が要件に直結するため、HIPAA readinessという別ルートが用意されている、という理解が実態に近いといえます。

PHIを扱う利用形態別、どちらを選ぶかの早見表

どの組織がどちらを選ぶべきかは、扱うデータの性質で決まります。

この表が示すのは、ZDRとHIPAA readinessのどちらが「優れているか」ではなく、扱うデータの性質と使いたい機能の組み合わせで選択肢がほぼ一意に決まるという点です。PHIの有無だけで判断せず、状態を持つ機能を使う予定があるかどうかを先に洗い出しておくと、後から設定を作り直す手戻りを避けられます。

まとめ

ZDRは「保存しない」ことで保護し、HIPAA readinessは「保護した状態で保持する」ことで対応するという、根本的に異なる2つの取り決めです。対象機能も重ならない部分が多く、HIPAA非対象の機能を使うとZDRでは通っていたリクエストがHIPAA readiness組織では400で弾かれます。PHIを扱う予定がある組織は、ZDRとの二重有効化を検討する必要はなく、HIPAA readinessを単独で使う設計を前提にするのが公式の推奨です。組織全体の契約形態を含めて確認したい場合はClaude法人プランの契約ガイドも参考になります。