コンテンツ更新管理

「最終更新日」を見ても、中身が確認されたかどうかは分かりません

料金を改定した、法令が変わった、サービス名が変わった。そのたびに「どの記事が影響を受けるのか」を人が思い出して探すことになります。棚卸し用のスプレッドシートを作っても、担当者が異動すれば更新されなくなり、半年後には誰も見ていません。そして困るのは、たいてい記事全体ではなく「記事の中の料金表だけ」が古い——という形で起きることです。

やることは4つだけ — 貼る、知らせる、確認する、次へ進める

機能を1つずつ説明する前に、全体像から。このプラグインがやるのは次の4つで、どの機能もこのどれかに属します。

この流れから外れた——つまり確認されないまま次回確認日を過ぎたときに何をするかも、あらかじめ決めておけます。記事なら下書き・非公開・別URLへのリダイレクト、記事の一部ならその範囲だけを非表示にするか、差し替え文言を出すか。何もしない、という選択肢もあります（そしてそれが初期値です）。

読者に見えるページには通常なにも出力しません。表示が変わるのは、管理対象にした記事や範囲が期限を過ぎて、かつ期限切れ処理として非表示・差し替え・リダイレクトを選んでいたときだけです。期限切れ処理の初期値は投稿・管理ブロック・ACFフィールド・カスタムフィールドの4系統すべて「何もしない」なので、有効化しただけでは何も止まりません。

記事まるごとでも、記事の中の料金表1つでも。棚卸ししたい単位で貼れます

このプラグインの管理単位は4種類あります。1つの投稿に対して、どの単位でも貼れます（記事まるごとの管理は1投稿に1つ、ブロックとフィールドはいくつでも）。

そして4種類とも、設定できる項目は同じです——担当者・承認者・エスカレーション先・次回確認日・更新頻度・重要度・通知・期限切れ処理・確認メモ・参照URL。運用ステータス8種も、期限状態4種も、履歴も共通です。違うのは「期限が来たときに何をするか」の選択肢だけで、それが次の節の話になります。

1つの記事の中で「料金表は3か月ごと、注意事項は1年ごと」

本文にブロック「コンテンツ更新管理セクション」を置いて料金表を囲むと、その範囲がそのまま1つの管理単位になります。同じ記事にいくつ置いても互いに独立するので、料金表は3か月ごと・営業時間は6か月ごと・注意事項は1年ごと、と別々の期限と担当者を持たせられます。記事全体を止めずに、古くなる部分だけを管理できるということです。

• 複製しても、別の記事へ貼り付けても、二重管理になりません：それぞれ独立した管理単位として扱われ、コピー元の担当者と履歴はそのまま残ります。
• ブロックの管理設定は、投稿の「更新」とは別に保存します：サイドバーの「管理設定を保存」ボタンで確定します。未保存のまま投稿を更新したときや、ブロックの選択を外したときには、その旨がエディタ上部に出ます。
• ブロックを消しても履歴は消えません：本文から消えた管理対象は削除ではなく無効化され、その理由が履歴に残ります。元に戻せば再び有効になります。
• 編集画面では中身が隠れません：期限を過ぎているブロックには赤い枠と「期限切れ」バッジ、そして「この管理対象は期限を過ぎています。フロントの表示は期限切れ処理の設定に従います。」という警告が出るだけなので、直すべき場所がその場で見えます。
• 管理対象の一覧から、該当ブロックへ直行できます：詳細画面の「該当ブロックを編集」を押すと、編集画面が開いてそのブロックが選択された状態になります。

ブロックを置いただけでは管理は始まりません（自動保存やプレビューでは管理対象を作らず、正規の投稿保存で初めて管理対象になります）。管理ブロックだけは管理対象名が必須で、担当者と次回確認日を入れるまで管理設定を保存できません。ブロックの入れ子はできず、同期パターンの中では管理対象になりません。ブロックが使えるのは、管理対象に設定した投稿タイプの、ブロックエディタの本文だけです。

期限が来たときの扱いを、単位ごとに選べます

「期限切れ処理」は、確認しないまま次回確認日を過ぎたときに何をするかの設定です。選択肢は管理単位ごとに違います。画面に出るとおりに並べると、こうなります。

• 投稿（5つ）：「何もしない」／「管理画面で警告のみ」／「投稿を下書きへ変更」／「投稿を非公開へ変更」／「指定 URL へリダイレクト」
• 管理ブロック（4つ）：「何もしない」／「管理画面で警告のみ」／「ブロックを非表示」（ブロックのサイドバーでは「フロントで非表示」と表示されます）／「代替メッセージを表示」
• ACF フィールド（3つ）：「何もしない」／「管理画面で警告のみ」／「通知のみ」
• カスタムフィールド（3つ）：ACFと同じく「何もしない」／「管理画面で警告のみ」／「通知のみ」

選ぶのは管理対象ごとなので、「終了したキャンペーン記事は下書きへ、統合した旧記事は新しい記事へ301リダイレクト、社内向けの手順書は管理画面で警告だけ」を1つのプラグインで同時に回せます。全部を同じ強さで止める必要はありません。

記事の一部を管理しているときは、その範囲だけをフロントから消すか、「代替メッセージを表示」で差し替えるかを選べます。差し替え文言の初期値は「現在、この情報は確認中です。」で、全体設定でもブロックごとでも変えられます。黙って消すのではなく「いま確認中です」と読者に伝えられる、ということです。

差し替えは表示のときだけ行う処理なので、本文は書き換わりません。しかも差し替えを行う場所がひとつしかないため、ページ表示だけでなくフィード・抜粋・公開REST APIの結果にも同じように効きます。「サイトでは消えているのにRSSには残っている」が起きません。

「投稿を下書きへ変更」「投稿を非公開へ変更」「指定 URL へリダイレクト」が効き始めるのは、毎時の定期処理が期限切れ処理を実行したあとです（リダイレクトはさらに最大5分のキャッシュがあります）。「管理画面で警告のみ」と、管理ブロックの非表示・代替メッセージは、期限を過ぎた時点から画面に反映されます。いずれも解除されるのは確認を完了したときだけで、次回確認日を先へずらしても外れません。下書き・非公開にした投稿を公開へ戻すのは「以前の公開状態へ戻す」の明示操作で、自動では戻りません（確認が終わったら勝手に再公開されていた、が起きない設計です）。

止めるのは公開状態と表示だけ。原稿の文章には手を入れません

公開記事を止められる仕組みを入れるとき、いちばん怖いのは「本文が壊れること」です。このプラグインが投稿単位の管理でWordPressに渡すのは、投稿IDと投稿ステータスだけです。期限切れ処理と「以前の公開状態へ戻す」の2か所で投稿を更新しますが、どちらも渡すのはこの2つで、本文・タイトル・抜粋には触れません。フロント表示に割り込むフィルター（the_content）も1つも登録していません。

リダイレクトも投稿ステータスを変えません。読者を指定したURLへ送りつつ、その記事をサイト内検索・フィード・アーカイブ・ブログ投稿一覧から外すだけです。読者が古い記事にたどり着く経路そのものが閉じます。

ACFフィールドとカスタムフィールドの期限切れ処理が3択しかないのも同じ理由です。フィールドの値がどのテーマ・プラグインから出力されるか分からない以上、値の削除も自動非表示もしません。投稿編集画面のフィールド用メタボックスにも「フィールドの値は期限切れでも変更されません。」と明示されています。

入れた初日に、公開中の記事が止まることはありません

この製品は「公開記事を下書きに落とせる」機能を持っています。だから初期状態は徹底して安全側に倒してあります。設定作業を後回しにしても、事故が起きないという意味です。

• 有効化した時点で管理対象は0件です：設定画面で決めるのは「管理対象にできる投稿タイプの候補」までで、管理対象は投稿編集画面・ブロックの配置・運用ルールの適用で作られます。サンプルのルールや管理対象が勝手に入ることもありません。
• 期限切れ処理の初期値は、4系統すべて「何もしない」です：投稿・管理ブロック・ACFフィールド・カスタムフィールドのどれも、明示的に変えるまで何も起きません。
• 期限当日通知の初期値は「送らない」です：送るように設定を変えたときにだけ届きます。
• 履歴保持期間の初期値は0（無期限）です：期間を設定しない限り、履歴は1件も消えません。
• アンインストール時のデータ削除の初期値は「すべてのデータを保持」です：プラグインを停止（無効化）しただけでは何も消えず、止まるのは定期処理だけです。

記事の公開状態が変わるのは、その記事を管理対象にしたうえで、期限切れ処理として「投稿を下書きへ変更」または「投稿を非公開へ変更」を明示的に選び、さらに次回確認日を過ぎたとき——この3つが揃ったときだけです。まずは1本の記事に担当者と次回確認日を貼るところから始められます。

登場人物は4人。誰のボールかが、いつでも1人に決まります

棚卸しが止まる原因のほとんどは「誰の番か分からない」ことです。この製品では、管理対象1つごとに次の役を指名します。指名できるのはそれぞれWordPressユーザー1人ずつで、部署やチーム単位の割り当てには対応していません。

• 担当者

  必須 ／ 中身を見る人

  確認作業を進め、結果を登録します。期限前・期限当日・期限超過の通知が届くのはこの人です。

  指名できる条件「確認を実行」の権限があり、かつその投稿を実際に開けること。人選の時点で弾かれるので、担当なのに画面が開けない行が混ざりません。

• 承認者

  任意 ／ 通すか止めるかを決める人

  設定すると、担当者が結果を登録しても完了にならず、承認されるまで「承認待ち」で止まります。差し戻すときは理由が要ります。

  指名できる条件「承認を実行」の権限。担当者との兼任はできません（同じ人を両方に指定すると保存が通りません）。

• エスカレーション先

  任意 ／ 遅れの連絡だけ受ける人

  期限を指定日数だけ超えたときに通知が届きます。通知を受け取るだけで、操作の権限は伴いません——だから上の図でもフローを動かす側には現れません。

  指名できる条件専用の権限は不要（候補に出るのは購読者以外のロールのユーザーです）。プラグインを触らせたくない責任者にも、遅れの連絡だけ届けられます。

• 管理者

  サイト全体 ／ 設計する人

  設定・運用ルール・通知ログの3画面と、ダッシュボードを開けます。担当者・承認者・エスカレーション先の付け替えができるのはこの人だけです。

  指名できる条件指名する対象ではなく、WordPressのロールに紐づく権限です。詳しくは下の「誰に何を触らせるか」を参照。

担当者とエスカレーション先を同じ人にすることはできますが、保存時に警告が出ます（1人に集約すると、遅れに気づく人がいなくなるためです）。指名した人をユーザーごと削除した場合も一覧はエラーにならず、その行が「ユーザー未設定」と表示されます。指名した人がその管理対象を開けなくなっただけの場合は、その人は実在するので行の表示は変わりません。どちらも一覧の上部に、管理者向けの警告がそれぞれ別に出ます。

「見た／見ていない」ではなく、どこまで進んだかが残ります

運用ステータスは8種類（「未対応」「確認中」「修正中」「承認待ち」「差し戻し」「完了・更新あり」「完了・変更なし」「完了・対象外」）、操作は7種類（「対応開始」「修正開始」「確認結果を登録」「承認」「差し戻し」「承認依頼を取り下げ」「対応再開」）。確認作業の画面には、いまのステータスで実行できる操作だけが並びます。「今どれを押していいのか」を担当者が判断する必要がありません。

下の図で、紫の実線は人が押して動く区間、灰色の破線はシステムが動かす区間です。自動で動くのは2か所しかありません。

1. 未対応

   確認作業がまだ始まっていない状態。新しく管理対象を作ったときと、次の確認回に入ったときがここです。

   担当者「対応開始」を押す

2. 確認中

   中身を見ている状態。直す必要があれば「修正開始」で修正中へ移り、そのまま結果を登録することもできます。

   担当者確認結果（「内容を更新した」／「確認したが変更不要」／「対応対象外と判断した」）を登録する

3. ここで道が2つに分かれます

   分かれ目は承認者を設定しているかどうかだけです。担当者の操作は同じで、「承認依頼」という別のボタンはありません。

   承認者なし

   登録した時点で完了。確認結果に応じて「完了・更新あり」「完了・変更なし」「完了・対象外」のいずれかになります。

   承認者あり

   承認待ちへ進み、承認されるまで完了になりません。完了の種類は担当者の結論のままで、承認者は書き換えられません。

4. 承認待ち

   承認者のボールになった状態。ここで初めて承認者に通知が届きます。

   承認者「承認」を押す

   本筋から外れる道が3つあります。 承認者が差し戻すと「差し戻し」へ（理由の入力が必須で、理由は履歴と通知本文の両方に残ります）。担当者が「対応再開」を押すと修正中へ戻ります。 承認を待たずに取り下げることもでき、これは担当者に限らず確認を実行できる人なら実行できます。 そして承認待ちの間に中身が書き換わったら、承認は自動で無効になり修正中へ戻ります——承認の空手形が通りません。

5. 完了・更新あり／完了・変更なし／完了・対象外

   確認が終わった状態。この時点の中身が「確認基準値」として控えられ、以後の変更はここと比べて検出されます。

自動 次の確認回へ戻すのはシステムの仕事です。完了した管理対象は、次回確認日が期限接近の範囲に入ったあとの毎時の定期処理で「未対応」に戻り、確認回の番号が1つ進みます。人が翌回の予定を立て直す必要はありません。

• 確認結果は3種類です：「内容を更新した」／「確認したが変更不要」／「対応対象外と判断した」。「見たけれど直す必要が無かった」が記録に残るので、次の担当者が同じ調査をやり直さずに済みます。
• 承認待ちの間に中身が書き換わったら、承認は自動的に無効になります：ステータスが「修正中」へ戻り、履歴に「承認待ちの間に対象の内容が変更されたため、承認を無効化しました。」が残ります。承認の空手形が通りません。
• 完了の種類は担当者の結論に従います：承認者ができるのは承認するか差し戻すかで、完了の種類を書き換えることはできません（確認結果が登録されていなければ承認自体ができません）。
• 差し戻しには理由が必須です：空欄や空白だけでは通りません。理由は管理対象と履歴の両方に残り、差し戻しの通知本文にも載ります。
• 担当者が休んでも運用が止まりません：作業を進められるかどうかを決めるのは、いまの運用ステータスと権限だけで、「担当者として指名されているか」は条件に入っていません。指名が効くのは通知の宛先と「自分の担当」画面の絞り込みです。

承認のやり取りを、3つの場面で通してみます

上の図は「対象がどの状態を通るか」を描いたものでした。ここでは縦の3本線が「担当者」「システム」「承認者」の持ち場で、横の矢印がその間を実際に行き来するものです。線の意味は上と同じで、実線は人が押した操作、破線はシステムが送る通知——押した人がいない線です。

場面3では通知が飛びません（通知イベントは8種類で、承認の無効化はそこに含まれません）。気づく場所は管理対象の詳細画面と履歴です。

「承認依頼」という操作はありません。「確認結果を登録」が、承認者を設定していれば自動的に承認待ちへ送ります（承認者を設定していなければ、その時点で完了です）。承認は1人・1段階で、複数段階の承認や部署・チーム単位の割り当てには対応していません。画面のボタン名と履歴に残る名前は別で、たとえばボタンは「対応開始」、履歴には「確認作業開始」と出ます。担当者と承認者を同じ人にすることはできません。

「四半期ごとに見直す」を、カレンダー登録に頼らない

更新頻度を決めておくと、確認が完了したときに次回確認日が自動で先へ進みます。基準になるのは元の期限ではなく実際に確認が完了した日（承認者がいれば承認した日、いなければ確認結果を登録した日）です。月単位・年単位で加算した先にその日が存在しないとき（1月31日の1か月後など）は月末日へ丸めるので、日付が壊れません。

さらに、完了した管理対象は、次回確認日が「期限接近」の範囲に入った時点で自動的に「未対応」へ戻り、新しい確認回として履歴が分かれます。前回の確認で何があったかを、回ごとに切り分けて読めるということです。

完了した対象が「未対応」へ戻るのは、次回確認日が期限接近の範囲に入ってから、しかも次の毎時の定期処理のときです（完了した瞬間に戻るわけではありません）。前回確認からの変更を検出しても次回確認日は動きません——「触ったから確認したことにする」が起きない設計です。期限を過ぎても運用ステータスが勝手に変わることもありません（作業がどこまで進んだかと、日付的にどうかは別の軸として扱います）。

管理画面を開いた瞬間に、「今日やること」が件数になる

ダッシュボードには集計カードが8枚並びます——「本日期限」「期限接近」「期限前」「期限超過」「承認待ち」「差し戻し」「前回確認後に変更あり」「重大・未対応」。どのカードを押しても、同じ条件で絞り込んだ管理対象一覧に着きます（件数と中身が必ず一致します）。「更新が止まっているページ」を探しに行く作業そのものが要らなくなります。

• 一覧は12列：管理対象名・種類・投稿タイトル・投稿タイプ・担当者・承認者・重要度・運用ステータス・期限状態・次回確認日・最終確認日・前回確認後の変更。9軸で絞り込めて、1ページ50件です。
• 期限状態は保存値ではなく、読み出すたびに今日の日付で計算し直します：定期処理が遅れているサイトでも、「期限超過なのに期限前と表示される」ことがありません。一覧が嘘をつかない、ということです。
• 担当者の入口は「自分の担当」画面です：「すべて」を含む7つのタブ（本日期限・期限接近・期限超過・承認待ち・差し戻し・対応完了）で、自分が担当者の行だけが並びます（承認者・エスカレーション先として関わる行は「管理対象一覧」から開きます）。担当者になるライターに教えるのはこの1画面だけで運用が始まります。
• 選んだ行にまとめて適用できます：一括操作は8種（担当者変更・承認者変更・エスカレーション先変更・次回確認日変更・更新頻度変更・重要度変更・通知設定変更・管理対象の無効化）。条件を満たさず飛ばした行は「権限が足りないため 2 件、担当者と承認者が同じため 1 件をスキップしました。」のように理由ごとの内訳で返ります。件数だけを返す一括操作と違い、あとで気づく事故になりません。
• 設定が矛盾していると、気づく前に画面が教えてくれます：「メール通知を全体で切ったのにメールを選んでいる管理対象がN件」「期限当日通知が有効なのに通知チャンネルが未設定の管理対象がN件」「通知の送信先を解決できない管理対象がN件」「期限切れ処理が『管理画面で警告のみ』で確認が必要な管理対象がN件」を件数付きで出します。

列見出しをクリックした並び替えやキーワード検索はなく、1ページの表示件数は50件で固定です。一括操作のチェックボックス列が出るのは、管理対象全体を管理する権限を持つ人（初期状態では管理者）だけです。ダッシュボードとライセンス画面を開けるのはサイトの管理権限を持つ人だけで、担当者は「自分の担当」から入ります。管理対象の詳細画面はメニューには出ず、一覧の管理対象名から開きます。管理画面の操作はすべて通常のPOSTで、admin-ajax.phpは1か所も使いません。

通知は「届かなかった理由」まで残ります

通知イベントは8種類（「期限前」「期限当日」「期限超過」「エスカレーション」「承認依頼」「承認完了」「差し戻し」「期限切れ処理実行」）、チャンネルは3種類（「メール」「Slack」「Chatwork」）です。期限前・期限超過は「14日前・7日前・1日前」のように日数を複数指定できます。

メールは「人」に届き、Slack・Chatworkは「部屋」に届きます。宛先の単位がそもそも違います。メールは役割で宛先が決まり（たとえばエスカレーションなら エスカレーション先 → 担当者 の2通、期限切れ処理実行なら 担当者 → 承認者 → エスカレーション先 の3通）、Slack・Chatworkは管理対象ごとに選んだ接続——つまりチャンネルやルーム——へ届きます。この2系統とは別に、全体設定に「追加のメール宛先」を登録しておくと、イベントを選んで同じメールをそのアドレスにも届けられます（役割とは無関係の固定の宛先です。下の表は役割で決まる宛先だけを並べています）。

メールが届く 選択した接続へ投稿される 届かない ＠ … メンションが付く（プロフィールにIDを登録している場合）

だからSlack・Chatworkには記事の中身を載せません。載るのは通知の種類・管理対象名・投稿タイトル・期限・期限状態・担当者・重要度・確認画面へのリンクと、差し戻し理由や確認コメントだけ。管理対象に書いた「確認メモ」・参照URL・現在のステータス・期限超過日数といった詳細項目は、個人宛のメールにだけ載ります（記事本文の抜粋やフィールドの値は、メールにも載せません）。チャンネルやルームは編集権限のない人も見られる場所だからです。

• 定期処理が半日止まっても、復旧した瞬間に何十通も降ってきません：「14日前・7日前・1日前」を設定していて残り5日で復旧したなら、送るのは「7日前」の1通だけです。過ぎてしまった段階を遡ってまとめ送りしません。
• 同じ通知が二度飛ばないことを、データベースの制約で保証しています：管理対象・確認回・イベント・タイミング・宛先の組み合わせを一意キーとして先に登録し、登録できたときだけ送ります。アプリケーション側のフラグではないので、定期処理が二重に走っても届く通数は変わりません。
• 確認が一巡すれば、同じ「7日前」がまたきちんと鳴ります：確認回が変わると一意キーも変わるためです。
• 「送らなかった」ことも記録に残ります：メール通知が全体設定で無効／通知チャンネルが未設定／宛先を解決できない／管理対象が停止中——この4つは、送らなかったこと自体を理由の文言つきで1件だけ残します。うち3つ（メール通知が全体で無効／期限当日通知のチャンネルが未設定／宛先を解決できない）は、ダッシュボードにも件数で警告が出ます。定期処理の故障なのか設定ミスなのかを、運用者が自分で切り分けられます。
• Slackが落ちていても、メールとChatworkは届きます：チャンネルと宛先ごとに送って結果を1件ずつ記録するので、1つの障害が他を巻き込みません。
• 失敗した通知は自動で拾い直します：毎時の定期処理が失敗分を再送し、通算3回の試行で打ち切ります。手動の再送は「通知ログ」画面のボタンからいつでもでき、打ち切ったあとの行も送り直せます。

「通知ログ」画面には通知失敗履歴20件と接続テスト履歴10件が並び、エラー内容を定型文に丸めず、返ってきたまま出します（HTTP 403 なのか名前解決の失敗なのかで、やるべきことが違うからです）。

Slack の Incoming Webhook URL と Chatwork の APIトークンは、登録した本人にも画面で全部は見えません。先頭4文字と末尾4文字だけを残して伏せ字にし（12文字以下は全体を伏せます）、入力欄には値を出さずプレースホルダとして表示します。空のまま保存すれば既存の値は消えないので、貼り直す必要もありません。管理画面を他部署に見せても秘密情報が漏れない、ということです。

テスト送信があるのは Slack と Chatwork だけです（メールにはありません）。通知ログに出るのは失敗と接続テストで、送信できた通知は管理対象ごとの履歴に残ります。担当者へのメンションは、ユーザープロフィール画面に「Slack メンバー ID」「Chatwork アカウント ID」を登録しておくと付きます（未登録でも通知は届き、表示名だけが書かれます）。メールの送信自体はWordPressのwp_mail()に任せているため、SMTPの設定項目は持ちません。通知ログ画面と設定画面を開けるのは、初期状態では管理者だけです。

価格や仕様の「その項目だけ」を、月次で確認する

ACFフィールドとカスタムフィールドは、投稿編集画面の専用メタボックス（「コンテンツ更新管理（ACF フィールド）」／「コンテンツ更新管理（カスタムフィールド）」）から1つずつ管理対象に追加します。ACF自身の入力欄には割り込まず、独自の保存ボタンも持ちません——投稿の「更新」ボタン1つで確定します。

「ACFを止めたら全フィールドが変更ありになった」も起きません（停止中は変更検出そのものを止めます）。止まっていた期間の通知が復旧の瞬間にまとめて飛ぶこともありません。停止中でも進行中の確認・承認は最後まで終わらせられます。そしてACFを入れていなくても、投稿単位・管理ブロック単位・カスタムフィールド単位の管理はそのまま使えます。

変更の判定は、値をそろえてから比べます。連想配列のキー順の入れ替えは無視し、1.0と1.00は同じとみなし、「未設定」と「空文字」と0は型まで見て区別します。改行や前後の空白の違いだけでは「変更あり」になりません。単純な値なら、詳細画面に「確認基準値」と「現在値」が並んで出るので、前回確認したときから何がどう変わったかを、投稿を開かずに読めます。

管理できる単位はフィールド1つずつです（リピーターの行単位、Flexible Content のレイアウト単位、グループ内のサブフィールドを単独で管理することはできません。リピーター・グループ・Flexible Content は全体で1つの管理対象になります）。1つのメタボックスで入力欄が出るのは上から12行までで、それ以降は表示のみになります（ACF用とカスタムフィールド用は別のメタボックスなので、それぞれ12行まで数えます）。WordPress内部の予約されたメタキーは管理者でも登録できません。

数百本の既存記事にも、これから増える記事にも

「この投稿タイプ × このカテゴリーなら、担当者は誰・更新頻度は何か月・通知はどうする・期限が来たらどうする」を運用ルールとして登録すると、条件に一致する新しい記事は最初から担当者と次回確認日が入った状態で生まれます。次回確認日は「適用した日 + 更新頻度」で自動計算されます。管理画面から作っても、RESTでも、移行スクリプトで流し込んでも同じように効くので、編集画面だけの機能ではありません。

既存の記事にすでに入っている管理設定が書き換わるのは、管理者が一括適用を実行したときだけです。既存の記事を保存したときも運用ルールは働きますが、そのときするのは「条件に一致していて、管理対象がまだ無い」ぶんを足すことだけで、入っている設定には触りません。一括適用は実行前に「条件に一致する投稿」「うち、この種類の管理対象が既にある投稿」「管理対象がまだ無い投稿」の3つが件数で出るので、押す前に規模が分かります。

• 既にある設定の扱いは3つから選べます：「未設定の項目だけ補完する（既定）」／「そのままにする（不足している管理対象だけ作る）」／「ルールの初期設定で上書きする」。既定は空欄だけを埋めるので、人が決めた担当者や重要度が黙って書き換わりません（どのモードでも、不足している管理対象は作られます）。
• 数千件でもブラウザを閉じて構いません：1つのジョブで扱えるのは2000投稿まで、50投稿ずつ進みます。途中でタブを閉じても定期処理が引き継ぎます。JavaScriptを使わないので、管理画面にJSを足す他プラグインと干渉しません。
• ルールが複数一致しても、どれが効いたかが必ず1つに決まります：優先順位（1〜999。小さいほど上位）で「管理対象の種類 + 対象キー」ごとに上位のルールが取ります。ルールを重ねても設定が混ざりません。
• ルールを無効化・削除しても、それまでに入った管理設定は残ります：確認ダイアログにも「このルールを削除します。適用済みの管理設定は残ります。」と出ます。「試しにルールを作って消す」が安全にできます。
• 担当者に指定した人がその記事を開けない場合は、黙って設定しません：理由を履歴に残すので、「担当なのに作業画面に入れない」行ができません。

運用ルールで指定できないものが3つあります——「指定 URL へリダイレクト」（リダイレクト先が投稿ごとに違うため、投稿の編集画面から設定します）、期限当日通知、エスカレーション日数。管理ブロックはルールから作れません（本文に置いたときにだけ生まれ、ルールは初期値を与える役割です）。カテゴリー等の条件は完全一致で、子タームは含みません。複数選んだときは、どれか1つに一致すれば対象になります。運用ルール画面を開けるのは、初期状態では管理者だけです。

誰に何を触らせるかは、WordPressのロールのまま設計できます

専用の権限は5種類（管理対象全体を管理／管理対象を編集／確認を実行／承認を実行／設定を変更）で、有効化した時点で3つのロールに仕分けされます。

あとから権限管理プラグインで組み替えても、アップデートで元に戻されることはありません（権限の付与は初回インストール時の一度きりです）。「投稿者から管理対象の編集を外した」といった運用を、更新のたびに設定し直す必要がありません。

そしてエスカレーション先だけは専用の権限を問いません。プラグインを触らせたくない責任者にも、「N日過ぎたら知らせる」だけを届けられます（購読者ロールは候補から外れます）。

担当者・承認者に指定できるのは、確認・承認の権限を持ち、かつその投稿を実際に開けるユーザーです。人選の時点で弾かれるので、「担当に指名されたのに画面が開けない」行が運用に混ざりません。ダッシュボードとライセンス画面はサイトの管理権限（manage_options）が必要です。3つの役割はいずれもWordPressユーザーの単一選択で、部署・チーム単位の割り当てには対応していません。

「なぜこのページが止まったのか」を、後から説明できる

管理対象の作成、担当者や次回確認日の変更、確認作業の開始、確認結果の登録、承認、差し戻し、通知の送信・失敗・再送、期限切れ処理の実行と解除——17種類の操作が追記型の台帳に並びます。定期処理や運用ルールによる自動処理も、実行者「システム」として同じ台帳に載ります。

• 「何から何へ変わったか」まで残ります：担当者・承認者・エスカレーション先・次回確認日・ステータスは変更前後の値を保存し、画面ではユーザーIDを表示名に、コードを日本語ラベルに直して出します。未設定は「（未設定）」と明示されるので、空欄と区別がつきます。
• 通常の操作では消せません：消える経路は2つだけ——保持期間を設定したときの自動削除と、アンインストール時の「管理設定と履歴をすべて削除」。しかも保持期間の初期値は無期限です。
• 本文の差分はWordPress標準のリビジョン比較へそのまま繋がります：変更が検出された投稿・管理ブロックには詳細画面から「リビジョンを比較」のリンクが出ます。独自の差分ビューアを覚え直す必要がありません。
• 履歴は確認回で束ねられます：1件ごとに「何巡目の確認か」を記録しているので、「前回の確認では何があったか」を回ごとに切り分けて読めます。管理対象の詳細画面には直近30件、投稿の編集画面には「履歴（最新 10 件）」が出ます。

止まっても壊れない

• 定期処理が数日止まっていても、復旧した最初の1回で追いつきます：実行時刻を条件にせず、「いま処理すべきで、まだ処理済み記録のない対象」を毎回抽出し直すためです。
• 期限切れ処理は「1つの確認回につき1回だけ」：毎時走っても、公開記事が何度も下書きに落とされることがありません。確認が一巡すれば、同じ設定でまた効き始めます。
• 1回の処理は打ち切って、続きを次回へ回します：管理対象200件・履歴の刈り込み200件・通知の再送50件。巡回位置を保存するので、数千件を登録しても毎時のバッチがタイムアウトで落ちる形になりません。
• wp-cron.phpは誰でも叩ける、という前提で作ってあります：多重起動の抑止は「読んでから書く」ではなくデータベースのユニーク制約で行い、取り残されたロックは300秒で掃除します。アクセスが集中する瞬間に定期処理が二重に走って通知が二重化する、が起きません。

コンテンツ更新管理そのものの定期処理は毎時のもの1本と、ACFのフィールド定義を点検する日次のもの1本の計2本です（このほかにライセンス確認の日次処理が1本動きます）。実行の間隔はWordPress標準のcronに従うため、アクセスの少ないサイトでは最大1時間ほど遅れることがあります。日時はすべてサイトのタイムゾーンで記録されます。

スプレッドシートでの棚卸しと、何が違う？

公開後のコンテンツを古くさせない方法はいくつかあります。判断材料として、運用のやり方ごとに観点を整理します。

※ 左の2列は一般的な運用のしかたを整理したもので、実際の運用により異なります。本プラグインの列は本製品の仕様です。

どんなサイトで役立つ？

入れたあとに困らないための備え

• 管理対象から外しても、記録は消えません：チェックを外すのは「削除」ではなく「無効化」で、行も履歴も残り、入れ直せば戻ります。投稿をゴミ箱に入れた場合も、戻せば管理も戻ります。
• 投稿タイプを管理対象から外しても、データは書き換わりません：一覧には「停止中」として残り、チェックを戻せば手作業ゼロで復帰します。止まるのは通知・期限切れ処理・変更検出の3つで、進行中の確認・承認は最後まで終わらせられます。
• 管理画面を汚しません：専用CSSは自プラグインの画面と、管理対象にした投稿タイプの編集画面だけ。JSを読み込むのは一覧2画面と、管理対象にした投稿タイプのブロックエディタ（保存結果の通知用）だけです。例外は管理ブロックそのもののエディタ用ファイルで、これはWordPressにブロックとして登録する以上、どの投稿タイプのブロックエディタでも読み込まれます。他プラグインの多いサイトでも見た目と挙動を邪魔しません。
• 設定が途中で切れて黙って消える事故を、プラグイン側が検出して止めます：PHPのmax_input_vars超過を検出したら保存を丸ごと中止して理由を出すので、共有サーバーで通知先やカタログが黙って消えることがありません。
• 削除するときの範囲を選べます：「すべてのデータを保持」（初期値）／「プラグイン設定のみ削除」／「管理設定と履歴をすべて削除」の3択。初期値は何も消さないので、入れ替え検証で運用記録を失いません。
• 有効なライセンスがあれば、管理画面から通常のプラグインと同じ操作で最新版へ自動アップデート。ライセンスは1サイトでアクティベートし、解除すれば別のサイトへ移し替えできます。
• ライセンスの期限が切れても、現場の運用は止まりません：止まるのはアップデートの受け取りとバグ報告だけで、管理対象の設定・通知・確認と承認のワークフロー・履歴・期限切れ処理はそのまま動き続けます。

動作環境

• WordPress6.6 以上
• PHP8.1 以上
• 確認済みWordPress 7.0
• エディタブロックエディタ / クラシックエディタ
• 言語日本語

通知と期限切れ処理は毎時の定期処理で動くため WP-Cron を使います（DISABLE_WP_CRON でコアの cron を止めている場合は、サーバーの cron から wp cron event run --due-now を実行してください）。ACFフィールドの管理には Advanced Custom Fields が必要です（無い場合、ACFの機能だけが表示されません）。Slack への通知には Incoming Webhook の URL、Chatwork への通知には APIトークンとルームID が必要です。マルチサイトでは検証していません。投稿・ACFフィールド・カスタムフィールドのメタボックスはブロックエディタでもクラシックエディタでも表示されますが、「コンテンツ更新管理セクション」ブロックはブロックエディタ専用です。管理画面の表示は日本語のみです。