2026年10月21日、日本国内で多くのWebサイトや業務システムが相次いで緊急停止する事態が起きました。
財務省のWebサイトや札幌市、大阪府といった自治体の検索機能、さらにはビジネスチャットツールのChatworkや人気スマートフォンゲームに至るまで、官公庁から民間企業までが予防措置としてサービスの停止や機能制限に踏み切ったのです。
原因は、世界中のWebサイトを支えているプログラミング言語「PHP」本体に見つかった、2つの極めて重大な脆弱性（通称「PHP2Shell」）でした。
この問題の本質を追っていくと、単なる技術的なトラブルにとどまらない、これからのAI時代に私たち中小企業経営者が直面する「デジタルの足腰」に関する深い問いが浮かび上がってきます。
今回は、この事件の背景と、私たちが事業を守るために何を理解しておくべきかについて整理してみたいと思います。
10年以上前から眠っていたコードの欠陥
今回の脆弱性の危険度は、10点満点中9.2という最悪に近い水準でした。条件さえ揃えば、攻撃者は管理者のIDやパスワードを知らなくても、サーバー上で勝手に不正なプログラムを実行できてしまうというものです。
しかし、驚くべきはコードが書かれた時期です。問題となった欠陥は、なんと10年以上も前からPHPの内部に存在し続けていました。
PHPは、Webサイトの裏側で動く仕組みを作る代表的な言語です。世界中のホームページで広く使われている「WordPress」もPHPで動いており、調査データによれば、Webサイトのサーバー側言語のおよそ7割をPHPが占めています。
今回見つかったのは、コンピューターの「メモリ管理」に関する不具合でした。処理の途中で異常が起きた際、本来は消去して片付けたはずのメモリ領域を、まだ有効なものとして扱ってしまうというバグです。
これを会社の事務処理に例えるなら、ある社員が「破棄したはずの重要書類」の管理台帳を消し忘れ、次の社員がその台帳を見て、すでに別の書類が置かれている引き出しを誤って参照・上書きしてしまうような状態です。
研究者たちは、この状態を巧妙に突くことで、外部からサーバーを遠隔操作できることを突き止めました。WordPressで構築された標準的なサイトでも、サーバーを乗っ取れることが実証されたのです。
なぜ10年も放置され、今になって火を噴いたのか
実は、2024年のセキュリティ監査の時点で、ある開発者がこのメモリ管理の異常に気づいていました。
「攻撃に使われるかもしれない」という懸念はあったものの、当時は実際にサーバーを乗っ取る具体的な手順までは分かっていませんでした。そして何より、修正することが極めて困難だったのです。
PHPは何十年にもわたって使われ、世界中の膨大なシステムがその挙動を前提に動いています。中核部分のコードを書き換えると、既存のシステムが一斉に動かなくなる恐れがあります。互換性を守ろうとすれば危険が残り、危険を取り除こうとすれば社会のシステムが壊れる――そうした葛藤と人手不足の中で、対応は先送りされていました。
では、なぜ2026年になって突然、世界を揺るがす危機へと変わったのでしょうか。
引き金を引いたのは、最先端のAI（GPT-5.6やGemini 4など）を活用したセキュリティ研究でした。
セキュリティ企業Wizの報告によると、従来であれば世界トップクラスの専門家チームが数か月かけていたような調査・検証作業を、AIの支援を受けた一人の研究者がわずか1週間ほどで成し遂げてしまったといいます。
攻撃を成立させるには、サーバーの環境や設定の違いを乗り越える膨大な試行錯誤が必要です。AIは、プログラムを分析し、実験結果から失敗原因を割り出し、次の修正案を作るという反復作業を劇的に高速化しました。人間にとっては複雑すぎて手が出せなかった攻撃手順を、AIが軽々と組み上げてしまったのです。
ソフトウェア自体は10年前から何も変わっていません。変わったのは、その欠陥を調べる側の能力でした。
公開前の攻撃と、支える側の限界
事態はさらに緊迫しました。修正版が準備され、世界に一斉公開される予定だった日の数日前から、すでに一部でこの脆弱性を狙った攻撃の試みが観測されていたのです（Amazonの観測網による報告）。
守る側の専門家たちが秘密裏に対策を進めている裏で、すでに別の何者かが同じ欠陥を見つけ、悪用し始めていました。
そして情報が一部公表されると、直後の45分で数万件、数日で数百万件という規模の不正な探索通信が世界中で飛び交いました。日本各地の自治体や企業がサービス停止を選んだのは、更新作業が完了するまでの間、侵入を防ぐための苦渋の予防策だったのです。
この騒動を通じて浮き彫りになったのは、現代社会のインフラの脆さです。
PHPという言語は、世界中の大企業や行政を動かし、天文学的な経済価値を生み出しています。しかし、その安全性を維持する根幹の作業は、ごく一握りの熟練開発者と非営利財団、そしてボランティアの献身に依存していました。
AIによって「脆弱性を探すスピード」が何倍にも跳ね上がった結果、善意の報告も悪意の攻撃も一気に押し寄せ、それを受け止めて検証・修正する人間のキャパシティが限界を迎えつつあります。
中小企業経営者が持ち帰るべき教訓
この話を、遠い国の巨大IT企業や大組織だけの問題として片付けることはできません。なぜなら、私たちが自社の集客や業務で使っているホームページや社内システムの多くも、まさにPHPやWordPressの上に成り立っているからです。
地方の中小企業や個人事業主の現場を見ていて、私が強く感じる教訓が2つあります。
1. 「動いているから安全」ではない
システムは何年も問題なく動いていると、「動いているのだから大丈夫だろう」と放置されがちです。しかし、「問題が起きていないこと」と「欠陥が存在しないこと」は全く別です。
過去に安全だと信じられていた古いシステムであっても、調査技術（AI）の進化によって、明日突然「誰でも攻撃できる危険な状態」へと裏返る可能性があります。サーバーのOSやPHPのバージョン、CMSのプラグインを定期的に最新へ保つという基本のメンテナンスは、事業を続けるための必須コストだと考える必要があります。
2. 道具の進化が、隠れていたリスクをあぶり出す
私たちは「AIが賢くなると新たな脅威が生まれる」と考えがちです。しかし今回の事件が示しているのは、「世界は最初から脆弱性を抱えており、AIがそれを猛烈な速度で可視化し始めた」という現実です。
攻撃者だけがAIを使うわけではありません。守る側も、そして私たちのような小さな企業も、AIを道具として理解し、自社の業務やデータがどのような土台の上に乗っているのかを把握しておく姿勢が求められます。
大掛かりなセキュリティ投資ができなくても構いません。「自社のサイトが何で動いていて、最後に保守したのはいつか」を確認することから、足腰の強化は始まります。
CloudLabは京都・亀岡を拠点に、中小企業のIT活用・AI導入・ホームページ制作を支援しています。自社サイトの安全性やシステムの現状把握などでお困りの際は、お気軽にご相談ください。
この記事の内容はYouTubeでも話しています。
動画を見る →