毎月1回、AIに記事への「追記」を頼んでいる

このブログには、相模原市の亀ヶ池八幡宮でいただく「月替わり限定御朱印」の記事があります。1年に1本の記事を作り、毎月1日分ずつ、御朱印と境内の写真を書き足していく形です。

以前はこの追記を、編集画面で画像をアップロードして、HTMLを手で貼り付けて……と自分でやっていました。いまは AI（Claude Code）にお願いして、追記用の小さなプログラムで行っています。

流れはこんな感じです。

1. 写真に写り込んだ人の顔をぼかし、ぼかしで大丈夫か自分が確認する
2. 御朱印のスキャン画像を切り抜き、写真と一緒に縮小する
3. プログラムが WordPress に画像をアップロードし、「その月のブロック」を記事の最後の手前に差し込む

公開中の記事は、自分でいったん「下書き」に戻してから追記を頼み、確認してから自分で公開し直す、というルールにしています。

この仕組みで、令和8年の記事には1月から順に追記してきました。ところが10月17日、記事を開いてみると 2月から8月までの7か月分が、まるごと無くなっていた のです。

何が起きていたのか：古い画面からの「保存」

原因は、WordPress の 開いたままになっていた古い編集画面 でした。

少し仕組みを説明します。WordPress の編集画面は、開いた瞬間の本文を画面の中に持っています。その画面を開きっぱなしにしている間に、別のところ（今回は AI のプログラム）が記事に追記しても、画面の中の本文は古いまま です。

そこで「更新」や「保存」を押すと、どうなるか。WordPress は画面に表示されている内容で記事を上書きします。つまり、後から足した追記は、古い本文で上書きされて消えてしまうのです。

人間が2人で同じ記事を編集すると、WordPress は「他のユーザーが編集中です」と警告を出してくれます。

ただ、今回は同じアカウントでの編集画面と、プログラムからの更新でした。この組み合わせでは、警告に気づけないまま保存できてしまいます。

リビジョンで7か月分を取り戻した

焦りましたが、WordPress には リビジョン という仕組みがあります。

リビジョンとは、記事を保存するたびに WordPress が自動で残してくれる「過去の版」です。Word やExcel の「以前のバージョン」のようなもの、と考えると分かりやすいと思います。

復元の手順は次のとおりです。

1. 記事の編集画面を開き、右側の設定パネルにある「リビジョン」をクリック
2. 画面上部のスライダーを動かして、版を1つずつさかのぼる
3. 左右に並んだ「変更前」と「変更後」を見比べて、8月分まで入っている最後の版を探す
4. 「このリビジョンを復元」をクリック

今回は AI に、REST API から記事のリビジョン一覧を取り出してもらい、「どの版に何月分まで入っているか」を数えてもらいました。人の目でスライダーを1つずつ見比べるより、ずっと早く目当ての版が見つかりました。

ここで安心できたのは、リビジョンの復元も、それ自体が新しいリビジョンとして残る ことです。もし間違った版に戻してしまっても、もう一度やり直せます。消えたと思った7か月分は、画像も含めて元どおりになりました。（画像そのものはメディアライブラリに残っていて、消えたのは本文の中の「貼り付け」だけでした。）

2017年の自分は「リビジョンを消す」記事を書いていた

実はこのブログには、2017年に書いた「リビジョンとデータベースの最適化プラグイン」という記事があります。たまったリビジョンを削除して、データベースを軽くするプラグインの紹介です。

当時は「リビジョンは増えすぎると重くなるもの」という見方が中心でした。もちろん、それも間違いではありません。ただ今回、リビジョンが残っていたから助かった のも事実です。

もし最適化で古いリビジョンを全部消していたら、復元できなかったかもしれません。【要確認：現在このサイトで最適化プラグインを使っているか、リビジョン数の上限を設定しているか】 リビジョンを整理するなら、「全部消す」ではなく「直近の何件かは残す」設定にしておくのが安心だと、いまは考えています。

同じことを起こさないために、AI側に足した3つの安全装置

復元したあと、追記用のプログラムを AI と一緒に見直しました。「人間が気をつける」だけでは、また同じことが起きると思ったからです。

安全装置1：前の月が欠けていたら、追記しない

プログラムは追記の前に、記事の中に1月から前の月までのブロックが全部そろっているかを確かめます。1つでも欠けていたら、「古い本文で上書きされていないか、リビジョンを確認してください」と表示して止まります。

もし気づかずに次の月を追記していたら、欠けた状態の本文の上にさらに書き足すことになります。おかしな状態のまま先へ進まないことが、一番大事だと感じています。

安全装置2：下書きでなければ、変更しない

元の記事に直接追記するのは、記事が「下書き」のときだけにしました。公開中の記事に誤って書き込むことはありません。公開に戻すのは、いつも自分の手です。

安全装置3：追記の前に、元の本文をファイルに残す

追記の直前に、その時点の本文をまるごとパソコンにファイルとして保存するようにしました。リビジョンは WordPress の中にあるので、サーバー側で何かあれば一緒に失われます。手元にも1つ控えを置いておく、という考え方です。

人間側のルールも1つ増えた

プログラムを直しただけでは足りません。自分の側にも、ルールを1つ足しました。

AI に追記を頼む前に、その記事の編集画面を閉じる。

これだけです。AI にも「追記の前に、編集画面を閉じたか確認すること」と覚えてもらい、毎回ひと声かけてもらうようにしました。ブラウザのタブをたくさん開いたまま作業するクセがあるので、自分にはこれが一番効くと思っています。

AIでWeb制作を手伝ってもらうときに感じたこと

AI に記事の更新を任せると、作業はとても楽になります。一方で、「人が触る画面」と「AI が触る裏側」が同時に動く ようになりました。今回の事故は、まさにその境目で起きています。

長くWeb制作をしてきて、データが消えるトラブルは何度も見てきました。そのたびに思うのは、「消えないようにする」よりも「消えても戻せるようにする」ほうが現実的だということです。

• WordPress のリビジョン
• 手元に残す本文の控え
• おかしな状態なら止まるプログラム

この3つがそろっていれば、少なくとも「取り返しがつかない」ことにはなりにくい。AI が手を動かす時代になっても、ここは変わらないと感じました。

まとめ

• WordPress の編集画面は、開いた時点の本文を持っている。開きっぱなしの古い画面で保存すると、後からの追記が上書きされて消える
• 消えてしまっても、リビジョン から過去の版を探して復元できる。復元自体も新しいリビジョンとして残るので、やり直しがきく
• リビジョンを整理するなら、全部は消さずに直近の分を残しておく
• AI やプログラムで記事を更新するなら、「欠けていたら止まる」「下書き以外は触らない」「直前の本文を手元に残す」の3つを入れておくと安心
• 人間側は、AI に頼む前に編集画面を閉じる

記事が消えたときは本当に血の気が引きましたが、WordPress が黙って残してくれていた版に助けられました。同じように AI やプログラムで記事を更新している方の参考になればうれしいです。