WordPressメジャー更新——プラグイン非互換への備え

🧩壊れるのは「本体」ではなく「個々のプラグイン」

互換性を守る方針の本体と、個別に作られているプラグインは、性質が違います。

WordPress公式ドキュメントは、「歴史的にWordPressは、バージョン間の後方互換性を維持することで知られてきた」と説明しています。同時に「後方互換性を壊すことがやむを得ない稀なケースもある」とも明記しており、絶対に壊さないという保証ではなく、あくまで維持を優先する方針だと理解しています（WordPress Developer: Backward Compatibility）。つまり「本体のメジャー更新そのもの」が壊れる主因になることは基本的には想定されていません。実際に非互換の問題が起きるのは、多くの場合その方針の外にある個々のプラグイン（開発が止まっている、非推奨のAPIに依存している等）の方だと理解しています。

🛡️それでも更新を止められない理由

WordPressにはLTS（長期サポート版）という概念がありません。

WordPress公式は、「公式にサポートされるのは常に最新のメジャーバージョンのみ」であり、「セキュリティ更新が過去のバージョンに提供されるのはあくまで好意によるものであり、保証や期限はない」「UbuntuのようなLTS版は存在しない」と明記しています（WordPress.org: Supported Versions）。古いバージョンに留まり続けることは、更新の手間を避けているようで、実際にはセキュリティリスクを積み上げていることになります。プラグイン非互換のリスクと、放置のリスクを天秤にかけると、私たちは更新を止めない方を選んでいます。

🔍更新前に確認していること

本番環境でいきなり更新せず、確認できる場を先に用意します。

実際に行っているのは、①本番と同じ構成のステージング環境で先に更新を試す②主要なプラグインが直近で更新されているか（開発が止まっていないか）を事前に確認する③更新前にバックアップを取得し、切り戻せる状態を確保する、という手順です。

②の確認は、WordPress.orgのプラグインページにある「最終更新（Last updated）」の表示を見るところから始めます。目安として、1年以上更新が止まっているプラグインは、次のメジャー更新で問題を起こしやすいという実感があります。同じくプラグインページには「WordPress のバージョン: 〇〇以降でテスト済み」という表示もあり、対象のメジャーバージョンでの動作確認が明言されているかどうかも合わせて見ています。この一手間を省くと、本番更新後にしか非互換に気づけなくなります。

🧭まとめ: 壊れるのはどこかを見極める

整理します。①WordPress本体は互換性を壊さない方針で作られている②壊れるとしたら個々のプラグイン側の問題であることが多い③LTSが存在しないため更新を止めること自体がリスクになる④ステージングでの事前確認とバックアップは更新前の必須手順。

「更新するかどうか」ではなく「どう確認してから更新するか」を設計しておくことが、非互換への一番の備えだと考えています。