古いPHPを使っているWebサイトで重大な脆弱性が見つかったとき、「設定を変えればよいのか」「サーバーを移行すべきか」で判断が止まることがあります。
2026年10月21日、PHP公式は、複数の対応版で重大な脆弱性を修正し、速やかな更新を案内しました。PHP 8.1以前はPHPプロジェクトの更新対象外であることも示されています。
一方、更新をすぐ適用できない環境では、事業者から危険を減らすための設定変更が案内される場合があります。ただし、これは完全な修復ではなく、一時的な緩和策です。
中小企業では、「今日できる緊急対策」と「今後も安全に使うための移行」を別の仕事として整理すると、判断しやすくなります。AIは、情報の抜けや矛盾を探す補助役として使います。
【1.現在の状態を一枚にする】
最初に、今の環境を一覧にします。
・サーバーのプラン
・PHPのバージョンとサポート状況
・CMS、テーマ、プラグイン
・データベースとバックアップ
・ドメイン、DNS、メールの管理先
・現在起きている不具合と業務への影響
分からない項目は推測で埋めず、「未確認」と書きます。AIへ渡すときも、管理画面のパスワードや秘密鍵は含めません。
サイトだけを見ていると、移行時にメール設定を見落とすことがあります。Webサイト、ドメイン、メールが同じ会社で管理されているとは限らないため、管理先を分けて記録します。
【2.緊急対策の範囲と期限を決める】
すぐ更新できない場合は、利用中のサービス事業者が出している公式案内を確認します。
緊急対策の表には、次の項目を残します。
・変更する設定
・何の危険を減らす対策か
・対策で残る危険
・実施前のバックアップ
・元に戻す手順
・実施担当者
・再確認する日
設定変更後は、サイト表示だけでなく、問い合わせフォーム、管理画面、ファイルのアップロードなども確認します。
ここで大切なのは、「緩和済み」と「修正済み」を区別することです。暫定設定を入れただけで、脆弱性そのものがなくなったとは限りません。
【3.恒久対応を別の工程にする】
次に、サポート中のPHPを使える環境への更新や移行を計画します。
・移行先のプランとPHP
・テーマやプラグインの互換性
・ファイルとデータベースの移行
・SSL証明書
・DNSとメール設定
・テスト環境
・停止時間
・問題が出た場合の戻し方
緊急対策と移行を一つの作業表へ詰め込むと、今日中に行う変更と後日行う検証が混ざります。表を分け、移行には期限と担当者を設定します。
特にDNSを変更する場合は、Webサイトだけでなくメールへの影響も確認します。移行前に現在の設定を保存し、切り替え後の確認項目を決めておきます。
【4.AIで二つの表を比べる】
AIには、設定を決めてもらうのではなく、確認漏れを探してもらいます。
たとえば、次のように依頼します。
「緊急対策表と移行計画表を比較し、根拠、確認日、担当者、期限、完了条件が空欄の項目を示してください。暫定対策を恒久対応と誤って扱っている箇所も分けてください。判断できない内容は推測せず『未確認』としてください」
AIが挙げた候補は、サーバー事業者やPHPの公式情報と照合します。実際の設定変更、公開、切り替えは担当者が確認してから行います。
【完了条件を分ける】
緊急対策の完了条件は、公式案内に沿った設定、動作確認、変更記録、次回確認日の設定です。
恒久対応の完了条件は、サポート中の環境での稼働、互換性確認、DNSとメールの確認、バックアップ、旧環境の扱いまで決まっていることです。
二つを分けることで、「緊急対応は終わったが移行は残っている」という状態を正確に共有できます。
【注意したいこと】
脆弱性対応は、AIの回答だけで判断しないでください。PHP公式、利用中のサービス事業者、IPAなどの一次情報を確認し、不明な点は専門家へ相談します。
バックアップを取らずに設定変更や更新を行うと、元へ戻せない場合があります。最初は対象を一つに絞り、変更前後の状態を記録してください。
【今日からできる小さな一歩】
まず、自社サイトのPHPバージョンとサポート状況を一つ確認してください。
次に、「今日できる対策」と「サポート中の環境へ移る計画」を別の二行に書きます。この二行が、緊急対応と恒久対応を混ぜない出発点になります。
WordPressの不具合やPHP更新後のエラーを整理したい方には、公開中の「WordPressの不具合を調査・修正します」で、原因調査と対応方針の確認をお手伝いしています。