WordPressのプラグイン更新を、しばらく止めていた。更新でサイトが壊れるのが嫌だったからだ。気づけば3サイトとも10件以上が溜まっていた。
2026年7月に、リリースから7日たった更新だけを毎朝自動で入れる仕組みを作った。8月1日から10月20日までの約80日で、3サイト合計115件を更新し、更新そのものの失敗は0件だった。
ただ、仕組みの細部はもう覚えていない。この記事を書くために資料と実装を読み返したら、設計のときに置いた前提が、実装では成り立っていない箇所が見つかった。
- リリースから7日たったプラグインだけを、毎朝5時にWP-CLIで更新している。
- その前の4時に、BackWPupのバックアップをNASへ取りに行く。
- 見直したら、バックアップが止まっても通知が来ない作りだったので、2026年10月20日に直した。
公開直後は入れず、7日待つ
毎朝やっていること
処理は、自宅のWindows PCのタスクスケジューラから毎朝動く。順番はこうだ。
プラグインの更新は、サーバーにSSHでつないでWP-CLIのplugin updateコマンドで行う。筆者が使っているXserverでは、WP-CLIが最初から使えた。
判定に使うのは、WordPress.orgのプラグイン情報に載っている最終更新日時だ。これが7日より新しいプラグインは、その日は見送る。翌日以降、7日を過ぎた時点で更新される。
安全の確認は、7日待つことで代えている
この仕組みのポイントは、公開直後には入れず、安全を確かめてから入れることだ。その確かめ方として、一定期間待つことだけを使っている。不具合の報告を調べたり、テスト環境で試したりはしていない。
初版に致命的な不具合があれば、7日のうちに使った人が気づき、作者が修正版を出すだろう、という考え方だ。修正版が出れば最終更新日時が新しくなるので、待ち時間はそこから数え直しになる。
裏返すと、7日たっても誰も気づいていない不具合は、そのまま入ってくる。待つことで避けられるのは、多くの人がすぐに踏む不具合だ。
もう一つ、WP-CLIには --minor（マイナーリリースだけ）や --patch（パッチリリースだけ）に絞るオプションがある。これは使っていない。大きなバージョンアップも7日たてば入る。実際、10月20日の朝にはCode Snippetsが3.10.2から4.0.0に上がった。同じ日に3サイトのトップページを開き、HTTP 200でエラー表示が無いこと、スニペットの一覧が取れることは確認した。
除外するプラグインは作らなかった
最初は、バックアップ用のBackWPupやCode Snippetsのように、壊れると困るものは対象外にするつもりだった。
これはやめた。目的は手間を減らすことで、壊れても戻せるなら全部対象でいい、と判断した。残った心配は「BackWPupが更新で壊れたら、戻すためのバックアップ自体が取れなくなる」ことだった。これはバックアップの取得に失敗したらSlackに通知を出すことで手当てした、つもりだった。この「つもり」が、あとで穴になる。
WordPress標準の自動更新との違い
WordPressには、5.5からプラグインごとの自動更新機能がある。公式ドキュメントによると、自動更新は1日2回動き、成功・失敗のどちらでもメールで知らせてくれる。
ただし、公式ドキュメントには「リリースから何日待つ」という設定は出てこない。待たずに入れてよいなら標準機能で足りる。今回わざわざ自前で組んだのは、7日待つことと、更新の前にバックアップを手元へ取ってくることの2点のためだ。公式ドキュメントも、自動更新を有効にする前に、戻せるようにバックアップを取っておくことを勧めている。
「戻せる前提」は、半分しか成り立っていなかった
バックアップは週1回だった
バックアップは、BackWPupがサーバー上に作るファイルを、毎朝4時にFTPで取ってきてNASへ保存している。1サイトあたり0.6〜1.3GBで、2世代だけ残す。
NASは家庭用のBuffalo LinkStationだ。本体のバックアップ機能は同じBuffalo製品どうしのLAN内向けで、インターネット越しにFTPで取ってくることはできなかった。そのため取りに行く処理はWindows PC側で動かしている。このNASの上では自作のプログラムも動かせないので、iPhoneの写真をNASへ退避するツールを作ったときも、同じ理由でPC側に処理を置いた。
毎朝4時に取りに行くので、バックアップも毎日あるように見える。NASの中を見たら、3サイトとも10月11日と10月18日の2つしかなかった。BackWPupがファイルを作るのは週に1回、日曜の未明だった（1サイトだけ朝にずれることがある）。毎朝4時の処理は、その週1回のファイルを拾いに行っているだけだ。
つまり、プラグインを更新した時点で戻せるのは、最大で6日前の状態になる。記事の下書きやコメントがその間に増えていれば、戻すとそれも消える。
止まっても通知が来ない作りだった
もっと困ったのはこちらだ。バックアップを取ってくる処理は、「サーバー上の最新ファイルが、もうNASにあるか」しか見ていなかった。
BackWPupが止まって新しいファイルを作らなくなると、サーバー上の最新ファイルは先週のままになる。それはもうNASにあるので、処理は何もせずに正常終了する。エラーにも通知にもならない。
プラグインの自動更新は、「BackWPupが壊れたら通知で気づける」ことを前提に、BackWPupまで更新対象にしていた。その前提が成り立っていなかったことになる。
戻せるから全部入れる、と決めた土台が、黙って崩れうる作りだった。80日何も起きなかったのは、BackWPupがたまたま止まらなかったからでしかない。
2026年10月20日に、サーバー上の最新バックアップが8日より古いとき、またはファイルが1つも無いときは失敗として通知するように直した。週1回の運用なので、1回取りこぼせば翌朝に気づける。
一度も戻したことはない
正直に書くと、NASのバックアップからサイトを戻したことは一度もない。戻せる前提で全プラグインを自動更新しているのに、その前提を試していない。
バックアップのファイルがNASにあることと、それで実際にサイトが元に戻ることは別の話だ。ここはまだ確かめていない。
80日で115件、落ちたのは接続だけ
数字で見る80日
ログが残っている2026年8月1日から10月20日まで、定期実行は78回動いた。
| 項目 | 結果 |
|---|---|
| 更新したプラグイン | 3サイト合計115件（16種類） |
| 更新そのものの失敗 | 0件 |
| 処理全体が失敗した日 | 3日（すべてSSH接続の段階） |
| ログが残っていない日 | 3日 |
更新の回数が多かったのは、website-llms-txt と Simple History がそれぞれ15件、WP Fastest Cache・EWWW Image Optimizer・Jetpack がそれぞれ12件だった。3サイトに共通で入っているプラグインは、1回の更新が3件として数えられている。
なお、仕組みを作った7月18日の初回は、3サイトで各11件、計33件をまとめて更新した。そのときもリリースから7日たっていない更新が、各サイト4〜6件残った。この初回分は上の表には入っていない。
表示が崩れた、という事態には気づいていない。ただし、ログが見ているのは「更新コマンドが成功したか」だけだ。見た目の崩れはログに出ないので、「崩れなかった」とまでは言い切れない。
失敗はすべてSSHの接続だった
3回の失敗は、どれもプラグインを更新する前の、サーバーにつなぐ段階で起きた。
最初の2回（8月1日・2日）は、Windowsに最初から入っているsshを使っていたことが原因だった。この仕組みは1回つないだ接続を使い回すために、sshのControlMasterという機能を使っている。Windows標準のsshではこれが動かず、毎朝すぐに落ちていた。厄介なのは、手で実行すると別のsshが使われて成功してしまうことで、手元では再現しなかった。Git for Windowsに入っているsshを明示的に使うように直して解決した。
接続を使い回しているのは、最初に作った版が1プラグインごとにSSHでつなぎ直していて、20回ほどつないだところでサーバー側に接続を断られたからだ。HTTPでのアクセスは普通にできるのに、SSHだけがつながらなくなった。
3回目（8月31日）は単純な接続タイムアウトだった。少し待つとつながることを確かめたので、接続だけを15秒おきに最大3回試すようにした。それ以降、接続で落ちた日は無い。
タスクスケジューラ経由だと手元と違う動きをする話は、Claude Codeを定期実行したときにWindowsで壊れた2箇所でも書いた。手で動かして成功しても、スケジューラから動くかは別に確かめる必要がある。
確認のつもりで本番を更新したこともある
7月31日、接続を確かめるつもりでスクリプトを直接実行し、3サイトで19件のプラグインを本番で更新してしまった。このスクリプトには「試しに動かすだけ」のモードが無く、動かせば即座に本番へ反映される。
結果は全件成功で実害は無かった。それ以来、接続だけを確かめたいときは、接続部分の関数だけを呼ぶようにしている。
通知は毎日来る。見るのは成功か失敗かだけ
中身は読んでいない
更新の結果は、成功でも「更新対象なし」でも、毎朝Slackに届く。届いていること自体は見ているが、どのプラグインが何から何へ上がったかまでは読んでいない。見ているのは成功か失敗かくらいだ。
先に書いたCode Snippetsの4.0.0への更新も、通知の上では他の行と同じ「更新成功」の1行だった。
ここにも穴があった。これまでの通知は、成功しても失敗しても1行目が同じ「プラグイン自動更新チェック結果」だった。失敗の中身は本文の下のほうにしか出ない。中身を読まない見方だと、失敗に気づけない。
10月20日に、失敗したときだけ1行目を「⚠️ プラグイン自動更新に失敗あり」に変えた。成功時の通知は今までどおり残している。
失敗のときだけ通知、にしなかった理由
失敗したときだけ通知する形にすれば、毎朝の通知は無くなって静かになる。そうしなかったのは、仕組みそのものが動かなかった日に何も届かなくなるからだ。
実際、80日のうち3日はログ自体が残っていない。理由までは追っていないが、少なくともその日の結果は記録されていない。失敗時だけ通知する作りなら、こういう日は何も届かず、止まったことにも気づけない。毎朝届くことが、動いていることの確認になっている。
仕組みは覚えていない。覚えなくていい
作ったことは覚えている。ただ、7日の判定に何を使っているか、バックアップがいつ作られているか、といった中身は覚えていない。覚える必要もないと思っている。設計の経緯や判断の理由は、資料とObsidianのメモに残っているからだ。メモの仕組みはClaude CodeとObsidianで作った横断ナレッジベースに書いた。
今回わかったのは、覚えていなくても、資料と実装を突き合わせれば前提のずれは見つかるということだ。設計のときの資料には「BackWPupが壊れたら通知で気づける」と書いてあったが、実装は止まっても何も来ない作りだった。
覚えていなくていいのは、資料が残っていて、必要なときに読み返せるからだ。正しいのは記憶ではなく資料のほうで、この記事を書いたのが、ちょうどその読み返す1回になった。
よくある質問
- QWordPress標準のプラグイン自動更新と何が違いますか？
- A
標準機能は1日2回動き、更新が出たら入れる。公式ドキュメントには、リリースから何日待つという設定は出てこない。筆者の仕組みは、WordPress.orgの最終更新日時から7日たったプラグインだけをWP-CLIで更新し、その1時間前にBackWPupのバックアップをNASへ取ってくる。待つことと、手元にバックアップを置くことの2点のために自前で組んだ。
- Qリリースから7日待てば、更新しても安全ですか？
- A
安全とは言い切れない。7日待つのは、初版に致命的な不具合があれば作者が修正版を出すだろう、という期待に乗っているだけで、不具合の報告を調べてはいない。筆者の3サイトでは80日で115件を更新して更新の失敗は0件、気づいた表示崩れも無いが、表示崩れまでは検査していない。
- Qバックアップを取っていれば、プラグインの自動更新は安心ですか？
- A
バックアップが本当に取れているかを、別に確かめる必要がある。筆者の仕組みは、BackWPupが止まっても通知が来ない作りだったことに80日後に気づいた。さらにBackWPupの作成は週1回で、更新時点で戻せるのは最大6日前の状態だった。NASのバックアップから戻したことも、まだ一度も無い。
7日待つのは保険。戻せるかは別に確かめる
リリースから7日待ってから入れるのは、手間をかけずに初版の事故を避けるには十分だった。3サイト80日で115件を更新し、更新そのものの失敗は無かった。
ただ、その安心は「壊れても戻せる」ことに乗っている。戻すためのバックアップが止まっても気づけない作りだったし、戻せるかどうかも試していない。前者は直した。残っているのは、NASのバックアップで本当にサイトが戻るかを一度試すことだ。
