ヌニェス氏らによると、AIをセキュリティ業務のどこに配置すべきか判断できない企業が少なくないという。選択肢が増え続ける一方、AI導入には相応の投資が必要になる。誤った判断をすれば、コストだけでなくセキュリティリスクにつながるという懸念も、意思決定を難しくしているという。

　こうした中でバレス氏がAI活用の入り口として挙げたのが、レッドチームと定型的なセキュリティ業務だ。

　バレス氏は「まずは繰り返し作業から始めるべきだ」と述べる。セキュリティオペレーションセンター（SOC）で実行するL1、L2レベルの業務やアラートの確認などをAIに任せることで、アラート疲れの軽減につなげられるという。

　同氏はレッドチームでAIを利用する利点についても言及した。攻撃者がAIをどのように利用するのかを防御側も理解できれば、新たな攻撃手法への備えにつなげられるという考えだ。

　ヌニェス氏も、AIの導入先として繰り返し作業を挙げた。例えば、同じ種類のアラートやイベントを繰り返しトリアージしているのであれば、その処理はAIを試す候補になる。こうした、既に作業内容が明確になっている業務は「AIを使ったセキュリティへの取り組みを始める上で良い方法になる」と同氏は説明する。複雑な業務プロセス全体をAIに置き換えるのではなく、処理内容と判断基準を把握できている仕事から試すという考え方だ。

年間数千回繰り返す仕事をAIエージェントに任せる

　ピッツ氏のチームでは、実際に大量に発生する定型業務の自動化を進めているという。対象の1つが、ベンダーリスク評価や契約内容の分析だ。こうした業務は確認するパラメーターや基準がある程度決まっているため、AIエージェントに一定の条件に照らした検証を任せやすい。

　ピッツ氏は「人が年間何千回も実施している仕事を、できる限り自動化している」と話す。

　単に人員を削減することが目的ではない。定型作業をAIに任せることで、担当者がより重要な仕事に時間を割けるようになる。同時に、小さな用途でAIの扱い方を学べば、リスクを抑えながら別の業務に用途を広げられるという。

AIエージェントには「できないこと」を決める

　AIをセキュリティ業務に組み込む際には、新たな攻撃経路にも注意が必要だ。

　ヌニェス氏らは、信頼しているログやアラートなどに攻撃者が悪意ある命令を忍び込ませ、AIエージェントに読み込ませる「ghostjacking」と呼ばれる攻撃手法を紹介する。従来のセキュリティ機能が攻撃そのものを正しく遮断しても、その記録を後からAIエージェントが読み取り、埋め込まれた命令に従ってしまう可能性があるという。

　ピッツ氏は、「こうした問題はAIだけに固有のものとして捉えるべきではない」と指摘する。これまで安全だと考えていた情報やシステムも、新しい技術と組み合わせることで別の攻撃経路になり得る。そのため、ゼロトラストのような既存のセキュリティ原則をAIにも適用する必要があるという。

　特に重要なのが、AIエージェントに与える権限だ。ピッツ氏は、「AIエージェントができることを制限し、明確な境界を設定する」必要があると話す。例えば、ログを読むAIエージェントであれば、自ら権限昇格したり、高リスクなコマンドを実行したりできないようにする。そのような操作が必要になった場合には、人間による承認を挟む仕組みにする。

　ヌニェス氏も、AIエージェントが「何にアクセスでき、どこで動き、何ができるのか」を事前に検討することが重要だと強調する。AIエージェントの能力を最大限利用しようとして権限を広げるほど、侵害された際の影響も大きくなる。

AIにパッチ作成を「丸投げ」してはいけない

　ヌニェス氏らは、AIによる脆弱（ぜいじゃく）性修正についても言及する。同氏らによると、AIコーディングエージェントを使って生成した540件のパッチのうち、元の脆弱性を解消できた割合は46％だった。さらに、脆弱性を修正できても別の問題を生み出すケースがあったという。

　一方バレス氏は、この結果だけを見てAIによるパッチ作成を否定すべきではないとの見方を示す。

　「人間が作成したパッチの成功率はどうでしょうか。パッチを当てた結果、別のところを壊してしまうことはどれくらいあるでしょう」（バレス氏）。同氏は続けて、AIによるパッチの失敗率についても、「人間が今やっていることと、それほど違わない」と指摘する。

　ヌニェス氏は、AIと人間を組み合わせればパッチ作成を改善できる可能性があるとした上で、導入初期からAIだけに作業を任せ、「100％正しく動く」と期待すべきではないと指摘する。

　「しばらくは“Human in the Loop”にした方がいい」とヌニェス氏は話す。AIが生成したものを人間が確認し、問題なく機能しているかどうかを検証する工程を残すということだ。

　ピッツ氏は、AIによるコード生成について慎重な見方を示す。

　「AIはコードを書くことはできる。ただし、それが必ずしもよいコードとは限らず、最初から安全なコードを書くことはほとんどない」（ピッツ氏）

　AIが生成したコードを別のAIエージェントに検証させる方法もあるが、検証の仕組みを増やせばコストも膨らむ。ピッツ氏は、「現時点では、率直に言ってAIに期待し過ぎています」と指摘する。AIだけで問題を解決しようとするのではなく、AIを人間の問題解決を支援する手段として位置付ける必要があるとの考えだ。

「AIで何ができるか」ではなく「何を解決したいか」

　今回の議論で共通していたのは、AIを万能なセキュリティ対策として導入しないことだ。

　まず、アラートのトリアージやリスク評価など、手順や判断基準が明確で繰り返し発生する仕事からAIを試す。その際もAIエージェントに必要以上の権限を与えず、高リスクな操作では人間の確認を残す。

　バレル氏は現在のAIについて「小学3年生なのに大学進学適性試験を受けさせようとしているようなものだ」と例える。AIは既に多くの作業をこなせるが、あらゆる仕事を高い品質で実行できる段階ではないという意味だ。

　セキュリティ部門が最初に決めるべきなのは、「どのAI製品を導入するか」ではない。「自社のどの仕事を改善したいのか」を明確にし、その仕事にAIを使う価値があるかどうかを見極めることが、AI活用の第一歩になりそうだ。

本稿は、IBM Technologyが2026年8月19日に公開したWhat should security leaders do with AI? They don’t know.を基に作成しました。