Claude APIのZDRとは — HIPAAとのデータ保持の違い

Claude APIのデータ保持には、Zero Data Retention(ZDR)とHIPAA readinessという2つの取り決めがあります。向いている方向は逆です。ZDRはAPIレスポンスを返した後にプロンプトと生成結果を保存しない設定です。HIPAA readinessは、PHI(保護対象の保健情報)を扱う組織向けに、暗号化・アクセス制御・監査ログを敷いたうえで保持そのものは許容します。

PHIを扱うならHIPAA readiness、扱わずに保存を避けたいならZDRが基本線です。両方を有効にする必要はありません。

ClaudeのZDRとは何か、どう申請するか

ZDRは、レスポンスを返した後、入力と出力をAnthropic側に保存しない契約上の取り決めです。Claude APIのZDRは、Anthropicの営業チームに依頼して有効にします。HIPAA readinessのようにConsole上で自己申請する手順は用意されていません。有効化は組織ごとで、新しい組織を作ればその組織で改めて依頼します。

症状から引く:どちらの設定が当てはまるか

扱うデータと使いたい機能の組み合わせで、選択肢はほぼ決まります。

最後の行が見落とされやすい落とし穴です。ZDRで使える機能が、HIPAA readinessでも使えるとは限りません。

ZDRの射程:対象になるものとならないもの

ZDRの対象は3つです。Messages APIとToken Counting APIの対象機能、Commercial組織のAPIキーで使うClaude Code、Claude Platform on AWSです。有効化は組織ごとで、同じアカウント配下の別組織には自動で広がりません。

対象外は次のとおりです。

• Claude Console(playgroundを含む)
• Claude Managed Agents
• Free・Pro・Maxプラン
• TeamとEnterpriseの製品インターフェース
• Claude for Excel

Claude Codeには例外が2つあります。API利用側でメトリクス記録を有効にすると、利用統計などの生産性データはZDRの例外として保持されることがあります。Claude Enterprise上のClaude Codeは、この取り決めではなく別枠のZDRで、有資格アカウントにAnthropicが個別に有効化します。

そのEnterprise側では、保存が前提の機能がバックエンドで止まります。クラウドセッション、Remote Control、Artifacts、/feedback・/bug・/shareなどが該当します。ZDRの組織に個人アカウントや別組織のAPIキーでログインしたセッションは対象外です。forceLoginMethodとforceLoginOrgUUIDの管理設定で、ログイン先を組織に固定できます。

Enterprise版のZDRには、ほかにも外側に残るものがあります。コントリビューション指標はZDR組織では使えず、分析ダッシュボードには利用指標だけが出ます。Claude for EnterpriseのWebインターフェースでのチャットとCoworkセッションも、ZDRの対象外です。無効化される機能にはClaude Tagもあり、チャンネルのメモリーとセッションのトランスクリプトを保持するためです。

ブラウザーから直接APIを呼ぶ構成にも制約があります。ZDR組織ではCORSがサポートされないため、バックエンドのプロキシ経由にする必要があります。

ZDRで対象外の機能を使うと何が起きるか

ZDRでは、対象外の機能を使ってもリクエストはブロックされません。その機能の保持ポリシーが適用されるだけです。保存が前提の機能ほど、保持期間がはっきり決まっています。

Files APIのファイルは、削除するか設定した有効期限が来るまで残ります。PHIを含むファイルをここに渡すと、プロンプトと応答の保存を避けても、ファイル自体は残ります。

保存対象外の機能は、一覧では次のように分かれます。ZDRとHIPAA readinessで答えが違う行に注目してください。

Programmatic tool callingもCode executionのコンテナ上で動くため、どちらも対象外です。

Web searchはZDRでもHIPAA readinessでも対象です。ただしWeb searchとWeb fetchのどちらでも、動的フィルタリング(Dynamic filtering)はZDRにもHIPAA readinessにも該当しません。Web fetchでは、取得先サイトの運営者が、取得されたURLやリクエストのメタデータを自らのポリシーに従って保持することがあります。

HIPAA readinessの射程と有効化

HIPAA readinessの対象はClaude API(api.anthropic.com)だけです。Claude Console経由の利用とClaude Codeは対象外です。Amazon Bedrock、Google CloudのAgent Platform、Claude Platform on AWS、Microsoft Foundryも同様です。ベータ機能も、適格性表に明記されていない限り、BAAの対象外として扱われます。

標準のBAAなら、Console上で自己申請できます。個別に交渉したBAAが必要な場合はAnthropicの営業チームが対応します。

Messages APIの機能すべてが対象になるわけではありません。PDFは、Messages APIにインラインで送る場合だけが対象で、Files API経由は対象外です。

対象外の機能を送ったときのエラーの読み方

HIPAA readinessが有効な組織が非対象の機能を含むリクエストを送ると、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を足せば通るという意味ではありません。機能をリクエストから外して再送します。

例外はクライアント側で動くツールです。Browser useのように、適格性表のDetails欄でブロックされないと書かれているものは受け付けられますが、HIPAA readinessの対象外のままです。通ったからといってBAAの対象になったわけではありません。どの機能が対象かの正は、署名したBAAです。

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

Structured outputsとstrict tool use(strict: true)は、JSONスキーマをグラマーにコンパイルし、メッセージ本体とは別にキャッシュします。このキャッシュにはプロンプトや応答と同じPHI保護がかかりません。

プロパティ名・enum値・const値・patternの正規表現にPHIを入れないでください。患者固有の情報はメッセージ本体にだけ書きます。実装レベルの詳細はClaudeのstrict tool useとHIPAA/PHIで扱っています。

HIPAAの文脈でPHIが現れるのは、メッセージ内容、添付ファイル(画像・PDF)、ファイル名やメタデータです。ワークスペース名、ユーザー情報、請求データ、サポートチケットにはPHIが含まれない前提になっています。

Covered Modelsとワークスペース単位の切り替え

Claude Fable 5.1・Fable 5・Claude Mythos 5.1・Mythos 5はCovered Modelsで、30日間のデータ保持が必須です。保持の設定を満たさない組織からのリクエストは、たとえばFable 5宛てなら400になります。

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "In order to access this model, your organization or workspace must have data retention enabled."
  }
}

Covered Modelsの一覧は、公式ページ間で書き方が違います。Claude CodeのZDRページはFable 5.1とFable 5の2つを挙げ、APIのデータ保持ページはMythos 5.1とMythos 5を加えた4つを挙げています。API側の4モデルは、ZDRではAnthropicが明示的に認めた場合を除いて使えません。両ページがリンクするCovered Modelsのサポート記事も同じ4モデルを挙げています。Fable 5.1とFable 5は一般提供で、Mythos 5.1とMythos 5は承認パートナーに限られた提供(Limited access)です。

保持データの置き場所は経路で変わります。Claude API(Claude Platform on AWSを含む)ではAnthropicが保持データを扱い、Amazon BedrockとGoogle CloudのAgent Platformでは、保持データは利用者のクラウド事業者の環境内に残ります。

ZDR組織は、ZDRを維持したまま特定のワークスペースだけ30日保持に切り替えられます。

1. Claude ConsoleのSettings > Workspacesで対象のワークスペースを選ぶ
2. Privacy controlsタブで30日間のデータ保持をオンにする
3. そのワークスペースからCovered Modelsへのリクエストが通るようになる

30日保持はワークスペース単位の設定で、上書きのないワークスペースは組織の既定であるZDRに従います。Covered Modelsを使う業務用のワークスペースを1つ切り出す構成になります。

ワークスペース単位の切り替えはZDR組織向けの仕組みで、HIPAA readinessは組織単位で強制されます。HIPAAを使う業務とそうでない業務は、別組織に分けます。契約形態ごとの切り分けはClaude Zero Data Retentionが有効になる契約形態の切り分けにあります。

どちらを選んでも残るもの

ZDRでもHIPAA readinessでも、法令上必要な場合と、自動化された安全性・不正利用検知システムがフラグを立てた場合は、入力と出力が最長2年保持されることがあります。2年保持の例外があることを前提に設計します。

監査・コンプライアンス側のデータにも別の保持規則があります。

• Activity Feedは6年間保持される
• Compliance APIはZDRが有効なローカルセッションを取得しない
• HIPAA readinessが有効な組織では、Compliance APIはCoworkとClaude Codeのローカルセッションだけを取得し、トランスクリプトを30日間保存する

「保存しない」と「監査で追える」は別の層の話です。

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

ここまでの内容は、Anthropicがデータ処理者になる経路(Claude API・Claude Platform on AWS・Microsoft Foundry)が前提です。

Amazon BedrockとGoogle CloudのAgent Platformでは、クラウド事業者がデータ処理者になります。保持とコンプライアンスは各社の文書が出発点で、このページの表はそのまま持ち込めません。

まとめ

取り決めを選ぶ前に、使いたい機能を先に並べます。PHIを扱うならHIPAA readinessだけで足り、ZDRの追加は要りません。組織全体の契約形態を含めて確認したい場合はClaude法人プランの契約ガイドも参考になります。