自動保存は「命綱」だけど、デフォルトがベストとは限らない
WordPress の「自動保存」は、投稿画面で記事を書いているときに、
一定間隔ごとに下書き状態を自動で保存してくれる仕組みです。
ブラウザが落ちた
PC がフリーズした
誤ってタブを閉じた
こういうときに、「さっきまで書いていた内容」が完全に消えずに済むのは、この自動保存のおかげです。
プログラミングで言えば、エディタの「オートセーブ」や IDE の「クラッシュ復旧」に近い“命綱”です。
ただし、この自動保存の「間隔」は固定ではなく、コードで調整できます。
デフォルトのままでも動きますが、サイトや書き方によっては、少しチューニングした方が快適になることがあります。
デフォルトの自動保存の動き方をイメージしよう
どれくらいの間隔で保存されているのか
WordPress では、投稿画面を開いて記事を書いていると、
一定時間ごとに「自動保存しました」というメッセージが出ます。
これは内部的には、
JavaScript から定期的に Ajax リクエストが飛び、
サーバー側で「自動保存用のリビジョン」が作られている動きです。
デフォルトでは、この間隔は 60 秒（1 分）です。
つまり、「1 分ごとに今の状態をサーバーに送っている」と考えてください。
1 分というのは、
「短すぎず長すぎず」の無難な値ですが、
記事の長さや書き方によっては、もっと短くしたい・逆に長くしたい、というニーズが出てきます。
自動保存と「通常の保存」は別物
ここで大事なのは、
自動保存はあくまで「保険」であって、
あなたが「更新」や「下書きとして保存」を押したときの保存とは別枠だ、ということです。
自動保存は、
ブラウザが落ちたときに「復元候補」として使われる一時的なデータ。
通常の保存は、「今の状態を正式な下書き／公開状態として確定する」操作。
この二つは役割が違うので、
自動保存の間隔を変えても、「更新ボタンを押したときの挙動」は変わりません。
なぜ自動保存の間隔を調整したくなるのか
短くしたいパターン：書いている量が多くて不安なとき
長文記事を書いているときや、
ブラウザや回線が不安定な環境で作業しているときは、
「もっとこまめに自動保存してほしい」と感じることがあります。
例えば、
1 分の間に 500 文字くらい一気に書くタイプの人だと、
「1 分前に戻る」と言われても、結構な量が消える感覚になります。
この場合、自動保存の間隔を 30 秒や 20 秒に短くすれば、
「最悪でも 30 秒前の状態までは戻れる」
という安心感が増します。
プログラミングで言えば、
「オートセーブの頻度を上げて、クラッシュ時のロスを減らす」
というチューニングです。
長くしたいパターン：サーバー負荷やリビジョン増加が気になるとき
逆に、
共有サーバーで複数人がガンガン記事を書いているような環境では、
1 分ごとの自動保存が大量のリクエストとリビジョンを生みます。
特に、
1 記事に対して何時間も編集し続ける
その間ずっと 1 分ごとに自動保存が走る
という状況だと、
データベースに自動保存用の履歴がかなり溜まります。
「投稿リビジョン数を制限」していても、
自動保存の頻度が高すぎると、
「常に最新の数件を入れ替え続ける」状態になり、
サーバーへの書き込み回数が増えます。
この場合、
自動保存の間隔を 120 秒（2 分）や 180 秒（3 分）に伸ばすことで、
サーバー負荷とリビジョン生成の頻度を少し抑えることができます。
実装イメージ：AUTOSAVE_INTERVAL で間隔を変える
wp-config.php に定数を追加する
自動保存の間隔は、wp-config.php に AUTOSAVE_INTERVAL という定数を定義することで変更できます。
イメージはこんな感じです。
define( 'AUTOSAVE_INTERVAL', 120 ); // 秒数で指定（ここでは 120 秒 = 2 分）
この例では、
「自動保存の間隔を 120 秒（2 分）にする」
という意味になります。
30 秒にしたければ 30、
90 秒にしたければ 90、
というように、秒数で指定します。
どこに書くかのイメージ
wp-config.php は、WordPress のルートディレクトリにある設定ファイルです。
中身には、
データベース設定
認証用キー
デバッグ設定
などが書かれています。
AUTOSAVE_INTERVAL を追加するときは、
だいたい /* That's all, stop editing! */ と書かれている行より上あたりに、
他の define と並べて書くイメージです。
プログラミング的には、
「アプリケーションのグローバル設定値を一つ追加する」
という感覚で捉えてください。
調整するときに意識しておきたいバランス
短くしすぎるとどうなるか
例えば、自動保存間隔を 5 秒や 10 秒にしてしまうと、
ほぼ常に自動保存が走り続ける状態になります。
その結果、
サーバーへのリクエストが増えすぎる
編集中に微妙なラグを感じることがある
リビジョンの入れ替わりが激しくなる
といったデメリットが出てきます。
「こまめに保存されて安心」よりも、
「なんか重い」「書いていてストレス」という感覚の方が強くなるかもしれません。
現実的には、
短くしても 20〜30 秒程度にしておくのが無難です。
長くしすぎるとどうなるか
逆に、5 分（300 秒）や 10 分（600 秒）などにすると、
「自動保存の意味が薄くなる」リスクがあります。
5 分あれば、
かなりの量を書き換えることができます。
その状態でブラウザが落ちると、
「5 分前の状態までしか戻れない」
というのは、かなり痛いロスです。
「自動保存を信頼できるかどうか」は、
自分の書き方と間隔のバランスで決まります。
天才プログラマー的に言えば、
「障害時に許容できる最大ロス時間（RPO）」を決めて、
それに合わせて自動保存間隔を設定するイメージです。
具体例でイメージする設定パターン
例1：一人でブログを書いている場合
あなたが個人でブログを書いていて、
1 記事あたり 30 分〜1 時間くらいかけて書くとします。
この場合、
自動保存間隔を 60 秒（デフォルト）のままでも十分ですが、
「ちょっと不安だな」と感じるなら 30 秒にしても良いでしょう。
wp-config.php に
define( 'AUTOSAVE_INTERVAL', 30 );
と書いておけば、
最悪でも 30 秒前の状態までは戻れる、という安心感が増えます。
例2：複数人で更新する企業サイト
複数の担当者が同時に記事を書いたり、
長時間編集することが多い企業サイトでは、
サーバー負荷も少し意識したくなります。
この場合、
自動保存間隔を 120 秒（2 分）程度に伸ばす、という選択肢もあります。
wp-config.php に
define( 'AUTOSAVE_INTERVAL', 120 );
と書けば、
自動保存の頻度は半分になり、
サーバーへの書き込み回数も少し抑えられます。
その代わり、
「最悪 2 分分の作業は消えるかもしれない」
という前提で運用することになります。
プログラミングの感覚で「自動保存間隔」を捉える
これは「オートセーブのポリシー設計」
エディタや IDE でも、
「何秒ごとにオートセーブするか」
「フォーカスが外れたときだけ保存するか」
といった設定があります。
WordPress の AUTOSAVE_INTERVAL は、
まさにその「オートセーブポリシー」を決める設定です。
重要なのは、
「デフォルトだからそのまま」ではなく、
「自分の書き方とサーバー環境に合わせて、一度は考えてみる」ことです。
「安全性」と「負荷」と「快適さ」の三つ巴
自動保存間隔を短くすると、
安全性（ロスの少なさ）は上がるが、負荷とラグのリスクが増える。
長くすると、
負荷は減るが、ロスのリスクが増える。
この三つのバランスをどう取るかが、
天才プログラマー的な設計ポイントです。
まとめ：自動保存は「信頼できる間隔」に自分でチューニングする
「自動保存の間隔を調整する」というのは、
自分がどれくらいの作業ロスなら許容できるか
サーバーにどれくらいの頻度で書き込みをさせたいか
編集時の快適さをどこまで優先するか
を、自分のサイトと自分の書き方に合わせて決める、ということです。
wp-config.php に
define( 'AUTOSAVE_INTERVAL', 30 ); // もっとこまめに守りたい
// あるいは
define( 'AUTOSAVE_INTERVAL', 120 ); // 負荷を少し抑えたい
と 1 行足すだけで、
WordPress の「命綱」の動き方は、あなた仕様に変わります。
もし今、
「長文を書いていて、ブラウザが落ちたら怖い」
「サーバーがちょっと重い気がする」
どちらか一つでも心当たりがあるなら、
自動保存間隔を一度だけでも“自分で決めてみる”価値はかなり大きいです。
