ニュースの概要
日本IBMは10月13日の記者説明会で、AIを使ったサイバー防御の新しい考え方を示した。軸になるのは、脆弱性（＝システムの弱点）を管理する基盤「IBM Concert」と、オープンソースソフトウェア向けの対策サービス「Project Lightwell」である。弱点を見つけて把握し、対応を決めて実行するまでの流れを、できるだけ自動でつなぐことを狙う。説明では、企業が今の業務にAIを足す「+AI」の段階から、AIの働きを前提に業務の流れそのものを描き直す段階へ進むべきだという方向性も語られた。守る側の仕事を、人の手作業からAIエージェントが動く仕組みへ移そうとする提案と言える。
引用元: 日本IBM、AIエージェントを中心に据えたサイバー防御モデルを提示（マイナビニュース）
分析・見解
攻撃の速さに人手の対応が追いつかなくなった
脆弱性の公開件数は年々増え、悪用が始まるまでの時間も短くなっている。報告された弱点を人が一件ずつ読み、自社のどの機器に関係するかを調べ、優先順位を付けて修正を依頼する。この流れは、対象が数万件の規模になると回らない。今回の提案が狙うのは、この「調べて決める」部分である。弱点を見つけるだけなら既存の診断ツールでも足りる。現場が本当に困るのは、見つかった大量の指摘のうち、どれから直すべきかを決められないことだ。
見つける作業より直す順番を決める作業が重い
脆弱性管理の負担は、検出よりも判断にある。同じ「重大」の指摘でも、外部から届く機器なのか、社内の閉じた環境なのか、すでに悪用が確認されているのかで、急ぐ度合いは大きく変わる。AIがこうした材料を集めて整理し、対応案まで出せるなら、担当者の時間は大きく空く。家の戸締まりで言えば、全部の窓に同じ時間をかけるのではなく、侵入されやすい一階の窓から先に閉める判断に近い。
オープンソースの弱点は一社では守りきれない
Project Lightwellが対象にするオープンソースは、ほぼ全てのシステムの内部に入り込んでいる。2021年のLog4jの問題では、自社が該当する部品を使っているかを確かめるだけで、多くの企業が数週間を費やした。使っている部品の一覧（＝部品表）を持たない組織ほど、影響範囲の把握が遅れる。この領域を支援するサービスが出てくる意義は大きい。ただし、修正の適用まで丸ごとAIに任せられるわけではない。ここには人が見る線引きが必要になる。
「+AI」の先で問われるのは責任の置き場所
既存業務にAIを足すだけなら、失敗しても元の手作業に戻れる。しかし、AIを前提に流れを組み直すと、戻る道は細くなる。自律型のエージェントが設定変更や通信の遮断まで実行する場面では、誤判断で業務システムを止める危険も生まれる。私が重要だと考える点は、防御の自動化では賢さより「止め方」が成否を分けることだ。権限の範囲、承認が必要な操作、判断の記録の残し方を先に決めた組織だけが、速さの利益を安全に受け取れる。
ビジネスへの影響
まず自社の弱点一覧と更新の担当を確かめる
導入を検討する前に、自社が使うソフトと機器の一覧を作れているかを確認したい。一覧がなければ、どんなAIも判断の材料を持てない。次に、脆弱性の指摘が出てから修正が終わるまでの日数を測っておく。この数字が、導入後の効果を比べる基準になる。中小企業であっても、重要なシステム十数件から始めれば十分に意味がある。
自動化の範囲は三段階に分けて広げる
最初は「調査と優先順位付け」だけをAIに任せ、結果は人が確認する。次に、影響の小さい試験環境での修正の適用を自動にする。最後に、本番環境での遮断や設定変更を、事前に決めた条件の中だけで許す。この順に進めれば、誤作動の被害を小さく保てる。契約の面では、AIの判断の記録が残るか、障害時に誰が責任を負うかも必ず見ておきたい。
費用の比較は人件費の削減だけで終わらせない
効果を人件費の削減だけで測ると、投資は小さく見えてしまう。本来の価値は、弱点が放置される空白期間を短くすることにある。侵害が一件起きたときの調査費、停止による売上の減少、取引先への説明まで含めて比べると、判断は変わってくる。経営会議には、修正までの平均日数と、未対応の重大な指摘の件数という二つの指標を出すとよい。
