Amazon Bedrock エンタープライズ導入に向けたセキュリティ設計指針

1. イントロダクション：生成AI時代における多層防御の戦略的重要性

2026年現在、Claude 4.5 (Opus/Sonnet) や Llama 4 といった超高性能な基盤モデルをエンタープライズ環境で運用することは、単なる利便性の追求ではなく、組織の知的財産を保護するための「情報戦」へと進化しています。生成AI特有の脆弱性であるプロンプトインジェクション、データ漏洩、非決定論的なハルシネーションに対し、従来の境界型セキュリティ（インフラレイヤー）と、会話の文脈や有害性を動的に検閲する「セマンティック・セキュリティ」を融合させた多層防御モデルの構築は、今や避けて通れない軍事レベルの必須要件です。

AWS 共有責任モデルと 2026 年の境界

Amazon Bedrock は AgentCore などのマネージドプラットフォームを通じて高度な抽象化を提供しますが、責任境界の峻別は依然として不可欠です。

• AWS の責任: 基盤モデルの管理、AgentCore 実行環境（Managed Runtime）のセッション分離、モデル学習へのデータ転用の防止、物理インフラの堅牢化。
• ユーザーの責任: IAM による最小権限の実装、PrivateLink による通信経路の隔離、KMS 顧客管理鍵（CMK）によるデータの全層暗号化、ガードレールを用いた出力の安全性担保。

Well-Architected Framework「セキュリティの柱」の適用

AWS Well-Architected Framework の原則に基づき、Bedrock アーキテクチャには以下の3点を適用します。

• 強力なアイデンティティ基盤: 全コンポーネントにおいて「明示的な信頼」が必要な IAM ロールを設計し、特権昇格リスクを排除します。
• 全レイヤーでの保護: ネットワーク境界、データストア、そしてモデル推論プロセスのセマンティックな監視まで、一貫した防衛策を講じます。
• 自動化された対応体制: IaC による構成の標準化と、ガードレール介入をトリガーとしたリアルタイム監視により、脅威への即時対応を実現します。

アイデンティティ定義がすべての防衛の起点となるため、次章では IAM による最小権限の実装詳細について論じます。

2. アイデンティティとアクセス管理（IAM）：最小権限原則の実装

2026年の生成AIワークフローにおいて、IAM は単なるアクセス制限ではなく、Amazon Bedrock AgentCore を中心とした各コンポーネント間の信頼基盤として機能します。特に AgentCore の「Managed Runtime」では、各セッションが論理的に分離されており、それらを安全にオーケストレーションするための厳格なロール設計が求められます。

主要な役割と権限の技術的評価

エンタープライズ要件を満たすためには、以下の4つのロールを厳格に分離する必要があります。

特権昇格リスクの回避策（iam:PassRole の制御）

エージェントの管理において、管理者が iam:PassRole 権限を保持している場合、自身に強力な権限を持つロールをエージェントに付与し、特権を昇格させるリスクがあります。

• ベストプラクティス: iam:PassRole 権限を付与する際は、Resource 句に特定のエージェント用サービスロールの ARN を明示し、ワイルドカード（*）の使用を厳禁とします。

アイデンティティが確立された後、次に守るべきはその通信経路です。

3. ネットワーク境界の確立：PrivateLink によるデータ通信の隔離

生成AIへのリクエストには機密情報や顧客データが含まれるため、パブリックインターネットを経由する構成は軍事レベルのセキュリティ基準では許容されません。通信を AWS バックボーン内に閉じ込める戦略的隔離が必要です。

AWS PrivateLink による Interface VPC Endpoint の構成

AWS PrivateLink を利用し、Bedrock 用の VPC エンドポイントを構築することで、トラフィックはパブリックインターネットを一切通過せず、AWS 内部ネットワークのみを通過します。

• エンドポイントポリシーの硬化: デフォルトのエンドポイントポリシーは「オープン」であり、VPC 内の誰でも Bedrock を呼び出せる状態です。これを「特定のアカウントおよび特定の IAM プリンシパルのみがアクセス可能」な制限的ポリシーに書き換えることが必須です。
• クロスリージョン推論の考慮: Source 8 が指摘するように、最新モデルでガードレールを適用する際、クロスリージョン推論プロファイルが必要になるケースがあります。この場合、エンドポイントポリシーでもリージョンを跨いだアクセスを適切に制御・許可する必要があります。

WAF と API Gateway によるエッジ防御

外部公開 API の場合は、AWS WAF と API Gateway をフロントに配置します。

• 地理的制限とレート制限: WAF を用いて特定の国からのアクセスを遮断し、さらに IP ごとのレート制限をかけることで、DDoS 攻撃や API の過剰消費によるコスト爆発を防止します。

通信経路の物理的保護に続き、やり取りされる「内容」の意味論的な安全性をガードレールで担保します。

4. セマンティック・セキュリティ：Amazon Bedrock Guardrails によるコンテンツ検閲

従来の WAF では、入力されたテキストの「有害な意図」を検知できません。Amazon Bedrock Guardrails は、Claude 4.5 や Llama 4 などの強力なモデルを安全に運用するための「意味論的な防護壁」として機能します。

6つの検閲カテゴリによるインパクト分析

1. 有害コンテンツのブロック: 暴力、ヘイト、性的表現をフィルタリング。組織のブランドリスクを直接的に低減します。
2. トピック制限: 「政治的意見」「財務アドバイス」など、AIが関与すべきでない領域を自然言語で定義し、役割を逸脱した挙動を封じ込めます。
3. ワードフィルタリング: 独自の禁止用語集を適用し、特定の製品名や不適切な用語を排除します。
4. PII（個人識別情報）の匿名化: 住所やクレジットカード番号を自動検出し、匿名化（リダクション）します。これはコンプライアンス遵守の要です。
5. 根拠チェック（Contextual Grounding）: 回答がナレッジベースの情報に基づいているか検証し、ハルシネーション（もっともらしい嘘）を物理的に抑制します。
6. カスタム論理ポリシー: 自動推論を通じて、複雑なビジネスルールや論理的整合性をチェックします。

重層的な安全モデルの設計

システムプロンプト（エージェントへの指示）による制約と、ガードレールによる独立した検閲を組み合わせることで、プロンプトインジェクションに対する防御層を厚くします。ただし、ガードレールは「非決定論的」な性質を持つため、100% の遮断を保証するものではなく、組織のリスク許容度に基づいた継続的なチューニングが必要です。

コンテンツの安全性が確保されたら、次は蓄積・転送されるデータの物理的保護を固めます。

5. データ保護：KMS による暗号化と機密情報の秘匿

Amazon Bedrock はデフォルトで推論データを学習に利用せず保持もしませんが、ガバナンスが極めて重要な環境では、デフォルト設定に頼らず「顧客管理鍵（CMK）」を導入し、完全な鍵の所有権を維持すべきです。

硬化要件：全レイヤーでの CMK 適用（Hardening Requirement）

「軍事レベル」のセキュリティを実現するには、Bedrock の全スタックにおいて CMK 暗号化を「明示的にオプトイン」する必要があります。デフォルトの暗号化は不十分であると定義してください。

• S3 データソース: ナレッジベースの元ファイルを保管するバケット。
• ベクトルストア: OpenSearch Serverless 等のインデックス。
• 一時ストレージ: データのインジェクション（取り込み）プロセスで利用される一時的な保存領域。
• モデル呼び出しログ: 監査のためにオプトインした S3 または CloudWatch Logs。

PII 検出によるコンプライアンス対応

ガードレールによる PII の自動リダクションは、GDPR や HIPAA 等の厳格なコンプライアンス要件を自動的に満たすための強力な手段です。これにより、意図せずログに残ってしまう機密情報の漏洩リスクを最小化できます。

保護策が正しく機能しているかを証明するためには、高度な監視体制が必要です。

6. モニタリングとガバナンス：可視性の確保と異常検知

AI システムの挙動は従来のロジックよりも不確実性が高いため、CloudWatch を中心としたリアルタイム監視が運用のレジリエンスを決定づけます。

監視メトリクスとアラート設計の「落とし穴」

• InvocationsIntervened の監視: ガードレールが介入した回数を示すこのメトリクスは、プロンプトインジェクション攻撃やユーザーの不適切な利用を検知する最重要のシグナルです。
• 権限の Gotcha: AgentCore のサービスロールには、AWS/Bedrock/Agents 名前空間に限定した cloudwatch:PutMetricData 権限を明示的に付与する必要があります。これが欠落していると、エージェントのメトリクスが CloudWatch に表示されないという運用上の致命的なミスに繋がります。
• モデル呼び出しログの有効化: 監査（フォレンジック）のために、フルペイロードのログ出力を CMK 暗号化された S3 へ記録するよう設定してください。

CloudTrail と KMS の監査ログを組み合わせることで、アイデンティティ、暗号化、アクセスの三位一体のトレーサビリティを確立します。

7. 実装と継続的改善：IaC による自動化と Well-Architected の適用

セキュリティ構成を常に最新かつ堅牢に保つためには、手動設定を排除し、Infrastructure as Code (IaC) による自動化が必須です。

2026 年の標準的な運用モデル

• Serverless Framework V.4「AWS AI Stack」の活用: V.4 では Bedrock LLM のデプロイメントが最適化されています。これを活用することで、セキュリティ設定済みのボイラープレートを一貫性を持ってマルチリージョンに展開できます。
• Kiro によるスペック駆動開発: AI エージェント IDE である Kiro を活用し、セキュリティ仕様書から IaC コード（CDK や Serverless Framework）を自動生成することで、設計と実装の乖離を防ぎます。
• Lambda Durable Functions と Managed Instances: 複雑なステートフルワークフローには Lambda Durable Functions を採用し、アーキテクチャを簡素化します。また、高性能な推論が必要な場合は Lambda Managed Instances（GPU/メモリ最適化）を選択することで、サーバーレスの利便性と EC2 レベルのパフォーマンスを両立させます。

Amazon Bedrock 安全運用チェックリスト

1. IAM: 全てのロールに iam:PassRole のスコープ制限とリソースベースポリシーが設定されているか？
2. Network: PrivateLink を使用し、エンドポイントポリシーを「制限的」に変更済みか？
3. Guardrails: InvocationsIntervened のアラート設定と、PII 匿名化が有効か？
4. Data: S3、ベクトルDB、一時ストレージのすべてに CMK 暗号化を明示的に適用しているか？
5. Monitoring: cloudwatch:PutMetricData 権限が AWS/Bedrock/Agents 名前空間に付与されているか？

この設計指針を継続的に評価・改善することで、Amazon Bedrock を活用したビジネスの成長と、エンタープライズが求める最高水準のセキュリティを両立させることが可能になります。