独立サイトのPHPバージョンアップ：互換性チェック、拡張機能のインストール、性能向上
1. PHPバージョンが独立サイトの性能に影響する理由
WordPressはPHPで書かれており、ページリクエストのたびにPHPインタプリタが動いて、コードをマシンが実行できる命令に翻訳します。PHPバージョンが新しいほど翻訳速度が上がります。PHP 8.xは7.4と比べてOPcacheの改善、JITコンパイル、メモリ管理の最適化など多くの低レイヤー最適化が施されており、同じコードが8.2では7.4より約2倍速く動きます。
この性能向上は独立サイトで直接体感できます。PHP 7.4でLCPが3.5秒だったサイトが、8.2に上げてOPcacheを有効にするとLCPは2秒前後まで下がり、Core Web Vitalsは赤から緑に変わります。テーマを変える必要も、プラグインを替える必要も、キャッシュを追加する必要もなく、PHPバージョンを変えるだけでこの効果が得られます。だからこそ運用チームは少なくとも2年に一度はPHPバージョンを上げることを勧めます。
| PHPバージョン | リリース時期 | セキュリティサポート終了 | 7.4比の性能 | 独立サイトでの推奨 |
|---|---|---|---|---|
| PHP 5.6以下 | 2014年以前 | とっくに終了 | 基準以下 | 絶対に使わない |
| PHP 7.0から7.3 | 2015〜2018年 | 終了済み | 約0.8倍 | 早急にアップグレード |
| PHP 7.4 | 2019年 | 2022年終了 | 基準1.0 | 過渡期のバージョン、早めに上げる |
| PHP 8.0 | 2020年 | 2023年終了 | 約1.5倍 | 使えるが長期利用は非推奨 |
| PHP 8.1 | 2021年 | 2025年末 | 約1.8倍 | 推奨、安定 |
| PHP 8.2 | 2022年 | 2026年末 | 約2.0倍 | 推奨、最新安定版 |
多くの独立サイトがまだPHP 7.4や7.3で動いています。理由は「ずっと問題なく動いているから触りたくない」です。しかし7.4は2022年11月以降セキュリティパッチが提供されておらず、新しい脆弱性が見つかっても修正されません。海外向けサイトにとって、セキュリティ更新のないPHPバージョンで動かすことは、時間とともにハッキングリスクが高まることを意味します。サイトがハッキングされた後の対処フローはサイトがハッキングされた後の対処、セキュリティ強化とバックアップはサイトのバックアップと復元演習。
2. 互換性チェック：アップグレード前に必ずやる3つのこと
PHPアップグレードの最大のリスクは性能ではなく互換性です。PHP 8.xでは構文に破壊的な変更が加えられました。たとえば一部の古い関数が廃止され、型の厳格さが変わり、従来の挙動が変わったものもあります。テーマやプラグインがこうした廃止された書き方を使っていると、アップグレード後にサイトが真っ白になり、管理画面にも入れなくなります。
アップグレード前に必ずやることは3つあります。1つ目は、すべてのプラグインとテーマを最新版に更新すること。古いバージョンは新しいPHPと互換性がないことが多く、新しいバージョンでは通常すでに修正されています。2つ目は、PHP Compatibility Checkerなどのプラグインでサイト全体のコードをスキャンし、どのファイルが互換性のない書き方を使っているか確認すること。3つ目は、staging環境でPHPバージョンを切り替え、主要な機能をすべて一通り動かしてみることです。
| チェック項目 | チェック方法 | 合格基準 | 未対応時の処理 |
|---|---|---|---|
| プラグイン互換性 | PHP Compatibility Checkerでスキャン | すべてのプラグインに致命的エラーなし | 代替プラグインを探すか作者に連絡 |
| テーマ互換性 | 同様にテーマディレクトリをスキャン | テーマに廃止関数の呼び出しなし | テーマを変更するか作者の更新を待つ |
| WordPress本体のバージョン | 管理画面でWPバージョンを確認 | PHP 8.2に対応するのはWP 6.0以上 | 先にWP本体をアップグレード |
| データベース拡張 | phpinfoでmysqliの有無を確認 | mysqliが有効 | mysqli拡張をインストール |
| カスタムコード | 子テーマとカスタムプラグインをスキャン | 廃止関数なし | 手動でコードを修正 |
事例：あるB2Bサイトが2019年の古いフォームプラグインを使っていたとします。このプラグインはPHP 8.1でエラーを出します。アップグレード前にCompatibility Checkerでスキャンすると、このプラグインがmysql_*系の関数（PHP 7.0で廃止）を使っていることが分かりました。この場合は無理にPHPバージョンを上げず、まず代替のフォームプラグイン（WPFormsやFluent Formsなど）を探してフォームを移行し、それからPHPをアップグレードします。craterが海外向けサイトでプラグイン互換性にどう対応しているかはこちらcraterの技術スタックと4つの自社開発プラグイン。
直感に反する判断：WordPress管理画面の「サイトヘルス」に表示されるPHP互換性の警告は、しばしば正確ではありません。これは現在インストールされているプラグインのバージョンしかチェックしておらず、あるプラグインが最新版でも作者が互換性テストを更新していなければ、管理画面は互換と表示したままです。正しい方法は、自分でスキャンツールを実行し、さらにstaging環境で実際に動かしてみることです。管理画面の表示だけを信じてはいけません。
3. PHPバージョンの選択：8.1か8.2か
どのバージョンにアップグレードするかは、2つの要素で決まります。セキュリティサポートがいつまで続くか、そしてプラグインエコシステムの互換性です。PHP 8.1のセキュリティサポートは2025年末まで、PHP 8.2は2026年末までです。ほとんどの独立系サイトにとって、8.2のほうがより安全な選択です。性能が最も良く、セキュリティサポート期間も最も長いからです。ただし、重要なプラグインの1つが8.1までしか対応していないと明記している場合は、まず8.1にアップグレードし、プラグインが更新されてから8.2に上げましょう。
バージョンを飛ばしてアップグレードしないでください。7.4から8.2へ直接上げると、間に2つのメジャーバージョンをまたぐことになり、非推奨関数や構文変更が積み重なって、1つずつ上げるより問題が起きる確率がずっと高くなります。正しい手順は7.4→8.0→8.1→8.2で、1バージョン上げるごとにstagingでテストし、問題がなければ次へ進みます。
| シナリオ | おすすめバージョン | 理由 | 注意点 |
|---|---|---|---|
| サイトを立ち上げたばかり | PHP 8.2 | 最新安定版で性能が最も良い | すべてのプラグインが8.2に対応しているか確認 |
| 古いサイトが7.4で稼働中 | まず8.1、次に8.2 | 1つずつ上げてリスクを抑える | 各バージョンでstagingテストを1回 |
| プラグインの対応が古い | PHP 8.0または8.1 | 互換性がより高い | プラグインの更新を待ってから上げる |
| ECサイト | PHP 8.1 | エコシステムが最も成熟 | 8.2では一部の決済プラグインが非対応 |
| 純粋なブログサイト | PHP 8.2 | プラグインが少なく互換性が良い | 8.2へ直接アップグレード |
例：プラグインが5つだけのコンテンツサイト（Yoast、WP Rocket、WPForms、UpdraftPlus、Wordfence）の場合、これらの主要プラグインはすべてPHP 8.2に対応しています。このケースではstagingで8.2へ直接上げてテストし、問題がなければ本番へ反映します。ただしWooCommerceと十数のECプラグインを使っているサイトなら、まず8.1で止めておくことをおすすめします。8.2が出たばかりの頃は、多くの決済・物流プラグインがまだ対応していなかったからです。
4. 拡張のインストール：OPcacheと主要拡張
PHPのバージョンを上げてもOPcacheを入れなければ、性能の恩恵は半分しか受けられません。OPcacheはPHPがコンパイルしたバイトコードをメモリに保存し、次に同じコードを実行するときはメモリから直接読み込むので、再コンパイルが不要になります。OPcacheを有効にするとPHPの実行時間は50%以上短縮でき、これは7.4から8.0へ上げるより大きな効果です。
OPcache以外にも、独立サイトにはいくつかの基本拡張が必要です。mysqli（データベース接続、WordPressで必須）、gdまたはimagick（画像処理、メディアライブラリで必要）、intl（多言語とローカライズ）、mbstring（マルチバイト文字列処理、中国語サイトで必要）。これらの拡張はほとんどのホストで標準搭載されていますが、共有ホストでは手動で有効化が必要な場合があります。
| 拡張 | 役割 | 必須かどうか | 設定の推奨 |
|---|---|---|---|
| OPcache | PHPバイトコードキャッシュ | 必須、性能が倍に | memory=256MB, revalidate_freq=60 |
| mysqli | MySQLデータベース接続 | 必須、WPコアが依存 | デフォルトでOK |
| gd/imagick | 画像処理 | メディアライブラリで必須 | imagickはgdより速い |
| intl | ローカライズと多言語 | 多言語サイトは必須 | デフォルトでOK |
| mbstring | マルチバイト文字列 | 中国語サイトで必須 | デフォルトでOK |
| curl | 外部HTTPリクエスト | 必須、REST APIが依存 | デフォルトでOK |
| xml | XMLパース | 必須、RSSとsitemap | デフォルトでOK |
OPcacheの設定ポイント：opcache.memory_consumptionは256（MB）、opcache.revalidate_freqは60（秒）に設定します。これはコード変更後60秒で再チェックするという意味です。開発環境ならrevalidate_freqを0にして毎回のリクエストで再コンパイルし、本番環境なら60秒にして性能と更新の即時性を両立させます。PHPのメモリ上限（memory_limit）は256M以上を推奨し、プラグインが多いサイトは512Mにします。
OPcacheとページキャッシュは別レイヤーです。混同しないでください。ページキャッシュはHTMLをファイルとして保存し、OPcacheはPHPバイトコードをメモリに保存します。この2つを組み合わせて初めてLCPを最小限に抑えられます。キャッシュのレイヤー別設定は独立サイトの3層キャッシュ戦略、性能指標の達成ラインはCore Web Vitalsの最適化。
5. アップグレード手順とロールバック方法
本番環境でPHPバージョンをアップグレードする場合は、必ずアクセスの少ない時間帯（日本時間の午前2時から4時）を選び、事前にロールバック方法を用意してください。作業中に問題が起きても、5分以内に旧バージョンへ戻せるようにします。日中に作業すると、問題発生時に訪問者のアクセスや問い合わせに影響します。
| ステップ | 操作 | 所要時間 | ロールバック方法 |
|---|---|---|---|
| 1. サイト全体をバックアップ | ファイルとデータベースを完全にバックアップ | 10分から30分 | バックアップファイルは最低7日間保管 |
| 2. アクセスの少ない時間帯を選ぶ | 日本時間の午前2時から4時 | —— | アクセスログを見て判断 |
| 3. PHPバージョンを切り替え | ホストの管理画面またはSSHで切り替え | 1分から5分 | 旧バージョンへはワンクリックで戻せる |
| 4. 主要な導線をテスト | トップページ、商品ページ、フォーム送信 | 10分 | 真っ白な画面になったら旧バージョンへ戻す |
| 5. 30分間観察 | エラーログとアクセス数を確認 | 30分 | エラーが出たらすぐロールバック |
| 6. OPcacheをクリア | PHP-FPMまたはWebサーバーを再起動 | 1分 | —— |
例：宝塔パネルやcPanelでPHPを7.4から8.1に切り替え、トップページを更新したら真っ白な画面になったとします。慌てないでください。まず7.4に戻すのが最優先です。ほとんどのホスト管理画面ではPHPバージョンの切り替えはクリック1回で、10秒で戻せます。その後エラーログを見て、どのプラグインがエラーを出しているか特定し、解決してから再試行します。真っ白な画面のまま何度も試すのはやめてください。訪問者にエラーページを見せ続けることになります。
アップグレード後は1週間観察します。見る指標は2つです。エラーログにPHP Fatal Errorが出ていないか、Lighthouseのスコアが上がったか。エラーログがきれいで、LCPが3.5秒から2秒以内に短縮されていればアップグレードは成功です。新しいPHP警告が出た場合は、まずどこかのプラグインの非推奨（deprecated）通知かどうかを確認します。この種の警告は機能に影響しませんが記録しておき、次回のプラグイン更新時に対応します。日々の保守ではPHPバージョンの確認は必須項目です。詳しくは公式サイト保守で毎月やる6つのこと。監視とアラートについてはサイト監視とアラート。
FAQ よくある質問
WordPressの独立サイトはどのPHPバージョンを使うべき？
PHPをアップグレードしたらサイトが真っ白になった場合は？
OPcacheとは何か、必ず有効にすべきか？
PHPバージョンは一気に飛ばしてアップグレードできるか？
PHPアップグレード前に必ずバックアップが必要か？
PHPアップグレード後にLCPが変わらないのは正常か？
最後に
PHPバージョンアップグレードで最大の障害は技術ではなく、心理的な「動かすのが怖い」という気持ちです。多くのチームのサイトは7.4で3年間動いており、「問題なく動いている」状態が続いています。しかしある時プラグイン更新後に画面が真っ白になったり、ハッキングされて初めてPHPを上げようと思い出すのです。実際、PHPアップグレードはすべての性能最適化の中で最も投資が小さく効果が最大です。業務コードを変更する必要はなく、ホストパネルでバージョンを切り替えるクリック一つと、主要機能を一時間テストするだけです。
導入は3ステップ。まずサイト全体とデータベースをバックアップし、Compatibility Checkerでプラグインとテーマの互換性を確認します。次にステージング環境で1バージョンずつアップグレードし（7.4→8.0→8.1→8.2）、各バージョンで主要な導線をテストします。最後にアクセスの少ない時間帯に本番へ反映し、30分間は様子を見て、問題が出たらすぐ切り戻します。ここまでやれば、サイトのパフォーマンスは2倍になり、セキュリティパッチも当たります。
覚えておきたい一言。PHPのアップグレードは自社サイトで最も費用対効果の高い高速化施策です。7.4から8.2に上げれば2倍速くなりますが、条件は先に互換性の確認を終えること。古いプラグインが1つあるだけで画面が真っ白になります。