トップ > 生成AI > 組織レベルで生成AI利用の安全を確保するAmazon Bedrock policies(プレビュー)

組織レベルで生成AI利用の安全を確保するAmazon Bedrock policies(プレビュー)

生成AI Amazon Bedrock セキュリティ Amazon Bedrock Guardrails
記事タイトルとURLをコピーする

はじめに

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

AWSを複数のアカウントで管理する際に利用するAWS Organizationsは、組織全体でポリシーを適用するための機能を多く提供しています。

2026年2月13日時点では、プレビュー中のものを含めて13種類のポリシーが提供されています。

本日はこの中でも、"Bedrock policies(Bedrockポリシー)" についてご紹介します。
"Bedrock policies"はプレビュー提供中の機能です。 AWSで生成AIを利用する際に、組織としてセキュリティ・プライバシー・コンプライアンスを確保し、責任あるAIの利用を支援することが可能です。

注意事項の箇所で、重要な制限等についてもご紹介しておりますので、ぜひ最後までご覧ください。

この記事でわかること

  • Bedrock policies（プレビュー）で組織全体に Guardrails を強制する方法
  • クロスアカウントでの共有に必要なリソースベースポリシーの設定
  • 適用時の落とし穴（誤設定で推論不能 / 埋め込みモデル）

【重要】現時点での制限事項：Knowledge Basesの埋め込みモデル等ガードレール非対応モデルを利用するアカウント(もしくはOU）には適用しないでください（推論エラーになります）

Bedrock policiesとは

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

docs.aws.amazon.com

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

blog.serverworks.co.jp

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

導入手順の全体像

Bedrock policiesは、以下の流れで設定を行います。

  1. 管理アカウントにてBedrock Guardrailsでガードレールを作成(利用するすべてのリージョンで必要)
  2. ガードレールのバージョンを作成する
  3. ガードレールにリソースベースのポリシーをアタッチする
  4. AWS OrganizationsでBedrock policiesを有効にする
  5. ガードレールを指定する管理ポリシーを作成し、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 - Preview"の箇所にある"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 policiesを有効にする

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

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

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

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

ポリシー名やタグを設定し、ポリシーのJSONでは以下のように指定します。

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

{
    "bedrock": {
        "guardrail_inference": {
            "ap-northeast-1": {
                "config_1": {
                    "identifier": {
                        "@@assign": "arn:aws:bedrock:ap-northeast-1:<account_id>:guardrail/<guardrail_id>:<version>"
                    },
                    "input_tags": {
                        "@@assign": "ignore"
                    }
                }
            }
        }
    }
}

input_tagsの箇所は、ガードレールの入力タグという仕組みの扱いを指定する箇所です。今回は「ignore」を指定し、ガードレールの入力タグが無視されるようにします。これは、ガードレールの入力タグは、ガードレールがモデル推論の入力に対してタグを付与する機能で、タグの内容に応じてガードレールの動作を変えることができます。メンバーアカウント側でガードレールを回避されないようにするため、今回は入力タグを無視する設定としています。

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

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

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

組織の構成が表示されますので、アタッチしたい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
    }
}

FAQ

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

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

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

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

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

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

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

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

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

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

ガードレールをサポートしていないモデルの場合はどうなるの?

ガードレールがサポートされていないモデル (埋め込みモデルなど) の場合、ランタイム検証エラーがスローされます。

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

この記述は非常に気になります。Amazon Bedrock Knowledge Basesでは、埋め込みモデルを利用してデータソースから埋め込みを作成し、モデル推論の際に類似度検索を行うという構成が一般的ですが、ガードレールがサポートされていない埋め込みモデルを利用している場合、モデル推論の際にエラーになってしまう可能性があります。

検証したところ、データソースから同期する処理（埋め込みモデルを利用する処理）でエラーになりました。

これは現在プレビュー中のため仕方ないところかもしれませんが、実際にBedrock policiesを利用するには、致命的な仕様かと思います。

つまり、Bedrock Knowledge Bases等で埋め込みモデルを利用している場合、Bedrock policiesを適用してはいけない、ということになります。

こちらは今後のアップデートでの改善を期待したいところです。

注意事項

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

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

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

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

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

埋め込みモデルなどのガードレールがサポートされていないモデルを利用している場合は絶対に適用しないように

前述のとおり、ガードレールがサポートされていないモデルを利用している場合、モデル推論の際にエラーになってしまいます。
記事執筆時点では例外を設定するといった回避策もないため、Bedrock Knowledge Basesなどで埋め込みモデルを利用している場合は、Bedrock policiesを適用しないようにしてください。

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

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

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

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

おわりに

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

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

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

また、記事執筆時点では埋め込みモデルを利用する環境にBedrock policiesを適用するとモデル推論がエラーになってしまうという制限もあります。

一般公開(GA)時にはこれらの注意点が改善され、より安全に利用できるようになることを期待したいと思います。

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

猫とAWSが好きです。