プラグインの更新の遅れを外から確かめる｜REST APIとWordPress.orgの公開APIで日数を数える

プラグインの更新は、管理画面の「更新」を開けば見られます。ただ、複数のサイトを運営していると、ひとつずつ開くのは大変です。この記事では、WordPressのREST APIで入っているプラグインの版を取り出し、WordPress.orgの公開APIの最新版と照合して、何日遅れているかを数える方法を、筆者のサイトで実際に実行した結果とあわせて紹介します。

（確認：筆者が運営するWordPressサイト1つ（WordPress 7.1.3）で、2026年10月20日に実行。取得は読み取りだけで、プラグインの更新・変更は行っていません。サイトの名前とプラグイン名は伏せ、件数だけを載せます）

仕組み

1. サイトのREST API /wp-json/wp/v2/plugins で、入っているプラグインの版と有効・無効を取る（管理者のアプリケーションパスワードが必要）
2. WordPress.orgの公開API https://api.wordpress.org/plugins/info/1.0/スラッグ.json で、最新版と、最新版が出た日（last_updated）を取る
3. 2つを比べ、同じか、遅れているか、ディレクトリに無いか（有料や自社配布のもの）を数える

アプリケーションパスワードの作り方はWordPressに外部から投稿する方法、403や401が出た時はREST APIのエラーコードを見てください。

コード

import base64, json, os, time, urllib.request
from datetime import datetime, timezone

SITE = os.environ["WP_SITE"]   # 例: https://example.com
AUTH = "Basic " + base64.b64encode(
    f"{os.environ['WP_USER']}:{os.environ['WP_APP_PASSWORD']}".encode()).decode()

def get(url, auth=False):
    h = {"User-Agent": "plugin-gap/1.0"}
    if auth: h["Authorization"] = AUTH
    with urllib.request.urlopen(urllib.request.Request(url, headers=h), timeout=30) as r:
        return json.loads(r.read().decode())

plugins = get(f"{SITE}/wp-json/wp/v2/plugins?per_page=100", auth=True)
now = datetime.now(timezone.utc)
for p in plugins:
    slug = p["plugin"].split("/")[0]
    try:
        info = get(f"https://api.wordpress.org/plugins/info/1.0/{slug}.json")
        released = datetime.strptime(info["last_updated"].replace(" GMT", ""),
                                     "%Y-%m-%d %I:%M%p").replace(tzinfo=timezone.utc)
        same = (p["version"] == info["version"])
        print(p["name"], p["version"], info["version"], "同じ" if same else f"遅れ（最新版は{(now-released).days}日前）")
    except Exception:
        print(p["name"], p["version"], "ディレクトリで見つからない、または通信エラー")
    time.sleep(1)                      # 公開APIに続けて問い合わせるので、1秒空ける

パスワードはコードに書かず、環境変数に入れます。リクエストの間は1秒ほど空けると、公開APIに負担をかけません。

筆者のサイトでの結果

遅れている11件について、「最新版が出てから何日たっているか」を数えると、0日・0日・0日・5日・5日・5日・7日・7日・7日・10日・11日でした。最新版が出てから11日以内のものばかりでした。ただし、この日数は「WordPress.orgで最新版が出てからの日数」で、サイトに入っている版がいつから古いかではありません。入っている版が数か月前のものでも、最新版が昨日出ていれば「0日」と出ます。そのため、「長く放置されたものはない」とは言えません（先頭の版の数字が違う、大きな遅れも1件ありました）。WordPress本体は、サイトが7.1.3、公式の最新も7.1.3で同じでした。

数字の使い方は2つあります。ひとつは、「何件遅れているか」ではなく「最新版が出てから何日か」で見ること。出たばかりの版は、他のサイトの不具合報告が出るのを少し待つ運用もありえます。もうひとつは、日数が長いものから優先して調べることです。更新をやめたプラグインは、最新版そのものが何か月も前なので、last_updated が古いものが見つかります。ただし、入っている版が古いかどうかは、この数字だけでは分かりません。

掲載したコードは、プラグイン名を表示する版です。筆者が実際に実行したのは、名前を出さず、件数と日数だけを出す版で、取得と照合の処理は同じです。

この方法で分からないこと

• 公開ディレクトリにない有料プラグインや、独自配布のプラグインの最新版（今回は1件が照合できませんでした）
• 脆弱性があるかどうか。版が古いことと、危険であることは別の話です
• 本番に反映する前に、表示が崩れないか。更新前のテストにはステージング環境が使えます（ステージング環境を備えるXServer for WordPressの解説）

更新の運用の考え方

WordPressの自動更新の仕組みは自動更新の記事にまとめています。本体は軽微な更新だけ自動で、プラグインは自分で選ぶ設定です。今回の方法は、自動更新を切っているプラグインの遅れを、サイトにログインせずに点検するために使えます。更新する前には、ファイルとデータベースの両方をバックアップしてください（バックアップの記事）。

まとめ

• REST APIの /wp/v2/plugins とWordPress.orgの公開APIを照合すると、サイトに入らなくてもプラグインの遅れが数えられる
• 筆者のサイトでは17個中、最新版と同じ5・遅れ11・照合不可1。遅れの11件は、最新版が出て0〜11日だった
• 見るのは件数ではなく「最新版が出てからの日数」。長いものを優先して確認する
• 有料プラグインは照合できない。更新前のバックアップとテストは別に必要

本記事は読み取りの方法の説明であり、更新や設定の変更は含みません。実際に更新する前には、バックアップを取ってください。