AIによってセキュリティ業務の分析や判断は、かつてないほど速く、正確になりつつありますが、それで人間は本当に楽になるのでしょうか。業務を分類すると、AIに「任せるべき仕事」と「人間に残すべき仕事」の意外な境界線が見えてきました。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
本連載「AIとサイバー攻防のダイナミクス」では、AIとサイバーセキュリティの構造変化を読み解くためのフレームワークを提示し、攻撃事例や防御の実践を交えながら、「AIをどこに導入すると効果的か」「どこまでAIに任せるべきか」「逆に人間の判断が不可欠な領域はどこか」を明らかにしていきます。
前回は攻撃側の視点から、AIが攻撃ライフサイクルのさまざまな工程に入り込みつつある実態を見ていきました。
そこで浮かび上がったのが、攻撃側と防御側の非対称性です。攻撃者はガバナンス上の制約を比較的受けにくく、AIを使って攻撃の速度や規模を高める一方、防御側では説明責任や誤検知時の業務影響などへの懸念から、AIに自律的な行動を委ねることに慎重な組織もあります。攻撃側と防御側のAI活用の速度差は、今後のサイバーセキュリティを考える上で重要な論点になります。
では、防御側はどこからAI活用を進めればよいのでしょうか。
「AIを導入する」こと自体は目標にはなりません。サイバーセキュリティ業務は、検知・分析からインシデント対応、危機管理、教育・訓練まで多岐にわたり、それぞれでAIに適した役割も、失敗した場合の影響も異なります。
重要なのは、「どの業務ならAIに任せられるのか」「どの判断には人間を残すべきなのか」を業務単位で考えることです。
そこで今回は、FIRST(Forum of Incident Response and Security Teams)が策定した「FIRST CSIRT Services Framework v2.1」で定義されるCSIRT業務をベースに、AIとの関係を「意思決定の主体」「業務アウトプット」「品質の評価タイミング」「失敗モード」「失敗の顕在化経路」という5つの軸から独自に整理します。ここでは、これらをS0〜S5の6つの「業務型」として分類し、それぞれの特徴と固有のリスクを見ていきます。
なお、S0〜S5はAIの自律度を単純に0から5まで並べた「成熟度モデル」ではありません。業務の性質や人間とAIの役割の違いを整理するための分類であり、数字が大きいほどAIに任せるべき、という意味ではありません。
本稿では、CSIRT業務を以下の6つの型に整理します。
S0は、ルールや設定に基づいて処理を自動実行する「自動実行型」です。S1は大量の情報を監視・選別する「監視者型」、S2はAIの分析や推奨を人間が承認する「承認者型」、S3はAIと人間が分析・判断を分担する「協働者型」です。S4は人間が意思決定を主導しAIを補助的に使う「主導者型」、S5は教育や演習など、組織の行動や能力そのものを変える「実践者型」と位置付けます。
この分類で重要なのは、「AIをどれだけ使うか」だけではありません。同じAI活用でも、失敗がすぐに検知できるのかどうか、長期間潜伏するのかどうか、他の業務に波及するのかどうか、最終的な責任を誰が負うのかなどによって、必要な人間の関与は変わります。
以下、各型の特徴と固有のリスクを順に見ていきます。
代表的な業務は、IPS/IDS(不正侵入検知/防御システム)による通信遮断、EDR(Endpoint Detection and Response)による自動隔離、脅威インテリジェンスフィードを受けた自動ブロックリスト更新などです。
これらはAIが登場する以前から存在するルールベースの自動化であり、AIによって新たに生まれた領域ではありません。大量の情報を高速に処理し、人間の判断を待たずに実行できることが強みです。一方、近年はAIや機械学習を利用してルールや検知ロジックの生成・更新を支援するケースも増えています。
S0の固有のリスクは、実行するルールや設定そのものが誤っていた場合です。誤ったルールは人間による個別判断を介さずに適用されるため、誤動作が広範囲に波及する可能性があります。
さらに厄介なのは、その異常が単一のアラートとして明確に現れないケースです。誤ったルールが少しずつ影響を蓄積させ、「問題が起きていない」のか「問題に気付いていない」のかを区別しにくくなることがあります。
つまり、S0では自動実行そのものを止めるのではなく、ルールや設定を設計・監査する人間の役割を残すことが重要になります。
代表的な業務は、SOC(Security Operation Center)におけるアラート監視、SIEM(Security Information and Event Management)によるイベント監視、AIが生成した検知結果や分析レポートの確認などです。
ML(機械学習)を含めたAIによる検知・アラートの優先度付けは、実運用に組み込まれている領域です。人間は大量の情報を一件ずつ処理するのではなく、AIやセキュリティ製品が絞り込んだ情報を確認し、必要に応じて介入する役割を担います。
しかしAIの精度が向上したからといって、人間の負荷が必ず減るとは限りません。検知能力が向上すれば、それまで見えていなかった異常まで拾うようになり、結果として確認すべき情報量が増える場合もあります。
大量の低重要度アラートの中に重大なアラートが埋もれたり、「どうせ誤検知だろう」という心理的な慣れが蓄積したりすれば、真のインシデントへの反応が鈍る可能性があります。
S1では、AIの検知精度だけでなく、アラート対応率や見逃し率、人間による判断の品質まで継続的に評価する必要があります。
代表的な業務は、イベント分析、アーティファクトやフォレンジック痕跡の分析、脆弱(ぜいじゃく)性分析などです。AIが一次分析や推奨を生成し、人間がその内容を確認して承認する形です。
この方式は、AIの処理能力を活用しながら最終的な判断を人間に残せるため、実務へのAI導入を考える際の典型的な形の一つです。しかしここには別の問題があります。AIの推奨に依存する状態が続くと、人間のレビューが形式的な確認へと収縮する可能性があるのです。
AIの推奨が妥当であるケースが増えるほど、人間は「なぜそう判断したのか」を検証するよりも、「問題なさそうだ」と承認することに慣れてしまいます。
つまり、危険なのはAIの精度が高いことそのものではありません。AIへの過度な依存によって、人間が自ら分析し、別の可能性を検討する能力を使わなくなることです。
重大インシデントが発生したときに初めて、「AIの推奨を承認することはできても、自分で分析することが難しくなっていた」と判明する可能性があります。
そのためS2では、通常業務とは別に「AIの推奨を見ずに判断する」訓練や、AIの判断に反証を求めるレビューを意図的に残すことが重要になります。
代表的な業務は、インシデントの分析・緩和・回復、脆弱性の調整、複数の情報源をまたいだ分析や統合などです。
AIが仮説を生成し、証跡を収集し、情報を整理する一方、人間が結果を評価して最終的な判断を下す。こうした協働型の利用は、AIによって分析の網羅性や速度を高められる可能性があります。
一方で、S3には「もっともらしい誤り」という固有のリスクがあります。
AIは前提となる情報が間違っていたとしても、そこから論理的に整合した推論を展開できます。人間がその説明の一貫性に引きずられると、別の仮説を検討する機会を失う可能性があります。
重要なのは、AIが間違わないことを期待するのではなく、AIの提案を疑う仕組みを設けることです。
例えば、重大な判断については別の担当者によるレビューを必須にしたり、AIの結論に対する反証や代替仮説を検討したりするプロセスを組み込む必要があります。
代表的な業務は、インシデントの調整や危機管理支援、外部へのコミュニケーション、脆弱性の開示、技術・ポリシーに関するアドバイスなどです。
この領域では、AIがドラフトの生成、情報整理、選択肢の列挙などを支援し、人間が最終的な意思決定を担います。特に外部への説明や危機対応では、判断の結果に対する説明責任を人間が負うことになります。
ただし、人間が最終決定者であれば十分とは限りません。
例えば、AIが作成したドラフトを先に確認すると、人間側の論点設定そのものがAIの提示した構造や選択肢に引っ張られる可能性があります。「最終判断は人間がした」としても、その判断材料や考える順番がAIによって規定されていれば、人間の意思決定が完全に独立しているとは言えません。
そのためS4では、AIの提案を見る前に自分の判断や論点を整理する、あるいは複数の選択肢を人間側で先に設定するといったプロセスが有効です。
代表的な業務は、セキュリティ啓発やトレーニング、教育、演習などです。
AIによるコンテンツ生成や個別化、ロールプレイ型演習の自動化が進めば、研修資料の作成やフィッシング模擬訓練の文面生成、多言語対応などを低コストで実施できるようになります。
しかし、コンテンツの量や品質が向上したからといって、組織の対応能力まで向上するとは限りません。
「研修を実施した」という記録だけが積み上がる一方で、実際の行動が変化していない状態は、通常の業務指標からは見えにくいものです。問題が顕在化するのは、実際のインシデントが発生したとき、あるいは実地演習をしたときになる可能性があります。
S5では、コンテンツ数や受講者数だけでなく、フィッシング訓練での報告率、インシデント対応演習における初動時間や判断品質など、実際の行動や対応能力に近いアウトカムを評価することが重要です。
Copyright © ITmedia, Inc. All Rights Reserved.