WordPressを保守していると、プラグインやテーマを更新する機会は何度もあります。
更新そのものは管理画面から数クリックで終わりますが、あとから「いつ、何を、どのバージョンへ更新したのか」を確認しようとすると、意外と情報が残っていないことがあります。
自分ひとりで管理しているサイトなら記憶をたどれるかもしれません。しかし、複数人で運用しているサイトや、毎月の保守内容を報告しているサイトでは、更新内容を記録しておきたい場面も多いですよね。
そこで、WordPress本体・プラグイン・テーマの更新履歴を管理画面から確認できる「OD Update History」というプラグインを作りました。
この記事では、OD Update History でできることや使い方、導入前に知っておきたい制約について紹介します。
OD Update Historyとは
OD Update Historyは、WordPress標準の更新処理を通して行われた更新を記録するプラグインです。
記録できる主な内容は、次のとおりです。
- 更新が完了した日時
- 更新した対象（WordPress本体・プラグイン・テーマ）
- 更新前と更新後のバージョン
- 更新時点でのプラグイン・テーマの有効状態
- 手動更新・自動更新・WP-CLIのどれで更新したか
- 更新を実行したユーザー
たとえば、プラグインを 1.2.0 から 1.3.0 へ更新した場合、その対象名や日時、更新方法などと一緒に履歴が保存されます。
「更新ボタンを押した」という操作ではなく、更新前後の実ファイルからバージョンを取得し、実際にバージョンが変わった場合だけ記録するのが、このプラグインの特徴です。
どのような場面で役立つのか
個人的には、次のようなWordPressサイトで活用しやすいと考えています。
- 定期保守の作業内容をクライアントへ報告している
- 複数人で WordPress の更新作業を担当している
- 不具合が起きた際に、直前の更新内容を確認したい
- 自動更新と手動更新を分けて把握したい
- 更新履歴を CSV で保管しておきたい
特に保守業務では、更新作業を実施するだけでなく、「何を更新したのか」を説明できる状態にしておくことも大切です。
もちろん、この履歴だけで不具合の原因を特定できるわけではありません。ただ、発生時期の近くで行われた更新を確認できれば、調査を始める際の手がかりにはなります。
更新前後のバージョンを実ファイルから確認して記録する
OD Update History は、WordPress 標準の更新処理で使われるWP_Upgraderのフックを利用しています。
大まかな流れは次のようになります。
- 更新前に、対象の名前・バージョン・有効状態を取得する
- WordPressが更新ファイルを置き換える
- 更新完了後に、実ファイルからもう一度バージョンを取得する
- 更新前後のバージョンが異なる場合だけ履歴を保存する
WordPress には、インストール開始前に呼ばれるupgrader_pre_installと、更新処理の完了時に呼ばれるupgrader_process_completeというフックがあります。OD Update History では、これらを使って更新前後の状態を確認しています。
更新候補として提示されたバージョン番号をそのまま保存するのではなく、実際にインストールされたファイルを確認するため、バージョンが変わらなかった処理は成功履歴として残りません。
また、最終的にWP_Upgraderを使って更新する仕組みであれば、WordPress.org 以外から配布されるプラグインやテーマも基本的には記録対象になります。
管理画面で履歴を確認・絞り込みできる
プラグインを有効化すると、WordPress管理画面に「更新履歴」というメニューが追加されます。
履歴は新しいものから順に 20 件ずつ表示され、次の条件で絞り込めます。
- 種別（WordPress・プラグイン・テーマ）
- 開始日と終了日
- 更新方法（手動更新・自動更新・WP-CLI・不明）
一覧では、対象名だけでなく、プラグインの basename やテーマの stylesheet も確認できます。同じような名前のプラグインがある場合でも、識別子まで確認できるようにしています。
履歴画面を表示できるのは、manage_options権限を持つユーザーです。通常のWordPress では、管理者が対象になります。
.csv と .txt で履歴を書き出せる
管理画面に表示している履歴は、CSV またはテキスト形式で書き出せます。
種別や期間、更新方法で絞り込んでいる場合は、その条件に一致する履歴だけがエクスポートされます。たとえば「先月行ったプラグインの手動更新だけを書き出す」といった使い方ができます。
CSV には UTF-8 の BOM を付けているため、Excel で開いた際の文字化けも起きにくい形にしています。保守報告用の資料へ転記したり、別の管理表へ取り込んだりする場合は CSV が扱いやすいでしょう。
テキストは、更新内容を人がそのまま読める形で残したい場合に向いています。
なお、エクスポートデータには更新を実行したユーザーの表示名が含まれます。ファイルを外部へ共有する場合は、共有範囲に注意してください。
履歴の保持期間も設定できる
更新履歴は、プラグインの有効化時に作成される専用テーブルへ保存されます。
{prefix}od_update_historyテーブル接頭辞が一般的なwp_であれば、テーブル名はwp_od_update_historyになります。
履歴の保持期間は、次の中から選択できます。
- 無期限
- 30日
- 90日
- 180日
- 365日
初期値は「無期限」です。期間を指定すると、WP-Cronが1日1回、設定した日数より古い履歴を削除します。
ここで注意したいのは、WP-Cron はサーバーの cron のように常時動いている仕組みではなく、基本的にサイトへのアクセスをきっかけに実行される点です。そのため、アクセスが少ないサイトでは削除時刻が遅れる場合があります。これはWordPress公式のCronに関する説明にも記載されています。
決まった時刻に確実に処理したい場合は、サーバー側の cron から WordPress の cron を実行する運用も検討したいところです。
また、管理画面から「指定した日数より古い履歴を今すぐ削除する」「すべての履歴を削除する」という操作も行えます。どちらも取り消せないため、必要に応じて先にCSVまたはTXTで書き出しておいてください。
インストール方法
執筆時点（2026年7月29日）の最新版はバージョン0.2.0です。現在はWordPress.orgのプラグインディレクトリではなく、GitHub Releasesから配布しています。
動作要件は次のとおりです。
| 項目 | 要件 |
|---|---|
| WordPress | 6.9以上 |
| PHP | 7.4以上 |
| データベース | MySQLまたはMariaDB |
| ライセンス | GPL-2.0-or-later |
インストール手順は以下のとおりです。
- 最新リリースページ から
od-update-history.zipをダウンロードする - WordPress管理画面の「プラグイン」→「新規プラグインを追加」を開く
- 「プラグインのアップロード」からZIPファイルを選択してインストールする
- 「OD Update History」を有効化する
- 管理画面の「更新履歴」を開く
GitHub が自動生成する「Source code」の ZIP ではなく、リリースの Assets にあるod-update-history.zipを利用してください。Source code の ZIP には、プラグイン自身の更新機能に必要な依存ファイルが含まれていません。
最初のインストールは手動で行う必要がありますが、その後に新しい GitHub Release が公開されると、WordPress管理画面に通常のプラグインと同じように更新候補が表示されます。
導入前に知っておきたい制約
OD Update History は、WordPress で起きるすべてのファイル変更を監視するプラグインではありません。
現時点では、次のような変更は記録できません。
- FTP・SSH・rsyncなどによる直接のファイル置換
- WordPressを介さないComposerでの更新
- ZIPの手動展開やディレクトリの差し替え
WP_Upgraderを使わない独自の更新処理- 更新開始・更新失敗・ロールバック
- プラグインやテーマの新規インストール・削除・有効化・無効化
つまり、「WordPress標準の更新処理を通り、実際にバージョンが変わった更新」を記録するためのプラグインです。ファイル監視や操作監査を目的としたプラグインとは役割が異なります。
また、現時点では単一サイトを主な対象としています。マルチサイトのサイト別・ネットワーク別管理や、複数サイトの履歴をまとめて確認する機能は未整備です。
プラグインを削除しても履歴は自動削除されない
もうひとつ、データの扱いについて大切な点があります。
OD Update History を無効化したり、WordPress管理画面から削除したりしても、保存済みの履歴テーブルと設定はデータベースに残ります。これは、プラグイン本体とは別の保守記録として履歴を扱い、再インストールした際にも既存データを確認できるようにするためです。
一方で、このプラグインを今後使わず、データベースからも完全に消したい場合は、履歴テーブルと関連するoptionsを手動で削除する必要があります。具体的な対象やSQL例は、GitHubリポジトリのREADMEに記載しています。
手動でのデータベース操作は元に戻せません。実行する場合は、事前にデータベース全体のバックアップを取得し、テーブル接頭辞を必ず確認してください。
まとめ
WordPress の更新作業は、サイトを継続的に運用していくうえで欠かせません。ただし、更新を続けていくほど「いつ、何を更新したのか」という記録も大切になってきます。
OD Update History を使うと、WordPress 本体・プラグイン・テーマの更新前後のバージョンや更新方法、実行者を管理画面から確認できます。CSV やテキストでも書き出せるため、保守報告や不具合調査の補助資料としても活用できます。
まだ記録できない更新方法や、マルチサイト対応などの課題はあります。そのあたりも含めて、今後の運用を通して必要な改善を続けていきたいと考えています。
WordPress の更新履歴を残す方法を探している方の参考になれば嬉しいです。
