(GA)組織レベルで生成AI利用の安全を確保するAmazon Bedrock ポリシー

記事タイトルとURLをコピーする

はじめに

こんにちは、久保(賢)です。

2026年4月3日、Amazon Bedrock Guardrails の組織向け保護機能に関するアップデートが公開され、AWS Organizations の Amazon Bedrock ポリシー(policies)で、組織レベルのガードレール適用をより柔軟に制御できるようになりました。

aws.amazon.com

GA後の最新仕様を踏まえつつ、実際の設定手順と、特にハマりやすかったクロスアカウント共有まわりの注意点をまとめます。

本記事は過去の拙著 組織レベルで生成AI利用の安全を確保するAmazon Bedrock policies(プレビュー) のアップデート版です。

この記事でわかること

  • Bedrock ポリシーで組織全体に Guardrails を強制する方法
  • クロスアカウントでの共有に必要なリソースベースポリシーの設定
  • GAで追加された model_enforcement によるガードレール適用モデルの制御

Bedrock ポリシーとは

Bedrock ポリシーは、 組織全体や任意のOU、アカウントの単位でアタッチし、Amazon Bedrockでモデル推論する際に 特定のAmazon Bedrock Guardrailsを強制的に適用できる AWS Organizationsのポリシーの一つです。

docs.aws.amazon.com

Amazon Bedrock Guardrails単体については、弊社の以下ブログをご参照ください。

blog.serverworks.co.jp

例えば組織のポリシーとして生成AIへの入出力を禁止するトピック(話題)や禁止する単語を定義したり、PII(個人情報)のマスキングを設定し、それをOUやアカウントに適用することで、組織全体で生成AIの利用に対するガバナンスを強化することが考えられます。

導入手順の全体像

Bedrock ポリシーは、以下の流れで設定を行います。

  1. 管理アカウントにてBedrock Guardrailsでガードレールを作成(利用するすべてのリージョンで必要)
  2. ガードレールのバージョンを作成する
  3. ガードレールにリソースベースのポリシーをアタッチする
  4. (日本語を扱う場合) クロスリージョン推論プロファイルにリソースベースポリシーをアタッチする
  5. AWS OrganizationsでBedrock ポリシーを有効にする
  6. ガードレールを指定する管理ポリシーを作成し、OUやアカウントにアタッチする

設定例

実際にやってみます。
今回は東京リージョンを対象として、以下のようなガードレールを作成します。

  • 単語フィルター: "ここだけの話"を禁止するガードレール
  • 機密情報フィルター: "名前"と"住所"をマスクするガードレール

管理アカウントにてBedrock Guardrailsでガードレールを作成

Bedrockの画面からガードレールの作成を行います。

本記事はガードレールの作成方法自体は扱いませんが、注意事項として日本語を対象にする場合はクロスリージョン推論(Cross-Region inference)を有効にする必要があります。
東京リージョンの場合は APAC Guardrail v1:0 というクロスリージョン推論プロファイルが利用可能です。

単語フィルターの設定で「ここだけの話」を禁止する設定を行います。(※単語フィルターは日本語に正式対応していませんがテスト用途として設定しています)

機密情報フィルターでは、PIIの種類として名前と住所を"マスク"するように設定してみます。

上記の設定をしてガードレールを作成します。

ガードレールのバージョンを作成する

ガードレールを作成した時点ではドラフト状態のガードレールとなっていますので、バージョンを作成することである時点のガードレールの設定を確定させます。

説明には任意の内容を入力し「バージョンを作成」をクリックします。

これで Version 1 が作成されました。

ガードレール ARN とバージョン番号 (例: 「1」、「2」など) をメモしておきます。

  • ARN: arn:aws:bedrock:ap-northeast-1:<account_id>:guardrail/<guardrail_id>
  • バージョン: 1

ガードレールにリソースベースのポリシーをアタッチする

同じガードレールの画面で、"Resource-based policy"の箇所にある"Create guardrail policy"をクリックします。

以下のように、組織内でガードレールを共有する設定を入力し「Create policy」をクリックします。

ResourceにはガードレールのARNが自動で入っています。 Conditionに、組織IDを指定することで、組織内でガードレールを共有することができます。 (組織IDはAWS Organizationsの画面で確認できます。)

{
    "Version":"2012-10-17",               
    "Statement": [{
        "Effect": "Allow",
        "Principal": "*",
        "Action": [
            "bedrock:GetGuardrail",
            "bedrock:ApplyGuardrail"
        ],
        "Resource": "arn:aws:bedrock:ap-northeast-1:<account_id>:guardrail/<guardrail_id>",
        "Condition": {
            "StringEquals": { 
                "aws:PrincipalOrgID": "<org_id>"
            }
        }
    }]
}

なお、メンバーアカウントでガードレールを利用するにはメンバーアカウント側のロールにbedrock:ApplyGuardrailの権限が付与されている必要があります。

ガードレールのクロスリージョン推論プロファイルにリソースベースポリシーをアタッチする

日本語を扱う場合にはクロスリージョン推論を有効にする必要があると前述しました。
その場合に必要な重要な設定として、クロスリージョン推論のプロファイルにもリソースベースのポリシーをアタッチする必要があります

この設定を行わないと、BedrockポリシーをアタッチしたメンバーアカウントでBedrockで推論しようとしても
"The provided resource ARN is from a different account." というエラーが出て推論自体ができない状態となりました。
何が問題なのかもエラー文からはわからないため、特定に時間を要しました。

ガードレールの画面の最下部にある「System-defined guardrail profiles」の箇所で、クロスリージョン推論プロファイル(例: APAC Guardrail v1:0)のリンクをクリックします。

「Create」をクリックします。

以下のJSONを設定し「Create policies」をクリックします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "bedrock:ApplyGuardrail"
      ],
      "Resource": "arn:aws:bedrock:ap-northeast-1:<account_id>:guardrail-profile/apac.guardrail.v1:0",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "<org_id>"
        }
      }
    }
  ]
}

AWS OrganizationsでBedrock ポリシーを有効にする

Organizationsの画面で「ポリシー」をクリックし、右ペインで「Bedrockポリシー」をクリックします。

「Bedrockポリシーを有効にする」をクリックします。

ガードレールを指定する管理ポリシーを作成し、OUやアカウントにアタッチする

Bedrockポリシーの作成

「ポリシーを作成」をクリックします。

ポリシー名やタグを設定し、ポリシーのJSONを指定します。

identifierの箇所には、先ほどメモしたガードレールのARNとバージョンを指定します。

{
    "bedrock": {
        "guardrail_inference": {
            "ap-northeast-1": {
                "config_1": {
                    "identifier": {
                        "@@assign": "arn:aws:bedrock:ap-northeast-1:<account_id>:guardrail/<guardrail_id>:1"
                    },
                    "selective_content_guarding": {
                        "system": {
                            "@@assign": "comprehensive"
                        },
                        "messages": {
                            "@@assign": "comprehensive"
                        }
                    },
                    "model_enforcement": {
                        "included_models": {
                            "@@assign": ["ALL"]
                        },
                        "excluded_models": {
                            "@@assign": ["amazon.titan-embed-text-v2:0", "cohere.embed-english-v3"]
                        }
                    }
                }
            }
        }
    }
}

入力後、「ポリシーを作成」をクリックします。

!New! GAに伴い、Bedrock ポリシーでガードレールの適用対象モデルの指定もしくは適用除外するモデルの指定が可能になりました。 ポリシーの形式については以下の公式ドキュメントを参照ください。(※英語版を参照ください。) https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_bedrock_syntax.html

model_enforcementが追加され、included_modelsでガードレールの適用対象モデルを指定、もしくはexcluded_modelsでガードレールの適用除外モデルを指定できるようになりました。

これにより、Bedrock Guardrailsに対応していないモデルをガードレールの適用対象から除外することが可能になりました。

プレビュー時点ではこのような指定ができず、例えばAmazon Titan Embed Text v2といったBedrock Guardrailsに対応していないモデルもガードレールの適用対象となってしまっていました。そのためこれらのモデルを利用しているAWSアカウントに強制適用するとBedrock Knowledge Basesが全く利用できなくなるといったリスクがありました。

model_enforcementの説明は以下のとおりです。

フィールド 説明
model_enforcement(任意) ガードレール構成に関するモデル固有の情報。記載がない場合、すべてのモデルに適用されます。
included_models(必須) ガードレールを適用するモデルのリスト。空欄の場合は、すべてのモデルに適用されます。また、キーワード「ALL」を指定することで、すべてのモデルを明示的に含めることもできます。
excluded_models(必須) ガードレールの適用対象から除外するモデル。空欄の場合は、適用対象から除外されません。含まれるモデルリストと除外されるモデルリストの両方に存在するモデルは除外されます。

selective_content_guardingの説明は以下のとおりです。

フィールド 説明
selective_content_guarding(任意) Amazon Bedrock API を使用すると、呼び出し元がガードレールで処理したい入力内の特定のコンテンツをマークできます。これらの設定により、エンフォーサーは呼び出し元が行ったコンテンツタグ付けの決定を尊重するかどうかを制御できます。指定する場合は、"system"または"messages"が必要です。
system(任意) ガードレールによるシステムプロンプトの処理方法を選択します。指定しない場合はcomprehensiveが使用されます。
messages(任意) ユーザーとアシスタントの会話を含むメッセージコンテンツがガードレールによってどのように処理されるかを選択します。指定しない場合はcomprehensiveが使用されます。
comprehensive ガードコンテンツタグに関係なく、すべてのコンテンツを評価します。
selective ガードコンテンツタグ内のコンテンツのみを評価します。タグが指定されていない場合は、メッセージ内のすべてのコンテンツを評価します。

selective_content_guarding はGuard Content Tagsの扱いをどうするかの設定です。Guard Content Tags は、入力テキストの中で「Guardrails に評価させたい部分」だけをマークするためのXMLタグです。有効にしている場合プロンプトの中の特定のXMLタグで囲まれた部分だけがガードレールの適用対象とすることができます。comprehensiveはこの動作を無視して、すべてのプロンプトに対してガードレールを適用します。こうすることで個別アカウント側でガードレールを回避できないようにすることができます。逆にselectiveにすることで、Guard Content Tagsを尊重し評価対象の部分のみにガードレールを適用することが可能です。
詳しくは Apply tags to user input to filter content - Amazon Bedrock を参照ください

Bedrockポリシーをアタッチ

作成したポリシー名のリンクをクリックします。

「ターゲット」タブをクリックし「アタッチ」をクリックします。

組織の構成が表示されますので、アタッチしたいOUやアカウントを選択して「アタッチ」をクリックします。 今回はRootにアタッチし、組織全体に強制してみます。

アタッチ後、ターゲットタブの表示は以下のようになっています。

動作確認

会話

それでは、メンバーアカウントでAmazon Bedrockを利用してみます。

メンバーアカウントのBedrock Guardrailsの画面を確認すると、先ほどアタッチしたガードレールが強制適用されていることがわかります。

プレイグラウンドで、ガードレールは指定なしの状態で、"ここだけの話 なのですが"というプロンプトを入力してみます。
ブロックされました。

※"ここだけの話"の後に空白スペースが入っています。これを入れないと「ここだけの話」という単語が検出されないため、ガードレールが発動しませんでした。単語フィルターは日本語に正式対応していないため、スペースを入れるなどの工夫が必要となります

次に、名前と住所(弊社の住所)を入力してみます。
名前と住所がマスクされました。

AWS CLIでAPI経由で呼び出してみます。

$ export AWS_REGION=ap-northeast-1
$ export MODEL_ID="arn:aws:bedrock:ap-northeast-1:<account_id>:inference-profile/jp.amazon.nova-2-lite-v1:0"

$ aws bedrock-runtime converse \
  --region "$AWS_REGION" \
  --model-id "$MODEL_ID" \
  --inference-config '{"maxTokens":1000,"temperature":0.0}' \
  --messages '[
    {
      "role":"user",
      "content":[
        {
          "text":"私の名前は久保賢二といいます。住所は東京都新宿区揚場町1番21号 飯田橋升本ビル2階です。\n私の氏名と住所を箇条書きにしてください。"
        }
      ]
    }
  ]'

結果は以下のとおり、名前と住所がマスクされていることがわかります。

{
    "output": {
        "message": {
            "role": "assistant",
            "content": [
                {
                    "text": "ご提供いただいた氏名と住所を箇条書きにします。\n\n- **氏名**: {NAME}\n- **住所**: {ADDRESS}"
                }
            ]
        }
    },
    "stopReason": "end_turn",
    "usage": {
        "inputTokens": 74,
        "outputTokens": 32,
        "totalTokens": 106
    },
    "metrics": {
        "latencyMs": 1098
    }
}

ガードレール非対応モデルの除外確認

ガードレールに対応していないAmazon Titan Text Embeddings V2といった埋め込みモデルは設定で除外対象にしておきました。 実際に除外されているか確認します。

Bedrock Knowledge Basesのデータ同期を実行したところ、エラーなく処理が成功しました。指定した埋め込みモデルが除外されています。

次に、Bedrockポリシーを編集して、ガードレール適用を除外しない設定にして再度試してみます。
model_enforcementを削除しました。

{
    "bedrock": {
        "guardrail_inference": {
            "ap-northeast-1": {
                "config_1": {
                    "identifier": {
                        "@@assign": "arn:aws:bedrock:ap-northeast-1:<account_id>:guardrail/<guardrail_id>:1"
                    },
                    "selective_content_guarding": {
                        "system": {
                            "@@assign": "comprehensive"
                        },
                        "messages": {
                            "@@assign": "comprehensive"
                        }
                    }
                }
            }
        }
    }
}

この状態で再度Bedrock Knowledge Basesでデータソースの同期を実行してみます。
すると、下記のように Enforced guardrails are configured for the account but guardrails aren't supported for the provided model というエラーで失敗する状態となりました。 (ただし反映されるまでに数分以上かかりました)

これでexcluded_modelsで意図通り埋め込みモデルへのガードレール適用が除外されていたことが確認できました。

FAQ

料金や複数ガードレールが存在する場合等気になる点があるかと思います。
公式ドキュメントにFAQが記載されていますのでその中の一部を紹介します。

Apply cross-account safeguards with Amazon Bedrock Guardrails enforcements - Amazon Bedrock

料金はどのアカウントに発生するの?

実際にBedrockで推論を行い、ガードレールを利用したアカウントに料金が発生します。

消費量は各リクエストに関連付けられたガードレールARNごとに計算され、API呼び出しを行ったAWSアカウントにカウントされます。

(ドキュメント抜粋の機械翻訳)

アカウントでもガードレールが適用されている場合どうなるの?

Bedrock ポリシーでガードレールを適用した場合と、アカウントでガードレールを適用した場合の両方がある場合、両方のガードレールが適用されます。

最終的な効果は、すべてのガードレールを統合したものとなり、最も制限の厳しい制御が優先されます。

(ドキュメント抜粋の機械翻訳)

注意事項

共有設定の誤り、不足に注意

ガードレールのリソースベースポリシーや、クロスリージョン推論プロファイルのリソースベースポリシーで、組織内で共有する設定が正しく行われていないと、メンバーアカウントでガードレールが利用できずすべての推論がエラーになります。

いずれかのリソースベースポリシーが誤っている場合、以下画面のようにThe provided resource ARN is from a different account.というエラーが表示され、モデル推論自体ができなくなってしまいます。

強制適用という強力な制限であるがゆえに、本番運用中の組織で誤った設定を行うと組織全体でモデル推論ができなくなってしまう大きなリスクがありますので、設定の際は十分にご注意ください。

必ずテスト用のOUを用意して、そこで十分に動作確認を行ってから他のOUやアカウントに適用することを強く推奨します。

埋め込みモデルなどのガードレールがサポートされていないモデルを対象外に設定する

前述のとおり、ガードレールがサポートされていないモデルを適用対象とした場合、モデル推論の際にエラーになってしまいます。
Bedrockポリシーのmodel_enforcementを利用して、included_modelsで適用対象モデルを明示的に指定するか、excluded_modelsで除外対象モデルを指定する必要があります。

以下の公式ドキュメントで、Bedrock Guardrailsに対応しているモデルを確認できます。

https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-supported.html

ただ残念ながら上記ドキュメントは2026年4月10日時点では最新状況に追随されておらず、例えばClaude Sonnet 4.6やClaude Opus 4.6などのモデルもBedrock Guardrailsに対応していますが、ドキュメント上では対応モデルとして反映されておりません。

そのため、安全のため 必ず検証用のOU、AWSアカウントにてガードレールの対応状態を動作確認 し、必要に応じてexcluded_modelsを指定することを推奨いたします。

組織内で完全な統制を行うにはすべてのリージョンでガードレールを定義しBedrockポリシーを適用する必要あり

本記事では管理アカウントで東京リージョンでのみガードレールを定義し、Bedrockポリシーで東京リージョンについての適用ポリシーを作成しました。

当然ながら例えば適用対象外のバージニア北部リージョンではガードレールの強制適用なしにBedrockの推論を行うことが可能です。
組織として全体を確実に統制するには、組織で利用を許可しているすべてのリージョンで同じ内容のガードレールを定義し、すべてのリージョンに対して強制適用するBedrockポリシーを定義する必要があります。

すべてのリージョンで同じ内容のガードレールを手作業で定義するのは非効率であるため、組織全体で完全な統制を行う際にはCloudFormationやAWS CDK、TerraformといったIaCでガードレールを定義、管理することが推奨されます。

おわりに

本記事では、AWS OrganizationsのBedrock ポリシーについてご紹介しました。

Bedrock ポリシーは、組織全体で生成AI活用の安全を確保するための強力な機能です。

ただし、設定を誤るとモデル推論ができなくなってしまうリスクもあります。

適切に設定を行い、生成AIの安全な利用にご活用いただけますと幸いです。

久保 賢二(執筆記事の一覧)

猫とAWSが好きです。