はじめに こんにちは、 ネクストモード株式会社 の sobar です。
こんにちは、ホワイトバードです。
ネクストモードのブログでは、生成AIのセキュリティ対策についての記事が多数あります。（生成AIセキュリティ対策シリーズ）
OktaやNetSkope、CrowdStrikeを使用した実装記事が中心となりますが、そもそもどういう観点で生成AIのセキュリティを考えていくべきなのかをAWS Well-Architected FrameworkのGenerative AI Lensを参照しながら少し考えてみたいと思います。
そもそも、AIにおけるセキュリティとは？
これまでITの世界ではファシリティやネットワーク、アプリケーションといったレイヤーに分けてセキュリティを導入してきました。生成AIにはこれまでのWebアプリケーションに求められる要素に加えて、ハルシネーション対策が必要、社会的なモラルに反するような不健全な回答をしないといった生成AI特有の考慮事項があることは感覚的に理解されている方は多いと思います。
AIのセキュリティのレイヤーを言い換えると、「Responsible AI（責任あるAI ）」という概念にたどり着きます。Responsible AI自体に統一的な定義はありませんが、いくつかの団体や企業による提唱をまとめると、おおむねこのような要素を含んでいます。
- Fairness（公平性）
- Explainability（説明可能性）
- Privacy and security（プライバシーの安全性）
- Safety（安心性）
- Controllability（可制御性）
- Veracity and robustness（真実性と堅牢性）
- Governance（統一性）
- Transparency（透明性）
これらの要素を具体的な技術で実装していくにはどうしたらよいか？というのが次に考えることになっていきます。
AWS Well-Architected Framework Generative AI Lensとは？
Responsible AIを実装するためにどのような設計が必要かを考えるには、Frameworkを使用したいと思います。AWSには、Well-Architected Frameworkというものがあります。AWSでシステムを作る際に次の6つに分けたガイダンスとベストプラクティスが用意されています。
- Operational Excellence（運用の優秀性の柱）
- Security（セキュリティの柱）
- Reliability（信頼性の柱）
- Performance（性能の柱）
- Cost Optimization（コスト最適化の柱）
- Sustainability（持続可能性の柱）
Well-Architected Frameworkには一般的なシステムだけではなく、Lensと呼ばれる特定の業界や用途に特化したものが用意されています。生成AIのシステムには"Generative AI Lens"が用意されているので、本内容を見ながらAIのセキュリティについて考慮すべき事項をまとめていきたいと思います。執筆日の時点では2025年11月19日版が最新版となります。（Generative AI Lens - AWS Well-Architected Framework）
執筆時時点では日本語訳は提供されていないため、簡単に日本語訳しながら解説していきたいと思います。
AWS Well-Architected Framework Generative AI Lensにおける「セキュリティの柱」
AWS Well-Architected Framework Generative AI Lensにおける「セキュリティの柱」（Security - Generative AI Lens）におけるベストプラクティスは次の項目で形成されています。
包括的なアクセス制御
- 全てのコンポーネントに対する最小権限の原則を適用する
- 基盤モデル
- データストア
- エンドポイント
- エージェントのワークフロー
データと通信フローの制御確保
- システムコンポーネントと外部入力間のやり取りの保護
- プライベートネットワーク通信
- ユーザ入力のサニタイズ
- プロンプト（システムプロンプト、入力プロンプト）のセキュリティ保護
- データアクセスの制御
- トレーニングデータの保護
- データの整合性の確保
セキュリティ境界の監視
- コントロールプレーンとデータプレーンの両方に監視・制御のメカニズムの構築
- アクセス監視
- 応答のフィルター
- ガードレールの実装
AIシステムの挙動制御
- AIがデータとやり取りし、ワークフローを実装する際のガードレールと境界の実装
- 応答に対するセキュリティ制御
- 安全なプロンプトカタログ
- エージェントの挙動の定義
これらのセキュリティの柱を守っていくことで、公平性や説明可能性、プライバシーの安全性といったResponsible AIを実現する要素を実装していきます。
技術的な実装ガイダンスは、次の項目になります。、
エンドポイントセキュリティ
エンドポイントのセキュリティはおもに基盤モデルへのアクセス、AIエージェントがデータストアにアクセスする際のアクセス権限となります。エンドポイントセキュリティはネットワークやアプリケーションのレイヤーでも考慮されますが、AIのセキュリティにおいては次の要素を考えていきます。
- 基盤モデルおよびAIエージェントのエンドポイントへのアクセス
- ID基盤の実装（AWS IAMやBedrock AgentCore Identityや、OktaなどのIdP）
- エンドポイントAPIでの認証認可
- AIエージェントとアプリケーション間のプライベートネットワークの実装
- プライベートネットワーク経由での通信の実現（インターフェースVPCエンドポイント、VPC内部での実装など）
-
- 転送中の暗号化
- データストアにアクセスする際の最小権限
- ID基盤の実装（AWS IAMやBedrock AgentCore Identityや、OktaなどのIdP）
- MCPなどの外部ツール利用の認証認可（Bedrock AgentCore Identity、Bedrock AgentCore Gatewayなど）
- 基盤モデルおよびAIエージェントへのアクセス監視
- 基盤モデルの呼び出しの記録（AWS CloudTrailやCloudWatch Logsなど）
- AIエージェントのトレース（CloudWatch Gen AI Observabilityなど）
- データストアのアクセスログやクエリログの実装
回答の検証
基盤モデルやAIエージェントが有害、偏向的なコンテンツを生成したり、ハルシネーションを起こしたりすることもFairnessやSafetyの観点でAIのセキュリティとして考慮する必要があります。
- 有害または不正確な応答を軽減するためのガードレールの実装
- CoTやLoT、few-shotプロンプティング、RAGなどのエンジニアリングでの実装
- 特定のフレーズやトピックのブロックやフィルタリング（Bedrock GuardRailsなど）
- 免責事項の表示
イベントのモニタリング
セキュリティとパフォーマンスの向上のために、これまでのアプリケーションレイヤのObservabilityに加えて、AIエージェントの思考のトレースやツールの呼び出し記録などを残しておく必要があります。具体的には、次の要素を検討していきます、
- パフォーマンス監視
- 応答時間、レイテンシ、スループット
- リソース使用率
- トークンの使用状況
- バッチ処理の効率とキューの長さ
- モデルの呼び出しの長さ
- 回答品質と精度の監視
- 完了率と成功率
- 回答品質スコア
- コンテンツの安全性対策
- ハルシネーション率と精度
- プロンプトの有効性と完了の関連性
- ユーザー評価
- セキュリティ監視
- 認証認可の記録
- プロンプトインジェクション攻撃の監視
- アクセスパターンと異常な動作のログ記録
- レート制限とクォータの使用状況
- データ漏洩の監視
- コスト監視
- トークンの使用状況と関連コスト
- リソース利用料
- API呼び出し回数
- ストレージとデータ転送コスト
- モデルのトレーニングコスト
- 呼び出しログや証跡ログの監視
- リクエストと応答の詳細なログ
- ユーザー操作とシステム変更のログ記録
- モデルのバージョン変更と更新ログ
- 構成変更ログ
- コンプライアンス関連の監査証跡（CloudTrailなど）
- コンプライアンス監視
- データ保護コンプライアンス
- 個人情報の取り扱い
- 法律等の規制要件の順守確認
- ユーザー同意事項の管理
- 地理的データ制限の監視（制限されたエリアからのアクセスがないか）
プロンプトのセキュリティ
AIエージェントはプロンプトが書き換わることで別の振る舞いに変わってしまうため、システムプロンプトなどのAIエージェントが基盤モデルとどう対話するかを定義するプロンプトの管理はアプリケーションと切り離して管理するのがベストプラクティスとなっています。また、こうすることでアプリケーションの変更を行うことなくプロンプトの変更だけでAIエージェントの振る舞いを調整することもできるため、プロンプトの変更は最小限の許可された管理者に委ねることもできるようになります。具体的には、次の要素を検討していきます。
- 安全なプロンプトカタログの実装
- プロンプトとそのバージョンの管理（Bedrock Prompt Management Catalog、専用のリポジトリなど）
- プロンプトカタログへの最小権限と、職能の定義
- プロンプトの最適化（Bedrock Flowsなど）
- プロンプト変更のテスト
- ユーザー入力のサニタイズ及び検証
- 個人情報の入力、悪意のある入力の抑止など、ユーザー入力の指示の検証（Bedrock Guardrailsなど）
AIエージェントの権限管理
AIエージェントは強力ですが、無制限にデータにアクセスできてしまうことによる情報漏洩や、本来の目的を超えたアクションを実行してしまう可能性を防止する必要があります。
- エージェントワークフローへの最小権限アクセスと権限境界の実装
- モデルアクセスの許可
- ツール・データストアの利用許可や承認フロー（Bedrock AgentCore IdentityやGatewayなど）
データの健全性
基盤モデルのトレーニングやカスタマイズを行う場合、学習データに不適切なデータが含まれていないようにデータレイヤーの検証を行う必要があります。また、RAGなどで外部データを活用する場合でもデータ自体に不適切なデータが含まれないよう、データ作成時に検証を行う必要があります。
まとめ
今回はAWS Well-Architected FrameworkのGenerative AI Lensのセキュリティの柱を簡単に振り返りながら解説してみました。商用レベルで検証を行う場合にはぜひ検討していきたい項目ですね。
その他、基盤モデルおよびAIエージェントの脅威については、OWASP Top 10にもまとめられている要素にもなりますので、これらも確認していく必要があります。セキュリティレベルを適切に保ちながら、Responsible AIを実現していきたいところです。
