【セッションレポート】実社会のセキュリティを支える生成 AI 活用ユースケース (AWS-61) #AWSSummit

2025 年 6月 26 日に行われた AWS Summit Tokyo 2025 に現地参加してきました。
『実社会のセキュリティを支える生成 AI 活用ユースケース(AWS-61)』のセッションを聴講したので、そのレポートになります。

セッション概要

実社会における生成 AI のユースケースはたくさんありますが、セキュリティの改善ではどうでしょうか。このセッションでは、インシデント対応、コンプライアンス要件への対応、脅威分析などの具体的なユースケースに関するアーキテクチャやデモを通じて、セキュリティ業務を自動化・効率化するために生成 AI を活用する方法を学んでいただけます。

セッションスピーカー

アマゾン ウェブ サービス ジャパン合同会社
シニアセキュリティソリューションアーキテクト

勝原 達也氏

冒頭

生成AIが世の中に溢れている現状。
AWSは、生成AIを単なる誇張やバズワードにはしてはいけない考えを持っている。

生成AIのセキュリティ活用には３つの視点がある

• 生成AIのセキュリティ
• セキュリティ改善のための生成AI
• 生成AIを活用した脅威から保護するためのセキュリティ

今回セッションのテーマは2番目の「セキュリティ改善のための生成AI」活用をとりあげる。

最初に忘れてはいけないこととして、生成AIはあくまでツールであることを念頭に置くよう前置きされていました。

生成AIはどう役に立つか

生成AIのセキュリティ活用には、様々な領域がある。
このあと、全ての領域を網羅したユースケースデモをご紹介いただきました。

生成AIの頻出課題

• ハルシネーション
  • 特にソリューションに組み込む場合はハルシネーションが起こることを考慮しなければいけない点で悩ましい
• プライバシー
• 品質保証
• 過剰な代理行為
  • 生成AIが実行できる権限を正しく設定する必要がある
  • 生成AIに任せた途端、アクセスが過剰になることは多く、重大な情報漏洩や変更に結びつくことを防ぐ

ユースケースの紹介

ここから先はシナリオをベースに、AWS上で生成AIを使ったセキュリティ改善の複数のデモを行っていただきました。
本記事では、デモの概要をテキストでのみお送りします。

No1. セキュリティインシデント対応の活用

• ペルソナ: インシデントレスポンダー
• 課題: 脅威インテリジェンスを使った分析・対応が主のロールだが、対応の際に必要なクエリの記述やコードの作成はある程度時間がかかる
• 生成AIを使ったソリューション: 自然言語によるクエリアシスタント

生成AIを使ってSecurity Hubの検出結果を要約し、生成AIを使って修正のためのスクリプトを作成してもらう、人間が目で問題のないコードがレビューした後、そのままCLI経由でスクリプトを実行し修復を行う。
自然言語を使いながら、実際にコードを書くことなく、半自動で設定ミスの修復処理を実現する、というデモを行っていました。

デモでは、実際のプロンプトの紹介とSageMaker Notebookでの対話の様子を見ることができます。

生成AIを使う注意点として、一貫性のある結果は得られないことでインシデント対応では問題となるケースがあることを取りてておりました。
この注意点における対策には、モデルパラメータの「温度=0」にしてランダム応答を極力防ぐことが上げられていました。
繰り返してLLMは非決定性であることは忘れないよう喚起がありました。

No.2 監査のサポート

• ペルソナ: コンプライアンス・リスク関係者
• 課題: コンプライアンスと統制に関する知識が必要で、膨大なフレームワークから適切な内容を参照するケースが多い。正しい文脈の読み取りと適切な回答を得ることでコンプライアンスチームのワークロードの低減を図りたい

AWS Systems Managerで収集した情報をもとに、SBOMの標準出力形式のCycloneDXに変換する。
自然言語を使って、変換をお願いするだけで、Systems Managerからの冗長な情報からCycloneDXへの変換を数分で実施する、というデモを実施いただきました。

その他、セキュリティチェックシートの回答を生成AIに説明させる、なんてこともやっていました。
こちらは、Amazon Bedrock Knowlege Basesを使ってRAGを構築することでNIST、FISC、PCI-DSSなどのセキュリティフレームワークをもとに回答が行えるような仕組みです。
大量の文書の中から、文脈にあった部分を素早く特定して業務を進めていくのに役立つソリューションを紹介されいます。

No.3 セキュリティテストの自動生成

• ペルソナ: スレットハンターやセキュリティテスター
• 課題: 環境の脆弱性、脅威モデリングと修復を行う際のテストを書くことや実行に時間をとられてしまう

ここでは、ネットワーク環境設定がセキュアな状態になっているかを確認し、結果の要約と不正な設定があれを注意を促す形で表示。修正とその結果をCSV出力するということを生成AIで行います。
Amazon Q Developerを使うことで対話型で生成AIに指示を行います。
流れは、生成AIがセキュリティグループの設定をスクリプトで抽出、生成AIが出力結果を見やすいように表示、生成AIが修正のスクリプトを作成、人間が出力結果の確認とスクリプトの内容を確認した後、生成AIに実行の指示を与えます。

No.4 セキュリティチームの能力を誇張する

このデモでは、Amazon Q Businessを使ってセキュリティチャットボットを構築します。
Amazon Q Businessがプライベートな環境で社内のポリシー規定を参照できるようにしておきます。
中央集権的な体制になりがちなセキュリティチームのワークロードを軽減するために、社員がチャットボットを使って、社内規定に沿ったアドバイスを受けることができる、といったデモを行われました。

No.5 デセプション（おとり）プラットフォーム

ペルソナ: スレットハンター/ブルーチーム
課題: 攻撃者がどんな資産に興味を持っていて、どんな手段で攻撃を仕掛けてくるのかを知っておくことをミッションにブルーチームはおとりプラットフォームを構築します。しかし、意図的に作った脆弱なイメージの作成と保守や構築工数が大きくかかってしまいます

外部公開されたWebサイトにおとりプラットフォームの仕組みを構築します。
具体的な方法までは紹介されていませんでしたが、CloudFront、WAFからアクセスされたトラフィックのうち、攻撃パターンを特定してラベル付けし、攻撃と判定されたリクエストに対して、Amazon Bedrockがダミーデータを返すように生成AIを組み込みます。
突破されたように攻撃者をあざむくことで、興味を持つユーザーや攻撃の方法を特定し、セキュリティ対策のデータとして活用する方法を紹介されていました。

こちらのユースケースでは、高いリスクを許容した上で効果を得るようなセキュリティ戦略がとれる場合のみ検討するべき、と注意点が述べられていました。

セッションのまとめ

最後に以下のようなまとめでセッションはクローズしました。

• 生成AIは人間を代替するものではない
• 依然として人間が困難課題に取り組む必要がある
• 使い慣れたAWSサービスのアーキテクチャと生成AIを活用することができる
• AIに関する広範なトレーニングを行うよりも、まずはすぐにやってみることが大事

筆者からのまとめ

こちらは AWS Summit Japan 2025 のいくつかの最終セッションの一つでもありました。
私自身 AWS Summit Japan は現地初参加でしたが、セッションや展示物を含め非常にまなびの多いイベントで感動しました。
またオンラインでは感じることのできない気づきやこのイベント自体の素晴らしさ（本当に多くの学びを得ることができるイベントだと思います）を知ることができました。
当セッションにおいても、最後のセッションにふさわしく、多くの学びを得ることができました。
動画が公開されましたら、ぜひご視聴いただくことをおすすめいたします。