Article
PHP8.4から8.5に上げるときの注意点と変更チェック項目
PHP8.4から8.5へ上げる際に、実務で確認しておきたい非互換やdeprecationの見どころを整理する。
実務で先に確認したいポイント
運用プロジェクトにおいて、php8.4から8.5のアップグレードをいくつか行ったので、その際遭遇した注意点をまとめていきます。 今回の変更には、公式ドキュメントにも書いてある通り破壊変更はないため、こまごまとした注意点になります。 新しく8.5になってから使用できるようになったパイプ演算子のような新機能は色々なところで既に書かれているので、それらには触れず、既存プロジェクトのPHPをアップグレードする際の注意点のみを記載しています。
1. 古い書き方が deprecation になっていないか
今回まず気にしたいのは、古いけれど動いていた書き方です。
特に確認が必要なケースは次のあたりです。
- バッククォート演算子を使ってシェル実行している箇所
(boolean)や(integer)のような非標準寄りのキャスト表記caseの末尾を:ではなく;にしているswitchnullを配列オフセットとして使っている箇所- 非数値文字列に
++している箇所
上記については、将来の更新コストを上げやすいので、8.5 に上げるタイミングで一緒に掃除しておいた方が楽です。
特に ++$str で "A" や "ZZ" を進めるようなコードや (boolean) によるキャスト表記は、5~10年位前に作成された案件で実際にあったのを確認したため注意が必要です。
2. warning に変わる挙動を甘く見ない
8.5では、今まで問題なかったものがwarningになるケースがあります。
これが厄介なのは、処理自体は継続しても、ログ監視や例外化方針によっては本番運用に影響することです。
見ておきたいのは主にこのあたり。
- float や float っぽい文字列を
intにキャストする箇所 NANを別型へキャストする箇所- 配列でない値を
list()や[]で分割代入している箇所
特に (int) $value をとりあえず当てている箇所が多いプロジェクトでは、一度検索して使用しているか確認しておく方が安全です。もし該当する箇所があればこの機会に直すのが良いかと思います。
3. disable_classes 依存がないか
PHP8.5では disable_classes が削除されています。
この設定を積極的に使っているケースは多くないと思いますが、要確認です。
アプリコードそのものより、以下のような場所にないか確認が必要です。
php.ini- Docker イメージ内の独自 ini
- ECS / Fargate / VM の起動設定
- 古い Ansible / Chef / shell script
4. PDO を使っているなら fetch 周りを確認する
PDO は 8.5 で微妙に挙動差が出る箇所があります。
業務アプリでは、ORMを使っていても周辺ツールや特殊クエリだけ生PDOを叩いていることがあるので注意が必要です。
特に見ておきたいのは主にこのあたり。
PDO::FETCH_CLASSを使っている箇所- コンストラクタ引数を伴う fetch
- fetch 中に特殊なモード変更をしている箇所
また、PDO 自体にも deprecation が追加されています。
uri:DSN スキームは deprecated- PDO クラス上のドライバ固有定数は deprecated
- PDO クラス上のドライバ固有メソッドは deprecated
特に uri: DSN スキームについては、リモート URI に起因する DSN のセキュリティ懸念が理由とされているため、古い接続コードや設定値を使い回している案件では一度確認しておいた方が安全です。
また、PDO クラスに生えていたドライバ固有の定数・メソッドも、各ドライバ専用クラスへ寄せる形に変わっています。
普段の業務でよく遭遇しやすそうなものを挙げると、例えば次のようなものです。
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY=>Pdo\Mysql::ATTR_USE_BUFFERED_QUERYPDO::MYSQL_ATTR_LOCAL_INFILE=>Pdo\Mysql::ATTR_LOCAL_INFILEPDO::MYSQL_ATTR_INIT_COMMAND=>Pdo\Mysql::ATTR_INIT_COMMANDPDO::MYSQL_ATTR_SSL_CA=>Pdo\Mysql::ATTR_SSL_CAPDO::PGSQL_ATTR_DISABLE_PREPARES=>Pdo\Pgsql::ATTR_DISABLE_PREPARESPDO::SQLITE_ATTR_EXTENDED_RESULT_CODES=>Pdo\Sqlite::ATTR_EXTENDED_RESULT_CODESPDO::pgsqlCopyFromFile()=>Pdo\Pgsql::copyFromFile()PDO::pgsqlGetNotify()=>Pdo\Pgsql::getNotify()PDO::sqliteCreateFunction()=>Pdo\Sqlite::createFunction()
MySQL / PostgreSQL / SQLite を直接触っているユーティリティコードや、古いサンプル実装をベースにした社内基盤ではこの手の書き方が残っていることがあります。
そのため、使用しているものに合わせて、以下についてgrep等で確認しやすいです。
PDO::MYSQL_ATTR_PDO::PGSQL_PDO::SQLITE_PDO::pgsqlPDO::sqlite
5. trait / attribute 周りを確認する
PHP8.5はtraitの束縛順やattributeの検証タイミングに関する変更があります。
たとえば次のようなコードであれば注意が必要です。
- attributeをDIやルーティングに多用している
- traitをかなり複雑に重ねている
- reflectionを使う独自フレームワーク・社内基盤がある
6. Composer依存関係の注意
PHP本体の差分より、Composer制約で止まる場合にも注意が必要です。
たとえば次の順で詰まりやすいです。
- フレームワーク本体が8.5対応前
- テストライブラリが未対応
- 静的解析ツールが未対応
- 開発用ツールだけが8.5を許可していない
なので、コードを直す前に、以下も併せて確認した方がよいです。
composer.jsonのPHP制約composer.lockに入っている主要パッケージのPHP対応状況- CIで使うPHPバージョン
- Dockerfileのベースイメージ
コード修正は問題なくても、CIや開発環境が8.4のままだと確認漏れが増えます。
まとめ
次の4点は先に見ておくと進めやすいです。
- 古い書き方のdeprecation
- 型変換や分割代入まわりのwarning
disable_classesなどの環境設定差分- PDO / trait / attributeなど、少し挙動差が出やすい箇所
「コード」だけでなく、「CI・Docker・php.ini・ログ監視」まで含めて確認しておくのが必要です。
公式ドキュメント
前後の記事
関連記事
Laravel12から13へ上げるときの注意点と確認項目
2026年3月17日にリリースされたLaravel13へ、Laravel12から上げる際に先に見ておきたいポイントを実務寄りに整理する。
Laravelでtruncateを使用する場合の注意点
Laravelでtruncateを使用する場合の注意点を実務の失敗例を踏まえて残しておく。
Laravelで作成したWebアプリをRust(Axum)に置き換えたときのログイン実装はどう考えるべきか
Laravelで作成したWebアプリをRust(Axum)に置き換えたときのログイン実装を、Laravel Sanctumとaxum-loginの違いを踏まえて整理する。
