Claude Fable 5の30日間保持ポリシー：ZDR、HIPAA、COPPA

2026年6月12日 · claude-fable-5 · data-retention · compliance

ポリシーの実際の内容
30日間の保持期間が存在する理由
同じ要件、3つのクラウド、3つの仕組み
エンタープライズデプロイメントへの影響
消費者向けプロダクトへの影響
機密データを扱う業界：30日間の保持が最も深刻な影響を与える場面
ヘルスケア（HIPAA）
子ども向けプロダクト（COPPA）
同じパターン、他のセクター
意思決定チェックリスト
結論
FAQ
出典

組織がゼロデータリテンション（ZDR）契約のもとでClaudeを運用している場合、claude-fable-5への最初のリクエストはコンプリーションを返しませんでした。返ってきたのは400 invalid_request_errorです。これは障害ではなく、ポリシーです。Fable 5は、30日間のデータ保持なしには使用できない初の一般提供Claudeモデルであり、この要件はあらゆるプラットフォームにおいてモデルに付随します。Claude API、AWS Bedrock、Google Vertex AI、Microsoft Foundryのいずれも、明示的な保持オプトインを条件としてアクセスを制限しています。

「私たちはあなたのデータを保持しない」という前提をLLMスタックの確定済みの特性として扱ってきたチームにとって、これはアーキテクチャ上の重大な出来事です。本記事では、ポリシーの内容、この保持期間が存在する理由、各クラウドでの実装方法、そしてコンシューマー製品や機密データを扱う業界への影響について解説します。

ポリシーの詳細は、2026-06-12時点でAnthropicおよびAWS、Google、Microsoftの公開ドキュメントに基づいて確認しています。ポリシーは変更される場合があります。リンク先の一次情報源および自社の契約内容を必ず確認してください。本記事はエンジニアリングの概説であり、法的アドバイスではありません。

ポリシーの実際の内容

Anthropicは、Claude Fable 5およびClaude Mythos 5をCovered Modelsに指定しています。APIデータ保持ドキュメントおよびMythosクラスの保持慣行に関する記事（2026-06-09発効）によると：

プロンプトとコンプリーションは30日間保持され、その後自動的に削除されます——ただし、有効な安全調査のためにフラグが立てられた場合や法律で義務付けられている場合を除きます。
オプトアウトはありません。 保持はモデルを使用するための条件です。保持設定が要件を満たしていない組織からのリクエストは400 invalid_request_errorを返します。
アクセスは設計上、限定的です。 自動化された安全システムがデータをスクリーニングし、フラグが立てられた会話をレビューできるのは承認された少数の担当者のみです。エクスポート、コピー、ダウンロードはできず、すべてのアクセスは改ざん防止ログに記録されます。
既存のZDR契約は、クラウドプラットフォーム経由のものを含め、Covered Modelのトラフィックには引き継がれません。

コンシューマープラン（Claude Free/Pro/Max）は影響を受けません——これらはすでに独自の保持条件のもとで運用されています。このポリシーは商用APIの領域を対象としており、まさに「一切保持しない」という約束が存在しやすい場所です。

30日間の保持期間が存在する理由

Covered Modelsの記事における根拠は具体的です。これらのモデルはソフトウェアエンジニアリング、エージェントワークフロー、サイバーセキュリティにおいて大幅に高度な能力を持っており、**「一部の悪用は多数のリクエストにわたって初めて検出可能になる」**とされています。挙げられている例——best-of-Nジェイルブレイキング、国家主導のスパイ活動——は、個々のプロンプトは無害に見えても、シーケンス全体が診断的な意味を持つ攻撃パターンです。削除してしまったシーケンスは検出できません。

この保持期間がではないものを2点挙げます：

トレーニングデータではありません。 Anthropicは、明示的な許可なく保持データをトレーニングに使用しないと明言しています。目的は不正使用の検出のみです。
種類として新しいものではなく、強制力が新しいのです。 約30日間の不正使用監視ウィンドウは業界標準として長年存在してきました。OpenAIはAPIの不正使用ログを最大30日間保持し（ZDRは承認制）、Azure OpenAIは修正済み不正使用監視の承認を受けない限りプロンプトを最大30日間保存します。変わったのは、この保持期間が特定のモデルクラスにおいて交渉不可能になったことです——以前はすべてのプロバイダーがゼロリテンションの抜け道を提供していました。

多くの人が驚く既存の注意点として：ZDRのもとでも、Anthropicは安全分類器の結果を保持しており、利用ポリシー違反としてフラグが立てられたコンテンツは最大2年間保持される可能性があります。ゼロデータリテンションは、データがゼロであることを意味したことはありません——通常のパスにおいてフラグが立てられていないコンテンツの保持がゼロであることを意味します。

同じ要件、3つのクラウド、3つの仕組み

保持ポリシーはモデルが動作する場所を問わず適用されるが、各プラットフォームでのオプトインの方法は異なる。そしてその違いが、誰がデータを処理し、どこにコントロールが存在するかを決定する。

プラットフォーム	オプトインの仕組み	スコープ	オプトインなしの場合
Claude API	プライバシー設定での30日間保持	組織またはワークスペース	`400 invalid_request_error`
AWS Bedrock	`data_retention_mode: provider_data_share`	アカウントまたはプロジェクト	モデルが`unavailable`として表示され、リクエストがブロックされる
Google Vertex AI	Anthropicのデータ共有 + Model Gardenの利用規約	プロジェクト	有効化するまでリクエストがブロックされる
Microsoft Foundry	デプロイ時にAnthropicの利用規約に同意	サブスクリプション/デプロイメント	AzureのZDRプログラムの対象外

AWS Bedrock は最も明示的だ。データ保持は設定可能なモード（default / provider_data_share / none）であり、プロジェクト → アカウント → モデルのデフォルトの順で解決される。Fable 5はallowed_modes: ["provider_data_share"]を宣言しており、プロンプトと補完結果がAnthropicと共有され、最大30日間保持される。それ以外のモードでは：

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Fable 5以前のモデルに変更はなく、bedrock:DataRetentionMode条件キーに対するSCPを使えば、組織全体でポリシーを強制できる。誰かがこっそりアカウントを切り替えて新しいモデルを試すことはできない。なお、クロスリージョン推論を使用する場合、保持されたコピーは宛先リージョンに存在する。データ所在地に関するコミットメントがある場合、この点は重要だ。

Google Vertex AI は、プロジェクトレベルのAnthropicデータ共有設定（dataSharingEnabledProvider: "anthropic"を指定したsetPublisherModelConfig）とModel Gardenでの利用規約への同意を通じて、モデルへのアクセスを制限している。詳細はGoogleのFable 5ドキュメントを参照。一般的なデータ処理はVertex AIのデータガバナンスポリシーに従う。データ所在地が重要なワークロードについては、Vertexのリージョンおよびマルチリージョンエンドポイントが推論の実行場所を制御し、現在は保持されたコピーの保存場所も含まれる。

Microsoft Foundry は構造的に異なる。Microsoftのデータとプライバシーに関するドキュメントには、Claudeモデルはサードパーティのマーケットプレイスサービスであることが明記されている。デプロイ時にAnthropicの利用規約に同意し、データ処理者はMicrosoftではなくAnthropicとなる。Azure OpenAIのZDRおよび修正済み不正使用監視プログラムは、Claudeのデプロイには適用されない。他の場所でZDRポリシーを採用している組織は、通常、対象モデルの使用を専用サブスクリプションに分離し、保持の境界を手続き的なものではなく構造的なものにしている。

3つのプラットフォームに共通するパターン：保持クラスは、契約書の一段落ではなく、モード、フラグ、利用規約ゲートという形で、機械可読なモデルの第一級属性となった。インフラストラクチャでデータポリシーを強制できるようになったのだから、そうすべきだ。

エンタープライズデプロイメントへの影響

ZDR契約がない場合、機械的には何も変わらない。おそらく気づかないまま、すでに30日間スタイルのポリシーの下にいたはずだ。必要な作業は、それをベンダードキュメントで明示的にすることだ。

ZDR契約がある場合、3つの選択肢がある：

対象モデルをスキップする。 ZDRの均一性を維持し、モデルを諦める。ワークロードがそれを必要としない場合は有効な選択肢だ。コストと差異については、Fable 5の実測評価を参照。
ワークスペースまたはプロジェクトで分割する。 すべてのプラットフォームがスコープ付きオプトインをサポートしている。指定されたClaude APIワークスペース（コンソール → 設定 → ワークスペース → プライバシー設定）、provider_data_shareを設定したBedrockプロジェクト、別のVertexプロジェクトまたはAzureサブスクリプションなどが使える。保持を許容できるワークロードのみをそこにルーティングする。
組織全体で保持を受け入れる。 運用は最もシンプルだが、すべてのワークロードに対する保証が暗黙的にダウングレードされる。ZDRを正当化した機密性の高いワークロードも含めて。これは設定変更ではなく、データ保護責任者が判断すべき事項だ。

プロバイダーに関わらず：自社のロギングは第二の保持サーフェスとなる。 ゲートウェイや可観測性スタックがプロンプトの全文をログに記録している場合、プロバイダーよりも長いウィンドウで、自社の管理下でデータを保持していることになる。プロバイダーの保証は、その前段のレイヤーと同程度の意味しか持たない。キャッシュの主張に適用した監査ロジックと同じことがここにも当てはまる。

消費者向けプロダクトへの影響

消費者にサービスを提供しており、そのコンテンツを対象モデル経由でルーティングしている場合、ZDR契約の有無にかかわらず、この変更はあなた自身の法的リスク領域にも波及します。具体的な影響は以下の3点です。

1. プライバシーポリシーの更新が必要になる可能性が高い。 多くの法制度では、収集だけでなく保持についても開示が求められます。GDPRの第13条第2項(a)は収集時に保存期間（または判断基準）の開示を義務付けており、カリフォルニア州のCPRAは収集時の通知において個人情報のカテゴリごとに保持期間を明示することを求めています。もし現在のポリシーが会話データはどこにも保持されないと明記または示唆している場合、処理者が30日間のコピーを保持するという事実によってその記載は誤りとなります。プライバシーポリシー、処理活動の記録、DPAインベントリをそれぞれ更新してください。

2. 自社が持っていないオプトアウト手段をユーザーに提供することはできない。 この保持ポリシーには例外の仕組みが存在しないため、そのモデルを使い続けながら特定ユーザーのプロンプトを対象外にするようなトグルを実装することは不可能です。実際に手元にある手段はルーティングです。同意状況を認識するゲートウェイを使えば、データ共有を拒否したユーザーをZDR対応モデルへ、それ以外のユーザーを対象モデルへ振り分けることができます。これは法的制約を通常のルーティングルールへと変換するアプローチであり、何も機能しない設定チェックボックスよりはるかに優れた解決策です。

3. 削除リクエストには正確な仕組みが必要。 消去義務（GDPR第17条、CPRAの削除規定、およびそれらに相当する各国法）は処理者にも及びます。30日以内に自動削除される有限の保持期間は、処理者としての対応として一般的に正当と認められますが、DSARの対応手順書にはその旨を明記しておくべきです。実行できない即時の下流削除を約束することは避けてください。

グローバルな側面がこれをさらに複雑にします。同様の開示・処理者ロジックは、英国GDPR、ブラジルのLGPD、そして広がりを見せる米国各州のプライバシー法にも存在します。中国のユーザーについては、PIPLがさらに厳しい2つの要件を加えます。個人情報を別の処理者に提供する場合は原則として別途同意が必要であり、中国ユーザーのコンテンツを海外のLLMエンドポイントにルーティングすることは越境移転に該当し、認められたメカニズム（安全評価、標準契約、または認証）が必要です。誰が何をどこでどのくらいの期間保持するかを変えるモデルのアップグレードは、まさにこれらの法的枠組みが再手続きを求める変更に該当します。

機密データを扱う業界：30日間の保持が最も深刻な影響を与える場面

多くのプロダクトにとって、プロバイダーの保持ウィンドウはドキュメント上の問題に過ぎない。しかし、データそのものが規制対象となる業界にとっては、アーキテクチャ上の問題だ。保持されたコピーはベンダーにおける規制対象データの静的保存であり、業界規則はまさにその点を規定している。

ヘルスケア（HIPAA）

HIPAAはゼロ保持を要求しているわけではない。要求しているのは、保護された医療情報（PHI）を保持するベンダーが、適切な保護措置を備えた**Business Associate Agreement（BAA）**のもとでそれを行うことだ。プロンプトの30日間コピーは、ビジネスアソシエイトにおける静的PHIであり、問題はそのBAAがそれをカバーしているかどうかだ。2つの主要なAPIベンダーはこの点を異なる形で構成しており、その違いが今や重要な意味を持つ。AnthropicのHIPAAに対応したAPIアクセスは明示的にZDRを必要としない——暗号化、アクセス制御、監査ログ、機能制限の強制といった保護措置を伴う保持の上に構築されている。OpenAIのAPI BAAはゼロデータ保持の対象エンドポイントをカバーしており、ZDRエンドポイントを対象としたBAAは、構造上、保持を義務付けるモデルをカバーできない。

モデルの保持クラスは、今やBAA適格性の問題だ。 PHIをルーティングする前に、特定のモデルをBAAがカバーしていることを書面で確認すること——そして、クラウドが変わればチェーンも変わることを忘れないように。Bedrockではプラットフォームがビジネスアソシエイトとなるが、FoundryではAnthropicが直接データを処理する。注意すべき点として、PHIは構造化出力のJSONスキーマ定義に含めてはならない——キャッシュされたスキーマはメッセージコンテンツと同じ保護を受けない。

子ども向けプロダクト（COPPA）

タイミングが厄介だ。FTCの改正COPPAルールは2025年6月23日に発効し、ほとんどの条項のコンプライアンス期限は2026年4月22日だ——プロバイダー側での保持が義務付けられた最初のモデルは、オペレーターが新しい保持義務の実装を終えたまさにそのタイミングで登場した。そのうち2つが30日間ウィンドウと直接関係する。書面による公開データ保持ポリシーが§312.10により義務化された——子どものデータが何を収集し、なぜ収集し、いつ削除されるか——そして無期限の保持は禁止され、収集目的に合理的に必要な範囲に限定される。

自動削除を伴う30日間の有限ウィンドウは適合する形だ——しかしプロバイダーはあなたが子どものデータを収集した目的ではなく、自社のトラスト＆セーフティ目的で保持する。あなたの通知はプロセッサーの関係を正確に記述しなければならない。データの痕跡を最小化するために特にZDRを採用した子ども向けプロダクトにとっては、ルーティングの答えがより高い重要性を持つ。子どものトラフィックはZDR対象モデルに留めるか、Covered Modelのウィンドウをまず§312.10ポリシーに記載するかだ。

同じパターン、他のセクター

構造が見えてくると——規制対象データ、ベンダーにおける保持コピー、保持を規定するセクタールール——それは繰り返し現れる。

生体認証（イリノイ州BIPA）： オペレーターは生体認証データの書面による公開保持スケジュールと廃棄ガイドラインを必要とする。生体認証識別子を含むプロンプトのプロバイダーによる30日間コピーはそのスケジュールに含まれる。
決済（PCI DSS / GLBA）： PCI DSSは認証後の機密認証データの保存を——どこであれ——禁止している。プロンプトに貼り付けられたカードデータは、プロバイダーに30日間保持されるカードデータになる。クリーンな答えは上流での編集であり、下流での書類作業ではない。
教育（FERPA）： 学校職員例外のもとで学生記録を扱うベンダーは、学校の直接管理下に置かれなければならない。学校がアクセスも早期削除もできない安全保持コピーは、その基準と相容れない——EdTechのトラフィックがCovered Modelに到達する前に法律顧問に確認すべき問題だ。
金融サービス——逆転（SEC/FINRA）： ブローカーディーラーは帳簿・記録規則のもとでビジネスコミュニケーションを保持しなければならない。彼らにとってプロバイダーのウィンドウは問題ではなく、自社のコンプライアンスコピーを取得することが問題だ。同じ保持の問題だが、符号が逆だ。

共通の糸は：セクタールールは両方向で保持を規制しており、自分でコントロールできないプロバイダー側のウィンドウは、自分のセクターが指し示すどちらの方向にもマッピングされなければならない。

意思決定チェックリスト

✅ トラフィックが実際に触れるモデルをインベントリする。 保持クラスは今やプロバイダー単位ではなく、モデル単位の属性だ。
✅ ZDRを持っている場合：意図的に決定する——Covered Modelをスキップする、ワークスペース/プロジェクト/サブスクリプションで分割する、または組織全体で保持を受け入れる。暗黙的に起こらせてはならない。
✅ インフラでポスチャーを強制する——Bedrock SCP、ワークスペースのプライバシーコントロール、別々のクラウドプロジェクト——Wikiページではなく。
✅ B2C：プライバシー通知とDSARプレイブックを更新する；同意していないユーザーを、機能しないオプトアウトを構築するのではなく、ZDR対象モデルにルーティングする。
✅ 規制対象データ：モデルごとに書面でカバレッジを確認する——PHIにはBAA、子どものデータには§312.10ポリシー、生体認証には保持スケジュール——そのデータを保持必須モデルにルーティングする前に。
✅ 自社のロギングを監査する。 プロバイダーの30日間ウィンドウは、自社のゲートウェイが無期限にプロンプトをログに記録しているなら無意味だ。

結論

Fable 5 に付随する30日間のウィンドウはデータ収集目的ではありません。これは範囲が限定され、目的も制限された不正利用監視であり、業界の大多数がデフォルトで既に実施していることと一致しています。削除済みデータではリクエスト横断的な不正利用検知が機能しないため、このモデルクラスに限って必須とされています。ほとんどのチームにとってエンジニアリング上の影響はゼロであり、ガバナンス上の影響はベンダーレビューの1段落程度です。

ただし、ゼロ保持を前提としたコンプライアンス体制を取っている組織——ZDRスコープのBAA、何も保持しないと明記したプライバシーポリシー、データ最小化原則に基づいて構築された子ども向け製品——にとって、Fable 5 はその前提がモデル全体で均一ではなくなった転換点です。解決策はこのモデルを避けることではありません。価格やコンテキストウィンドウをすでに扱っているのと同様に、保持クラスをルーティング判断へのモデルごとの明示的な入力として組み込むことです。

FAQ

ゼロデータ保持契約のもとで Claude Fable 5 を使用できますか？ いいえ。Fable 5 と Mythos 5 は30日間の保持を必要とする対象モデル（Covered Models）です。ZDR組織は、ワークスペースで30日間保持を有効にして Fable 5 のトラフィックをそこ経由でルーティングしない限り、400 invalid_request_error が返されます。

AWS Bedrock、Vertex AI、または Microsoft Foundry を経由すれば要件を回避できますか？ いいえ。各プラットフォームはそれぞれ独自の保持オプトインの後ろにモデルを配置しています。Bedrock では provider_data_share、Vertex では Anthropic のデータ共有と Model Garden の利用規約、Foundry では展開時の Anthropic の利用規約（Foundry では Microsoft ではなく Anthropic がデータ処理者）が必要です。既存の ZDR 契約はいずれのプラットフォームでも引き継がれません。

エンドユーザーは保持をオプトアウトできますか？ いいえ——オプトアウトの仕組みはありません。あなたが持つ手段はルーティングです。データ共有を拒否するユーザーは ZDR 対応モデルに送ってください。何も変わらない設定トグルを実装しないでください。

保持されたデータはモデルの学習に使用されますか？ Anthropic は、保持されたデータは明示的な許可なしに学習に使用されることはないと述べています。目的はトラスト＆セーフティのレビューです。自動スクリーニングを行い、フラグが立てられた会話はデータをエクスポートできない承認済み担当者のみが閲覧でき、改ざん防止のアクセスログが記録されます。

30日間の保持はプロンプトキャッシュの動作を変えますか？ いいえ。キャッシュエントリは独自の短い TTL（5分または1時間）に従い、Fable 5 のキャッシュ契約は変わりません——実測評価をご覧ください。30日間のウィンドウは安全性レビューのための別個の並行保持です。

出典

すべて 2026-06-12 に確認済み。ポリシーは変更される場合があります——現在のドキュメントおよびご自身の契約に照らして確認してください。法的アドバイスではありません。

← ブログに戻る