Claude Zero Data Retentionが有効になる契約形態の切り分け
ZDRが有効なのは、Claude for EnterpriseでのZDR個別有効化か、コンシューマー以外のAPIキー利用の2経路だけです。Web UI・Cowork・Teamプラン本体は対象外という範囲をまとめます。
Claude Zero Data Retention(ZDR)は「契約すれば全社的にオンになる」機能ではありません。有効になる経路は、Claude for Enterpriseでの個別有効化と、コンシューマー以外のAPIキーによる利用の2つに限られます。Teamプランの画面やClaude.aiのチャット、Coworkは、この2経路のどちらに乗せてもZDRの対象になりません。社内システムへの組み込みを検討する前に、この境界線をまず正確に引く必要があります。
Claude Zero Data Retentionとは何か
ZDRは、APIレスポンスを返した後にプロンプトと生成結果をAnthropicが保存しない設定です。法令順守や不正利用対策のために必要な場合を除き、会話の中身は応答が返った時点で残りません。有効化は組織単位で、同じアカウントの下に新しく作られた組織には引き継がれないため、複数組織を運用する会社は組織ごとに申請が要ります。
ZDRが適用されるのは、Anthropicが直接データ処理者(データプロセッサー)になる面だけです。Amazon BedrockとGoogle Cloudのエージェント基盤では、クラウド事業者側がデータ処理者になるため、それぞれのプラットフォームの方針に従います。Microsoft Foundry上のClaudeは、API側の公式ページではAnthropicがデータ処理者になる面に含まれます。ただしClaude CodeのZDRページはFoundry上の利用を各プラットフォームの方針に振り分けているため、契約と設定は個別に確認します。自社がどの経路でClaudeを呼んでいるかで、読むべきドキュメントそのものが変わります。
自社の使い方がZDRの内側かを決める順序
公式は契約プラン名ではなく、認証先の組織と経路で範囲を決めています。次の順に当てはめると、どの経路に乗っているかが分かります。
ZDRの内側かどうかを判定する順序
- 1
Anthropic直営の面か確かめる
BedrockかGoogle Cloud経由なら、ZDRの話ではなく各クラウドの方針の話です。ここで判定は終わります。Microsoft Foundryは契約とAzure側の設定を個別に確認します。
- 2
呼び出し口を特定する
claude.aiのチャット、Cowork、Claude Consoleのプレイグラウンドなら、契約プランを問わず対象外です。ClaudeのAPI、またはClaude Codeなら次へ進みます。
- 3
認証先の組織にZDRが個別有効化されているか確かめる
Commercial組織のAPIキー、またはZDRを有効化したEnterprise組織にログインしたClaude Codeだけが対象です。個人アカウントや別組織のキーでログインしたセッションは外れます。
- 4
使う機能と対象モデルを確かめる
同じZDR組織でも、機能とモデルによって外れるものがあります。後の節の一覧で照合します。
ZDRが有効になる2つの契約形態
ZDRが効く2つの経路
コンシューマー以外のAPIキー
Anthropicの営業チームへの申請で有効になります。Claude APIとClaude Platform on AWSが対象で、Claude CodeもCommercial組織のAPIキーで使えばZDRの内側です。
Claude for Enterprise
標準のEnterpriseプランには含まれず、管理画面からも有効化できません。適格性を確認したうえでAnthropicが個別に有効化し、対象はClaude Codeの利用だけです。
どちらも「契約するだけで自動的にオン」にはなりません。Enterpriseと契約したこと自体は、ZDRの根拠にならない点が誤解されやすい部分です。
従量課金のAPIキーでZDRを使っていた組織は、ZDRを維持したままEnterpriseへ移行し、ユーザー単位のコスト管理・Analyticsダッシュボード・サーバー管理設定・監査ログを得られます。ただしZDR組織のClaude Code Analyticsでは、contribution metrics(コードの採用状況などの詳細指標)が使えず、利用量メトリクスのみになります。
対象外になる面と、ZDR組織の中で外れるもの
範囲外は次のとおりです。
- Claude Free・Pro・Max: Web・デスクトップ・モバイルアプリ、およびこれらのプランでのClaude Codeを含めて対象外です
- TeamとEnterpriseの製品インターフェース: claude.aiのチャット画面はZDR対象外です。例外はEnterprise配下でZDRが有効化されたClaude Codeだけです
- Cowork: セッションはZDRの対象になりません
- Claude Console(プレイグラウンドを含む): いかなる利用も対象外です
- Claude for Excel: 対象外です(API側の公式ページに明記があります)
- Claude Managed Agents: セッションはステートフルで、記録は明示的に削除するまで残ります
- ブラウザからの直接呼び出し: ZDR組織はCORSに対応しないため、ブラウザ上のコードからはバックエンドプロキシ経由でAPIを呼びます
- サードパーティー連携: MCPサーバーなど外部ツールが処理したデータには、ZDRが及びません
APIキー経路でも「No」の機能は止められない
API側のページには、機能ごとにZDR対象かどうかを示す一覧があります。ここに落とし穴があります。ZDR非対応の機能を使っても、リクエストはブロックされません。記述は「その特定のデータについてZDRの外に出る選択をしたことになる」です。同じ一覧でHIPAA非対応の機能を使うと、APIが400エラーで止めるのとは対照的です。
| ZDR非対応の機能 | 保持の記載 |
|---|---|
| Batch processing | 保持の記載29日間保持(非同期の保存が必要) |
| Code execution・Programmatic tool calling | 保持の記載コンテナのデータを最長30日保持 |
| Files API | 保持の記載明示的に削除するか、設定した期限まで保持 |
| MCP connector・Agent skills | 保持の記載標準の保持方針に従う |
一方、Bash tool・Text editor tool・Memory toolのようなクライアント側で動くツールや、Prompt cachingはZDR対象です。プロンプトキャッシュはKV cacheと暗号ハッシュがキャッシュの有効期間だけメモリー上に置かれ、期限後に速やかに削除されると書かれています。ZDRのAPIキーで社内システムを組むとき、「Messages APIを呼べばよい」で済まず、使うツールごとの照合が要ります。
Enterprise ZDRで自動的に無効化される機能
EnterpriseでZDRが有効な組織では、プロンプトや応答の保存を前提とする機能がバックエンドで自動的に無効化されます。クライアント側の表示にかかわらずブロックされるため、起動時に表示されていても使おうとするとエラーが返ります。
| 無効化される機能 | 理由 |
|---|---|
| クラウドセッション(Claude Code on the webと、Desktopアプリから開始したもの) | 理由会話履歴を含むセッションデータのサーバー側保存が前提 |
| Claude Tag | 理由チャンネルの記憶とセッション記録を保持する |
| Artifacts | 理由公開ページのコンテンツをAnthropic側のインフラに保存する |
フィードバック送信(/feedback /bug /share) | 理由会話データをAnthropicへ送る動作そのもの |
| Remote Control | 理由デバイス間の同期のため、セッション記録をAnthropicのサーバーに保存する |
プロンプトや生成結果の保存を必要とする新機能も、今後同じ基準で無効化されうると明記されています。ZDR組織で新機能が使えないときは、まずこの一覧を疑う価値があります。
公式ページ同士で食い違って見える3点
ZDRの説明はClaude Codeのドキュメント、APIのドキュメント、ヘルプセンターに分かれています。突き合わせると、1ページだけ読んでも気づけない差が3つ出ます。
ページをまたぐと見える差
無効化リストの外にもZDR非互換がある
Claude CodeのZDRページの無効化リストは5項目です。一方、BAAのヘルプ記事の対応表では、Claude Code Review・Claude Code Security・Claude Code Computer Use(いずれもベータ)にも「ZDRと非互換」と書かれています。リストに無いからといって、使えるとは限りません。
HIPAAはZDRの代わりになり、Claude Codeでは前提になる
APIのドキュメントは、PHIを扱う組織にはHIPAA readinessがZDRの代替で、両方は要らないとします。一方BAAのヘルプ記事では、Claude CodeはZDRが有効なときにだけBAAの対象です。
ZDRでも残るデータがある
Claude Codeでメトリクスログを有効にすると、利用統計などの生産性データはZDRの例外として保持されうるとAPI側に書かれています。Compliance APIは、ZDRが有効なローカルセッションを取得しません。
HIPAAとZDRは同じものではありません。HIPAA readinessは暗号化・アクセス制御・監査ログといった安全管理措置を課す仕組みで、即時削除を求めません。APIだけでPHIを扱うならHIPAA readinessで足り、Claude Codeまで含めるときにZDRが必要になる、というのが2つのページを合わせた読み方です。医療機関側の前提条件はClaude EnterpriseのBAA締結 — 医療機関の前提条件で整理しています。
ZDRを確実に効かせるClaude Codeのログイン設定
Claude Codeは、開発者が個人アカウントや別組織のAPIキーでログインすることも技術的にはできます。ZDRが適用されるのは、ZDR有効の組織に認証したセッションだけです。個人のclaude.aiアカウントや別組織のキーでログインすると、そのセッションは対象から外れます。
これを防ぐには、forceLoginMethodとforceLoginOrgUUIDのmanaged settingsを配布し、ログイン先をZDR組織に強制します。Claude Consoleでのログインをこのキーがどう扱うかも公式に定義されているため、配布前に組織全体のログイン経路を洗い出しておくことが前提です。
Fable 5.1などの対象モデルはZDRのままでは使えない
Claude Fable 5.1・Fable 5・Claude Mythos 5.1・Mythos 5は「Covered Models」に指定され、30日間のデータ保持が必須です。Anthropicが明示的に認めた場合を除いて、ZDRでは使えません。API側の公式ページの例では、保持設定が要件を満たさない組織からClaude Fable 5へリクエストすると、400 invalid_request_errorが返ります。メッセージは「組織またはワークスペースでデータ保持を有効にする必要がある」という趣旨です。Claude Codeでは、モデルピッカーに出ないか、無効表示になります。
Enterprise Frontier Safeguards(EFS)への移行期間として、対象顧客が自社の業務アプリケーション向けにFable 5・5.1をZDRのまま使える、期間限定の経過措置もあります。Mythosは含まれず、対象になる組織にはAnthropicなどから連絡が来るとされています。
Fableはデフォルトモデルではないため、影響が出るのは開発者がFableを明示的に指定した場合です。bestエイリアスは利用可能な最新のFableに解決され、Fableが使えない組織ではOpusに解決されるので、エイリアス経由で400に当たることはありません。Fable 5.1の安全対策に絡む動きは、監視データを顧客のクラウドに置くEnterprise Frontier Safeguardsの発表で扱っています。
ZDRを維持したままFableを使うには、ワークスペース単位で30日保持を有効にします。設定はClaude Consoleのワークスペース設定にある「Privacy controls」タブで、他のワークスペースはZDRのままです。Claude Codeを使うEnterpriseのZDR組織では、管理コンソールで保持設定を切り替える仕組みが案内されています。Foundryの場合は、別のAzureサブスクリプションを作って使い分けます。ワークスペース単位の手順はClaude ZDR組織でワークスペースごとにデータ保持を有効にする手順にまとめています。
ZDRが有効でも、法令上の要請や利用ポリシー違反への対応が必要な場合、Anthropicはデータを保持することがあります。セッションが違反として検知されたときは、入出力を最長2年保持する場合があります。
経路単位でポリシーを決める
ZDRをどの単位で保証するかが、社内システムの設計判断になります。ZDR契約のAPIキーを使うシステムだけがZDR対象で、同じ会社の従業員がTeamプランのWeb UIで同じ業務をこなせば、保護は及びません。EnterpriseでZDRを有効にした場合も、対象はClaude Codeだけで、同じ組織のチャット画面やCoworkは外側に残ります。
このため、機密情報の扱いを「プランで一律に決める」設計は成り立ちません。機密性の高い業務をZDR対象の経路に限り、それ以外の経路では機密情報を扱わせない、という経路単位のルールが実態に合います。プランごとの機能差はClaude法人プランの契約ガイド、そもそもどこまでの機密情報を入力してよいかはClaudeに機密情報を入力しても安全かが手前の論点です。
まとめ
ZDRの範囲は、プラン名ではなく「どの経路で、どの機能を、どのモデルで使うか」で決まります。社内の担当者は、APIキー経路とEnterpriseのClaude Codeだけを機密業務の入口にし、その内側でも「No」の機能とCovered Modelsが外れることを確認してから設計に入る、という順序が読み取れます。エンタープライズプラン全体の構成はClaude Enterpriseガイド、ログイン先の固定に使うmanaged settingsの配布経路はClaude Code DesktopのSSOとデバイス管理で扱っています。