WordPressを更新したい。でも、画面が開かなくなったら困る。以前入れたプラグインも、いま何に使っているのか全部は分からない。
不正アクセスや情報漏えいの話を聞いて不安になっても、この状態では更新ボタンを押しにくいと思います。サイトは動いているので、ひとまずそのままにする。その間にも、修正を適用する必要のある部品が残っていきます。
当社がサイトの保守で重く見るのは、更新や停止の影響を説明できなくなることです。便利な機能を足すときに、何を管理し続けることになるのか。そこまで含めて、仕組みを選びたいと考えています。
本稿は保守・移行の知見を一般化した説明です。構成とPHP・WordPressのバージョンは説明用の仮定で、特定サイトの調査結果を示しません。公開済みの脆弱性やサポート期限は、出典に基づく事実として扱います。
以前は便利だったプラグインが、いまも必要とは限らない
ページを編集しやすくする。画像を並べる。フォームを設置する。WordPressには、やりたいことを短い手順で実現できるプラグインが数多くあります。
導入した時点では、必要な判断だったかもしれません。ただ、運用が変わっても、プラグインは自分から片付いてくれません。別の仕組みへ切り替えたあとも残っていたり、一部の古いページだけで使われていたりします。
追加するほど、更新や互換性を確かめる対象も増えます。同じ役割の部品が重なると、設定の上書きやブラウザ側の処理の競合が、不具合の要因になる場合もあります。
ここで、数だけを減らそうとすると別の問題が起きます。見た目に出ないプラグインでも、メールの配送、転送、バックアップなどを担っている場合があるからです。反対に、少数の導入でも、重要な機能の保守が止まっていれば確認を急ぐ必要があります。
当社で保守を進めるなら、まず次の内容を一覧にします。
| 残す記録 | 確かめること |
|---|---|
| 現在の役割 | どのページや仕事で、何をしているか |
| 依存する部品 | テーマ、ほかのプラグイン、PHPとの組み合わせ |
| 保守と更新 | 修正が提供されるか、更新を受け取れる契約・取得方法か |
| 保持するデータ | 停止や削除で、設定・受付記録などが失われないか |
| 担当と判断 | 誰が確認し、更新・代替・撤去のどれを進めるか |
「何となく残す」を、必要性と担当が分かる記録へ変える作業です。画面に表示される通常のプラグインに加え、サーバー側で常時読み込む追加処理や独自改修も、保守担当者に確認します。
無効化と削除も区別します。無効化してもファイルは残り、プラグインの作りによっては直接アクセスできる処理が残る場合があります。WordPress公式の保護指針も、使わないプラグインの削除を勧めています。WordPress公式の保護指針（新しいタブで開きます）
ただし、削除時に設定や専用のデータを消す仕組みを持つプラグインもあります。必要なデータと依存先を確認し、バックアップを確保してから進めます。「使っていなさそう」という印象だけでの一括削除は避けたいところです。WordPress公式のアンインストールの説明（新しいタブで開きます）
「更新したら開けなくなる」を、確認できる問題に分ける
更新後に画面が開かなくなる、表示が崩れる、編集できなくなる。こうした問題には、PHPとの互換性、テーマの独自改修、プラグイン間の依存、ブラウザで動く処理の競合など、異なる原因が考えられます。
更新直後に起きたという時間の関係だけで、どの部品に原因があるかまでは決まりません。WordPress公式も、PHPを更新する前にテーマやプラグインの互換性を確かめるよう案内しています。WordPress公式のPHP更新ガイド（新しいタブで開きます）
本番のボタンを押して結果を待つ前に、次の準備をします。
- 現在の構成と戻す方法を残す。 ファイル、データベース、設定、必要な画像・資料を一組として保存し、本番と分離した場所で復元できるか確かめる。
- 検証環境で更新の組み合わせを試す。 PHPの設定やデータベースを本番と共有していないかも確認する。複製した個人情報の扱い、メール送信、外部サービスへの連携を制限する。
- 変更と結果を対応させる。 提供元の依存条件に沿って更新し、何を変えた段階で問題が出たかを記録する。更新順序は、実際の組み合わせから決める。
- 必要な仕事が続くか確かめる。 パソコン・スマートフォンの表示に加え、編集、検索、リンク、フォームの受付・通知を確認する。
バックアップについては、保存したという表示だけで完了にしません。WordPressの復元には、通常、ファイルとデータベースの両方が必要です。プログラムだけを前の版へ戻しても、更新後のデータ構造と合わないことがあります。WordPress公式のバックアップの説明（新しいタブで開きます）、更新と差戻しの注意点（新しいタブで開きます）
本番で復旧する場合には、バックアップ取得後に入った受付データなども保全します。以前の状態へ戻せたとしても、そこに残る脆弱性への対処は必要です。重大な問題の悪用が公表されている場合は、通常の更新予定を待たず、保守担当者と修正や一時的な制限を判断します。
WordPress本体の更新と、PHP・プラグインの保守を分ける
説明用に、WordPress 6.2.xとPHP 8.0.xを使う構成を考えます。この組み合わせは仮定であり、実在サイトの構成や推奨する更新先ではありません。
PHP 8.0の公式サポートは、2023年11月26日に終了しています。動いていることに加えて、修正が届く状態かを確認する必要があります。提供元による追加保守がある場合は、その対象と期限も確かめます。PHP公式のサポート終了一覧（新しいタブで開きます）
一方、WordPress本体は、系列が古いという理由だけで「何年も一度も更新していない」と決めつけられません。公式のサポート対象は最新版ですが、過去の版へ重要な修正が提供される場合があります。それを、旧系列の保守が今後も保証されるという意味には受け取れません。WordPress公式のセキュリティ方針（新しいタブで開きます）
本体に修正が入っていても、テーマ、プラグイン、PHP、サーバー側のソフトウェアまで更新されたことにはなりません。それぞれの実際の版、修正、保守期限を確かめます。
開発が止まった部品も、方針を読み分けます。新機能の開発停止、互換性確認の停止、セキュリティ修正の終了では意味が違います。必要な機能を引き継げる代替先と、切り替える時期を決めておくことが、更新できる状態を保つための準備になります。
Elementorの脆弱性は、製品と使い方まで照合する
Elementorを調べる場合は、無料版、Pro版、別会社が提供する追加機能を分けます。似た名前で画面上も一緒に使えても、修正する製品と、問題が成立する条件は同じとは限りません。
公開情報の例として、Elementor Proには、ファイル受付の検証不備によって不正なファイルをアップロードされる脆弱性が報告されています。Wordfenceの報告では、影響を受ける未修正の版で、必須ではないファイル添付欄を含むProのフォームを公開していることが条件です。条件がそろうと、ログインしていない第三者によるコード実行やサイトの乗っ取りにつながり得ます。発見・分析側による報告（CVE-2026-32475）（新しいタブで開きます）
この例で確認するのは、導入の有無だけではありません。実際に動く版と修正状況、該当するフォーム機能、公開範囲、必要な保護を対応させます。修正履歴には無料版とPro版の記録が並ぶ場合があるため、対象製品も読み違えないようにします。Elementor公式の更新履歴（新しいタブで開きます）
また、公開ページのCSSやJavaScriptのURLに付く版番号は、調査の手掛かりです。キャッシュや個別ライブラリの番号の場合もあり、それだけでサーバー側の実コードや修正状況は確定できません。
当社では確認できた表示、既知の問題との照合候補、内部での確認が残る項目を分けて記録します。脆弱性の対象かもしれないことと、実際に侵入や情報流出が起きた証拠も区別します。危険性を大きく言い切ると、必要な対策の順序まで誤りかねません。
管理画面とトップページだけでは、運用を確かめきれない
更新の確認では、管理画面とトップページに加え、公開フォームや追加機能、外部連携も対象にします。フォームは入力画面の表示だけで終えず、受付処理、記録の保存、管理者への通知、自動返信や資料の案内まで確かめます。
認証・権限・公開範囲の日常点検と、不正アクセスが疑われる場合の初動は、WordPressの不正ログイン・不正アクセス対策に整理しています。
WordPressを使わなくても、ブラウザから更新できる
ここまで確認すると、「保守対象を減らしたいけれど、自分で記事を更新する便利さは残したい」という考えが出てきます。その選択肢として、当社が構築しているのが、EmDashを記事管理の基盤にしたKaizen CMSです。
EmDashはAstro向けのCMSで、ブラウザの管理画面から記事や画像を扱えます。WordPressやPHPを実行する仕組みではありません。サイトのデザインや表示は、Astro側で実装します。EmDash公式の位置づけ（新しいタブで開きます）
Kaizen CMSでは、EmDashの標準的な記事編集に、公開サイトへの反映や資料管理などを組み合わせています。日々の更新のために、担当者がソースコードを編集する必要はありません。
| 日々の作業 | Kaizen CMSで用意した流れ |
|---|---|
| お知らせや基本ページを書く | 日本語の本文を編集し、画像を選んで保存する |
| 公開中の記事を直す | 公開版を維持しながら、変更内容を下書きに保存する |
| 以前の文章を取り出す | 履歴から下書きへ戻し、確認してから公開する |
| 編集と公開を分担する | 編集担当・公開担当などの操作権限を分ける |
| サイトへ届ける | 公開する版を固定し、生成・反映の結果を確認する |
保存、CMSでの公開、閲覧者へのサイト反映は、別の段階です。反映を依頼できた時点で、サイトまで変わったことにはしません。ローカルで確認した反映処理では、失敗時に以前の公開版を維持し、どこで止まったかを確認できるようにしています。
下書きの保持、履歴復元、権限に応じた操作の拒否、静的ページへの反映と失敗時の前版保持には、架空データによるローカル受入の確認記録があります。顧客の本番環境での導入実績や、すべての構成の動作を示すものではありません。
安全性を説明するなら、何を減らしたかを示す
Kaizen CMSで採った構成では、編集用CMSと公開サイトを分け、確認した記事の版から静的なHTMLを生成します。公開ページを読むたびに、WordPressのPHP、テーマ、プラグインやデータベースを動かす必要がなくなります。
この構成で減らせるのは、公開閲覧に伴うWordPressの実行処理と、その処理の脆弱性を狙われる経路です。CMSの更新や反映処理で問題が起きたときも、以前の公開ページを維持する手順を用意できます。これは、構成と実装に基づくリスク低減の説明です。
EmDash自体は、管理画面とデータベースを使う動的なアプリです。導入するだけで公開サイトが静的になるわけではありません。管理と公開配信を分けることは、Kaizen CMSで行った設計上の選択です。
プラグインの扱いにも違いがあります。EmDashには、隔離した実行環境を設定し、その中で動くsandboxed形式のプラグインに与えるデータ操作や通信の権限を制限する仕組みがあります。一方、native形式はCMS本体と同じ実行環境で動き、同じ隔離は得られません。EmDash公式のプラグイン形式（新しいタブで開きます）、隔離する実行環境の設定（新しいタブで開きます）
現在のKaizen CMSの自社拡張はnative形式です。そのため、「EmDashなので、追加した機能は全部隔離されていて安全」という説明はしません。自社拡張を保守する責任は残ります。
Kaizen CMSでは、顧客ごとのCMS・データ保存先を分ける構成とし、編集や公開の権限をAPIでも確認する制御を実装しました。公開画像と配布条件のある資料も別に扱います。静的ページの生成では、本文を任意のHTMLとしてそのまま実行せず、対応する要素だけを表示し、未対応の内容は反映を失敗させます。これらは架空データによるローカル受入で確認した範囲であり、実クラウドへの適用は別途確認が必要です。
編集アカウントや公開権限を奪われれば、不正な内容が静的サイトへ配信される可能性は残ります。CMSと依存部品の更新、認証、バックアップ、公開操作の記録、外部フォームの保守は引き続き必要です。実際のクラウド環境での認証・公開経路・復旧も、導入先で確認する項目です。
更新する仕事に合う構成を選ぶ
当社は新着情報や会社の基本情報を更新するために、必要以上の実行機能を公開サイトへ持たせたくありません。その用途であれば、ブラウザから編集できるCMSと静的配信を組み合わせる構成は、有力な選択肢です。
多様な担当者が複雑なページを組み立て、WordPress固有の機能を日常的に使っている場合は、既存構成を整理しながら保守する方法も比較します。EmDashはElementorの画面設計やWordPressのテーマ、プラグインを、そのまま再現・実行する道具ではありません。移行する本文、追加項目、表示、業務機能を対応させる必要があります。
移行では、以前のURL、本文、画像・資料、検索設定、受付・通知、必要な計測と編集方法を引き継ぎます。静的サイトへ切り替えたあとも古いWordPressを別の場所で動かし続ければ、そちらの保守は残ります。必要な業務を移し、受入を終えてから、旧環境の入口や定期処理を退役させるところまで計画します。全面リニューアルで確認すること
最初に取りかかるなら、いま入っている機能について、「何に使うか」「誰が保守するか」「更新で何を確かめるか」を一枚にまとめてください。説明できない機能を見つけることから、更新できるサイトへ戻す作業が始まります。
構成や更新方法を見直すご相談は、ウェブ運用・改善で支援内容をご確認いただけます。調査・改修・移行・継続保守は、対象と担当、費用を個別に合意して進めます。
参考になったら、いいねでお知らせください。