更新しないサイトなら、バックアップも年1回でいい？——WordPressで頻度と世代を分けて考える

更新頻度の低いコーポレートサイトを受託で作り、公開が見えてきた頃に、施主からこう聞かれました。「事例の更新は年に一度くらいなので、バックアップの頻度も年1回にして固定費を下げられませんか」。私は反射的に「頻度を落としてもコストは下がりません」と否定の回答を書きました。ところが施主から、こう反論が返ってきました。「更新が年1回ならバックアップも年1回で問題ないのでは。週1回取っても中身は変わらないのだから」。

これは正しい指摘でした。そして私の最初の回答は、正しい部分を認めないまま代案だけを押し出す、噛み合わない形になっていました。反論されて初めて、自分が何を混ぜて話していたのかが分かりました。

先に結論——頻度を落としても安くはならない、でも「触らないサイトほど世代が要る」

結論を2つ先に置きます。1つ目、自動化済みのバックアップは、頻度を年1回に落としても固定費は下がりません。費用の実体は人件費で、自動実行にした後の1回あたりのコストはほぼゼロだからです。「頻度」というつまみは、すでに費用につながっていません。

2つ目、むしろ「めったに更新しないサイト」こそ、過去の複数時点に戻れる”世代”が要ります。直感と逆ですが、放置前提の運用ほど「壊れてから気づくまでのラグ」が長く、そのラグが保持期間を超えた瞬間に、保持1本のバックアップは価値を失うからです。落としてよいのは頻度そのものではなく、後述する「重いファイルの取得間隔」だけです。

「バックアップ頻度」という一語が、性質の違う3つの価値を束ねている

噛み合わなかった原因はこれでした。「バックアップの頻度」という言葉が、依存する変数の違う3つの価値を1つに束ねていたのです。分けると、施主の理屈がどこに効いてどこに効かないかがはっきりします。

施主が語っていたのは①だけで、そこは完全に正しいのです。私が言いたかったのは②と③でした。①を否定する形で話し始めたので、噛み合いませんでした。「半分正しい、正しいのはここ、効かないのはここ」と分けて返すべきでした。

世代がなぜ効くのか——バックアップは「壊れた時」ではなく「気づいた時」に使う

バックアップを取り出す瞬間は、たいてい「壊れた時」ではなく「壊れたと気づいた時」です。この2点にはラグがあります。改ざん・設定事故・プラグインの不整合は、誰も見ていなければ何ヶ月でも気づかれません。年1回・保持1本の運用でこのラグが効くと、こうなります。

保持1本の年次バックアップは、ラグが1年を跨いだ瞬間に価値がゼロになります。これは「どこまで巻き戻せるか」ではなく「無事な版が1本でも残っているか」の問題で、中身の更新頻度とは無関係に成立します。放置前提の運用ほど気づくまでのラグが長いので、触らないサイトこそ世代が要る——直感と逆になるのはこのためです。

失敗検知——バックアップは静かに失敗する

バックアップは静かに失敗します。保存先の容量超過、クラウド連携の認証トークン切れ、サイトが育ってからの実行時間切れ。どれもサイトの表示には何の影響も出ないので、通知を見ていなければ誰も気づきません。週次なら1回失敗しても前週分が残りますが、年次で失敗するとその年の在庫はゼロで、しかもそれが分かるのは次に必要になった時です。「取ったつもりで取れていない」を確かめる話は、反映したはずが本番が変わらない——確かめ方を間違えた3つの現場とも地続きです。仕組みは動いていても、結果を確かめない限り「動いているつもり」から抜け出せません。

そして本丸——頻度を落とす「理由」のほうが、そもそも成立していなかった

ここまでは②③の話ですが、より根本的な見落としがありました。議論の前提が「頻度を落とす＝安くなる」でしたが、それ自体が成立していなかったのです。

固定費の実体は人件費で、自動実行にした後の1回あたりのコストはほぼゼロです。週1でも年1でも、人が動かないなら請求の根拠は変わりません。つまり「安くするために頻度を落とす」という交換自体が、最初から存在していませんでした。施主は「頻度」というつまみを回そうとしていましたが、そのつまみは費用につながっていなかったのです。削減の相談を受けたときは、まず「そのつまみは本当に費用につながっているか」を確かめるのが先だと、後から気づきました。

ただし、頻度を上げるコストが実在する場所が1つだけある——容量

1箇所だけ、施主の直感がそのまま効く場所があります。ストレージ容量です。そして効く対象は限定できます。

DBは軽いので世代を厚く持ち、重いファイルだけ間隔を空ける。結論は施主の直感に近い場所へ着地しましたが、理由が違います。「事例の更新が年1回だから」ではなく「ファイルは増えないから、ファイルだけ落とす」。DBと世代数は落としません。ここを混ぜて「全部を年1回に」としてしまうと、②の世代が消えてしまいます。

有料の提案をする前に——無料で既に動いている標準機能を数える

固定費の相談なら、まずすでに無料で動いているものを数えるのが先でした。国内大手のエックスサーバーには自動バックアップが標準で付いています。公式の案内を確認したところ、全プラン標準で初期費用も月額も0円、1日1回バックアップ専用サーバーへ自動コピー、Web・メール・MySQL いずれも過去14日分を保持し、サーバーパネルから利用者自身が復元できると明記されていました（エックスサーバー「自動バックアップ」／2026年8月時点。一部の旧サーバーはWeb・メールが7日分の旨も併記）。契約している時点で、すでに毎日14日分が無料で取られていたわけです。

一方、定番のバックアッププラグインである UpdraftPlus は、無料版のバックアップ範囲が名前の印象より狭い点に注意が要ります。公式ページによれば、無料版がバックアップするのは「WordPressのcontentディレクトリ内のすべてのファイル（plugins、themes、uploads など）」で、wp-config.php・WordPress本体のカスタマイズ・通常のWordPress構造の外にあるディレクトリは有料機能（Back up More Files）が追加するもの、と明記されています（UpdraftPlus 公式「Back up More Files」／2026年8月時点）。

ここで狙ったわけではないのに、2つの無料手段が正確に補完し合っていました。UpdraftPlus 無料版が取りこぼす WordPress本体・wp-config.php・.htaccess は、エックスサーバー側の「Web領域まるごと14日分」に入っています。（.htaccess はルート直下＝wp-content の外なので UpdraftPlus 無料版の対象外、というのは公式の「wp-content外は有料」記述からの私の推論で、公式が .htaccess を名指ししているわけではありません。この点は断定を避けます。）

この2層を重ねると、理屈の上で残る穴は「15日以上前の wp-config.php と .htaccess」だけです。しかもこの2つは、いざとなれば再作成できます。DB接続情報はサーバー管理画面にありますし、.htaccess のパーマリンク部分は WordPress が自動生成します。この穴を埋めるためだけに有料版を買う必要はない、というのが実査した上での判断でした。先に足元の無料在庫を数えないと、要らない在庫を売る提案になってしまいます。

持ち帰れる形——バックアップの相談で混ぜないための6点

• 「頻度」を1つのつまみとして議論しない。復元の粒度（失う量）・到達できる過去の範囲（世代）・仕組みの健全性（失敗検知）は、束ねられているが依存する変数が違う。相手がどれを指しているかを先に特定する
• 相手の理屈が正しい部分は、代案より先に認める。「半分正しい、正しいのはここ、効かないのはここ」と分けて返す
• 削減の相談では、まず「そのつまみは本当に費用につながっているか」を確かめる。自動化済みの作業では、頻度と費用のリンクは既に切れている
• バックアップの価値は「どこまで戻れるか」より「無事な版が1本でも残っているか」で決まる場面がある。放置前提の運用ほど気づくまでのラグが長いので、触らないサイトこそ世代が要る
• 有料の提案をする前に、無料で既に動いている標準機能を数える。レンタルサーバー側が毎日14日分を無料で取っていることは珍しくない
• 「バックアップ」という語の指す範囲を、相手やツールと揃えてから話す。WordPressはDBとファイルの両方が揃わないと復元できない（DBだけ戻すと画像が消え、ファイルだけ戻すと記事が消える）。製品名だけで安心せず、対象ファイルの範囲を実際に確認する

技術的な提案が拒まれるとき、相手はたいてい間違っているのではなく、別の正しいことを言っている——今回いちばん残ったのはこの感覚でした。日々の受託の現場で踏んだ判断は受託の現場でClaude Codeを毎日使うにもまとめています。