
ラスベガスで開催中の Cisco Live 2026 キーノートから考える、セキュリティのこれからについて。今日も キャプテンおおつかの目線で 印象に残ったポイントを整理します。
Day1速報
https://licensecounter.jp/engineer-voice/blog/articles/20260603_cisco_live_2026_day1ai.html
Shields Upに見る、CVE運用の限界とレジリエンスへの転換
Cisco Live 2026では、AIエージェント時代に向けた企業インフラのあり方が大きなテーマとして語られました。
Build、Secure、Run。
人とAIエージェントが同じ環境で働く時代に、ネットワーク、セキュリティ、データ、運用をどのように束ねるのか。Cisco Cloud ControlやAgenticOpsといった発表は、個別製品の追加というより、AI時代のCritical Infrastructureをどう支えるかという文脈で捉えるべきものだと感じています。
特にDay2キーノートでは、Cisco IQやLive Protectを通じて、脆弱性リスクの把握や、パッチ適用までのギャップをどう埋めるかにも触れられていました。
Cisco IQ:どこに古い機器、設定不備、サポート切れ、脆弱性リスクがあるのかを把握するための取り組み。AIによるプロアクティブな事前対策

Live Protect:恒久パッチを適用するまでの空白期間に、攻撃経路を封じ込め、露出時間を短くするための取り組み

これらは単なる新機能紹介ではなく、攻撃がAIで高速化する時代に、防御側の運用モデルをどう変えるかというテーマにつながります。
一方で、私自身が以前から気になっていたのは、もっと現場寄りの問題です。
・VPN機器の脆弱性対応。
・終わらないパッチ運用。
・ランサムウェア被害への不安。
そして、AIによって攻撃準備が高速化していく中で、人手中心の運用は本当に追いつけるのか、という問題です。
Cisco Trust Centerに公開された「Shields up: Guidance for defending in the age of AI-enabled attacks」は、この問題を考えるうえで非常に示唆的です。
このガイダンスで重要なのは、単に「AIを悪用した攻撃に注意しましょう」という話ではありません。
AIによって脆弱性の発見・解析・悪用までの速度と件数が増えることで、従来のCVE運用やパッチ適用の前提そのものが揺らぎ始めている、という問題提起です。

攻撃側と防御側の時間軸が噛み合わない
これまでの脆弱性対応は、ある程度、人間の運用速度を前提にしてきました。
しかしAI時代に問題になるのは、このサイクルがさらに圧縮されることです。

AIを活用すれば、ソースコードやパッチ差分の解析、脆弱性候補の発見、PoCや攻撃コードの生成、悪用可能性の検証が高速化します。攻撃者の生産性が上がり、これまでよりも短い時間で、より多くの攻撃準備が進む可能性があります。
攻撃側は、AIによって短期間で反復・量産できるようになる。
一方で、防御側は、情報収集、影響調査、優先度判断、検証、承認、メンテナンス調整、パッチ適用、事後確認というプロセスを省略できません。
つまり、攻撃の"質"だけでなく、"速度と量"が変わる。
問題は、担当者が怠けていることではありません。
攻撃側の時間軸がAIによって短縮される一方で、防御側の時間軸は、業務影響、変更管理、検証、承認、運用体制に縛られ続けることです。
ここに、AI時代の脆弱性対応の難しさがあります。
「1脆弱性=1 CVE」モデルの限界
CiscoのShields Upで特に印象的なのは、「1件の脆弱性につき1件のCVE」という従来モデルの限界に踏み込んでいる点です。

CVEは、脆弱性を識別し、関係者が共通認識を持つために重要な仕組みです。
しかし、AIによって軽微な欠陥まで大量に発見されるようになると、それらをすべて個別に開示・記録し、利用者側が一つひとつ判断する運用は現実的ではなくなります。
・メーカー側は開示と修正に追われる。
・利用者側は影響確認と優先順位付けに追われる。
・結果として、本来必要なアップグレードや修正が遅れてしまう。
ここで問題になるのは、「CVEが増えること」そのものではありません。
問題は、CVEを受け止める運用そのものが回らなくなることです。
従来のように、個別CVEを確認し、個別に判断し、順番にパッチを適用していくモデルだけでは、AI時代の速度と量に対応しきれない可能性があります。
そのためCiscoは、重大な脆弱性を優先し、軽微な修正は通常リリースに組み込むなど、結果に焦点を当てた開示モデルへの移行を示しています。
これは、脆弱性を隠すという話ではありません。
むしろ、利用者が本当に必要な対策とアップグレードに集中できるようにするための、開示と修正のあり方の見直しだと捉えるべきです。
顧客に求められる4つの示唆
では、顧客側は何を変えるべきなのでしょうか。
Shields Upの考え方を現場の運用に引き寄せると、次の4つに整理できます。

See it:見る
資産・ID・サービス・APIを継続的に把握すること。何があるか分からなければ、脆弱性が公開されても影響を判断できない。つまりAI時代には、資産管理や可視化は単なる棚卸しではなく、防御の出発点になります。
Prove it:確かめる
CVSSスコアだけで判断するのではなく、自社環境で実際に悪用可能な経路があるのかを検証すること。攻撃者は、CVSSの点数順に攻撃するわけではありません。スコアだけでは見落としがちなリスクが、重要資産への経路上に存在する場合もあります。
Contain it:止める
恒久対応までの間、攻撃経路を一時的にふさぎ、露出を抑えること。パッチは必要ですが、すべてを即時に適用できる環境ばかりではありません。その間、何もできない状態では、攻撃速度に負けてしまいます。
Replace it:更新する
EOL/EOSや古い構成を減らし、継続的に更新できる基盤へ移行すること。サポート切れや、複雑な例外設定が残っている環境では、いくら脆弱性情報が出ても、迅速に対応できません。脆弱性が公開されるたびにパッチ対応へ追われるだけでは、運用側の負担は増え続けます。
AI時代のリスクは、製品導入だけでは吸収できません。
"見える・確かめられる・止められる・更新できる"環境へ変える必要があります。
Cisco自身も対応モデルを変える
重要なのは、Ciscoが顧客側にだけ変革を求めているわけではない点です。Cisco自身も、AI時代に向けて対応モデルを変えようとしています。
Ciscoは、AIを活用した脆弱性発見・検証、リスクベースの脆弱性開示、定期的・予測可能な修正提供、secure-by-design / secure-by-default、Live Protectによる攻撃経路の封じ込め、レジリエントなインフラへの移行支援へと対応モデルを広げようとしています。

これは、単に「脆弱性を公開し、パッチを出す」という従来のメーカー対応だけでは、AI時代の速度に追いつけないという認識の表れとも言えます。
Ciscoも変わる。
しかし、それだけで十分ではありません。
どれだけメーカー側の対応が進んでも、顧客環境に古い機器、更新できない構成、広すぎる権限、見えないID、手作業の封じ込めが残っていれば、リスクは残り続けます。
顧客の運用環境も"変われる構造"へ移行しなければ、レジリエンスは実装できません!
Shields Upは、製品ではなく防御姿勢である
レポートに書かれている「Shields Up」は、特定の単一製品を指す言葉ではなく、AI活用型攻撃の時代に向けた防御姿勢として捉えるべきだと思います。
攻撃者が「AIによって高速化・自動化」されるなら、防御側も「人手による確認と判断だけに依存する運用から脱却」する必要があります。
AI時代の脆弱性対応は、CVEを追いかけるだけの運用では成立しにくくなります。
これから問われるのは、脆弱性情報の多さに耐えることではなく、攻撃速度に負けない構造を作れるかどうかです。
Ciscoが対応モデルを変え、ユーザー環境も変わり、パートナーがその変化を現実の移行計画と運用設計に落としていく。
AI時代のレジリエンスは、そうした全体の変革として考える必要があります。
最後に
文字では伝わりにくい熱気は、各方面でセミナー登壇しておりますので、皆さんとお会いできたらと思います。
参考情報
Cisco:Shields up: Guidance for defending in the age of AI-enabled attacks(PDF原文)
https://www.cisco.com/c/dam/en_us/about/doing_business/trust-center/docs/cisco-defending-against-ai-attacks-guidance.pdf
Cisco Blog:A new model for infrastructure security: How Cisco defends against AI threats
https://blogs.cisco.com/cisco-on-cisco/how-cisco-defends-against-ai-threats
Connect Everything. - Ciscoで拡がる無限の可能性 -
著者紹介
SB C&S
エバンジェリスト
大塚 正之 - Masayuki Otsuka -
