オルタナティブ・ブログ > 経営者が読むNVIDIAのフィジカルAI / ADAS業界日報 by 今泉大輔 >

20年以上断続的にこのブログを書き継いできたインフラコモンズ代表の今泉大輔です。NVIDIAのフィジカルAIの世界が日本の上場企業多数に時価総額増大の事業機会を1つだけではなく複数与えることを確信してこの名前にしました。ネタは無限にあります。何卒よろしくお願い申し上げます。

東証プライム社長向けにPHP脆弱性世界規模セキュリティ事案を解説。PHP重大脆弱性「PHP2Shell」で日本のサイトが一斉停止。高市首相・各国当局も警告

»

昨日のPHPの「重大脆弱性」に関する一連の動きは、過去に例がなかった大規模なものでありまして、最終的には、Xで高市首相までが警告を発する展開となりました。英国や米国などの関係当局が出す警告もリアルタイムでXを流れました。関係する各社の情報システム部門では、現在も、リリースされたばかりのPHPのパッチをあてがう作業をした上で、テストを行っていると思います(お疲れ様でございます)。
ウェブのシステムに詳しい人でない限り、PHPが何を意味するのか?なぜそれほどまでに大ごとになっているのか?理解しづらいと思います。そこでテクノロジーに詳しくない人の味方であるChatGPT 6 Astra氏にお出ましを願い、東証プライム上場企業社長にわかる言葉で、全体像を描き出してもらいました。

さっつーセキュリティ.jpeg

【講師関係者 限定特別優待】本ページからの申込で受講料が5,000円引き(税抜)になります
5,000円引で申し込む ≫
SSK SEMINAR
2026
11.6 (金)
10:00〜12:00
LIVE / アーカイブ
2週間見逃し配信
2026年 11月 6日(金)10:00〜12:00主催:新社会システム総合研究所(SSK)
【GX戦略地域「データセンター集積型」9地域10地点を徹底検証】
大型AIデータセンターの事業化・ファイナンス戦略
~日米4事例に学ぶ300MW級の実装条件とオフテイク・資本構成・地域別SWOT~
講師今泉 大輔 氏(さっつーのAIエージェント監修 / AI×経営ストラテジスト)
【注目セッション:300MW級の事業構造と生死を分ける2大条件】
なぜ「GW級」ではなく「300MW級」がAIファクトリーの黄金律なのか。米先進3拠点とソフトバンク苫小牧の先行4事例からスケールと実装モデルを徹底解剖。さらに、案件の生死を分ける「オフテイク構造」と「ファイナンス・資本構成」の実務的条件を詳解します。
第1部:先行4事例に学ぶ「300MW級AIデータセンター」の事業構造
〜米先進3拠点とソフトバンク苫小牧から読み解くスケールと実装モデル〜
1. なぜ「GW級」ではなく「300MW級」がAIファクトリーの黄金律なのか
・数兆円規模に膨らむGW級の資金調達限界と、300MW級における投資適格サイズの整合性
・GPUクラスタの光結合(InfiniBand/RoCE)限界と特高変電所(154kV/275kV降圧)の設計上限
・1ラック40〜100kW超の超高密度電力、Direct-to-Chip(D2C)液冷への移行
2. 先行4事例のビジネスモデル・インフラ・地域共生の徹底比較
・Applied Digital(米ノースダコタ州エレンデール):寒冷地・安価な電力網を活かした400MW級BTS型キャンパス開発
・Talen Energy × AWS(米ペンシルベニア州サスケハナ):原発隣接インフラを活用した300MW〜最大960MW供給の電源直結モデル
・Microsoft × QTS / Brookfield(米ウィスコンシン州等):旧Foxconn用地等を活用した超巨額プロジェクトファイナンスモデル
・ソフトバンク「Brain DateCenter」(北海道苫小牧市):経産省助成金・100%再エネ・自治体連携による国内最大級のベンチマーク事例
3. GX戦略地域がトレースすべき事業化モデルの共通原則
第2部:300MW級案件の生死を分ける2大条件
〜「オフテイク構造」と「ファイナンス・資本構成」の実務〜
1. オフテイク・事業モデル(Offtake & Tenancy)
・成功の条件 / 失敗の条件
2. ファイナンス・資本構成(Capital Structure & Financing)
・成功の条件 / 失敗の条件
【対象】 大手電力・再エネ事業者、不動産・インフラファンド、金融機関(プロジェクトファイナンス部門)、データセンター事業者、重電・エンジニアリング企業、自治体の産業政策責任者

2026年10月21日、日本の主要なインターネットサービスが相次いで緊急メンテナンスに入り、一部ではサービスが全面停止しました。

人気ゲーム「ウマ娘 プリティーダービー」、保育・教育施設向けICTサービス「コドモン」、ネットショップ作成サービス「BASE」、レンタルサーバーを提供するさくらインターネットなど、幅広い企業に影響が及びました。

原因となったのは、世界中のウェブサイトで使われているプログラミング言語「PHP」に発見された、極めて重大なセキュリティ上の欠陥です。

この脆弱性は「PHP2Shell」と呼ばれ、深刻度は10点満点中9.2点。2件の重大な欠陥が発見され、条件がそろえば攻撃者が外部からサーバーを不正に操作できることが明らかになりました。

米国ではOpenAIやCloudflareが対応に加わり、日本、英国、EUなどのサイバーセキュリティ当局も緊急の注意喚起を行いました。

今回の事件で注目すべきなのは、単にコンピューターのソフトウェアに重大な欠陥が見つかったことではありません。

多くの企業が、サイバー攻撃による被害が確認される前に、自らサービスを停止するという経営判断を行ったことです。

その背景には、AIによってサイバー攻撃の可能性が大きく変わりつつあるという、もう一つの重要な事実があります。

1.PHPとは何か。なぜ世界のウェブサイトの約7割に関係するのか

PHPとは、ウェブサイトやウェブサービスを動かすために使われるプログラミング言語です。

例えば、利用者がネットショップで商品を検索したり、会員情報を登録したり、オンラインサービスにログインしたりする際、サーバーの内部ではさまざまなプログラムが動いています。

PHPは、こうした処理を実行するために広く使われています。

世界的に普及しているウェブサイト構築システム「WordPress」もPHPを利用しています。企業のホームページ、ネットショップ、会員制サイト、行政サービスなど、多様なシステムに関係する技術です。

ウェブ技術の普及状況を調査するW3Techsによると、2026年10月21日時点で、サーバー側のプログラミング言語を識別できるウェブサイトの69.3%がPHPを使用しています。

出典:W3Techs「PHP usage statistics」

この69.3%という数字は、世界の全ウェブサイトを無条件に対象とした割合ではありません。また、PHPを使うサイトの約7割が今回の脆弱性によって侵害されたという意味でもありません。

しかし、PHPがインターネットを支える最も重要な基盤技術の一つであることは確かです。

今回、欠陥が見つかったのは、特定の企業が開発したウェブサイトではなく、PHPという共通基盤そのものでした。

つまり、個々の企業が自社のウェブサイトを正しく開発していても、その下で動くPHPに重大な欠陥があれば、影響を受ける可能性があります。

これが、今回の問題が世界規模の緊急事態になった最大の理由です。

2.PHP2Shellとは何か。深刻度9.2の欠陥が2件発見された

2026年10月21日、PHPの開発チームは、2件の重大な脆弱性に対応する修正プログラムを公開しました。

それぞれ「CVE-2026-109618」「CVE-2026-109619」という識別番号が付けられています。

どちらもPHPの内部でメモリを管理したり、エラーを処理したりする仕組みに関係する欠陥です。

技術的な詳細は複雑ですが、経営者が理解すべき点は明確です。

攻撃者が、正規の利用者としてログインしなくても、条件によっては企業のサーバー上で不正なプログラムを実行できる可能性があるということです。(今泉注:例えば、自社サイトがポルノコンテンツ販売サイトになったり、悪意のあるマルウェアをダウンロードできる犯罪加担サイトになったりする)

これは専門用語で「リモートコード実行(RCE)」と呼ばれます。

攻撃に成功した場合、サーバーの不正操作、情報の窃取、ウェブサイトの改ざん、サービス停止などにつながるおそれがあります。

ただし、今回の脆弱性が存在するだけで、すべてのPHPサーバーが自動的に乗っ取られるわけではありません。実際に攻撃が成立するかどうかは、PHPのバージョンやサーバーの構成などによって異なります。

PHPの開発チームが10月21日に公開した修正済みバージョンは、以下の通りです。

PHPの系列

修正済みバージョン

PHP 8.2

8.2.35

PHP 8.3

8.3.36

PHP 8.4

8.4.27

PHP 8.5

8.5.12

古いPHP 7系やPHP 8.1以前のバージョンは、PHP本家の通常のセキュリティサポート対象外です。こうした環境では、サポート中のバージョンへの移行、または保守事業者が提供する修正の確認が必要です。

PHP開発チームは、一時的な防御策だけでは完全な対処にならず、修正済みバージョンへの更新が必要だと説明しています。

出典:PHP Foundation「Today's PHP Security Release」

3.日本ではウマ娘、コドモンなどが緊急停止

今回の事件では、日本企業の対応が非常に迅速でした。

ゲーム大手のCygamesは10月21日、「ウマ娘 プリティーダービー」のPHP脆弱性に対応するため、緊急メンテナンスを実施すると発表しました。

当初は23時ごろの開始を予定していましたが、その後、開始時刻を22時ごろに前倒ししています。

ゲームのプレイやデータ連携など、すべての機能が利用できなくなる措置でした。

同社は、発表時点では脆弱性を悪用した被害や利用者データの流出を確認していないと説明しています。

出典:ウマ娘公式「PHPの脆弱性対応に伴うメンテナンスのお知らせ」

さらに注目されるのが、保育・教育施設向けICTサービスを提供するコドモンの対応です。

同社は10月21日、PHPの脆弱性による攻撃の可能性があるとして、保護者向けアプリを含むサービス全体を緊急停止すると発表しました。

コドモンは保育施設と保護者の連絡、登降園管理、日々の保育業務などに利用されるサービスです。

このようなサービスが停止すれば、単にウェブページが見られなくなるだけでは済みません。現場で働く職員や保護者の日常業務にも影響します。

同社は、サービスの停止によって利用者への個別連絡も難しくなることを説明し、SNSなどを通じて情報を発信しました。

出典:コドモン公式「緊急メンテナンス実施のお知らせ」

一方、ネットショップ作成サービス「BASE」も、10月21日15時50分から翌22日7時までを予定した緊急メンテナンスを告知しました。

この間、ネットショップの閲覧や注文、管理画面、PAY IDアプリ、APIなどが利用できなくなると説明しています。

ただし、BASEの公式告知では、メンテナンスの目的をデータベースの安定性向上と説明しており、PHP2Shellが直接の原因だったとまでは断定できません。

出典:BASE公式「緊急メンテナンスのお知らせ」

このほか、さくらインターネット、エックスサーバーなどのホスティング事業者でも、PHPの脆弱性への対応に伴う緊急メンテナンスが報じられました。

もちろん、すべての顧客のウェブサイトが一斉に停止したわけではありません。停止の対象や範囲は事業者によって異なります。

こうした一連の動きが示すのは、攻撃による被害が確認されてから対応するのではなく、危険性が明らかになった段階で、予防的にシステムを停止する企業が相次いだということです。(今泉注:このような、脆弱性による攻撃が発生する前に、世界規模で、各社が予防的にシステムを停止したという展開は過去に類例がない。)

4.日本政府も「必要ならウェブサイトの一時停止」を呼びかけた

政府機関も迅速に対応しました。

情報処理推進機構(IPA)は10月21日、PHPの重大な脆弱性について事前の注意喚起を公開しました。

その中で、PHPを利用しているウェブサイトや業務システムを把握し、修正プログラムが公開されたら速やかに適用するよう求めています。

また、PHPはウェブサイトだけでなく、ソフトウェア製品やネットワーク機器などの内部でも利用される場合があると説明しています。

つまり、自社がPHPでウェブサイトを開発していなくても、使用する業務システムや機器にPHPが組み込まれている可能性があります。

出典:IPA「PHPのセキュリティリリース公開予定について」

国家サイバー統括室も、修正プログラムを速やかに適用することが難しい場合には、ウェブサイトなどを一時的に停止することがリスクを低減する有効な手段になり得ると注意喚起しました。

これは企業経営者にとって重要なメッセージです。

通常、企業のシステム運用では、サービスを停止させないことが重視されます。

ECサイトなら販売機会の損失、企業向けクラウドサービスなら顧客業務への影響、金融サービスなら決済や取引への影響が生じるからです。

しかし、今回のような重大な欠陥が発見された場合には、運用を続けることが、かえって企業に大きな損害をもたらす可能性があります。

そのため、攻撃を受ける前にサービスを停止するという判断が必要になるのです。

5.欧米でも政府機関が緊急警告。Cloudflareは攻撃を観測

今回のPHP2Shellは、日本だけの問題ではありません。

EUのサイバーセキュリティ機関CERT-EUは、PHPを利用するシステムを特定し、修正プログラムを直ちに適用できるよう準備することを勧告しました。

修正がすぐにできない場合には、インターネットから公開システムを切り離すことも検討するよう求めています。

英国の国家サイバーセキュリティセンター(NCSC)も同様に、速やかな修正が難しい場合にはシステムの一時停止を検討するよう呼びかけました。

出典:CERT-EU「Critical Vulnerabilities in PHP」

出典:英国NCSC「Critical security issue affecting PHP」

米国のインターネットセキュリティ大手Cloudflareも、今回の対応で重要な役割を果たしました。

Cloudflareは10月初旬からPHP2Shellへの防御策を準備し、脆弱性の正式公開より約9時間早く、利用者向けの防御ルールを展開しました。

無料プランの利用者も対象です。

さらに同社は、今回の脆弱性を狙った攻撃トラフィックを実際に観測したと報告しています。

攻撃者が防御ルールを回避しようとして、攻撃データを変更している様子も確認されました。

ただし、攻撃の試行が観測されたことと、実際に多数の企業が侵害されたことは別です。今回の大規模なサービス停止を、そのままサイバー攻撃の被害件数と解釈することはできません。

出典:Cloudflare「Cloudflare deploys protections against php2shell vulnerability」

6.OpenAIのAIが重大な脆弱性の発見を支援していた

今回の事件には、もう一つ大きな特徴があります。

PHP2Shellの重大性を明らかにする研究に、OpenAIのAIモデルが使われていたことです。

OpenAIは10月21日、「Patch the Planet」と呼ばれる取り組みの一環として、セキュリティ企業CalifがAIモデル「GPT-5.6 Sol」を活用し、PHPの重大な欠陥を発見したことを発表しました。

また、別のセキュリティ企業Wizも独立した研究によって脆弱性を報告しています。

今回の問題の一部は、2024年のセキュリティ監査の段階ですでに兆候が把握されていました。

しかし、実際に悪用できる方法を証明することが難しく、修正には複雑な技術的判断が必要でした。

その後、2026年8月にAIを利用した研究によって、遠隔から不正なプログラムを実行できることが明らかになり、PHP開発チームは修正作業を本格化させました。

OpenAIは約2か月にわたり、PHP開発者、セキュリティ研究者、Cloudflareなどと連携し、情報公開前に修正と防御策を準備する取り組みを支援しました。

出典:OpenAI「Patch the Planet: global response coordination as agents uncover critical vulnerabilities」

今泉注:以下の流れ。

・「敵」がAIによってPHPの重大脆弱性を知り、世界規模の同時多発攻撃を始める前に、OpenAIが、最新のAIモデルを使って、PHPの重大脆弱性を発見した。(クロード・ミュトスを使えば同じことができる。人間が発見できない脆弱性をAIが発見できるため、「敵」に渡ってしまうと大変になる。ミュトスの配布先が限られたのはそういう理由。)

・そうして「敵」が動く前に、対策を講じた(パッチを開発した)。それにはPHP(非営利団体)やその他のサイバーセキュリティ専門家も加わった。

・パッチを全世界に配布できる状態が整ってから、「さあ、2026年10月21日日本時間午後11時に、パッチを配布します」とアナウンス。これは「敵」が動く時間的余裕を与えないため。

・このアナウンスに基づいて、世界各国のウェブサーバー運営者が動いた。政府関連当局も警告を発した。「早くパッチを当てて下さい。敵にやられてしまう前に」と。

7.なぜ日本企業は「攻撃される前に停止する」と判断したのか

ここからは、企業経営の問題です。

従来、サイバーセキュリティにおける重大な経営判断は、主に攻撃を受けた後に発生していました。

例えばランサムウェア攻撃で基幹システムが停止した場合、経営者は工場の操業停止、受発注の中断、顧客への連絡、システムの復旧費用などについて判断しなければなりません。

ところが、今回のPHP2Shellでは順序が逆になりました。

サイバー攻撃による被害が確認されていない段階で、企業が自らサービスを停止したのです。

なぜでしょうか。

理由は、サービスを継続した場合に発生し得る損失が、短時間の停止による損失を上回る可能性があるからです。

例えば、企業が運営するECサイトを数時間停止すれば、その間の売上が失われます。

しかし、重大な脆弱性を放置して攻撃を受けた場合には、顧客情報の漏洩、不正注文、決済情報への影響、システム改ざん、長期的なサービス停止などにつながる可能性があります。

その結果、被害調査、システムの再構築、顧客対応、法的対応、信用回復など、多くの費用が発生するおそれがあります。

もちろん、停止すれば必ず損失を最小化できるわけではありません。影響を受けないシステムまで一律に止めれば、不必要な経済損失が発生します。

重要なのは、脆弱性の重大性、外部からの攻撃可能性、修正までの所要時間、停止した場合の事業影響を比較し、迅速に判断することです。

こうした判断を、現場のシステム担当者だけに任せることは適切ではありません。

事業継続、顧客との契約、売上、企業の信用に関わる問題だからです。

Comment(0)