AI時代の脆弱性対応とレガシーシステムのリスク管理

AIの進化は、ソフトウェア開発の生産性だけでなく、サイバーセキュリティの前提も変え始めています。

2026年10月、PHPの深刻な脆弱性として公表された「PHP2Shell」は、その変化を考えるうえで重要な事例です。AIの支援によって、長年見つけにくかった脆弱性の発見や、悪用可能性の検証が進む一方、企業には従来以上に迅速かつ確実な対応が求められます。

しかし、経営やIT部門が考えるべき問題は、脆弱性が発見されたことだけではありません。

自社が保有・運用するシステムをどこまで把握し、影響を評価し、安全に修正できるのか。

この問いに答えられる体制がなければ、脆弱性情報を早く入手できても、事業リスクを十分に低減できるとは限りません。

本記事では、PHP2Shellをきっかけに、AI時代における脆弱性対応の変化と、レガシーシステムを抱える企業が見直すべき管理・開発・保守のあり方を考察します。

PHP2Shellが示した、脆弱性対応の新しい課題

2026年10月21日、PHP Foundationは、PHPに関する2件の重大な脆弱性について情報を公開し、修正プログラムを提供しました。対象となる脆弱性はCVE-2026-109618およびCVE-2026-109619で、報道では深刻度の評価値が9.2とされています。

PHPは、WordPressなどのCMSや、Laravelなどのフレームワークを利用したWebサイト・Webシステムで広く使われています。そのため、PHPの脆弱性は、特定のWebサイトだけでなく、企業の情報発信、顧客向けサービス、業務アプリケーションなどにも関係する可能性があります。

今回注目されたのは、AIが脆弱性の発見や悪用可能性の検証を支援した点です。人間の研究者だけでは分析に時間を要する複雑なコードであっても、AIを活用することで、潜在的な問題を見つけ、検証するまでのハードルが下がりつつあります。

ここで重要なのは、AIがすべての脆弱性を自動的に発見できるということではありません。AIの能力は、対象コード、実行環境、与えられた情報、検証方法などに左右されます。

それでも、脆弱性を発見し、攻撃に利用できるかどうかを調べるための時間や技術的な負担が小さくなれば、企業が対応に使える時間も相対的に短くなる可能性があります。

従来は、複雑な脆弱性を発見してから実際の攻撃に利用するまでに、一定の技術力と時間が必要でした。しかし、その前提を固定的に考えることは難しくなっています。

企業は、脆弱性情報が公開された後に対応を始めるだけでなく、影響を受けるシステムを迅速に特定し、修正を実行できる状態を日頃から整えておく必要があります。

問題は脆弱性そのものより、対応できる状態にあるかどうか

脆弱性が公表された際、企業が最初に確認すべきことは、対象となるソフトウェアを使用しているかどうかです。

しかし、実際の企業システムでは、この確認だけでも簡単ではありません。

例えば、次のような状況が考えられます。

コーポレートサイトや業務システムが、どのPHPバージョンで稼働しているか分からない。
開発会社に保守を委託しており、社内にソースコードや構成情報が十分に残っていない。
古いライブラリやプラグインが、現在のシステムでどのように利用されているか把握できていない。
複数のシステムが同じサーバーや共通コンポーネントに依存しているが、影響範囲をすぐに特定できない。
修正プログラムを適用したいものの、既存機能への影響やサービス停止のリスクを判断できない。

こうした問題は、必ずしもセキュリティ専任者の不足だけが原因ではありません。長年の機能追加、担当者の異動、開発会社の変更、ドキュメントの更新不足などが重なり、システムの実態と管理情報が乖離していることも一因です。

つまり、脆弱性対応の速度は、インシデント発生後の対応力だけで決まるわけではありません。平時にどこまでシステムの構造を把握し、変更に必要な情報を維持できているかによっても左右されます。

システムの全体像を把握できていなければ、影響範囲を判断できない。影響範囲を判断できなければ、安全な修正計画も立てにくい。

この連鎖こそ、レガシーシステムを抱える企業が見落としやすい課題です。

パッチを適用するだけでは、対応が完了しない理由

脆弱性への基本的な対応は、公式情報を確認し、影響の有無を評価したうえで、修正プログラムを適用することです。

ただし、実際の業務システムでは、更新作業を実施すればすべてが解決するとは限りません。

例えば、古いPHPで動作しているWebシステムを更新する場合、アプリケーション本体だけでなく、フレームワーク、ライブラリ、プラグイン、サーバー設定などとの互換性を確認する必要があります。更新によって既存の処理が動かなくなれば、セキュリティ上のリスクを低減できても、業務上の障害を引き起こす可能性があります。

そのため、実務では次のプロセスを一体として考えることが重要です。

1. 資産と利用環境を把握する

対象となるシステム、PHPのバージョン、依存ライブラリ、稼働環境、外部との接続関係を確認します。

管理台帳に記載された情報だけを信用するのではなく、実際の稼働環境との整合性を確認することが重要です。

2. 影響範囲と優先順位を判断する

脆弱性の深刻度だけでなく、外部からアクセス可能か、どのようなデータを扱っているか、侵害された場合にどの業務が停止するかなどを踏まえて優先順位を決めます。

すべてのシステムを同時に修正できない場合でも、リスクと事業影響に基づいて対応順序を明確にする必要があります。

なお、今回のように緊急性の高い脆弱性については、通常の計画に固執せず、公式の勧告に従って緊急対応を優先する判断も求められます。

3. 修正と変更管理を行う

修正済みバージョンへの更新、必要なコード変更、設定の見直しなどを実施します。

すぐに更新できない場合は、公式の勧告や専門家の判断に基づき、アクセス制限などの暫定措置を検討します。ただし、暫定措置は修正そのものの代わりにはなりません。

また、変更前のバックアップ、復旧手順、作業承認、影響を受ける関係者との調整も欠かせません。

4. テストと監視によって結果を確認する

更新後は、起動確認だけでなく、重要な業務機能、外部連携、データ処理、認証・認可などを確認します。変更内容に応じた回帰テストを行い、想定外の不具合がないかを検証します。

さらに、侵害の可能性がある場合は、パッチ適用だけで対応を終えず、ログや不審なプロセス、アカウント、通信などを調査し、必要な封じ込めや復旧を進める必要があります。

修正できたことと、リスクが解消されたことは同じではありません。 更新後の検証と、必要に応じた侵害調査まで含めて、対応の完了を判断することが重要です。

CTO・CIOが見直すべき、レガシーシステムの管理

今回の事例を、単にPHPのバージョンを更新する問題として捉えると、重要な論点を見落とす可能性があります。

経営・IT部門に求められるのは、個別の脆弱性への対応だけでなく、将来の脆弱性にも対応できるシステム管理の仕組みを整えることです。

その際、次の3つの観点が判断の軸になります。

システムの構造を把握できているか

最初に確認したいのは、保有するシステムの一覧だけでなく、その内部構造と依存関係をどこまで説明できるかです。

例えば、どのシステムがどのバージョンのランタイムやライブラリを利用しているのか。どの機能が外部公開されているのか。修正した場合、どの業務やシステムに影響するのか。

こうした情報が不足している場合、脆弱性対応のたびに調査を一からやり直すことになります。

AIによるコード解析やドキュメント生成は、ソースコードの理解、依存関係の整理、変更影響の把握などを支援する手段になり得ます。ただし、生成された情報をそのまま正しいとみなすのではなく、実際のコードや稼働環境との照合が必要です。

安全に変更できる設計とテスト基盤があるか

長期間稼働しているシステムでは、仕様書が古い、テストコードが不足している、特定の担当者しか業務ロジックを理解していない、といった問題が生じることがあります。

この状態では、小さな修正であっても影響範囲を特定できず、変更を先送りする判断につながりかねません。

対策としては、重要な業務フローの文書化、依存関係の整理、テストの整備、変更手順の標準化などが考えられます。

AIを活用すれば、既存コードの分析やテスト作成を効率化できる可能性があります。しかし、AIが生成したテストが業務上の正しさを十分に保証するとは限りません。重要な業務ルールについては、担当者による確認と実際の動作検証が必要です。

目指すべきなのは、単にコードを新しくすることではありません。必要な変更を、影響を把握しながら、安全かつ継続的に実施できる状態をつくることです。

保守とセキュリティの責任が明確になっているか

システムの開発を外部に委託している企業では、障害や脆弱性が発生した際に、誰が影響調査を行い、誰が修正を承認し、誰がテストと復旧を担当するのかを明確にしておく必要があります。

開発会社、インフラ事業者、社内IT部門、セキュリティ担当者の役割が分断されていると、技術的な問題そのものよりも、情報共有や判断の遅れが対応時間を延ばすことがあります。

特に、開発当初の担当者が離れていたり、保守契約が終了していたりするシステムでは、ソースコード、設計資料、環境情報、運用手順へのアクセスを確認することが重要です。

外部パートナーを選定する際も、開発能力だけでなく、既存システムの理解、変更時のテスト、ドキュメント整備、運用への引き継ぎまで対応できるかを評価する必要があります。

延命・改修・再構築をどう判断するか

脆弱性への対応をきっかけに、レガシーシステムを全面刷新すべきだと考える企業もあるかもしれません。しかし、重大な脆弱性が見つかったことだけを理由に、全面的な再構築を選ぶのは必ずしも合理的ではありません。

判断すべきなのは、現在のリスクをどの方法で、どの程度の時間とコストで低減できるかです。

選択肢	検討に適した状況	注意点
延命・保守継続	対応範囲が限定的で、現行環境を安全に維持できる	サポート終了や技術的負債を放置しない
部分改修・段階的な更新	問題のあるコンポーネントを特定でき、周辺機能への影響を管理できる	依存関係や回帰テストの整備が必要
再構築・モダナイゼーション	サポート終了、構造の複雑化、変更困難などの問題が継続している	移行期間、業務影響、データ整合性、総コストを評価する

重要なのは、緊急の脆弱性対応と、中長期的なシステム刷新を同じ判断にまとめないことです。

まずは公式の勧告に基づいて緊急リスクを低減し、その後、保守性や変更コスト、事業継続性を評価して、必要な改善を計画する。この二段階の考え方が、過剰な投資とリスクの放置の両方を避けるうえで有効です。

AIは対応を加速するが、責任を代替するわけではない

AIによるコード解析、脆弱性の検出支援、ドキュメント生成、テスト作成は、既存システムの調査や改修に必要な時間を短縮する可能性があります。

一方で、AIの出力には誤りや見落としが含まれる可能性があり、実際のシステム構成や業務要件を知らなければ、適切な修正方針を決められない場合もあります。

特に、ソースコードや顧客情報をAIサービスに入力する場合は、利用する環境のデータ取り扱い、アクセス権限、情報管理ルールを確認する必要があります。

AIを導入すること自体を目的にするのではなく、どの工程を効率化し、どの判断を人間が担い、どのように結果を検証するかを明確にすることが重要です。

例えば、AIを活用してコードや依存関係の調査を進めながら、エンジニアが変更内容をレビューし、テスト結果を確認し、業務への影響を判断する。こうした役割分担によって、速度と品質の両立を目指せます。

最終的な責任は、AIではなく、システムを運用する企業と、その対応を担う関係者にあります。

まとめ：次の脆弱性に備えられるシステムへ

PHP2Shellの事例が示しているのは、AIが脆弱性を発見する能力を高める一方で、企業側にも、システムを理解し、修正し、検証する能力が求められるということです。

今後、脆弱性への対応速度がますます重要になるとすれば、企業が取り組むべきことは、緊急時の作業を速くするだけではありません。

自社のシステムとソフトウェアの利用状況を把握する。
依存関係と変更の影響範囲を説明できる状態にする。
修正、テスト、復旧の手順を整備する。
AIを調査・開発・テストの支援に活用し、結果を検証する。
保守責任と技術情報を、特定の担当者や開発会社だけに依存させない。

これらは、セキュリティ対策に限らず、システムの保守性、開発効率、事業継続性を改善するための基盤でもあります。

システムの刷新は、必ずしも一度にすべてを置き換えることではありません。現状を把握し、リスクの高い部分から優先順位を付け、段階的に変更できる状態を整えることも、重要なモダナイゼーションです。

AIの進化によって変わるのは、脆弱性を発見する技術だけではありません。企業がシステムを管理し、変化に対応するための能力そのものが問われています。

Synoraは、既存システムの理解から改修・開発、AIを活用したモダナイゼーションまで、企業のシステム改善を技術面から支援します。目指すのは、単に新しい技術を導入することではなく、企業が自社のシステムを理解し、継続的に改善できる基盤をつくることです。

※本記事は、一般的なシステム管理・開発の観点から解説したものであり、個別の脆弱性診断やインシデント対応を保証するものではありません。実際の対応では、PHP公式のセキュリティ情報や関係機関の最新の勧告を確認してください。