AWSをマルチアカウント構成で運用する組織では、生成AI活用が進むにつれて新たな課題が生まれています。各チームや事業部がそれぞれのAWSアカウントでAmazon Bedrockを活用する場合、コンプライアンスや安全ポリシーの一貫した適用が難しくなっていました。

このたびGAとなったAmazon Bedrock GuardrailsのクロスアカウントSafeguards機能は、そうした課題に直接答える機能です。管理アカウントから組織全体のAIセーフガードを一元管理できるようになり、エンタープライズ規模でのBedrock活用が大きく前進します。

なぜ組織規模でのGuardrails管理が必要なのか

大企業や急成長するスタートアップでは、AWS Organizations配下に複数のAWSアカウントを持つ構成が一般的です。開発・ステージング・本番の分離、事業部別アカウント、プロジェクト別アカウントなど、用途に応じてアカウントを分けることがベストプラクティスとされています。

この構成は管理・セキュリティ面で優れていますが、Amazon Bedrockを活用するにあたっては以下のような課題が生じていました。

• 各アカウントで個別にGuardrailsを設定する必要があり、設定の漏れや不整合が発生しやすい
• 組織のAI利用ポリシーが変わるたびに、すべてのアカウントを個別に更新しなければならない
• セキュリティチームが全アカウントの設定を個別に監査・確認する必要がある
• 新しいアカウントを作成するたびに、Guardrails設定を忘れずに適用する仕組みが必要

これらは単なる運用コストの問題だけでなく、コンプライアンスリスクにも直結します。万が一、Guardrailsの適用漏れがあったアカウントで不適切なコンテンツが生成された場合、組織全体の信頼に影響する可能性があります。

クロスアカウントSafeguards機能は、こうした課題を根本から解決するアプローチを提供します。

クロスアカウントSafeguards機能の全体像

この機能では、2つのレベルでGuardrailsの施行（enforcement）を設定できます。それぞれ目的と適用範囲が異なり、組み合わせて使うことで柔軟なガバナンス設計が可能です。

組織レベルの施行（Organization-level enforcement）は、AWS Organizationsの管理アカウントから設定するポリシーです。組織のルートや特定のOU（Organizational Unit）、個別のアカウントにBedrockポリシーをアタッチすることで、対象エンティティ内のすべてのBedrockモデル呼び出しに対してGuardrailsが自動適用されます。

アカウントレベルの施行（Account-level enforcement）は、特定のAWSアカウント内のすべてのBedrockモデル呼び出しに対して自動的にGuardrailsを適用する設定です。アカウント内のすべての推論APIコール（InvokeModel、InvokeModelWithResponseStream、Converse、ConverseStream）に対して、設定したGuardrailのSafeguardが適用されます。

この2レイヤー設計により、「全社共通のルールは組織ポリシーで強制し、部門ごとの追加制御はアカウントレベルで設定する」といった階層的なガバナンスが実現できます。セキュリティチームは組織ポリシーで最低限の保護を担保しながら、各チームは独自の要件に応じた追加制御を自分たちのアカウントで管理できます。

アカウントレベル施行の設定手順

アカウントレベルの施行を設定するには、まずAmazon Bedrock Guardrailsコンソールにアクセスします。設定前に、適用したいGuardrailを特定バージョンで作成しておく必要があります。バージョンを固定することで、施行後にGuardrailの設定が変更されても、メンバーアカウントへの影響が予期せず生じることを防ぎます。

コンソールのAccount-level enforcement configurationsセクションで「Create」を選択し、適用するGuardrailとバージョンを指定します。このとき、どのモデルに対して施行するかをInclude/Excludeで細かく制御できる点が、GA版で追加された新機能です。特定のモデルだけに制限を適用したい、あるいは特定のモデルを除外したいといったユースケースに対応できます。

コンテンツガード制御の設定では、2つのモードを選択できます。

設定完了後は、アカウント内のロールを使用して施行をテスト・検証できます。Bedrockの推論APIを呼び出すと、レスポンスにGuardrailの評価情報が含まれるようになります。

組織レベル施行の設定手順

組織レベルの施行は、AWS Organizationsコンソールから設定します。手順はアカウントレベルの設定と少し異なり、AWS Organizations側でのポリシー管理が中心になります。

まず、AWS OrganizationsコンソールのPoliciesメニューにアクセスし、Bedrock Policiesを有効化します。これはOrganizations全体の設定で、一度だけ行えば以降のポリシー作成に使えます。

次に、Bedrockポリシーを新規作成します。ポリシー内でGuardrailのARN（Amazon Resource Name）とバージョンを指定し、入力タグの設定（Comprehensive/Selective）を行います。ポリシーの構文については、Amazon Bedrock policy syntax and examplesを参照してください。

ポリシー作成後、Targetsタブから適用先を設定します。組織のルート、特定のOU、個別のアカウントなどを選択してポリシーをアタッチできます。例えば、本番環境のOUには厳しいGuardrailを適用し、開発環境のOUには緩めの設定にするといった制御が可能です。

ポリシーのアタッチが完了すると、対象のメンバーアカウントからAmazon Bedrockコンソールを確認したとき、「Organization-level enforcement configurations」セクションに施行中のGuardrailが表示されます。メンバーアカウントのユーザーは、このGuardrailを修正することはできません。施行されたGuardrailの配下にある各Safeguardが、対象エンティティ内のすべての推論リクエストに対して自動的に強制されます。

設計時の注意点とベストプラクティス

この機能を本番環境で活用する前に、いくつかの重要な考慮事項があります。実装の成否を左右するポイントを整理します。

まず、GuardrailのARN管理には細心の注意が必要です。組織ポリシーに誤ったARNや無効なARNを指定すると、ポリシー違反が発生し、対象アカウントでAmazon Bedrockのモデルが使えなくなる場合があります。ARNは必ず正確に確認し、ポリシーに設定する前にコンソールやAPIで存在確認を行いましょう。

次に、Guardrailのバージョン管理が重要です。施行に使用するGuardrailは特定バージョンに固定することが推奨されています。ドラフト版（DRAFT）を使用すると、Guardrailの設定変更が即座に全組織に反映されてしまう可能性があります。バージョンを固定することで、変更管理プロセスを経た上で安全に更新できます。

また、Automated Reasoning checksはこのクロスアカウント施行機能ではサポートされていません。この種のチェックが必要なユースケースでは、別途対応策を検討する必要があります。

前提条件として、Guardrailのリソースベースポリシーの設定が必要です。詳細は公式ドキュメントを確認してください。また、前提条件の一覧はこちらにまとめられています。

まとめ - エンタープライズAI基盤のガバナンス設計に向けて

Amazon Bedrock GuardrailsのクロスアカウントSafeguards機能は、エンタープライズ規模での生成AI活用において重要な転換点となります。これまでアカウントごとに手作業で行っていたGuardrails設定が、組織ポリシーとして一元管理できるようになりました。

この機能がもたらす組織的なメリットは大きく3つあります。第一に、セキュリティ設定の一貫性担保です。全アカウントに同一のGuardrailが適用されるため、設定漏れによるコンプライアンスリスクを排除できます。第二に、運用負荷の大幅削減です。セキュリティチームが各アカウントを個別に監査する必要がなくなり、組織ポリシーの変更も一度の操作で全体に反映されます。第三に、柔軟なガバナンス設計の実現です。組織レベルで最低限の保護を強制しながら、各チームが独自の要件に応じた追加制御を持てる2レイヤー設計により、セキュリティと生産性のバランスを取れます。

Ragateでは、AWS Organizations環境での生成AI基盤構築やGuardrailsを活用したセキュアなAIプラットフォーム設計の支援実績を持っています。今回のクロスアカウントSafeguards機能は、エンタープライズAI基盤のガバナンス設計において有力な選択肢となります。マルチアカウント環境でのBedrock活用やAIセーフガードの設計にお悩みの方は、ぜひRagateにご相談ください。