PHPの次のバージョン「PHP 8.6」の開発が最終段階に入っています。2026年9月10日にBeta 3が公開され、9月24日にはRC1(リリース候補版)が予定されています。レンタルサーバーの管理画面に「PHP 8.6」が並ぶのはもう少し先ですが、「うちのWordPressは8.6にしても大丈夫か」「今のうちに何を確認しておくべきか」という相談は、正式版が出る前から増え始めます。
結論から言うと、PHP 8.6は2026年11月19日に正式版が公開される予定で、現時点(RC前)では本番サイトで使う段階ではありません。ただし、WordPress 7.1の本体はPHP 8.6のBeta版で問題なく動作することを当社で確認しており、正式版が出た後に問題になるのは本体ではなく、古いプラグインやテーマになる見込みです。この記事では、スケジュール、WordPressに影響する変更点、当社での実測、確認手順、レンタルサーバーで使えるようになる時期の目安を整理します。
この記事は2026年9月18日時点の情報です。9月24日予定のRC1公開、11月19日予定の正式版公開、WordPress公式の互換性表の更新、主要レンタルサーバーの提供開始のタイミングで更新します。
PHP 8.6はいつ公開される?スケジュールと現在の位置
PHP公式のリリース予定表(wiki.php.net)によると、PHP 8.6は次のスケジュールで進んでいます。Beta 3までは公開済みで、次がRC1です。
| 日付(2026年) | リリース | 状態 |
|---|---|---|
| 7月2日・16日・30日 | Alpha 1〜3 | 公開済み |
| 8月13日 | Beta 1(新機能の締め切り) | 公開済み |
| 8月27日 | Beta 2 | 公開済み |
| 9月10日 | Beta 3 | 公開済み |
| 9月22日 | 機能の最終凍結 | 予定 |
| 9月24日 | RC 1(リリース候補版) | 予定 |
| 10月8日・22日、11月5日 | RC 2〜4 | 予定 |
| 11月19日 | 正式版(GA) | 予定 |
Beta版の告知文には毎回「Please DO NOT use this version in production, it is an early test version.(本番環境では使わないでください。初期のテスト版です)」と明記されています。RC版も同じ扱いです。つまり11月19日より前に本番サイトのPHPを8.6にする理由はありません。この時期にやるべきなのは「切り替え」ではなく「確認」です。
なお、現在の安定版はPHP 8.5系(2026年8月27日公開の8.5.10が最新)で、WordPress公式もPHP 8.3以上を推奨しています。8.6を待たずに、8.2以下で運用しているサイトは先に8.3か8.4へ上げておくほうが、セキュリティと速度の両面で得です。
PHP 8.6で何が変わる?WordPressサイトに影響しそうな変更点
PHP 8.6は8.5と同じく「メジャーな作り直し」ではなく、非推奨の追加と細かな挙動変更が中心です。公式のUPGRADINGファイル(Beta 3時点)から、WordPressのプラグインやテーマのコードに影響しそうなものを抜き出しました。
| 変更内容 | 種類 | WordPressサイトへの影響 |
|---|---|---|
| is_a() / is_subclass_of() に文字列を渡す(allow_stringがfalse) | 非推奨 | 古いプラグインでよく見る書き方。警告が出る。後述のとおりWooCommerceでも1件確認 |
| is_integer() / is_long() / is_double() / doubleval() | 非推奨 | is_int() / is_float() / floatval() の別名。古いコードに残っていることがある |
| define() の第3引数(大文字小文字を区別しない定数) | 非推奨 | 7.3以降ずっと非推奨だったが警告の対象に。古いテーマの functions.php に稀にある |
| finally ブロック内の return | 非推奨 | まれ。独自開発のコードで注意 |
| spl_object_hash() | 非推奨 | WordPress本体は7.1で spl_object_id() に移行済み。プラグインが独自に使っていれば警告 |
| trim() / ltrim() / rtrim() の既定の削除文字に改ページ(\f)が追加 | 挙動変更 | 通常の文字列処理では影響なし。特殊な制御文字を扱う処理は要確認 |
| preg_grep() が実行エラー時に false を返す | 挙動変更 | 戻り値を配列前提で扱っているコードは要確認 |
| mysqli_get_charset() / 引数なしの mysqli_stmt_init() | 非推奨 | WordPress本体の wpdb は影響を受けない。独自にmysqliを触るプラグインは要確認 |
| mb_ereg 系(mbregex) | 非推奨 | 日本語処理の古いライブラリで使われていることがある。preg_ 系への置き換えが必要になる |
| metaphone() / strcoll() / SORT_LOCALE_STRING | 非推奨 | まれ |
| セッションの初期値変更(use_strict_mode=1、cookie_httponly=1、samesite=Lax) | 挙動変更 | WordPress本体はPHPセッションを使わない。独自にセッションを使うプラグインは動作確認 |
| ファイル関数(file_exists等)にNULバイトを含むパスを渡すと例外 | 挙動変更 | 通常は影響なし。セキュリティ上はむしろ改善 |
新機能としては、値を範囲内に収める clamp() 関数、readonly プロパティへの初期値設定、日付計算用の Time\Duration クラスなどが追加されます。これらは「使えるようになる」ものなので、既存サイトが壊れる方向の変更ではありません。
表を見て分かるとおり、8.6で「動かなくなる」変更はほとんどなく、大半は「警告が出るようになる」変更です。ただし警告は放置すると次のメジャーバージョンでエラーに変わりますし、WP_DEBUG が有効なサイトでは画面に表示されてしまいます。
WordPress本体はPHP 8.6に対応している?公式の互換性表の読み方
WordPress公式の「PHP Compatibility and WordPress Versions」の表は2026年8月19日に更新され、WordPress 7.0と7.1はPHP 8.2〜8.5で「Y(対応)」になっています。PHP 8.6の列はまだありません。これは未対応という意味ではなく、正式版が出ていないためです。
この表の運用は2026年5月に変わりました。以前は新しいPHPに「ベータサポート」というラベルを付けていましたが、ホスティング会社やプラグイン開発者が新しいPHPへの移行をためらう原因になっていたとして廃止されました。現在は、そのPHPバージョンの利用率が全体の10%を超えた時点を目安に表へ載せる方針です。
過去の実績も参考になります。PHP 8.5(2025年11月20日公開)に対しては、WordPress 6.9のRC2の段階で報告された問題がすべて修正され、正式版公開前に対応が済んでいました。8.5で必要だった修正は「前回より少数」だったと公式が書いています。WordPress本体は、PHPの正式版が出る前に対応を終える体制ができていると考えてよいでしょう。
実際にWordPress 7.1をPHP 8.6で動かしてみた
公式の表を待つだけでは心もとないので、当社でBeta版のPHP 8.6を使って実際に動かしました。環境は、Homebrewで導入したPHP 8.6.0-dev(2026年9月16日ビルド)と、ローカルのWordPress 7.1(テーマはTwenty Twenty-Five、有効プラグインはWooCommerce 11.1.0とMCP Adapter 0.6.1)です。すべての警告を拾うため、error_reporting は E_ALL にしています。
構文チェック:本体1,301ファイルでエラーなし
まず wp-admin と wp-includes 配下の全PHPファイル(1,301ファイル)を PHP 8.6 の php -l で構文チェックしました。構文エラーは0件です。コンパイル時の非推奨警告は2種類だけ出ましたが、どちらも実際には読み込まれないファイルでした。
- wp-includes/php-compat/readonly.php の「readonly という名前の関数」の警告。このファイルはPHP 8.1未満でしか読み込まれない互換用で、8.6では実行されません
- wp-includes/sodium_compat 配下のCore32ディレクトリの警告。32bit環境専用のコードで、64bitサーバーでは使われません
フロント・REST API:警告0件
次にWordPressを実際に起動し、フロントページ、単一記事、検索結果、REST API(wp/v2/posts)を実行しました。WordPress本体からの非推奨警告・警告は0件で、HTMLは正常に生成されました。
管理画面:本体は警告0件、WooCommerceで1件
管理画面も、ダッシュボード、投稿一覧、新規投稿(ブロックエディター)、プラグイン一覧、一般設定、テーマ、メディア、WooCommerceの商品一覧を実行しました。すべて正常に描画され、WordPress本体からの警告は0件でした。
一方、WooCommerce 11.1.0では、8.6で新たに非推奨になった「is_a() に文字列を渡す」呼び出しが1か所(日付を扱う内部処理)で警告になりました。動作自体は正常で、表示にも影響はありませんが、WooCommerce側の修正が入るまでは、WP_DEBUG を有効にした環境でこの警告が出ます。これは「WooCommerceが壊れる」話ではなく、「有名プラグインでも8.6向けの微修正は必要」という実例です。
| 確認項目 | 結果(PHP 8.6.0-dev、WordPress 7.1) |
|---|---|
| 本体1,301ファイルの構文チェック | エラー0。非推奨警告は未使用ファイルのみ |
| フロントページ・単一記事・検索 | 正常表示。警告0 |
| REST API | 正常応答。警告0 |
| 管理画面8ページ(ブロックエディター含む) | 正常表示。本体の警告0 |
| WooCommerce 11.1.0 | 正常動作。is_a() の非推奨警告が1か所 |
| MCP Adapter 0.6.1 | 読み込み時の警告0 |
正式版が出たら同じ手順でもう一度確認し、この表を更新します。Beta版での結果なので、RC以降で挙動が変わる可能性は残ります。

ここまでのまとめ:本体より「古いプラグイン」を疑う
PHP 8.6は11月19日公開予定で、それまでは本番で使う段階ではありません。WordPress本体はBeta版の時点で問題なく動き、公式も正式版前に対応を終える体制です。正式版後に問題になるのは、更新が止まっているプラグインやテーマ、そして自作コードです。ここから先は、それをどう確認するかという実務の話です。
プラグイン・テーマがPHP 8.6に対応しているか確認する方法
「有名なプラグインなら大丈夫」とは限りません。当社に寄せられたトラブル相談の中に、PHPのバージョンを上げた直後にAll in One SEO Packの設定を保存したときやページを表示したときに致命的なエラー(Fatal error)が出て、画面が真っ白や500エラーになったというものがありました。原因はプラグイン側が新しいPHPに追いついていなかったことで、プラグインの更新(または一時的な無効化とPHPの戻し)で復旧しています。SEO系のプラグインは全ページの描画に関わるため、非対応だとサイト全体が止まります。利用者の多いプラグインほど早く対応版が出る傾向はありますが、「自分のサイトで使っているバージョンが対応しているか」は別の話です。
確認の順番は次のとおりです。上から順にやれば、切り替え当日に慌てることはほぼなくなります。
- 1年以上更新されていないプラグインを洗い出す。プラグイン一覧の「最終更新」を見て、古いものは代替を検討するか、開発元の対応予定を確認する
- プラグイン配布ページの「PHPバージョン」欄を見る。WordPress.orgの各プラグインページには「必要PHPバージョン」と「検証済みWordPressバージョン」が載っている。ただし「8.6で検証済み」と書かれるのは正式版の後なので、今の時点で空欄でも慌てない
- 互換性チェック系のプラグインは参考程度に。PHP Compatibility Checker のようなツールは静的に構文を調べるだけで、実行時にしか出ない警告や、動的に呼ばれる関数は検出できない。「問題なし」と出ても保証にはならない
- ステージング環境で実際に切り替えて動かす。これが唯一確実な方法。レンタルサーバーで8.6が選べるようになったら、本番のコピーで切り替え、WP_DEBUG_LOG を有効にして管理画面と公開側を一通り操作し、ログを見る
- 戻せる状態を作ってから本番を切り替える。PHPバージョンの切り替えはサーバーパネルから数秒で戻せるが、切り替え直後にキャッシュを消し、表示確認を済ませるまでは目を離さない
ステージングの作り方や更新前のバックアップは、安全なWordPressアップデート手順とWordPressのバックアップガイドにまとめています。
レンタルサーバーでPHP 8.6が使えるのはいつ?過去の実績から見た目安
PHPの正式版が出ても、レンタルサーバーの管理画面で選べるようになるまでには時差があります。前回のPHP 8.5(2025年11月20日公開)の実績を見ると、会社によってかなり差がありました。
| レンタルサーバー | PHP 8.5の提供開始 | 正式版からの日数 |
|---|---|---|
| エックスサーバー | 2026年1月29日 | 約2か月 |
| ロリポップ | 2026年5月27日 | 約6か月 |
| さくらのレンタルサーバ・ConoHa WING | 執筆時点で公式の8.5提供開始日を確認できず | — |
この実績をそのまま当てはめると、PHP 8.6がレンタルサーバーで選べるようになるのは、早い会社で2027年1月〜2月、遅い会社では2027年春以降と見込むのが妥当です。各社とも提供開始のお知らせで「自動では切り替わらない」「切り替え後に動作確認を」と案内しているので、勝手に8.6になる心配はありません。逆に言えば、自分で切り替えない限り恩恵もありません。
当社の保守先では、PHPは8.2または8.3で運用し、新しいバージョンはWordPress本体と同じく公開後しばらく様子を見てから、ステージングで確認したうえで切り替える方針にしています。急いで最新にするより、主要プラグインの対応版が出揃ってからのほうが、切り替え作業は確実に短く済みます。
技術者向け:8.6で自作コードを点検するポイント
ここからはテーマやプラグインを自作している方向けです。8.6の変更点のうち、実際のWordPressコードで引っかかりやすいものを挙げます。
最も遭遇しやすいのが is_a() の書き方です。クラス名の文字列を第1引数に渡す古い書き方は、第3引数に true を付けるか、instanceof に書き換えます。
|
1 2 3 4 5 6 7 8 9 |
// 8.6で非推奨になる書き方(第1引数が文字列) if ( is_a( $class_name, 'WP_Post' ) ) { } // 対処1: allow_string を明示する if ( is_a( $class_name, 'WP_Post', true ) ) { } // 対処2: オブジェクトなら instanceof を使う if ( $object instanceof WP_Post ) { } |
フックのコールバック識別に spl_object_hash() を使っているプラグインも要注意です。WordPress本体は7.1で spl_object_id() に切り替えました(この変更が一部プラグインの致命的エラーを招いた経緯はWordPress 7.1の不具合まとめに書いています)。8.6では spl_object_hash() 自体が非推奨なので、独自にフックの登録状況を走査しているコードは spl_object_id() へ移行します。
検出の手順としては、次の3段階が現実的です。
- ステージングで WP_DEBUG と WP_DEBUG_LOG を有効にし、管理画面と公開側を一通り操作して debug.log を確認する。実行時にしか出ない警告はこれでしか拾えない
- PHPCompatibility(PHP_CodeSniffer のルールセット)で testVersion を 8.6 にして静的解析する。8.6向けルールの整備状況は正式版前後で変わるため、結果は目安として扱う
- PHPStan を使っているなら、PHP 8.6 のバイナリで実行して型関連の警告を確認する
今回の当社の検証も、この手順の1つ目を PHP 8.6 のCLIで再現したものです。Homebrewのshivammathur/phpタップには8.6が既に用意されているので、Macのローカル環境なら既定のPHPを変えずに8.6を並行導入して同じ確認ができます。
まとめ:PHP 8.6は「今すぐ切り替え」ではなく「今から確認」
PHP 8.6は2026年11月19日に正式版が公開される予定で、RC1は9月24日です。それまでは本番サイトで使う段階ではありません。WordPress 7.1の本体はBeta版のPHP 8.6で構文エラー・実行時警告ともに0件で動作し、公式も正式版前に対応を終える体制です。問題になるのは古いプラグイン・テーマと自作コードで、WooCommerceのような主要プラグインでも8.6向けの微修正は必要になります。レンタルサーバーで選べるようになるのは、前回の実績から見て早くて2027年1月〜2月です。今やるべきことは、更新の止まったプラグインの洗い出しと、ステージングで確認できる体制づくりです。
WordPress 7.2も12月に公開予定で、こちらはWordPress 7.2の新機能と変更点にまとめています。年末はPHPとWordPressの両方が新しくなるので、切り替えの順番を決めておくと安心です。
更新履歴
- 2026年9月18日:初版公開(PHP 8.6 Beta 3時点。WordPress 7.1での実測を掲載)
PHPの切り替えで止まってしまったら
「PHPを上げたら管理画面が真っ白になった」「戻したのに表示が崩れたまま」という状態は、原因の切り分けさえできれば短時間で復旧できます。WordPressトラブル対応サービスでは、他社制作のサイトでもログの確認から復旧までお引き受けします。PHPとWordPressの更新を毎回自分で判断するのが負担なら、ステージングでの事前確認と更新代行を含む保守サポートサービスもご検討ください。「うちのプラグインは8.6で大丈夫か」の段階でも、無料相談からお気軽にどうぞ。