「この料金表、いつ誰が確認しました？」と聞かれて、答えられるでしょうか。
Slackのログをさかのぼれば「確認しました」の一言は見つかるかもしれない。でもそれが料金表のどの版に対する確認で、その後に誰かが触っていないかまでは、チャットからは分かりません。確認した事実は、確認した人の記憶と、流れていくチャットの中にだけある。半年後に「なぜ古い料金が載っていたのか」を説明する場面で、これは弱い。
コンテンツ更新管理は、確認の記録を管理対象ごとの履歴としてWordPressの中に残します。この記事は、その履歴に何が残り、誰が見られて、いつ消えるかの話です。「監査ログ」と呼ばない理由も最後に書きます。期限と担当者を持たせる全体の枠組みは柱の記事にあります。
17種類の操作が、変更前と変更後の値つきで残る
履歴に記録される操作は17種類です。管理対象の作成、管理設定の変更、担当者・承認者・エスカレーション先の変更、次回確認日の変更、ステータス変更、確認作業の開始、確認結果の登録、承認依頼、承認、差し戻し、通知の送信と失敗、期限切れ処理の実行と解除、通知の再送。
各行が持つのは、実行日時、実行ユーザー、操作種別、変更前の値、変更後の値、コメント、通知チャンネル、通知結果（種別ごとに該当するものだけ）。定期処理や運用ルールによる自動適用は実行ユーザーが「システム」になります。
要点は「変更前の値」と「変更後の値」を両方持っていることです。担当者をAさんからBさんに変えたら「A → B」、次回確認日を動かしたら「3月31日 → 6月30日」と、投稿編集画面のメタボックスと詳細画面の両方に出ます。「変更された」という事実だけでは、時間が経ってから見返したときに何から何へ変わったのか復元できない。設計の段階で、履歴は「そのとき何が起きたか」を後の状態に依存せずに読めるものにする、と決めていました。
確認結果も「内容を更新した」「確認したが変更不要」「対応対象外」の3種のどれかで残るので、「見たけど変えていない」が記録になります。これが無いと、変更が無かった期間は「誰も見ていなかった」のか「見て問題なしだった」のか区別が付きません。差し戻しは理由と一緒に残り、期限切れ処理は実行と解除がそれぞれ1行になる。手動で先に下書きにしてあった投稿に期限切れ処理が回ってきたときは「処理不要」と記録され、何もしなかったことも残ります。
通知は「誰宛に、どの役割で」まで残す
通知を送った記録も履歴に入ります。行に出るのは、チャンネル（メール／Slack／Chatwork）、役割（担当者／承認者／エスカレーション先／追加宛先）、送信先（メールアドレス、または接続の登録名）。同じイベントで3通送っても、同じ見た目の行が3つ並ぶのではなく、「メールで担当者の◯◯宛」「Slackで編集部チャンネル宛」と区別が付きます。
役割は送信した時点で行に書き込みます。表示するときに「いまの担当者は誰か」を引いて役割を推定する作り方もあり得たのですが、それだと担当者をAさんからBさんに変えたあとで、過去の通知の行の役割が変わってしまう。履歴は「そのとき何が起きたか」の記録で、後の設定変更で意味が変わってはいけない——作っている側として、通知の役割まで送信時に固定したのはその考え方の延長です。
届かなかった通知は履歴に「通知失敗」として1行残り、失敗の理由・接続テストの結果・手動再送は「通知ログ」という別の画面で扱います。通知が届かないときの追い方は通知の記事に書いたので、ここでは「送った・送れなかったの両方が管理対象の履歴に残る」ところまでにします。接続のテスト送信だけは、管理対象の記録ではないので履歴には入りません。
誰が履歴を見られるか
全件の履歴を見られるのは、管理対象全体を管理する権限を持つ人か、他人の投稿を編集できる人（既定では管理者・編集者）です。それ以外の人が見られるのは、自分が閲覧できる管理対象の履歴だけ。一覧に出る管理対象は、自分が担当者・承認者・エスカレーション先に指名されている行と、自分が作成者でその投稿タイプを編集できる行で、履歴もその範囲に従います。
履歴は管理対象の詳細画面と、投稿編集画面のメタボックスの両方に出ます。確認する人はいつもの編集画面から、管理する人はダッシュボードから管理対象を辿って、どちらからでも同じ履歴に届く。
消えるのは、保持期間が過ぎたときとアンインストールのときだけ
履歴は通常の操作では編集も削除もできません。管理画面に「この行を消す」ボタンは無く、管理対象そのものを無効化しても、親の投稿を削除しても履歴は残ります。投稿がゴミ箱に入れば管理対象は無効化され、戻せば再有効化され、完全削除されれば論理削除になる——いずれも理由つきで履歴に1行足されるだけで、過去の行は消えません。
消える経路は2つです。ひとつは基本設定の「履歴保持期間」。日数を決めるか無期限にするかを選び、日数を決めた場合は定期処理が1日1回、期限を過ぎた行を一定件数ずつ刈り込みます。もうひとつはアンインストールで、「管理設定と履歴をすべて削除」を選んだときだけ消えます。既定は「すべてのデータを保持」なので、プラグインを消しても履歴は残る。無効化しただけなら何も消えません。
保持期間を決めるときは、「何年後に説明を求められる可能性があるか」から逆算するのが現実的です。記事数×年数回の確認×通知の行、と積み上がっていくので、無期限にするか年数で切るかは運用の初期に一度決めておく方が楽です。
「監査ログ」とは呼ばない
ここまで読むと監査ログのように見えるかもしれませんが、そう言い切らないことにしています。
履歴は一般的な追記型の記録です。管理画面の通常操作で消せず、変更前後の値と通知の宛先まで残るので、「なぜこの情報が古かったのか」「誰がいつ確認したのか」を時間が経ってから説明する材料にはなる。ただし、保持期間を設定すれば消えますし、通常操作の外——データベースを直接触るような経路——まで塞ぐ仕組みではありません。「改ざんできない」「法的な証跡になる」とは言えない。
できることは、確認の事実を人の記憶とチャットの外に出して、変更前後の値つきで、通常操作では消せない形に置いておくこと。冒頭の「いつ誰が確認しました？」に画面を見せて答えられる、というのがこの機能の到達点です。
製品ページは コンテンツ更新管理 にあります。
