Claude ZDR組織でワークスペースごとにデータ保持を有効にする手順

Claude ZDR組織のワークスペースで30日間のデータ保持を有効にすると、そのワークスペースだけがCovered Models(Claude Fable 5.1など)を使えるようになります。組織全体のゼロデータ保持(ZDR)を解除する必要はありません。有効化にはAdmin・Owner・Primary Ownerのいずれかの権限が必要で、対象になるのは既定以外のワークスペースだけです。変更は遡及せず、暗号鍵を使うワークスペースでは後から無効化できません。

ZDR(ゼロデータ保持)とは何か

ZDRは、APIの応答を返したあと、プロンプトと出力を保存しない取り決めです。会話内容(プロンプトとClaudeの出力)はもともと既定では保持されません。例外がCovered Modelsで、こちらは30日の保持が必要です。

ZDRは組織ごとに有効化され、申し込み先はAnthropicの営業チームです。Claude TeamsとClaude Enterpriseの製品画面は、この取り決めの対象外です。EnterpriseのClaude Codeだけは、別のZDR提供があります。

「Claudeのデータ保持」と検索して出てくる設定は、使い方で別物です。この記事が扱うのは、Claude APIの組織とワークスペースの保持です。claude.aiのチャットやプロジェクトの内容は、組織が管理画面で決める保持期間に従います。

Covered Modelsを呼んだら400エラーになるのはなぜか

Covered Modelsに指定されているのは、Claude Fable 5.1・Claude Mythos 5.1・Claude Fable 5・Claude Mythos 5の4モデルです。これらは30日間のデータ保持が必須で、Anthropicが組織に対して明示的に認めた場合を除き、ZDRのままでは使えません。ZDRのワークスペースのAPIキーでリクエストを送ると、400 invalid_request_error が返ります。

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

エラー文の表記は資料によって少し違います。API側のドキュメントは workspace と小文字で、サポート記事は Workspace と大文字で書いています。どちらも意味は同じなので、メッセージの完全一致で検知する処理を書くときは、大文字小文字を区別しない比較にしておくと安全です。

データ保持はワークスペース単位の設定です。Covered Modelsを使いたいワークスペースごとに、個別に有効化します。

同じエラーが出ても、直し方は状況で変わります。

組織全体でどの契約形態がZDRの対象になるかはClaude Zero Data Retentionが有効になる契約形態の切り分けで扱っています。この記事は、ワークスペース単位の保持トグルを実際に操作する側に絞っています。

どの経路でClaudeを呼んでいる組織が対象か

API側のドキュメントがZDRとして扱うのは、Claude API(api.anthropic.com)・Claude Platform on AWS・Claude in Microsoft Foundryです。いずれもAnthropicがデータの処理主体になる経路です。一方、Amazon BedrockとGoogle CloudのAgent Platformでは、クラウド事業者が処理主体になります。Covered Modelsの30日保持の要件はそちらにも及びますが、保持されたデータは各クラウド事業者の環境内に留まります。有効化の手順は各プラットフォームの資料に従い、このConsoleの画面で操作する対象ではありません。

サポート記事のほうは、この設定が使えるのを「ZDRを使うClaude APIの組織」と限定しています。Claude Platform on AWSの組織にこの画面が出るかどうかは、サポート記事に書かれていません。AWS経由で契約している場合は、まず自分の組織のConsoleにData retention列と「This workspace」のスイッチがあるかを見るのが近道です。

ZDRは組織ごとに有効化されます。同じアカウントの下に別の組織を作っても、ZDRは自動では引き継がれず、組織ごとにアカウントチームが有効化します。保持の設定が組織で違うことがあるのはこのためです。

始める前に確認する権限とワークスペース

操作を始める前に、次の2点を満たしているか確かめます。

• Admin・Owner・Primary Ownerのいずれかであること。それ以外のロールでワークスペースに参加しているメンバーは、設定を見られても変更できません。
• 既定のワークスペース以外を操作していること。既定のワークスペースの保持は組織単位で管理されており、この画面からは変えられません。

Covered Modelsを既定のワークスペースで使いたい場合は、新しいワークスペースを作成して、そちらで保持を有効にします。作成方法はConsoleのワークスペース管理の手順に沿います。

権限の広さは、組織データのエクスポートと比べるとわかりやすくなります。エクスポートはPrimary Ownerだけが実行できる操作です。このトグルはAdminとOwnerも操作できます。エクスポートの手順はClaude組織データエクスポートの手順(Primary Owner向け)にあります。

ワークスペース単位でデータ保持を有効にする手順

設定は、各ワークスペースの左サイドバー最下部にあるPrivacy controls(プライバシー設定)にあります。

メニューの辿り方は、公式ページ同士で表記が違います。API側のドキュメントは「Claude Console > Settings > Workspaces」でワークスペースを選び、「Privacy controls」タブを開く、と書いています。手元のConsoleで一方の経路に見つからなければ、もう一方の経路を試します。

オンにすると何が変わるか

変更は新しいリクエストにすぐ反映されます。まれに最大1時間かかることがあります。反映の遅れを疑う場合は、1時間ほど待ってから再試行します。

Covered Modelsを呼べるのは、組織がそのモデルへのアクセス権をすでに持っている場合に限ります。ワークスペースの保持を変えても、組織の側にないアクセス権は付きません。

トグルが対象にするのは、APIのリクエストとレスポンスです。Batch API・Files API・Claude Managed Agentsのセッションのように、動かすためにデータを保存する機能は、このトグルで保持期間が変わりません。ZDRの取り決めの下でも、これらの機能は自分の保持ポリシーに従います。ZDRの下でこうした機能を使っても、リクエストが拒否されるわけではありません。使うと、その機能のデータについてはZDRの外に出ることになります。Compliance APIのように、ZDRやHIPAA readinessとは別の保持モデルを持つ機能もあり、Compliance APIのFAQで扱っています。

フラグが付いたデータはトグルと別に保持される

この保持は、ワークスペースのトグルとは別の仕組みです。ZDRやHIPAA readinessの取り決めがあっても、法律上必要な場合や、Anthropicの自動のトラスト&セーフティ検知でフラグが付いた場合は、データが保持されることがあります。フラグが付いた会話やセッションの入力と出力は、最長2年保持されることがあり、ZDRのワークスペースでもこの例外は消えません。

どのワークスペースが保持中かを見分ける

「Organization settings」→「Workspaces」を開くと、Data retention列があります。各ワークスペースが「Zero data retention」か「30 day retention」のどちらかで出ます。複数のワークスペースを運用している組織では、Covered Modelsを使う予定のものだけが「30 day retention」になっているかを、この一覧で棚卸しできます。

データ保持をオフに戻すときの制約

有効化した保持は、同じスイッチからオフに戻せます。ただし、次の3つに注意が必要です。

• 暗号鍵(customer-managed encryption keys)を使うワークスペースでは、保持をオフに戻せません。暗号鍵を使う運用に切り替える前に、トグルをオフへ戻す可能性があるかを見極めておきます。
• 保持を必須とするプログラムが付いているワークスペースでは、オフにするとそのプログラムが外れます。プログラムの割り当ては、サポート記事「Assign a program to workspaces in Claude Console」にあります。
• 保持がオフのワークスペースからは、Covered Modelsを呼べません。呼ぶと、冒頭の400エラーが返ります。Covered Modelsの利用を目的にオンにしていたワークスペースでは、オフに戻した時点でそのモデルが使えなくなります。

オフに戻したあと、すでに保持されたデータがどう扱われるかは、サポート記事にもAPI側のドキュメントにも書かれていません。この点はアカウント担当に確かめます。

なお、ZDRの対象外にある機能について削除を求めたいときは、アカウント担当に相談する、とAPI側のドキュメントは書いています。

ワークスペース単位にするか、契約側で扱うか

Covered Modelsを使うワークスペースが限られているなら、ワークスペース単位のトグルが向いています。使わないワークスペースは、これまでどおりZDRのまま残せるためです。API側のドキュメントも、保持を有効にしたワークスペース以外はZDRを保つ、と書いています。

使う想定のワークスペースが組織の大半に広がる場合は、事情が変わります。ワークスペースごとにトグルを入れていく運用が現実的かどうかは、この点で判断が分かれます。組織全体の保持の扱いやZDRが自分の組織に入っているかどうかは、契約条件かアカウント担当で確かめる、とAPI側のドキュメントは案内しています。

まとめ

Covered Modelsが400エラーで拒否される原因がZDRのワークスペースなら、そのワークスペースの「This workspace」をオンにします。前提は、組織がそのモデルへのアクセス権を持っていることです。暗号鍵を使うワークスペースでは後からオフに戻せないので、オンにする前に決めておきます。