先月、複数のクライアントのサイトで「PHP 8.1がもうすぐEOLですよ」という話が重なりました。
それ自体は以前から分かっていたことなのですが、いざ複数案件で同時に向き合うと、「延命するか、乗り換えるか」という判断をそれぞれ真剣にやらなければならなくて、結果的に自分の中での整理が進みました。その整理を書き残しておきます。
PHPのEOLは「その日に壊れる」わけではない
まずここの誤解を解いておきたいのですが、PHPのサポートが終了したからといって、翌日からサイトが動かなくなるわけではありません。動くは動く。
問題はもっと静かにやってきます。
PHPのEOLとは「セキュリティパッチの提供が終わる」ことを意味します。つまり、その後に脆弱性が発見されても修正版が出ない。ホスティング側も対応を迫られて、古いPHPバージョンのサポートを段階的に縮小していきます。国内のレンタルサーバーサービスでは、EOL後1〜2年を目安にして該当バージョンを選択不可にするケースが多いと考えています。
つまり「今は動いているが、ある日突然サーバー移行か強制アップグレードを迫られる」という状況になるわけです。その日がいつ来るか分からない、という不確実性を抱えながら運用し続けることになる。運用を考えると、これはかなりきつい状態です。
PHPのサポートライフサイクルは通常2年です。
PHP 8.1: Active Support → 2024-11-25、Security Support → 2026-11-25
PHP 8.2: Active Support → 2025-12-08、Security Support → 2027-12-08
PHP 8.3: Active Support → 2026-11-23（予定）、Security Support → 2028-11-23（予定）上のスケジュールを見ると、今まさに8.1からの移行判断が必要な時期であることが分かります。8.2に上げれば1年半は安心できますが、2年後にはまた同じ判断が待っています。
WordPressの互換性問題は「段階的に壊れる」
PHPを上げれば万事解決、とはいかないのが現実です。
WordPressでは、コア・PHP・プラグイン・テーマの4つが絡み合っています。これらのバージョンを上げる際、壊れる順序というものがあって、私が複数案件で観察した経験では、だいたいこういう順番で問題が顕在化します。
- プラグインの非推奨関数が出る（WordPressのコアをアップデートした直後）
- テーマのカスタムコードがPHP 8.xの型チェック厳格化に引っかかる
- 「実はずっと動いていなかった」機能がバージョンアップで死ぬ（これが一番困る）
特に3番目は厄介です。ログを見てみると「あれ、このフォームのメール送信、半年前から止まってるな」みたいなことが普通にあります。クライアントもその機能をほとんど使っていないから気づいていない、というパターンです。正直なところ、アップグレード作業中に初めて発覚することも少なくありません。
テスト環境を用意してバージョンアップを試みるたびに、「このプラグインだけ対応バージョンが古くて更新が止まっている」という問題にぶつかることがあります。プラグインの開発者がメンテナンスを放棄しているケースもあり、そうなると代替プラグインへの移行コストが発生する。「アップグレードしようと思ったら、想定外の地雷を踏んだ」という経験は、WordPress案件では珍しくありません。
選択肢A：PHP/WPのアップグレードで延命する
まず「このままWordPressで行く」前提でのアップグレードについてです。
作業範囲は概ねこんな感じになります。
| 工程 | 内容 | おおよその工数（中規模サイト） |
|---|---|---|
| 事前調査 | プラグイン・テーマの互換性チェック、廃止関数の洗い出し | 3〜5時間 |
| テスト環境構築 | 本番と同じ状態で新バージョンを検証 | 2〜4時間 |
| 互換性修正 | プラグイン更新・コード修正・代替対応 | 4〜20時間（個体差大） |
| 本番適用 | 作業＋確認＋切り戻し準備 | 2〜4時間 |
| 検収 | 主要機能の動作確認 | 1〜3時間 |
工数の幅が大きい理由は「プラグイン・テーマのカスタマイズ度合い」に強く依存するためです。スタンダードなプラグイン構成でカスタマイズが少なければ10時間以内で終わることが多い。一方、開発会社が独自にカスタムした構成だと、30〜50時間かかることもあります。
費用感の目安としては、エンジニア時間単価を仮に8,000円/時とすると、最小で8万円程度、カスタマイズが多いと30〜40万円規模になることもある。これに月次保守費用が乗ってくる。
# WP-CLIを使った一括アップデート（注意: 必ずテスト環境で先に実行すること）
wp core update
wp plugin update --all
wp theme update --all
# アップデート後に非推奨ウォーニングを確認
wp eval 'error_reporting(E_ALL);'このスクリプトは手順を示すためのもので、実際には各プラグインの更新前後で動作確認をはさみながら進めます。なおWP-CLIが使えない環境もあるので、その場合は管理画面からの手動更新になります（改善の余地あり：実際の案件ではこのスクリプトを環境ごとに調整していますが、汎用的なチェックリスト化はまだできていません）。
アップグレードで延命する選択は、コンテンツが多くて移行コストが高い場合、WooCommerceなど強い依存関係があるプラグインを使っている場合、更新頻度が高くWordPressのエコシステムを活かしている場合に向いていると考えています。
選択肢B：静的構成へ乗り換える
「この機会に根本から変える」という判断も十分合理的です。
静的構成（AstroやHugoなど）へ移行した場合、PHPもWordPressも関係なくなります。EOLサイクルに毎回向き合うコストがなくなる。これは長期的に見るとかなり大きいと考えています。
コストの比較をざっくり並べるとこうなります。
| 項目 | WordPress延命 | 静的化移行 |
|---|---|---|
| 初期費用 | 8〜40万円（アップグレード作業） | 30〜80万円（移行コスト） |
| 月次費用 | 1〜3万円（保守・監視） | 数百〜数千円（S3＋CloudFront） |
| 次のEOL対応 | 2〜3年後に再発生 | 原則不要 |
| セキュリティリスク | プラグイン依存で継続的に存在 | 動的処理がなく大幅に低減 |
今思えば、「延命コストが2年後にまた発生する」という事実を最初から含めて比較していなかったことが、判断を曇らせていたかもしれません。先送りすると次回の対応費用も発生する。それを足した合計で比べる必要があります。
ただ、静的化が合わないケースもあります。会員機能・ECカート・予約システムなど、本質的に動的な処理が必要な場合です。フォームはFormspreeやSendGridで代替できますが、リアルタイムの在庫管理などはさすがに無理です。
乗り換えを選択した場合の作業フローは概ねこうなります。
フェーズ1: 要件整理（1〜2週間）
└ 動的機能の洗い出し → 代替案の検討 → 静的化可能かどうかの判断
フェーズ2: 設計（1〜2週間）
└ サイト構造設計、Astroプロジェクト構築、コンテンツ移行方針決定
フェーズ3: 実装（2〜4週間）
└ ページ実装、コンテンツ移行、フォーム代替実装
フェーズ4: 移行・検収（1週間）
└ DNS切替、旧サイト停止判断、SEO影響確認リダイレクト設計と画像移行がボトルネックになりやすいです。特に記事数が多いサイトでは、URLが大きく変わる場合の301リダイレクト対応に想定より時間がかかることが多い。
どちらを選ぶかの判断基準
最終的にはこの2軸で見ると判断しやすいと考えています。
動的機能の有無：会員管理・EC・予約など本質的に動的な機能があるなら静的化は困難。なければ静的化の候補に入る。
保守体制の持続性：「毎回のEOL対応を社内エンジニアが担えるか」「外注コストを継続的に出せるか」という問いです。月次保守コストと2〜3年ごとのアップグレードコストが永続的に発生し続けることを許容できるかどうか。
どちらかが必ずしも正解ということはありませんが、「先送りした場合にいつ・何が起きるか」を明確にした上で判断することが重要です。
振り返って
今回複数の案件を同時期に整理して気づいたのは、「選択肢を並べること」自体がクライアントに価値を提供している場面が意外と多いということです。
「延命するとこのコストで、次のEOLまで2〜3年。乗り換えるとこのコストで、EOL対応は原則不要になる」と並べると、自分で判断できる方が多い。エンジニア側が先に結論を出そうとすると、クライアントの事情を見誤ることがあります。
まだ完全には言語化できていない判断ポイントも残っているので、案件を重ねながら引き続き整理していきたいと思っています。