更新期限を決めて、担当者を置いて、期限が来たら確認する。ここまで回り始めると、次に気になるのは「期限と期限のあいだ」です。確認してから次の確認日までの数か月、そのページは誰も見ていない。その間に中身が変わっていたら、どうやって気づくのか。
たとえばこういう状況です。料金表のブロックは3か月ごとに確認する設定にしてあり、前回の確認は先月、次回確認日まであと2か月。その間に別の担当者が「キャンペーンの価格を反映して」とブロックの中の数字を1行書き換えた。期限の管理だけを見ていると、この状態は「期限前・完了」のまま静かに過ぎていきます。次の確認日が来るまで、承認者を含めて誰も、料金表が承認したときと違う内容で公開されていることに気づかない。
期限より先に、中身のほうが変わる。更新管理をやり始めると割とすぐ出会う状況で、コンテンツ更新管理には期限管理とは別の軸として「前回確認後の変更」を検出する機能を入れてあります。この記事で書くのは、その仕組みと、見え方と、できないこと。期限と担当者の全体像は柱の記事にあります。
比べる基準は「前回、確認が完了した時点」
変更検出は、いまのコンテンツを「前回確認が完了した時点」の状態と比べます。前回の保存時点でも、投稿の公開日でもなく、確認完了の時点。承認者を置いている管理対象なら承認が下りた時点で、置いていなければ担当者が確認結果を登録した時点で、そのときの状態が基準値として保存されます。
基準をここに置いたのは、この機能が答える問いが「最後に人が『合っている』と言ったものと、いま公開されているものは同じか」だからです。「前回の保存から変わったか」では、担当者が自分で直した保存も全部「変更あり」になって意味をなさない。確認完了を起点にすれば、確認した人が見た状態からのズレだけが残ります。
一度も確認が完了していない管理対象には基準値が無いので、一覧では「未確認」と出ます。導入直後は全部これです。最初の確認サイクルを一周させてから機能し始める、と思っておいてください。
投稿は6項目、ブロックはひとかたまり、フィールドは値そのもの
何を比べるかは管理単位で違います。
| 管理単位 | 比較するもの |
|---|---|
| 投稿 | タイトル／本文／抜粋／スラッグURLの末尾に使う、投稿やカテゴリーごとの英数字の名前。このサイトなら plugear.net/wordpress-japan-map/ の「wordpress-japan-map」の部分。／アイキャッチ／ターム の6項目（項目ごとにハッシュ） |
| 管理ブロック | そのブロックをシリアライズした結果（内側のブロックを含む）のハッシュ |
| ACFAdvanced Custom Fields。投稿に独自の入力欄（カスタムフィールド）を追加するプラグインの定番。無料版と有料のPro版がある。・カスタムフィールド投稿に本文とは別の「項目名と値」を持たせる入力欄。資本金や営業時間のような値を本文の外で管理でき、ACFなどのプラグインで追加するのが一般的。 | 確認完了時点の値を保存し、正規化した値どうしで比較 |
投稿は項目ごとに見るので、「本文は変わっていないがカテゴリが付け替えられた」も検出できます。ブロックは丸ごと1つのハッシュなので、中の並び替えや空白の違いでも「変更あり」になる。ここは誤検知寄りに倒してあり、「変わったのに気づかない」より「変わっていないのに変わったと言われる」を選んでいます。
フィールドの比較は少し慎重にしてあります。リスト型は順序を区別し、連想配列はキーの順序を無視し、型と「未設定・null・空文字・空配列」を区別する。そしてACFは書式化する前の生の値で比べます。この仕様にしたのは、書式化後の値が安定しないからです。画像フィールドは設定次第で配列にもURLにもなり、ACFの設定変更やバージョン更新で形が変わる。中身が変わっていないのに「変更あり」になるのは、この機能では致命的だと考えました。
リピーターは全体で1つの管理対象。行単位には分けられず、行を並び替えただけでも「変更あり」になります（リスト型の順序を区別しているので）。
一覧の12列目、ダッシュボードのカード、詳細画面の1行
検出は保存のたびに走り、結果の出る場所は3つ。
管理対象一覧の12列目が「前回確認後の変更有無」で、絞り込みの軸にもなっています。「変更あり」だけを抜き出して並べれば、期限は先だが見ておくべき対象の一覧になる。ダッシュボードには「前回確認後に変更あり」のカードがあり、押すとその絞り込み済み一覧へ飛んで件数が一致します。管理対象の詳細画面には「前回確認時点からの変更有無」の行があり、履歴にも残ります。
何が変わったかの見え方は、値の種類で違います。文字列や数値のような単純な値は、変更前と変更後を並べて見せる。配列のような複雑な値は「変更あり」と整形済みのスナップショットだけで、視覚的な差分は出ません。投稿本文の変更はWordPressのリビジョンで見る導線を出します（リビジョンを無効にしているサイトでは「詳細差分なし」）。「何がどう変わったかを全部見せる」機能ではなく、「変わった、ここを見ろ」までを担当する機能です。
検出しても、期限は動かない
「変更あり」になっても、次回確認日は変わりません。「変わった」と表示するだけです。中身が変わったからといって期限を前倒しにするかどうかは人が決める。見た結果「問題ない」なら、そのまま次の期限まで置いてよいし、気になるなら次回確認日を手前に動かせばいい。期限接近の圏内に入った次の毎時処理で「未対応」に戻り、新しい確認サイクルが始まって、確認完了で基準値が更新されます。
例外がひとつ。承認待ちの管理対象で変更を検出したときは、承認を無効にして修正中へ戻します。承認者が承認しようとしている内容と公開されている内容が食い違う状態を残さないため。履歴には実行ユーザー「システム」として記録されます。承認の流れ全体は承認をつける話のほうに書きました。
変わったことは分かる。正しいかどうかは分からない
この機能が見ているのは「確認したときと違うか」、それだけ。変更の内容が正しいか、重要か、更新すべき情報かは判定しません。AIで古さを見つけたり、変更の重大さを点数にしたりはしない。料金表の数字が正しく更新されたのか誤って書き換えられたのかは、一覧で「変更あり」を見た人が開いて決めます。
もうひとつ、変更検出が止まる条件があります。設定「管理対象とする投稿タイプ」からその投稿タイプを外すと、既存の管理対象は「停止中」になって通知・期限切れ処理と一緒に変更検出も止まる（戻せば元どおり）。ACF連携を無効にしたときも、ACFの管理対象は同じく止まります。行を書き換えずに都度算出しているので、設定を戻せばまた比べ始めます。
製品ページは コンテンツ更新管理 にあります。
