更新頻度の欄に入れられるのは、1〜999の数字と日・週・月・年の単位、それに「なし」です。組み合わせは事実上いくらでも作れます。作れることと、決められることは別。
先に結論を書いておくと、全ページに配れる正解の周期はありません。周期は「何か月ごとがちょうどいいか」と考えて決めるものではなく、そのページに書いてある値が何の都合で変わるのかを見て、逆算して割り当てるものです。以下は、コンテンツ更新管理というプラグインで更新頻度を設定する前提で、その逆算のしかたを並べたものになります。誰が・いつまでに・どこを確認するかをWordPressの中に持たせる仕組みそのものは公開して終わりにしないための全体像にまとめてあります。
周期の正解は、ページの側にしか書かれていない
同じサイトの中でも、料金の行と会社沿革の行では変わる速さがまるで違います。この差を無視して全部へ「6か月ごと」を配ると、どうなるか。
周期が短すぎるページでは、確認結果が「確認したが変更不要」で埋まります。読んで、合っていることを確かめて、記録して、また半年後。作業としては正しく、得るものが薄い。長すぎるページではその逆で、期限が来る前に中身のほうが先に変わります。このプラグインには前回の確認完了時点と比べて本文やタイトルが変わったかを出す仕組みがあるので、期限が来ていないのに「変更あり」ばかり並ぶページは、周期が中身の速さに追いついていない合図として読めます。
つまり周期は、担当者の都合でも運用のキリのよさでもなく、ページに載っている値の性質のほうが決めている。決め方は逆算になります。この値を動かしているのは何か。
値を動かしているのが何かで、周期は分かれる
ページに載る情報を、変わる引き金で分けるとこうなります。
| ページに載っている値 | 変わる引き金 | 周期の当て方 |
|---|---|---|
| 料金・プラン・営業時間・送料 | 自社の決裁。日付は社内で決まる | 短め。値が動く間隔より短い周期にしておく |
| 法令・制度・規格・対応バージョン | 外から来る日付 | 周期ではなく出来事。「なし」にして手前の日を次回確認日に |
| 担当者・役員・有資格者・連絡先・採用条件 | 人の異動 | 年単位。異動の時期の手前へ寄せる |
| 実績・事例・対応エリア | 積み上がるだけ | 年単位で足りることが多い |
| コラム・読み物 | ほとんど変わらない | 周期を持たせない選択もある |
自社が決める値の典型的な落ち方は、決裁は通っているのに更新の依頼が誰にも渡っていない、という形です。値が変わる間隔より周期が長いと、変わってから次の確認までのあいだ、古い数字が載り続けることになる。
外から日付が来るものに周期を当てると、施行日の翌週に確認が来たり、何も起きていない年に3回確認したりします。ここで使うのが更新頻度の「なし」です。次回確認日のほうは必須項目ですが、更新頻度は任意で、「なし」を選んだ管理対象は確認を完了しても日付が動かない。動かないぶん、次の日付は人が入れ直すことになります。周期側は間隔を決める、出来事側は日付を置く。入れるものが違う、と分けて考えると迷いません。
人に紐づく値は、変わったこと自体は社内で共有されているのに、ページまで届かない類のもの。年1回で足りますが、置く月は選べます。異動や役員改選の時期の手前へ次回確認日を寄せておくと、空振りが減る。
積み上がる値は、古くても誤りにはなりません。自社の実績ページに「100社」と書いてあって実際は150社でも、読んだ人が困ることはない。ここへ短い周期を配ると、急がなくていい行が通知と一覧の場所を取ります。
このサイトも同じものを抱えています。柱の記事に「WordPress 6.6以上、PHP 8.1以上」と書いた行があって、本体の要件を上げた日から古くなる。記事の他の部分は数年もつのに、その2行だけ寿命が違う。分類でいえば1行目、自社の都合で日付が決まる値です。
1ページに1つしか周期を置けないと思うと、決められなくなる
この表をページ単位で当てようとすると、そこで詰まります。1枚のサービスページに、料金も、注意事項も、担当窓口も、導入実績も同居しているからです。ページ全体でどれかに寄せた時点で、残りの周期は間違っている。
コンテンツ更新管理が期限を持たせる単位は4つあります。投稿そのものは1記事に1つ、本文をブロックで囲んだ範囲と、ACFAdvanced Custom Fields。投稿に独自の入力欄（カスタムフィールド）を追加するプラグインの定番。無料版と有料のPro版がある。フィールド・カスタムフィールド投稿に本文とは別の「項目名と値」を持たせる入力欄。資本金や営業時間のような値を本文の外で管理でき、ACFなどのプラグインで追加するのが一般的。の値は何個でも。周期も担当者も単位ごとに別々に持てるので、表の当て方はページではなく値の側へ落とせます。囲む範囲の作り方と、期限を過ぎたときにその範囲だけどう見せるかはページの一部分だけを別の周期で回す話に書きました。
見落としやすいのはフィールドのほうです。営業時間や料金がカスタムフィールドに入っていると、本文を読み直す確認では引っかかりません。値そのものに周期を持たせられる、というのがこの単位の意味です。
次の期限は、決めた日付ではなく確認を終えた日から立つ
周期を決めたあとの動き方も、選ぶ数字に効いてきます。
次回確認日の再計算に使うのは確認が完了した日（承認者を置いているなら承認された日）で、元の次回確認日ではありません。3日遅れて確認すれば、次の期限も3日後ろへ動く。基準は完了日の1つだけで、元の日付を覚えておいて引き戻す作りにはしていません。周期を決めるというのは、日付を固定することではなく間隔を決めることだ、と読み替えたほうが近い。
月単位の周期には、もう一つ癖があります。加算した先に同じ日が無ければ、その月の末日へ丸める。1月31日に確認を終えて「1か月」なら、次は2月28日（閏年なら29日）です。そして2月28日に確認を終えれば、次は3月28日。31日には戻りません。年単位で2月29日を起点にした場合も同じで、翌年は2月28日になります。
毎月末に見ると決めているつもりでも、計算を周期に任せているかぎり日付は前へ動いていく。日付そのものを固定したいなら、周期に計算させず、確認のたびに次回確認日を入れ直す形になります。
週や日の単位で回すなら、期限接近の日数も一緒に下げる
日・週の単位も選べますが、短い周期にはもう一つの設定が絡みます。期限接近と見なす日数です。既定は7日、1〜90日の範囲で変えられます。
更新頻度を7日にすると、確認を終えた時点で次の期限がもう接近の範囲に入っている。完了した管理対象が「未対応」へ戻るのは次回確認日が接近の圏内に入ったあとの毎時処理で、完了した直後に圏内でも即座には戻さないようにしてあります。それでも周期と閾値が同じままなら、終えたそばから次のサイクルが立ち上がる並びに近づく。日や週で回すなら、接近の日数を1〜2日へ下げておくほうが一覧が読めます。
判定はどれも日単位で、サイトのタイムゾーンが基準です。時刻の精度で切り替わるものではありません。それから、通知を厚くしたいだけなら周期を短くするより期限前通知の日数を増やすほうが素直で、こちらは複数の段を指定できます。
使う数字は、サイトの中で数種類に決めておく
最後に、決めた周期を運用に載せるときの話を一つ。
ページごとに最適な数字を入れていくと、「このページは4か月、こちらは5か月」で一覧から法則が読めなくなります。あとから「事例は全部1年にする」と決めたとき、直す先を人が探すことになる。3か月・1年・なし、というくらいに使う数字を絞っておくと、投稿タイプやカテゴリの条件へ担当者と周期をまとめて持たせられます。条件で配る仕組みは条件ごとに担当者と更新頻度を配る記事のほうに書きました。
条件側で「なし」を選ぶときだけ、挙動が変わります。ルールが配る次回確認日は「適用した日＋更新頻度」で計算されるので、頻度が無ければ日付も入らない。次回確認日が空のまま管理対象ができ、一覧には並ぶのに通知も期限切れ処理も動きません。出来事で回すものは、ルールで一斉に作ってから日付を入れる順になります。
念のため書いておくと、周期を決めたからといって古い情報が自動で見つかるわけではありません。このプラグインが古さを判定することはなく、判定するのは確認する人です。更新頻度が決めているのは、そのページを見に行く回数だけ。それでも、見に行く回数がゼロだったページを年に1回にするところが、いちばん大きく変わります。
製品ページは コンテンツ更新管理 にあります。
