WordPressの記事だけをバックアップする方法|エクスポートでは1本だけ戻せない理由と、一括編集の前に本文を退避する仕組み【2026年最新】

記事の本文を書き換える前に1本ずつ退避し戻せる形で残すことを示すイメージ

「WordPressの記事を大きく書き換える前に、その記事だけバックアップしておきたい」 「調べたら『ツール→エクスポート』か『サーバーの自動バックアップ』と出てきた。でも、それで1本だけ戻せるのか分からない」 「一括で直したら、記事がおかしくなった。元の本文が手元にない」

3つ目まで来た人は、バックアップの取り方ではなく「戻し方」の話を読んでください。この記事はそこから始めます。

先に結論です。WordPressの記事だけをバックアップする方法は、公式の「エクスポート」機能でも、サーバー会社の自動バックアップでもありません。書き換える直前に、その記事の本文だけを1本ずつファイルに退避するのが、いちばん単純で、いちばん戻しやすい方法でした。筆者のブログでは、記事の本文を機械で書き換えるときは必ずこれをやっていて、退避したファイルは110本たまっています。

ただし、たどり着くまでに2回、記事を壊しました。

  • 1回目:広告ブロックを一括で差し替えたら、変換されなかった目印の文字がそのまま読者に見える状態で公開されていた
  • 2回目:5本の記事のタイトル欄に、本文が丸ごと(1,700〜1,800字)流し込まれていた
  • どちらも「元の状態」が手元になく、戻すのに書き換えた時間の何倍もかかった

筆者は40代の会社員(非エンジニア)です。プログラムは書けません。この記事では、AIに作ってもらった「本文だけを退避する道具」を1つのブログで運用して分かったことを、エクスポートで1本だけ戻せない理由から、退避と戻し方の手順まで、専門用語を噛み砕いて説明します。

※ 本記事は Claude Code(筆者が使用中のAIアシスタント)が筆者の実体験を元に執筆しています。


この記事はこんな方向け

  • 記事を一括で書き換える前に、その記事だけ元に戻せる状態にしておきたい人
  • 「エクスポート」を取ってはいるが、1本だけ戻したことは一度もない人
  • サーバーの自動バックアップを「保険」だと思っているが、戻すと他の記事まで巻き戻ることに気づいていない人
  • プラグインをこれ以上増やしたくない人

🎬 この記事に登場するキャラ

  • 社長 — 筆者本人(40代・副業で複数の事業を運営)
  • 凛 — 姉御肌の相棒。甘えを許さない
  • 策 — 冷静な軍師。手順に落とす担当
  • Claude — AIアシスタント。実測値を出す担当

社長:「エクスポートは月イチで取ってるんだよ。だから安心してたんだけどさ。」

凛:「で、5本のタイトルが本文になった日、そのエクスポートで戻したの?」

社長:「……戻してない。どうやって1本だけ戻すのか分からなくて、結局手で打ち直した。」

策:「それがこの記事の答えです。バックアップは「取れたか」ではなく「1本だけ戻せるか」で決まります。今日は、戻せる形で取る方法だけ説明します。」

Claude:「実測を先に出します。筆者のブログで、本文の書き換え前に退避したファイルは110本。書き換え後に「タイトル・アドレス・公開状態・公開日が変わっていないか」を機械で検算するようにしてからは、タイトルや公開状態が変わる種類の失敗は起きていません。」


📌 目次(クリックでジャンプ)

  1. 1. 【問題提起】WordPressの記事だけをバックアップしたいのに、うまくいかない本当の理由
  2. 2. 【AI導入で変わった】バックアップを「取る作業」から「書き換えの手順に組み込まれたもの」に変える
  3. 3. 【具体例】1つのブログで110本退避して分かった3つのこと
  4. 4. 【じゃあどうやる?】WordPressの記事だけをバックアップして、戻せる形にする5ステップ
  5. 5. よくある質問(FAQ)
  6. 6. まとめ|WordPressの記事のバックアップは「取れたか」より「1本だけ戻せるか」で決まる

1. 【問題提起】WordPressの記事だけをバックアップしたいのに、うまくいかない本当の理由

1-1. 「エクスポート」は全部まとめて1つのファイルになる

まず、ネットで最初に出てくる方法を噛み砕きます。WordPressの管理画面には「ツール → エクスポート」があり、「投稿」を選ぶと、全記事の本文が1つのファイル(XMLという形式)になって手元に落ちてきます。これ自体は正しい機能です。

まとめて書き出す方法とサーバーの自動保存は全体を守る道具で1本だけ戻すには本文だけの退避が要ることを示す3方式の比較図

問題は、戻すときです。戻す方法は「ツール → インポート」で、そのファイルを読み込ませるのですが、これは「上書きして元に戻す」のではなく、「記事を追加する」動きをします。同じ記事がすでにある場合は取り込まれなかったり、逆に同じ記事がもう1本できたりします。つまり、「あの1本だけ、書き換える前の状態に戻したい」という使い方に向いていません。

方法 取れるもの 1本だけ戻せるか
ツール → エクスポート 全記事まとめて1ファイル △ 追加はできるが上書きはできない
サーバーの自動バックアップ サイト丸ごと(記事も画像も設定も) ✕ サイト全体がその日に戻る
本文だけを1本ずつ退避 その記事の本文だけ ○ その記事だけ戻せる

1-2. サーバーの自動バックアップは「サイト全体をその日に戻す」

サーバー会社の多く(筆者が使っている会社も)は、サイト全体を毎日自動で保存してくれています。これは本当に助かる機能で、サイトが真っ白になったときの命綱です。

ただ、これも「1本だけ」には向きません。戻すのはサイト全体なので、たとえば今日3本の記事を書き換えて、そのうち1本だけ失敗したとき、昨日の状態に戻すと成功した2本まで巻き戻ります。しかも復元には数分〜数十分かかり、その間サイトの表示が止まることもあります。「1本のミス」に対して、道具が大きすぎるのです。

1-3. 本当に困るのは「記事を書き換えた直後」だと気づいた

筆者が記事を壊した2回は、どちらも記事を機械で一括で書き換えた直後でした。

  • 1回目は、記事の途中に入れる広告ブロックを差し替えたとき。差し替えの目印にしていた [CTA_...] という文字が、変換されないまま本文に残って公開されていました。読者から見ると、意味不明な記号が記事の途中に出ている状態です
  • 2回目は、記事のタイトルを直そうとしたとき。送る中身を取り違えて、5本の記事のタイトル欄に本文が丸ごと流し込まれました。1本あたり1,700〜1,800字のタイトルです

どちらも、書き換える直前の本文が手元にあれば、送り返すだけで数分で戻せたはずでした。それが無かったので、1回目は該当する記事を1本ずつ開いて目で探し、2回目は下書きの原稿からタイトルを打ち直しました。

凛:「月イチのエクスポートは、先月の状態でしょ。書き換える直前の状態じゃない。」

社長:「そう。先月から先週までに直した分が、そのエクスポートには入ってない。」

策:「だから「いつ取るか」が答えになります。書き換える直前に、その記事だけ取る。取る対象と取るタイミングを絞ると、戻し方も1つに絞れます。」

Claude:「補足すると、壊れた本文は自分からは知らせてきません。1回目の目印文字は、公開から数週間後の点検で見つかりました。壊れた瞬間に気づける前提で考えないほうが安全です。」


2. 【AI導入で変わった】バックアップを「取る作業」から「書き換えの手順に組み込まれたもの」に変える

2-1. 発想の転換:「取る」のではなく「書き換える道具の中に入れておく」

2回目の失敗のあと、考え方を変えました。バックアップを別の作業として覚えておくのをやめて、記事を書き換える道具そのものに「送る前に元の本文を保存する」動きを入れたのです。

こうすると、バックアップを「取り忘れる」ということが起きません。書き換えようとした時点で、必ず退避ファイルができます。人間が覚えているかどうかに頼らない、というのが要点です。

2-2. 取るのは「本文だけ」に絞る

もう1つ変えたのは、取る範囲です。サイト全体でも、全記事でもなく、書き換えるその記事の本文だけにしました。理由は3つあります。

  1. 戻すのが速い:本文だけなら、送り返すだけで戻る。他に何も影響しない
  2. どこが変わったか比べられる:退避した本文と、今の本文を並べれば、何が変わったかが1本単位で分かる
  3. 画像は退避しなくていい:画像はサーバーの「メディア」に別に置かれていて、本文には「画像のある場所」が書かれているだけ。本文を戻せば画像も元通りに表示される

逆に、この方法で守れないものもはっきりしています。画像そのもの・サイトの設定・テーマはこの方法では退避されません。それらはサーバーの自動バックアップに任せる、という役割分担です。

2-3. 非エンジニアがAIに頼むときの言い方

筆者はプログラムを書けないので、この道具はAIアシスタントに作ってもらいました。頼み方は、やりたいことを箇条書きにするだけです。

・WordPressの記事を、記事番号で指定して本文だけ取り出したい
・取り出した本文を「記事番号_アドレス_日付_before」という名前のファイルに保存したい
・そのあとで新しい本文を送りたい。送るのは本文だけで、タイトル・公開日・公開状態は絶対に送らないでほしい
・送ったあとに、タイトル・アドレス・公開状態・公開日が変わっていないか確かめて表示してほしい
・失敗したら、退避したファイルの中身を送り返して元に戻せるようにしてほしい

ポイントは、「できないこと」も先に書くことです。「タイトルや公開日は送らない」と最初に決めておくと、2回目の失敗(タイトル欄に本文が入る)は仕組みとして起きなくなります。

社長:「『やらないでほしいこと』を先に言うの、考えたことなかったな。」

策:「道具はできることが少ないほど安全です。本文しか送れない道具なら、タイトルを壊す事故は構造的に起きません。」

凛:「非エンジニアほど、ここを絞りなさい。何でもできる道具は、何でも壊せる道具よ。」

Claude:「筆者の道具は実際に「本文の差し替え」しかできません。タイトル・公開状態・アドレスの変更、記事の削除は機能として存在しないので、間違えて使うこともできません。」


3. 【具体例】1つのブログで110本退避して分かった3つのこと

実際にこの方式で運用した結果を出します。退避ファイルは、記事の途中のリンクを足したときのもの、広告ブロックを差し替えたときのもの、本文を追記したときのもので、合計110本になりました。

退避110本の運用で分かった編集用の本文を取る・戻すときも本文だけ送る・名前に番号とアドレスと日付を入れるという3つの要点を示す図

3-1. 「表示用の本文」と「編集用の本文」は別物だった

最初につまずいたのはここです。WordPressから記事を取り出す方法には2つあって、読者が見ている形(表示用)と、編集画面に入っている形(編集用)があります。

最初は表示用を退避していました。ところが表示用は、WordPressが自動で整えたあとの形で、改行の扱いや一部の記号が編集用と違います。これを送り返すと、見た目は同じでも編集画面の中身が変わってしまい、次に編集したときにズレが出ました。

退避するのは編集用の本文です。AIに頼むときは「編集画面に入っている本文をそのまま取り出して」と言えば伝わります。この違いは、戻してみるまで気づけませんでした。

3-2. 戻すときに「公開日」を一緒に送ると、予約記事が即公開になることがある(筆者は1回やった)

2つ目は、戻すときの落とし穴です。筆者はバックアップとは別の作業で、予約公開にしていた記事の公開日だけを送り直したことがあります。すると、その記事はその場で公開されました。本文を戻すときに「ついでに公開日も揃えておこう」とすると、同じことが起きます。

WordPressの公開日は「日本時間」と「世界標準時」の2つで管理されています。筆者は片方だけ送って即公開になりましたが、本体の仕様では片方だけでも残りは自動で計算されるので、原因は「送った日付がサーバーから見て過去だった」可能性が高い、というのが今の見立てです。何を送って何が起きたかは「WordPressの予約投稿を一括変更する方法」に書きましたが、バックアップから戻すときも同じです。戻すときも、送るのは本文だけ。これが鉄則になりました。

3-3. 記事番号は「別のブログと同じ番号」がある

3つ目は、筆者がブログを2つ運営しているせいで踏んだ穴です。記事には番号(記事ID)が付いていて、退避ファイルの名前も最初は番号だけにしていました。ところが別のブログにも同じ番号の記事があったのです(例:片方の49番と、もう片方の49番は別の記事)。

退避ファイルの名前が番号だけだと、どちらのブログの本文か分からなくなります。そこで名前を「番号+記事のアドレス+日付+before」に変えました。アドレス(スラッグ)は同じブログの中で必ず1つなので、取り違えがなくなりました。ブログが1つの人でも、日付だけは必ず入れることをおすすめします。同じ記事を2回書き換えたとき、どちらの「前」なのかが分かるからです。

社長:「名前の付け方まで失敗するとは思わなかった。」

凛:「失敗の種類が毎回違うのは、まあ、進んでる証拠ではあるわね。」

策:「3つとも、道具を作った時点では分からず、戻してみて初めて分かったものです。だから次の章の最後に「一度戻してみる」を入れています。」

Claude:「検算の位置も出します。退避110本は、いずれも送る前に自動で作られたもので、人間が取り忘れた回はありません。検算を入れる前の2回の失敗は、どちらも検算があれば送った直後に見つかっていました。」

PR / アフィリエイトリンク


4. 【じゃあどうやる?】WordPressの記事だけをバックアップして、戻せる形にする5ステップ

ここからは手順です。プラグインは使いません。AIアシスタントに道具を作ってもらう前提ですが、Step 1・3・5は人間が決めることなので、AIに頼む前に読んでおいてください。

記事の本文を戻せる形で退避する5工程のうち人が決めるのは守る範囲と名前と一度戻してみることであると示す手順図

Step 1. 「何を守るか」を本文だけに絞る

守るものを決めます。この記事の方法で守るのは記事の本文だけです。画像・設定・テーマはサーバーの自動バックアップに任せます。ここを「全部」にすると、道具が大きくなり、戻すのも大変になります。

Step 2. AIに「本文を取り出して保存する道具」を作ってもらう

2-3の箇条書きをそのまま渡します。必ず入れる条件は次の3つです。

  1. 編集用の本文を取り出す(表示用ではない)
  2. 送るのは本文だけ。タイトル・公開日・公開状態・アドレスは送らない
  3. 送ったあとに、タイトル・アドレス・公開状態・公開日が変わっていないかを確かめて表示する

WordPressの外から記事を読み書きする仕組み(REST APIと呼びます)を使うので、「アプリケーションパスワード」という専用の合言葉が要ります。管理画面の「ユーザー → プロフィール」で発行できます。普段のログインパスワードとは別物で、この合言葉は道具の中に直接書かず、別のファイルに置くようAIに伝えてください。

Step 3. 退避ファイルの名前は「番号+アドレス+日付+before」

3-3で書いたとおりです。名前を見ただけで「どの記事の・いつの・書き換え前」と分かる形にします。置き場所は1つのフォルダに決め、消さないでください。110本でも合計数MBです。

Step 4. 書き換えたら、その場で4項目を検算する

送ったあとに、タイトル・アドレス・公開状態・公開日の4つが書き換え前と同じかを確かめます。1つでも変わっていたら、退避ファイルから戻します。筆者の2回の失敗は、どちらもこの検算があれば送った直後に見つかっていたものです。

Step 5. 一度、わざと戻してみる

最後に、何も壊れていない記事で、退避ファイルから戻す操作を1回やってみます。3-1の「表示用と編集用の違い」も、3-2の「公開日を送ると即公開」も、戻してみるまで分かりませんでした。戻したことのないバックアップは、無いのと同じです。下書きの記事で試せば、公開中の記事には何も起きません。

なお、道具を作ったあとに403というエラーで弾かれることがあります。これはサーバーの防犯機能によるもので、記事の内容ではなく送り方に反応しています。そのときの切り分けは「WordPress REST APIが403になる原因」にまとめてあります。

PR / アフィリエイトリンク


5. よくある質問(FAQ)

Q. プラグインのバックアップ機能ではダメですか? A. ダメではありません。ただ、多くのバックアッププラグインは「サイト全体」を保存する作りで、1本の記事だけを書き換え前に戻す用途には向いていません。この記事の方法は、プラグインの代わりではなく、書き換えの直前だけに使う小さな保険です。両方あって構いません。

Q. 記事を手で1本ずつ直すだけなら、ここまで要りますか? A. 手で直すなら、WordPress標準の「リビジョン」(編集画面の右側に出る、過去の版に戻せる機能)で十分なことが多いです。この記事の方法が効くのは、機械で一括で書き換えるときです。一括の書き換えはリビジョンが残らない経路で行われることがあり、そこで筆者は2回壊しました。

Q. 画像はどうやって守ればいいですか? A. 画像はサーバーの「メディア」に別に保存されていて、この方法では退避されません。画像を守るのはサーバー会社の自動バックアップの仕事です。多くのサーバー会社が標準で自動バックアップを付けていて、保存日数や復元が無料かどうかは会社ごとに違います(各社の公式情報を確認してください)。自分のパソコン側のファイルを守る話は「Google Driveに自動バックアップする方法」に書いています。

Q. 一括で書き換えたあと、壊れているかどうかはどう見つけますか? A. Step 4の4項目の検算で「枠」の壊れは見つかります。本文の中身の壊れ(目印の文字が残る等)は、別に「本文を全記事点検する」工程が要ります。その手順は「WordPressで一括置換する方法」の後半に書きました。

Q. エクスポートは取らなくていいのですか? A. 取ってください。全記事を丸ごと手元に持っておく用途には今でも最適です。この記事は「エクスポートが不要」という話ではなく、「1本だけ戻す」には別の形が要るという話です。


6. まとめ|WordPressの記事のバックアップは「取れたか」より「1本だけ戻せるか」で決まる

社長:「バックアップは取ってた。取ってたのに戻せなかった、ってのが全部だな。」

凛:「そう。取る作業と戻す作業は別物。戻したことがないなら、取ってないのと同じ。」

策:「そして、取り忘れないように「書き換える道具の中に入れる」。人間の記憶に頼らない形にしたのが、今回いちばん効いた変更です。」

Claude:「実測を再掲します。退避110本・取り忘れ0回。検算を入れてから、タイトルや公開状態が変わる種類の失敗は起きていません。」

この記事で伝えたかったことは3つです。

  1. エクスポートとサーバーの自動バックアップは「全体」を守る道具。「1本だけ戻す」には、書き換える直前に本文だけを退避する形が要る
  2. 退避は別の作業にせず、書き換える道具の中に組み込む。送るのは本文だけ・タイトルや公開日は送らない・送ったあとに4項目を検算する
  3. 一度わざと戻してみる。表示用と編集用の違いも、公開日の罠も、戻してみるまで分からなかった

バックアップの話は、失敗するまで真剣になれないものだと思います。筆者もそうでした。ただ、一括で書き換える前に1本ずつ退避するという形にしてからは、書き換えること自体が怖くなくなりました。戻せると分かっていれば、直す手が軽くなります。

次に読むべき記事

※ 本記事は Claude Code(筆者が使用中のAIアシスタント)自身が、筆者の実体験を元に執筆しています。 ※ 本記事にはアフィリエイトリンクが含まれます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!