サービス紹介のページを上から眺めると、サービスの説明、料金表、よくある質問、注意事項、問い合わせボタン、という順に並んでいます。このうち料金表は四半期ごとに見直しが入り、注意事項は法改正のたびに書き換わり、サービスの説明は何年も変わらない。1ページの中に、鮮度の違う情報が同居している。
そのページに「3か月ごとに見直す」と期限をつけると、変わらないサービス説明のために毎回ページ全体を読み直すことになります。逆に「1年ごと」にすれば、料金表は1年放置される。料金表の更新忘れは、料金表そのものより「ページ単位で期限を切った」ところから始まっていることが多い。
この記事では、記事の一部分——料金表や注意書きの範囲だけ——に担当者と次回確認日をつける方法を、コンテンツ更新管理の「コンテンツ更新管理セクション」ブロック（以下、管理ブロック）の挙動に沿って書きます。投稿・ブロック・フィールドという単位の全体像は更新期限を管理する4つの単位にまとめてあるので、ここでは一部分の話だけに絞ります。
囲んだ範囲が、記事本体とは別の管理対象になる
管理ブロックは中に任意のブロックを置けるラッパーです。料金表ならテーブルブロックを、注意事項なら段落やリストを、このブロックで囲む。囲んだ範囲がひとつの管理対象になり、担当者・承認者・次回確認日・更新頻度・重要度・通知・期限切れ処理を、記事本体とは別に持ちます。
同じ記事に何個でも置けます。料金表のブロックは3か月ごと、注意事項のブロックは1年ごと、記事全体は投稿単位の管理対象で2年ごと。3つの管理対象が1記事の中に並び、それぞれ独立して期限が来て、独立して確認が完了する。担当者も分けられるので、料金表は営業側の担当者、注意事項は法務を見ている人、という割り当てが素直に組めます。担当者に指定できるのはその投稿を編集できるユーザーだけ、という条件は投稿単位と同じです。
想定している用途は、料金表、キャンペーン情報、製品仕様、対応バージョン、注意事項、CTA、採用条件、法令関連の説明。要するに「記事の中で、そこだけ寿命が違う部分」です。
ひとつだけ構造の制約があって、入れ子はできません。ブロックの中に同じブロックは挿入できないので、「注意事項全体は毎年、そのうちの1項目だけは3か月」という二重構造は組めない。期限の違う範囲は縦に並べる。
それから、管理対象名は空のままでも保存できますが、そうすると一覧に「（名称未設定）」と投稿タイトルの組で出ます。ブロックが1記事に3つあると、どれがどれだか分からなくなる。「料金表（法人プラン）」のように付けておくと、通知の件名でも一覧でも迷いません。
もうひとつ。投稿タイプやカテゴリごとに管理設定を自動で当てる運用ルールという仕組みがありますが、ブロックの管理対象はルールでは作れません。本文のどこを囲むかは人にしか決められないので、ブロックは置いた人がその場で設定する前提です。
複製すると別物になり、消しても記録は消えない
管理ブロックの属性が持っているのは管理IDだけです。このIDの扱いが、複製・削除まわりの挙動を決めています。
ブロックを複製したとき、コピーして貼り付けたとき、別の投稿へコピーしたとき、パターンとして挿入したとき。いずれもエディタ側で新しいIDが振られ、別の管理対象として扱われます（保存時にサーバー側でも重複を検出して再発行する保険つき）。料金表のブロックを別のサービスページへコピーしたら、期限も担当者も設定し直す前提で使ってください。同じ設定を2か所で共有する形にはしていません。
逆に、ブロックを本文から消した場合。管理対象は削除されず、「参照元ブロックなし」として無効化され、履歴はそのまま残ります。本文に戻せば再有効化される。うっかり消して「更新」を押しても、それまでの確認の記録が失われることはありません。
なお、自動保存・リビジョン・下書きプレビューでは管理対象を作りません。正規の投稿保存のときだけです。書きかけの段階でブロックを置いたり外したりしても、管理対象が増殖することはない。同期パターンの中で使うのは正式対応外で、置くと編集画面に注意が出ます。
期限が来たら、中身ではなく見せ方が変わる
ブロック単位の期限切れ処理は、管理画面で警告のみ／フロント画面でブロックを非表示／代替メッセージを表示、の3つから選びます。既定は「何もしない」で、設定画面から既定値を変えられます。
「一部分だけ管理する」ことの効きどころはここです。料金表の期限が過ぎたとき、記事全体は公開されたまま、料金表の範囲だけが「現在、この情報は確認中です。」という文言に差し替わる。ページを丸ごと下書きに戻す必要がない。文言は全体設定で変えられ、管理対象ごとに上書きもできるので、「最新の料金はお問い合わせください」のように場所ごとに変えて構いません。
差し替えはフロントのページ表示だけでなく、フィード・検索の抜粋・公開REST APIの描画結果にも効きます。一方でエディタの中では中身が表示されたままで、期限切れのバッジと警告枠が出る。本文はどこも書き換えられていない、ということが編集画面を開けば分かります。確認が完了すれば、非表示も代替メッセージも自動で解除されます。
タイミングは日単位で、期限日の翌日0:00以降の最初の毎時処理です。分単位で切り替わるものではありません。
投稿全体を下書き・非公開・リダイレクトにするほうの話は、記事単位の期限切れ処理と戻し方として別に書きました。
「更新」では保存されない——保存ボタンが別にある理由
ここが管理ブロックで一番つまずきやすいところで、先に言っておきます。
管理ブロックの担当者や次回確認日は、投稿の「更新」ボタンでは保存されません。ブロックを選んだときに出るインスペクタの「管理設定を保存」ボタンを押す必要があります。未保存のまま別の操作をしようとすると「保存していない変更があります」と出て、ブロックの選択を外すと入力は破棄されます（破棄した旨は画面上部に表示されます）。投稿単位・ACF・カスタムフィールドの設定は「更新」で一緒に保存されるので、ブロックだけ勝手が違う。
作っている側から言うと、これは不便を承知で選んだ形です。管理対象のデータの正本はプラグインのデータベースにあり、ブロックの属性が持つのは管理IDだけ、と決めました。属性を正本にすると何が起きるかというと、管理対象の一覧から担当者を一括で変えた直後に、誰かが開きっぱなしにしていた編集画面で「更新」を押すと、本文の古い属性が次の保存でデータベースを黙って上書きします。一括操作の結果が消えるのに、誰も気づけない。この壊れ方を避ける代わりに、ブロックだけは保存ボタンが別になりました。
確認作業画面（管理対象の詳細）でも、ブロックの中身は描画しません。投稿タイトルと、そのブロックへの編集リンクを出すだけです。中身を見るのは編集画面で、記録を残すのは詳細画面で、という分担になります。
動作環境として、管理ブロックはWordPress 6.6以上を要求します。ブロックのビルド成果物が6.6で追加された react-jsx-runtime に依存していて、6.5以前ではブロックが登録されないためです。動くふりをするより、満たさない環境では有効化できないようにしました。
製品ページは コンテンツ更新管理 にあります。
