Synthorai
🎁 新規 無料登録、10回の呼び出しを進呈。最大 $1、カード不要。
Claude Fable 5 は ZDR では利用不可：30 日間のデータ保持が必須

Claude Fable 5 は ZDR では利用不可：30 日間のデータ保持が必須

2026年6月12日 · 更新日 2026年7月19日 · claude-fable-5 · data-retention · compliance
目次
  1. ポリシーの内容
  2. 30 日間の保持期間が必要な理由
  3. 同じ要件でも cloud ごとに仕組みが異なる
  4. Enterprise deployment への影響
  5. Consumer 向け product への影響
  6. 機密データを扱う業界：30 日間の保持が最も重く響く領域
  7. Healthcare（HIPAA）
  8. 子ども向け product（COPPA）
  9. 他の業界でも同じ構造が繰り返される
  10. 判断用 checklist
  11. 結論
  12. FAQ
  13. 出典

組織でゼロデータ保持契約（ZDR）のもと Claude を利用している場合、claude-fable-5 への最初のリクエストで completion は返りません。返るのは 400 invalid_request_error です。障害ではなく、ポリシーによるものです。Fable 5 は、30 日間のデータ保持なしでは利用できない初の一般提供 Claude モデルです。この要件は、Claude API、AWS Bedrock、Google Vertex AI、Microsoft Foundry のすべてに適用され、どのプラットフォームでも明示的な保持へのオプトインが必要です。

「データを保持しない」ことを LLM stack の確定した前提としてきたチームにとって、これはアーキテクチャ上の大きな変更です。本記事では、ポリシーの内容、30 日という期間が設けられた理由、各 cloud での実装、consumer product や機密データを扱う業界への影響を説明します。

TL;DR

  • Claude Fable 5 を利用するには、prompt と completion を 30 日間保持する必要があります。この要件は Claude API、AWS Bedrock、Google Vertex AI、Microsoft Foundry に適用されます（ポリシー発効日 2026-06-09）。
  • オプトアウトはありません。ゼロデータ保持契約下の組織には 400 invalid_request_error が返り、既存の ZDR 条項は引き継がれません。
  • Bedrock では Fable 5 に data_retention_mode: provider_data_share が必要です。設定しない場合、モデルは利用不可と表示されます。
  • Usage Policy 違反の可能性があると判定された内容は、30 日間の保持期間とは別に、最大 2 年間保持される場合があります。

ポリシーの詳細は、2026-06-12 時点で Anthropic、AWS、Google、Microsoft の公開ドキュメントと照合しています。ポリシーは変更されるため、リンク先の一次資料と自社の契約を確認してください。本記事は engineering 上の概要であり、法的助言ではありません。

ポリシーの内容

Anthropic は Claude Fable 5 と Claude Mythos 5 を対象モデルに指定しています。API のデータ保持に関するドキュメントとMythos クラスモデルのデータ保持方針によると、2026-06-09 以降は次のとおりです。

  • Prompt と completion は 30 日間保持された後、自動的に削除されます。ただし、進行中の安全性調査の対象になった場合や、法令上の保持義務がある場合を除きます。
  • オプトアウトはありません。 データ保持はモデルの利用条件です。保持設定が要件を満たしていない組織からリクエストすると、400 invalid_request_error が返ります。
  • アクセスは意図的に厳しく制限されています。 データは自動 safety system で screening され、flag が付いた会話を確認できるのは、承認済みの少人数の担当者だけです。担当者はデータを export、copy、download できず、すべてのアクセスが改ざん防止 log に記録されます。
  • 既存の ZDR 契約は、対象モデルへの traffic には適用されません。Cloud platform 経由でも同様です。

Consumer plan の Claude Free／Pro／Max には影響しません。これらは従来から、それぞれの保持条件で運用されています。今回のポリシーが対象にするのは commercial API です。「データを一切保持しない」という保証が設定されることの多い領域です。

30 日間の保持期間が必要な理由

対象モデルの記事では、理由が明確に説明されています。これらのモデルは software engineering、agentic workflow、cybersecurity の能力が大幅に向上しており、**「一部の不正利用は、多数のリクエストを横断しなければ検出できない」**ためです。例として挙げられている best-of-N jailbreaking や国家支援型 espionage は、個々の prompt だけなら問題がないように見え、連続した request を見て初めて攻撃だと判断できる pattern です。削除済みの request から sequence を検出することはできません。

この保持期間について、次の 2 点は誤解されがちです。

  • Training data ではありません。 Anthropic は、明示的な許可がない限り、保持したデータを training に使用しないとしています。目的はあくまで不正利用の検出です。
  • 保持自体が新しいのではなく、強制される点が新しいのです。 約 30 日間の abuse monitoring は、業界で以前から標準的に使われています。OpenAI は API の abuse log を最大 30 日間保持し、承認を受けた組織には ZDR を提供しています。Azure OpenAI も、modified abuse monitoring の承認がない限り、prompt を最大 30 日間保存します。変わったのは、特定のモデルクラスではこの期間を拒否できなくなったことです。従来は、どの provider にもゼロ保持を選べる手段がありました。

以前から存在する注意点もあります。Anthropic は ZDR のもとでも safety classifier の結果を保持し、Usage Policy 違反の可能性があると判定された内容は最大 2 年間保持する場合があります。ゼロデータ保持は、文字どおり一切のデータを保持しないという意味ではありません。通常経路で flag が付かなかった内容を保持しないという意味です。

同じ要件でも cloud ごとに仕組みが異なる

保持要件はモデルを実行するすべての環境に適用されます。ただし、オプトインの実装は platform ごとに異なります。この違いによって、データの処理主体と control の配置場所が決まります。

Platformオプトイン方法適用範囲オプトインしない場合
Claude APIPrivacy controls で 30 日間の保持を有効化Organization または workspace400 invalid_request_error
AWS Bedrockdata_retention_mode: provider_data_shareAccount または projectモデルが unavailable と表示され、request が拒否される
Google Vertex AIAnthropic data sharing と Model Garden の利用条件Project有効化するまで request が拒否される
Microsoft FoundryDeployment 時に Anthropic の利用条件へ同意Subscription／deploymentAzure の ZDR program の対象外

AWS Bedrock は、最も明示的な実装です。データ保持は設定可能な modeであり、default／provider_data_share／none から選びます。設定は project、account、model default の順で解決されます。Fable 5 の宣言は allowed_modes: ["provider_data_share"] です。Prompt と completion は Anthropic と共有され、最大 30 日間保持されます。それ以外の mode では次のようになります。

{
  "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 condition key に SCP を設定すれば、組織全体の方針を強制できます。新しいモデルを試すために、誰かが account 設定をひそかに変更する事態を防げます。Cross-region inference では、保持される copy は送信先 region に置かれます。Data residency に関する契約がある場合は、この点が重要です。

Google Vertex AI では、project 単位の Anthropic data-sharing 設定と、Model Garden での利用条件への同意が必要です。Google の Fable 5 ドキュメントにあるとおり、設定には setPublisherModelConfig と dataSharingEnabledProvider: "anthropic" を使用します。一般的なデータ処理には、Vertex AI の data governance policyが適用されます。Data residency が重要な workload では、Vertex の regional endpoint と multi-region endpoint によって inference の実行場所を制御します。今後は、その場所に保持 copy も置かれます。

Microsoft Foundry は構造が異なります。Microsoft のデータと privacy に関するドキュメントには、Claude model が third-party marketplace service であると明記されています。Deployment 時に Anthropic の利用条件へ同意し、データ処理者になるのは Microsoft ではなく Anthropic です。Azure OpenAI の ZDR program と modified-abuse-monitoring program は、Claude deployment には適用されません。他の環境で ZDR を採用している組織は通常、対象モデル専用の subscription を用意します。保持の境界を手続きではなく構造で分離するためです。

3 つの platform に共通するのは、保持クラスが機械的に判定可能な第一級のモデル属性になったことです。契約書の一文ではなく、mode、flag、利用条件への同意として表現されます。Infrastructure でデータ保持方針を強制できるようになった以上、実際に強制すべきです。

Enterprise deployment への影響

ZDR 契約がない場合、仕組み上の変更はありません。認識していなかったとしても、すでに 30 日程度の保持を前提とした運用になっていました。必要なのは、その事実を vendor 関連の文書に明記することです。

ZDR 契約がある場合、選択肢は 3 つです。

  1. 対象モデルを使わない。 ZDR を一律に維持する代わりに、そのモデルを諦めます。Workload にモデルが不要なら現実的です。コストと違いについては、Fable 5 の実測評価を参照してください。
  2. Workspace または project を分ける。 どの platform でも、限定された範囲でオプトインできます。Claude API なら専用 workspace（Console → Settings → Workspaces → Privacy controls）、Bedrock なら provider_data_share を設定した project、Vertex なら別 project、Azure なら別 subscription を使います。データ保持を許容できる workload だけを routing します。
  3. 組織全体で保持を受け入れる。 運用は最も簡単ですが、ZDR が必要なほど機密性の高い workload を含め、すべての workload に対する保証が暗黙に引き下げられます。単なる config 変更ではなく、データ保護責任者が判断すべき事項です。

Provider にかかわらず、自社の logging も別の保持経路です。 Gateway や observability stack が prompt 全文を記録しているなら、provider より長い期間、自社環境で保持していることになります。Provider の保証が意味を持つかどうかは、その手前の layer 次第です。Cache に関する主張の監査で使ったのと同じ考え方が、ここにも当てはまります。

Consumer 向け product への影響

Consumer に service を提供し、その内容を対象モデルへ routing する場合、ZDR 契約の有無にかかわらず、自社の法的対応にも影響します。具体的な影響は 3 つあります。

1．Privacy notice の更新が必要になる可能性が高い。 多くの法制度では、収集だけでなく保持についても開示が必要です。GDPR 第 13 条 2 項 a 号では、収集時に保存期間またはその決定基準を提示する必要があります。California の CPRA では、収集時の notice に個人情報の category ごとの保持期間を記載する必要があります。会話データがどこにも保持されないと明記または暗示している場合、processor が 30 日間 copy を保持すれば、その説明は事実と異なります。Notice、処理活動記録、DPA inventory を更新してください。

2．自社に存在しないオプトアウトを user に提供することはできない。 保持には例外の仕組みがないため、そのモデルを使いながら特定 user の prompt だけを除外する toggle は作れません。実際に制御できるのは routing です。Consent-aware gateway を使い、データ共有を拒否した user は ZDR 対応モデルへ、それ以外は対象モデルへ送ります。法的制約を通常の routing rule として扱う方法です。何も変えない preference checkbox よりはるかに適切です。

3．削除 request の処理経路を正確に整備する必要がある。 消去義務は、GDPR 第 17 条、CPRA の削除権、その同等制度を含めて processor にも及びます。30 日以内に自動削除される有限の保持期間は、通常、processor の対応として説明可能です。ただし DSAR の運用手順には、その事実を記載する必要があります。実行できない即時の downstream 削除を約束してはいけません。

この問題は世界各国に広がります。同様の開示と processor に関する考え方は、UK GDPR、Brazil の LGPD、増え続ける US 州 privacy law にも見られます。China の user には PIPL による追加の要件があります。個人情報を別の processor に提供する場合、通常は個別の同意が必要です。また、中国の user の内容を海外の LLM endpoint へ routing することは cross-border transfer に該当し、security assessment、standard contract、certification のいずれかの公認された仕組みが必要です。誰が何を、どこで、どれだけ保持するかが変わる model upgrade は、まさにこれらの制度が文書の見直しを求める変更です。

機密データを扱う業界：30 日間の保持が最も重く響く領域

多くの product では、provider による保持期間は文書上の問題です。データ自体が規制対象となる業界では、アーキテクチャの問題になります。Vendor に保持された copy は、規制対象データが保存された状態に相当し、業界固有の規則が直接適用されます。

Healthcare（HIPAA）

HIPAA はゼロ保持を要求していません。Protected health information を保持する vendor に対し、適切な safeguard を定めた **Business Associate Agreement（BAA）**のもとで取り扱うことを求めています。Prompt の 30 日間の copy は、business associate が保存する PHI です。問題は、その保持が BAA の対象に含まれているかどうかです。主要な 2 つの API vendor は異なる構造を採用しており、今回その違いが重要になりました。Anthropic の HIPAA 対応 API accessでは、ZDR は明示的に必須とされていません。Encryption、access control、audit logging、機能制限の強制といった safeguard を備えた、保持を前提とする設計です。OpenAI の API BAAは、ゼロデータ保持に対応する endpoint を対象とします。ZDR endpoint に限定した BAA では、保持を必須とするモデルを構造上カバーできません。

モデルの保持クラスは、BAA の適用可否を左右する条件になりました。 PHI を routing する前に、該当モデルが BAA の対象であることを書面で確認してください。Cloud を使う場合は処理主体の chain も変わります。Bedrock では platform が business associate になり、Foundry では Anthropic がデータを直接処理します。注意すべき点として、structured output の JSON schema definition に PHI を含めてはいけません。Cache された schema には、message content と同じ保護が適用されないためです。

子ども向け product（COPPA）

時期も難しいところです。FTC の改正 COPPA Ruleは 2025 年 6 月 23 日に発効し、大半の規定の compliance 期限は 2026 年 4 月 22 日でした。Operator が新しい保持義務への対応を終えた直後に、provider 側での保持が必須となる最初のモデルが登場したことになります。新しい義務のうち、2 つが 30 日間の保持に直接関係します。書面による公開データ保持ポリシーが §312.10 で必須となり、収集する子どものデータ、収集理由、削除時期を記載する必要があります。また、無期限の保持は禁止され、収集目的のために合理的に必要な期間だけ保持できます。

30 日間に限定され自動削除される仕組みは、形式上は両立可能です。ただし、provider が保持する目的は provider 自身の trust and safety であり、自社が子どものデータを収集した目的とは異なります。Notice には processor との関係を正確に記載する必要があります。Data trail を最小化する目的で ZDR を採用した子ども向け product では、routing の判断がさらに重要です。子どもの traffic は ZDR 対応モデルに限定するか、対象モデルの保持期間を事前に §312.10 の policy に追加する必要があります。

他の業界でも同じ構造が繰り返される

規制対象データが vendor に copy として保持され、その保持を業界規則が制約するという構造は、さまざまな分野で繰り返されます。

  • Biometrics（Illinois BIPA）： Operator は、biometric data に関する書面の保持 schedule と廃棄基準を公開する必要があります。Biometric identifier を含む prompt が provider に 30 日間保持されるなら、その copy も schedule に含める必要があります。
  • Payments（PCI DSS／GLBA）： PCI DSS では、authorization 後の sensitive authentication data を保存することが禁じられています。Prompt に貼り付けた card data は、provider に 30 日間保持される card data です。適切な対策は downstream の文書整備ではなく、upstream での redaction です。
  • Education（FERPA）： School-official exception に基づいて student record を扱う vendor は、学校の直接的な管理下に置かれる必要があります。学校が access できず、期限前に削除することもできない safety-retention copy は、この基準との整合性に疑問が残ります。EdTech traffic を対象モデルへ送る前に、法律の専門家へ確認すべきです。
  • Financial services における逆方向の要件（SEC／FINRA）： Broker-dealer は books-and-records rule により、business communication を保持する必要があります。この業界では provider の保持期間が問題なのではなく、自社で compliance 要件を満たす copy を確保することが課題です。同じ保持の問題でも、方向が逆です。

共通するのは、業界規則が保持を増やす方向にも減らす方向にも作用することです。自社で制御できない provider 側の保持期間を、業界固有の方向に合わせて整理する必要があります。

判断用 checklist

  • ✅ Traffic が実際に触れるモデルを洗い出す。 保持クラスは provider 単位ではなく、model 単位の属性になりました。
  • ✅ ZDR を利用している場合は明示的に選択する。 対象モデルを使わない、workspace／project／subscription を分ける、組織全体で保持を受け入れる、のいずれかです。暗黙のまま適用させてはいけません。
  • ✅ 方針は infrastructure で強制する。 Bedrock SCP、workspace privacy control、分離した cloud project を使い、wiki page に書くだけで済ませないでください。
  • ✅ B2C では privacy notice と DSAR の運用手順を更新する。 機能しないオプトアウトを作るのではなく、同意しない user を ZDR 対応モデルへ routing します。
  • ✅ 規制対象データについては、model ごとの適用範囲を書面で確認する。 PHI なら BAA、子どものデータなら §312.10 policy、biometrics なら保持 schedule を確認した後で、保持必須モデルへ routing してください。
  • ✅ 自社の logging を監査する。 Gateway が prompt を無期限に記録しているなら、provider の 30 日間という制限に意味はありません。

結論

Fable 5 に設定された 30 日間の保持は、データ収集を目的としたものではありません。期間と目的を限定した abuse monitoring であり、業界の大半が標準で行ってきた運用と同じです。Request を横断した不正利用の検出は、削除済みのデータでは機能しないため、特定のモデルクラスで必須になりました。多くのチームでは engineering 上の影響はなく、governance 上の対応も vendor review に一段落を追加する程度です。

一方、ZDR 対象の BAA、データが残らないと説明する privacy notice、data minimization を前提に設計した子ども向け product など、compliance の前提をゼロ保持に置いていた組織では状況が異なります。Fable 5 によって、保持条件はモデル間で一律ではなくなりました。解決策はモデルを避けることではありません。価格やコンテキストウィンドウと同じように、model ごとの保持クラスを routing の明示的な入力条件として扱うことです。

FAQ

Claude Fable 5 はゼロデータ保持契約のもとで利用できますか？ いいえ。Fable 5 と Mythos 5 は、30 日間の保持を必須とする対象モデルです。ZDR 組織が利用するには、workspace で 30 日間の保持を有効にし、Fable 5 の traffic をそこへ routing する必要があります。それ以外の場合は 400 invalid_request_error が返ります。

AWS Bedrock、Vertex AI、Microsoft Foundry を経由すれば、この要件を回避できますか？ できません。どの platform でも、それぞれの方法で保持へのオプトインが必要です。Bedrock では provider_data_share、Vertex では Anthropic data sharing と Model Garden の利用条件への同意、Foundry では deployment 時の Anthropic 利用条件への同意が必要です。Foundry でデータ処理者になるのは Microsoft ではなく Anthropic です。既存の ZDR 契約は、いずれの platform にも引き継がれません。

End user は保持をオプトアウトできますか？ できません。オプトアウトの仕組みはありません。制御できるのは routing です。データ共有を拒否した user は ZDR 対応モデルへ送ってください。何も変化しない preference toggle を提供してはいけません。

保持されたデータはモデルの training に使われますか？ Anthropic は、明示的な許可がない限り、保持データを training に使用しないとしています。目的は trust and safety の review です。自動 screening を行い、flag が付いた会話は承認済みの担当者だけが確認できます。担当者はデータを export できず、access は改ざん防止 log に記録されます。

30 日間の保持によって prompt caching の動作は変わりますか？ 変わりません。Cache entry には個別の短い TTL（5 分または 1 時間）があり、Fable 5 の caching contract に変更はありません。実測評価を参照してください。30 日間の保持は safety review のために並行して行われる別の処理です。

関連記事：Prompt caching 完全ガイドでは、保持ポリシーと関係する cache の仕組みを解説しています。Platform 別 pricingでは、各モデルの provider list price を確認できます。

出典

すべて 2026-06-12 に確認済みです。ポリシーは変更されるため、最新の文書と自社の契約を確認してください。法的助言ではありません。

← ブログに戻る