なぜ「更新できない」のか？ PHP騒動で見えた、パッチを先送りする企業の盲点：「新しい乱世」を生き抜くためのIT羅針盤

この記事は会員限定です。会員登録すると全てご覧いただけます。

これまでどの時代でも、時代に適応した者だけが生き残ってきました。

テクノロジーの急速な進化、経済見通しの不透明さ、地政学リスクの顕在化、そして前例なき気候変動――。これまでの経験や常識が通用しにくいこの時代は、まさに「新しい乱世」と言えるでしょう。

今、企業に求められているのは、混迷の中を生き抜いていくために必要な次の一手を見極める力です。

そのための羅針盤となるのが、経営とビジネスを根本から変革し得るエンタープライズITなのです。

本連載では、アイ・ティ・アールの入谷光浩氏（取締役／プリンシパル・アナリスト）がエンタープライズITにまつわるテーマについて、その背景を深掘りしつつ全体像を分かりやすく解説します。「新しい乱世」を生き抜くためのITの羅針盤を、入谷氏とともに探っていきましょう。

「新しい乱世」を生き抜くためのIT羅針盤：記事一覧

　2026年10月21日、Webアプリケーションの開発言語PHPの重大な脆弱（ぜいじゃく）性が公表され、多くのWebサイトが対応のためのメンテナンスで一時停止しました。高市早苗首相が自身の「X」アカウントでパッチ適用の準備を呼び掛ける、異例の事態にもなりました。テレビでもトップニュースになり、筆者は75歳の母からPHPの説明を求められました。筆者にも、思わぬ形で「緊急対応」が発生したわけです。

　冗談はさておき、脆弱性を修正するセキュリティパッチの適用は、サイバー攻撃への基本的な対策です。今回のように社会的な関心を集めれば、対応の必要性も共有しやすいでしょう。しかし、企業の現場では、普段から数多くのパッチへの対応が求められます。動作検証やバックアップの取得に加え、その都度、業務部門や委託先の理解を得て作業を調整するのは容易ではありません。こうした負担から、「必要になったら更新すればよい」と考えて更新を見送ってはいないでしょうか。その判断は、いざというときに本当に更新できることを確かめた上でのものでしょうか。

　筆者が所属するアイ・ティ・アールには、企業のIT部門から「パッチはどの程度の頻度で適用すべきか」「バージョンアップは実施すべきか」といった相談が多く寄せられます。業務への影響や作業負担を考えると、どちらの実施時期も簡単には決められません。

　では、決めかねた末に、更新を見送る判断が繰り返されるのはなぜでしょうか。そこには担当者個人の姿勢だけでは説明できない、組織側の事情があります。

　更新を実施するには、検証や適用作業に時間と人手を割かなければなりません。一方、見送ってもシステムが動き続けていれば、業務は目立った影響を受けません。そのため先送りによって残るリスクより、目の前の作業負担を減らすことが優先されやすくなります。

　例えば、パッチの適用後に受注システムへログインできなくなり、営業部門の業務が止まったとします。IT部門は復旧を急ぐとともに、更新を実施した判断についても説明を求められることになります。こうした業務停止だけが厳しく問われ、更新を見送るリスクが問われないのであれば、担当者の判断が先送りに傾くのも無理はないと筆者は考えます。

　更新が進まない背景には、現場の意識だけでは解決できない、組織の判断基準や責任の問われ方に関わる根深い問題があるのです。

　ただし、更新を見送っている間に、緊急時に必要な作業が増える場合があります。「そのときにパッチを適用すればよい」と考えていても、適用作業に入るまでに別の更新や検証が必要になることがあるからです。

　例えば、受注システムで使っているデータベース製品のバージョンアップを見送り、そのバージョンへのパッチ提供が終了したとします。重大な脆弱性に対応するには、パッチの提供を受けられるバージョンへの移行が必要になる場合があります。その際には、移行方法を検討し、新しいバージョンでも受注システムが正常に動くかどうかを確認しなければなりません。

　サポート期限を見据えて平時に進められたはずの移行や検証に、脆弱性への対応を急ぐ中で取り組むことになります。米国立標準技術研究所（NIST）のパッチ管理ガイド「SP 800-40 Rev. 4」も、通常の更新を遅らせることで、緊急パッチの前提となる過去のパッチの適用が必要になり、対応が長引く可能性を指摘しています。製品ごとに更新の前提条件を確かめておく必要があります。

　パッチの提供を受け続けるためのバージョンアップは、こうした事態に備える準備でもあります。利用中のバージョンへのパッチ提供がいつまで続くかを把握し、移行を計画しておくことが重要です。企業は更新の時期をずらしたつもりでも、結果として、対応を急ぐ場面で必要な作業を増やしていないか。先送りの判断では、そこまで考えなければなりません。

　皆さんは、パッチを適用する際、どのシステムや業務への影響を確認すべきか、すぐに判断できるでしょうか。影響範囲が分からず、念のため検証する範囲を広げているなら、その負担の一因は、判断に使う情報の不足にあります。こうした判断に必要な情報を、日頃からIT資産管理と構成管理でそろえておくことが重要になります。

　まずIT資産管理で把握する製品、利用場所、バージョン、管理担当者の情報を使い、パッチの適用対象を特定します。サポート期限や保守契約も、更新時期や対応方法を決める際の判断材料になります。

　構成管理ではOS、データベース、業務アプリケーションの組み合わせや設定、システム間のつながりを把握します。例えば、受注システムと在庫管理システムが同じデータベースを使っていれば、データベース製品の更新時には両方への影響を確認する必要があります。こうした関係を踏まえ、検証や業務部門との調整の範囲を決めます。

　前回（第14回）で取り上げた金融庁と日本銀行の要請は、フロンティアAI（最先端の高性能AIモデル）によって脆弱性の発見から攻撃までの期間が短くなり得ることを指摘していました。その備えとして、ソフトウェアやネットワークの構成を再確認し、パッチの適用対象をすぐに特定できる状態も求めています。また、検証不足による障害と、適用を待つ間の攻撃リスクを比べ、検証項目や範囲を絞れないか検討するよう促しています。金融機関向けの要請ですが、対象や影響範囲の調査に時間がかかるほど、検証や適用に使える時間が減る点は、他の業種も同様です。

　IT資産管理と構成管理はIT運用の基本ですが、筆者がIT運用を支援する中で、更新の判断に使える情報がそろっていない企業が多いと実感しています。台帳があっても実態を把握できておらず、緊急時に調査から始めなければならないような状態に、サイバー攻撃への備えの危うさを感じます。管理ツールによる自動収集を活用するとともに、ソフトウェアの更新や構成変更の結果を反映し、実際の稼働状態に合わせて情報を維持する必要があります。

　「更新しない」という判断の中に、「更新できない」という問題が隠れていることがあります。資産・構成情報が足りず、影響範囲を確かめられないために見送るケースは、その一つです。

　リスクを評価した上で繁忙期を避けた日程を決め、検証や要員の確保も進めているなら、それは実施時期を選んだ上での延期です。一方、検証環境がない、担当者が分からない、委託先の対応体制が決まっていないといった理由で「次回検討」を繰り返しているなら、期日を延ばすだけでは準備は進みません。

　両者を同じ「延期」として扱うと、本来は環境や体制を整えるべき問題が、いつ実施するかという日程の問題に置き換わってしまいます。脆弱性管理で未対応のパッチや対応期限を追っていても、見送りの原因に手を付けていなければ、同じ判断を繰り返すことになります。

　見送りを判断する責任者は、誰がいつまでに何を整えるかを決め、必要な予算や要員の確保、関係部門や委託先との調整を進める役割を担うことが求められます。再び見送る際には、前回の見送り以降、更新に必要な条件はどこまで整ったかを確かめる。先送りを認める判断と、更新できる状態を作る責任を切り離さないことが重要だと考えます。

　システムが今日も問題なく動いていることは、必要なときに更新できることの証明にはなりません。パッチの提供を受けられるバージョンを利用しているか、更新対象と影響範囲を把握しているか、検証と適用に必要な時間や要員を確保できるか。こうした具体的な準備が、「必要になったら更新する」という判断を支えます。「今は更新しない理由」と併せて、「必要になったときに更新できる可能性」も確かめる。そこまでを含めて、平時の運用を評価すべきではないでしょうか。

IT業界のアナリストとして20年以上の経験を有する。グローバルITリサーチ・コンサルティング会社において15年間アナリストとして従事、クラウドサービスとソフトウェアに関する市場調査責任者を務め、ベンダーやユーザー企業に対する多数のコンサルティングにも従事した。また、複数の外資系ITベンダーにおいて、事業戦略の推進、新規事業計画の立案、競合分析に携わった経験を有する。2023年よりITRのアナリストとして、クラウド・コンピューティング、ITインフラストラクチャ、システム運用管理、開発プラットフォーム、セキュリティ、サステナビリティ情報管理の領域において、市場・技術動向に関する調査とレポートの執筆、ユーザー企業に対するアドバイザリーとコンサルティング、ベンダーのビジネス・製品戦略支援を行っている。イベントやセミナーでの講演、メディアへの記事寄稿の実績多数。

IT部門は「止める判断」を下せるか？　フロンティアAIによって変わる脅威への対応法障害やサイバー攻撃の現場で「止めない」を守り続けることが、最悪の選択になることがあります。復旧が遅れる本当の原因と、RTOでは測れない「止める判断」の設計、そして経営層や関係部門の調整の在り方をユーザー企業のIT部門の視点から考えます。
PHPに深刻な脆弱性　更新だけで対策は終わらない、企業が最初にやるべき2つのこと PHPの開発チームが、認証不要のリモートコード実行につながる2件の重大脆弱性を修正するセキュリティリリースを公開した。IPAも注意喚起を出し、速やかな適用を促す。だが、全てのシステムを直ちに更新できる企業ばかりではない。何から手を付けるべきか。
「今夜に対応して頂きたい」総理の異例投稿　PHP騒動が残した「運用」という教訓多くのWebサイトを支えるPHPに攻撃コードが存在する重大脆弱性が見つかり、2026年10月21日夕方から夜にかけて、各社が一斉に緊急メンテナンスへ踏み切りました。現職総理がSNSでパッチ適用を呼び掛ける異例の事態から、企業と個人は何を学ぶべきでしょうか。
Oracle Javaに55件の脆弱性　IPAが「早急に適用を」と促す対象は IPAはOracle Javaの脆弱性について注意喚起した。修正された55件のうち49件は、認証を必要とせずネットワーク経由で悪用される可能性がある。被害は攻撃者によるPCの制御に及ぶ恐れもあるという。