本番サーバーのPHPバージョンを上げたらサイトが壊れた話

「更新したらサイトが真っ白になった」は現場でよく起きる悲劇です。テスト環境なしのPHPアップデートが招くリスクと、安全な更新手順を実案件ベースで解説します。

こんな状況、心当たりありませんか？

サーバー管理会社から「PHP 7.4のサポートが終了します。バージョンアップを推奨します」という通知メールが届いた。セキュリティのためにも早めに対応しなければ、と思い立ってその日の夜に本番サーバーのPHPを8.1に更新した。

そして翌朝、サイトが真っ白——。

お問い合わせフォームも動かない。管理画面にもログインできない。営業時間が始まってから問い合わせが届き始めて、パニックになる。

これは決して珍しい話ではありません。Fivenineでも過去に「他社で急にバージョンアップされてしまって…」というご相談を何件も受けています。PHPのメジャーバージョンアップは、一見すると単純な作業に見えて、実は非常に影響範囲が広い変更です。このページでは、なぜテスト環境が必要なのか、そして安全に更新するための具体的な手順を解説します。

なぜPHPバージョンアップでサイトが壊れるのか

PHPは「後方互換性」を意図的に捨てることがある

PHP 7系から8系へのアップグレードは特に破壊的な変更が多く、開発者の間では「マイグレーションの鬼門」とも呼ばれています。具体的にどのような変更があるかというと——

PHP 8.0での主な破壊的変更（一例）

• array_key_exists() の第2引数にオブジェクトを渡すと型エラー
• 数値文字列の比較演算の挙動変更（0 == 'foo' が false に）
• 非推奨だった関数群（create_function() など）の完全削除
• 引数の型チェックが厳格化され、型の不一致でエラーが発生しやすくなった

PHP 8.1での追加変更

• null を非null型の変数に渡すと Deprecated 警告（将来的にエラー）
• fsync() などの新関数追加と既存関数の動作変更
• readonly プロパティの導入による一部ライブラリとの競合

これらの変更は、長年動いていたコードを「突然動かなくなるコード」に変えてしまいます。特にWordPressの古いプラグインやLaravelの旧バージョン、自社開発の独自システムは影響を受けやすい傾向があります。

実案件から学ぶ：ステージング環境があれば防げた事故

あるクライアント（神奈川県内の製造業、WordPressで製品紹介サイトを運営）から連絡が入ったのは、本番サーバーのPHPを7.4から8.2に更新した直後でした。症状は以下のとおりです。

• トップページは表示されるが、製品一覧ページが500エラー
• カスタムフィールドを表示するプラグイン「Advanced Custom Fields（無料版）」が動作しない
• お問い合わせフォームプラグインのメール送信が停止

原因を調査したところ、ACFの古いバージョンがPHP 8.xの型チェック厳格化に対応していなかったことが判明しました。また、フォームプラグインが依存していた関数がPHP 8.2で挙動変更されており、そこでも問題が発生していました。

復旧にかかった時間は約4時間。その間、問い合わせページにアクセスできない状態が続きました。

もし事前にステージング環境で同じ手順を試していれば、この問題はリリース前に発見できていました。対処も「本番が落ちた状態での作業」ではなく、落ち着いた状態でのテストとして完結できたはずです。

安全なPHPバージョンアップの具体的な手順

ステップ1：ステージング環境を用意する

まず本番と同等の環境を別途用意します。多くのレンタルサーバー（エックスサーバー、ConoHa WINGなど）はコントロールパネルからPHPバージョンを切り替えられるため、ステージングサブドメインを作成してそこで検証するのが現実的です。

Dockerを使えるエンジニアがいる場合は、ローカル環境で先行テストするのも有効です。

# docker-compose.yml
version: '3.8'
services:
  php81:
    image: php:8.1-apache
    ports:
      - "8081:80"
    volumes:
      - ./src:/var/www/html
  php82:
    image: php:8.2-apache
    ports:
      - "8082:80"
    volumes:
      - ./src:/var/www/html

# .htaccessでステージング環境のPHPバージョンを指定（エックスサーバーの場合）
# Xserverのコントロールパネル > PHP Ver.切替 > ステージングドメインに適用

# またはphp.iniで確認
phpinfo();
// 現在のバージョンと設定を確認してから変更する

ステップ2：PHP互換性チェックツールで事前スキャン

コードを目視で確認するのは限界があります。PHP_CodeSniffer + PHPCompatibility というツールを使うと、対象バージョンで問題になるコードを自動検出できます。

# Composerでインストール
composer require --dev squizlabs/php_codesniffer
composer require --dev phpcompatibility/php-compatibility

# PHP 8.1の互換性チェックを実行
./vendor/bin/phpcs \
  --standard=PHPCompatibility \
  --runtime-set testVersion 8.1 \
  -r ./wp-content/themes/your-theme/ \
  --extensions=php

出力例：

FOUND 3 ERRORS AFFECTING 2 FILES
-------------------------------------------------------
 functions.php:142 | ERROR | Function create_function() is removed in PHP 8.0
 custom-post.php:87 | ERROR | Passing null to non-nullable parameter deprecated in PHP 8.1

このようにエラーが特定できれば、修正箇所が明確になります。

ステップ3：ステージングでバージョン切り替えと動作確認

ツールでのスキャン後、ステージング環境でPHPバージョンを切り替えて実際に動作確認します。確認すべき項目はシステムによって異なりますが、最低限以下は必ずチェックしてください。

• トップページの表示
• 主要な内部リンクページの表示
• フォーム送信（実際に送信テストを行う）
• 管理画面へのログインと各種操作
• ECサイトであれば決済フロー全体
• 外部サービス連携（メール送信、API連携など）

エラーが出た場合は、PHPのエラーログを確認します。

# エラーログの確認（サーバーのパスは環境により異なる）
tail -n 50 /var/log/php/error.log

# またはWordPressならwp-config.phpでデバッグを有効化
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );  // /wp-content/debug.logに記録
define( 'WP_DEBUG_DISPLAY', false );  // 画面には表示しない

ステップ4：本番更新前にバックアップを取得し、メンテナンスモードへ

ステージングで問題なければ、本番に適用します。ただし更新前後のバックアップは必須です。

# データベースのバックアップ（WordPressの場合）
mysqldump -u dbuser -p dbname > backup_$(date +%Y%m%d_%H%M%S).sql

# ファイルのバックアップ
tar czf site_backup_$(date +%Y%m%d).tar.gz /var/www/html/

WordPressであればメンテナンスプラグインを使い、作業中はユーザーに「メンテナンス中」画面を表示する配慮も忘れずに。

よくある失敗パターンと対処法

まとめ：「更新前のひと手間」がサイトを守る

PHPのバージョンアップ自体は避けて通れない作業です。セキュリティ的には古いPHPを使い続けることのほうが危険であり、サポート切れのバージョンは脆弱性が修正されなくなります。

問題は「更新する/しない」ではなく、**「どのように更新するか」**です。ステージング環境での事前検証というひと手間が、本番サイトの停止という最大のリスクを防ぎます。

Fivenineでは、お客様のサーバー環境を調査したうえで、ステージング環境の構築から動作確認・本番適用まで一括してサポートしています。「自分では判断できない」「エラーが出て対処できない」という方は、ぜひご相談ください。

PHPバージョンアップ 安全手順チェックリスト