背景

D学園様は、入学希望者向けの願書請求フォーム、オープンキャンパス案内、年間行事カレンダーをWordPressサイトで運用されていました。

しかし、サイトで稼働していたPHPは5.6系。2018年12月31日に公式サポートが終了して以降、実に6年以上にわたってセキュリティパッチが適用されない状態で運用が続いていました。サーバー会社から「PHP5.6は提供終了が迫っている、至急PHP8.x系へ更新を」という通知を受けて、対応が急務となりました。

初期状態の問題点

  • PHPバージョン：5.6系（2018年末にEOL、以降サポート停止）
  • WordPress本体：4.x系のまま長期運用（既にEOL、管理画面も古い）
  • カスタム実装：独自テーマとプラグイン追加が多く、互換性不明
  • フォーム運用：願書請求フォームが常時稼働必須
  • 保守状況：「更新すると壊れる」懸念から、10年近くアップデートを先送り

教育機関ならではの運用制約

教育機関サイトは、一般的なコーポレートサイトよりも「止められない時期」が明確です。

  • 願書請求が増える秋〜冬（出願前）のアクセスピーク
  • オープンキャンパス告知の更新が集中する時期
  • 学校行事・入試関連情報の公開スケジュールが固定

このため、単純な一括更新ではなく、停止リスクを最小化した多段階の移行計画が必要でした。

実施したバージョンアップ施策

1. 現状分析とアップグレード方針の確定

本番構成を複製したステージング環境を作成し、テーマ・プラグイン・フォーム導線の依存関係を全て洗い出しました。

確認した技術要件：

  • PHP 5.6は2018年末EOL、PHP 7.4も2022年末EOLのため、到達目標はPHP 8.2
  • PHP 5.6から8.2への直接ジャンプは非互換の塊。中間バージョン（PHP 7.4）を経由する多段階移行が必要
  • WordPress 4.x系も5.x系を飛ばさず、4.x → 5.x → 6.x の段階更新が安全
  • 独自テーマはmysql_*系の非推奨関数、PHP 7以降で削除された関数を複数使用

2. ステージング環境での互換性検証

本番同等のデータで検証を行い、主要ページと重要導線を重点的に確認しました。

検証対象：
- 願書請求フォーム（入力・確認・送信・自動返信）
- 行事案内ページ（カスタム投稿・検索・一覧）
- お知らせ更新フロー（管理画面からの投稿）
- 主要プラグインの管理画面挙動
- テーマ内のカスタム関数（独自の問い合わせ処理など）

判定結果：
非互換プラグイン6点を確認（PHP 7以上で致命的エラーまたは機能不全）
独自テーマ内でPHP 7以降に削除された関数の使用を複数検出

3. 非互換プラグイン6点を代替へ置き換え

既に更新が止まっていたり、PHP新バージョンに対応しないプラグインを、同等機能を持つ保守継続中のプラグインへ段階的に置き換えました。

  • 各プラグインの既存データ移行手順を事前作成
  • URL構造・入力項目・通知メール仕様を維持
  • 置き換え後にフォーム送信テストを複数パターンで実施
  • 古いキャッシュ系プラグインは最新世代に刷新

4. 独自テーマの書き直し

PHP 5.6時代に書かれた独自テーマは、部分修正では対応しきれず、核となる処理を段階的に書き直しました。

主な修正：
- 削除済みの mysql_* 系関数を wpdb・WP_Query に置き換え
- ereg_*、split() など削除済み関数を preg_*、explode() に置換
- 型の不一致で致命的エラーとなる処理をリファクタ
- PHP 7以降で必要な引数型宣言を導入
- null扱いが曖昧な条件分岐を明確化

結果：
見た目・導線を維持したまま、PHP 8.2でもエラーゼロで動作

5. 多段階アップグレードの実施（PHP 5.6 → 7.4 → 8.2）

不具合切り分けを容易にするため、以下の順で段階的に実施しました。一括では絶対に行わない運用を徹底。

  1. WordPressを4.x系から5.x系へ更新（段階的に複数マイナーを経由）
  2. プラグイン・テーマを中間互換版へ統一
  3. PHPを5.6から7.4へ切り替え（第1段階）
  4. ステージング・本番の両方で動作確認、数日間の安定稼働を確認
  5. WordPressを5.x系から6.x系へ更新
  6. PHPを7.4から8.2へ切り替え（第2段階）
  7. キャッシュ再構築と動作確認
  8. フォーム送信テストと監視強化

作業は深夜帯に限定し、各段階の間に数日〜1週間の安定稼働期間を設けて、約3ヶ月かけて慎重に進めました。

6. リリース後の監視と即応体制

各段階のリリース後72時間は重点監視期間とし、フォーム送信ログ・エラーログ・表示速度を継続確認しました。

  • 主要ページの死活監視
  • フォーム送信成功率のモニタリング
  • PHPエラー通知のリアルタイム確認
  • 切り戻し手順の事前準備（段階ごとにリストア可能な状態を維持）

成果

システム指標の改善

指標 改善前 改善後 変化
PHPバージョン 5.6（2018年末EOL） 8.2 サポート対象へ完全復帰
WordPressバージョン 4.x系（EOL） 6.x系 最新世代へ更新
主要ページ表示速度 約3.5秒 約1.0秒 約71%改善
セキュリティアラート件数（月次） 32件 5件 約84%減少

運用面の改善

  • ✅ 3ヶ月の移行期間中、願書請求フォームを一度も停止せず
  • ✅ サーバー会社からの強制停止リスクを完全回避
  • ✅ 行事案内・入試情報の更新業務を継続
  • ✅ 10年近く続いたアップデート忌避状態を解消し、定期更新体制に移行
  • ✅ PHP 8.2のJIT最適化・エンジン改善により、サーバー負荷も軽減

お客様の声

「サーバー会社から更新期限の連絡が来ても、正直どこから手を付けるべきか分かりませんでした。『PHPが6年以上サポート切れ』と言われて初めて事の深刻さを理解したくらいです。願書請求の時期に止められないという前提で、3ヶ月かけて段階的に進めていただけたのが非常に助かりました。移行後は表示も見違えるほど速くなり、運用担当としての不安が大きく減りました。」

— D学園様 広報ご担当者様

継続的な改善

移行完了後は、以下を継続して運用しています。

  • 月次のWordPress・プラグイン更新
  • 入試シーズン前の事前互換性チェック
  • フォーム疎通テストの定期実施
  • エラーログとセキュリティ通知の定点監視

まとめ

PHP 5.6のような古いバージョンからのアップグレードは、「一括で更新すれば終わる」という発想では必ず失敗します。更新の本質は“変える勇気”ではなく“変えても事業が止まらない設計”です。

今回のケースでは、PHP 5.6 → 7.4 → 8.2 の多段階移行と、ステージング検証を徹底することで、願書請求などの重要導線を維持したままPHP 8.2・WordPress 6.xへの移行を実現しました。結果として、停止リスクの回避だけでなく、表示速度と運用安全性の両面で大幅な改善につながっています。