WordPress自動保存の上書きで記事が消えた二重編集の話

AIに入稿まで任せられるようにしたのに、足したはずの一節が次に開いたら消えていた——そんな経験はありませんか？
私が先日踏んだのは、WordPressの自動保存が古い版で上書きして書いた記事が消えた、という現象でした

正体を先に言っておきます
これは行が削除されたのではなく、自動保存が”古い版”で上書きしただけです

同じ本文を2つの書き手が奪い合って、後から保存した方が勝つ
この二重編集の後勝ちが原因で、何が起きて、どう防ぐかまでを実録で残します

自動保存の上書きで書いた記事が消えた、その一部始終

まずは、起きたことを順番に振り返ります
まだ下書きだったある記事に、AIでMCP経由の一節を追記して、反映されたのを画面でも確認したところまでは、いつも通りでした

ところが数分後、ブラウザで開いたままにしていた編集画面を何気なく触ったら、足したはずの一節が消えて、追記する前の版に戻っていました
手元の原稿と見比べると、確かに追記前の状態まで巻き戻っていたんです

WordPressを使っていると、編集画面で「以下のバージョンよりも新しい自動保存された投稿があります」という一文を見たことはありませんか？
あれは、いま画面が持っている版と、保存された版がズレたときに出るサインです

差分を確かめて分かったのは、”消えた”の正体でした
行が削除されたのではなく、古い版で上書きされただけ、という結論です

なぜ消えるのか——2つの書き手の”後勝ち”

犯人捜しではなく、仕組みの話です
WordPressの本文には、じつは独立した2つの”書き手”がいます

• AI・ツール側=MCP(REST API)から本文を書きにくる書き手
• ブラウザの編集画面(ブロックエディタ)の自動保存という書き手

MCPやREST APIって何、という部分は、本家の Claude Codeの拡張機構の入門記事 にまとめています
ここでは”外から本文を書きにくる、もう1人の書き手”くらいの捉え方で十分です

この2人が同じ本文を書きに行くと、後から保存した方が勝ちます
WordPressが競合を気を利かせて混ぜてくれるわけではないので、片方の変更がまるごと消えます

キモは、編集画面の性質です
編集画面は開いた時点の(古い)本文を握ったままで、その後AIがRESTで新しい版に更新しても、画面側は古いままなんです

その古い版を握った画面が、自動保存のタイミングで保存する
その瞬間に古い版で上書きされて、足した一節が消える、という流れです

イメージは、同じノートを2人が別々に書き写している状態です
片方が新しい内容に更新しても、もう片方は古いノートを持ったまま、後からそれで上書きしてしまう、という感じでしょうか

順番にすると、こういう流れで足した分が消えます

• ブラウザで編集画面を開く(この時点の古い本文を握る)
• AIがRESTで本文を新しい版に更新する
• 開いたままの画面が、握っている”古い版”で自動保存する
• 後勝ちで上書きされ、足した分が消える

AIでブログ運営するなら、自動保存(オートセーブ)を切る

ここからが、今回いちばん伝えたいところです
先ほど見た後勝ちは、手元の原稿を正本にしてAIにMCPで入稿する——という経路を一方に寄せた人ほど、自動保存が保険にならず、リスクだけが残ります

画面で本文を手打ちしないなら、自動保存が守ってくれる”書きかけ”はそもそもありません
むしろ開きっぱなしの画面が古い版で上書きしてくる火種になるので、自動保存そのものを切るという選択が出てきます

入稿の仕組みそのものは、前回作った AIに記事の入稿まで任せる仕組み にまとめています
ここでは自動保存の無効化のやり方を、やさしい順に3つ並べます

方法1 プラグインで切る(ノーコードでいちばん手軽)

コードもファイル編集もいらない、いちばん手軽な方法です
SWELLが使うブロックエディタの自動保存に直接効く Disable Gutenberg Autosave というプラグインを使います

ひとつ添えておくと、これで完全に止めきるわけではありません
プレビューを押したときの保存やブラウザ側の一時保存までは残りますが、開きっぱなしのタブがタイマーで古い版を書き戻す事故は、これでかなり起きにくくなります

方法2 wp-config.php で間隔を延ばす(実質オフにする)

ここからはファイルを直接いじる方法です
wp-config.php という、WordPressの奥にある設定ファイルに1行だけ足して、自動保存の間隔を延ばします
これはSWELLが使うブロックエディタの自動保存にも効きます(WordPress 5.1以降、ブロックエディタもこの間隔にしたがうため)

ファイルの置き場所は、Xserverなら {ドメイン}/public_html/wp-config.php です
ドメイン直下にWordPressを入れていれば public_html のすぐ下にあり、サブフォルダに入れたならそのフォルダの直下になります
SFTP/FTPで開いて編集する手順は、前回の FileZillaでXserverにファイルを送る記事 にまとめています

define( 'AUTOSAVE_INTERVAL', 86400 ); // 秒(=24時間ぶん、実質オフに近い)

この1行を、ファイル中ほどの「編集が必要なのはここまでです」(英語のままなら That’s all, stop editing!)という行より上に書き足します
数字は秒で、60が既定(1分ごと)、300で5分ごと、86400で24時間ごとになります

気をつけたいのは、これは自動保存を完全に止める設定ではなく、間隔を延ばして実質オフにするものだという点です
86400にしても24時間後には保存が走るので、ゼロにはなりません
方法1と同じくブラウザ側の一時保存は別に残りますが、そちらはサーバーの本文を書き換えないので、後勝ちの火種にはなりません

方法3 functions.php(子テーマ)で止める

最後は、子テーマの functions.php にコードを書いて止める方法です
ただ、この方法には大きな前提があります

下のコードが効くのはクラシックエディタだけで、SWELLが使うブロックエディタの自動保存は別のしくみで動くので止まりません
つまりSWELLのこのブログでは、この方法だけだと今回の事故は防げず、切りたいなら方法1が本命になります

// 子テーマの functions.php に追記(効くのはクラシックエディタだけ)
add_action( 'admin_enqueue_scripts', 'zerokara_disable_autosave' );
function zerokara_disable_autosave() {
    if ( is_admin() ) {
        wp_deregister_script( 'autosave' );
    }
}

コードは子テーマのほうに書くのが原則です
親テーマに直接書くと、テーマを更新したときに消えてしまうからです

切っても切らなくても、戻せる道は用意しておきます
手元の原稿(ローカルのファイル)が正本なので、ズレたら再アップで戻せますし、WordPress側でもリビジョンから前の版に戻せることがあります

ただ、リビジョンの画面で「このリビジョンを復元」や「この自動保存を復元」を押すと、選んだ版で本文がまるごと入れ替わります
古い自動保存版に戻してしまうこともあるので、戻す先は中身を確かめてからにします

AIと私の分担

この事故の復旧と再発防止でも、AIと私の分担を整理しておきます

まとめ、そして次の一歩

二重編集の落とし穴を振り返ります
経路を一方に寄せると自動保存オフ、この2つを組み合わせると後勝ちが構造的に起きにくくなります

ただし公開済みの記事を古い画面から手動で更新した後勝ちは残るので、タブを閉じる・現物を確認する、も一緒に続けます
この後勝ちの上書きは、AIに運用を任せるほど起きやすいものなので、最初から仕組みに組み込んでおくと、あとがラクになります

最後に、次の一歩です
文体まで育てたAIに任せる流れは、前回の ブログ用AIの育て方 にまとめました
そこに今回の”経路を一方に寄せる”と”自動保存オフ”を足すと、書く・入稿する・直すの一連が、後勝ちで崩れにくくなります