目次
「サイトは表示されているし、管理画面にも入れるから大丈夫」。WordPressの点検を、この二つだけで終えていませんか。表示に問題がなくても、更新処理の停止、診断情報の公開、意図しないファイル変更などは別の確認が必要です。点検で役立つのは、安心できそうな表示を集めることではなく、何を確かめ、何がまだ分からないかを残すことです。
この記事は2026年10月18日にWordPress公式資料を確認して作成した運用ガイドです。特定のサイトで侵害を発見したという報告ではありません。管理画面でできる確認から始め、利用できる環境ではWP-CLIによる整合性の確認へ進みます。実行環境や保守契約によって使える機能が異なるため、コマンドを利用できない場合の依頼事項も整理します。
スポンサーリンク
点検前に対象と基準日を決める
最初に、対象のドメイン、WordPressの設置場所、本番か検証環境か、点検時刻、担当者を記録します。同じサーバーに古い検証サイトが残っている場合、本番だけ確認しても管理対象全体を把握したことにはなりません。使っていないサイトは、公開の必要性と保守の責任者を確認してください。
本サイトの提案は、点検結果を「問題なし」「要対応」「未確認」の三つに分ける方法です。権限がなくて見られなかった項目や、提供元が分からない独自コードを、空欄のまま問題なしへ含めないようにします。前回の記録があれば、追加されたプラグイン、ユーザー、外部連携などの差分も確認できます。
サイトヘルスを入口にして状態を読む
説明用に、更新通信の失敗とサイトマップの遅延が同時に見つかった場合を考えます。画面上の順番で処理するより、更新を受け取れない原因を先に調べる方がよい場合があります。対応の優先度は、警告の色だけでなく、攻撃を受ける条件、業務への影響、代替手段から決めてください。
管理画面の「ツール→サイトヘルス」には、対応が必要な項目を示すステータスと、環境情報を確認する情報タブがあります。公式資料は、バックグラウンド更新の問題、エラー表示、古いPHPなども確認対象として説明しています。情報タブ自体は設定を変更する画面ではありません。出典：WordPress公式：Site Health screen。
表示された件数をゼロにすることだけを目標にしないでください。たとえば更新用の通信ができない場合、通信先の制限、サーバー側の設定、プラグインの影響など、原因の切り分けが必要です。警告を消すために外部通信の制限をすべて解除すると、意図して設けた境界まで失う場合があります。
逆に、合格したテストがあることは、サイト全体の侵害がない証明ではありません。サイトヘルスで確認した設定、ファイルの整合性、利用者の権限は別の観点です。以下は本サイトの記録例です。実際の表示名や項目は、版と追加機能によって異なります。
- 更新：警告の内容、発生した時刻、最後に更新できた時刻を記録する。
- 公開設定：本番で意図しないエラー表示がないか、外部から見える状態も確認する。
- 環境：PHPなどの版とサーバー側の保守状況を、契約先の案内で照合する。
- 未確認：管理権限が必要な情報や、保守会社へ依頼した項目に担当と期限を付ける。
スポンサーリンク
診断情報は共有する前に中身を確認する
サイトヘルスの情報には、テーマやプラグイン、サーバー、ディレクトリなどの技術情報が含まれ、コピー機能も用意されています。サポートへ渡す資料として便利ですが、そのまま公開掲示板や一般公開のチケットへ貼り付ける前に内容を確認してください。出典：WordPress公式：サイトヘルスの情報タブ。
本サイトでは、相談に必要な項目だけを残し、設置先の絶対パス、不要な接続情報、個人を特定できる値などを確認してから共有する方法を勧めます。プラグインによって追加情報が異なるため、「コピー機能があるからすべて公開してよい」とは判断しません。認証用の秘密や本番データは、診断の便宜のために付け足さないようにします。
エラーを隠すこととログを守ることを分ける
公式のデバッグ資料では、WP_DEBUG_DISPLAYは画面への表示、WP_DEBUG_LOGはファイルへの記録を制御します。WP_DEBUG_LOGにtrueを指定すると通常はwp-content/debug.logへ保存され、別の保存先も指定できます。また、デバッグ機能は本番での常用を推奨していません。出典：WordPress公式：Debugging in WordPress。
画面にエラーが出なくても、ログファイルが外部から読めれば別の公開経路になります。運用上は、本番で診断が必要な期間と担当者を決め、保存先へのアクセス制限、保持期間、診断終了後の設定を確認します。自分のサイトの既知のログ保存先を確認し、ログ本文が取得できる状態なら対処してください。
ログを確認するときは、パスワードやトークンを含むデータを追記して調査しないことも重要です。共有するのは必要な行と時刻に絞り、機密部分を除きます。エラーを見つけるための記録が、新しい漏えい経路にならない形に整えてください。
スポンサーリンク
WP-CLIでコアファイルを公式配布物と比較する
SSHとWP-CLIを利用できる環境では、コアファイルのチェックサムを公式配布物と比較できます。公式リファレンスによれば、このコマンドはWordPressの読み込み前に実行され、必要に応じて版と言語を指定します。以下は説明用の例であり、対象パスは実際の設置場所へ置き換えます。出典：WP-CLI公式：wp core verify-checksums。
wp core verify-checksums --path=/absolute/path/to/wordpressこの操作はWordPressコアの照合です。DB内の投稿や設定、画像、独自テーマ、すべてのプラグインまで安全だと判定するコマンドではありません。一致は比較対象のファイルについての結果として読み、サイト全体に範囲を広げないようにします。
不一致があったときは、まず版や言語の指定、正規の変更履歴を照合します。不一致だけでマルウェアと決め付けず、差分の内容と理由を確認してください。一方、理由が分からないまま公式ファイルを上書きすると調査材料を失うため、侵害が疑われる場合は保守担当と証拠を残す手順を決めてから復旧します。
プラグインの照合には対象外がある
プラグイン用には、WordPress.orgのチェックサムへ照合する別のコマンドがあります。公式リファレンスは全プラグインを指定する--allと、軽微な差分も検出する--strictを説明しています。まずは標準の照合から始め、結果の対象件数と警告を読みます。出典：WP-CLI公式：wp plugin verify-checksums。
wp plugin verify-checksums --all --path=/absolute/path/to/wordpress公式の照合データがない有料製品や自作プラグインは、同じ方法で判定できるとは限りません。取得元の正規パッケージ、管理しているソース、配備時の記録など、別の基準を用意します。検証できなかったものを削除したり、検証成功に数えたりせず、未確認の理由を残してください。
侵害を疑う環境では、未知のコードを含むサイトを通常どおり読み込む操作にも注意が必要です。WP-CLIという名前だけで全コマンドが同じ安全性だと考えず、信頼できる実行環境と隔離したコピーを使うか、専門担当へ依頼します。TLS検証を無効にするオプションで照合を強行することも避けます。
差分を正規の変更と対応付ける
照合や監視の結果を読むには、正常な変更の記録が必要です。本サイトの提案は、更新した日時、担当者、対象の版、変更申請を一組で残すことです。テーマを直接修正していた事情があるなら、それを正規の変更として記録しつつ、今後も更新で維持できる方法を検討します。
ファイルの更新時刻だけでは変更理由は分かりません。配備や復元で時刻が変わることもあれば、DBだけに変更がある場合もあります。点検で見つけた説明できない差分は、誰のどの作業かを確認し、正当な理由がない場合に調査の優先度を上げます。
レンタルサーバーでは依頼できる形にする
WP-CLIを使えない契約でも、点検を終える必要はありません。管理画面の記録をもとに、保守会社やサーバー事業者へ「対象環境」「確認してほしい範囲」「必要な結果」を伝えます。「安全か見てほしい」だけでは、ソフトウェアの版確認と侵害調査のどちらを依頼したのか曖昧になります。
たとえば、更新通信が失敗する原因の確認、コアの公式配布物との差分確認、診断ログの公開制限を分けて依頼します。事業者が対応できる範囲と、別の調査契約が必要な範囲も確認してください。点検のために管理者パスワードを平文で公開したり、不要に権限を広げたりしないことが基本です。
スポンサーリンク
点検結果を次回の比較に使う
完了時には、解消した問題、経過観察、未確認を分けます。頻度はサイトの変更量や重要性に合わせて決め、大きなプラグイン追加やPHP更新の後にも比較すると、変化を追いやすくなります。毎回同じ画面を見るだけでなく、前回との差分と対処の結果を残す点検にしましょう。
点検の目的は、完全な安全を宣言することではありません。確認対象と限界を明らかにし、更新・権限・復旧の改善へつなげることです。異常が見つかった場合は、安易に消して終わらせず、公開状態と業務影響を踏まえて保守担当へ引き継いでください。
