AIで既存記事に1節足す前に、残す情報を決めて改稿後に照合する

公開済みの記事をAIに直させると、説明は増えても、元の注意事項や日付、リンク、コードが消えていることがあります。消えた情報は、改稿後の文章だけを読んでも気づけません。反対に、元の情報がすべて残っていても、足された文の中に、根拠のない一文や読者に不要な一文が混ざることがあります。

WordPressのバックアップ記事に「復元候補を選ぶ」節を1つ足す依頼を、禁止事項（具体的な画面操作、固定の保存間隔、成功の保証などを加えない）を書いて、AIに2回出しました。2回とも、元の注意文・表・画像参照・リンク・コードはすべて残り、保持の検査に合格しました。ところが追加された文には、2回とも、禁止事項をそのまま読者向けの断り書きにした文がありました（「…推奨値ではありません」「…目安となる時間差を定めません」など）。どの禁止事項が断り書きになったかは回ごとに違い、2回目は、依頼に添えた出典のメモまで記事の本文として出力されました。

この記事では、改稿の前に読者の問いと「変えずに残す情報」を決める改善ブリーフ、改稿後に照合する保持対象表とPythonの検査、追加された文を読み分ける手順を、この2回の実例で示します。読み終えたら、AIの改稿案を採用するか、直してから採るか、保留するかを決められます。

使う場面と、手元に残るもの

この手順は、すでに公開している記事の一部だけをAIに書き足させたいときに使います。手元に残るのは次の3つです。

手順1：読者の問いを1文で決める

最初に、この記事に来た読者が片づけたいことを1文にします。検索語と今の本文から考えます。今回の例は「WordPressのバックアップ設定と保存先」という記事で、Search Consoleでは「WordPress バックアップ 復元」でも表示され、その語の掲載順位が下がっていました（直す記事を選ぶ手順の記事の練習データ）。保存の仕方の記事に、戻し方を探す人も来ていると読めます。

そこで問いを「保存済みのバックアップから、どれを復元候補にすればよいか」と決めました。問いが今の記事の役割（保存対象と保存先の確認）の続きなら、既存の記事に足します。プラグインの比較のように目的が違う問いなら、別の記事にします。特定のサービスの画面操作のように根拠をまだ確かめていない問いは、保留にします。

手順2：改善ブリーフに、残す情報と扱わないことを書く

問いが決まったら、改善ブリーフを書きます。今回のブリーフは次のとおりです。

足す情報の根拠には、WordPress公式の説明を使いました。通常の復元にはデータベースとファイルの両方が必要で、同じ頃の保存分を一組として扱うこと、データベースを復元すると現在の内容が上書きされることです（バックアップの公式説明、データベースのバックアップ・復元、確認日：2026年10月11日）。

手順3：依頼文に、ブリーフと元の本文を添えて送る

ブリーフをもとに、次の依頼文を作りました。この後に、改稿前の本文（before.md）の全文と、確認済みの出典2件の要約を続けて送ります。

読者は、保存済みのWordPressバックアップから復元候補を選びたい人です。
既存記事の目的は、保存対象と保存先の確認です。

元の本文を書き換えず、「復元候補を選ぶ」節だけを後ろに追加してください。
元の注意文、表の日時と対象、画像のaltと参照、リンク先、コード全文を残します。

根拠は添付したWordPress公式資料です。
対象サイト・保存日時・ファイルとDBの組合せを確認する説明を加えます。
不明なら保留し、記録や利用サービスの公式資料を確認するよう書いてください。

具体的な画面操作、固定の保存間隔、成功保証、未測定のSEO効果は加えません。
記録例の日時を推奨値として扱わないでください。
出力は元の本文全体と追加節です。

この依頼文を、Claudeの新しいチャットに1回送りました（2026年10月20日）。その前に、この記事を作る作業の中で、同じ禁止事項を箇条書きにした指示書でAIに1回書き足させています（2026年10月11日）。以下の「1回目」「2回目」はこの2回です。

改稿前の本文は次のとおりです。照合を再現するときは、UTF-8の before.md として保存します。

# WordPressのバックアップ設定と保存先

WordPressのバックアップでは、データベースとファイルを両方保存します。保存先はサーバー内だけにせず、手元や別の保管先にもコピーを置きます。

## 保存する対象

記事や設定の多くはデータベースに、アップロード画像やテーマ等はファイルに入ります。片方だけでは同じ状態に戻せない場合があります。

| 記録例の保存日時 | 対象 | 確認するもの |
| --- | --- | --- |
| 2026-10-10 09:00 JST | データベース | SQLファイル |
| 2026-10-10 09:00 JST | ファイル | 画像・テーマ等 |

![データベースとファイルを一組として確認する図](backup-set.webp)

保存対象は[WordPress公式のバックアップ説明](https://developer.wordpress.org/advanced-administration/security/backup/)も確認してください。

~~~python
backup_set = ["database.sql", "files.zip"]
print(len(backup_set))  # 記録例の対象は2種類
~~~

## 実行前の確認

保存日時、対象サイト、ファイルの有無を記録します。復元すると現在の内容が上書きされる可能性があるため、作業直前の状態も別に保存してください。公開サイトでいきなり試さず、検証環境で確認します。

## 復元について

復元の手順は利用するホスティングやプラグインで異なります。この記事にはサービス別の操作手順はまだありません。

手順4：保持対象表とPythonで、元の情報が残ったかを照合する

改稿案を受け取ったら、まず元の情報が残っているかを照合します。保持対象ごとに、照合のしかたと、照合だけでは分からないことを表にしておきます。

文字列の照合は、次の check.py で行えます。Python 3の標準ライブラリだけで動き、before.md と改稿後の after.md を同じフォルダに置いて python3 check.py before.md after.md で実行します。

"""Python 3標準ライブラリ。保護した箇所の完全一致を確認する小例。"""
from pathlib import Path
import re
import sys


def protected(text):
    warnings = (
        "保存日時、対象サイト、ファイルの有無を記録します。",
        "復元すると現在の内容が上書きされる可能性があるため、作業直前の状態も別に保存してください。",
        "公開サイトでいきなり試さず、検証環境で確認します。",
    )
    if not all(s in text for s in warnings):
        raise ValueError("比較元の注意文が不足しています")
    return {
        "注意文": list(warnings),
        "表": re.findall(r"^\|.*\|$", text, re.M),
        "画像参照": re.findall(r"^!\[.*\]\(.*\)$", text, re.M),
        "リンク先": re.findall(r"(?<!!)\[[^\]]+\]\(([^)]+)\)", text),
        "コード": re.findall(r"~~~[^\n]*\n.*?\n~~~", text, re.S),
    }


def check(before, after):
    failed = []
    actual = {
        "注意文": after,
        "表": after.splitlines(),
        "画像参照": after.splitlines(),
        "リンク先": re.findall(r"(?<!!)\[[^\]]+\]\(([^)]+)\)", after),
        "コード": re.findall(r"~~~[^\n]*\n.*?\n~~~", after, re.S),
    }
    for kind, pieces in protected(before).items():
        if not pieces:
            raise ValueError(f"比較元に{kind}がありません")
        if any(piece not in actual[kind] for piece in pieces):
            failed.append(kind)
    return failed


if __name__ == "__main__":
    if len(sys.argv) != 3:
        raise SystemExit("使い方: python3 check.py before.md after.md")
    before = Path(sys.argv[1]).read_text(encoding="utf-8")
    after = Path(sys.argv[2]).read_text(encoding="utf-8")
    try:
        failed = check(before, after)
    except ValueError as error:
        raise SystemExit(str(error))
    print("FAIL: " + "、".join(failed) if failed else "PASS: 保持対象の文字列が一致")
    raise SystemExit(1 if failed else 0)

2回の改稿案は、どちらも次の結果でした（終了コード0）。

PASS: 保持対象の文字列が一致

表の日時を1つ変えると FAIL: 表、注意文の「上書きされる可能性」を否定に変えると FAIL: 注意文 になります。一方で、注意文を残したまま「検証環境なら現在の内容は上書きされません。」のような根拠のない一文を足しても、この検査は合格します。この検査が確かめるのは「残すと決めた情報が残っているか」だけで、足された文が正しいかは、次の手順で読みます。

コードを使わない場合は、WordPressのリビジョン画面で改稿前後を見比べられます。投稿の設定サイドバーで「リビジョン」の横の数字を押すと一覧が開き、WordPress 7.0以降では、追加したブロックが緑、削除したブロックが赤、変更したブロックが黄色で示されます（WordPress公式：リビジョン、確認日：2026年10月12日）。公開済みの記事は「更新」を押した時点で反映されるので、改稿は検証環境で保存してから見比べます。

手順5：足された文を、採る・削る・出典に戻すに分ける

保持の照合に合格したら、足された文を1文ずつ読みます。Googleも、生成AIで作った内容に正確さ・品質・関連性を求めています（Googleの生成AIコンテンツの指針、確認日：2026年10月11日）。2回の改稿案で、読み分けが必要だった文は次のとおりです（AIの出力の原文の一部）。

禁止事項が断り書きの文になった箇所は、1回目に3文、2回目に3文（2か所）ありました。2回に共通していたのは「記録例の日時を推奨値として扱わない」だけで、ほかは回ごとに違う禁止事項が文になっています。依頼に「〜は加えない」と書くと、AIはそれを守ったうえで、守ったことを読者に向けて書くことがある、と考えておくと読み落としにくくなります。

分け方の基準は次の3つです。

• 採る：読者が手順や判断に使え、添えた出典で説明できる文。

• 削る：依頼の禁止事項を読者に向けて言い直しただけの文、依頼の外から入った文。

• 出典に戻す：出典に書かれていない具体例や確かめ方。根拠を確かめてから残す。

1回目の追加節から、削る3文を除くと次のようになります。1回目の出力を読み分けの結果に合わせて直した例です。

## 復元候補を選ぶ

まず、不具合が起きる前の保存分を候補にします。その保存分が対象サイトのもので、ファイルとデータベースが同じ頃の一組になっているかを確認してください。

対象サイトや保存日時が分からない場合、または片方が欠けている場合は、復元を始めず、保存記録や利用サービスの公式資料を確認します。

復元すると、保存後に追加・変更した内容が戻らなくなる可能性があります。作業直前の状態を別に保存し、検証環境で必要な記事や画像を確認したうえで、利用するホスティングやプラグインの公式手順に進んでください。

採用するか、保留するかを決める

照合と読み分けの結果から、次のように決めます。

• 採用する：保持の照合に合格し、足された文がすべて「採る」だった。

• 直してから採用する：保持の照合に合格し、「削る」文を除けば残りがすべて「採る」になる。今回の1回目はこれに当たり、上の直した例が採用案です。

• 保留する：保持の照合に不合格だった、または「出典に戻す」文の根拠がまだ確かめられない。今回の2回目は、出典にない確かめ方が複数あるので、この基準では保留になります。

採用したら、変更した日と範囲を記録しておきます。検索での評価は、同じ条件の期間のデータで別に見ます。

保持対象表は、AIに頼むときだけでなく、人が書き直すときにも使えます。この記事自体を書き直したときも、次の表で前後を照らしました。意図して外したものには理由の欄を付けておくと、後で「なぜ消えたか」を追えます。