Amazon Bedrock のゼロデータ保持の強制方法

本ブログは 2026 年 7 月 7 日に公開された AWS Blog “Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies” を翻訳したものです。

Claude Fable 5 のように、サードパーティープロバイダーとのデータ共有を必要とするモデルの登場により、組織にはデータ保持ポリシーを一元的に適用する方法が求められています。Amazon Bedrock では、推論リクエストの完了後にプロンプトとモデル出力を保持するかどうかを制御できます。すべてのアカウントに保持設定を適用しつつ、選択したモデルが対応している場合にはプロジェクト単位でデータ保持をきめ細かく制御したい、というケースもあるでしょう。

本記事では、Amazon Bedrock のデータ保持モードの仕組み、保持を管理するために利用できるツール (Amazon Bedrock Projects やサービスコントロールポリシー (SCP) など)、およびポリシー設定が正しく機能していることを検証する方法を説明します。

本記事では、以下の内容を取り上げます。

Amazon Bedrock のデータ保持モードの仕組みと、各モードがデータに対して何を意味するか
互換性のあるモデルで Amazon Bedrock Projects を使用して、保持要件が異なるワークロードを分離する方法
組織内の誰もデータ共有を有効にできないようにする SCP の作成とデプロイの方法
データ保持モードとクロスリージョン推論プロファイルの相互作用
設定が正しく機能していることを検証する方法

データ保持モードを理解する

Amazon Bedrock では、アカウントのモード設定を通じてデータ保持を制御できます。この設定は、各推論リクエストの後にプロンプトと出力がどのように扱われるかを決定するものであり、コンプライアンス要件を評価するうえで理解しておくことが重要です。すべてのモデルがデータ保持やデータ共有を必要とするわけではなく、これらを必要としないモデルで Amazon Bedrock を引き続き利用することもできます。データ保持またはデータ共有を必要とするモデルの最新リストについては、「Amazon Bedrock ドキュメント」を参照してください。最終的には、コンプライアンス要件に合致するモデルを選択することはお客様の責任となります。

重要な注意事項: 児童性的虐待コンテンツ (CSAM) の拡散を防止するため、Amazon Bedrock は自動化されたメカニズムを使用して、モデルの入力/出力に含まれる CSAM を特定します。モードが none の場合でも、フラグが付けられたコンテンツを保存および確認し、報告目的で CSAM に該当するかどうかを判断することがあります。

以下のモードによって、Amazon Bedrock がデータをどのように扱うかが決まります。

モード	動作	プロバイダーとのデータ共有
`none`	ゼロデータ保持。プロンプトとレスポンスは処理後、直ちに破棄されます。	なし
`default`	モデルプロバイダーとデータは共有されません。一部のモデルでは、信頼と安全性のチェックのために最大 30 日間のデータ保持が必要になる場合があります。詳細は各モデルの利用条件を確認してください。このモードでは、本質的に保持を必要とする API (例: Batch API、store=true を指定した Responses API) も使用できます。ゼロデータ保持をサポートするモデルは、引き続きゼロデータ保持で動作します。	なし
`inherit`	明示的な設定は適用されず、1 つ上のスコープに従います (プロジェクトはアカウントに、アカウントはサービスのデフォルトに従います)。新しいアカウントのデフォルトはこのモードです。	なし
`provider_data_share`	データは信頼と安全性のために最大 30 日間保持され、モデルプロバイダーと共有される場合があります。	あり

モードは下限ではなく上限であることを理解する

最も重要な概念は、設定したモードは許容できる保持の上限であり、すべてのリクエストがそのモードで動作するわけではないという点です。アカウントを provider_data_share に設定しても、すべてのリクエストが突然データの保持や共有を始めるわけではありません。ゼロデータ保持をサポートするモデルは、アカウントレベルの設定にかかわらず、引き続きゼロデータ保持で動作します。

アクセス許可の上限として考えてみましょう。

アカウントのモード	呼び出すモデル	動作
`provider_data_share`	Claude Sonnet (none をサポート)	ゼロデータ保持。Sonnet はデータ共有もデータ保持も必要としません。
`provider_data_share`	Claude Fable 5 (`provider_data_share` が必要)	データは最大 30 日間保持され、プロバイダーと共有される場合があります。Fable 5 はデータ共有とデータ保持を必要とします。
`none`	Claude Sonnet (`none` をサポート)	ゼロデータ保持、データ共有なし
`none`	Claude Fable 5 (`provider_data_share` が必要)	ブロックされます。上限がモデルの要件を下回っているため、このモデルの呼び出しは拒否されます。
`default`	Claude Sonnet (`none` をサポート)	ゼロデータ保持。Sonnet はゼロデータ保持をサポートしており、データ保持もデータ共有もありません。
`default`	安全性チェックのために保持を必要とするモデル	データは保持されます。モデルが保持を必要としており、上限がそれを許可しているためです。

重要なポイント: モード設定は、許容するデータ保持の最大レベルを宣言するものです。ゼロデータ保持をサポートするモデルは、アカウント設定にかかわらず、引き続きゼロデータ保持で動作します。Amazon Bedrock は、アカウントのモードが許可しているという理由だけで、必要以上のデータ保持が発生しないように設計されています。

重要: provider_data_share はモデルから継承されるものではなく、アカウントまたはプロジェクトレベルでの明示的なオプトインです。アカウントが inherit または default に設定されている場合、アカウントまたはプロジェクト内で設定しない限り、どのモデルを使用してもプロバイダーとのデータ共有が行われることはありません。

注: inherit の動作について: inherit モードは、階層の 1 つ上のスコープに従います (プロジェクトはアカウントに、アカウントはサービスのデフォルトに従います)。プロジェクトが inherit に設定され、その上のアカウントが provider_data_share に設定されている場合、プロジェクトは provider_data_share を継承します。モデルから provider_data_share を継承することはなく、アカウントまたはプロジェクトレベルでの明示的な設定が必要です。

注: 保持を必要とする API について: 一部の Amazon Bedrock API は、モデルのサポート状況にかかわらず、動作にデータ保持を必要とします。例えば、Batch API と store=true を指定した Responses API が該当します。モードを none に設定すると、これらの API はブロックされますが、これは想定どおりの動作です。上限が none であるということは保持を一切許容しないという意味であり、保持を必要とする API は利用できなくなります。

なぜ `provider_data_share` が存在するのか

一部の基盤モデルは、動作に provider_data_share モードを必要とします。AI モデルの進化に伴い、お客様と、お客様による安全な利用を保護するメカニズムも進化していく必要があります。provider_data_share を必要とするモデルには allowed_modes: ["provider_data_share"] が設定されており、アカウントが明示的にオプトインしない限り、利用不可として表示されます。これは意図的な設計です。AWS では、お客様がこれらのモデルを使用する前に、データを共有するという意識的な決定を行うことを求めています。Amazon Bedrock で利用可能なモデルとその保持要件については、「現在のモデルリスト」を参照してください。この内容は新しいモデルのリリースに伴い変わる可能性があります。

規制要件、社内ポリシー、またはお客様への約束事項により、サードパーティーのモデルプロバイダーとのデータ共有が禁止されている場合は、複数のレベルでこれを強制できます。Amazon Bedrock は、きめ細かいプロジェクトレベルの設定から組織全体での強制まで、データ保持を管理するための複数のツールを提供しています。

データ保持を管理するためのツール

Amazon Bedrock は、データ保持に対する複数レイヤーの制御手段を提供しています。これらは個別に使用することも、多層防御のために組み合わせることもできます。

ツール	スコープ	ユースケース
Amazon Bedrock コンソール	アカウントごと、AWS リージョンごと	迅速な設定と可視化。新しい Amazon Bedrock (mantle エンドポイント) コンソールで保持モードを直接表示および変更できます。
Amazon Bedrock Projects	アカウント内のプロジェクトごと	互換性のあるモデルについて、同一アカウント内で保持要件が異なるワークロードを分離
SCP	組織全体	どのアカウントもデータ共有にオプトインできないようにする
IAM ポリシー	アカウントごとまたはプリンシパルごと	管理アカウント (SCP の対象外) を含む、きめ細かい制御

Amazon Bedrock Projects によるきめ細かい制御

アカウント内のすべてのワークロードが同じデータ保持要件を持つとは限りません。bedrock-mantle エンドポイント (OpenAI 互換 API など) を使用している場合、Amazon Bedrock Projects を使用することで、データ保持を許容できるトラフィックと保持してはならないトラフィックを、同じアカウント内であっても分離できます。

例えば、以下のような状況が考えられます。

チームが実験のために最新のモデル (provider_data_share を必要とするモデルを含む) へのアクセスを必要とするリサーチプロジェクト
ゼロデータ保持が必須である、顧客データを扱う本番プロジェクト

Amazon Bedrock Projects を使用すると、リサーチプロジェクトには provider_data_share を設定しながら、本番プロジェクトは none にロックしたままにできます。各プロジェクトは、それぞれ独立して保持の上限を強制します。

プロジェクトレベルの保持の仕組み:

各プロジェクトは、それぞれ独自のデータ保持モードを設定できます
inherit に設定されたプロジェクトは、アカウントレベルからモードを継承します
none に設定されたプロジェクトは、アカウント設定にかかわらずゼロデータ保持を強制します。そのプロジェクトを経由するトラフィックでデータ共有が行われることはありません
provider_data_share に設定されたプロジェクトは、データ共有を必要とするモデルを許可しますが、そのプロジェクト内のリクエストに限られます

これにより、組織は機密性の高いワークロードに対して厳格なデータガバナンスを維持しながら、新しいモデルを段階的に導入する柔軟性を得られます。プロジェクト設定は、Amazon Bedrock コンソールまたは bedrock-mantle API を使用して管理できます。

重要: Amazon Bedrock Projects は bedrock-mantle エンドポイントでのみ利用可能です。mantle エンドポイント上の OpenAI 互換 API (Responses、Chat Completions) および Anthropic Messages API を使用してアクセスするモデルで動作します。すべてのモデルが bedrock-mantle で利用できるわけではありません。最新のサポート状況については、「モデルごとのエンドポイントの可用性」ページを確認してください。

bedrock-runtime エンドポイントでのワークロードの分離

bedrock-runtime エンドポイント (Invoke、Converse API) を使用している場合、プロジェクトレベルのデータ保持は利用できません。bedrock-runtime を通じて行われるすべてのリクエストには、アカウントレベルの保持モードが適用されます。

bedrock-runtime でワークロードレベルの分離を実現するには、別々の AWS アカウントを使用してください。

provider_data_share を必要とするワークロードは、SCP を適用しないアカウント (または OU) に配置します
ゼロデータ保持を必要とするワークロードは、SCP を適用した別のアカウント (または OU) に配置します

AWS Organizations の OU を使用して、保持ポリシーごとにアカウントをグループ化し、SCP を選択的に適用できます。

Organization Root
├── OU: Zero-Retention (SCP attached — blocks provider_data_share)
│   ├── Account: Production-App-A
│   └── Account: Production-App-B
└── OU: Research (no SCP — allows provider_data_share)
    └── Account: ML-Experimentation

プロジェクトと SCP の組み合わせ: SCP を使用して組織レベルで none を強制すると、bedrock-mantle 上のすべてのプロジェクトレベル設定より優先されます。プロジェクトレベルの柔軟性が必要なアカウントには SCP を適用せず、代わりにプロジェクトレベルの分離を使用してください。いかなる状況でもデータ共有を許可してはならないアカウントに対しては、SCP を使用することで、両方のエンドポイントにおいて回避不可能な保証が得られます。

SCP による組織全体での強制

誰が管理者アクセス権を持っていても、どのエンドポイントを使用していても、どのアカウントもデータ共有を有効にできないという絶対的な保証が必要な組織にとって、SCP は最も強力な強制メカニズムです。SCP は、Amazon Bedrock コントロールプレーン (bedrock:PutAccountDataRetention) と mantle エンドポイント (bedrock-mantle:PutAccountDataRetention、bedrock-mantle:CreateProject、bedrock-mantle:UpdateProject) の両方に適用されます。

SCP によるゼロデータ保持の強制

このセクションでは、SCP を使用してデータ保持ポリシーを管理する方法を説明します。まず SCP とは何かを紹介し、続いて組織で使用できるポリシーの例をいくつか示します。

SCP とは

サービスコントロールポリシー (SCP) は、組織レベルで設定されるガードレールです。アカウント管理者やルートユーザーを含む、組織内のすべてのプリンシパルより優先されます。たとえフル管理者権限を持っていても、SCP による拒否を AWS Identity and Access Management (IAM) ポリシーで上書きすることはできません。

SCP は AWS Organizations で管理され、以下のさまざまなレベルにアタッチできます。

ルート – 組織内のすべてのアカウントに適用されます
組織単位 (OU) – その OU 内のすべてのアカウントに適用されます
個別のアカウント – その特定のアカウントにのみ適用されます

重要: すべてのアカウントをカバーするには、SCP をルート OU にアタッチする必要があります。子 OU にアタッチした場合、その OU の外にあるアカウントは保護されません。また、組織の管理アカウントには SCP による制御は適用されません。

SCP ポリシー

以下のポリシーを使用すると、組織内の誰も Amazon Bedrock のデータ保持モードを none 以外に変更できなくなります。

重要: 新しいアカウントのデフォルトは inherit です (none ではありません)。この SCP をアタッチする前に、各アカウントを明示的に none に設定する必要があります。まず、各アカウントで以下を実行してください。

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

数百、数千の AWS アカウントを持っている場合は、この作業をスケールさせる方法が必要になります。その方法については、AWS re:Post の記事「Automate Bedrock Zero Data Retention Across All Accounts in Your Organization」を参照してください。

Amazon Bedrock ポリシー:

このポリシーは、データ保持を none にのみ設定できるように制限するために使用します。none 以外の値は拒否されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RESTRICTBEDROCKDATARETENTION",
            "Effect": "Deny",
            "Action": [
                "bedrock:PutAccountDataRetention"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "bedrock:DataRetentionMode": "none"
                }
            }
        }
    ]
}

仕組み

Condition ブロックでは StringNotEquals を使用しており、none 以外の値に対して拒否が発動します。これにより、以下が保証されます。

アクション	結果
モードを `none` に設定	許可
モードを `provider_data_share` に設定	SCP により拒否
モードを `default` に設定	SCP により拒否
モードを `inherit` に設定	SCP により拒否

この設定が組織にとって意味することは、以下のとおりです。

誰もモデルプロバイダーとのデータ共有を有効にできない – アカウント管理者であっても Access Denied を受け取ります
provider_data_share を必要とするモデルは恒久的に利用不可になる – データ共有を必要とするモデル (Claude Fable 5 や Claude Mythos 5 など) は組織全体で動作しなくなります
その他のすべてのモデルは引き続き通常どおり動作する – none モードをサポートするモデルは影響を受けません
この設定は回避できない – IAM ポリシーで SCP の deny を上書きすることはできません

オプション: プロジェクトレベルの上書きをブロックする

bedrock-mantle エンドポイントは、プロジェクトレベルのデータ保持設定をサポートしています。追加の SCP でカバーしない場合、誰かが provider_data_share を設定したプロジェクトを作成または更新することで、アカウントレベルの制限を回避できてしまいます。これを防ぐには、SCP を拡張して bedrock-mantle のプロジェクトアクションを含めます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RESTRICTBEDROCKDATARETENTION",
            "Effect": "Deny",
            "Action": [
                "bedrock:PutAccountDataRetention",
                "bedrock-mantle:PutAccountDataRetention",
                "bedrock-mantle:CreateProject",
                "bedrock-mantle:UpdateProject"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "bedrock:DataRetentionMode": "none"
                }
            }
        }
    ]
}

なぜ bedrock-runtime にはプロジェクトレベルのブロックが不要なのか？bedrock-runtime エンドポイントにはプロジェクトが存在しません。bedrock-runtime のトラフィックの保持設定を変更する唯一の方法は、アカウントレベルの bedrock:PutAccountDataRetention アクションであり、これは基本の SCP で既にブロックされています。追加の CreateProject と UpdateProject アクションが必要なのは、bedrock-mantle がプロジェクトごとの保持設定の上書きを許可しているためであり、bedrock-runtime ではプロジェクトレベルの制御は必要ありません。

データ保持とクロスリージョン推論

クロスリージョン推論プロファイルを使用する場合、データ保持モードがどのように評価されるかを理解しておくことが重要です。モードは、リクエストのソースリージョン、つまり API コールを行う AWS リージョンで評価されます。すべてのデスティネーションリージョンで保持モードを設定する必要はありません。

ただし、重要な注意点があります。モードのチェックはソースリージョンで行われますが、データ自体は推論が処理されるデスティネーションリージョンで保持される可能性があります。これは、保持されたデータが地理的にどこに存在するかを追跡している組織にとって重要なポイントです。

実際には何を意味するか

データ保持と推論が実際にどのように動作するかを、以下に示します。

ソースリージョン (例: us-east-1) が provider_data_share に設定されている場合、クロスリージョン推論プロファイルを使用するリクエストは、デスティネーションリージョンの保持設定にかかわらず許可されます
ソースリージョンが none に設定されている場合、provider_data_share を必要とするモデルへのリクエストは、デスティネーションリージョンにルーティングされる前に、ソース側でブロックされます
SCP は引き続きグローバルに適用されます。ルート OU の単一の SCP により、すべてのリージョンで provider_data_share が自動的にブロックされます

SCP はグローバルに適用される

データ保持設定はきめ細かい制御に役立ちますが、SCP を使用すれば、すべてのリージョンにわたってデータ保持の制限をグローバルに自動適用できます。ルート OU にアタッチされた単一の SCP により、リージョンごとに設定を行うことなく、すべてのリージョンで provider_data_share がブロックされます。これが、手動設定に頼るのではなく SCP を強制手段として使用することの主な利点の 1 つです。

設定を検証する

データ保持設定と SCP の強制は、AWS SDK、AWS コマンドラインインターフェイス (AWS CLI)、または Amazon Bedrock コンソールを使用して検証できます。

現在の保持モードを確認する

現在の保持モードは、以下の方法で確認できます。

Amazon Bedrock コンソールを使用する場合:

AWS マネジメントコンソールで新しい Amazon Bedrock (mantle エンドポイント) コンソールに移動し、[設定] を選択してから、[データ保持] を選択します。ここで、現在のアカウントレベルの保持モードを確認し、直接変更できます。

訳注: bedrock-runtime 経由 (aws bedrock コマンド、Invoke / Converse API) と bedrock-mantle 経由のアカウントレベルのデータ保持モードは、それぞれ独立した設定です。一方を変更しても他方には反映されません。コンソールで変更できるのは mantle 側のみのため、bedrock-runtime のトラフィックを制御するには、別途 aws bedrock コマンドまたは API での設定が必要です。

AWS CLI を使用する場合 (CLI バージョン 2.35 以降が必要):

aws bedrock get-account-data-retention --region us-east-1

想定されるレスポンス:

{
  "mode": "none",
  "updatedAt": "2026-07-01T01:58:34.684Z"
}

bedrock-mantle API を使用する場合 (Amazon Bedrock API キーを使用):

curl https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
	-H "x-api-key: $BEDROCK_API_KEY"

想定されるレスポンス:

{
  "mode": "none",
  "updated_at": 1719792000
}

モデルの有効なモードと許可されているモードを確認する

bedrock-mantle API を使用して、特定のモデルでどの保持モードが有効になっているか、およびそのモデルがどのモードをサポートしているかを確認することもできます。

curl https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-fable-5 \
  -H "x-api-key: $BEDROCK_API_KEY"

レスポンス:

{
  "id": "anthropic.claude-fable-5",
  "status": "available",
  "data_retention": {
    "mode": "provider_data_share",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

モデルが "status": "unavailable" と表示される場合、status_reason フィールドに保持モードの競合に関する説明が表示されます。

SCP が機能していることを検証する

SCP がデータ保持の変更を実際にブロックしていることを確認するには、モードを provider_data_share に設定してみてください。

AWS CLI を使用する場合:

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

bedrock-mantle API を使用する場合:

curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "provider_data_share" }'

SCP が機能している場合、Access Denied エラーが返されます。

An error occurred (AccessDeniedException) when calling the PutAccountDataRetention operation:
User: arn:aws:iam::123456789012:user/admin is not authorized to perform:
bedrock:PutAccountDataRetention with an explicit deny in a service control policy

SCP が機能していない場合、リクエストは成功してしまいます。この場合は、直ちに設定を元に戻してください。

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

その後、SCP のアタッチについて、以下の観点でトラブルシューティングを行います。

SCP が子 OU ではなくルート OU にアタッチされていることを確認する
SCP ポリシーの構文と条件キーを確認する
AWS Organizations の管理アカウントは SCP の対象外であることに注意する。そのアカウントにポリシーを強制するには IAM ポリシーを使用してください

データ保持を必要とするモデルでデータ保持を有効にする

provider_data_share を必要とするモデルを使用したいアカウント (SCP が適用されていないアカウント) では、AWS CLI、API、またはコンソールを使用してモードを設定します。

AWS CLI を使用する場合:

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

bedrock-mantle API を使用する場合:

curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "provider_data_share" }'

新しい Amazon Bedrock (mantle エンドポイント) コンソールの [設定] にある [データ保持] からも設定できます。

データ保持を none に戻す

ゼロデータ保持に戻すには、以下を実行します。

AWS CLI を使用する場合:

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

bedrock-mantle API を使用する場合:

curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "none" }'

プロジェクトレベルのデータ保持を管理する

プロジェクトレベルでデータ保持を設定することで、同じアカウント内の異なるワークロードに異なる保持ポリシーを適用できます。プロジェクトのデータ保持モードを更新するには、bedrock-mantle API を使用します。

# Set a project to provider_data_share
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "data_retention": { "mode": "provider_data_share" } }'

# Set a project to none (zero retention)
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "data_retention": { "mode": "none" } }'

# Check a project's current setting
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY"

プロジェクトレベルの保持の解決方法: リクエストに対する有効なモードは、プロジェクト、アカウント、モデルのデフォルトという階層の中で、最初に見つかった inherit 以外の値によって決まります。プロジェクトが none に設定されている場合、アカウント設定にかかわらずゼロデータ保持が強制されます。プロジェクトが inherit に設定されている場合は、アカウントレベルの設定に従います。

注: プロジェクトレベルのデータ保持は、bedrock-mantle API を通じてのみ管理できます。プロジェクトレベルの設定用の AWS CLI コマンドはありません。前述の AWS CLI コマンドは、Amazon Bedrock コントロールプレーンを通じてアカウントレベルの設定のみを管理します。

まとめ

本記事では、プロジェクトレベルのデータ保持や、SCP を使用して実装できる組織全体での制御など、Amazon Bedrock でデータ保持を管理するさまざまな方法を紹介しました。要件に合った組み合わせを選択し、デプロイ前に Amazon Bedrock のドキュメントで各モデルのモード要件を確認してください。

Amazon Bedrock のデータ保持の詳細については、「データ保持のドキュメント」を参照してください。SCP については、AWS Organizations ユーザーガイドの「サービスコントロールポリシー」を参照してください。

その他のリソース

Amazon Bedrock のデータ保持 – 保持モード、設定、IAM による強制に関する完全なドキュメント
クロスリージョン推論プロファイル – 推論が AWS リージョン間でどのようにルーティングされるかを理解する
Amazon Bedrock の不正使用検出 – 安全性の目的で保持されるデータ
拒否されたリクエストに対するフォールバッククレジット – Fable 5 が Opus 4.8 にフォールバックした場合の請求の仕組み
Claude Fable 5 と Mythos 5 の発表 – 新しいデータ保持ポリシーに関する Anthropic の説明
Anthropic データ処理補遺 – Anthropic と共有されるデータを管理する法的条件
サービスコントロールポリシー (SCP) – AWS Organizations のドキュメント

ぜひ本記事の例をお試しください。フィードバックは、AWS re:Post for Amazon Bedrock または通常の AWS サポートの窓口を通じてお寄せください。

Amazon Web Services ブログ

Amazon Bedrock のゼロデータ保持の強制方法

データ保持モードを理解する

モードは下限ではなく上限であることを理解する

なぜ `provider_data_share` が存在するのか

データ保持を管理するためのツール

Amazon Bedrock Projects によるきめ細かい制御

bedrock-runtime エンドポイントでのワークロードの分離

SCP による組織全体での強制

SCP によるゼロデータ保持の強制

SCP とは

SCP ポリシー

仕組み

オプション: プロジェクトレベルの上書きをブロックする

データ保持とクロスリージョン推論

実際には何を意味するか

SCP はグローバルに適用される

設定を検証する

現在の保持モードを確認する

モデルの有効なモードと許可されているモードを確認する

SCP が機能していることを検証する

データ保持を必要とするモデルでデータ保持を有効にする

データ保持を none に戻す

プロジェクトレベルのデータ保持を管理する

まとめ

その他のリソース

お役立ちリンク

フォローお願いいたします

学ぶ

リソース

デベロッパー

ヘルプ

Amazon Web Services ブログ

Amazon Bedrock のゼロデータ保持の強制方法

データ保持モードを理解する

モードは下限ではなく上限であることを理解する

なぜ provider_data_share が存在するのか

データ保持を管理するためのツール

Amazon Bedrock Projects によるきめ細かい制御

bedrock-runtime エンドポイントでのワークロードの分離

SCP による組織全体での強制

SCP によるゼロデータ保持の強制

SCP とは

SCP ポリシー

仕組み

オプション: プロジェクトレベルの上書きをブロックする

データ保持とクロスリージョン推論

実際には何を意味するか

SCP はグローバルに適用される

設定を検証する

現在の保持モードを確認する

モデルの有効なモードと許可されているモードを確認する

SCP が機能していることを検証する

データ保持を必要とするモデルでデータ保持を有効にする

データ保持を none に戻す

プロジェクトレベルのデータ保持を管理する

まとめ

その他のリソース

お役立ちリンク

フォローお願いいたします

学ぶ

リソース

デベロッパー

ヘルプ

なぜ `provider_data_share` が存在するのか