AIが脆弱性を発見する時代、サイバー攻撃と防御はどう変わる？

「AIが重大な脆弱性を発見した」。その知らせは、頼もしくも、少し怖くも聞こえます。人が見落とした問題を見つけてくれるなら安心できそうです。一方、同じ力を攻撃する側が使ったら、どうなるのでしょうか。

AIは、ソフトウェアの弱点を見つける手助けになります。その力は、守る側にも攻撃する側にも使われ得ます。 私たちが安全に使えるかを分けるのは、発見の速さだけではありません。問題が本物かを確かめ、直し、利用中のサービスへ修正を届けるところまで進められるかが重要です。

2026年10月のPHPの事例には、この両面が表れています。ここでは2026年10月22日までに確認した情報をもとに、確認済みの事実、専門機関の見通し、そこから考える条件付きの未来を分けて読み解きます。

AIによる脆弱性発見で、今回何が変わった？

今回のPHPの問題について、Google Cloudは、Wizが複数のAIモデルを使って発見と修正を支援し、Gemini 4 Argonが発見や修正の検証などに貢献したと説明しています。これは開発・提供側の発表であり、すべての検査でAIが人を上回ることを示す比較試験ではありません。

それでも、この事例からは、AIの役割が「不審なメールを振り分ける」だけにとどまらず、ソフトウェアの内部の問題を調べる作業へ広がっていることが分かります。

ここで、「AIが見つけた弱点」は「AIが作った弱点」とは限りません。以前から存在していた問題を、新しい道具や調べ方で発見する場合があるからです。見つかった日と、問題が生まれた日は別です。

また、AIが関与したという一言だけでは、どこまで自動だったのかも分かりません。調べる場所を選ぶ、疑わしい動作を見つける、再現を確かめる、修正後の挙動を確認する。それぞれ別の仕事です。「AIが発見」という見出しの先で、実際に助けた工程を読む必要があります。

AIが見つける脆弱性の増加は、被害の増加と同じ？

同じではありません。調べる力が上がれば、以前は見えていなかった弱点が多く見つかる可能性があります。数字が増えた原因が、弱点を作る量の増加なのか、発見能力の向上なのかは、件数だけでは区別できません。

たとえば、街の橋を点検する回数を増やすと、修理すべき場所の報告が増えるかもしれません。それは橋がその日に急に傷んだという意味とは限らず、直す機会が増えたとも考えられます。ソフトウェアの点検も、発見したあとに修正できることが重要です。

ただし、このたとえには違いもあります。ソフトウェアでは、修正の変更点などが攻撃者にとって弱点を理解する手がかりになる場合があります。問題を明らかにすることと、対策を届けることの時間差が、安全を左右します。

発見件数が増えても、修正までの時間が短くなり、実際の被害が減るなら、守る力が上がっている可能性があります。反対に、発見だけ増えて未対応の問題がたまれば、数字の大きさを喜ぶだけでは済みません。

AIによるサイバー攻撃が速まると何が困る？

守る側は、自分の環境に関係する問題を見分け、修正が動作に影響しないか確かめ、更新し、反映を確認する必要があります。サービスを提供し続けながら進めるため、手順を一つ省けばよいとは限りません。

攻撃する側は、入り込める場所を一つ見つければ、そこから攻撃を広げられる場合があります。サービスを動かし続けたり、止まったときに利用者へ案内したりする仕事は、攻撃する側にはありません。守る側が「利用者に影響を出さずに直せるか」まで確かめている間も、攻撃する側は次を試せます。この負担の違いが、対応を難しくします。

AmazonのPHP2Shellに関する報告は、公表前の攻撃の試みや、公表後に観測された悪用を説明しています。また、AIによる分析が攻撃手法の開発を速め得ると指摘しています。ただし、今回観測した個々の攻撃がすべてAIで作られたと証明した報告ではありません。

もし攻撃方法が短時間で広まれば、「来週の定期作業で更新する」予定では間に合わない場面が増えるかもしれません。たとえば、翌朝使う予約サービスが夜間に緊急メンテナンスへ入る。必要な機能だけ一時的に止まる。利用者には、こうした予定の変更として届く可能性があります。

だからといって、すべての更新を確認なしで即時適用すれば解決するわけでもありません。更新で業務が止まる危険もあります。必要になるのは、事前に確認できる環境や、対象を小さく区切って適用する仕組み、誰が緊急判断をするかという準備です。

AIによるセキュリティ対策にも人の判断が残る

AIが「ここが危ないかもしれない」と大量に報告しても、そのすべてが本当の弱点とは限りません。実際に問題が起きるか、どんな被害につながるかを確かめて、直す順番を決める必要があります。誤った報告が多いほど、確認に時間がかかり、本当に急ぐ問題への対応が遅れる可能性があります。

修正案も同じです。目の前の不具合が消えたように見えても、別の条件で動かなくなることがあります。正しさを確認する基準まで、同じAIの説明だけに頼ると、見落としが残るかもしれません。

ここには、AIの能力が上がっても残る仕事があります。

• 何が起きれば重大な被害とみなすかを決める。
• 実際の環境で問題が再現し、修正で解消したかを確かめる。
• 更新による停止と、未修正の危険を比べて適用順を決める。
• 利用者へ、分かったことと調査中のことを説明する。

これらの一部をAIが助けることは考えられます。それでも、「誰が判断の責任を持つか」と「検証の材料が残るか」は別の問いです。分かりやすい説明が出ることと、その説明が正しいことの違いは、AIが間違いを答える理由でも扱っています。

もう一つの問題は、守る道具を誰が使えるかです。高性能なAIを利用できても、報告を確認する人や更新の担当がいなければ、防御として使い切れません。道具の価格が下がることと、安全を運用する負担がなくなることは同じではありません。

AIとサイバー攻撃の未来を三つの条件で考える

英国NCSCの2025年5月の評価は、2027年に向けてAIが弱点の発見や攻撃を助け、防御側の対応力に差が生まれると予測しています。一方、高度な攻撃を最初から最後まで完全自動で行うことは、同期間には起こりにくいと見ています。これは将来の評価であり、すでに全部実現したという報告ではありません。

そこから先を考えるときも、「AIが進歩するか」の一問だけでは足りません。少なくとも、発見する力、報告を処理する力、修正を実際に適用する力を分けて見る必要があります。

以下は、その組み合わせから考えた編集上の想定です。起きる年や確率を断定するものではありません。

発見と修正適用が一緒に速くなる場合

検証できる報告が増え、修正を試して配る仕組みも整えば、弱点が残る期間を短くできる可能性があります。利用者には、問題を知らない間に安全な更新が届く形も考えられます。

この方向を確かめる手がかりは、AIの発見件数より、修正が必要な環境へ届くまでの時間や、更新後の不具合への対応です。「発見した」「直した」「届いた」がつながっているかを見ます。

発見だけが速くなり、確認と修正が追いつかない場合

報告が増えても、重複や誤りの確認に時間がかかれば、修正待ちがたまります。短期的には、優先順位を判断する人や、実際の影響を確かめる人の負担が増える可能性があります。

利用者からは、警告が頻繁に届くのに、何をすべきか分かりにくい状態として見えるかもしれません。通知の数を減らすだけでなく、対象と必要な行動を絞って伝える工夫が求められます。

一部だけが速く直せる場合

大きな基盤や保守の整った環境だけで更新が進み、古いシステムが残れば、攻撃者がその差を狙う可能性があります。新しいAIを導入したという発表が増えても、社会全体の危険が同じように下がるとは限りません。

この場合、技術の普及だけでなく、古い環境を安全に移す支援や、保守を継続する費用の分担も重要になります。その問題は、オープンソースの保守と費用へつながります。

AI時代の安全性は、発見数以外も見て判断する

AIによる発見が話題になるほど、目を引く大きな数字を追いたくなります。けれど、利用者にとって必要なのは、問題を見つけたという成果が、自分の使うサービスの安全へ届いているかです。

「何件見つけたか」に加えて、「本当に問題だと確認できたか」「修正が用意されたか」「利用する環境へ適用されたか」「実際の被害はどうだったか」を分けて読むと、発表の意味を捉えやすくなります。

これらの情報が公開されていなければ、外から安全性を断定することはできません。情報が足りないという状態を、そのまま残すことも大切です。AIが関わったというだけで過大に期待したり、逆に全部を怖がったりする必要はありません。

今後の変化で期待できるのは、人だけでは調べきれなかった場所へ点検が届くことです。同時に、その成果を安全な更新へ変える仕事が置き去りになれば、発見の速さが新しい負担にもなります。

次に「AIが脆弱性を発見」というニュースを読んだら、まず発見・修正・適用・被害のどこまで書かれているかを確かめてみてください。暮らしへの影響を広く考えたい人は、PHPの問題から見るインターネットの未来で、止まったときの備えまでつなげられます。