WordPressのPHPバージョンアップは、管理画面で版を切り替える前の互換性確認で成否が決まります。WordPress 7.1はPHP 7.4〜8.5で動きますが、テーマやプラグインが同じ範囲で動く保証はありません。本記事では、WordPressとPHPの対応範囲を一次情報で整理したうえで、WP-CLIでプラグインの要件を一覧にするコマンド、PHPCompatibilityWPでの非互換の検出、ステージングでのdebug.logの確認、本番の切り替えと戻し方までを、2026年10月26日時点の情報で解説します。
まとめ：WordPressのPHPは8.4へ、検証環境で確かめてから切り替え
PHP 8.2以前で動いているWordPressサイトは、2026年12月31日までに8.4へ上げる計画を立てます。8.2は年末でPHP本体のセキュリティ修正が止まり、WordPress.orgの統計では今も57.1%のサイトが8.3未満で動いています。
作業の順番は、本体・テーマ・プラグインの更新、要件の一覧化と静的な互換チェック、ステージングでのPHP切り替えとログの確認、本番の切り替えです。公式の案内にある互換チェッカーのプラグインは保守が終わっており、PHP 8.0までしか判定できません。判定にはWP-CLIとPHPCompatibilityWPを使います。独自に開発したテーマやプラグインがあるサイトは、版上げの前に改修の量を見積もります。
WordPressとPHPの対応関係：7.1系が動く範囲と8.4を移行先にする理由
最初に、WordPress本体がどのPHPで動くのかを確認します。値はWordPressコア開発チームの公式資料から取得しました。
WordPress 7.0・7.1が動くPHP 7.4〜8.5の範囲と6.9以前との差
WordPressとPHPの互換表（2026年8月19日更新）では、WordPressの版ごとに動作するPHPの範囲が定められています。
| WordPress | 対応するPHP | 備考 |
|---|---|---|
| 7.1・7.0 | 7.4〜8.5 | 7.0で7.2・7.3を対象外に |
| 6.9 | 7.2〜8.5 | 7.2・7.3のサイトはこの系列に残る |
| 6.8・6.7 | 7.2〜8.4 | 8.5は対象外 |
| 6.6 | 7.2〜8.3 | 8.4は対象外 |
7.2と7.3の切り捨ては、2026年1月9日のコア開発チームの告知で決まりました。両版の利用が監視対象の4%未満に下がったことが理由です。推奨は8.3以上のままで、最低要件は7.4です。7.0の新機能と本体の更新手順はWordPress 7.0の新機能と安全なアップデート手順で扱っています。
PHP 8.2以前で動くWordPressサイトが57.1%残る統計APIの実測値
WordPress.orgは、更新確認の通信から集計したPHP版の比率をJSONで公開しています。手元で取得するコマンドは次の通りです。
# WordPress.orgが集計するPHP版ごとの利用比率を多い順に表示する
curl -s "https://api.wordpress.org/stats/php/1.0/" \
| jq -r 'to_entries | sort_by(-.value) | .[:8][] | "\(.key)\t\(.value)%"'
# 2026年10月26日の実行結果（上位8件）
# 8.3 27.289%
# 8.2 23.244%
# 7.4 15.154%
# 8.4 10.097%
# 8.1 9.664%
# 8.5 5.501%
# 8.0 3.538%
# 7.3 1.323%8.3未満を合計すると57.1%です。8.4以上は15.6%にとどまります。7.4のサイトは15.2%あり、WordPress 7.1の最低要件ぎりぎりで動いている計算です。
8.2の修正が2026年12月31日に止まる影響と移行先を8.4にする根拠
php.netのサポート表では、8.2のセキュリティサポートが2026年12月31日、8.3が2027年12月31日、8.4が2028年12月31日で終わります。WordPress本体は8.2でも動き続けますが、PHPに脆弱性が見つかっても修正版は出なくなります。2026年10月に公表されたPHP2Shellでは、終了済みの8.1以前に本家の修正版が出ませんでした。
移行先は8.4にします。互換表で7.1が8.4まで対応しており、期限まで残された期間は2年です。8.3は2027年末で終わるため、検証の手間をかけても1年余りで次の版上げが来ます。8.5は本体が対応していても、プラグイン側の対応が8.4より遅れがちです。PHPの版ごとの期限と移行計画の全体はPHPのサポート期限一覧と移行手順にまとめています。
版上げ前の互換性確認：WP-CLIとPHPCompatibilityWPで非互換を洗い出す
PHPを切り替える前に、何が動かなくなるかを机上で洗い出します。先に公式の案内のとおり、WordPress本体・テーマ・プラグインを最新にしておきます。新しい版ほど新しいPHPに対応しているためです。
WP-CLIのrequires_phpでプラグインごとの要求PHPと更新状況を一覧化
プラグインの多くは、ヘッダーのRequires PHPに必要な最低版を書いています。WP-CLIのplugin listは、この値を任意フィールドとして出せます。
# 稼働中のPHPとWordPressの版を確認する
wp eval 'echo PHP_VERSION, " / WordPress ", get_bloginfo("version"), PHP_EOL;'
# プラグインごとの版・要求PHP・動作確認済みのWP版・公式ディレクトリでの状態を出す
wp plugin list --fields=name,status,version,update,requires_php,tested_up_to,wporg_status,wporg_last_updated --format=csv > plugins.csv見るべきは要求PHPより、wporg_last_updatedとwporg_statusです。最終更新が2年以上前のものや、公式ディレクトリから外れたものは、新しいPHPでの動作を誰も確かめていない可能性が高いからです。この列で、検証を厚くするプラグインと、置き換えを検討するプラグインを先に決めます。
PHPCompatibilityWPでテーマと独自プラグインの非互換を検出するコマンド
独自に開発したテーマやプラグインは、静的解析で非互換を探します。PHPCompatibilityWPはPHP_CodeSnifferのルール集で、WordPressが自前で補っている関数を除外し、誤検知を減らした版です。
# 検証用の作業ディレクトリで導入する（PHPCompatibility 10.0.0以上が前提）
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/phpcompatibility-wp:"^3.0@dev"
# 独自テーマと独自プラグインを、8.4で問題になる箇所に絞って検査する
vendor/bin/phpcs -p wp-content/themes/my-theme wp-content/plugins/my-plugin \
--standard=PHPCompatibilityWP --runtime-set testVersion 8.4 \
--extensions=php --report-full=compat-84.txtmy-themeとmy-pluginは自社のディレクトリ名に置き換えます。公式ディレクトリから入れたプラグインまで検査すると件数が膨らむため、まずは自社で直せるコードに絞ります。結果のERRORは8.4で動かない箇所、WARNINGは非推奨の箇所です。
公式が案内するPHP Compatibility Checkerを判定に使わない理由
WordPress日本語版の案内は、互換性の確認にPHP Compatibility Checkerを挙げています。しかし配布ページには、保守が終了しており今後はセキュリティ修正も出ないと明記されています。判定できるのはPHP 8.0までで、8.4への版上げの判断には使えません。
検査の対象も、WordPress.orgに掲載されたプラグインとテーマに限られます。独自開発のテーマや有料プラグインは調べられません。本番サイトに保守の止まったプラグインを足すこと自体も避けたいので、判定は前の2つの手順で行います。
ステージングでのPHP切り替え手順：debug.logで非推奨と致命的エラーを集める
机上の確認で拾えるのは、コードを読んで分かる問題だけです。実際の動作は、本番と同じ構成の検証環境でPHPだけを変えて確かめます。
本番の複製でPHPだけを8.4に変える検証環境の作り方と確認画面
- 本番のファイルとデータベースを取得する（取得と復元の手順はWordPressのバックアップ設計を参照）
- レンタルサーバーのステージング機能、またはサブドメインに本番を複製する
- 検証環境のPHPを本番と同じ版で立ち上げ、表示が本番と一致することを確かめる
- PHPだけを8.4に切り替え、次章のログ設定を入れる
- トップ・記事・固定ページ、問い合わせフォームの送信、管理画面の投稿と更新を一通り操作する
3番目で本番と一致させるのは、PHP以外の差を潰すためです。ここを飛ばすと、出た不具合がPHPの版によるものか、複製の失敗によるものか区別できません。複製の手順はサーバー移行と同じなので、WordPressのサーバー移行の手順も参考になります。
wp-config.phpのWP_DEBUG_LOGで警告を画面に出さず記録する設定
検証環境のwp-config.phpに、WordPressのデバッグ設定を入れます。記述する位置は「That’s all, stop editing!」の行より前です。
// 検証環境だけに入れる。エラーと非推奨の警告を wp-content/debug.log に記録する
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
// 画面には出さない（表示崩れと情報の露出を防ぐ）
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );# 操作をひと通り終えたら、種類ごとの件数と発生源を確かめる
grep -c "PHP Fatal error" wp-content/debug.log
grep -c "PHP Deprecated" wp-content/debug.log
grep -o "wp-content/plugins/[^/]*" wp-content/debug.log | sort | uniq -c | sort -rn最後のコマンドで、ログを出しているプラグインが件数の多い順に並びます。公式の資料では、この設定を本番で使うことは非推奨です。既定のdebug.logはwp-content直下に作られ、Webサーバーの設定によっては外部から読めます。本番に持ち込まないことを確認してから切り替えに進みます。
8.0と8.4で増えるエラー・非推奨の典型と直す順番の決め方
ログの中身は、PHPの版ごとに傾向があります。7.4から上げる場合は、8.0で多くの警告が致命的エラーへ格上げされた点が最大の壁です。詳細はPHP 7.4.xから8.0.xへの移行ガイドにあります。
| ログの種類 | サイトへの影響 | 直す順番 |
|---|---|---|
| PHP Fatal error | その画面が真っ白になる | 最優先。切り替えの前に必ず解消 |
| PHP Warning | 表示は続くが値が欠ける | フォーム・決済など業務の画面から |
| PHP Deprecated | 今は動く。次の版で止まる | 8.4の非推奨は次の版上げまでに |
8.2で非推奨になった動的プロパティや、8.4で非推奨になった暗黙のnullable型は、Deprecatedとして大量に出がちです。8.4時点では動作を止めないため、切り替えの判断はFatal errorが0件かどうかで行います。8.4の変更点はPHP 8.4の新機能と変更点で、型の不整合の検出はPHPStanのレベル運用で補えます。
本番のPHP切り替えと戻し方：レンタルサーバー・VPS・マネージド別
検証でFatal errorが0件になったら、本番を切り替えます。手順は、PHPを誰が管理しているかで変わります。
管理画面で版を選ぶ環境とphp-fpmを入れ替えるVPSでの切り替え手順
レンタルサーバーでは、管理画面でドメインごとにPHPの版を選ぶ方式が一般的です。切り替えは数秒で反映されるため、アクセスの少ない時間帯を選び、直前にバックアップを取ります。マネージドWordPressでは事業者がPHPを管理し、利用者による版の選択はできない場合もある方式です。その場合は、事業者の切り替え予定日までに前章の検証を終えておきます。
VPSや自社サーバーでは、8.4のphp-fpmを並べて入れ、Webサーバーの接続先を切り替えます。旧版のphp-fpmを残しておけば、元に戻すために必要なのは接続先の変更だけです。mbstringやintlなどの拡張は版ごとに入れ直しが必要で、入れ忘れると切り替え直後に致命的エラーが出ます。サイトヘルスの「情報」タブで、切り替え後の版と拡張を確認します。
致命的エラー時のリカバリーモードと業務画面の不具合で旧版へ戻す判断基準
本番で致命的エラーが出ると、WordPressは管理者のメールアドレスへ、問題のプラグインを止めて管理画面に入るためのリンクを送ります。これがリカバリーモードです。原因が1つのプラグインに絞れる場合は、停止して代替を探す方が早く済みます。
旧版のPHPへ戻すのは、問い合わせフォームや会員ログインのような業務の画面が動かない場合です。戻したらすぐに検証環境で原因を特定し、日を改めて切り替えます。戻したまま年を越すのは失敗パターンです。8.2以前に戻した場合、2027年以降はPHP本体の修正が受けられません。
自社で版上げできるサイトと保守会社に任せるサイトの構成別判断基準
ここまでの手順を、誰が実行するかを決めます。条件を示したうえで結論を書きます。
自社で版上げできるサイトと保守会社に任せるサイトの構成による線引き
自社で済むのは、公式ディレクトリのテーマとプラグインだけで構成され、WP-CLIの一覧で最終更新が2年以上前のものが無いサイトです。ステージング機能のあるレンタルサーバーなら、本記事の手順を1日程度で進められます。
任せた方が早いのは、独自開発のテーマやプラグインがある、7.4以前で止まっている、制作した会社や担当者と連絡が取れない、のいずれかに当たるサイトです。PHPCompatibilityWPの検出結果を直すにはPHPの改修が必要で、期限の12月31日に間に合わない原因の一つです。一創のWordPress保守・メンテナンスでは、互換性の調査から独自コードの改修、切り替え後の監視までを請け負っています。保守を内製と外注のどちらで持つかはWordPress保守運用の作業範囲と内製か外注かの判断基準で整理しています。
PHP 7.4のまま据え置くと詰む構成と版上げを急ぐべき3つの兆候
7.4はWordPress 7.1の最低要件を満たすため、今は本体の更新を受けられます。しかし次に最低要件が上がれば、本体の更新が止まり、7.2・7.3のサイトが6.9系に残されたのと同じ状態になります。PHP本体の修正が終了した時期は2022年11月です。
次の兆候が1つでもあれば、版上げを先送りしません。要求PHPを満たさないために更新を適用できないプラグインがある、サイトヘルスがPHPの更新を求める警告、レンタルサーバーからの旧版の提供終了の通知です。どれも、放置すると脆弱性の修正が入らない状態に直結します。WordPress全体の防御策はWordPressセキュリティ対策の設定と確認手順にまとめています。
WordPressのPHPバージョンアップに関するよくある質問と回答
WordPressのPHPの版上げについて、サイト運用の担当者から寄せられやすい質問に答えます。
WordPressのPHPバージョンはどこで確認できますか？
管理画面の「ツール」から「サイトヘルス」を開き、「情報」タブの「サーバー」を展開すると「PHPバージョン」が表示されます。サーバーに入れる場合は、wp eval 'echo PHP_VERSION;'で確認できるのは、WordPressが実際に使っている版です。php -vはコマンドラインのPHPを示すため、Webサーバー側の版と異なる場合があります。値が8.3以上なら、公式の案内では今すぐの更新は不要とされています。
PHPを上げたら画面が真っ白になった場合はどうすればよいですか？
まず管理者宛てにリカバリーモードのメールが届いていないかを確かめます。リンクから管理画面に入れた場合は、原因のプラグインを停止できる状態です。メールが無く管理画面にも入れない場合は、レンタルサーバーの管理画面でPHPを元の版に戻し、サイトの表示を回復させます。そのうえで検証環境にdebug.logの設定を入れ、Fatal errorの発生源を特定してから切り替え直します。
PHP 8.5に上げてもWordPressは動きますか？
WordPress本体は動きます。公式の互換表では、6.9以降がPHP 8.5に対応しています。ただし、WordPress.orgの統計で8.5のサイトは5.5%にとどまり、プラグインの動作確認は8.4より進んでいません。業務で使うサイトは8.4を移行先にし、8.5はプラグインの対応がそろってから検討します。期限は8.4が2028年末、8.5が2029年末です。
WordPress本体とPHPはどちらを先に更新すべきですか？
原則としてWordPress本体・テーマ・プラグインを先に更新します。新しい版ほど新しいPHPに対応しているためで、公式の案内も同じ順番です。例外は、PHPが7.2や7.3のサイトです。WordPress 7.0以降は7.4以上が必要なので、本体は6.9系のまま先にPHPを7.4以上に上げ、その後に本体を7.1系へ更新します。
PHP 7.4のままWordPressを使い続けられますか？
WordPress 7.1は7.4でも動くため、本体の更新は受けられます。しかし7.4はPHP本体のサポートが2022年11月28日に終わっており、以後の脆弱性は直りません。プラグインの作者がヘッダーの要求PHPを上げるたびに、そのプラグインの更新も受けられなくなります。使い続けられるのは、版上げの準備期間までと考えます。
関連記事
- WordPress 7.0「Armstrong」の新機能・変更点と安全なアップデート手順：PHPの版上げの前に済ませる本体の更新手順です。
- PHPのサポート期限一覧：8.2は2026年末で終了、版ごとのEOLと移行手順：WordPress以外のPHPシステムも含めた期限と移行計画を確認できます。
- WordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順：切り替え前の取得と、戻すときの復元の手順をまとめています。
- PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版・更新できない場合の設定：古いPHPを放置したときに起きた事例です。
- WordPress保守運用とは：作業範囲・費用相場と内製か外注かの判断基準：PHPの版上げを含む保守を誰が担うかを判断する材料になります。
