LASSIC Media らしくメディア
PHP 8.1サポート終了、バージョン移行を外注で対応
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- PHP 8.1のセキュリティサポートは2025年12月31日に終了しており、以降に見つかった脆弱性への修正パッチは提供されません*1。
- PHP 8.2ではクラスの動的プロパティ生成が非推奨化されるなど、8.2・8.3への移行では複数の後方非互換の変更点が存在します*4。
- LaravelやWordPressといった主要フレームワークも対応PHPバージョンを更新しており、移行の判断には内製と外注の切り分けが検討材料になります*6。
目次
PHP 8.1サポート終了とは、セキュリティ更新が止まる状態を指す
PHP 8.1サポート終了とは、PHP公式が2025年12月31日をもってPHP 8.1系のセキュリティサポートを終える段階を指します*1。この時点での最終リリースは8.1.34で、以降に見つかった脆弱性には修正パッチが提供されません*1。稼働自体は止まりませんが、脆弱性対応の責任は利用者側に移ります。
PHPは新しいバージョンをおよそ1年ごとに公開し、各バージョンは公開から2年間のアクティブサポート、その後2年間のセキュリティサポートを経て終了する運用です*2。PHP 8.2は2024年12月31日にアクティブサポートを終え、2026年12月31日にセキュリティサポートも終了する予定です*2。
PHP 8.1はこの区分の外にあり、アクティブサポートに続くセキュリティサポートもすでに終了済みです*1。次に控えるPHP 8.2も、2026年7月現在ではセキュリティサポート終了まで残り5か月という段階に入っています*2。移行を先送りするほど、次の期限も同時に迫ってきます。
2025年12月31日、PHP 8.1がセキュリティサポートを終了
PHP公式のサポート方針では、各バージョンは公開後2年間のアクティブサポートで機能追加・不具合修正を受け、続く2年間のセキュリティサポートでは重大なセキュリティ問題のみ修正されます*2。PHP 8.1はこの合計4年間の提供期間をすでに終え、2025年12月31日に区分そのものが終了しました*1。
サポート終了後にPHP 8.1を稼働させ続けると、新たに発見された脆弱性についてPHP本体からの修正パッチは提供されません*1。公開Webアプリケーションやコーポレートサイトのように外部からアクセスできるシステムでは、脆弱性を突かれた場合の影響が広がりやすい点に注意が必要です。
OSやディストリビューションのパッケージ管理によっては、PHP 8.1のバイナリ自体が標準リポジトリから外れる場合もあります。サーバー側のOSサポート状況とあわせて確認することが、移行計画を立てる際の起点になります。
Dockerでコンテナイメージを運用している場合は、ベースイメージのタグがphp:8.1系のまま固定されていないかも見落としやすい点です。イメージ側のタグを更新し忘れると、アプリケーションのコードだけを直しても、実行環境は旧バージョンのまま残ってしまいます。
PHP 8.1から8.2/8.3への主な変更点——非推奨・非互換の要点
PHP公式は各バージョンの移行ガイドで、後方非互換の変更点と非推奨(deprecated。将来のバージョンで削除される可能性がある機能に警告を出す仕組み)機能を一覧にしています*3*4*5。8.1から8.2・8.3へ進むにつれ、複数の書き方が警告付きの非推奨扱いに変わります。
| バージョン | 主な変更点 | 実務での影響 |
|---|---|---|
| PHP 8.1 | 組み込み関数の非nullable引数にnullを渡す呼び出しを非推奨化*3 | 外部ライブラリを含め広い範囲で警告が発生し得ます |
| PHP 8.2 | クラスの動的プロパティ生成を非推奨化。属性#[AllowDynamicProperties]で許可可*4 | 未定義プロパティへの代入を多用するコードで警告が出やすくなります |
| PHP 8.3 | 空文字列・非数値文字列へのインクリメント演算子(++)適用などを非推奨化*5 | 影響範囲は限定的ですが、検証は必要です |
これらはE_DEPRECATEDという警告レベルの通知であり、直ちにエラーにはなりません。ただし将来のバージョンで削除される可能性があるため、移行の時点でコードを洗い出しておくことが望ましいでしょう。
PHP 8.1自体でも、Serializableインターフェースを__serialize／__unserializeを使わずに実装する古い書き方や、浮動小数点数から整数への暗黙的な非互換変換などが非推奨化されています*3。古いコードベースほど、こうした細かな非推奨箇所が複数積み重なっているケースが見られます。
監査から切替まで——PHP 8.1移行で踏む5つの段階
PHP 8.1からの移行では、いきなり本番環境を切り替えるのではなく、段階を踏んで進めるのが実務上一般的です。最初の段階は現状調査です。稼働中のシステムがどのPHP拡張・Composerパッケージに依存しているかを洗い出し、8.2以降での対応状況を確認します。
次の段階は検証環境の構築です。本番と同等の構成でPHP 8.2または8.3を動かし、前章の表に挙げた非推奨警告がどの程度発生するかを確認します*4。ここで警告のログを収集しておくと、次の修正作業の優先順位付けに役立ちます。
3つめの段階はコード修正です。動的プロパティへの依存や非nullable引数へのnull渡しなど、洗い出した非推奨箇所を1つずつ改修します*3*4。フレームワークやライブラリ側の対応バージョンが上がっている場合は、依存関係の更新も同時に進めます。
4つめの段階は段階移行です。修正済みのコードを一部の環境やステージング系に先行適用し、実際のトラフィックに近い条件で問題が起きないかを確かめます。ここで想定外の挙動が見つかれば、本番切替前に対処する時間を確保できます。
最後の段階が本番切替です。段階移行で問題が出なかったことを確認したうえで、全環境のPHPバージョンを8.2または8.3以降に統一します。切替後もエラーログとアクセス状況を一定期間監視し、想定していなかった非互換が残っていないかを見届けます。
移行で見落としやすい落とし穴——拡張モジュール・フレームワーク・テスト環境
移行そのものの手順は明確ですが、影響範囲の見極めが作業負荷を左右します。PECL拡張のように、8.2・8.3向けのビルドが提供されていない古い拡張モジュールに依存していると、そこで作業が止まってしまう場合があります。
フレームワークを使っている場合は、対応PHPバージョンの確認が欠かせません。Laravelの公式リリースノートでは、バージョンごとの対応PHPと支援期限が次のように示されています*6。
| Laravelバージョン | 対応PHP | セキュリティ修正終了 |
|---|---|---|
| Laravel 10 | 8.1〜8.3 | 2025年2月4日(終了済み)*6 |
| Laravel 11 | 8.2〜8.4 | 2026年3月12日*6 |
| Laravel 12 | 8.2〜8.5 | 2027年2月24日*6 |
Laravel 10はPHP 8.1に対応する最後の系列で、そのセキュリティ修正自体も2025年2月4日にすでに終了しています*6。Laravel 11以降はPHP 8.1に対応せず、PHPとフレームワーク双方の期限が重なって迫っている状態です*6。
WordPressを使っている場合は、公式のシステム要件ページが推奨バージョンをPHP 8.3以上としている点を踏まえておく必要があります*7。8.1は推奨ラインより2世代前にあたり、プラグインやテーマの検証対象からも外れやすくなります。
この作業を内製で担うには、複数領域の知識が要ります。PHP本体の非推奨機能の把握、Composer依存パッケージの対応バージョン確認、フレームワークのアップグレード手順、そして検証環境でのテスト運用などです*3*4*6。CI(継続的インテグレーション。コード変更を自動でビルド・テストする仕組み)パイプラインのPHPバージョン指定を更新し忘れると、切替後に想定外のビルド失敗が起きる場合もあります。
Composerを利用している場合は、composer.jsonのrequireにPHPバージョンの制約を明記しておくと、意図しない古いPHPでの実行を防ぎやすくなります。CI環境のPHPバージョン指定と本番サーバーの実際のバージョンが食い違っていないかも、切替前にあわせて確認したい点です。
内製と外注の分かれ目——移行体制の工数で判断する
PHP 8.1移行そのものの手順は公式情報として整理されているため、対象システムが小規模であれば自社で対応できる場合もあります*3*4。判断が分かれるのは、複数のシステムを抱える環境や、フレームワーク・拡張モジュールが複雑に絡む構成での監査と検証です。
専門パートナーに委託する場合は、依存関係の洗い出しから検証環境の構築、段階的な適用、切替後の監視までを一括して依頼できるかどうかが選定の分かれ目になります。内製では既存の運用担当者が通常業務と並行して対応することになり、検証に割ける時間が限られる場合があります。
。対象システムの数やフレームワークの構成によって必要な工数は変わってくるため、現状のコード診断から内製・外注の切り分けを検討することが実務的です。
まとめ：PHP 8.1移行で押さえる3つの判断軸
本稿ではPHP 8.1のサポート終了と移行の考え方を、PHP公式・フレームワーク公式の情報をもとに整理しました。要点は3つに集約できます。第一に、PHP 8.1のセキュリティサポートは2025年12月31日に終了し、以降の脆弱性修正は提供されません*1。第二に、8.2・8.3への移行では動的プロパティの非推奨化など複数の後方非互換の変更点があり、検証環境での事前確認が欠かせません*4。第三に、LaravelはすでにPHP 8.1対応系列のセキュリティ修正を終えており*6、対象システムの規模や構成によって内製と外注の判断が分かれます。
よくある質問
PHP 8.1のセキュリティサポートはいつ終了しましたか。
PHP公式は2025年12月31日をもってPHP 8.1系のセキュリティサポートを終了しました*1。この時点での最終リリースは8.1.34で、以降に見つかった脆弱性への修正パッチは提供されません*1。
PHP 8.1を使い続けると具体的にどのようなリスクがありますか。
新たに発見された脆弱性について、PHP本体からの修正パッチが提供されなくなります*1。外部からアクセスできるWebアプリケーションでは、脆弱性を突かれた場合の影響が広がりやすい点に注意が必要です。
PHP 8.2や8.3へ移行すると、既存のコードはそのまま動きますか。
多くの場合は動きますが、そのまま問題なく動くとは限りません。PHP 8.2ではクラスの動的プロパティ生成が非推奨化されるなど、書き方によっては警告が発生する変更点があります*4。移行前に検証環境での動作確認をお勧めします。
LaravelやWordPressを使っている場合、対応バージョンはどう確認すればよいですか。
Laravelは公式リリースノートにバージョンごとの対応PHPと支援期限を公開しており、Laravel 10はPHP 8.1に対応する最後の系列です*6。WordPressは公式の要件ページで推奨バージョンをPHP 8.3以上としています*7。まずは利用中のフレームワーク・CMSのバージョンを確認することが出発点になります。
移行作業を外部に委託する場合、何を確認すればよいですか。
対象システムの棚卸し方法、非推奨箇所の洗い出し手段、段階的な切替のスケジュールをまず確認します。加えてフレームワークやCMSのアップグレード対応範囲を委託先とすり合わせることが大切です。契約前に検証環境での確認範囲を明確にしておくと、切替後のトラブルを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：PHP「Unsupported Branches」（https://www.php.net/eol.php）
- *2 出典：PHP「Supported Versions」（https://www.php.net/supported-versions.php）
- *3 出典：PHP Manual「Deprecated Features（Migrating from PHP 8.0.x to PHP 8.1.x）」（https://www.php.net/manual/en/migration81.deprecated.php）
- *4 出典：PHP Manual「Deprecated Features（Migrating from PHP 8.1.x to PHP 8.2.x）」（https://www.php.net/manual/en/migration82.deprecated.php）
- *5 出典：PHP Manual「Deprecated Features（Migrating from PHP 8.2.x to PHP 8.3.x）」（https://www.php.net/manual/en/migration83.deprecated.php）
- *6 出典：Laravel「Release Notes」（https://laravel.com/docs/12.x/releases）
- *7 出典：WordPress.org「Requirements」（https://wordpress.org/about/requirements/）
