※本記事には広告・アフィリエイトリンクが含まれています。
WordPressの高速化記事を見ると「PHPを新しくすれば速くなる」と簡単に書かれていることがあります。方向としては間違いではありませんが、実運用で重要なのは速度だけではありません。PHPはWordPress本体だけでなく、テーマ、プラグイン、独自コード、画像処理、メール送信、バックアップ処理まで動かす土台です。
2026年10月時点でWordPress Hosting Teamは、新しいWordPress 7.1環境にPHP 8.4.xまたは8.5.xを推奨しています。一方、WordPress 7.1自体はPHP 7.4〜8.5へ互換性を持っています。「動く最低ライン」と「今から選ぶ推奨ライン」は別物です。
WordPress 7.1でPHP 8.4と8.5はどちらを選ぶ？
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| PHP 8.4 | 既存テーマ・プラグインの安定性も重視しつつ、現行のActive Supportを使いたい | 本番へ変える前にステージング確認 |
| PHP 8.5 | WordPress本体・利用プラグインが新しく、互換性確認を終えたサイト | 古いプラグインや独自コードの警告を確認 |
| PHP 8.3 | 互換性上の理由で8.4以上へ上げられない既存サイト | 新規環境の第一候補にはしにくい |
| PHP 8.2以下 | 一時的な互換維持 | 長期運用では更新計画を作る |
僕なら「新規サイトだから8.5」「既存だから8.4」と機械的には決めません。まずレンタルサーバーの対応、次にテーマ・主要プラグインの互換性、最後に本番と同じ条件でのテストを見ます。WordPress本体が対応済みでも、サイト全体を構成する部品が同時に対応しているとは限らないからです。
2026年10月時点のPHPサポート状況
| PHP | WordPress 7.1 | PHP側の状態/目安 | TameshiTechの判断 |
|---|---|---|---|
| 8.5 | 互換 | Active Support〜2027-12-31 / Security Support〜2029-12-31 | テーマ/主要プラグインまで検証済みなら新規候補 |
| 8.4 | 互換 | Active Support〜2026-12-31 / Security Support〜2028-12-31 | 安定性と新しさのバランスを取りやすい |
| 8.3 | 互換 | Security Support〜2027-12-31 | 既存互換性の都合がある場合 |
| 8.2 | 互換 | Security Support〜2026-12-31 | 2026年末を見据えて移行計画を作る |
WordPressが「動く」ことと、PHP側が現在も安全にサポートされていることは別です。WordPress 7.1の新規インストールではHosting Teamが8.4.x/8.5.xを推奨しているため、古いPHPを積極的に選ぶ理由がなければ8.4/8.5を中心に検討します。
2026年10月2日時点のPHP 8.6はRC2で、PHP公式も「本番環境では使用しない」よう案内しています。この記事で8.4/8.5を比較するのは、8.6がまだ正式安定版ではないためです。
PHP 8.4と8.5を選ぶ判断フロー
まず「新規サイトか既存サイトか」で分けます。新規ならWordPress Hosting Teamの推奨範囲に合わせて8.4または8.5を候補にし、利用予定のテーマ・プラグインが両方で検証済みか確認します。既存なら現在のPHP、WordPress、テーマ、プラグインを一覧化し、8.4へ上げるのか8.5まで進むのかを一段ずつ決めます。
次に、壊れた時の影響を見ます。収益サイトや問い合わせフォームが重要なら、公開時間帯に直接変更せず、ステージングで「変更→QA→戻す」まで試します。個人の検証ブログなら低リスク時間帯に直接変更してもよい場合がありますが、それでもバックアップと旧PHPへ戻す手順は先に確認します。
PHP 8.5を選びやすい条件
- WordPress 6.9/7.0以降、できれば7.1へ更新済み
- 主要テーマ・プラグインの更新が継続している
- 独自PHPコードが少ない、またはテストできる
- ステージングでフォーム・Cron・画像処理まで確認できる
- ホスティング側が8.5を正式提供している
PHP 8.4を選びやすい条件
- 最新性より既存プラグインの検証量を重視したい
- 8.5でdeprecationや互換性警告が出た
- 複数サイトを順番に更新し、変更幅を抑えたい
- サーバー側の推奨初期値が8.4になっている
プラグイン互換性は何を見ればいい？
WordPress.orgの「Tested up to」はWordPress本体の目安で、PHPの全バージョン互換を保証する表示ではありません。プラグイン公式のrequirements、changelog、support forum、GitHubのissueがあれば確認します。決済・会員・バックアップ・SMTPなど業務停止につながるプラグインほど優先度を上げます。
また、プラグインが「動く」だけでなく、PHPログに大量のwarning/deprecatedが出ていないかも確認します。画面上は正常でもログが急増すると、将来のPHP更新でfatalへ変わる前兆になり得ます。
PHPを更新する前に確認する7項目
- WordPress本体をバックアップする
- データベースも同じ復元点で戻せるようにする
- テーマと子テーマを更新する
- 主要プラグインの更新履歴・動作条件を確認する
- ステージング環境でPHPだけ変更する
- フォーム送信・画像アップロード・予約投稿・管理画面を確認する
- 問題が出た時に旧PHPへ戻す手順を先に把握する
トップページだけ開いて終わりにすると、管理画面の一括処理、Contact Form 7、バックアップ、画像変換などでだけエラーが出ることがあります。普段使う業務フローをチェックリスト化してから更新します。
PHP更新で起きやすい不具合
画面が真っ白・500エラーになる
古いテーマやプラグインが、新しいPHPで廃止・変更された構文を使っている可能性があります。ここでメモリ上限だけを増やして直そうとすると原因を隠すことがあります。サーバーログやWordPressのデバッグログを見て、どのコードで止まっているかを確認します。
管理画面だけ遅い
フロントはページキャッシュで速く見えていても、管理画面はPHPとDBの影響を受けやすい領域です。PHP更新で速くなる可能性はありますが、autoload、Cron、外部API待ち、バックアップ処理も切り分けます。
フォーム・メールだけ失敗する
PHP更新と同時にSMTPライブラリやプラグインが更新されると、送信経路の問題が表面化することがあります。131〜133で整理したSMTP・SPF・DKIM・DMARCも併せて確認します。
PHP変更後に見るべきポイント
| 確認場所 | 合格条件 | 異常時の次の一手 |
|---|---|---|
| サイトヘルス | 致命的な警告なし | PHP・拡張・DBの警告を確認 |
| フロント表示 | 主要5〜10ページが正常 | テーマ/プラグインを切り分け |
| 管理画面 | 投稿保存・メディア操作が正常 | エラーログ確認 |
| フォーム | 送信→受信まで確認 | SMTPログと認証を確認 |
| Cron | 予約投稿・定期処理が動く | 143のCron診断へ |
本番切替を15分で確認する実務フロー
切替直後は、キャッシュを全消去してからトップ、カテゴリ、記事、検索、404、管理画面、メディア、フォームの順に確認します。続いてPHPエラーログ、WordPressサイトヘルス、予約投稿、バックアップを確認します。ここまで通れば「画面が開く」ではなく「運営が継続できる」状態に近づきます。
複数サイトを運営する場合、全サイトを同じ日に一斉切替しない方が安全です。まず影響の小さい1サイトで変更し、同じテーマやプラグイン構成で問題がないことを確認してから次へ広げます。障害が起きた時に原因を1サイトへ閉じ込められるためです。
複数サイトを運営する場合の更新順
複数WordPressを同時に運営している場合、最も重要なサイトから更新するのではなく、構成が似ていて影響の小さいサイトから始めます。成功した組み合わせを「WordPress版・PHP版・テーマ版・主要プラグイン版」として台帳化し、そのセットを他サイトへ横展開します。
サイトごとに異なるプラグインがある場合、その差分だけ追加QAします。これにより10サイトすべてをゼロから確認するより、共通部分と差分に分けて短時間で安全に更新できます。
PHPを新しくしても速くならない場合
PHP更新は万能ではありません。遅さの原因が画像、JavaScript、外部広告、DB肥大化、Cron、オブジェクトキャッシュ不足、サーバーCPUの混雑なら、PHPだけ変えても体感差が小さいことがあります。速度改善は「何が遅いか」を測ってから手段を選ぶ方が再現性があります。
既存のWordPressが重い原因と改善手順で全体を切り分け、メモリ不足なら142のmemory_limit、DBなら144のDB最適化、Redisなら145のObject Cache、サーバー自体なら149の性能判断へ進むと重複せず判断できます。PHP変更前のテスト環境は148のステージング環境で整理しています。
PHP更新を後回しにし続けるリスク
古いPHPはWordPress本体が動く期間が残っていても、PHP側のセキュリティサポートが終了していることがあります。さらに新しいプラグインが古いPHPを切り捨てると、更新できない連鎖が起きます。緊急時に一気に複数世代を上げるより、年1〜2回でも互換性確認をして段階的に更新する方が運用負担は小さくなります。
PHP対応を理由にサーバーを変えるべきケース
現在のサーバーでPHP 8.4/8.5へ安全に切り替えられない、ステージングがない、バックアップ復元が弱い、管理画面も慢性的に遅い――このように複数の制約が重なった時は、設定を継ぎ足すよりサーバーを比較する価値があります。反対にPHP切替だけで解決できるなら移転は不要です。
WordPressの土台から見直す場合
PHP 8.4/8.5へ上げられない、ステージングや復元機能も弱いなど、PHP以外の制約まで重なる場合だけサーバー比較へ進みます。PHP切替だけで解決できる環境なら移転は不要です。
ロリポップ！の最新条件を見る
／ エックスサーバーの最新条件を見る
／ ConoHa WINGの最新条件を見る
／ シンレンタルサーバーの最新条件を見る
公式情報・参考資料
- WordPress 7.1 Server Compatibility
- PHP Compatibility and WordPress Versions
- WordPress Hosting Handbook: Server Environment
- PHP: Supported Versions
- PHP: Pre-Release Builds
まとめ
2026年のWordPress 7.1ではPHP 8.4/8.5が現実的な選択肢です。ただし更新の価値は「新しい数字にすること」ではなく、安全性・保守性・性能を上げながら既存機能を壊さないことにあります。バックアップ→ステージング→実業務QA→本番変更→切り戻し確認までを1セットにしてください。
コメント