更新期限をSlack・Chatwork・メールで知らせる：14日前・7日前・1日前、そして超過後

「あのページ、そろそろ見直しの時期ですよ」を、誰かがカレンダーで覚えていて口頭で伝えている——更新期限の管理がうまくいかない現場は、たいていここで止まっています。期限を決めるところまではできても、期限が近づいたことを本人に知らせる仕組みが無い。担当者が変わると、そのカレンダーごと消える。

コンテンツ更新管理はこの「知らせる」部分を担当者への通知として持っていて、数字で言うと次のようになります。通知のイベントは8種類、送り先はメール・Slack・Chatworkの3チャンネル。期限前の通知は「14日前・7日前・1日前」のように日数を複数指定でき、期限を過ぎたあとも「1日目・3日目・7日目」と段階を分けて送れる。送れなかった通知は毎時の定期処理で通算3回まで自動で再送し、それでも届かなければ通知ログに理由つきで残ります。

この記事は、その数字の中身です。何をいつ誰に送るのか、SlackとChatworkをつなぐのに何が要るのか、同じ通知が二重に飛ばないのはなぜか、届かなかったときにどう追うか。「あのページそろそろ見直し」を人の記憶で回している状態から抜けたい人向けに、設定する順で書きます。管理単位や期限の考え方そのものは柱の記事にあります。

何を、いつ、誰に送るか

イベントは次の8つです。宛先は管理対象ごとに指名した担当者・承認者・エスカレーション先で、ロールではなく個人のWordPressユーザーです。

イベント	いつ	メールの宛先	Slack・Chatwork
期限前	次回確認日のN日前（複数指定可）	担当者	選んだチャンネル＋担当者メンション
期限当日	次回確認日の当日	担当者	同上
期限超過	超過後N日目（複数指定可）	担当者	同上
エスカレーション	超過後の、期限超過通知とは別に決めた日	エスカレーション先と担当者	チャンネル＋両者メンション
承認依頼	担当者が確認結果を登録したとき	承認者	チャンネル＋承認者メンション
承認完了	承認者が承認したとき	担当者	チャンネル＋担当者メンション
差し戻し	承認者が差し戻したとき	担当者	同上
期限切れ処理の実行	期限超過で処理が走ったとき	担当者・承認者・エスカレーション先	選んだチャンネル

期限前と期限超過の日数は管理対象ごとに複数持てます。「14日前に一度、7日前にもう一度、前日にも」と段階を組んでおくと、1通見逃しても次が来る。エスカレーションの日数は期限超過通知とは別に設定し、担当者宛とは別の通知として記録されます。上長に「超過して3日経ちました」が届くのはこの経路です。期限当日の通知は全体設定の既定を管理対象ごとに上書きする形。

指名した個人以外にも送れます。通知設定の「追加のメール宛先」にメールアドレスと対象イベントを登録しておくと、部署の共有アドレスにも同じイベントが飛ぶ。対象イベントを選ばなければ全イベントが対象です。

SlackはIncoming Webhook、ChatworkはAPIトークンとルームID

3チャンネルのうち、メールはWordPressのメール送信機能をそのまま使うので準備は要りません。SlackとChatworkは接続を登録します。

接続はそれぞれ複数登録できます。「編集部のSlack」と「制作会社との共有Slack」を別の接続として持ち、管理対象ごとにどちらへ送るかを選ぶ、という形。Webhook URLとAPIトークンは登録後は画面上で伏せ字になり、入力欄に生の値は出ません。テスト送信の結果は通知ログ画面に出ます（管理対象の履歴には混ぜません）。

管理対象側では、通知チャンネルをメール／Slack／Chatworkから複数選び、SlackかChatworkを選ぶならそのチャンネルの送信先（登録した接続）を1つ以上選びます。通知イベントを1つでも有効にしているのにチャンネルが空だと保存できません。

メンションは、ユーザーのプロフィールにSlackのメンバーIDまたはChatworkのアカウントIDを登録してある人にだけ付きます。未登録なら表示名が書かれるだけで、通知は届いても本人の未読にはならない。ここは導入時に忘れやすいので、担当者になる人のプロフィール欄を先に埋めておく方が楽です。

なおSlackもChatworkも設定しなくて構いません。メールだけで成立します。接続を登録したときにだけ、管理対象の通知チャンネルにSlack・Chatworkが現れます。

同じ通知が二重に飛ばないのは、ユニークキーで弾いているから

定期処理はWP-Cronの毎時イベント1本で、期限の判定は「日」単位、基準はサイトのタイムゾーンです。予定時刻は該当日の0:00で、0:00以降に最初に走ったスイープで送ります。

WP-Cronはサイトへのアクセスで動くので、遅れることも、同じ日に何度も走ることもある。作っている側で決めていたのは、その前提で「何度走っても結果が変わらない」処理にすることでした。通知の重複防止は、送信前に「送ったかどうか」をフラグで調べる方式ではなく、「管理対象ID＋確認サイクルID＋イベント＋通知タイミング＋送信先」の組み合わせを通知ログのユニーク制約に置き、INSERTが通れば送る、通らなければ送らない、で判定しています。同じ日にスイープが3回走っても、7日前通知が3通になることはありません。テストで「2回実行して結果が変わらない」を直接確かめられるのも、この形にした理由のひとつです。

「確認サイクル」が単位に入っているのが要点で、確認が完了して次のサイクルに入ると、同じ段階の通知はまた送られます。前回「7日前」を送ったからといって、次の期限の7日前が黙ることはない。

遅延で複数の期限前段階をまとめて過ぎてしまったときは、遡って全部は送らず、いま有効な最新の段階だけを送ります。14日前と7日前を両方通り過ぎていたら、届くのは7日前の1通。

届かなかったとき：通知ログに残り、3回まで自動で再送する

送信に失敗した通知は、次回以降の毎時スイープで再送します。実質1時間おきで、通算3回で打ち切り。その後は「通知ログ」画面から手動で再送できます。

通知ログは、届かなかった通知と失敗の理由、接続テストの結果が並ぶ独立した画面です。送れた通知はここには出ず、管理対象ごとの履歴に残ります。失敗の理由には、Webhookのエラーだけでなく「送信先が解決できない」「接続が無効化されている」「メール通知が全体設定で無効」「投稿タイプが管理対象から外れて停止中」も含まれ、いずれも通知ログと履歴に1件残してダッシュボードに件数が出ます。

通知が黙って止まる状態を作らない、というのがここでの判断です。「ある日からSlackに来なくなった」ときに、cronが止まったのか接続を消したのかを切り分けられないのがいちばん困る。逆に、管理対象が参照している接続を削除できないようにする案は採りませんでした。Slackのワークスペース移行のような接続の統廃合ができなくなるからです。接続を消したら通知は失敗として記録され、ログで分かる。それで足りると考えました。

「送信先なし」の行には再送ボタンの代わりに案内が出ます。再送しても同じ結果になるので。担当者に指名していたユーザーが削除されて宛先が無い、というケースはここに出ます。

再送するときは、送信時に組み立てた本文をそのまま送り直します。差し戻し理由や確認コメントは通知ログの行に本文ごと保存してあるので、履歴が保持期間で消えていても、別件の理由が載ることはありません。送った通知が管理対象の履歴のほうにどう残るか（宛先と役割つき）は、確認の記録を残す話として別に書きました。

Slack・Chatworkには本文を載せない

通知の本文は3チャンネル共通で8項目です。通知種別、管理対象名、投稿タイトル、期限、期限状態、担当者、重要度、確認画面へのリンク。差し戻し理由と確認コメントは、記載があるときだけ行が足されます（チャンネル宛は200文字幅で丸め、メールは全文）。

メールにはさらに、サイト名・管理対象の種類・現在のステータス・承認者・次回確認日・期限超過日数・確認メモ・参照URL・投稿編集画面へのリンク・管理詳細画面へのリンクが付きます。

SlackとChatworkに載せないのは、投稿本文の抜粋、フィールドの値、確認メモです。チャンネルは誰が読めるかをWordPressの権限で縛れない場所なので、「料金表の中身」や「確認メモに書いた社内事情」がそこへ流れる設計にはしませんでした。チャンネル宛は「何が期限で、誰の担当か」までにして、中身は個人宛メールか管理画面で見る。管理対象名に <!channel> や [To:…] のようなメンション記法が入っていても通しません。

毎時の定期処理なので、分単位ではない

期限は日で判定し、通知は毎時のスイープで送ります。「期限日の朝9時ちょうどに届く」ような時刻指定はできず、該当日の0:00以降、cronが動いた最初のタイミングで飛びます。アクセスがほとんど無いサイトではWP-Cron自体が発火しないので、DISABLE_WP_CRON でコアのcronを止めている環境と同じく、サーバーのcronから wp cron event run --due-now を回してください。

送り先はSlack・Chatwork・メールの3つで、TeamsやLINEはありません。SlackとChatworkの中から承認や確認を済ませることもできず、通知はあくまで管理画面へ戻ってくるための入口です。

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