Webページと予定表、交換用の部品を並べた紙細工のイラスト
解説用イラスト(AI生成)。実際の管理画面ではありません。
この手順でできること

必要なイベントを記録し、日時と対象から変更履歴を追える運用を作れます。

作業を始める前に

  • WordPressの時刻と担当者ごとのアカウントを確認します。
  • DB容量とバックアップ状況を確認します。
AT A GLANCE先に、全体の流れを確認
  1. 01記録の目的と閲覧担当を決める
  2. 02記録対象と保持期間を設定する
  3. 03無害な変更で記録を試す
  4. 04不具合の前後を絞って読む

下の各項目で、判断のポイントと確認方法を説明します。

進め方・判断のポイント 05 STEPS

01

記録の目的と閲覧担当を決める

記事の変更調査、ユーザー権限の見直し、プラグイン更新の追跡など、ログが必要な場面を挙げます。操作履歴にはユーザー名やIP等の情報が含まれるため、誰が何のために閲覧するかを決めます。ログを残すことと、変更した記事を元に戻すことは別の仕組みです。

✓ 完了の目印

記録する目的と閲覧者を決めました。

02

記録対象と保持期間を設定する

プラグインの設定で対象イベントを確認します。操作が多い環境では、必要な履歴がノイズに埋もれないよう範囲を調整します。ただし管理者の操作を広く除外すると重要な変更が追えなくなります。保持期間は調査に必要な日数とDB容量で決め、短縮すると古い履歴が失われることを確認します。

入力例・選択の目安
項目入力する内容・例
記録する内容投稿・権限・ログイン・更新など調査目的に合わせて選ぶ。
保持期間必要な調査期間と容量から決定短縮による削除に注意。
閲覧権限保守担当へ限定ログを公開の相談欄へ貼らない。
✓ 完了の目印

調査に必要な期間を保存できる設定になりました。

03

無害な変更で記録を試す

検証用の下書きタイトルを変更するなど、影響の小さい操作を行います。ログビューアーで時刻、ユーザー、対象、操作内容を確認します。WordPressとログ側のタイムゾーンが違う場合は、どの時刻を見ているかを記録します。保存していなかった過去のイベントは後から取得できません。

✓ 完了の目印

試験操作が期待した情報で記録されました。

04

不具合の前後を絞って読む

発生URL、気づいた時刻、最後に正常だった時刻を先に整理し、その前後の更新を確認します。投稿変更だけでなくテーマやプラグイン、権限の変更も照合します。利用中のプランで使える検索・フィルターを使い、同時刻の別作業も確認して原因候補を絞ります。ログ1件だけで担当者のミスと断定しないようにします。

✓ 完了の目印

問題と時間的に関連する変更の候補を整理しました。

05

通知と保守の仕組みを見直す

重要な権限変更等を通知したい場合は、利用中のプランが対応する通知やレポートの条件を確認します。ログを外部へ渡す際は必要な範囲に絞り、共有先を限定します。定期的に容量と保存期間、退職者のアクセス、取得が止まっていないかを確認して運用を続けます。

✓ 完了の目印

ログの保存と確認を担当者が継続できる状態になりました。

終わったら確認すること

  • 操作ログと記事のリビジョン・バックアップを区別します。
  • 必要なログが記録され、閲覧者が限定されているか確認します。

途中で困ったときは

ログからボタン一つで記事を復元できますか?

操作ログは変更の手がかりです。記事の復元はリビジョン、サイト全体の復元はバックアップなど、対象に合う仕組みを使います。

導入前の変更も見られますか?

記録していなかったイベントは後から取得できません。導入時点と保持期間を確認して、履歴の欠けている期間を区別してください。

参照した公式資料

画面や条件が異なる場合は、ご利用環境と公式の最新案内を確認してください。

手順確認日 2026.10.30 / 読む時間は目安です。操作に必要な時間は環境によって異なります。

管理画面の項目を調べる

入力欄の意味・操作・確認方法を、項目ごとに確認できます。

WP Activity Log →