MENU
contact

PHPのバージョン管理について

PHP

採用はこちら

PHPのバージョン管理とは、プロジェクトごとに適切なPHPバージョンを決め、開発環境・本番環境・CI/CD・Composerの依存関係をできるだけ揃えて管理することです。

PHPはWebサイトやWebアプリケーション、WordPress、Laravel、Symfony、EC-CUBEなどで広く使われています。

しかし、プロジェクトによって必要なPHPバージョンは異なります。

たとえば、ある案件ではPHP 8.2、別の案件ではPHP 8.4、古いWordPressサイトではPHP 7.4、Laravelの新規案件ではPHP 8.4以上が必要になることもあります。

このような状態でPHPのバージョンを正しく管理していないと、次のようなトラブルが起こりやすくなります。

  • ローカル環境では動くのに本番環境でエラーになる
  • Composerの依存パッケージをインストールできない
  • WordPressのテーマやプラグインが動かない
  • PHPのアップデート後に警告やエラーが大量に出る
  • EOL済みのPHPを使い続けてセキュリティリスクが高まる
  • 引き継ぎ時に、どのPHPバージョンで動かすべきか分からない

PHPのバージョン管理は、単に「PHPを最新版にする」作業ではありません。

サイトやシステムを安定して運用するための環境管理と考えると分かりやすいです。

目次

PHPのバージョン管理が重要な理由

PHPのバージョン管理が重要な理由は、主に次の4つです。

開発環境と本番環境の差異を防ぐため

PHPはバージョンによって挙動が変わることがあります。

たとえば、古いPHPでは動いていたコードが、PHP 8系ではエラーになるケースがあります。

特にPHP 7系からPHP 8系へ移行する場合、型チェックの厳格化や非推奨機能の影響を受けることがあります。

開発環境がPHP 8.4で、本番環境がPHP 8.1のようにズレていると、開発中には問題が見えず、本番反映後にエラーが発生する可能性があります。

そのため、PHPのバージョンはできるだけ次の環境で揃えることが重要です。

  • ローカル開発環境
  • Dockerなどのコンテナ環境
  • ステージング環境
  • 本番環境
  • CI/CD環境
  • ComposerのPHP要件

完全に同じパッチバージョンまで揃えるのが難しい場合でも、少なくとも同じマイナーバージョン系で揃えることが望ましいです。

たとえば、本番がPHP 8.3系なら、開発環境もPHP 8.3系に合わせるという考え方です。

Composerの依存関係を正しく管理するため

PHPプロジェクトでは、Composerを使ってライブラリやフレームワークを管理することが一般的です。

Composerのパッケージには、それぞれ対応するPHPバージョンが指定されています。

たとえば、あるパッケージがPHP 8.2以上を要求している場合、PHP 8.1ではインストールできません。

また、ローカル環境のPHPが新しすぎると、本番環境では動かないバージョンのパッケージがインストールされてしまう場合もあります。

そのため、composer.json にPHPの対応バージョンを明記しておくことが大切です。

{
  "require": {
    "php": "^8.3"
  }
}

このように書くことで、そのプロジェクトがどのPHPバージョンを想定しているかを明確にできます。

また、本番環境がPHP 8.3で、ローカル環境がPHP 8.4の場合は、Composerの config.platform.php を使って、本番環境に合わせた依存解決を行うこともあります。

{
  "config": {
    "platform": {
      "php": "8.3.0"
    }
  }
}

ただし、config.platform.php は実際のPHP実行バージョンを変更する機能ではありません。

あくまで、Composerの依存解決上のPHPバージョンを指定する設定です。

セキュリティリスクを下げるため

PHPにはサポート期限があります。

サポートが終了したPHPバージョンは、脆弱性が見つかっても公式の修正が提供されません。

そのため、EOL済みのPHPを使い続けると、セキュリティリスクが高まります。

特に、PHP 7.4以前やPHP 8.0、PHP 8.1を使っているサイトは注意が必要です。

これらのバージョンはすでに公式サポートが終了しています。

EOL済みのPHPを使い続けると、次のような問題が起こりやすくなります。

  • セキュリティ脆弱性が修正されない
  • 新しいライブラリやフレームワークを使えない
  • サーバー移行時に古いPHPが利用できない
  • 保守できる担当者が少なくなる
  • 取引先や監査上のセキュリティ要件を満たせない場合がある

PHPのバージョン管理では、現在動いているかどうかだけでなく、今後も安全に運用できるかを考えることが重要です。

WordPressやプラグインの互換性を確認するため

WordPress案件では、PHP本体だけでなく、WordPress本体・テーマ・プラグイン・サーバー環境の対応状況も確認する必要があります。

PHPのバージョンを上げた結果、古いテーマやプラグインがエラーを起こすことがあります。

たとえば、次のようなトラブルが発生することがあります。

  • 管理画面にログインできない
  • 固定ページや投稿ページでエラーが出る
  • お問い合わせフォームが送信できない
  • EC機能や予約機能が動かない
  • カスタム投稿やカスタムフィールドが表示されない
  • 古いプラグインでFatal errorが出る

特にWebマーケティングに関わるサイトでは、フォーム・CVタグ・広告タグ・計測タグの不具合が機会損失につながります。

PHPのバージョンを変更した後は、見た目の確認だけでなく、コンバージョン導線まで確認することが大切です。

PHPのサポート状況

PHPは、各バージョンごとにサポート期限が決まっています。

基本的には、PHPの各リリースブランチは約2年間の通常サポートと、その後の約2年間のセキュリティサポートを受けます。

その後、EOLとなり、公式サポートが終了します。

2026年6月5日時点では、PHP 8.2、PHP 8.3、PHP 8.4、PHP 8.5が公式サポート対象です。

一方で、PHP 8.1以下は公式サポートが終了しています。

現在サポートされているPHPバージョン

2026年6月5日時点のPHPサポート状況は、次のように整理できます。

PHPバージョン状態通常サポート終了セキュリティサポート終了
PHP 8.5通常サポート中2027年12月31日2029年12月31日
PHP 8.4通常サポート中2026年12月31日2028年12月31日
PHP 8.3セキュリティサポート中2025年12月31日2027年12月31日
PHP 8.2セキュリティサポート中2024年12月31日2026年12月31日
PHP 8.1以下EOL終了済み終了済み

この表を見ると、PHP 8.2はまだサポート対象ではあるものの、2026年12月31日にセキュリティサポートが終了予定です。

そのため、これから新しく採用するバージョンとしては、PHP 8.2よりもPHP 8.4以上を検討したほうが安心です。

PHP 8.5の位置づけ

PHP 8.5は、2026年6月時点で最新のメジャー系バージョンです。サポート期間が長いため、新規開発の候補になります。

ただし、最新バージョンである分、周辺ツールやライブラリ、レンタルサーバー、WordPressプラグインが完全に対応していない可能性もあります。

PHP 8.5を採用する場合は、次の点を確認しましょう。

  • 利用するフレームワークがPHP 8.5に対応しているか
  • ComposerパッケージがPHP 8.5に対応しているか
  • 本番サーバーでPHP 8.5を利用できるか
  • 必要なPHP拡張モジュールが使えるか
  • WordPress案件の場合、テーマやプラグインが対応しているか

新規のLaravelやSymfony案件ではPHP 8.5が候補になりますが、安定性や互換性を重視する場合はPHP 8.4を選ぶ判断も現実的です。

PHP 8.4の位置づけ

PHP 8.4は、2026年6月時点では通常サポート中のバージョンです。

新規開発でも既存案件の移行先としても、バランスのよい選択肢です。

PHP 8.5ほど新しすぎず、PHP 8.3よりサポート期間にも余裕があります。

そのため、実務ではPHP 8.4を第一候補にすると判断しやすいケースが多いです。

特に次のような案件では、PHP 8.4が候補になります。

  • 新規のWebアプリケーション開発
  • LaravelやSymfonyなどのフレームワーク案件
  • 中長期で保守するWebサイト
  • PHP 8.1やPHP 8.2からの移行先
  • WordPressの新規構築案件

ただし、WordPress案件ではサーバーやプラグインの対応状況によって、PHP 8.3を選ぶほうが安全な場合もあります。

PHP 8.3の位置づけ

PHP 8.3は、2026年6月時点でセキュリティサポート中のバージョンです。

すでに通常サポートは終了していますが、まだ公式サポート対象です。そのため、既存案件の移行先としては現実的です。

ただし、新規で数年運用する案件では、PHP 8.4以上を優先したほうがサポート期間に余裕があります。

PHP 8.3が向いているのは、次のようなケースです。

  • 本番サーバーがPHP 8.4やPHP 8.5に未対応
  • WordPressプラグインの検証状況を重視したい
  • 既存サイトを段階的にPHP 8系へ移行したい
  • PHP 8.4以上で一部ライブラリに不安がある

PHP 8.3は「古くて使えない」バージョンではありません。

ただし、長期的にはPHP 8.4以上への移行計画を持っておくと安心です。

PHP 8.2の位置づけ

PHP 8.2は、2026年6月時点ではセキュリティサポート中です。

しかし、セキュリティサポートの終了が2026年12月31日に迫っています。

そのため、今から新規案件で積極的に採用するよりも、移行対象として考えるべきバージョンです。

すでにPHP 8.2で運用している案件は、すぐに危険というわけではありません。

ただし、2026年内にPHP 8.4以上への移行計画を立てるのが望ましいです。

PHP 8.1以下の位置づけ

PHP 8.1以下は、すでに公式サポートが終了しています。

そのため、原則として移行対象です。

特にPHP 7.4以前のサイトは、長期間EOL状態が続いています。

現在もPHP 7.4以下で動いているサイトは、セキュリティ・保守性・サーバー移行の観点から、早めに調査を行うべきです。

ただし、古いPHPから最新PHPへ一気に上げると、コードやライブラリ、WordPressテーマ、プラグインが壊れる可能性があります。

そのため、次のように段階的に進めると安全です。

PHP 7.4以下
↓
コード・依存関係・プラグインの調査
↓
PHP 8.1または8.2相当で検証
↓
PHP 8.3または8.4へ移行
↓
最終的にPHP 8.4以上を目指す

PHPバージョン番号の見方

PHPのバージョン番号は、一般的に次のような形式で表されます。

8.4.22

これは、次の3つに分けて考えます。

8 . 4 . 22
│   │   └ パッチバージョン
│   └ マイナーバージョン
└ メジャーバージョン

メジャーバージョン

メジャーバージョンは、PHP 7からPHP 8のような大きな変更を表します。

メジャーバージョンが変わると、互換性に影響する変更が含まれることがあります。

そのため、PHP 7系からPHP 8系へ移行する場合は、慎重な検証が必要です。

マイナーバージョン

マイナーバージョンは、PHP 8.3からPHP 8.4のような変更です。

新機能の追加や非推奨機能の変更、細かな仕様変更が含まれます。

基本的には互換性を意識してリリースされますが、既存コードに影響が出る場合もあります。

そのため、マイナーバージョンを上げる場合は、テスト環境で確認してから本番へ反映するのが安全です。

パッチバージョン

パッチバージョンは、PHP 8.4.21からPHP 8.4.22のような変更です。

主にバグ修正やセキュリティ修正が中心です。

通常は互換性への影響が少ないため、できるだけ最新のパッチバージョンを使うことが推奨されます。

PHPのバージョン管理では、次の考え方が基本です。

パッチバージョン：積極的に更新する
マイナーバージョン：検証して更新する
メジャーバージョン：計画的に移行する

PHPのバージョン管理方法

PHPのバージョン管理には、いくつかの方法があります。

代表的な方法は次の通りです。

  • Dockerで管理する
  • asdfで管理する
  • phpenvで管理する
  • Homebrewで管理する
  • レンタルサーバーの管理画面で切り替える
  • Composerで対応バージョンを明記する

どの方法が最適かは、案件の種類やチーム体制によって変わります。

Dockerで管理する

現在の実務では、Dockerを使ってPHPバージョンを管理する方法が非常に有効です。

Dockerを使うと、プロジェクトごとにPHPバージョンを固定できます。

たとえば、docker-compose.yml に次のように書くことで、PHP 8.4の環境を用意できます。

services:
  app:
    image: php:8.4-fpm
    volumes:
      - .:/var/www/html

Dockerを使うメリットは次の通りです。

  • プロジェクトごとにPHPバージョンを分けられる
  • チームメンバーの環境を揃えやすい
  • Windows、Mac、Linuxの差異を減らせる
  • Nginx、MySQL、Redisなどもまとめて管理できる
  • 本番環境に近い構成を再現しやすい
  • 環境構築手順をコードとして残せる

たとえば、A案件はPHP 8.2、B案件はPHP 8.4、C案件はPHP 8.5というように、複数案件を並行して扱う場合に便利です。

Web制作、WordPress、Laravel、ECサイト開発など、複数のプロジェクトを扱う場合は、Dockerによるバージョン管理が特に向いています。

asdfで管理する

asdfは、PHPだけでなく、Node.js、Ruby、Pythonなど複数の言語バージョンを管理できるツールです。

フロントエンドとバックエンドを両方扱う開発者にとって便利です。

asdfでは、プロジェクトルートに .tool-versions というファイルを置いて、使用するバージョンを指定します。

php 8.4.22
nodejs 22.0.0

これにより、プロジェクトごとにPHPやNode.jsのバージョンを切り替えられます。

ただし、PHPのビルドや拡張モジュールの設定で詰まることもあるため、初心者やチーム開発ではDockerのほうが扱いやすい場合もあります。

phpenvで管理する

phpenvも、複数のPHPバージョンを切り替えるためのツールです。

プロジェクトごとにPHPのバージョンを指定できるため、ローカル環境で複数案件を扱う場合に役立ちます。

ただし、asdfと同様に、PHPのビルドや拡張モジュールの設定が必要になることがあります。

すでにphpenvに慣れている場合は有効ですが、これから導入するなら、Dockerやasdfと比較して選ぶとよいでしょう。

Homebrewで管理する

Macを使っている場合は、HomebrewでPHPをインストールして管理する方法もあります。

brew install php@8.4

PHPのバージョンを切り替える場合は、次のようなコマンドを使います。

brew unlink php
brew link php@8.4 --force --overwrite
php -v

Homebrewは手軽にPHPを導入できる点がメリットです。

ただし、PC全体のPHPを切り替えるイメージに近いため、プロジェクトごとに細かくPHPバージョンを分けたい場合にはやや不向きです。

単一案件や個人開発では便利ですが、複数案件を扱う場合はDockerやasdfのほうが管理しやすいです。

レンタルサーバーで管理する

WordPress案件では、レンタルサーバーの管理画面からPHPバージョンを切り替えるケースが多いです。

たとえば、エックスサーバー、ConoHa WING、ロリポップ、さくらのレンタルサーバなどでは、管理画面からPHPバージョンを変更できます。

ただし、レンタルサーバーでは選べるPHPバージョンに制限があります。

ローカル環境ではPHP 8.5を使っていても、本番サーバーではPHP 8.3までしか選べないこともあります。

そのため、WordPress案件では、ローカル環境を作る前に本番サーバーで利用できるPHPバージョンを確認しておくことが大切です。

確認すべき項目は次の通りです。

  • 本番サーバーで選べるPHPバージョン
  • 利用しているWordPress本体のバージョン
  • テーマのPHP対応状況
  • プラグインのPHP対応状況
  • 必要なPHP拡張モジュール
  • ステージング環境の有無
  • バックアップ機能の有無

ComposerでPHPバージョンを管理する

Composerは、PHPプロジェクトの依存関係を管理するツールです。

PHPのバージョン管理では、Composerの設定も非常に重要です。

composer.jsonにPHP要件を書く

composer.json にPHPのバージョン要件を書いておくと、そのプロジェクトがどのPHPバージョンを想定しているかを明確にできます。

たとえば、PHP 8.3以上を想定する場合は次のように書きます。

{
  "require": {
    "php": "^8.3"
  }
}

PHP 8.4以上を想定する場合は、次のように書きます。

{
  "require": {
    "php": "^8.4"
  }
}

より範囲を細かく指定したい場合は、次のような書き方もできます。

{
  "require": {
    "php": ">=8.3 <8.5"
  }
}

このように書いておくことで、対応していないPHPバージョンでComposerを実行したときにエラーを出せます。

config.platform.phpを使う

config.platform.php は、Composerの依存解決上のPHPバージョンを指定する設定です。

たとえば、本番環境がPHP 8.3で、ローカル環境がPHP 8.4の場合、ローカル環境のPHP 8.4を基準に依存関係が解決されると、本番環境で動かないパッケージが入ってしまう可能性があります。

そのような場合、次のように設定します。

{
  "config": {
    "platform": {
      "php": "8.3.0"
    }
  }
}

これにより、ComposerはPHP 8.3の環境として依存関係を解決します。

ただし、重要な注意点があります。

config.platform.php は、実際のPHP実行バージョンを変更するものではありません。

あくまでComposerの依存解決を制御する設定です。

つまり、次のような状態もあり得ます。

ローカルPHP：8.4
Composer上の想定PHP：8.3
本番PHP：8.3

実際の動作確認は、本番と同じPHPバージョンの環境で行うのが理想です。

composer.lockを管理する

Composerを使うプロジェクトでは、composer.lock も重要です。

composer.lock には、実際にインストールされたパッケージのバージョンが記録されます。

チーム開発では、composer.json だけでなく composer.lock もGitで管理することで、メンバー全員が同じ依存パッケージを使いやすくなります。

本番環境でも、基本的には次のように composer install を使います。

composer install --no-dev --optimize-autoloader

composer update は依存パッケージのバージョンを更新するコマンドなので、本番環境で安易に実行しないほうが安全です。

PHP拡張モジュールも確認する

PHPのバージョン管理では、PHP本体のバージョンだけでなく、PHP拡張モジュールも確認する必要があります。

Composerのパッケージによっては、次のような拡張モジュールを要求することがあります。

ext-mbstring
ext-intl
ext-pdo
ext-curl
ext-zip
ext-gd
ext-openssl

PHPのバージョンが合っていても、必要な拡張モジュールが入っていないとアプリケーションが動かないことがあります。

確認には次のコマンドが便利です。

composer check-platform-reqs

このコマンドでは、PHPバージョンだけでなく、必要なPHP拡張モジュールを満たしているかも確認できます。

PHPバージョンを確認するコマンド

PHPのバージョン管理を行う場合、まず現在の環境を確認することが重要です。

PHPのバージョンを確認する

php -v

このコマンドで、CLI上のPHPバージョンを確認できます。

ただし、CLIのPHPとWebサーバーで動いているPHPが異なることがあります。

特にレンタルサーバーや複数PHP環境では注意が必要です。

PHPのパスを確認する

MacやLinuxでは、次のコマンドでPHPの場所を確認できます。

which php

Windowsでは次のコマンドを使います。

where php

想定と違うPHPが使われている場合、PATHの設定やシェルの設定を見直す必要があります。

読み込まれているphp.iniを確認する

PHPの設定ファイルを確認するには、次のコマンドを使います。

php --ini

これにより、どの php.ini が読み込まれているかを確認できます。

PHPのメモリ上限、アップロードサイズ、タイムゾーン、エラー表示などは php.ini の影響を受けます。

PHP拡張モジュールを確認する

インストールされているPHP拡張モジュールを確認するには、次のコマンドを使います。

php -m

mbstring、intl、pdo_mysql、curl、zip、gd などが必要になる案件は多いです。

LaravelやWordPress、ECサイトでは、PHP本体のバージョンだけでなく拡張モジュールの確認も欠かせません。

Composerの要件を確認する

Composerの依存関係が現在の環境を満たしているか確認するには、次のコマンドを使います。

composer check-platform-reqs

依存パッケージの更新状況を確認するには、次のコマンドを使います。

composer outdated

Composerの診断情報を確認するには、次のコマンドを使います。

composer diagnose

PHPバージョンを変更する前の確認項目

PHPのバージョンを変更する前には、必ず事前確認を行いましょう。

特に本番環境でいきなりPHPバージョンを変更するのは危険です。

現在のPHPバージョンを確認する

まず、現在のPHPバージョンを確認します。

php -v

Webサーバー上で動いているPHPを確認する場合は、サーバー管理画面やphpinfoを使います。

一時的に phpinfo.php を設置して確認する場合は、確認後に必ず削除してください。

<?php
phpinfo();

phpinfo() はサーバー情報を大量に表示するため、放置するとセキュリティ上好ましくありません。

本番環境で選べるPHPバージョンを確認する

レンタルサーバーやマネージドサーバーでは、利用できるPHPバージョンが決まっています。

ローカル環境でPHP 8.5を使えても、本番環境ではPHP 8.4までしか選べない場合があります。

そのため、PHPのバージョン管理では、本番環境を基準に考えることが大切です。

フレームワークの対応状況を確認する

Laravel、Symfony、CakePHP、CodeIgniterなどを使っている場合は、フレームワークの対応PHPバージョンを確認します。

古いフレームワークでは、最新PHPに対応していないことがあります。

PHP本体だけを上げても、フレームワークが対応していなければ動作しません。

Composerパッケージの対応状況を確認する

PHPバージョンを上げる前に、Composerパッケージの対応状況も確認します。

composer outdated
composer check-platform-reqs

古いパッケージがある場合は、PHPバージョンを上げる前にパッケージ更新が必要になることがあります。

WordPressのテーマ・プラグインを確認する

WordPress案件では、次の確認が重要です。

  • WordPress本体が最新に近いか
  • 使用テーマがPHP 8系に対応しているか
  • 使用プラグインがPHP 8系に対応しているか
  • 放置されているプラグインがないか
  • 独自カスタマイズ部分がPHP 8系で動くか
  • ステージング環境で検証できるか

古いテーマやプラグインでは、PHP 8系でエラーが出ることがあります。

バックアップを取る

PHPバージョンを変更する前には、必ずバックアップを取ります。

最低限、次のバックアップを取得しましょう。

  • ファイル一式
  • データベース
  • .env
  • composer.json
  • composer.lock
  • WordPressの wp-content
  • アップロードファイル
  • テーマファイル
  • プラグインファイル

特にWordPressでは、データベースと wp-content のバックアップが重要です。

PHPバージョンアップの進め方

PHPのバージョンアップは、計画的に進めることが大切です。

現状を把握する

まず、現在の環境を整理します。

現在のPHPバージョン
本番サーバーで選べるPHPバージョン
使用しているフレームワーク
Composerパッケージ
WordPress本体
テーマ
プラグイン
PHP拡張モジュール
エラーログ

この段階で、EOL済みのPHPを使っているか、どのバージョンまで上げられるかを確認します。

ステージング環境を用意する

本番環境でいきなりPHPを変更するのではなく、ステージング環境で検証します。

ステージング環境では、本番とできるだけ同じ構成にすることが理想です。

同じPHPバージョン
同じWebサーバー
同じデータベース
同じComposer依存関係
同じWordPressテーマ・プラグイン
同じPHP拡張モジュール

環境差異が大きいと、ステージングで問題がなくても本番でエラーが出る可能性があります。

依存関係を更新する

PHPバージョンを上げる前に、ComposerパッケージやWordPressプラグインを更新します。

Laravelなどのフレームワーク案件では、まずフレームワーク本体や主要パッケージの対応状況を確認しましょう。

WordPress案件では、次の順番が安全です。

1. バックアップを取る
2. WordPress本体を更新する
3. テーマを更新する
4. プラグインを更新する
5. ステージング環境でPHPを変更する
6. エラーログを確認する
7. 主要機能をテストする
8. 問題がなければ本番へ反映する

エラーログを確認する

PHPバージョンを変更したら、必ずエラーログを確認します。

WordPressでは、必要に応じて wp-config.php に次の設定を入れて、デバッグログを確認します。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

WP_DEBUG_DISPLAY を false にしておくことで、画面上にはエラーを表示せず、ログに記録できます。

本番環境では、画面にエラーを表示しない設定にするのが基本です。

WordPress案件でのPHPバージョン管理

WordPress案件では、PHPバージョン管理の考え方が少し特殊です。

PHP本体だけでなく、WordPress本体・テーマ・プラグイン・レンタルサーバーの組み合わせで判断する必要があります。

WordPressではPHP最新版が常に正解とは限らない

PHPは新しいほうがセキュリティやパフォーマンス面で有利なことが多いです。

しかし、WordPress案件では、最新PHPにすると古いテーマやプラグインが動かなくなる場合があります。

特に次のようなサイトでは注意が必要です。

  • 長年更新されていないWordPressサイト
  • 制作会社独自の古いテーマを使っているサイト
  • 開発が止まっているプラグインを使っているサイト
  • PHP 7系で長く運用されていたサイト
  • カスタム投稿やカスタムフィールドが多いサイト
  • EC、予約、会員機能があるサイト

このような場合、いきなりPHP 8.5に上げるのではなく、ステージングでPHP 8.3やPHP 8.4を試しながら段階的に移行するのが安全です。

WordPressでPHPを上げる前に確認すること

WordPressでPHPを上げる前には、次の項目を確認しましょう。

WordPress本体のバージョン
テーマの更新状況
プラグインの更新状況
PHP 8系への対応状況
サーバーで選べるPHPバージョン
バックアップの有無
ステージング環境の有無
エラーログの確認方法
フォームや決済機能の有無
広告タグや計測タグの有無

特に、問い合わせフォームや決済機能があるサイトでは、PHP変更後に必ず実際の送信・購入テストを行いましょう。

WordPress案件でおすすめの進め方

WordPress案件では、次の流れで進めると安全です。

1. 現在のPHPバージョンを確認する
2. WordPress本体・テーマ・プラグインを確認する
3. バックアップを取る
4. ステージング環境を作る
5. ステージングでPHPを変更する
6. エラーログを確認する
7. 管理画面と公開ページを確認する
8. フォーム・決済・予約・会員機能を確認する
9. 広告タグ・CVタグ・計測タグを確認する
10. 問題がなければ本番環境でPHPを変更する

WordPressの場合、管理画面にログインできるかどうかも重要です。

公開ページが正常でも、管理画面でエラーが出る場合があります。

更新作業や記事投稿に支障が出るため、必ず確認しましょう。

案件別のPHPバージョン選定

PHPの推奨バージョンは、案件の種類によって変わります。

新規のLaravel・Symfony案件

新規のLaravelやSymfony案件では、PHP 8.4またはPHP 8.5が候補になります。

ただし、利用するフレームワークやパッケージがPHP 8.5に完全対応しているか確認する必要があります。

安定性とサポート期間のバランスを重視するなら、PHP 8.4が選びやすいです。

最新性重視：PHP 8.5
安定性重視：PHP 8.4
長期運用重視：PHP 8.4以上

新規WordPress案件

新規WordPress案件では、PHP 8.4を第一候補にしつつ、サーバーやプラグインの対応状況によってPHP 8.3を選ぶこともあります。

PHP 8.5も候補になりますが、テーマやプラグインの検証状況によっては慎重に判断したほうがよいです。

特に、複数のプラグインを使うサイトでは、最新PHPへの対応状況を確認してから採用しましょう。

既存WordPress案件

既存WordPress案件では、現在のPHPバージョンとサイトの状態によって判断します。

PHP 8.1以下を使っている場合は、すでにEOLのため移行が必要です。

ただし、古いサイトではPHPを一気に上げるとエラーが出る可能性があります。

まずはステージング環境でPHP 8.3またはPHP 8.4を検証し、問題点を洗い出すとよいでしょう。

PHP 8.2で運用中の案件

PHP 8.2は、2026年12月31日にセキュリティサポート終了予定です。

そのため、現在PHP 8.2で運用している案件は、2026年内にPHP 8.4以上への移行計画を立てるのが望ましいです。

すぐにPHP 8.5へ移行できない場合でも、PHP 8.4を目標にすると現実的です。

PHP 8.1以下で運用中の案件

PHP 8.1以下は公式サポートが終了しています。

そのため、できるだけ早めに移行を検討しましょう。

特にPHP 7.4以下の場合、古い書き方やライブラリが多く残っている可能性があります。

その場合は、次のように段階的に進めると安全です。

1. 現在のコード・ライブラリ・プラグインを調査する
2. エラーログを確認する
3. 依存関係を更新する
4. PHP 8系で動作検証する
5. 問題箇所を修正する
6. PHP 8.3またはPHP 8.4へ移行する

PHPバージョン管理でよくある失敗

PHPのバージョン管理では、よくある失敗パターンがあります。

ローカルと本番のPHPバージョンが違う

もっとも多い失敗の1つが、ローカル環境と本番環境のPHPバージョンが違うケースです。

ローカルではPHP 8.4、本番ではPHP 8.1という状態だと、ローカルで動いていたコードが本番で動かない可能性があります。

この問題を防ぐには、Dockerやasdfを使って、プロジェクトごとにPHPバージョンを明確に管理することが有効です。

composer.jsonにPHP要件を書いていない

composer.json にPHP要件を書いていないと、そのプロジェクトがどのPHPバージョンを想定しているか分かりにくくなります。

チーム開発や長期保守では、必ずPHP要件を書いておきましょう。

{
  "require": {
    "php": "^8.4"
  }
}

composer.lockを更新・管理していない

composer.lock を管理していないと、開発者ごとに異なるパッケージバージョンが入ってしまう場合があります。

本番環境と開発環境の依存関係を揃えるためにも、通常は composer.lock をGitで管理します。

EOL済みPHPを使い続ける

「今動いているから大丈夫」という理由でEOL済みPHPを使い続けるのは危険です。

EOL済みPHPはセキュリティ修正が提供されないため、脆弱性が残る可能性があります。

特に企業サイト、ECサイト、会員サイト、問い合わせフォームを持つサイトでは、早めの移行が必要です。

本番環境でいきなりPHPを変更する

本番環境でいきなりPHPバージョンを変更すると、サイト全体が表示されなくなる可能性があります。

PHPバージョンを変更する場合は、必ずステージング環境で検証してから本番に反映しましょう。

表示確認だけで終わってしまう

PHPバージョン変更後にトップページだけ確認して終わるのは危険です。

フォーム、決済、ログイン、検索、会員機能、管理画面、広告タグ、CVタグなども確認する必要があります。

特にマーケティングサイトでは、見た目が正常でもCV計測が壊れている可能性があります。

PHPバージョン管理の実務チェックリスト

PHPのバージョン管理では、次のチェックリストを使うと抜け漏れを防ぎやすくなります。

環境確認のチェックリスト

現在のPHPバージョンを確認した
本番環境のPHPバージョンを確認した
ローカル環境のPHPバージョンを確認した
CI/CD環境のPHPバージョンを確認した
読み込まれているphp.iniを確認した
必要なPHP拡張モジュールを確認した

Composer確認のチェックリスト

composer.jsonにPHP要件を書いている
composer.lockを管理している
composer check-platform-reqsを実行した
composer outdatedで古いパッケージを確認した
config.platform.phpの必要性を確認した
本番環境でcomposer updateを安易に実行しない運用にしている

WordPress確認のチェックリスト

WordPress本体を更新した
テーマの対応状況を確認した
プラグインの対応状況を確認した
放置されているプラグインを確認した
バックアップを取った
ステージング環境で検証した
管理画面を確認した
公開ページを確認した
フォーム送信を確認した
広告タグ・CVタグを確認した
エラーログを確認した

本番反映前のチェックリスト

ファイルのバックアップを取った
データベースのバックアップを取った
ステージング環境で動作確認した
主要ページを確認した
主要機能を確認した
エラーログを確認した
ロールバック手順を用意した
関係者に作業時間を共有した

PHPバージョン管理のおすすめ方針

2026年6月時点でのPHPバージョン管理は、次のように考えるとよいです。

新規開発ではPHP 8.4以上を検討する

新規開発では、PHP 8.4以上を検討するのが現実的です。

PHP 8.5はサポート期間が長く魅力的ですが、周辺ツールやサーバーの対応状況を確認する必要があります。

安定性を重視するならPHP 8.4、最新性を重視するならPHP 8.5を候補にするとよいでしょう。

既存案件ではPHP 8.3以上を目標にする

既存案件では、まずPHP 8.3以上を目標にすると現実的です。

ただし、PHP 8.3はすでにセキュリティサポートのみの段階です。

長期運用を考えるなら、最終的にはPHP 8.4以上を目指しましょう。

PHP 8.2は移行計画を立てる

PHP 8.2は、2026年末にセキュリティサポートが終了予定です。

現在PHP 8.2で運用している案件は、早めにPHP 8.4以上への移行計画を立てることをおすすめします。

PHP 8.1以下は早急に移行する

PHP 8.1以下は公式サポートが終了しています。

そのため、セキュリティや保守性の観点から早急に移行を検討しましょう。

ただし、古い環境では一気に上げるとトラブルが起こる可能性があるため、ステージング環境で段階的に検証することが重要です。

まとめ

PHPのバージョン管理は、WebサイトやWebアプリケーションを安全に運用するために欠かせない作業です。

PHP本体のバージョンだけでなく、開発環境、本番環境、CI/CD、Composer、PHP拡張モジュール、WordPressテーマ、プラグインまで含めて管理する必要があります。

2026年6月時点では、PHP 8.2、PHP 8.3、PHP 8.4、PHP 8.5が公式サポート対象です。

ただし、PHP 8.2とPHP 8.3は通常サポートが終了しており、セキュリティサポートのみです。

そのため、実務では次のように考えるとよいでしょう。

新規開発：PHP 8.4またはPHP 8.5を検討する
既存案件：PHP 8.3以上、できればPHP 8.4以上を目指す
PHP 8.2案件：2026年内に移行計画を立てる
PHP 8.1以下：早急に移行を検討する

PHPのバージョンアップでは、本番環境でいきなり変更するのではなく、必ずステージング環境で検証しましょう。

特にWordPress案件では、テーマ・プラグイン・フォーム・決済・広告タグ・CVタグまで確認することが重要です。

PHPのバージョン管理を適切に行うことで、セキュリティリスクを下げ、サイトの安定性を高め、長期的に保守しやすい環境を作ることができます。

以上、PHPのバージョン管理についてでした。

最後までお読みいただき、ありがとうございました。

PHP
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

関連記事

  1. ホーム
  2. PHP
  3. PHPのバージョン管理について
目次