「このサイト、更新したほうがいいですか？」という相談は、プラグインや本体のバージョンが並んだ表を見るだけでは答えにくい。よしあきは、まず切り分けの順番を決めてから、部品（プラグイン・テーマ）の古いまま残っている更新を見るようにしている。この記事はその手順の話である。
案件の固有事情は書かない。読者が自分のサイト、あるいは依頼を受けたサイトで同じ順番を試せるようにする。
手順を一文でまとめると
よしあきが相談を受けたあとにやっている順番は、だいたい次のとおりだ。
- 取れるなら Site Health と XML（サイトマップ／必要ならエクスポート）で版と構成を先に揃える
- Site Health の現行版を latest・脆弱性DB・ベンダー告知 と照らし合わせる
- 緊急の要否と、本体／PHP の新しさを切る
- 部品は「未認証で悪用されうるか」を軸に並べる（権限前提は運用で現実リスクを補正）
- そのサイトの版で当て直す（他サイトの表は使わない）
- バックアップ用途も同じ軸で見る
- ページ組み立て系は確認工数を別枠で見る（XML の地図を材料にする）
- 説明は「何が起きうるか」まで言い切る
- 単発／継続の枠と、サイト固有の差額で見積に落とす
- 版が取れない箇所は推測せず未確認のまま残す
以下、この順番に沿って中身を書く。
情報は Site Health と XML でまとめて取る
画面をひとつずつ開いて版を手書きするのは遅い。よしあきは、取れるときは次の二つを先に揃える。
Site Health（サイトヘルス）の情報
管理画面の ツール → サイトヘルス → 情報 から、サイトの情報をまとめてコピーできる。ここを正本にすると、次が一気に揃いやすい。
- WordPress 本体の版
- PHP の版
- テーマ
- 有効／停止中のプラグインと、それぞれの現行版（と、画面上に出る最新版の手がかり）
プラグイン一覧を管理画面で目視しながら表を埋めるより、一度吐き出してから照らし合わせるほうが抜けが減る。土台（本体／PHP）と、部品側の古いまま残っている更新を、同じ素材から切れるのも大きい。
Site Health で掴んだ「いまの版」は、主に次と照らし合わせる。
| 照らし合わせ先 | 見ること |
|---|---|
| Site Health 上の最新版の手がかり | 現行と latest の差。最新からどれだけ遅れているか |
| 脆弱性データベース（Patchstack・WPScan・Wordfence Intelligence など） | 現行版が影響範囲に入るか。修正版があるか |
| ベンダーや公式の告知 | データベースに無い／遅れている注意点の補完 |
取り方は、日常の監視と、相談サイトの突合で分けている。
- 日常（よく使う部品の横断ウォッチ） — Wordfence Intelligence の API でフィードを取り、自分のウォッチ一覧に載っているものだけに絞る。WordPress 本体や PHP は、公式のリリース情報やサポート期限の公開データも見る。仕組みの選び方は別稿に書いた。
- 相談サイト（Site Health の版を当てるとき） — フィードを全部読むのではなく、入っている部品だけを Patchstack や WPScan の公開ページで検索して当てる。データベースに無い・遅いときは、プラグイン作者や WordPress.org の告知、必要なら PHP / コアの公式発表を開く。
優先度に載せるのは、おおむね 「現行が影響上限以下」かつ「直す版がある」 ものだ。版が古いだけでは緊急にしない。未認証で悪用されうるか、という前の軸と組み合わせる。断定は照合した時点の出典付きに留める。
XML（サイトマップと、必要ならエクスポート）
XML は用途を分けて使う。
| 種別 | 主な使いどころ |
|---|---|
| 公開の XML サイトマップ | ログイン前でも、ページ URL のざっくりした一覧と構成が取れる。ページ組み立て系の「更新後に見る範囲」を見積もる材料になる |
| 管理画面のエクスポート XML（コンテンツの書き出し） | 投稿タイプやページの実データ側の手がかり。公開サイトマップに載らないものや、構成の裏取りに使う |
サイトマップは「公開されている URL の地図」であって、無効化済みプラグインや PHP の版までは教えてくれない。逆に Site Health だけでは、更新後にどの画面を目視すべきかの範囲は弱い。版の正本は Site Health、確認範囲の地図は XML、という役割分担にしている。
版一覧が空のまま、推測で埋めない
素材（いま入っている本体・PHP・部品の版）が揃っていないとき、推測で「たぶんこの版」と埋めない。
分けるとよい。
| 取れる経路 | 例 |
|---|---|
| 公開面の実測で補える範囲 | 公開 HTML や応答ヘッダから分かる範囲、公開されているジェネレータ情報、XML サイトマップなど（取れるものだけ） |
| 管理画面やサーバー情報が要る範囲 | サイトヘルス（Site Health）の情報、プラグインの正確な版、無効化済みの部品、PHP の実バージョン、コンテンツのエクスポート XML |
取れないものは「未確認」と書く。空欄を埋めたつもりになると、優先度も見積もずれる。Site Health も XML も無いときは、この表どおり公開面で取れる範囲と未確認を分けたまま進める。
最初に切るのは「緊急」と「土台」
相談が来たら、いきなりプラグインの更新リストを埋めない。先に次の2点を見る。
- 緊急対応の要否 — いま公開面で悪用されうる状態か。あとからまとめてよい更新なのか。
- 本体と PHP が新しいか — WordPress コアとサーバー側の PHP。ここが古いと、部品だけ新しくしても土台の穴が残る。
残りは、部品側の古いまま残っている更新として扱う。件数が多いほど「全部すぐ更新」と言いたくなるが、土台と緊急の切り分けがないと優先順位が崩れやすい。
優先度の軸は「未認証で悪用されうるか」
脆弱性の説明には、権限の前提が書いてあることが多い。よしあきが最初に見るのは、おおむね次の軸である。
- ログインなしで悪用されうるか（未認証）
- 悪用に 管理者や投稿者などの権限 が要るか
低権限や、すでにログインしたユーザーが前提の弱点は、次のような運用なら現実リスクを下げて考えてよいことが多い。
- 管理ユーザーがほぼ1名
- 新規登録が無効
- 不要な権限を持つアカウントがいない
「脆弱性がある＝即緊急」ではない。悪用の前提が今のサイトに揃っているかを見る。
同型サイトでも、版が1つ違えば判定は別物
見た目や構成が似たサイトでも、導入している部品の版が1つ違うだけで該当件数は変わる。他サイトで作った「このプラグインは危ない／大丈夫」表を流用しない。
毎回、そのサイトの実際の版に当て直す。似ているから同じ、は省略になる。
バックアップ用の部品も、用途名だけで後回しにしない
バックアップや移行のための部品は、「守る側の道具」に見える。だから更新候補の末尾に回りがちだ。
ただ、その部品自体が古いと、守る道具が穴になりうる。用途の印象だけで後回しにせず、他の部品と同じ軸（未認証で悪用されうるか、版がどれだけ遅れているか）で並べる。
ページ組み立て系は、更新より「確認の重さ」
ページビルダーや、ページの見た目を大きく握る部品は、更新そのものより更新後の表示確認が工数を左右しやすい。
- トップや主要下層の見た目崩れ
- 編集画面と公開面の差
- キャッシュや最適化との組み合わせ
「更新ボタンを押す時間」だけで見積もると足りない。確認範囲を先に見積に含める。XML サイトマップは、その範囲を見積もる材料になる。
専門語のまま渡さず、必要性を言い切る
公表されている注意点（アドバイザリや脆弱性情報）を、そのまま専門語で渡しても必要性が伝わりにくいことがある。よしあきは、読者や依頼者向けには、起きうることを次のように言い切るようにしている。
ログインなしで呼べる窓口から、内容が書き換えられうる。
細部の CVE 番号や CVSS の数値は根拠として残してよい。ただ、判断を求める相手には何が起きうるかを先に置く。
調査結果は、そのまま見積の根拠になる
調査で出した優先度と作業量は、見積の材料になる。読み手が迷わない型は次のような形である。
- 単発で片付ける枠と、継続（定期の版確認・小さな更新）の枠を先に共有する
- サイト固有の重い確認（ページ組み立て系の表示確認、独自改修の有無など）だけを差額で示す
「全部まとめていくら」より、共通枠と固有分が分かれているほうが、次の相談でも説明を再利用しやすい。
知る仕組み（どこから脆弱性情報を拾うか）と、相談を受けてからの切り分けは別の話になる。前者を整えても、後者の順番が無いと「全部更新」か「様子見」かの両極端に寄りやすい。よしあきは、相談の入口ではこの順番を先に固定するようにしている。