aws-recipe-user 🧩 この記事でわかること
-
re:Invent 2025 は 「エージェント × セキュリティ」 が強く打ち出された年だった
-
特に以下3つが、生成AIシステムの「安全な本番運用」に直結する
- Amazon Bedrock AgentCore Policy / Evaluations
- AWS Security Agent（セキュリティ専用フロンティアエージェント）
- S3 Vectors など、RAG基盤のセキュア化につながるデータ系アップデート
全体トレンド：“エージェントを安全に回すための土台づくり”
re:Invent 2025 の基調講演では、NovaやTrainium3 などのインフラに加え、「Frontier Agents」「AgentCore」「Security Agent」「DevOps Agent」など、エージェント前提の世界観が前面に出されました。
一方で、エージェントは外部API・コード実行・RAG・権限管理など、これまでのLLMチャット以上に “セキュリティの踏み外しポイント” が増えます。
そのため今年は、
- エージェントの権限を ポリシーで制御する
- エージェントのふるまいを 継続的に評価する
- アプリ全体を AIで「攻めのセキュリティ診断」する
- ベクトルストアやログ基盤を セキュアに一元管理する
といった、「生成AIを安全に回すための土台」がかなり整ってきた印象です。
以下、生成AIセキュリティ観点で特に重要な3つをピックアップします。
1. Amazon Bedrock AgentCore Policy / Evaluations
―「エージェントに何をさせてよいか」をポリシーで固める
1-1. Policy 機能：エージェントの権限を Cedar で制御
re:Invent 2025 で、Amazon Bedrock AgentCore に Policy 機能（プレビュー） が追加されました。
ポイントは：
-
Cedar などのポリシー言語で
- 「誰が (principal)」
- 「どのエージェント／どのツールに対して (resource)」
- 「どの操作を許可／拒否するか (action)」
を厳密に定義できる
- 「このエージェントは “読み取り専用のRAG検索” だけ 許可」
「このユーザロールでは 顧客PIIを含むインデックスには到達不可」
のような制御がコードではなく ポリシーとして一元管理 できる
「危険なツール呼び出しの制御」を、Bedrock標準機能としてデザインできるようになりつつあります。
1-2. AgentCore Evaluations：エージェントのふるまいを継続評価
同時に AgentCore Evaluations も発表され、エージェントの動作ログをもとに、以下のような尺度でスコアリングできるようになりました。
- タスク達成度
- 応答の有用性・正確性
- 有害性 / セキュリティ違反の有無（攻撃的・不適切・ポリシー違反など）
これにより、
- 「このエージェントは、どのくらいの確率で危険な出力をするのか？」
- 「特定のツール呼び出しパスで、失敗やポリシー違反が多発していないか？」
を定量的にトラッキングできます。CloudWatch や GenAI Observability との連携により、メトリクス / トレースベースで監視可能な点も大きいです。
1-3. 実務的な示唆
-
「エージェントPoCが動いたので、そのまま本番へ」ではなく、
- Policy で権限境界を固める
- Evaluations で “安全性と品質の振る舞い” を見ながら SLO を設計する
-
RBAC/RAGガバナンス（Day15）で決めたルールを、AgentCore Policy に落とし込む イメージ
2. AWS Security Agent
―「AIでAIを攻める」アプリケーションセキュリティ
2-1. 概要：設計〜コード〜ペンテストまで“AIセキュリティ担当”
re:Invent 2025 では、AWS Security Agent が新サービスとして発表されました（プレビュー）。
公式ブログによると、Security Agent は以下のような特徴を持つ セキュリティ専用フロンティアエージェント です。
-
アプリケーションのライフサイクル全体（設計・コード・インフラ）を通じて セキュリティリスクを自動的に洗い出し・改善案を提示
-
具体的には：
- 設計レビュー：アーキ図や要件からセキュリティ要件抜けを指摘
- コードレビュー：CI/CD と連携し、脆弱なコードパターンを検出
- ペネトレーションテストの補助：脆弱なエンドポイント候補を提示
- 結果を Security Hub など既存のセキュリティ基盤と連携
生成AIを使ってアプリを作るだけではなく、生成AIを使って“アプリとそのAI機能を攻めさせる” という立ち位置になっています。
2-2. 生成AIセキュリティへの効きどころ
Security Agent 自体は「LLM専用ツール」というより、アプリ全体のセキュリティ向けですが、次のような点で、生成AI機能にかなり効きます。
- プロンプトインジェクションの入り口になりがちな Web エンドポイントの設計漏れを早期に発見
- LLM アプリ側の認可抜け・入力バリデーション不足をコードレビューで指摘
- Bedrock や S3 Vectors、RAG 構成の誤設定などを、
セキュリティベストプラクティスに基づいて検査
「AI機能だけ単体で守る」のではなく、アプリ全体のセキュリティ診断フローの中に、生成AI機能も組み込まれていくイメージです。
2-3. 実務的な示唆
-
これまで「アプリケーションセキュリティ」と「生成AIセキュリティ」を分けて考えていた組織にとって、両方を一気通貫でレビューできる“入口” になり得る
-
プロジェクトとしては
- まずは Security Agent を 既存のCI/CD や Security Hub と連携して試す
- その後、生成AI機能を含むアプリを流し込んでベースラインを作る
-
LLMレッドチーミングを 半自動化する相棒としても検討価値あり
3. S3 Vectors と周辺アップデート
―「RAG基盤をセキュアかつ運用可能にする」方向性
3-1. S3 Vectors GA：“S3ネイティブのベクトルストア”
re:Invent 2025 では、S3 Vectors が GA（正式リリース）とされ、東京リージョンでも利用可能になりました。
S3 Vectors は、ざっくり言うと：
-
Amazon S3 上に ネイティブなベクトル検索機能 を統合したサービス
-
RAG 用のベクトルストアを、S3 の
- IAM
- 暗号化
- バケットポリシー
- アクセスポイント
といった既存のセキュリティ機構の上で運用できる
これにより、
- 「RAGだけ別ベンダーのベクトルDBを立てる → セキュリティ/運用がバラバラ」
- 「S3のアクセス制御とベクトルDBのACLが二重管理でつらい」
といった課題を、かなり軽減できます。
3-2. GuardDuty / Security Hub / CloudWatch との組み合わせ
同じく re:Invent 2025 では、
- GuardDuty Extended Threat Detection for ECS/EC2 グループ
- 新しい Security Hub の GA`
- CloudWatch のユニファイドデータストア（ログ基盤強化）
といったアップデートも発表されています。
これら自体は「生成AI専用」ではないものの、
- S3 Vectors や Bedrock を利用した RAG/エージェントの実行ログ を CloudWatch に集約
- Security Agent / GuardDuty / Security Hub と組み合わせて RAG まわりの挙動や権限逸脱を検知・集約
- Day20 で述べたような LLM可観測性 / SIEM連携 を、AWS内で完結させやすくなる
という意味で、生成AIセキュリティ運用の“インフラ層” として重要です。
3-3. 実務的な示唆
-
RAG を AWS 上で組むなら：
- ベクトルストア：S3 Vectors
- アクセス制御：IAM / バケットポリシー / AgentCore Policy
- 可観測性：CloudWatch + GenAI Observability
- セキュリティモニタリング：GuardDuty / Security Hub / Security Agent
という形で、「フルスタックAWSで閉じる」構成をかなり現実的に描けるようになった
4. まとめ：“エージェント前提”の時代に備えるセキュリティ設計へ
今年の re:Invent 2025 を「生成AIセキュリティ」の観点だけで振り返ると、主なメッセージは次の3つに整理できます。
-
エージェントにはポリシーと評価が必須
- Bedrock AgentCore Policy / Evaluations によって、
「何をしてよいか」「実際どう振る舞っているか」を管理する時代に入った。
- Bedrock AgentCore Policy / Evaluations によって、
-
AIでアプリを“攻める”Security Agent の登場
- 設計〜コード〜ペンテストまで、
AIを使ったセキュリティ診断を標準化しようという流れが加速している。
- 設計〜コード〜ペンテストまで、
-
RAG・ログ・監視をAWS内で完結させる基盤づくり
- S3 Vectors / 新Security Hub / CloudWatch 強化等により、
「RAGを安全に回すためのストレージ＋監査・監視」が整い始めた。
- S3 Vectors / 新Security Hub / CloudWatch 強化等により、
📌 次の一手（社内でやるべきこと）
この記事を読んだあと、実務担当としては例えば以下のようなステップが現実的です。
-
自社ユースケースを棚卸し
- 既に or 検討中の Bedrock / RAG / エージェント案件をリストアップ
-
「どこでポリシーを効かせるか」を構想
- RAGの権限、Agentが叩くツール、外部API などを洗い出し
- AgentCore Policy / IAM / RBAC のどこに境界線を引くかを検討
-
Security Agent / GenAI Observability の PoC
- 既存アプリの一部を対象に、「AIでAIを攻める」診断フローを試してみる
-
S3 Vectors 前提のRAGリファレンス構成を描く
- S3 Vectors + GuardDuty + Security Hub でどう実現するかスケッチする
本記事は、ナレッジコミュニケーションによる生成AIセキュリティ支援の実務知見をもとに執筆しています。
安全にAIを活用するための導入支援・運用設計をご希望の方は、ぜひご相談ください。
👉 AIセキュリティ支援サービス
