Amazon Bedrockのゼロデータ保持と4つの保持モード

Amazon Bedrock は、推論リクエストの完了後にプロンプトと出力を保持するかどうかを明示的に制御できます。設定はアカウント単位とプロジェクト単位の 2 スコープで構成でき、Messages、Chat Completions、Responses の各 API で一貫して適用されます。この仕組みは、サードパーティのモデルプロバイダーとのデータ共有を要求するモデル（例として Claude Fable 5 や Claude Mythos 5）の登場にともない、組織全体で保持ポリシーを中央集権的に強制する必要性から用意されました。なお Claude Fable 5 より前のモデルは従来の保持挙動が維持されます。

データ保持は単純な on/off トグルではなくモードで制御されます。API のボディでは mode、ドキュメント本文の表記では data_retention_mode というフィールド名で扱われます。4 つのモードの意味と挙動を整理します。

スコープは 3 段で構成されます。最も具体的な Project、次に Account、最後に読み取り専用フォールバックの Model default です。有効モードは project → account → model default の順にたどり、最初に inherit 以外だった値になります。たとえば project が inherit、account が none なら有効モードは none です。

各モデルは、自身が許可するモードを allowed_modes として宣言します。有効モードがそこに含まれない場合、モデルは一覧で unavailable となりリクエストはブロックされます。Claude Fable 5 と Claude Mythos 5 は ["provider_data_share"] のみを許可するため、有効モードが none や default のときは利用できません。逆に provider_data_share へ設定しても全モデルが共有を始めるわけではなく、["default","provider_data_share"] を宣言するモデルは AWS 内でのみ保持されます。

Bedrock Projectsでワークロードごとに保持ポリシーを分離する

Amazon Bedrock Projects を使うと、ワークロードごとに独立した保持モードを設定できます。プロジェクトを none にするとアカウント設定にかかわらずゼロ保持を強制でき、inherit にすればアカウントレベルの設定を継承します。機密性の高いワークロードはゼロ保持、実験的なワークロードは共有を許可する、といった使い分けを 1 つのアカウント内で実現できます。

ただし、このプロジェクト単位の分離は bedrock-mantle エンドポイントでのみ利用でき、bedrock-runtime では利用できません。プロジェクト設定は mantle API で行い、AWS 公式情報では POST /v1/organization/projects/{project_id} の形で設定するとされています。

混在モデルのプロジェクトでは、有効モードとモデルごとの allowed_modes の組み合わせで利用可否が個別に決まります。プロジェクトを provider_data_share にしても、共有を宣言していないモデルは AWS 内での保持にとどまります。プロジェクト設定は許可枠を与えるだけで、実際の共有はモデルの宣言に従います。

bedrock-runtime エンドポイントでワークロードを分離したい場合は、別々の AWS アカウントに分け、OU でグルーピングして SCP を選択的に適用する運用が推奨されています。ゼロ保持を強制する OU には SCP を付与し、共有を許可したい調査用 OU には付与しない、という設計です。

SCPでゼロデータ保持を組織全体に強制する

データ保持ポリシーは、IAM ポリシーまたは SCP（サービスコントロールポリシー）で組織全体に強制できます。書き込み系のアクションが condition キーを発行するため、設定可能なモードを制限できます。基本形は、アカウントレベルの保持モードを none 以外に変更する操作 bedrock:PutAccountDataRetention を StringNotEquals で拒否するものです。プロジェクト作成や更新経由の抜け穴も塞ぐには、次のように 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"
                }
            }
        }
    ]
}

ここで最も注意したいのが condition キーの名前空間です。AWS 公式ブログの例ではすべてのアクションに bedrock:DataRetentionMode を使用しています。一方、公式ドキュメントの例では mantle 系アクションに bedrock-mantle:DataRetentionMode、コントロールプレーン系に bedrock:DataRetentionMode と名前空間を分けています。情報源で表記が異なるため、本記事ではどちらか一方を正解と断定しません。実装前に、対象アクションが実際に発行する condition キー名を IAM の公式リファレンスで確認してください。

付与先にも注意が必要です。SCP はルート OU に付与して全アカウントをカバーします。子 OU にのみ付与すると他のアカウントが未保護のまま残ります。また AWS Organizations の仕様として管理アカウントは SCP 強制の対象外のため、管理アカウント上でワークロードを動かさない運用が安全です。SCP が効いていれば、none 以外への設定を試みたときに AccessDeniedException が返ります。

クロスリージョン推論プロファイルとゼロデータ保持の相互作用

クロスリージョン推論プロファイルを使う場合、保持モードの評価はソースリージョン、つまり API を呼び出したリージョンで行われ、宛先リージョンでは行われません。ソースが none のときは、provider_data_share を要求するモデルへのリクエストは宛先へルーティングされる前にブロックされます。逆にソースが provider_data_share のときは、宛先の設定にかかわらずルーティングが進行します。

ここで見落としやすいのが、データが実際に保持され得る場所です。推論が宛先リージョンで実行される場合、保持対象の入力と出力は宛先リージョンに保存され得るため、地理的なコンプライアンス要件を追跡するうえでは宛先側の保持を意識する必要があります。provider_data_share 対象モデル（現時点では Claude Mythos 5 と Claude Fable 5）では、プロンプトと補完結果が trust & safety の目的で最大 30 日間保持されるとされています。

これらの経路を一律に塞げるのが SCP の強みです。SCP は全リージョンに自動的にグローバル適用されるため、ルート OU に 1 つ付与すれば、クロスリージョン経由の設定変更も含めて全リージョンで provider_data_share をブロックできます。

AWS CLI / API で設定を検証する

設定の確認と検証には AWS CLI と mantle API を使います。AWS 公式ブログでは、アカウントレベルの現在モードを取得するコマンドとして次の形が紹介されており、あわせて新しめの AWS CLI（記載では 2.35 以降）が必要とされています。ただしコマンド名や必要バージョンは情報源で表記差があるため、実行前に AWS CLI リファレンスで確認してください。

# AWS公式ブログで紹介されているコマンド（要確認）
aws bedrock get-account-data-retention --region us-east-1
aws bedrock put-account-data-retention --region us-east-1 --mode none

プロジェクトレベルの設定は CLI では扱えず、mantle API を直接呼び出します。モデルの有効モードと allowed_modes は、次の curl 例のようにモデルのエンドポイントへ問い合わせて確認します。

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

有効モードがモデルの許可リストに含まれない場合、status は unavailable となり status_reason に理由が示されます。レスポンスの data_retention には mode、source、allowed_modes が含まれ、有効モードのスコープ由来とモデルが許可するモードを一目で確認できます。なお updated_at の型はエンドポイントで異なり、mantle は Unix epoch の数値、コントロールプレーンは ISO8601 の文字列で返ります。

SCP の強制が効いているかは、none 以外への設定を試すことで確認します。provider_data_share への変更を試み AccessDeniedException が返れば、組織のガードレールが正しく機能していると判断できます。なお、ローンチ時点ではデータ保持設定用のコンソール UI がないため、確認や設定は API または CLI で行います。

まとめ

Amazon Bedrock のゼロデータ保持は、モードによる制御、Bedrock Projects によるワークロード分離、SCP による組織強制の 3 層を組み合わせることで、中央集権的なデータ保持ガバナンスの型を作れます。4 つのモードの違いと project → account → model default の決定ロジックを押さえ、必要に応じてプロジェクト単位あるいはアカウント分離と OU 運用で分離し、最後にルート OU への SCP で none 以外への変更を全リージョンで拒否する、という流れが基本形です。

実装前に検証すべき項目としては、SCP の condition キー名前空間、CLI のコマンド名と必要バージョン、mantle エンドポイントのパス形式が挙げられます。いずれも AWS の公式リファレンスで最新の表記を確認したうえで適用することをおすすめします。