はじめに
2026年10月21日、Webシステムで広く使われているプログラミング言語「PHP」に、外部から不正なプログラムを実行される可能性のある重大な脆弱性が2件公表されました。国家サイバー統括室（NCO）がSNSで修正版の早期適用を呼びかけ、適用が難しければサイトを一時停止するよう求めるという、異例の対応がとられた事案です。
それから1週間以上が過ぎた10月30日、産経新聞の調査で、少なくとも全国31市町村がWebサイトの公開を止めたり縮小したりしたままであることが報じられました。
一方で、民間には公表当日のうちにサービスを止め、翌日には主要機能を復旧させた企業もあります。同じ脆弱性に対して、なぜこれほど差がついたのでしょうか。この記事では、事案の概要を整理したうえで、自治体に限らず事業会社でも起こりうる「緊急パッチを当てられない状態」をどう防ぐかを、発注側支援の立場から解説します。
何が起きたのか
報道と各機関の発表によると、概要は次のとおりです。
- 2026年10月21日、PHPの開発チームが重大な脆弱性2件（通称「php2shell」、CVSS 9.2）を公表し、同日深夜（日本時間23時頃）に修正版を公開した
- 認証なしで外部からサーバー上のコードを実行される可能性があり、PHP 8.2〜8.5系の修正前バージョンが対象。サポート切れの7.4・8.0・8.1系は正式な修正版がなく、バックポートや配布元パッケージでの対応が必要とされている
- NCOは修正版の速やかな適用と、適用が難しい場合のサイト一時停止を呼びかけた。JPCERT/CCも10月22日に注意喚起を出し、侵害有無の調査も促している
- 産経新聞が全1,741市区町村のサイトを確認したところ、10月29日夜の時点で8市17町6村の計31市町村が通常ページを表示できず、メンテナンス表示になっていた。何らかの影響が出た自治体は少なくとも200あったとされる
- 対応が遅れている自治体からは、IT人材が少なく委託業者に教わりながら対応している、サイトが古く作り直しに費用と時間がかかる、といった声が出ている
なお、報道時点で多くの自治体は不正アクセスや情報漏えいは確認されていないとしています。今回の問題は「被害が出た」ことよりも、「直すのに時間がかかり、その間サービスを止め続けている」ことにあります。
対照的なのが、保育施設向けSaaSを提供するコドモンです。ITmedia NEWSによると、同社は公表当日の朝に事態を把握し、攻撃手法の情報が出回り始めたことを受けて昼過ぎに日中の緊急停止を決断、約18時間後には主要システムを復旧させています。
なぜ「すぐに直せない」状態が生まれるのか
自治体の人手不足の問題として片付けたくなりますが、私が発注側の支援で見てきた事業会社でも、同じ構造はよくあります。原因はおおむね次の3つです。
1. 何がどこで動いているか、発注側が把握していない
「PHPの脆弱性」と聞いて、自社のどのサイト・システムが該当し、それぞれ何のバージョンで動いているかを即答できる会社は多くありません。キャンペーンサイトや採用サイト、部門が個別に発注した小さなWebシステムは、情シスの台帳に載っていないことも珍しくありません。
2. 保守契約に「緊急対応」が書かれていない
構築時の契約は細かく詰めても、保守契約は「問い合わせ対応」「障害対応」程度の書き方で済ませがちです。脆弱性が出たときに、誰が影響を調べ、誰が判断し、何時間以内にパッチを当てるのか。この取り決めがないと、委託先は「見積もりを出してから」、発注側は「委託先がやってくれるはず」となり、時間だけが過ぎます。
3. バージョンアップを先送りし続けている
今回、正式な修正版が出なかったサポート切れのバージョンで動いているサイトは、パッチを当てるだけでは済まず、作り直しに近い対応が必要になります。予算が付かないまま「動いているから」と放置してきた技術的な負債が、緊急時に一気に表面化した形です。
発注側が自社で整えておきたい仕組み
報道では人材確保や修正版の適用が対策として挙げられていますが、発注側として本当に効くのは、事前に「判断と作業の段取り」を決めておくことです。次の5点を順に整えることをおすすめします。
1. 外部公開システムの台帳を「バージョンまで」持つ
まず、外部に公開しているサイト・システムを一覧にし、次の項目を記録します。
- システム名、URL、業務上の重要度
- 主要なソフトウェア（OS、言語、フレームワーク、CMS）とそのバージョン
- 構築・保守の委託先と連絡窓口
- 社内の責任者（業務側・IT側）
部門が独自に発注したものも含めて洗い出すのがポイントです。台帳は委託先に年1〜2回更新してもらい、受領を保守契約の作業項目にしておくと形骸化しにくくなります。
2. 保守契約に「緊急脆弱性対応」の条項を入れる
保守契約やSLAに、少なくとも次の内容を書いておきます。
- 重大な脆弱性（例：CVSS 9.0以上）が公表された際、委託先が影響有無を報告する期限（例：24時間以内）
- 修正版の適用目標期限と、適用できない場合の代替策（一時停止、WAFでの遮断など）の提案義務
- 緊急対応の費用が保守費用の範囲内か、別途見積もりか
特に最後の費用の扱いは、決めていないと「見積もり→稟議→発注」で数日が過ぎます。SLAで押さえるべき数字の考え方は、ベンダーとのSLAで何を数値で握っておくべきかの記事でも整理しています。
3. 「止める判断」の権限を事前に決めておく
コドモンの事例で注目したいのは、技術的な対応の速さ以上に、日中にサービスを止めるという判断を短時間で下せたことです。多くの組織では、サービス停止には上長や業務部門の了承が必要で、その調整に時間がかかります。
あらかじめ「重大な脆弱性が出て、修正版の適用まで時間がかかる場合は、情シス責任者の判断で外部公開を一時停止してよい」といったルールを決め、経営層の了承を得ておきましょう。あわせて、停止時に表示するお知らせ文のひな形と、問い合わせ窓口も用意しておくと、当日の作業が大きく減ります。
4. バージョンアップを「計画的な予算」にする
サポート切れのソフトウェアで動くシステムは、今回のように緊急時の選択肢が極端に狭くなります。台帳に各ソフトウェアのサポート終了日を記録し、終了の1年前には更新の予算を計上するルールにします。PHP 8.2系も2026年12月31日でサポートが終わる予定とされており、該当システムがあれば今すぐ確認が必要です。
「動いているものに予算はつかない」という壁は、経営層に「サポート切れのまま重大な脆弱性が出たら、サイトを止めるしか手がない」と、今回の事例を材料に説明すると通りやすくなります。
5. 年に一度、机上訓練をする
最後に、今回の事案を題材にした机上訓練をおすすめします。「明日、自社で使っている言語に重大な脆弱性が出たら」という想定で、台帳から対象システムを特定し、委託先に連絡し、停止判断をするまでの流れを関係者で確認するだけでも十分です。台帳の漏れや、連絡先の古さ、判断者の不在といった穴が見つかります。
まとめ
PHPの重大な脆弱性をきっかけに、少なくとも31市町村でWebサイトの停止が続いている事案は、人手不足だけでなく、「何が動いているか分からない」「緊急時の取り決めがない」「古いバージョンを放置してきた」という、多くの組織に共通する構造から生まれています。一方で、公表当日に停止を決断し翌日に復旧した企業もあり、差を分けたのは事前の段取りでした。発注側にできるのは、外部公開システムの台帳をバージョンまで持ち、保守契約に緊急対応と費用の扱いを書き、停止判断の権限を決め、バージョンアップを計画的な予算にしておくことです。次の重大な脆弱性はいつ出てもおかしくありません。まずは自社の公開サイトを一覧にするところから始めてみてください。
参考
- ITmedia NEWS（産経新聞）「『ITノウハウ持つ人材少なく』 PHP脆弱性問題、31市町村でサイト一時停止継続」（2026年10月30日）
- ITmedia NEWS「PHP脆弱性でいち早くサービス停止、コドモン経営判断の舞台裏」（2026年10月30日）
- ＠IT「EOLのPHP 7.4、8.0、8.1にも異例のパッチ JPCERT/CCが警告する『php2shell』の侵害痕跡3つと緊急対策」（2026年10月23日）
- 熊本日日新聞（共同通信）「PHP注意喚起、状況把握に全力 政府、SNSで情報周知」（2026年10月22日）
- 仙台市「仙台市が管理・利用するウェブサイト・サービスの一部停止について（令和8年10月21日に発覚したPHPの脆弱性対応）」
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント