クラウドキャリアフリーランス
技術記事 2026/8/17

Bedrock の Claude Opus 5 は ZDR がデフォルト — それでも SCP で強制すべき理由

Claude Opus 5 が Amazon Bedrock でゼロデータ保持デフォルトで提供開始。ただし新規アカウントの既定値は inherit です。データ保持モードの解決順と、Bedrock Projects・SCP で組織的に強制する設計を公式情報から整理します。

  • #Amazon Bedrock
  • #AWS Organizations
  • #SCP
  • #生成AI
  • #データガバナンス

2026年7月24日、AWS は Claude Opus 5 の提供開始を発表しました。Amazon Bedrock 経由での提供では、ゼロデータ保持(ZDR=プロンプトと応答を保存しない扱い)がデフォルトで有効になっています。規制業種でのAI基盤構築では「モデルに投げたデータが残らないこと」が導入可否そのものを左右するため、この一文の意味は小さくありません。

ただし「デフォルトで有効」は「組織として保証されている」とは別の話です。同じ7月には、Bedrock Projects と Service Control Policies(SCP)を使ってゼロデータ保持を組織的に強制する手順が AWS Security Blog で公開されています。本記事では、Bedrock のデータ保持設定がどう決まるのかを公式ドキュメントから整理したうえで、なぜ強制の仕組みが別途必要になるのかを設計の観点から解説します。

Bedrock のデータ保持設定とは

すでに Bedrock のデータ保持モードを触っている方は、次のセクションまで読み飛ばしてください。

Amazon Bedrock は、推論リクエストのプロンプトと出力を保持するかどうかを利用者が明示的に制御できる仕組みを持っています。公式ドキュメントでは、この設定はアカウント単位またはプロジェクト単位で構成でき、Messages API・Chat Completions API・Responses API のいずれからの呼び出しに対しても一貫して適用される、と説明されています。

重要なのは、これが単純なオン・オフのトグルではなく「モード」で表現されている点です。2026年7月時点で定義されているモードは次の4つです。

モード挙動
noneゼロデータ保持。リクエスト・レスポンスのデータは AWS の永続ストレージに書き込まれず、モデルプロバイダーにも共有されません
defaultモデル自身のデータ保持ポリシーが適用されます。AWS が安全性・不正利用防止の目的でデータを保持する場合がありますが、モデルプロバイダーには渡りません
provider_data_share推論データをモデルプロバイダーの要件に従って保持・共有します。特定のモデルへのアクセスに必要です
inheritこのスコープでは意見を持たず、より広いスコープの判断に委ねます

none を選ぶと Responses API の store パラメータは既定が false になり、store=true は拒否されます。逆に default モードで store=false を指定しても、それだけではゼロデータ保持は保証されません。安全性レビューのためにデータが保持されることがあるためで、保証が要るなら store ではなく data_retention_modenone にする、と公式ドキュメントは整理しています。

実効モードはどう決まるか

4つのモードのうち inherit だけは性質が違います。これは「値」ではなく「判断の委譲」だからです。

データ保持は、プロジェクト(最も具体的)、アカウント、そしてモデル自身の既定値(読み取り専用のフォールバック)という3つのスコープで決まります。あるリクエストに適用される実効モードは、この順に見ていって最初に inherit 以外だった値になります。プロジェクトが inherit でアカウントが none なら、そのプロジェクトから呼ばれるすべてのモデルの実効モードは none です。

データ保持の実効モードがプロジェクト・アカウント・モデル既定の順に解決される流れを示した図
図1: 実効モードは「最初に inherit 以外だった値」で決まる(2026年7月時点)

ここで押さえておきたいのが、新規アカウントおよび新規プロジェクトの既定値は none ではなく inherit だという点です。つまり、組織側が何も設定していないアカウントでは、実効モードはモデル既定にフォールバックします。Claude Opus 5 を Bedrock で呼んだときに ZDR が効くのは、アカウントにゼロデータ保持の設定が入っているからではなく、より広いスコープに何の指定も無いまま、モデル側の既定が採用されている状態だということになります。

この違いはモデルを差し替えた瞬間に表面化します。各モデルは許容するモードを allowed_modes として宣言しており、実効モードがそこに含まれなければ、そのモデルは一覧上 unavailable となりリクエストがブロックされます。公式ドキュメントは Claude Fable 5 と Claude Mythos 5 を allowed_modesprovider_data_share のみの例として挙げています。

Bedrock Projects と SCP で強制する

AWS Security Blog(2026年7月7日公開・Advanced 300 区分)は、この「既定に頼った状態」を組織の統制に変える手順を扱っています。論点は2つです。

ひとつは分離です。Bedrock Projects は、同一アカウント内で異なるデータ保持要件を持つワークロードを分けるための単位で、プロジェクトごとに独立した保持モードを設定できます。研究用途のプロジェクトでは provider_data_share を許容しつつ、本番プロジェクトは none に固定する、といった使い分けが可能になります。ただし Projects は bedrock-mantle エンドポイント上の機能であり、bedrock-runtime エンドポイントには存在しません。対象は OpenAI 互換 API(Responses・Chat Completions)と Anthropic Messages API 経由で呼ぶモデルで、すべてのモデルが bedrock-mantle で使えるわけではない点に注意が要ります。

もうひとつが強制です。データ保持モードを書き換えるアクションは条件キーを公開しており、これを使って none 以外への設定を拒否する SCP を組めます。Bedrock コントロールプレーン向けの例は次の形です。

{
    "Effect": "Deny",
    "Action": [
        "bedrock:PutAccountDataRetention"
    ],
    "Condition": {
        "StringNotEquals": {
            "bedrock:DataRetentionMode": "none"
        }
    }
}

Bedrock Projects まで含めて塞ぐ場合は、対象アクションにプロジェクトの作成・更新(CreateProject / UpdateProject)を加えます。ここで条件キーの名前空間に注意が要ります。公式ドキュメントの例は bedrock-mantle エンドポイントのアクションに bedrock-mantle:DataRetentionMode を添えているのに対し、Security Blog の拡張版ポリシーは同じアクション群に bedrock:DataRetentionMode を添えた形で掲載されています。2026年7月時点で一次情報の記載が分かれているため、適用前に条件が意図どおり評価されるかを確認してください。

SCPでゼロデータ保持を強制する2ステップと、root OUへのアタッチなど3つの注意点を示した図
図2: 全アカウントを明示的に none にしてから SCP をアタッチする

順序も決まっています。Security Blog は、SCP をアタッチする前に各アカウントのデータ保持モードを明示的に none に設定しておくことを前提条件として挙げています。

aws bedrock put-account-data-retention --region us-east-1 --mode none

SCP が止められるのは「これから行われる設定変更」だけで、既存の設定値を書き換えるわけではありません。inherit のまま残っているアカウントは、SCP をアタッチしても none にはならず、実効モードはモデル既定へのフォールバックのままです。「強制した」つもりの状態と、実際に保証されている状態がずれるのはここです。

実務で使うときの注意点

適用範囲の穴に注意してください。SCP は全アカウントを覆うよう root OU にアタッチする必要があり、加えて組織の管理アカウントは SCP の制御を継承しません。管理アカウントから Bedrock を呼ぶ運用が残っていると、統制の外側に経路が1本残ることになります。

ゼロデータ保持が必須の組織が、保持を要求するモデルを使いたい場合は別の経路があります。公式ドキュメントは ZDR アクセスがアカウント単位・モデル単位でモデルプロバイダーと協議のうえ評価される旨を記載しており、AWS のアカウントマネージャーへの相談を案内しています。承認されたアカウントでは、そのモデルの allowed_modesnone が含まれるようになります。

運用面では、提供開始時点でデータ保持を設定するコンソール UI が無く、API または Bedrock SDK からの操作になる点を織り込んでおく必要があります。また、クロスリージョン推論を有効にしている場合、保持されるデータは推論が処理された先のリージョンに保存されます。データの所在地に制約がある案件では、保持モードとクロスリージョン推論の設定を合わせて確認してください。

なお、Claude Fable 5 より前にリリースされた Claude モデルについては、データ保持の扱いに変更はないと公式ドキュメントに明記されています。既存ワークロードの挙動が今回の仕組みで変わるわけではありません。

まとめ

本記事のポイントを3つに整理します。

  1. Claude Opus 5 は 2026年7月24日に Amazon Bedrock で提供開始され、ZDR がデフォルトで有効。Claude Platform on AWS 経由では ZDR はリクエストベースで、既定ではない
  2. Bedrock のデータ保持は4モードで表現され、実効モードはプロジェクト→アカウント→モデル既定の順に最初の非 inherit 値で決まる。新規アカウントの既定は inherit であり、「デフォルトで ZDR」はモデル既定に依存した状態
  3. 組織として保証するには、全アカウントを明示的に none に設定したうえで、条件キーによる Deny の SCP を root OU にアタッチする。SCP は既存値を書き換えず、管理アカウントには継承されない

出典

For Freelancers

AWSフリーランス案件、お探しですか?

案件探しから単価交渉・契約手続き・参画後のフォローまで、専任コンサルタントが伴走します。 お名前とメールだけで、まずは無料でご相談いただけます。

案件を探す