PHP 8へ更新する前に確認！WordPressプラグイン・テーマ互換性の調べ方

2026年10月23日

2026年10月23日確認。PHPの修正版へ急いで切り替えるとき、WordPressのプラグインやテーマが新しい実行環境で動くか不安になるものです。しかし「不具合が怖いから古いPHPを維持する」だけでは、2026年10月21日に公表されたPHPの重大な欠陥への対応が遅れます。安全な進め方は、更新を止めることではなく、影響の大きい機能から互換性を確認し、修正済みPHPへ移行することです。

PHP公式はCVE-2026-109618とCVE-2026-109619に対応したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開し、更新が唯一の完全な対策だと説明しています。WordPress公式もサイト管理者へPHPの早急な更新を求めています。本記事は脆弱性の技術詳細やホスト別の操作ではなく、プラグイン・テーマ・独自コードの互換性を確認しながら、事業機能を止めずに更新する手順を扱います。欠陥の全体像はPHP2ShellとWordPressの対応策をご確認ください。

利用する根拠は、PHP公式の緊急リリース、WordPress公式の注意喚起、WordPress Coreの互換性表です。プラグインごとの対応は提供元が更新するため、作業当日にその公式ページやサポートへ再確認してください。

PHP更新前に確認すべき互換性の範囲を決める

「WordPressが新しいPHPをサポートしている」ことと、「自分のサイトの全機能が動く」ことは別です。WordPress本体、プラグイン、テーマ、子テーマ、独自スニペット、決済や予約などの外部サービス連携は別々に確認する必要があります。WordPress CoreのPHP互換性表は本体の判断には役立ちますが、個別プラグインの動作保証書ではありません。移行先のPHP系統を選ぶ前に、サイト内の構成要素と停止時の影響を洗い出します。

機能から逆算して棚卸しする

管理画面のプラグイン一覧を単に保存するだけでは足りません。読者から見える主要な行動と、それを実現するプラグインや独自コードを対応させます。問い合わせ、購入、予約、会員ログイン、資料ダウンロード、メール配信、検索、画像処理、バックアップ、セキュリティ機能の順に、サイト固有の導線を列挙してください。たとえば「フォームプラグインが有効」は機能の説明ではありません。「送信後に自動返信が届き、CRMにも登録される」までが検証対象です。

一つの機能が複数の部品へ依存することがあります。問い合わせは画面のフォーム、スパム判定、メール送信、Webhook、通知先の受信設定の連鎖です。決済はカート、支払事業者との接続、在庫、領収書、注文メールまでつながります。PHP更新で本体の表示だけ正常でも、連鎖の途中が失敗すると実害が出ます。利用者の重要度が高い機能を上に並べ、テスト時間が限られるときはそこから試します。

「対応済み」表示の読み方

プラグインの「Requires PHP」は一般に必要な最低PHP版を示します。たとえば最低PHP 8.0と表示されても、PHP 8.5で十分に検証済みという意味ではありません。WordPressのプラグインヘッダーの説明、提供元の変更履歴、FAQ、サポート情報を合わせて確認します。WordPress.orgの「Tested up to」は主にWordPress本体の版に関する表示で、PHPの全系統に対する動作保証とは分けて読みます。

商用プラグインでは、公式配布ページ、ライセンス契約に含まれるサポート範囲、利用中の版番号、直近の修正履歴を確認します。公開情報が「PHP 8対応」の一文だけなら、どの8系までを検証したのか、現在使っている版で有効なのかを問い合わせます。公開リポジトリに更新がないことも、必ずしも動作不良を意味しませんが、サポート窓口がない場合はリスクとして記録します。提供元の回答日を残し、後から更新された説明と区別してください。

自社制作のテーマやスニペットを忘れない

外部プラグインばかり調べ、子テーマのfunctions.php、独自プラグイン、管理画面で設定したコードスニペットを見落とすことがあります。これらは提供元が自動的に互換性を保証してくれません。制作会社や退職した担当者が書いたコードなら、所有者、保守契約、版管理、テスト可能な環境を確認します。WordPressの標準テーマへ切り替えると動く場合でも、その瞬間にサイトの表示や機能が変わるため、本番での確認には計画が必要です。

対象	確認する証拠	実機テスト	不明な場合の扱い
WordPress本体	公式のPHP互換性表、利用中の版	管理画面・投稿・更新	本体の更新計画を立てる
重要プラグイン	提供元の対応表、変更履歴、サポート回答	購入・送信・予約など一連の操作	提供元へ確認し代替を検討
テーマ・子テーマ	公式の更新情報、自社の変更履歴	主要ページと画面幅、テンプレート	制作担当にコード調査を依頼
独自コード・連携	リポジトリ、API仕様、担当者	入出力とエラー処理	実行箇所を特定して隔離テスト
PHP拡張	ホストの提供一覧と設定	画像、メール、DB、外部API	ホストへ提供可否を照会

更新先のPHP版をどう選ぶか

2026年10月21日発表の公式修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。ただし、共用ホストやLinuxディストリビューションがセキュリティ修正を旧番号へバックポートする場合、管理画面に見える数字だけでは最終判定できません。ホストの告知で今回のCVEへの対応を確認し、不明なら契約プランとドメインを添えて問い合わせます。WordPressの公式注意喚起もホストへ確認しつつ早急にPHPを更新するよう呼びかけています。

同じ系統のパッチと系統をまたぐ更新を分ける

現在PHP 8.4を使い、8.4.27へ変更できるなら、まず同じ系統の修正版へ移る案を検討できます。PHP 8.2から8.5へ一気に移るより、言語仕様の差による不具合を切り分けやすいためです。ただし「同じ系統なら検証不要」ではありません。ホストのPHP実行方式や拡張、設定の変更が同時に行われれば影響が出ます。逆に現在の系統に修正パッケージがない場合は、修正済みの別系統へ上げる必要があります。ホストが提示する選択肢とサポート期間を照合します。

PHP公式のサポート表によると、PHP 8.2のセキュリティサポートは2026年12月31日までです。8.2.35へ更新できても、それを長期の最終地点にしないでください。PHP 8.3・8.4・8.5のサポート期間と、WordPress本体・主要プラグインの対応を確認し、次の移行日を決めます。契約上の延長サポートやバックポートがある場合は提供元の条件を確認します。PHP公式の番号とホストの版表示だけを機械的に比較しないことが重要です。

旧PHPへ戻すという選択のリスク

更新後に一部機能が壊れても、未修正のPHPへ戻すと今回の脆弱性への対応が後退し得ます。PHP公式は設定変更やWAFなどの暫定策を完全な解決とは位置付けていません。まずは互換性問題を修正したプラグインへ更新する、修正済みの別系統を試す、対象機能を一時停止する、公開範囲を制限するなどをホスト・保守担当と検討します。やむを得ない緊急ロールバックには承認者、理由、公開範囲、監視、再更新期限を明記し、恒久的に旧版を使い続けないでください。

PHP 8.1以前はPHPプロジェクトの通常のサポート外です。旧系統でしか動かないプラグインを使っている場合は、そのプラグインを守るためにサイト全体を古いPHPへ固定する判断になっていないか見直します。代替プラグインや機能改修、サーバー移行が必要かもしれません。ホストやOS提供元によるバックポートがあるなら、今回の欠陥と将来のサポート範囲を文書で確認します。単に「古いが動く」という状態は安全の根拠になりません。

ステージングで互換性を検証する手順

事前検証では、本番サイトの複製であるステージングを用意し、実際に使うPHP版へ切り替えます。WordPress公式のPHP更新の説明も、事前準備としてバックアップ、WordPress・テーマ・プラグインの更新、互換性問題の確認を挙げています。ステージングは本番と「似ている」だけでは不十分です。テーマ、重要プラグイン、PHP拡張、データベース、キャッシュ、外部連携の差を把握し、検証結果が本番に移せる状態を作ります。

複製するものと複製しないもの

ファイルとデータベースのバックアップを取り、復元テストで戻せることを確認します。複製先には本番のテーマ・プラグイン・設定をそろえます。一方で、実際の決済、通知メール、外部CRMへの書き込みなどは、テスト用の接続先へ変更するか停止します。顧客の個人情報を検証環境へ無条件に複製せず、権限・保存期間・マスキングを決めます。ステージングが検索エンジンから見える場合は、認証やアクセス制限を掛け、公開URLの重複を避けます。「検索エンジンに表示しない」設定だけでは認証の代わりにはなりません。

本番とステージングでホストの提供PHPが違うと、テストで成功した版を本番で使えないことがあります。ドメインごとのPHP設定、PHP-FPMとWebサーバーの構成、利用できる拡張、メモリ上限、ファイル権限を比較します。相違点はテスト記録に書きます。決済や会員管理が本番データでしか動かない設計なら、非本番用のアカウントやSandboxを用意できるか提供元へ確認してください。実ユーザーの注文や通知を作ってしまう検証は避けます。

テスト開始前の「成功条件」を文章にする

事業責任者が「サイトが普通に動けばよい」と伝えるだけでは、検証担当はどこまで試せばよいか判断できません。機能ごとに入力、操作、期待結果、失敗時の影響を一行ずつ書きます。たとえば問い合わせなら「テスト用アドレスから送信し、画面に完了表示が出て、管理画面に保存され、通知先へ一通だけ届く」です。購入なら「テスト決済が成功し、在庫が一回だけ減り、注文一覧と通知内容が一致する」です。正常系だけでなく、必須項目の未入力、決済の失敗、ログイン期限切れも試します。

テストで使うデータと責任者を決めることも大切です。サポート担当が検証後に「テスト注文」と「実注文」を取り違えると、互換性問題とは別の業務事故になります。テスト用アカウント、件名、注文番号の命名規則を決め、検証後は削除または識別できる状態にします。外部サービスのテスト環境がない場合は、その機能を「未検証」と明記し、本番切替後の最初の確認者と連絡先を指定します。未検証を合格扱いしないことが重要です。

テストは画面表示だけで終えない

「トップページが開いた」だけでは互換性は分かりません。テスト利用者として、検索から記事を開く、問い合わせを送る、ログインする、購入する、予約する、管理画面で投稿を更新する、バックアップを実行するという一連の操作を確認します。運用者と利用者の両方の視点を含めます。外部連携があるなら、送信元と送信先でデータが一致したかまで見ます。対象機能にテストデータを使ったこと、後片付けをしたことも記録します。

HTTP応答と画面表示に加えて、PHP・WordPressのエラーログを確認します。目に見えない非推奨警告が大量に出ている場合、今すぐ500ではなくても将来の更新で停止要因になることがあります。ただし警告を一律に致命的障害として扱わず、種類、発生箇所、頻度、事業影響で優先度を付けます。WordPressの公式デバッグ文書を参照し、公開画面へエラーを表示しない設定で検証し、ログには個人情報が含まれ得ることを踏まえて管理します。

互換性チェックツールを使うときの限界

自動診断ツールは、コード内に古い関数や既知の互換性問題がないかを探す補助になります。しかし、実際の決済フローやAPI連携、特定のページでのみ実行されるコードまでは保証できません。静的なスキャンで「問題なし」でも、実機で送信すると失敗することがあります。逆にスキャン警告が出ても、使っていない経路や条件付きコードで影響が限定される場合もあります。ツールの出力を安全宣言にせず、実行テストと提供元の回答、ログを組み合わせます。

検証対象	具体的な操作	合格基準	失敗時の対応
閲覧	トップ、記事、重要LPを開く	表示とHTTP応答が正常	テーマ・キャッシュ・ログを確認
フォーム	テスト送信と通知確認	保存、通知、連携が完了	フォームとメール経路を分離
会員	登録、ログイン、権限別閲覧	権限を越えず正常に利用	認証プラグインとセッションを確認
購入・予約	Sandboxで完了まで進める	注文・予約・通知が一致	決済側とサイト側のログを照合
管理運用	投稿編集、画像、バックアップ	担当者の通常作業が完了	管理画面専用プラグインを確認

プラグインやテーマが非対応だった場合の判断

互換性テストに失敗したとき、全サイトのPHP更新を無期限に止める必要はありません。まずエラーと対象機能を特定し、提供元の修正版、設定変更、代替プラグイン、対象機能の一時停止を順番に検討します。WordPress公式も、問題が見つかったらテーマやプラグインの開発元に問い合わせ、対応が得られない場合は同等機能の代替を検討するよう案内しています。サイト固有の優先順位に従い、事業影響を比較します。

提供元へ問い合わせる情報をそろえる

「新PHPで動きません」だけでは調査しにくいため、PHPの切替前後の版、WordPress版、プラグイン・テーマの版、発生URL、再現操作、エラーの種類、発生時刻、ステージングか本番かをまとめます。ログの抜粋は個人情報や秘密を削除して共有します。回答で「対応予定」とだけ言われた場合は、対象版、提供予定日、回避策、サポート継続期間を確認します。重要な機能では口頭回答だけでなく、サポートチケットやリリースノートを残します。

無料プラグインと商用プラグインでは対応窓口や保証の範囲が異なります。「更新日が新しいから安全」「導入数が多いから今回のPHP版でも動く」という推測は避けます。逆に数か月更新がないだけで即危険と決めるのも早計です。公式の対応声明、実際の更新内容、テスト結果を中心に判断します。更新のためにライセンスの再契約が必要な場合は、費用、期限、乗換え可能性を事業責任者へ示してください。

代替プラグインへの移行はデータと権限が核心

フォームや会員プラグインを別製品へ替えると、画面だけでなく、過去の送信履歴、会員情報、権限、メールテンプレート、Webhook、短縮コードが影響を受けます。代替品の「同じ機能」という広告文言だけで置き換えず、移行できるデータ、移行できないデータ、停止時間、運用担当者の教育を確認します。旧プラグインを消す前にエクスポートと復元テストを行い、新旧が同時に動く期間が必要か判断します。二重送信や二重決済が起きないよう、切替時刻を決めます。

不要なプラグインは削除より先に用途を確認

長く使っていないように見えるプラグインも、月次バッチや管理者だけの画面で使われていることがあります。停止を検討するなら、いつ誰が最後に利用し、どのデータを保管し、削除で何が消えるかを調べます。セキュリティ、バックアップ、キャッシュは見た目から用途が分かりにくい代表例です。ステージングで無効化し、管理画面、予約処理、バックアップを検証します。用途不明のまま本番で一括削除するのは避けます。

独自テーマの修正では、PHPの新しい系統で互換性のない記述を変更するときも、見た目の確認だけで終えないでください。メニュー、ウィジェット、SEO出力、カスタム投稿タイプ、構造化データ、フォームの埋め込みなどに影響し得ます。ソースを版管理し、修正対象とレビュー担当を決め、ステージングで旧版と新版を比較します。これにより「どの変更で壊れたか」を追いやすくなります。

小規模サイトと業務サイトで対策を変える

記事閲覧と簡単な問い合わせが中心の小規模サイトでは、重要ページ、フォーム、管理画面、バックアップを短い検証表にまとめられます。一方、ECや会員サービスでは、売上・個人情報・外部連携に関わる機能を対象に、提供元と保守会社を含めた確認が必要です。同じ「プラグイン一つの不具合」でも、表示用の目次が壊れた場合と、購入を二重処理する場合では、復旧の優先順位が異なります。単純なサイトで大掛かりな承認を増やしすぎず、重要サイトでテストを省きすぎないよう、事業影響で作業量を決めます。

切替日までに非対応プラグインの修正版が間に合わない場合は、対象機能の運用停止と代替窓口を準備します。たとえば予約が止まるなら、電話や別の安全なフォームで受ける期間、受付時間、手入力時の重複防止、後からのデータ移行担当を定めます。ただし個人情報を通常より弱い方法で受け取ることは避けます。暫定運用の終了条件と期限を書き、置き換えが完了したら古い機能を停止します。「とりあえず手作業」は期間と責任者を決めなければ長期化しやすくなります。

本番切替の当日手順と完了条件

事前検証が済んだら、本番での作業日時、責任者、復旧の連絡先を決めます。バックアップは作成した事実だけでなく、復元できることが重要です。ファイルとデータベースの両方が必要か、取得時刻と保持場所はどこか、復元で失う直近の注文や投稿は何かを確認します。予約・ECなど更新が続くサイトでは、複製後に発生したデータをどう扱うかも決めます。安易にステージングのデータベースを本番へ丸ごと戻すと、正しい新規データを失う恐れがあります。

変更を同じ時間帯に重ねない

PHP版を切り替える当日に、大規模なテーマ改修やプラグイン全更新、DNS変更まで同時に行うと、障害の原因が分からなくなります。セキュリティ上やむを得ない緊急対応は例外として、変更を小さな単位に分け、各段階で確認します。WordPress本体・プラグインの既知の互換修正版を事前にステージングで試し、本番の適用順序を決めておきます。切替ボタンを押す担当と検証する担当を分けられるなら、相互確認します。

切替前・直後・翌日の三段階で確認

切替前に現行PHP版、重要ページのHTTP応答、フォーム・決済など主要導線、エラーログを記録します。直後にサイトヘルスやホスト画面で新PHP版を確認し、先ほどと同じURL・操作を再実行します。ログへ新たなFatal errorが出ていないかを見ます。翌日には通常のアクセスが集まった状態でログ、エラー率、問い合わせ・注文の件数を確認します。サイトが「表示される」だけでは、通知が届かない、管理画面の保存だけ失敗するといった遅延した不具合を拾えません。

エラーが出たら、PHP切替後のHTTP 500と白画面の復旧手順を参考に、切替時刻と最初のエラーを照合します。旧PHPへ直ちに戻すのではなく、プラグイン・テーマ・PHP拡張・サーバー設定のどこに問題があるかを確認します。重要機能だけが失敗する場合は、機能を一時停止して代替窓口を示す方法もあります。全体停止で短時間に修復できないなら、メンテナンス表示やアクセス制限を検討し、ホストへエスカレーションします。

完了と判断する条件

「修正済みPHPが適用されている」「WordPressと主要機能が動く」「エラーログに新規の致命的エラーがない」「担当者と確認時刻を記録した」の四条件をそろえます。修正済みかどうかはホストの告知と実行環境で確認します。画面上の選択値だけが変わり、実際のPHPワーカーが旧版のままなら完了ではありません。ホストがバックポート修正を使う場合は、その根拠となる告知を保存します。

改善の証拠として「問い合わせ件数が元へ戻った」などの成果も見ますが、更新直後の短い期間に検索流入や売上の変動をPHP更新だけの効果と断定しないでください。重要なのは安全な実行環境と業務機能の継続です。検索エンジン向けには、主要URLがHTTP 200で返ること、canonicalやnoindex設定が意図せず変わっていないこと、画像やスクリプトが読み込まれることも確認します。ステージングの設定を本番へ移してnoindexになった、という失敗も防ぎます。

作業後の引き継ぎを省かない

更新を担当した制作会社だけが結果を知っていると、数か月後に別の担当者が同じ確認を繰り返すことになります。作業記録には、サイトURL、ホストとプラン、切替前後のPHP版、今回の修正適用の根拠、WordPress・テーマ・主要プラグインの版、検証結果、未解決の警告、次回の再確認日を残します。プラグイン提供元から「次の版で修正予定」と回答が来ている場合は、そのチケット番号と担当者も書きます。機密情報は記録の本文に貼らず、安全な管理場所を参照してください。

次回の更新では、この記録から差分だけを見れば準備が始められます。重要プラグインの更新通知を受ける人、PHPのサポート期限を見直す人、障害時にホストへ連絡する人を決めておきましょう。日常の担当が曖昧なまま緊急リリースを迎えると、互換性の調査より権限の確認に時間が掛かります。技術的な互換性と同じくらい、連絡と承認の流れを整えることが停止時間を短くします。

よくある質問：対応版、未更新プラグイン、緊急性

Q. プラグインに「Requires PHP 8.0」と書いてあればPHP 8.5でも安全ですか？

最低動作版を示す情報だけで、PHP 8.5の実機テストや安全性が保証されるわけではありません。提供元のPHP 8.5に関する情報、更新履歴、サポート回答を確認し、ステージングで主要機能を試してください。同じプラグインでも利用中の版や他プラグインとの組み合わせで結果が変わります。

Q. 更新が止まったプラグインはすべて削除すべきですか？

更新日だけで即削除とは決めません。ただし、提供元のサポートがなく、新PHPでの不具合が解消されず、重要機能や機密情報へアクセスするプラグインなら優先度の高いリスクです。用途、保存データ、代替品、移行コストを調べて計画的に交換します。停止できる機能なら一時停止も検討します。セキュリティ修正を受けられない状態を放置しないことが重要です。

Q. PHP 8.2.35に上げたら今後の移行は不要ですか？

不要ではありません。今回の欠陥への修正という意味では重要ですが、PHP公式サポート表は8.2のサポート終了を2026年12月31日としています。より長くサポートされる系統への移行計画を立て、WordPress本体とプラグイン・テーマの互換性を検証してください。ホスト独自の延長サポートがあるなら、その対象と期限を確認します。

Q. ステージングがない小規模サイトはどうすればよいですか？

ホストの複製機能や保守会社による検証環境を探します。どうしても用意できない場合は、復元可能なバックアップ、影響の少ない時間帯、主要導線の事前記録、ホストの連絡先、メンテナンス表示を用意し、変更を一つずつ行います。テスト環境がないことを理由に古いPHPを無期限で使うのではなく、次回から検証可能な運用へ変える計画も立てます。

Q. WAFを有効にしていれば互換性の問題も脆弱性も解決しますか？

いいえ。WAFは特定の通信を抑える暫定的な防御にはなりますが、PHP本体の欠陥やプラグインの互換性を修正しません。PHP公式は今回の欠陥について更新のみが完全な対策と説明しています。ホストがWAFを導入した場合も、修正適用状況と次の更新時刻を別に確認してください。

まとめ：PHP更新の互換性確認は、プラグインの版表示を見るだけで終わりません。事業上の重要機能を棚卸しし、提供元の一次情報とステージングでの実行結果を合わせ、修正済みPHPで公開機能が動くことを確認します。不具合を理由に旧PHPへ無期限で戻さず、修正、代替、限定停止、公開範囲の調整を選びます。この記事の情報確認日は2026年10月23日です。公開前・作業時にはPHP、WordPress、ホスト、各プラグイン提供元の最新情報を確認してください。

AIスキルで、未来の自分をアップデート！

WordPress運用では、プラグインの棚卸し、変更履歴の要約、検証表の作成など、繰り返しながら正確さが求められる作業があります。AIは整理を手伝えますが、提供元の公式情報や実機テストの代わりにはなりません。WithAIでAIの活用を学び、根拠を確認しながら仕事に役立てませんか。詳しくは下のバナーをご覧ください。