![[アップデート] Amazon Bedrock Guardrails でクロスアカウントのセーフガードが GA になり、組織全体のガードレールを一元管理できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e3065182082062711612153bbdcf1d96/c04359de689df2f56eb066576ab63fb5/amazon-bedrock?w=3840&fm=webp)
[アップデート] Amazon Bedrock Guardrails でクロスアカウントのセーフガードが GA になり、組織全体のガードレールを一元管理できるようになりました
いわさです。
Amazon Bedrock Guardrails は、生成 AI アプリケーションに対してコンテンツフィルタリングやトピック制御、PII 検出などのガードレール的な制御を提供する機能です。アプリケーションから推論を呼び出す際にガードレールを指定することで、入力プロンプトとモデルの応答の両方に対してセーフガードを適用できます。
また、AWS Organizations には Amazon Bedrock ポリシーというポリシータイプがあり、管理アカウントで作成したガードレールを組織内のメンバーアカウントに対して強制適用できます。2025年3月には IAM 条件キー bedrock:GuardrailIdentifier による強制適用がリリースされ、その後アカウントレベル・組織レベルでの強制適用がプレビューとして提供されていました。
先日のアップデートで、このクロスアカウントのセーフガード機能が GA となりました。
公式ドキュメントの変更前後を比較した限りでは GA に合わせて、以下の新機能が追加されているようです。
- モデル制御（Include / Exclude）：強制適用の対象モデルを指定できるようになり、特定のモデル（例：埋め込みモデル）を除外可能に
- Selective content guarding：system プロンプトと messages それぞれに対して、Comprehensive（すべて評価）か Selective（タグ付きコンテンツのみ評価）を選択可能に
今回は組織レベルの強制適用を実際に設定して、GA で追加された新機能も含めて確認してみたので紹介します。
組織レベルの強制適用を設定してみる
では早速、管理アカウントからメンバーアカウントへガードレールを強制適用する手順を確認してみましょう。
全体の流れは以下のとおりです。
- 管理アカウントでガードレールを作成し、バージョンを発行する
- ガードレールにリソースベースポリシーをアタッチし、メンバーアカウントからのアクセスを許可する
- メンバーアカウントの IAM ロールに
bedrock:ApplyGuardrail権限を付与する - AWS Organizations で Amazon Bedrock ポリシータイプを有効化する
- Bedrock ポリシーを作成し、対象の OU やアカウントにアタッチする
- メンバーアカウントから推論を実行し、ガードレールが強制適用されることを確認する
今回は東京リージョンで試してみました。
ガードレールの作成とバージョン発行（管理アカウント）
管理アカウントの Amazon Bedrock コンソールの左メニューから「ガードレール」を選択すると、ガードレールの一覧画面が表示されます。今回は Word filters で「AWS」をブロック、Denied Topics で AWS 関連コンテンツを拒否する設定のガードレールを作成済みです。
また、ガードレールの「バージョン」セクションで「バージョンを作成」からバージョンも発行済みです。強制適用にはバージョン番号の指定が必要みたいです（DRAFT は使えない）
また、ガードレール作成時に一点注意事項があって、Automated Reasoning チェックは強制適用ではサポートされていないため、有効にしないよう注意してください。ドキュメントにも以下のとおり明記されており、有効にするとランタイムエラーが発生するみたいです。
Do not include the automated reasoning policy, as it is unsupported for guardrail enforcements and will cause runtime failures.
リソースベースポリシーの設定（管理アカウント）
管理アカウントで作成したガードレールに、組織全体からのアクセスを許可するリソースベースポリシーをアタッチします。
ガードレールの詳細画面を下にスクロールすると「Resource-based policy - Preview」セクションがあるので、「Create guardrail policy」を押します。
「Create resource-based policy」画面が開くので、以下のようなポリシーを入力します。aws:PrincipalOrgID 条件で組織内のアカウントに限定しています。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": [
"bedrock:GetGuardrail",
"bedrock:ApplyGuardrail"
],
"Resource": "arn:aws:bedrock:ap-northeast-1:123456789012:guardrail/your-guardrail-id",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-your-org-id"
}
}
}]
}
「Create policy」を押してポリシーを保存します。
メンバーアカウントの IAM 権限設定
メンバーアカウント側で Bedrock を利用する IAM ロールに、管理アカウントのガードレールに対する bedrock:ApplyGuardrail 権限を付与する必要があります。
メンバーアカウントの IAM コンソールで、対象のロールに以下のようなポリシーを追加します。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "bedrock:ApplyGuardrail",
"Resource": "arn:aws:bedrock:us-east-1:123456789012:guardrail/your-guardrail-id"
}]
}
なお、この権限がないと推論時にアクセス拒否エラーが発生するらしいので、SCP とかで細かく管理している場合は注意しましょう。
Bedrock ポリシーの作成（Organizations）
AWS Organizations コンソールで Bedrock ポリシーを作成します。
作成の流れは省略しますが、ポリシーは以下のような形で設定します。
{
"bedrock": {
"guardrail_inference": {
"ap-northeast-1": {
"config_1": {
"identifier": {
"@@assign": "arn:aws:bedrock:ap-northeast-1:123456789012:guardrail/your-guardrail-id:1"
},
"selective_content_guarding": {
"system": {
"@@assign": "comprehensive"
},
"messages": {
"@@assign": "comprehensive"
}
},
"model_enforcement": {
"included_models": {
"@@assign": ["ALL"]
},
"excluded_models": {
"@@assign": ["amazon.nova-lite-v1:0"]
}
}
}
}
}
}
}
ポイントをいくつか補足します。
identifierにはガードレール ARN の末尾にバージョン番号を:1のように付与します。ここで不正な ARN を指定するとポリシー違反となり、メンバーアカウントで Bedrock の推論自体が使えなくなるので注意が必要です- なお、リージョンキー（上記例では
ap-northeast-1）は、ガードレールを作成したリージョンと一致させる必要があるみたいです。私は最初us-east-1と指定してしまいThe provided policy document does not meet the requirements of the specified policy typeというエラーが発生しました。ガードレール ARN に含まれるリージョンとポリシーのリージョンキーが一致しているか確認しましょう selective_content_guardingは GA で追加された設定です。system プロンプトと messages それぞれにcomprehensive（すべて評価）かselective（タグ付きコンテンツのみ評価）を指定できます。comprehensiveはすべてのコンテンツをガードレールで評価するため、呼び出し側のタグ付けに依存しない安全なデフォルトです。selectiveは呼び出し側が適切にタグ付けすることを信頼し、不要なガードレール処理を減らしたい場合に有用です。今回はどちらもcomprehensiveにしていますmodel_enforcementも GA で追加された設定です。強制適用の対象モデルを制御できます。ALLを指定するとすべてのモデルに適用されます。特定のモデルをガードレール適用対象から外したい場合はexcluded_modelsで除外できます。今回は検証用にamazon.nova-lite-v1:0を除外して、除外したモデルではガードレールが適用されないことを後ほど確認してみます
「ポリシーを作成」を押してポリシーを保存します。
ポリシーのアタッチ（Organizations）
作成したポリシーを対象の OU やアカウントにアタッチします。今回は OU の「ポリシー」タブから「Bedrock ポリシー」セクションの「アタッチ」を押してアタッチしました。
メンバーアカウントでの確認
メンバーアカウントに切り替えて、Bedrock コンソールの「ガードレール」ページを開きます。
メンバーアカウント自体にはガードレールが作成されていませんが、「Organization-level enforced guardrails」セクションに管理アカウントから適用されたガードレールが表示されていることが確認できます。Configuration ID、Guardrail ID、Version、Model configuration などの情報が確認できますね。
メンバーアカウントのプレイグラウンドからガードレールを明示的に指定せずに推論を実行してみましょう。
まず、除外対象ではないモデル（Nova 2 Lite）を選択し、「AWS」と送信してみます。
「2026年4月5日の管理アカウントのガードレールでブロックされました」と表示されました。ガードレールを指定していないにもかかわらず、管理アカウントから強制適用されたガードレールによってコンテンツがブロックされていることが確認できます。
次に、excluded_models で除外した Nova Lite に切り替えて、同じく「AWS」と送信してみます。
こちらはガードレールが適用されず、AWS についての通常の応答が返ってきました。model_enforcement の除外設定がちゃんと効いていることが確認できますね。
これで、管理アカウントで設定したガードレールがメンバーアカウントの推論に自動的に適用されていること、そして除外モデルにはガードレールが適用されないことが確認できました。
さいごに
本日は Amazon Bedrock Guardrails のクロスアカウントセーフガード機能が GA になったので、組織レベルの強制適用を実際に設定して確認してみました。
プレビューから GA になったことで、モデルの Include/Exclude 制御や Selective content guarding が追加され、より実用的な構成が可能になっています。
今回私は初めて Bedroc ポリシー使ったのですが、これなかなか良いですね。
マルチアカウントで Bedrock を利用している組織にとっては、ガバナンス強化の面でかなり良い。
