以前の記事で、WordPress 更新後にトラブルが発生し、キャッシュのクリアで解決したことがあった。今回は、「WordPress でキャッシュクリアはどれくらい・いつやるべきか」という疑問に対して、順を追って丁寧に説明する。結論だけを先に言うなら、キャッシュクリアは「定期清掃」ではない。状態が変わったときに、必要な範囲だけ、段階的に行う。つまり、運用設計の中心は「頻度」ではなく「トリガ（きっかけ）」である。そのうえで、運用が回り始めると必ず起きるのが「誰かが勢いで全部消す」「本番と検証を間違える」「原因究明のログが残らない」という事故である。ここから先は、その事故を防ぐ考え方と、最終的に WP-CLI を安全にラップして自動化する設計まで、ひとつの流れとして整理する。
1. そもそもキャッシュとは何か
キャッシュ（cache）とは、ざっくり言えば「同じ計算や同じ取り出しを、何度も繰り返さないための、一時保存」である。Web サイトでは、ページ表示のたびにデータベースを読んだり、外部 API を呼んだり、複雑な処理をしたりする。これを毎回やると遅くなるので、一度作った結果をしばらく使い回す。その仕組みがキャッシュだ。キャッシュがあると速くなる一方で、「古い内容が残る」ことが起きる。WordPress の運用で「更新したのに表示が変わらない」と感じる現象の多くは、この「どこかの層に古いキャッシュが残っている」ことで説明できる。HTTP のキャッシュの標準仕様は RFC 9111 にまとまっている。[1]
用語の補足
- キャッシュ：一時保存。速さのために、結果を使い回す。
- パージ（purge）：キャッシュを「期限まで待たずに」捨てること。CDN などでよく使う。
- フラッシュ（flush）：溜まっているキャッシュをまとめて無効化・削除すること。WP-CLI の用語としても出てくる。[2]
2. WordPress には「キャッシュの層」がいくつもある
WordPress の「キャッシュ」は 1 箇所ではない。複数の層（レイヤ）が重なっている。ここを理解しないと、運用は必ず迷走する。そこで、この記事では次の 4 層モデルを共通言語として固定する。
| 層 | 名前 | 何が保存されるか | 代表例 |
|---|---|---|---|
| L1 | トランジェント | WordPress が「期限付き」で保存する一時データ | Transients API / wp_options など [3] |
| L2 | オブジェクトキャッシュ | WordPress の内部オブジェクトを高速に取り出すためのキャッシュ | wp_cache / Redis / Memcached [4] |
| L3 | ページキャッシュ | 生成済み HTML を丸ごと保存して再利用 | W3 Total Cache など [5] |
| L4 | CDN / ブラウザ | ネットワークの途中や利用者側が保存するキャッシュ | Cloudflare / ブラウザ [6] |
ポイントは単純で、層が上に行くほど「広く効く」かわりに「危ない」ことだ。L1 を消しても影響は小さい。しかし L3 を全部消すと、次のアクセスで大量にページ再生成が走り、サーバに負荷がかかる。WP-CLI のドキュメントでも、object cache flush の本番影響に注意が書かれている。[2]
3. 「キャッシュクリアは定期清掃ではない」という考え方
ここがこの記事の中心となる思想（設計原理）である。
キャッシュは「時間が経てば自然に消える」ことが前提で設計されている。Transients API も、有効期限を持ち、期限後に削除される仕組みとして説明されている。[3] つまり、運用で毎日・毎週キャッシュを掃除することは、多くの場合「設計思想に逆らう」行為になる。
なぜ定期全消去が悪いのか
- 負荷が上がる：キャッシュを消すと、次のアクセスで再生成が集中する。
- 原因が隠れる：本当は設定や更新手順の問題なのに、「消したら直った」で放置される。
- ユーザ体験が揺れる：ある瞬間だけ遅くなり、タイムアウトなどが出る。
ではいつ消すのか。答えは「状態が変わったとき」である。WordPress の更新は状態変化の代表であり、更新手順は公式ドキュメントにもまとまっている。[7]
4. 運用設計：いつ、何を、どこまで消すか
ここからは「運用設計」を、一般的な IT 運用の考え方に沿って分解する。運用設計には少なくとも次の観点がある。
- 変更管理：更新や設定変更のときに、何をどの順番で行うか。
- 事故防止：本番誤爆、過剰な全消去、同時実行の衝突をどう防ぐか。
- 可観測性：やった結果が正しいかを、どう確認し、記録するか。
- 復旧設計：失敗したときに戻せるか、影響を局所化できるか。
- セキュリティ：更新の遅れ・権限管理・脆弱性対応をどう扱うか。
- コスト設計：手動運用の負荷をどこまで許容し、どこから自動化するか。
以下は、上の観点をすべて使って、「キャッシュクリア運用」をイベント駆動で設計する。
4.1 イベント駆動：頻度ではなくトリガで決める
| イベント | 何が変わったか | 推奨アクション | 狙い |
|---|---|---|---|
| 平常時 | 何も変わらない | 何もしない | TTL と自動更新に任せる |
| WordPress 本体更新 | コード + DB スキーマが変わる可能性 | L1 → L2 → （可能なら L3） | 整合性を取り直す |
| プラグイン更新 | 機能・DB・表示が変わる可能性 | 影響に応じて L2 まで / 表示系なら L3 まで | 影響範囲に見合う最小限 |
| テーマ / CSS 手修正 | 表示が確実に変わる | L1 → L2 → L3（ページキャッシュ） | 「反映しない」事故を潰す |
| 記事投稿 / 更新 | コンテンツが変わる | 原則何もしない（自動パージに任せる） | 手動操作を増やさない |
| 障害対応（反映されない / 表示がおかしい） | 原因不明の状態 | 段階手順（L1 → L2 → L3 → L4） | 原因を切り分けながら直す |
4.2 「段階手順」の意味
段階手順とは、「小さく消して、直るならそこで止める」方法である。なぜなら、直った瞬間に「どこが原因だったか」の仮説が立つからだ。いきなり全部消すと、原因が分からないままになる。
| 段階 | やること | 直ったかの確認 | 次に進む条件 |
|---|---|---|---|
| Step 1 | L1（トランジェント）を消す | 該当ページが更新されるか | まだ古い / まだ壊れている |
| Step 2 | L2（オブジェクトキャッシュ）を flush | 管理画面・表示・API が戻るか | 改善しない |
| Step 3 | L3（ページキャッシュ）を purge | HTML が更新されるか | 改善しない / CDN 介在が疑わしい |
| Step 4 | L4（CDN / ブラウザ）を purge / 確認 | 別端末・別ネットワークで確認 | まだ残るなら別原因（更新手順やコード） |
4.3 変更管理：更新時の「正しい流れ」を固定する
運用が崩れる最大の原因は「更新手順が人によって違う」ことである。そこで、更新イベントごとに、最低限の手順を固定する。
- WordPress 本体更新：更新後に DB 更新が必要になるケースがあるため、WP-CLI の update-db を含める。[8]
- プラグインとテーマ：自動更新もあるが、更新が走るタイミングが人間の認識とズレるため、通知と記録が重要になる。[9]
「更新の境界でキャッシュを整合させる」という位置づけが重要で、「定期掃除」の発想とは別である。
4.4 可観測性：やったことを残す、影響を測る
キャッシュクリアは「やったら終わり」ではなく、「やった結果が正しいか」を観測して初めて運用になる。最低限、次を残す。
- いつ実行したか（日時）
- 誰が実行したか（実行者）
- なぜ実行したか（reason）
- どの層を消したか（L1 / L2 / L3 / L4）
- 対象サイト（URL）
- 成功したか（終了コードとメッセージ）
4.5 事故防止：やってはいけないことを明文化する
- cron で毎日 / 毎週の「全キャッシュ消去」を回す（根本原因を隠し、負荷を増やす）。
- トラブル時に Step 3（全 purge）から始める（原因が消える）。
- 本番と検証で同じ手順を使い、対象を確認せず実行する（誤爆）。
4.6 セキュリティ：更新とキャッシュの関係
一般に「キャッシュ」は性能の話だと思われがちだが、運用ではセキュリティと直結する。理由は単純で、WordPress とプラグインは脆弱性が出る。更新が遅れると、攻撃を受ける可能性が上がる。最近の例として、W3 Total Cache の脆弱性が報道され、更新の必要性が強調された。[10]
ここから導かれる運用原則は、「更新を安全に回す仕組みを作る」ことであり、キャッシュクリアはその一部として位置付く。
5. なぜ「スクリプト設計（自動化）」の話に至るのか
ここまでの運用設計は、人間が守れば成立する。しかし現実には次が必ず起きる。
- 忙しいときに手順が省略される。
- 人によって解釈が違い、実行コマンドが変わる。
- 本番で実行してはいけない操作を、うっかりやる。
- ログが残らず、後から原因が追えない。
この問題を「精神力」で解決しようとすると破綻する。そこで、運用設計を守らせる仕組みとして、WP-CLI コマンドをラップした安全用スクリプトを設計する、という流れになる。つまり自動化は「楽をする」ためだけではなく、「事故を減らす」ために行う。ここが設計思想として重要だ。
6. スクリプト設計：安全ラッパーの設計原理
安全ラッパーの目的は 3 つに絞る。
- 誤対象防止：本番と検証、別サイトを間違えない。
- 過剰実行防止：段階手順を強制し、全消去を最終手段にする。
- 再現性：誰が何をしたかを必ず残す。
6.1 「イベント駆動コマンド」にする
人間が直接 wp cache flush のような低レベル操作を叩くと、運用ルールが守られない。そこでラッパーの表面 API は「運用イベント」に寄せる。例えば次のように、人が理解しやすい名前を付ける。
- after-core-update：本体更新直後の整合処理
- after-plugin-update：プラグイン更新直後の整合処理
- after-theme-update：テーマや CSS 変更後の整合処理
- troubleshoot：段階手順による切り分け
- status：現状（W3TC 有効か、CDN があるか等）の検出結果を表示
この設計は「運用設計をスクリプトに埋め込む」という意味を持つ。
6.2 必須ガード（ここが安全の本丸）
WP-CLI にはグローバルパラメータがあり、–path のように「どの WordPress を対象にするか」を明確に指定できる。[11] 安全ラッパーは、–path を必須にすることで「カレントディレクトリ依存の誤爆」を潰す。加えて、対象サイトの URL を取得し、許可リストに合わない場合は実行拒否にする。ここまでやって初めて、本番誤爆対策として成立する。
6.3 段階実行を強制する
ラッパーは内部で必ず L1 → L2 → L3 の順で実行する。途中で失敗したら止める。成功したら次に進む。この「段階」をコードで固定することで、運用ルールが破られにくくなる。
6.4 排他とレート制限
キャッシュクリアは、複数人が同時に走らせると負荷と混乱が増える。よって排他（ロック）を持たせる。さらに L3 の全 purge は「高負荷トリガ」なので、同一日に何度も実行できないようレート制限を持たせるのが合理的だ。
7. W3 Total Cache 前提 / 非前提の分岐設計
ここは設計の難所で、一般人が見落としやすい部分でもある。「キャッシュクリア」と言っても、サイトの構成により「ページキャッシュがどこにあるか」が違う。W3 Total Cache を使う環境では、W3TC の purge が必要になる。W3TC の管理画面にも、キャッシュを empty / purge できることが書かれている。[5] 一方で、W3TC を使っていない環境では、そのコマンド自体が存在しない。ラッパーが固定で実行すると失敗する。だから分岐が必要になる。
7.1 検出の考え方（なぜ二重チェックが必要か）
検出を 1 つの条件だけで済ませると、誤判定が起きる。例えば「ファイルがあるから W3TC だ」と判断すると、残骸で誤判定する。だからラッパーは次の二重チェックを基本にする。
- WP-CLI コマンドが存在するか（実行可能性）
- プラグインが有効か（実運用で効いているか）
このうち、WP-CLI のコマンド体系は公式ドキュメントとして参照できる。[13] また、W3TC の WP-CLI での flush 例はホスティング事業者のサポート記事にもある。[14]
7.2 分岐の仕様（運用イベントから見たふるまい）
| 条件 | ラッパーの動作 | ログレベル |
|---|---|---|
| W3TC 有効 + コマンドあり | L3 として W3TC purge を実行 | [INFO] |
| W3TC 無効 / コマンドなし | L3 をスキップし、理由を出す | [WARN] |
| イベントが L3 必須（テーマ更新等）なのに L3 不可 | 運用上は「未完了」とみなし失敗扱いも検討 | [ERROR]（方針次第） |
重要なのは「スキップしたことを必ず見える化する」ことだ。スキップを黙ってやると「クリアしたつもり」の事故になる。
7.3 W3TC 以外のページキャッシュがある場合
W3TC がないからと言って、ページキャッシュが存在しないとは限らない。典型は CDN で、Cloudflare には purge のドキュメントと API がある。[6] [15] さらに、Nginx の proxy cache や purge の仕組みもある。[16] [17]
よってラッパーは「W3TC をスキップした」だけで終わらせず、「この環境では L4（CDN）や別レイヤがあり得る」ことを運用者に伝える設計が望ましい。
8. 具体的な運用設計（より充実した観点での整理）
ここは「運用設計をもっと充実させる」という要件に対応して、観点を増やして整理する。キャッシュクリアは単体作業ではなく、運用全体の中で位置付ける必要がある。
8.1 リスク設計（最悪を先に潰す）
- 本番誤爆：対象 URL allowlist と –path 強制で防ぐ。
- 高負荷：L3 全 purge は最終手段にし、レート制限する。
- マルチサイト影響：object cache flush は全サイトに影響し得る。WP-CLI でも注意されている。[2] さらに環境により挙動が異なる例もある。[18]
8.2 性能設計（「速さ」を守るために消しすぎない）
- キャッシュは速度のためにある。消すのは例外である。
- ページキャッシュ全消去は「全ページを再生成する」方向に働く。
- CDN は「推奨は purge by URL（狭く消す）」が基本となる。[6]
8.3 監査性・説明責任（あとで説明できる設計）
- L3 以上は理由（reason）必須。
- ログは「実行コマンド列」と「対象 URL」を含む。
- 失敗時はどの段階で止まったかを残す。
8.4 手順設計（手順のブレをなくす）
8.5 体制設計（誰が何をできるか）
- 実行権限：本番で L3 を実行できる人を限定する（最小権限）。
- 承認：大規模サイトでは L3 purge をチケット紐付けにする。
- 緊急時：障害時のみ例外ルールを用意する（ただし記録必須）。
8.6 セキュリティ運用（更新を回す仕組み）
- プラグインの脆弱性は現実に発生する。更新遅れはリスクになる。[10]
- 自動更新の活用と、更新後のチェック手順をセットで設計する。
9. WP-CLI で実際にできる操作（技術的詳細）
ここでは、スクリプト設計に直結する WP-CLI の事実を整理する。WP-CLI は WordPress をコマンドラインから操作する仕組みで、公式サイトとドキュメントがある。[21]
9.1 L1：トランジェント削除
トランジェントは WordPress の期限付きキャッシュであり、WP-CLI からは transient delete が使える。–all で全削除もできる。[22]
9.2 L2：オブジェクトキャッシュ flush
wp cache flush はオブジェクトキャッシュを flush する。マルチサイトや永続キャッシュでは影響が大きくなり得るため注意が必要と明記されている。[2] なお Redis 系のオブジェクトキャッシュでは、専用コマンドが提供されることもあり、データ消失の危険があるため分離が推奨される、という注意もある。[23]
9.3 L3：W3 Total Cache の purge
W3TC の「empty all caches」は管理画面で提供される。[5] WP-CLI 経由で flush する例も紹介されている。[14]
9.4 L4：CDN / ブラウザ
CDN を使う場合、推奨は「特定 URL を purge」するような狭い操作である。Cloudflare は purge の方法と API を公開している。[6] [15]
10. ラッパースクリプトの設計チェックリスト（実装前に固める）
| 観点 | 要件 | 理由 |
|---|---|---|
| 対象同定 | –path 必須、URL allowlist | 誤爆防止 |
| 段階実行 | L1→L2→L3 を固定 | 原因切り分けと最小影響 |
| 分岐 | W3TC は二重チェックで検出 | 誤判定防止 |
| 排他 | 同時実行を拒否 | 負荷と混乱を防ぐ |
| レート制限 | L3 全 purge を抑制 | 高負荷トリガを制御 |
| ログ | reason 必須、層・対象・結果を記録 | 説明責任と再現性 |
| ドライラン | 実行予定を表示できる | 運用者が確認できる |
| エラーコード | 原因ごとに分ける | 自動化と監視に接続 |
WP-CLI のグローバルパラメータ（–path など）自体も公式に整理されているため、設計の根拠として参照できる。[11]
なお、実際に実装したコードは wp_cachectl.py である。
11. まとめ：この設計が目指すもの
この記事の設計思想は一貫している。キャッシュは性能のための仕組みであり、日常的に掃除する対象ではない。運用としては、状態が変わるイベントの境界で、必要最小限を段階的に整合させる。さらに、事故は精神力では防げないので、運用ルールをコード（安全ラッパー）に落として「間違えにくい仕組み」にする。この流れにより、「更新したのに反映されない」問題は、感覚や経験ではなく、層モデルと段階手順で説明できるようになる。そして運用設計は「いつ消すか」だけでなく、変更管理、事故防止、観測、復旧、セキュリティ、権限、コストという複数観点で整合した形になる。
参考文献
- IETF, “RFC 9111: HTTP Caching”. https://www.rfc-editor.org/rfc/rfc9111.html
- WordPress.org, “wp cache flush – WP-CLI Command”. https://developer.wordpress.org/cli/commands/cache/flush/
- WordPress.org, “Transients – Common APIs Handbook”. https://developer.wordpress.org/apis/transients/
- WordPress.org, “wp cache – WP-CLI Command”. https://developer.wordpress.org/cli/commands/cache/
- BoldGrid, “W3 Total Cache Documentation”. https://www.boldgrid.com/support/w3-total-cache/
- Cloudflare, “Purge cache (How-to)”. https://developers.cloudflare.com/cache/how-to/purge-cache/
- WordPress.org, “Updating WordPress – Documentation”. https://wordpress.org/documentation/article/updating-wordpress/
- WordPress.org, “wp core update-db – WP-CLI Command”. https://developer.wordpress.org/cli/commands/core/update-db/
- WordPress.org, “Plugin and themes auto-updates – Documentation”. https://wordpress.org/documentation/article/plugins-themes-auto-updates/
- TechRadar, “WordPress plugin with over a million installs may have a worrying security flaw – here’s what we know”. https://www.techradar.com/pro/security/wordpress-plugin-with-over-a-million-installs-may-have-a-worrying-security-flaw-heres-what-we-know
- Make WordPress, “Config – WP-CLI Handbook (Global parameters, e.g. –path)”. https://make.wordpress.org/cli/handbook/references/config/
- Conetix, “Clearing a W3 Total Cache’s Page Cache”. https://conetix.com.au/support/clearing-w3-total-cache-page-cache/
- GitHub, “wp-cli/cache-command”. https://github.com/wp-cli/cache-command
- WebHostingHub, “Clear W3 Total Cache Using WP-CLI”. https://help.webhostinghub.com/hc/en-us/articles/14847429042967-Clear-W3-Total-Cache-Using-WP-CLI
- Cloudflare, “Purge Cached Content – Cloudflare API”. https://developers.cloudflare.com/api/resources/cache/methods/purge/
- NGINX, “Module ngx_http_proxy_module (purge)”. https://nginx.org/en/docs/http/ngx_http_proxy_module.html
- NGINX, “Content Caching (Admin Guide)”. https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/
- WordPress VIP Docs, “Flush the object cache”. https://docs.wpvip.com/caching/object-cache/flush-the-object-cache/
- WordPress.org, “wp transient delete – WP-CLI Command”. https://developer.wordpress.org/cli/commands/transient/delete/
- WordPress.org, “wp core update-db – WP-CLI Command”. https://developer.wordpress.org/cli/commands/core/update-db/
- WP-CLI, “WP-CLI project site”. https://wp-cli.org/
- Cloudflare, “Cache docs (Purge overview)”. https://developers.cloudflare.com/cache/
- Object Cache Pro Docs, “WP CLI – Flushing / Redis flush cautions”. https://objectcache.pro/docs/wp-cli