PHPバージョンアップでサイト崩壊？安全な切り替え順序と検証手法

0. イントロダクション
1. 事前準備フェーズ（前日までに必ず実施）
2. 検証フェーズ（Stagingで徹底テスト）
3. 本番切替フェーズ（ダウンタイム最短15分）
4. 切替後72時間モニタリング＆微調整
5. 代表的エラーと即応フローチャート（図解）
6. ケーススタディ３選
7. よくある質問 20（FAQ）
8. まとめ ─ “安全バージョンアップ”３ヵ条と今後のステップ

0. イントロダクション

0‑1. なぜ今 PHP を上げるべきか

速度向上 : PHP 8.x は 7.4 と比べ実行速度が 10〜30% 向上。ページ離脱率低下と SEO スコア改善に直結します。
セキュリティ : 7.4 は 2025‑11 に EOL。脆弱性パッチが提供されなくなると、改ざんや情報漏洩リスクが急上昇。
最新テーマ／プラグイン互換 : 新機能は 8.x 前提が増加。旧バージョンではアップデートすら不可能になるケースも。

0‑2. バージョンアップで起きる典型的トラブル３種

Fatal error : 非推奨関数や型宣言エラーで画面が真っ白（White Screen of Death）。
表示崩れ : テーマやビルダーが未対応で CSS／JS が読めずレイアウト破壊。
外部連携停止 : 古いプラグインの REST API コールが 500 を返し、決済・フォームが動かない。

0‑3. “安全切替３ステップ” 全体像

Step1 事前準備（前日まで）    ― 現状把握＋Staging複製＋互換性スキャン
Step2 検証フェーズ（当日午前） ― StagingでPHP切替→全機能テスト
Step3 本番切替＋モニタ（午後〜72h） ― メンテON→切替→監視→微調整

この順序を守れば、ダウンタイム15分以内 でバージョンアップ可能です。

1. 事前準備フェーズ（前日までに必ず実施）

本番切替の成否は準備で 80% 決まります。以下を漏れなくチェックしましょう。

1‑1. 現行環境の棚卸し

項目	確認方法	メモ例
PHPバージョン	ServerPanel → PHP Ver切替	7.4.33
拡張モジュール	`phpinfo()` or WP Site Health	mbstring, curl, imagick
テーマ/プラグイン数	WP管理画面 → プラグイン一覧	有効36, 無効12
カスタムコード	`functions.php`, mu‑plugins	独自ショートコード3本

理由 : 互換性エラーは「どこで何を使っているか」を把握していないと特定が困難。

エラー回避Tips

プラグインは CSV でエクスポートし、バージョンを一覧化。後の互換チェックとロールバックに便利。

1‑2. Git／自動バックアップ確認

Git管理 : git status が clean であることを確認し、タグ pre‑php‑upgrade を打つ。
Xserver自動バックアップ : サーバーパネル → バックアップ → 手動バックアップを取得。
復元テスト : Staging環境で ZIP を展開し、リストア時間を計測（目標15分以内）。

理由 : ロールバックに 30 分以上かかると、売上・SEO 影響が無視できない規模に。

1‑3. Staging環境複製（WP Staging 使用例）

プラグイン「WP Staging」をインストール → [Create New Staging Site] をクリック。
stg.example.com などサブディレクトリに複製。完了まで待機（数分〜サイト規模により異なる）。
ログインURLと管理者PWをメモ。検索エンジン非公開設定をONに。

補足 : Local by Flywheel を使う場合は、wp‑content と DB をエクスポート → インポートで同等環境を作成可能。

1‑4. PHP互換性スキャナ実行

wp plugin install php‑compatibility‑checker --activate
wp php‑compatibility‑checker

出力例
- Deprecated: create_function() → PHP8で削除
- Incompatible: each() → 代替 foreach

理由 : コードを全行手動確認は不可能。ツールで “危険箇所” を絞り込みます。

1‑5. ロールバック手順書を印刷

メンテOFF→PHP7.4へ戻す→OPcacheクリア→キャッシュ削除 の手順を A4 1枚にまとめる。
万一の停電やネット遮断でもスマホ写真で参照できるよう撮影。

Tips : Slack ワークスペースにもピン留めし、リモート担当者と共有すると安心。

次の出力では Step2「検証フェーズ」を丁寧に執筆していきます。

2. 検証フェーズ（Stagingで徹底テスト）

本番へ切り替える前に、Staging環境で必須機能をすべて動作確認し、互換性を検証します。

2-1. ServerPanelで PHP7.4 → 8.x へ切替／モジュール選択

手順

Staging環境のServerPanelにログインし、［PHP Ver.切替］を開く。
現行の7.4系を確認後、8.1または8.2を選択して［変更］をクリック。
同画面の［モジュール選択］で、mbstring、curl、xml、gd、intl、opcacheなど必須拡張が有効かチェック。
もしOFFの場合はONに切り替え、［設定反映］を実行。
設定反映後、StagingのWordPress管理画面→サイトヘルス情報でPHPバージョンと拡張状況を再確認。

理由

新バージョンはデフォルトで一部拡張が外れることがあるため、本番と同じモジュール構成で動作検証が必要です。

補足

複数バージョンをテストしたい場合は、8.0→8.1→8.2の順に切り替え、各バージョンで手順2-2以降を繰り返します。

エラー回避Tips

PHP情報画面(phpinfo())はキャッシュ消去後に閲覧し、古い情報が残らないよう注意。

2-2. ログイン〜投稿〜決済・問い合わせフォーム動作確認フロー

手順

Stagingサイトに管理者でログインし、ダッシュボードの表示を確認。
新規固定ページを作成し、本文にサンプルテキストを入力して公開。
投稿（ブログ記事）を新規追加し、カテゴリー・タグを設定後、公開画面を確認。
決済テスト環境（WooCommerce等）にてサンドボックス決済を実行し、決済完了メールが送受信できるか検証。
問い合わせフォーム（Contact Form 7 等）でテスト送信し、メール受信ログに記録されるかチェック。

理由

管理画面の崩壊や投稿・決済・フォームといった主要な機能停止はサイト運営に致命的。全フローを網羅的に確認します。

補足

キャッシュプラグインを使っている場合は一度無効化し、純粋なPHP挙動を確認してください。

エラー回避Tips

ステップごとにスクリーンショットを撮り、後で本番環境と比較しやすくしておくと安心です。

2-3. WP_DEBUG + Query Monitor でDeprecated確認

手順

wp-config.php に以下を追加：

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

プラグイン「Query Monitor」をインストールし、有効化。
サイト上で各ページを巡回。Query Monitor の管理バーから「PHP Warnings」を確認し、Deprecated や Notices を洗い出す。
wp-content/debug.log を開き、該当ログの詳細パスと行番号を把握。

理由

PHP8 では旧関数や非推奨仕様がエラー扱いになるものがあるため、事前に洗い出し修正が必要です。

補足

Query Monitor はクエリ実行時間やHTTP APIコールも表示できるため、パフォーマンス検証にも使えます。

エラー回避Tips

デバッグ後は必ず WP_DEBUG をfalseに戻し、公開環境でログ出力オーバーヘッドを防ぎます。

2-4. カスタムコード互換テスト

手順

/wp-content/themes/使用テーマ/functions.php と /wp-content/mu-plugins/ 内のファイルをIDEで開く。
type error や undefined function をキーワードに全ファイルをgrep検索。
クラス名・関数名のスペルミス、名前空間衝突を修正。
独自プラグインがある場合は、each() や create_function() の置換も行う。
修正後、Step2-2 を再実行して機能確認。

理由

独自コードやカスタマイズ部分は自動ツールが検知できないため、手動で重点チェックが必要です。

補足

functions.php は必ずPCローカルで php -l filename.php を通して構文エラーがないか検証。

エラー回避Tips

名前空間を付与する場合は namespace MyTheme; を先頭に追加して他ライブラリと衝突しないように。

2-5. 自動テストスクリプト例（WP-CLI + Ghost Inspector）

# WP-CLI で主要フローを一括テスト
wp --url=https://stg.example.com eval "
  require 'wp-load.php';
  // テスト関数呼び出し
  var_export(test_post_and_page());
"

Ghost Inspector はブラウザ自動操作で「ログイン→投稿→購入→問い合わせ送信」のスクリーンキャプチャを取る。

理由

手動テストだけでは見落としがあるため、自動化スクリプトで繰り返し検証できる環境を整えます。

補足

GitHub Actions に組み込むことで、プルリクエスト時にも検証が走るCIパイプラインが実現。

エラー回避Tips

テストデータはStaging専用にし、本番DBに影響しないよう環境変数で切替。

2-6. “OK判定”チェックリスト

検証項目	結果	備考
管理画面ログイン	◯	30秒以内
固定ページ作成・公開	◯	レイアウト崩れなし
投稿記事表示	◯	メディア読み込みOK
決済テスト	◯	支払い成功/メール送信
問い合わせフォーム送信	◯	送信完了メッセージ表示
PHP Warnings・Deprecated順番	◯	debug.log無ERROR

すべて◯になるまで Staging 反映禁止。問題が残る場合は Step1 へ戻って該当箇所の修正を繰り返します。

Step2完了。次の出力でStep3「本番切替フェーズ」を解説します。

3. 本番切替フェーズ（ダウンタイム最短15分）

本番サイトを最小限のダウンタイムで切り替える手順です。事前準備と検証が整っていれば、この手順で15分以内に完了できます。

3-1. メンテナンスモードON

手順

プラグイン「WP Maintenance Mode」を有効化し、メンテナンス画面を公開中に設定。

または、public_html/.htaccess の先頭に以下を追加して一時的に全アクセスを制限:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance.html$
RewriteRule ^.*$ /maintenance.html [R=307,L]

確認用に maintenance.html を用意して、メンテナンス画面が正常に表示されることをチェック。

理由

切替中のアクセスでPHPバージョン不一致エラーが出ることを防ぎ、ユーザー体験を保護します。

エラー回避Tips

トグル用管理者IP制限を併用し、限定IPからのみ本番確認できるようにしておくと安心です。

3-2. ServerPanelで PHPバージョン変更 → OPcacheクリア

手順

ServerPanelの［PHP Ver.切替］を開き、本番ドメインを8.xへ切り替え。
同画面の［PHP高速化設定］→［OPcache設定］でキャッシュをクリア。
SSHで php -v を実行し、本番サーバーが8.xに変わったことを確認。

理由

OPcacheに旧バージョンのバイトコードが残っていると、新バージョン切替後も古い処理を実行し、予期せぬ動作を引き起こします。

エラー回避Tips

OPcacheクリア後はサーバー再起動不要ですが、念のため1分程度待ってから次のステップへ。

3-3. 主要ページ５点チェック

手順
以下のURLに管理者ブラウザからアクセスし、エラーや表示崩れがないか確認します:

TOPページ /
固定ページ /about-us など代表的なページ
投稿一覧ページ /blog
投稿詳細ページ /blog/sample-post
決済完了ページまたはカートページ /cart /checkout

理由

ユーザーがよく訪れる代表的なページを優先的に確認し、重大な不具合を早期に検出します。

エラー回避Tips

ブラウザのキャッシュを無効化して確認。開発者ツールの「Disable cache」オプションを使用しましょう。

3-4. 500/502が出た時の「３分ロールバック」手順

手順

すぐにSSH接続し、git タグ pre-php-upgrade をチェックアウト:
```
cd ~/ドメイン/public_html
git checkout pre-php-upgrade
```
ServerPanelでPHPバージョンを7.4に戻す。
OPcacheをクリアし、キャッシュプラグインのキャッシュも削除。
ブラウザキャッシュをクリアし、サイト正常動作を再確認。

理由

重大エラー発生時は迅速に元の動作環境に戻し、影響を最小限に抑えます。

エラー回避Tips

SSH接続情報を踏み台サーバーに記録し、最速で切り戻せるようにしておきます。

3-5. メンテ解除 → 検証ログと比較

手順

メンテナンスモードプラグインを無効化、または.htaccessから制限ルールを削除。
本番のアクセスログと、Step2で取得したStagingのスクリーンショットを比較。
debug.log やQuery Monitor のログをダウンロードし、Error/Warn の増減を確認。

理由

本番解除後に見落としがないか、StagingでOKだった挙動が本番で再現しているかをクロスチェックします。

エラー回避Tips

比較は担当者間でダブルチェックし、ソースコードの差分も git diff で確認しましょう。

Step3完了。次の出力でStep4「切替後72時間モニタリング＆微調整」を解説します。

4. 切替後72時間モニタリング＆微調整

バージョンアップ後の72時間は最もリスクが高い時間帯です。モニタリングと微調整を徹底し、潜在的な不具合を早期にキャッチしましょう。

4-1. New Relic・UptimeRobotでエラー/レスポンス監視

手順

New Relic APMにアプリを登録し、専用エージェントをStagingで動作検証後、本番へ導入。
UptimeRobotで主要URL（TOP／決済完了／問い合わせ送信）を5分間隔で監視設定。
障害発生時はSlack Webhookで #php-upgrade-alert チャンネルへ自動通知。

理由

PHP切替によるパフォーマンス劣化やエラー増加をリアルタイムで把握し、迅速に対応できます。

4-2. WP-CLI cron testで非同期処理の挙動を点検

手順

SSH接続し、以下コマンドでCronイベントのリストと次回実行時刻を確認:
```
wp cron event list --path=~/ドメイン/public_html
```
テスト用イベントを登録し、即実行→エラーが出ないかチェック:
```
wp cron event run test_event --path=~/ドメイン/public_html
```

理由

PHP8以降はCron処理で新しいエラーが出ることがあり、バックグラウンドタスク停止を避けるため事前確認が重要。

4-3. Deprecated通知メール自動化（WP Crontrol + MailPoet）

手順

プラグイン「WP Crontrol」をインストールし、cronフック wp_version_update にフックを追加:

add_action('wp_version_update', function() {
  $logs = file_get_contents(WP_CONTENT_DIR . '/debug.log');
  if(strpos($logs, 'Deprecated') !== false) {
    wp_mail('dev@example.com', 'Deprecated Warning Detected', $logs);
  }
});

MailPoetで宛先リストを作成し、通知メールをHTMLテンプレートで装飾。

理由

目視だけでDeprecatedを監視すると見逃しやすく、継続的な検証に役立つ自動化が欠かせません。

4-4. OPcache/JIT 最適パラメータ調整

手順

php.ini に以下を追加/調整:

opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.jit_buffer_size=100M
jit=1235

PHP-FPMを再起動し、New Relicでレスポンスタイムの改善を確認。

理由

PHP8のJITは適切設定で大幅なパフォーマンス向上をもたらしますが、メモリ不足でエラーになることもあります。

4-5. PHP.ini 推奨設定テンプレ

設定項目	推奨値	説明
memory_limit	256M	大規模プラグイン実行時のメモリ不足防止
max_execution_time	120	長時間処理（決済連携など）秒単位で延長
post_max_size	64M	ファイルアップロードサイズの上限
upload_max_filesize	64M	同上
opcache.validate_timestamps	1	ファイル更新後のキャッシュ自動検証

Step4完了。次の出力でStep5「代表的エラーと即応フローチャート」を解説します。

5. 代表的エラーと即応フローチャート（図解）

以下はPHP8アップデート時に多発する5大エラーへの“まずはこれ”対応フローです。

st=>start: エラー発生
cond1=>condition: Fatal error: Uncaught TypeError
act1=>operation: 型宣言を見直し、キャストを追加
cond2=>condition: Call to undefined function
act2=>operation: 拡張モジュール／use宣言を確認
cond3=>condition: Deprecated: create_function()
act3=>operation: 無名関数に書き換え
cond4=>condition: Cannot modify header
act4=>operation: ob_start()/ob_end_flush()を適切に配置
cond5=>condition: 503 after FPM reload
act5=>operation: pm.max_children等FPM設定調整
e=>end

st->cond1
cond1(yes)->act1->cond2
cond1(no)->cond2
cond2(yes)->act2->cond3
cond2(no)->cond3
cond3(yes)->act3->cond4
cond3(no)->cond4
cond4(yes)->act4->cond5
cond4(no)->cond5
cond5(yes)->act5->e
cond5(no)->e

簡単解説

TypeError → 型指定で厳格になった部分へ柔軟な変換を追加。例：(int)$var。
undefined function → PHP拡張が外れているか、名前空間が合っていないかをチェック。
Deprecated → 旧関数はほぼ代替関数／無名関数で置き換え。
Cannot modify header → 出力バッファリングを整理し、早期にヘッダー送信。
503 FPM → ワーカー数不足やタイムアウト設定を見直し。

6. ケーススタディ３選

6-1. WooCommerce 大規模 EC：7.4→8.1でAPDEX +20%

課題: 決済プラグインが非推奨関数を使い、切替直後は注文画面が落ちる。
対応: Stagingで独自スニペットで置換→本番切替時に即マージ。
結果: 処理速度向上で決済完了までの時間が30%短縮、サイト体験指数(APDEX)が20%改善。

6-2. 会員制 LMS：プラグイン互換地獄を1週間で解決

課題: 複数LMSプラグイン群が8.0非対応でエラー多発。
対応: PHPに合わせたバージョンマップを作成し、順次アップデート→エラーをIssue化し開発者と連携。
結果: 7.4→8.0→8.1の段階的切替で稼働率100%、地獄の検証工数を80%削減。

6-3. メディアサイト（PV100万/日）：段階的ロールアウト＋A/B復旧

課題: 一気に上げると一部テーマでCSS / JS崩壊。
対応: 全トラフィックの10%をバージョン8へ切替し、グループA/Bを分けて検証。問題なしを確認して残りを切替。
結果: 無停止レベルでPHP8.1に移行し、トラフィック100%へ安全に拡大。

7. よくある質問 20（FAQ）

バージョンを一気に上げても大丈夫？
小～中規模のサイトならStaging検証で問題なければ可能ですが、大規模サイトやカスタム要素が多い場合は段階的にアップする方が安全です。
旧バージョンはいつまで使える？
PHP 7.4は2025年11月まで公式サポートがありますが、その後はセキュリティパッチも提供されなくなるため、早めの移行をおすすめします。
CLI版PHPは別に切り替える必要がありますか？
はい。WP-CLIやcronジョブはCLIのPHPバイナリを参照するため、OSレベルでupdate-alternativesやシェルパスを切り替えてください。
同一サーバーでPHP 7.4と8.xを共存できますか？
PHP-FPMのプールを分ければ可能です。各仮想ホストでFPM Poolを指定し、ドメインごとにバージョン運用できます。
WP-CLIはPHP 8.x対応ですか？
最新版にアップデートすれば対応しています。事前にwp cli update --nightlyなどで最新版を適用してください。
必要な拡張モジュールはどうやって確認しますか？
phpinfo()やWordPressのサイトヘルス画面で一覧が確認できます。不足があればServerPanelの「モジュール選択」で追加しましょう。
エラーログはどこを見ればいいですか？
WordPressのwp-content/debug.log、サーバー側の/var/log/error.log（Apache/nginx）を確認してください。
Composer依存ライブラリはどう対応すれば？
composer.jsonの"php": ">=7.4"を">=8.0"に更新し、composer update後にテストを実行します。
Cronバッチ処理が動かない場合は？
WP-CLIで手動実行(wp cron event run --due-now)し、エラー内容を確認。互換性問題が多い箇所を修正します。
OPcacheが反映されないときはどうすれば？
OPCacheのクリア設定を確認し、opcache_reset()を実行、またはServerPanelの「OPcacheクリア機能」を使ってください。
CLIとFPMでバージョン差がある場合の対処は？
システムのphp -vとphpinfo()のPHPバージョンが一致するよう、パス優先度を調整します。
Docker環境でPHPをアップデートする手順は？
DockerfileのFROM php:7.4-fpmをphp:8.1-fpm等に変更し、docker-compose buildで再構築します。
自動テスト（PHPUnit）は必須ですか？
推奨です。プラグインやテーマのユニットテストを通せば、切り替え後の壊れを事前に検知できます。
モノリシックとマイクロサービスで移行方法は違いますか？
マイクロサービスは個別にバージョン管理可能ですが、モノリスはサイト全体を一括で検証・切り替える必要があります。
自作プラグインの互換テスト方法は？
functions.phpと同様にphp -lで構文チェックし、手動で主要機能を動作確認してください。
親テーマ・子テーマの対応手順は？
まず親テーマの互換性を確認後、子テーマを順次検証。問題がなければ一括切り替えできます。
データベースマイグレーションは必要ですか？
コアアップデート後にwp core update-dbを実行し、DBスキーマの更新を適用してください。
メモリ不足エラーが出たらどうする？
php.iniのmemory_limitを増やすか、大量処理を分割し、必要な箇所だけメモリ確保を行います。
型エラーの傾向を検知する方法は？
Query MonitorでTypeErrorをログに出力し、対象関数を絞り込むと効率的です。
さらに詳しい情報はどこで確認できますか？
本記事のAppendix DにあるNotionリンクとGitHubリポジトリに最新情報を随時アップしています。