投稿タイプ・カテゴリごとに担当者と更新頻度を自動で当てる：運用ルールの作り方

記事が300本あるサイトで更新期限の管理を始めるとして、300本ぶんの編集画面を開いて、担当者を選び、更新頻度を入れ、通知の日数を決めて保存する——最後までやりきれるでしょうか。やりきれたとして、来月増える20本にも同じことを続けられるでしょうか。

投稿ごとに設定して回る前提だと、更新管理はだいたい「設定した記事」と「設定していない記事」の二層に分かれて止まります。担当者や頻度は投稿1本1本の属性というより、「導入事例カテゴリなら営業部の誰それが半年ごと」「料金ページなら管理部が3か月ごと」のように、投稿タイプやカテゴリのほうに紐づいていることが多い。だったら条件のほうに設定を持たせて、条件に合う投稿へ配ればいい。コンテンツ更新管理ではこれを「運用ルール」と呼んでいます。この記事は、そのルールで何を決められて、何を決められないかの話です。

条件は投稿タイプとタクソノミーの組み合わせ

運用ルール1件は「条件」と「初期管理設定」の組で、決められる項目は15個あります。ルール名、対象投稿タイプ、対象カテゴリー・タクソノミー投稿を分類する仕組みの総称。カテゴリーとタグが標準で、プラグインやテーマが「エリア」「業種」のような独自の分類を追加することもある。、管理対象の種類、対象ACFAdvanced Custom Fields。投稿に独自の入力欄（カスタムフィールド）を追加するプラグインの定番。無料版と有料のPro版がある。フィールド、対象カスタムフィールド投稿に本文とは別の「項目名と値」を持たせる入力欄。資本金や営業時間のような値を本文の外で管理でき、ACFなどのプラグインで追加するのが一般的。、初期担当者、初期承認者、初期エスカレーション先、更新頻度、重要度、期限前通知、期限超過通知、通知チャンネル、期限切れ処理。

条件に使えるのは投稿タイプとタクソノミーの2軸だけです。タイトルに含まれる語や公開日で振り分けることはできません。タームは複数指定でき、その場合はORで判定します。「導入事例」か「お客様の声」のどちらかが付いていれば一致、という形。判定は完全一致で、子タームは自動では含めません。「料金」カテゴリの下に「法人料金」「個人料金」を作っているなら、親だけ指定したルールは子カテゴリしか付いていない投稿には当たらないので、子まで並べて指定します。ここはつまずきやすいところで、一括適用の件数確認（後述）で「思ったより少ない」と出たら、まず子タームを疑ってください。

たとえばこんなルールになります。

項目	値
ルール名	導入事例（投稿全体）
対象投稿タイプ	投稿
対象タクソノミー	カテゴリー: 導入事例
管理対象の種類	投稿
初期担当者 / 初期承認者	営業部の担当ユーザー / 広報の承認ユーザー
更新頻度	6か月
重要度	中
期限前通知 / 期限超過通知	14日前・7日前 / 超過3日目
通知チャンネル	メール + Slack
期限切れ処理	管理画面で警告のみ

運用ルールを作れるのは、設定を管理する権限を持つ人（既定では管理者）だけです。担当者や承認者に指名できるユーザーの条件はルール経由でも変わらず、担当者はその投稿を編集できるユーザーから選びます。

ルールが配るのは初期値で、配ったあとは投稿ごとに動く

条件に一致する新しい投稿が、auto-draft を除いて最初に正規保存されたとき、ルールの内容で管理対象が作られます。管理画面からの保存だけでなく、REST API経由やプログラムからの投稿作成でも同じです。次回確認日は「適用した日 + 更新頻度」で入る。あとは通常どおり、その投稿の管理対象として期限が動き、通知が飛び、確認が回ります。

ここで押さえておきたいのは、ルールは「初期値を配る」ものであって、配ったあとの管理対象を縛り続けるものではないことです。

つまり、ある投稿の担当者を個別に変えたあとでルール側の担当者を変えても、その投稿は巻き戻りません。テンプレートというより「配布」に近い挙動です。逆に言えば、ルールを直しただけでは何も変わらないので、「ルールを変えたのに一覧が古いまま」と感じたら一括適用が要ります。

更新頻度を「なし」にしたルールも作れます。この場合、管理対象は次回確認日が未設定のまま作られ、一覧には出るが通知と期限切れ処理の対象にはなりません。担当者だけ先に決めておいて期限はあとで個別に入れる、という使い方向けです。

2つのルールが同じ投稿に当たったとき

「投稿タイプが投稿なら全部」というルールと、「カテゴリが料金なら」というルールを両方作ると、料金カテゴリの投稿には2つとも一致します。このときの決め方は、管理対象の単位で優先順位の上のルールを採る、です。優先順位はルール一覧で並び替えられます。

ただし比べるのは同じ種類のルールどうしだけ。「投稿全体」を作るルールと、「ACFの価格フィールド」を作るルールは、種類が違うので競合せず両方適用されます。ACFフィールドやカスタムフィールドをルールの対象にする話は、フィールドに期限をつける記事のほうにまとめました。同じフィールドを対象にした2つのルールが当たったときも、そのフィールド単位で上位を採ります。

既存の投稿には一括適用で当てる

ルールを作った時点では、既存の投稿は何も変わりません。既存分へは運用ルール画面の「一括適用」で当てます。

実行の前に、対象の件数が3つ出ます。条件に一致する投稿数、そのうち既に管理対象がある投稿数、今回作成または更新される数。この画面で「一致する投稿数」が想定とずれていたら、条件（さっきの子タームなど）を直してから実行します。

既に管理対象がある投稿の扱いは3択です。

既定が補完なので、投稿ごとに手で入れた担当者や期限は、何も選ばずに流しても消えません。迷ったら補完で回してから、必要な投稿だけ上書きし直すほうが安全です。

実行は1回50件ずつ、画面が順に進めます。300本なら6バッチ。進捗はその画面で見えて、途中でブラウザを閉じてもWP-CronWordPressが予約投稿や定期処理を動かす仕組み。サーバーの時計ではなく、誰かがサイトを開いたタイミングで動くため、アクセスの少ないサイトでは遅れることがある。が続きを引き継ぎます。1ジョブで扱える上限は2000投稿なので、それを超えるサイトでは条件を分けて回します。

WXR（WordPress標準のエクスポート形式）でインポートした投稿には、注意が一つ。インポートは「投稿を作ってからタームを付ける」順で進むことがあり、その場合は初回保存の時点でタクソノミー条件に一致せず、新規投稿への自動適用がかかりません。インポート後に一括適用を1回走らせる運用を前提にしてください。

ルールでは決められないこと

作っている側から言うと、ルールに入れなかった項目が2つあります。

一つは期限切れ処理の「指定URLへリダイレクトあるURLを開いたとき、別のURLへ自動で転送すること。ページを消す代わりに関連ページへ送ると、検索エンジンからの流入やブックマークを失いにくい。」。投稿単位の管理対象は期限が過ぎたときの処理として下書き・非公開・リダイレクトを選べますが、運用ルールの期限切れ処理ではリダイレクトを選べません。ルールは遷移先URLを持てないからです。URLの無いリダイレクト対象を作ってしまうと、フロントでは何も起きず、履歴には「実行しました」と残り、その投稿の編集画面は保存が通らなくなる——三つが同時に起きます。「条件に一致した全投稿を同じURLへ飛ばす」という設計も検討しましたが、一括で当てる操作にしては効き方が強すぎると判断して外しました。リダイレクトが要る投稿は、編集画面で個別に設定します。

もう一つは管理ブロックの行。ルールで作れる管理対象の種類は「投稿」「ACFフィールド」「カスタムフィールド」で、本文の一部分を囲む「コンテンツ更新管理セクション」ブロックはルールでは作れません。ブロックは囲む範囲を人が本文で決めるものなので、条件だけでは作りようがない。ブロックの管理対象は、本文に置いて保存した時点で作られます。

ルールで配れるのは、担当者・承認者・エスカレーション先、更新頻度、重要度、通知の日数とチャンネル、そしてリダイレクト以外の期限切れ処理まで。それ以外——記事の一部分だけを囲む範囲、リダイレクト先——は投稿ごとに人が決めます。何を管理対象にできて、そこに何を持たせるかの全体像は更新期限と担当者を管理する話の柱記事に書きました。

製品ページは コンテンツ更新管理 にあります。