セキュリティ業務で活用可能な生成AI事例 — SOC分析からクラウドセキュリティまで

生成AIがセキュリティ担当者を代替するという話は誇張に近いでしょう。しかし、セキュリティ業務の大部分を占める読み込み、要約、比較、ドラフト作成、反復的な検索作業を削減するツールであることは明らかです。

セキュリティチームが日々直面するデータは膨大です。

数百のセキュリティアラート
長くて複雑なログ
難読化されたスクリプト
新たに公開される脆弱性と脅威情報
クラウドとKubernetesの設定ファイル
セキュリティポリシー、監査結果、インシデントレポート

問題は情報が不足しているのではなく、多すぎるために重要なシグナルをタイムリーに見つけるのが難しいことです。生成AIは、この情報を人間が判断しやすい形に変換するのに特に役立ちます。

この記事では、製品紹介よりも実際のセキュリティ業務を基準に、生成AIをどこに適用できるかを探ります。各事例ごとに、何を任せられるか、どのような結果を期待できるか、そして人間が何を検証すべきかをまとめています。

生成AIがセキュリティアラートとクラウド情報をアナリストの判断資料として整理する様子

生成AIがセキュリティ業務で得意なこと

生成AIの利点は、すべての攻撃を自動的に見つけ出す能力ではありません。それは、異なる形式の情報を整理し、人間が次の判断を下すために必要なコンテキストを作成する能力です。

業務タイプ	生成AIが得意なこと	人間がすべきこと
要約	長いアラートとログを事件の流れに整理	元の証拠と一致するか確認
変換	自然言語をKQL、SPL、SQL、Sigmaのドラフトに変換	クエリの範囲・フィールド・パフォーマンス検証
分類	フィッシング疑いメールや脆弱性の優先順位提案	誤検知・未検知と業務影響の判断
説明	難読化コード、攻撃手法とセキュリティ設定の説明	サンドボックスと実際の環境で検証
ドラフト作成	インシデントレポート、検知ルールと対応手順の作成	承認、責任判断と最終実行
比較	ポリシー・設定・バージョン間の差異分析	最新の公式ドキュメントと運用条件の確認

肝心なのは、生成AIを最終的な判定者ではなく、分析補助者として位置づけることです。

事例 1: セキュリティアラートとインシデントタイムラインの要約

SOCアナリストは、一つのインシデントを調査するために、エンドポイント、メール、アカウント、ファイアウォール、クラウドのログを行き来する必要があります。同じ事象に対して複数の製品がそれぞれ異なるアラートを生成することもあります。

生成AIは、以下のデータを一つの時系列順に整理できます。

初回検知時刻
関連ユーザーと機器
疑わしいIP・ドメイン・ファイルハッシュ
実行されたプロセスとコマンド
初期侵入、権限昇格、内部移動などの攻撃段階
未分析の証拠と追加確認項目

例えば、次のようにリクエストできます。

아래 경보와 로그를 시간 순서로 정리해줘.

1. 확인된 사실과 추정을 분리한다.
2. 사용자, 호스트, IP, 프로세스 관계를 표로 만든다.
3. MITRE ATT&CK 전술과 기법은 근거가 있는 경우에만 연결한다.
4. 누락된 조사 항목을 질문 형태로 제시한다.
5. 격리나 차단 작업은 실행하지 말고 제안만 한다.

Microsoftの公式Security Copilotの事例も、複数のアラートを含むインシデントを要約し、攻撃段階を説明し、対応ガイドを提供する流れを提示しています。

ただし、AIが作成したタイムラインは元のイベントではありません。最終報告書には、SIEMイベントID、タイムスタンプ、クエリ、および元の証拠を一緒に残す必要があります。

事例 2: アラート優先順位の分類と誤検知分析

すべてのアラートを同じ順序で処理すると、重要なインシデントが後回しになります。生成AIは、アラートの深刻度自体よりも、組織のコンテキストを含んだ優先順位を提案するのに役立ちます。

例えば、以下の情報を一緒に入力します。

アラートの種類と検知ルール
攻撃対象資産の重要度
インターネット露出の有無
ユーザー権限と職務
既知の脆弱性の存在有無
最近の変更作業
同一オブジェクトの過去のアラート

結果は、単に危険・安全に分けるよりも、次の形式が良いでしょう。

判定項目	出力例
暫定優先順位	緊急、高、中、低
判断根拠	確認されたログと資産の重要度
不確実性	欠落データと相反するシグナル
追加調査	必要なSIEM・EDRクエリ
推奨措置	分析、隔離検討、ユーザー確認

AIが低リスクと分類したという理由だけで、アラートを自動終了してはなりません。特に管理者アカウント、ドメインコントローラー、CI/CD資格情報、および外部公開システムには、別途保守的なポリシーが必要です。

事例 3: 脅威インテリジェンスの要約とIOCの補強

新しい攻撃キャンペーンやCVEが公開されると、セキュリティ担当者は複数のレポートを読み、自社の環境と関連があるかを判断する必要があります。

生成AIに公式勧告文と信頼できる脅威インテリジェンスを提供すると、以下の作業を迅速に実行できます。

攻撃者の目標と主要なTTPの要約
IOCからIP、ドメイン、URL、ハッシュの抽出
MITRE ATT&CK手法への関連付け
影響を受ける製品とバージョンの整理
自社資産リストとクロス比較するための質問生成
検知と緩和策のドラフト作成

첨부한 공식 권고문에서 확인된 사실만 사용해 다음을 작성해줘.

- 영향받는 제품과 버전
- 악용 전제조건
- 침해지표 목록
- MITRE ATT&CK 연결과 근거 문장
- 우리 환경에서 확인할 자산·로그·쿼리
- 패치 전 임시 완화책

문서에 없는 내용은 추측하지 말고 '확인 필요'로 표시해줘.

ここで重要なのは、出所追跡です。AIの要約だけを保存するのではなく、原文URL、公開日、CVE番号、および引用の根拠を一緒に保存する必要があります。

事例 4: 自然言語で脅威ハンティングクエリのドラフトを作成

SIEMは強力ですが、製品ごとにクエリ言語が異なります。Microsoft SentinelのKQL、SplunkのSPL、一般的なSQL、EDR固有の文法をすべて熟練して扱うのは困難です。

生成AIは、自然言語の要件をクエリのドラフトに変換したり、既存のクエリを説明したりするのに役立ちます。

Microsoft Defender Advanced Hunting용 KQL 초안을 작성해줘.

목표: 최근 24시간 동안 Office 프로세스가 PowerShell을 실행한 사례 탐지
필수 출력: 시간, 장비명, 사용자, 부모 프로세스, 명령줄, SHA256
제외: 승인된 자동화 계정 sec-automation
주의: 실제 테이블과 필드가 없으면 임의로 만들지 말고 확인이 필요한 필드로 표시

AIが作成したクエリは、すぐに運用検知ルールとして登録してはなりません。

スキーマとフィールド名を確認します。
短期間と制限されたデータで実行します。
結果サンプルを元のイベントと比較します。
クエリコストと実行時間を確認します。
誤検知除外条件が攻撃者の迂回経路にならないか検討します。

良い活用方法は、クエリ生成を任せきりにするのではなく、アナリストが検証可能な最初のドラフトを迅速に得ることにあります。

事例 5: 疑わしいスクリプトとコマンドラインの分析

PowerShell、Bash、JavaScript、およびマクロは、攻撃と正規の自動化の両方に使用されます。生成AIは、長いコマンドラインを分割し、各オプションの意味を説明し、難読化の階層を識別するのに役立ちます。

可能な作業は以下の通りです。

Base64とURLエンコーディングの識別
PowerShell実行引数の説明
ファイルダウンロードと実行フローの要約
ネットワーク接続ターゲットの抽出
永続化動作候補の識別
調査すべきファイル・レジストリ・プロセスの提案

しかし、分析対象のコードをAIが直接実行させてはなりません。復号化されたスクリプトは隔離されたサンドボックスで静的・動的分析を行うべきであり、AIが安全だと説明したコードも信頼してはなりません。

また、公開型AIサービスに実際のマルウェアサンプル、顧客情報が含まれるログや内部パスをそのままアップロードしてはなりません。組織が承認したセキュリティ境界内で使用するか、機密情報を削除する必要があります。

事例 6: 検知ルールとSigmaルールのドラフト作成

新しい攻撃手法を把握した後には、それを検知可能な条件に変換する必要があります。生成AIは、分析文をSigmaルールの最初のドラフトに変換できます。

다음 행위를 탐지하는 Sigma 규칙 초안을 작성해줘.

- Windows에서 rundll32.exe가 원격 URL을 인수로 사용
- 부모 프로세스와 전체 CommandLine 포함
- ATT&CK 매핑에는 근거를 주석으로 남김
- 정상 관리 도구와 충돌할 수 있는 오탐 사례 제시
- 운영 적용 전 필요한 로그 소스와 감사 정책 명시

検討すべき項目は明確です。

必要なログが実際に収集されているか
フィールド名が対象SIEM変換器と合っているか
大文字・小文字とパスの変形を処理するか
攻撃者が容易に迂回できる文字列一つに依存していないか
正常なソフトウェア展開と衝突しないか

AIはルール作成時間を短縮できますが、検知品質はテストデータと継続的なチューニングによって決定されます。

事例 7: 脆弱性優先順位とパッチ影響分析

脆弱性管理において、CVSSスコアが高い項目から処理するだけでは不十分です。実際のリスクは、資産の露出と重要度、悪用可能性、補完的統制によって異なります。

生成AIは、以下の資料を一つの判断表に整理できます。

CVE説明とCVSSベクトル
CISA KEVへの含まれ具合
ベンダー勧告文とパッチバージョン
インターネット露出資産
インストールされた製品と実際のバージョン
攻撃前提条件と必要な権限
WAF、ネットワーク分離などの補完的統制

質問	生成AI活用結果
自社環境が影響を受けるか	資産・バージョン別確認リスト
今すぐ悪用可能か	前提条件と露出経路の要約
まずパッチを適用すべき対象は	根拠を含む優先順位提案
パッチが難しい場合	公式文書に基づく一時的な緩和策の整理
何を監視すべきか	関連ログと検知アイデア

パッチコマンドや設定変更は、必ずベンダーの公式ドキュメントと変更管理手順を経る必要があります。AIが存在しないパッチバージョンやオプションを生成する可能性があるためです。

事例 8: クラウドとKubernetes設定のレビュー

IAMポリシー、Terraform、Kubernetes YAML、およびネットワークポリシーはテキストベースであるため、生成AIが比較的うまく処理できます。

例えば、次の問題を見つけるように依頼できます。

過度なIAMワイルドカード権限
公開ストレージとインターネット露出
セキュリティグループの広範なインバウンドルール
コンテナのprivileged実行
hostNetwork、hostPID、hostPathの使用
欠落したsecurityContext
Secretの平文ハードコーディング
Kubernetes RBACの過度な権限
NetworkPolicyの不在

이 Kubernetes 매니페스트를 보안 관점에서 검토해줘.

각 항목을 위험도, 근거가 되는 YAML 경로, 공격 시나리오,
최소 변경 수정안으로 정리한다.
Pod Security Standards와 Kubernetes 공식 문서를 우선 기준으로 사용한다.
애플리케이션 동작을 알 수 없는 항목은 단정하지 말고 질문으로 남긴다.

AIが作成した修正案をすぐにkubectl applyしたり、Terraformに反映したりしてはなりません。スキーマ検証、ポリシーエンジン、テスト環境、コードレビューを通過する必要があります。

事例 9: フィッシングメール調査の補助

フィッシング報告メールには、繰り返し確認すべき項目が多くあります。

表示名と実際の送信元アドレス
Reply-Toの不一致
SPF、DKIM、DMARCの結果
URLとリダイレクトチェーン
添付ファイル形式とハッシュ
ユーザーのリンククリック有無
その後のログインとセッション活動
同じ送信者からの組織内受信者

生成AIは、ヘッダーとセキュリティ製品の結果を要約し、追加調査の順序を提案できます。Microsoftも、ユーザー報告メールを分類し、分析根拠を提供するフィッシングトリアージの事例を公式セキュリティAI活用領域として提示しています。

ただし、メール本文には個人情報と会社機密が含まれる可能性があります。外部モデルに原文を送信する前に、承認されたサービスであるかを確認し、必要であればアドレス・本文・添付ファイルを非識別化する必要があります。

事例 10: 侵害事故対応手順と報告書作成

事故が発生すると、分析と同時に記録を残す必要があります。しかし、緊急な状況で報告書の品質まで維持するのは容易ではありません。

生成AIは、確認された証拠に基づいて以下の文書のドラフトを作成できます。

事故概要
時間帯別タイムライン
影響を受けた資産とアカウント
確認された侵害範囲
実行された隔離・遮断・復旧措置
残存リスクと追加作業
経営陣向け要約
再発防止課題

良い入力方法は、アナリストのメモをそのまま投げ込むのではなく、事実、推定、決定、実行結果を区別することです。

아래 사고 기록으로 보고서 초안을 작성해줘.

- 확인된 사실과 분석가의 추정을 분리한다.
- 시간은 모두 KST와 UTC를 병기한다.
- 수행하지 않은 조치를 수행했다고 쓰지 않는다.
- 근거 이벤트 ID가 없는 결론은 '검증 필요'로 표시한다.
- 기술팀용 상세본과 경영진용 5문장 요약을 각각 만든다.

法的申告、顧客通知、対外発表文言は、法務・個人情報・経営責任者のレビューなしにAI結果を使用してはなりません。

事例 11: セキュリティポリシーと監査証跡の整理

セキュリティ担当者は、技術分析だけでなく、ポリシーや監査対応にも多くの時間を使います。生成AIは以下の作業を補助できます。

複数のポリシー文書の重複と衝突の比較
統制項目と実際の証跡のマッピング
インタビュー質問とチェックリストの作成
技術設定を非技術担当者向けの文章に変換
不備点と必要な証跡リストの整理

例えば、ISMS、ISO 27001、または内部統制基準をクラウド設定と関連付ける際に、AIがマッピングのドラフトを作成できます。しかし、認証充足の有無や法解釈をAIが最終的に判断してはなりません。

自動化レベルは3段階に分けるのが安全

生成AIの導入は、最初から自動対応エージェントを作成するよりも、リスクの低い業務から始める方が良いでしょう。

段階	AI権限	適切な業務
1段階: 読み込み・要約	データ照会とドラフト生成	アラート要約、レポート、クエリ説明
2段階: 提案	調査クエリと措置案の生成	ハンティングクエリ、検知ルール、チケット作成
3段階: 制限的実行	承認されたツールを狭い範囲で呼び出し	アカウントロックアウト要求、機器隔離ワークフロー

初期段階では、1段階で品質とリスクを測定します。2段階では、人間が承認した後に実行し、3段階は、強力な権限制限、監査ログ、中断装置が準備されている場合にのみ適用します。

特に、以下の作業は基本的に人間の承認を必要とすべきです。

アカウントの無効化と権限の取り消し
エンドポイントの隔離
ファイアウォール遮断
Kubernetesリソースの削除
クラウドIAMの変更
外部機関または顧客への通知

セキュリティチームが生成AIに入力してはならないデータ

導入効果よりもまず、データ境界を定める必要があります。

データ	基本処理原則
パスワード・APIキー・トークン	入力禁止、即時マスキング
顧客個人情報	承認された環境で最小限のみ処理
内部ソースコード	契約・保存・学習ポリシー確認後使用
マルウェア原本	隔離分析環境でのみ処理
事故ログ	アカウント・IP・ホスト名など非識別化検討
未公開脆弱性	公開サービス入力禁止、アクセス制御

NISTの生成AIリスク管理ガイドは、データプライバシー、情報完全性、情報セキュリティ、人間とAIの役割構成、および第三者生成AI事故対応を主要なリスク領域として扱っています。

組織は少なくとも以下の質問に答えることができる必要があります。

入力データがモデル学習に使用されるか
プロンプトと応答はどれくらい保管されるか
データはどの地域で処理されるか
管理者とサプライヤーが会話を見ることができるか
削除と監査ログ機能があるか
接続されたプラグインとエージェントはどのような権限を持つか

生成AIの回答を検証するチェックリスト

セキュリティ業務では、もっともらしい誤答が最も危険です。

元のログにないイベントを作成していないか
存在しないCVE、パッチバージョン、コマンドを提示していないか
IOCと攻撃手法の出所があるか
事実と推定を区別しているか
時間帯とイベント順序が正しいか
クエリが実際のスキーマで実行されるか
提案された措置が業務中断を引き起こさないか
削除・隔離・遮断前に人間の承認を受けるか
AIの入力、出力、実行記録が監査ログに残るか

MITRE ATLASは、生成AIとエージェントシステムを対象に、プロンプト、検索コンテキスト、ツール接続、制御ポリシーが攻撃対象になり得ることを体系的に整理しています。セキュリティチームがAIを防御に活用する際には、AIシステム自体のセキュリティも合わせて設計する必要があります。

小さなパイロットから始める方法

最初のプロジェクトとしては、自動遮断よりもインシデントレポートのドラフト作成やアラートの要約のように、元に戻せる業務が適しています。

繰り返し時間がかかる業務を一つ選択します。
入力可能なデータ等級を定めます。
正解がある過去事例を20〜50個準備します。
精度、欠落、幻覚、作業時間削減を測定します。
人間がレビューする承認地点を定義します。
プロンプトと結果を監査可能に記録します。
品質基準を通過した後、次の業務に拡張します。

評価指標も単純な満足度よりも具体的であるべきです。

分析時間削減率
重要証拠欠落率
誤ったIOC・CVE生成率
クエリ実行成功率
アナリストが修正した文章の割合
誤検知・未検知の変化
高リスク措置の人承認遵守率

結論: 生成AIは判断を代替するよりも、判断準備時間を短縮する

セキュリティ業務において、生成AIが最も大きな効果を発揮する領域は、繰り返される情報整理と最初のドラフト作成です。

アラートを事件の流れに変換し、脅威レポートからIOCを抽出し、自然言語をハンティングクエリに変換し、クラウド設定のリスク候補を見つけ、インシデントレポートの構造を作成する作業は、生成AIと相性が良いです。

逆に、攻撃の有無の最終判定、システム隔離、アカウント遮断、パッチ適用、法的判断は、依然として責任ある人間のレビューが必要です。

良い導入原則は簡単です。

AIは証拠を整理し、選択肢を提案する。人間は原本を検証し、責任ある決定を下す。

生成AIをセキュリティチームの自動判定器として導入すると、リスクが大きくなります。アナリストがより迅速かつ一貫して判断できるよう支援する補助ツールとして開始すれば、効果を測定し、制御しやすくなります。