PHP 8.6.0のRC3は試験用で、本番では使えない。UPGRADINGの非互換と非推奨は、自社のコードと設定で確かめられる ── 試験環境で確認する13項目（2026年10月時点）

目次

1. 01 何が起きたか — PHP 8.6.0のRC3が試験用に公開された。本番では使わず、変更点の一覧を、自社のコードと設定で確かめる段階である
   1. php.netが、RC3の公開を告げた
   2. 変更点の正本は、UPGRADINGという文書である
   3. RC3の文書と、開発中の最新の文書は、すでに少し違う
   4. 予定表では、正式版は11月19日になっている
2. 02 なぜ・背景 — 「次の版」の確認は、版を上げる前の宿題である
   1. 公式の移行ガイドも、本番の前に試すよう書いている
   2. 変更点は、3種類に分けて読む
   3. 非推奨の警告は、先の版での削除の予告である
3. 03 この記事で出てくる用語
   1. UPGRADING
   2. 非互換な変更
   3. 非推奨とE_DEPRECATED
   4. ValueErrorとTypeError
   5. セッションのCookie
   6. 試験環境
4. 04 型別 — 適用範囲・この記事が確かめていないこと・手順
   1. 適用範囲 — この確認が向いているサイト
   2. この記事が確かめていないこと
   3. 手順の流れは、4つに分かれる
   4. 使っている拡張は、2つの方法で書き出せる
   5. 調べる範囲は、自社で書いたコードに絞る
5. 05 明日、自社サイトで確認できることチェックリスト
   1. まず13項目を通して見る
   2. 観点別の内訳と、かかる時間
   3. 5分で終わらない項目があったとき
6. 06 代替・他の選択肢（表で）
   1. PHPの版を、どうするかの4つの選び方
   2. php.netの対応版の表を、日付で並べる
   3. 非推奨の関数は、書き換え先が示されている
   4. セッションのCookieの既定値が、3つ変わる
   5. 他にも、新しく例外を出すようになった項目が多い
7. 07 当サイトで内訳を確かめてみた例
   1. 数えた範囲と方法
   2. 関数の名前で探せる19種類を検索した
   3. 見つかった2種類の中身
   4. セッションのCookieを、JavaScriptから読んでいるか
   5. この例の限界
8. 08 このテーマの、これまで
   1. PHPの版と、サーバーの更新の過去の記事
   2. 警告の数え方と、見た目と実際を分ける考え方
9. 09 この記事のまとめ

01 何が起きたか — PHP 8.6.0のRC3が試験用に公開された。本番では使わず、変更点の一覧を、自社のコードと設定で確かめる段階である

php.netが、RC3の公開を告げた

PHPの公式サイトphp.netのお知らせに、「PHP 8.6.0 RC3 available for testing（訳: PHP 8.6.0 RC3を、試験用に公開した）」という記事がある。日付は2026年10月8日である。記事には、次の一文がある。

"Please DO NOT use this version in production, it is an early test version."

（訳: この版を、本番では絶対に使わないでください。早い段階の試験版です。）

記事は、あわせて、次のRC4の予定も書いている。

"The next release will be RC4, planned for 22 October 2026."

（訳: 次の版はRC4で、2026年10月22日の予定です。）

つまり、この版は、公式が「本番で使うな」と明記した試験版である。サイトの管理者がやるのは、本番の版を上げることではない。変更点を読んで、自社のコードと設定に当てはまるものを、試験用の環境で確かめることである。

変更点の正本は、UPGRADINGという文書である

記事には、変更点をどこで読むかも書かれている。

"For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes."

（訳: 新機能やその他の変更についてのくわしい情報は、NEWSファイル、または、版を上げるときの注意の完全な一覧であるUPGRADINGファイルで読めます。）

PHPのソースコードを置いているGitHubの、RC3のタグ（php-8.6.0RC3）にあるUPGRADINGを、2026年10月13日に開いた。冒頭に14の章の見出しが並び、1章が「Backward Incompatible Changes（訳: 後ろ向きに互換でない変更）」、4章が「Deprecated Functionality（訳: 非推奨の機能）」である。8章の「Removed Extensions and SAPIs（訳: 削除された拡張とSAPI）」には、RC3の時点で、項目が書かれていなかった。

RC3の文書と、開発中の最新の文書は、すでに少し違う

同じ10月13日に、開発中のブランチ（PHP-8.6）のUPGRADINGと、RC3のタグの文書を比べた。違いは、1章にURL関連の拡張の項目が1つ多い、という1か所だった。RC3の公開後にも、文書は書き足されている。読むときは、どの時点の文書かを、書き留めておく。

予定表では、正式版は11月19日になっている

リリースの予定は、PHPのwikiの「PHP 8.6 Preparation Tasks（訳: PHP 8.6の準備作業）」に載っている。先頭には、次の注意がある。

"Based upon a target GA in late November. Individual releases may be added or removed to accommodate development progress."

（訳: 11月下旬のGA（一般提供）を目標にしている。個々のリリースは、開発の進み具合に合わせて、足したり、取りやめたりすることがある。）

表には、RC4が10月22日、RC5が11月5日、GAが11月19日と書かれている（2026年10月13日に開いた版）。ただし、注意書きのとおり、予定は変わりうる。この記事は、日付を予定として読み、確定した日付とは扱わない。

02 なぜ・背景 — 「次の版」の確認は、版を上げる前の宿題である

公式の移行ガイドも、本番の前に試すよう書いている

PHPのマニュアルの「Migrating from PHP 8.4.x to PHP 8.5.x（訳: PHP 8.4から8.5への移行）」は、冒頭で、次のように書いている。

"This new minor version brings with it a number of new features and a few incompatibilities that should be tested for before switching PHP versions in production environments."

（訳: この新しいマイナーバージョンは、いくつかの新機能と、少数の非互換をもたらします。非互換は、本番の環境でPHPの版を切り替える前に、試験しておくべきものです。）

8.6の移行ガイドは、2026年10月13日の時点で、このマニュアルの目次には載っていなかった。ただ、考え方は同じである。非互換は、版を上げる前に試験して見つける。RCの段階から読んでおくと、本番の版を上げる日に、確認する量が減る。

変更点は、3種類に分けて読む

UPGRADINGの項目は、3種類に分けると読みやすい。1つ目は、非互換な変更で、いまのコードの動きが変わるものである。2つ目は、非推奨で、いまは動くが、警告が出る。PHP 9での削除が提案されているものである。3つ目は、新機能で、足されるだけのものである。確認が要るのは、おもに1つ目と2つ目である。

非推奨の警告は、先の版での削除の予告である

PHPの警告の種類に、E_DEPRECATEDがある。PHPのマニュアルは、次のように書いている。

"Enable this to receive warnings about code that will not work in future versions."

（訳: これを有効にすると、将来の版では動かなくなるコードについての警告を受け取れます。）

8.6の非推奨をまとめたRFC（PHPの仕様の提案書）は、冒頭で、次のように書いている。

"The RFC proposes to deprecate the listed functionality in PHP 8.6 and remove it in PHP 9 (except where otherwise noted)."

（訳: このRFCは、挙げた機能を、PHP 8.6で非推奨にし、PHP 9で削除することを提案する（別に書いたものを除く）。）

RFCの状態は「Pending Implementation (for the accepted proposals)（訳: 採択された提案について、実装待ち）」と表示されていた。RFCは、提案を1つずつ採決にかけ、3分の2以上の賛成を求めている。つまり、このRFCは、8.6での非推奨と、PHP 9での削除を提案する機能の一覧であり、例外もある。実際に8.6で非推奨になるのは、採択されて実装された分で、UPGRADINGの4章に載る（4章には、別のRFCの項目も並ぶ）。8.6で動いても、PHP 9でも使えるとは限らない。

03 この記事で出てくる用語

UPGRADING

PHPのソースコードの置き場にある、版を上げるときの注意をまとめた文書である。拡張（機能のまとまり）ごとに、変更点が並ぶ。「1. Backward Incompatible Changes」「4. Deprecated Functionality」のように、番号つきの章に分かれている。

非互換な変更

これまでのコードの動きが変わる変更である。たとえば、エラーにならなかった呼び出しが、新たに例外（処理を止める知らせ）を出すようになる、といったものである。

非推奨とE_DEPRECATED

非推奨は、「いまは動くが、先の版で使えなくなる」機能である。使うと、E_DEPRECATEDという種類の警告が出る。警告をログに出す設定になっていれば、記録に残る。

ValueErrorとTypeError

PHP 8系で使われる、例外の種類である。ValueErrorは「値が受け付けられない」、TypeErrorは「型が合わない」ときに出る。UPGRADINGの1章には、以前は黙って受け付けていた値に、ValueErrorやTypeErrorを出すようにした項目が、多く並ぶ。

セッションのCookie

ログインした利用者を見分けるために、サーバーがブラウザに渡す小さなデータが、セッションのCookieである。HttpOnlyは、JavaScriptから読めなくする属性、SameSiteは、別のサイトからの通信に付けるかを決める属性である。

試験環境

本番とは別に用意した、動作を試すための環境である。この記事で「試験用の環境」と書くのは、本番の利用者に影響しない場所を指す。

04 型別 — 適用範囲・この記事が確かめていないこと・手順

適用範囲 — この確認が向いているサイト

PHPで動いているサイトが、すべて対象である。自社で書いたコードを持つサイトも、CMS（サイトの管理システム）とプラグインだけのサイトも含む。CMSだけのサイトでは、直す作業は提供元に任せることになる。それでも、「自社が何を使っているか」と「提供元が8.6への対応を出しているか」を確かめる作業は、同じように役に立つ。

この記事が確かめていないこと

確かめていないことは、4つある。1つ目は、RC3を実際に動かしたときの、動作の違いである。UPGRADINGを読んだだけで、8.6を入れて動かしてはいない。2つ目は、RC4以降の文書の変更である。3つ目は、WordPressなど個々のCMSやプラグインが、いつ8.6に対応するかである。4つ目は、8.6にしたときの表示の速さの変化である。

手順の流れは、4つに分かれる

手順は、4つに分かれる。文書を読むのは、UPGRADINGの1章と4章から、自社が使っている拡張の項目を拾う作業である。自社を調べるのは、使っている拡張の一覧を作り、コードと設定を検索する作業である。試験するのは、本番とは別の環境で、警告を数える作業である。決めるのは、「今すぐ試す」「別の版を先に上げる」「様子を見る」の1つを選ぶ作業である。

使っている拡張は、2つの方法で書き出せる

PHPの拡張の一覧は、コマンドラインでは「php -m」で出る。画面で見たいときは、phpinfo()を表示するページを、試験用の環境で一時的に作る方法もある。レンタルサーバーなどで、どちらも使えない場合は、ホスティング会社の管理画面の、PHPの設定のページで、読み込まれている拡張を見る。この記事は、サーバーごとの違いまでは確かめていない。

調べる範囲は、自社で書いたコードに絞る

CMSの本体や、外から入れた部品（ライブラリ）の中まで、1行ずつ調べる必要はない。そこは、提供元が8.6への対応を出すのを待つ。自社で書いたテーマやプラグイン、独自のプログラムだけを、関数の名前で検索する。検索で見つからなかった関数は、「自社のコードには無い」と書いてよい。ただし、検索で探せないもの（たとえば、finallyの中のreturn）は、別の方法で確かめる。

05 明日、自社サイトで確認できることチェックリスト

まず13項目を通して見る

以下は、明日、自社のコードと設定を開いて、PHP 8.6の変更点を確かめるための項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。1〜4番目が文書の確認、5〜7番目が自社のコードと部品の確認、8〜10番目がセッションのCookieの確認、11〜12番目が試験環境と警告の確認、13番目が判断である。

• php.netのお知らせ「PHP 8.6.0 RC3 available for testing」を開き、「DO NOT use this version in production」の一文を探して、「本番では使わない」と表の最上段に書く
• GitHubのUPGRADING（タグはphp-8.6.0RC3）を開き、14の章の見出しから、「1. Backward Incompatible Changes」と「4. Deprecated Functionality」の2つを選び、章ごとの拡張名を、あるだけ書き出す
• 自社のPHPで読み込まれている拡張を、「php -m」か、ホスティング会社の管理画面で確かめ、名前を全部書き出す
• 2番目と3番目の名前を突き合わせ、両方にある拡張に○を付けて、その数を書く
• ○を付けた拡張の項目だけを読み、自社のコードで使っていそうな関数や設定の名前を、10個まで書き出す
• 自社で書いたコードの置き場で、5番目に書いた関数の名前を検索し、見つかったファイルの数と、箇所の数を表に書く
• CMSやプラグインを使っているなら、プラグインの一覧の上から10個の名前と、それぞれの説明に書かれた、対応するPHPの版を書く（書かれていなければ「不明」と書く）
• session.use_strict_mode、session.cookie_httponly、session.cookie_samesiteの3つの、いまの設定値を、phpinfoか設定ファイルで探して書き写し、8.6の既定値と並べて書く
• 自社のJavaScriptで「document.cookie」を検索し、見つかったファイルの数を書き、セッションのCookieを読んでいる箇所があるかを、「ある」か「ない」で書く
• 別のドメインから戻ってくる通信（決済・ログインの連携・埋め込み）を、3つまで書き出し、それぞれがセッションのCookieを必要とするかを、○か×で書く
• 本番とは別に使える試験用の環境があるかを確かめ、あれば現在のPHPの版を書き、なければ「なし」と書く
• エラーログの設定を開き、E_DEPRECATEDを記録する設定かを書き、直近1日のログで「Deprecated」を含む行の数を数えて書く
• 「今すぐ試す」「別の版を先に上げる」「様子を見る」の1つを選んで、理由を1行と、見直す日（たとえばRC4の翌日の2026年10月23日）を、表の上に書く

観点別の内訳と、かかる時間

すべてに目を通す時間は、あわせて60分ほどである（筆者の見積もりで、コードの量や、管理画面に入る手間で変わる）。内訳は、1〜4番目が15分、5〜7番目が20分、8〜10番目が15分、11〜12番目が10分、13番目が数分である。CMSだけで自社のコードがないサイトは、1〜4番目と、7番目、13番目だけでも、「対応を待つ部品の一覧」が手元に残る。

5分で終わらない項目があったとき

6番目は、コードの量が多いと、5分では終わらない。そのときは、関数の名前を3つに絞って検索する。10個すべてを一度に調べる必要はない。7番目は、プラグインの数が多いサイトで時間がかかる。そのときは、サイトの主要な機能に使っている上位3個から調べる。

06 代替・他の選択肢（表で）

PHPの版を、どうするかの4つの選び方

PHP 8.6は、まだ試験の段階である。サイトの管理者が選べる道は、1つではない。4つに分けて、公式の文書に書かれていることと、先に確認することを並べた。公式が勧める順番ではなく、筆者の整理である。

この表から言えるのは、8.6は、年内に版を上げる先としては、まだ使えないということである。8.2を使っているサイトの確認は、当サイトの記事「PHP 8.2のセキュリティサポートは2026年12月31日で終わる ── 自社と担当サイトのPHPの版を確かめ、年内の移行先と試験日を決める13項目（2026年10月時点）」で扱った。この記事は、その次の、次の版を見据えた確認である。

php.netの対応版の表を、日付で並べる

php.netの「Supported Versions（訳: 対応している版）」を、2026年10月13日に開いた。ページの上部には「Today: 13 Oct 2026」と表示されていた。載っている4つの版の日付を、表に写した。

この表に、8.6の行はまだない。8.6の期限は、正式版が出たあとに、同じ表で確かめる。ここで写したのは、表に書かれた日付だけで、期限を延ばす・縮める判断は含まない。

非推奨の関数は、書き換え先が示されている

UPGRADINGの4章は、非推奨になった関数に、置き換え先を書いているものがある。たとえば、次の文である。

"The is_double() function is now deprecated. Use is_float() instead."

（訳: is_double()関数は、非推奨になった。代わりにis_float()を使う。）

"The spl_object_hash() function is now deprecated. Use spl_object_id() instead."

（訳: spl_object_hash()関数は、非推奨になった。代わりにspl_object_id()を使う。）

置き換え先が書かれたものを、表にまとめた。UPGRADINGの文のとおりに写している。

ほかに、書き換え先ではなく、使い方そのものを変える項目もある。たとえば、「Mbregex has been deprecated, because the underlying Oniguruma library is no longer maintained.（訳: Mbregexは非推奨になった。土台のOniguruma（正規表現のライブラリ）が、もう保守されていないためである。）」と書かれている。mbstringの正規表現の関数（mb_ereg系）を使っているコードは、確認の対象になる。

セッションのCookieの既定値が、3つ変わる

非互換な変更の中で、サイトの動きに影響しやすいのが、セッションの設定である。UPGRADINGの1章は、次のように書いている。

"The defaults of three session INI settings have changed to provide secure behavior out of the box:"

（訳: セッションの3つの設定（INI）の既定値は、最初から安全な動きになるように、変更された。）

3つは、session.use_strict_mode（0から1）、session.cookie_httponly（0から1）、session.cookie_samesite（未設定から「Lax」）である。このうち、JavaScriptとの関係を、UPGRADINGは次のように書いている。

"Session cookies are no longer accessible to JavaScript via document.cookie. Applications that read the session cookie from JavaScript must explicitly set this to 0."

（訳: セッションのCookieは、document.cookieを通じて、JavaScriptからは読めなくなる。セッションのCookieをJavaScriptから読むアプリは、これを明示的に0に設定しなければならない。）

別のサイトからの通信については、次のように書かれている。

"Applications that depend on session cookies being sent on cross-site POST submissions must explicitly set this to "None" (and also set session.cookie_secure to 1)."

（訳: 別のサイトからのPOSTの送信で、セッションのCookieが送られることに頼るアプリは、これを明示的に「None」にしなければならない（あわせて、session.cookie_secureも1にする）。）

決済サービスやログイン連携から、別のドメインを経由して戻ってくる作りのサイトは、この3つの変更の影響を受けうる。この変更は、RFCの状態が「Accepted（訳: 承認された）」と表示されていた。05章の8〜10番目は、そのための項目である。JavaScriptから読む必要がなければ、新しい既定値のままでよい。必要なら、設定で明示する。どちらにするかは、サイトごとの判断である。

他にも、新しく例外を出すようになった項目が多い

1章には、以前は黙って受け付けていた値に、例外を出すようにした項目が、多く並ぶ。たとえば、「preg_grep() now returns false instead of a partial array when a PCRE execution error occurs (e.g. malformed UTF-8 input with the /u modifier).（訳: preg_grep()は、正規表現の実行でエラーが出たとき、一部だけの配列ではなく、falseを返すようになった。たとえば、/uの指定のとき、壊れたUTF-8の入力で起きる。）」と書かれている。戻り値の型を前提にしているコードは、確かめる対象になる。

07 当サイトで内訳を確かめてみた例

数えた範囲と方法

当サイト（WEBサイトサポート）も、この記事の手順の6番目に当たる確認を、2026年10月13日に、試験用の環境で行った。範囲は、当サイト独自のPHPのファイル1,232本である。バックアップの名前が付いたファイルは、数えなかった。

関数の名前で探せる19種類を検索した

UPGRADINGの1章と4章から、関数や設定の名前で探せるものを19種類選び、検索した。非推奨のis_double・is_long・is_integer・doubleval・spl_object_hash・mysqli_get_charset・mysqli_stmt_init・metaphone・strcoll・SORT_LOCALE_STRING・array_walk、mb_ereg系の関数、セッション関連のsession_start・session_set_save_handler・iniの変更、preg_grep・array_intersect・http_build_query・trim系である。結果は、19種類のうち、見つかったのは2種類だけだった。

見つかった2種類の中身

1つ目は、http_build_queryで、2つのファイルに5か所あった。引数は、確かめた範囲では、どれも配列だった。UPGRADINGが非推奨にしたのは、オブジェクトを渡す使い方なので、この5か所は、該当しないと読める。2つ目は、trim・rtrim・ltrimで、87ファイルに360か所あった。UPGRADINGは、「Form feed (\f) is now added to the default trimmed characters of trim(), rtrim() and ltrim().（訳: 改ページ文字(\f)が、trim()・rtrim()・ltrim()の、既定で取り除く文字に加わった。）」と書いている。改ページ文字を含む値を扱う箇所があるかは、検索では判断できないので、確認は残っている。

セッションのCookieを、JavaScriptから読んでいるか

9番目の確認として、自社のJavaScript（圧縮済みのファイルを除く17本）で、document.cookieを検索した。見つかったファイルは0本で、セッションの識別子の名前を含むファイルも0本だった。自社のJavaScriptが、セッションのCookieを読んでいる箇所は、見つからなかった。

この例の限界

これは、名前で探せる19種類の検索であり、試験環境でRC3を動かした結果ではない。finallyの中のreturnや、let・isという名前の使用のように、検索では探しにくい項目は調べていない。外から入れた部品の中身も、調べていない。当サイトがPHP 8.6を試す日付は、この記事を公開した時点では、決めていない。試したら、結果を別の記事に書く。

08 このテーマの、これまで

PHPの版と、サーバーの更新の過去の記事

当サイトには、版の確認を別の角度から扱った記事がある。PHP 8.2のセキュリティサポートは2026年12月31日で終わる ── 自社と担当サイトのPHPの版を確かめ、年内の移行先と試験日を決める13項目（2026年10月時点）は、8.2の期限を軸に、自社と担当サイトのPHPの版と、移行先、試験日を決める記事で、この記事の前の段階にあたる。WordPress 7.2は12月8日に出る予定で、ベータは10月20日に始まる ── 日程の各日付に試験環境でやることを割り当てる13項目（2026年10月時点）は、WordPressの日程の各日付に、試験環境でやることを割り当てた記事である。WordPress 7.1.3の7件の修正は、それぞれ別の機能に当たる ── 自社のWordPressで使っている機能と突き合わせて確かめる13項目（2026年10月時点）は、WordPressの修正を、自社で使っている機能と突き合わせた記事である。WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点）は、担当サイトの版と自動更新、バックアップを一覧で確かめる記事である。

ブログでは、記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.69を、記事を公開したその日に上げるまでが、記事に書いた確認項目を自社のサーバーに当てて、更新した話である。

警告の数え方と、見た目と実際を分ける考え方

非推奨の警告のログを数えるときは、件数だけで判断しない方がよい。毎朝の「警告1,415件」を、初めて種類別に数えた ── 96.7%は見なくていいもので、唯一の「本物」は自分で叩くまで分からなかったは、毎朝の警告を種類別に数えて、大半が見なくてよいものだった話である。警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かったは、警告の中に本物が2件だけだった話である。外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけたは、外から取った画面が目当ての画面とは限らなかった話で、試験環境と本番を比べるときも、同じ注意が要る。記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかったは、記事に書いた確認項目を、公開した日に自分のサイトへ当てた話である。