はじめに
- 「あのチームのアカウント、ガードレールちゃんと設定してあったっけ？」
- 「モデル呼び出し、誰がどんなプロンプトを投げてるんだろう？」
- 「ポリシー変えたいけど、アカウント全部回るの気が遠くなる…」
中央のセキュリティチームが一番欲しいのは、「1箇所で決めたルールが、組織全部にちゃんと効いてる」という点じゃないでしょうか。
2026年4月3日、Amazon Bedrock Guardrails のクロスアカウント保護機能（Cross-account safeguards） がGAになりました。
この記事では、この機能の仕組みと「何がうれしいのか」、そして実際にどうセットアップしていくのかの流れを、初心者〜中級者向けに噛み砕いて紹介します。
なお、今回は概要とざっくりとした流れのみでやってみた系はありません。
忙しい人のために要約
- Bedrock Guardrailsを組織単位で一括強制適用できる機能が2026年4月3日にGA
- 管理アカウントに作ったガードレールを、AWS Organizationsの新しい「Bedrockポリシー」経由で全メンバーアカウントに自動適用できる
- 組織レベル／アカウントレベル／アプリケーション個別の3層で重ね掛け可能（最も厳しいルールが優先）
- GAで追加された目玉は モデルのInclude/Exclude と Comprehensive/Selective（保護範囲の選択）
- Automated Reasoningチェックは本機能では非対応。料金は強制適用されたガードレールごとに発生
クロスアカウント保護機能とは
まずBedrock Guardrailsのおさらいから。Bedrock Guardrailsは、基盤モデル（FM）の 入力プロンプト と モデルの応答 に対して、有害コンテンツをブロックしたり、ハルシネーション（もっともらしい嘘）をフィルタリングしたりする安全装置です。有害なマルチモーダルコンテンツを 最大88% までブロックできるとされています。
これまでは「ガードレールはアカウントごと・アプリケーションごとに設定するもの」だったのですが、今回のアップデートで 組織（AWS Organizations）全体に強制適用 できるようになりました。
Before / After
2つの強制適用レベル
本機能では、以下の2つのレベルで強制適用を構成できます。
| レベル | 適用範囲 | 設定場所 |
|---|---|---|
| Organization-level（組織レベル） | 組織全体／OU／特定アカウント | AWS Organizationsの Bedrockポリシー |
| Account-level（アカウントレベル） | 単一のAWSアカウント内の全Bedrock呼び出し | Bedrock Guardrailsコンソール |
さらに、アプリケーション側で個別に指定するガードレールと組み合わせる Layered Protection（重ね掛け） にも対応しており、適用結果は「すべてのガードレールの和集合」になります。そして 同じタイプの制御がぶつかった場合は、より厳しい方が勝つ という分かりやすいルールです。
何がうれしいのか
このアップデートの価値を、立場別に見てみましょう。
セキュリティ・ガバナンス担当
- ベースラインの責任AIポリシーを全社で強制できる
- アカウントごとに「ちゃんと設定されてる？」を確認して回る運用負荷から解放
組織管理者・プラットフォームチーム
- 本番環境ではOUごとに厳しめのガードレール、サンドボックスOUでは緩めの設定、といった OU単位の運用 がすっきり書ける
- 新しいメンバーアカウントを追加しても、ポリシーのターゲットになっていれば自動的に保護対象
アプリ開発者
- アプリ個別の追加ガードレールは引き続き使える
- プロンプト設計時に「組織のベースライン保護が効いている前提」で実装できる
GAで追加された2つの新機能
GAのタイミングで追加された機能が2つあるようです。
1. モデルのInclude / Exclude
- Include: 指定したモデルにのみガードレール適用
- Exclude: 指定したモデル以外にガードレール適用
「この機能はクリティカルだからガードレール必須、でもあのモデルは検証用だから外したい」といった使い分けができます。
2. Comprehensive / Selective
システムプロンプトやユーザープロンプトに対して、どこまで保護するか を選べるようになりました。
| モード | 振る舞い | 向いているケース |
|---|---|---|
| Comprehensive | 呼び出し側のタグに関係なく、すべてにガードレール適用 | 呼び出し元を信頼できない・安全側に倒したいデフォルト |
| Selective | 呼び出し側が明示的にタグ付けした部分だけ保護 | 検証済みコンテンツと生成コンテンツが混在し、無駄な処理を省きたいケース |
Selectiveは処理コストを抑えられる代わりに、「呼び出し側がちゃんとタグを付ける」という信頼が前提になります。まずはComprehensiveで始めて、運用が成熟したらSelectiveを検討、というのが安全な進め方ですね。
セットアップの流れ（概念編）
ここは本来「やってみた」セクションにしたいところですが、本機能は 複数のAWSアカウント＋AWS Organizationsの管理アカウント権限 が必須で、個人の単一アカウント環境ではフルで試すのが難しい機能です。
というわけで、今回は 公式ドキュメントをベースに、セットアップの流れと勘所 を整理しておきます。
組織レベル強制適用の場合
アカウントレベル強制適用の場合
こちらは単一アカウントで完結するのでシンプルです。
アカウントレベルだけでも、「このアカウント内のBedrock呼び出しには必ずこのガードレールを通す」という強制ができるので、まずは1アカウントで試す→組織に展開 という段階的な導入もしやすいです。
気をつけるポイント・注意点
Automated Reasoning チェックは非サポート
強制適用の対象にできるガードレール機能は以下です：
- コンテンツフィルター
- 禁止トピック
- ワードフィルター
- 機密情報フィルター
- コンテキスト根拠チェック（Contextual grounding）
Automated Reasoning ポリシーは本機能では非対応 で、含めると実行時エラーになります。既存のガードレールを流用するときに見落としがちなので要注意です。
運用のベストプラクティス
- バージョンを必ず切る: DRAFTではなく数値バージョンで固定し、意図しない変更を防ぐ
- 段階的なロールアウト: まずは小さなOUにアタッチして効果確認 → 徐々に広げる
- 監視を忘れずに: CloudWatchやBedrockのログで、ガードレール発動状況をモニタリング
まとめ
Amazon Bedrock Guardrailsのクロスアカウント保護機能は、「生成AIのガバナンスを中央に寄せたい」という組織的な課題にAWSが出した答え と言える機能です。
- 組織レベルで一貫した責任AIルールを強制
- メンバーアカウントから改変されない不変の設定
- 組織／アカウント／アプリの3層で柔軟に重ね掛け
AWS Organizationsを使っている企業や組織にとっては、「やっと来た」 という嬉しい企業もあるのではないでしょうか
参考リンク
- AWS What's New: Amazon Bedrock Guardrails のクロスアカウント保護機能の一般提供
- AWS News Blog: Amazon Bedrock Guardrails supports cross-account safeguards with centralized control and management
- 公式ドキュメント: Apply cross-account safeguards with Amazon Bedrock Guardrails enforcements
- 公式ドキュメント: Amazon Bedrock policies in AWS Organizations
- 公式ドキュメント: Using resource-based policies for guardrails
- 公式ドキュメント: Best practices for using Amazon Bedrock policies
- Amazon Bedrock Guardrails サービスページ