「記事の中の古いサービス名を、まとめて新しい名前に変えたい」 「プラグインで一括置換したけど、これで本当に全部直ったのか不安」 「本文を触って、記事が壊れたらと思うと手が出せない」
WordPressの一括置換でつまずくのは、置換のやり方ではありません。「置換したあとに何が残るか」を誰も教えてくれないからです。
先に結論を書きます。一括置換は「文字を替える作業」ではなく「文脈を直す作業」でした。筆者は公開済み記事のバナーを12本まとめて外し、上位5記事を別サービスに差し替えましたが、文字を替えただけで終わらせた記事は、あとから必ず食い違いが出ました。
筆者は北海道で建設業をやっている40代の現場マン（非エンジニア）です。プログラムは書けません。それでもブログ100本近くの管理は、AIアシスタント（Claude Code）に任せる形で回しています。この記事では、一括置換のやり方に加えて、置換のあとに残る3種類の落とし穴と、その潰し方を書きます。専門用語は出るたびに噛み砕きます。
※ 本記事は Claude Code（筆者が使用中のAIアシスタント）が筆者の実体験を元に執筆しています。
この記事はこんな方向け
- 記事数が増えて、古い記述をまとめて直したい人
- プラグインで一括置換したものの、本当に全部直ったのか確信が持てない人
- 「置換したら記事が壊れた」という話を聞いて、怖くて手が出せない人
- プログラミングは分からないけれど、AIに点検を任せてみたい人
🎬 この記事に登場するキャラ
- 社長 — 筆者本人（北海道・建設業41歳・副業で複数の事業を運営）
- 策 — Claude Code（参謀AI・冷静な軍師）
- 凛 — Claude.ai（秘書AI・ちょいドS姉御）
- Claude — 純AIキャラ（実測値・仕様を淡々と提示するロボット）
社長：「サービス名が変わったから、記事の中の古い名前を全部置換したのよ。プラグイン入れて、3分で終わった。」
凛：「で？終わったつもりで、まだ古い名前が残ってたんでしょ。」
社長：「なんで分かるの。」
策：「よくある話です。一括置換の検索は書き方が1文字でも違うと引っかかりません。人間が『同じ言葉』だと思っているものを、機械は別物として扱います。」
凛：「つまり『0件でした』は安心の合図じゃないの。書き方を変えて探し直すまで、何も分かってないのよ。」
📌 目次（クリックでジャンプ）
1. 【問題提起】WordPressの一括置換で事故が起きる本当の理由
1-1. 一括置換そのものは、3分で終わる
まず、作業自体は難しくありません。Search Regex や Better Search Replace といったプラグイン（WordPressに機能を足す拡張部品のこと）を入れれば、探したい文字と置き換えたい文字を打ち込むだけです。何十記事でも一瞬で終わります。
難しいのは、そのあとです。
置換は「文字を機械的に入れ替える」だけの動作です。その文字が本文の中でどういう役割を持っていたかは、一切考えてくれません。ここが事故の入口でした。
1-2. 「置換できた」と「直った」は、まったく別のこと
筆者が実際に経験した順序で書きます。
提携していたアフィリエイトサービスが終了したので、公開済み12本の記事からバナーを一括で外しました。置換は成功しました。バナーは消えました。
ところが記事を読み返すと、「このサービスがおすすめです」という本文だけが残っていました。紹介文があるのに、紹介先がない。読者から見れば、ただの意味不明な段落です。
置換ツールは仕事をしています。バナーのコードは確実に消えました。でも記事としては壊れていました。
1-3. 非エンジニアが一番損をするポイント
この手の食い違いは、エラーが出ません。画面は真っ白にならないし、警告も出ない。だから気づけません。
筆者の場合、社内で使っている略称が公開記事に2ヶ月以上残っていたこともあります。チェックの仕組みは動いていたのに、書き方の違いですり抜けていました（詳しくは3章で書きます）。
エラーで止まってくれるトラブルは、まだ親切です。困るのは静かに間違ったまま公開され続けるタイプで、これは自分では見つけられません。エラーが出るタイプの詰まり方についてはClaude Codeでエラーが出た時の対処法にまとめました。
2. 【AI導入で変わった】置換の前後にAIを挟むと、何が変わるか
2-1. 置換の「前」— 本当に全部ヒットしているかを疑わせる
一括置換の前に、AIアシスタントにこう頼むようになりました。
このブログの全記事から「◯◯」という言葉を探して。
ただし、次の書き方の違いも全部拾って一覧にして。
- 大文字と小文字の違い
- 前後に記号や数字がくっついている場合 # ここを書き換える
- URLの中に入っている場合
これだけで、プラグインの検索では0件だったものが、数件出てきます。「見つからなかった」ではなく「その書き方では見つからなかった」だけだった、というのが分かります。
2-2. 置換の「後」— 文脈が食い違っていないかを読ませる
置換が終わったあとが本番です。
今、記事から「◯◯」の紹介バナーを外しました。
本文の中に、外したものを前提にした文章が残っていないか読んで教えて。
見出し・目次・まとめも含めて確認して。
人間の目視だと、自分で書いた文章は「読んだつもり」になって素通りします。AIは書いた本人ではないので、素通りしません。ここが一番効きました。
2-3. 体感で変わったこと
| 工程 | 以前 | AIを挟んだあと |
|---|---|---|
| 置換前の洗い出し | 記憶と勘 | 書き方の揺れごとに一覧化 |
| 置換後の点検 | 数本だけ目視 | 全記事を読ませて報告させる |
作業時間そのものは、正直あまり変わっていません。変わったのは「終わったと言い切れるかどうか」です。
社長：「置換の前と後にAIを挟むだけ？それだけでそんな変わるの。」
Claude：「置換ツールは指定された文字だけを見ます。前後の文章は評価対象外です。評価する担当がいないなら、追加するしかありません。」
策：「そうです。置換ツールと点検役は別の仕事なんです。同じ道具に両方やらせようとするから漏れます。」
凛：「あんた、置換ボタン押した瞬間に『終わった』って言うクセあるでしょ。あれが一番危ないの。」
3. 【具体例】実際に起きた3つの食い違い
ここからは、筆者が実際にやらかした3つを書きます。全部、置換自体は成功していたものです。
3-1. ケース1：バナーだけ替えて、本文の推奨文が古いまま
一番多いパターンです。
流入の多い上位5記事で、紹介するサービスを別のものに差し替えました。バナーは新しくなりました。でも本文の「筆者はこれを使っています」という説明と、見出しと、目次が古いままでした。
読者からは「バナーと本文が違うことを言っている記事」に見えます。信用を落とす直接の原因です。
教訓：バナーを差し替える時は、必ず直前の誘導文・見出し・目次の3点をセットで確認する。リンクやボタンをどこに置くかという設計の話はアフィリエイトリンクを貼る場所の正解に整理してあります。
3-2. ケース2：検索に引っかからない書き方が生き残る
これが一番ゾッとした事故です。
ブログに書いてはいけない社内用の略称（英字3文字）が、公開済み4記事に2ヶ月以上残っていました。しかもチェックの仕組みは毎回動いていたのです。
原因は、機械の「単語の区切り」の判定でした。
略称の直後に_052のようにアンダースコアや数字が続くと、別の単語として扱われて引っかからない- URLの中で小文字になっていると、大文字で探していたので別物扱い
つまり「チェック0件でした」という報告は、「その探し方では0件」という意味しかなかったわけです。
教訓：検索が0件だったら、書き方を変えてもう一度探す。特にURL（スラッグ）の中は、本文と別枠で探し直します。転送設定が効いていても、URLの文字列そのものは読者の画面に表示されるので、本文中の古いリンクは書き換えが必要でした。
3-3. ケース3：置換したら403が出て止まる
3つ目は技術的な壁です。
記事をまとめて書き換えようとすると、「403（アクセスが拒否されました）」で止まることがあります。これはブログが壊れたのではなく、サーバー側の防御機能（WAF＝不審な通信を遮断する仕組み）が「怪しい書き換えだ」と判断して止めているだけです。
筆者の場合、原因は2つでした。
- 書き換えの命令の送り方が防御機能に弾かれていた
- 本文に日本語のコメントを足した時だけ弾かれていた（同じ内容を変更なしで送ると通る）
切り分けの手順はシンプルです。まず何も変えずに送ってみる（通ればルート自体は生きている）→ 短い文字列だけ送ってみる → 本命を最小の差分で送る。この順で、どこが引っかかっているか特定できます。
同じ403でも原因はいくつかあるので、WordPress REST APIが403になる原因とWordPressのWAF 403エラーの直し方に分けて書いてあります。
社長：「403って出た時、俺サイトが死んだかと思って血の気引いたわ。」
凛：「死んでないわよ。門番が『通していいか判断できない』って言ってるだけ。」
策：「はい。403は拒否であって故障ではありません。何を送ったら止まったのかを1つずつ切り分ければ、必ず原因にたどり着きます。」
社長：「変更なしで送ってみる、って発想がなかったな。」
Claude：「基準を作る手順です。通る状態を1つ確保してから差分を足す。原因の切り分けはこれが最短です。」
PR / アフィリエイトリンク
4. 【じゃあどうやる？】WordPressで一括置換を壊さずやる5ステップ
ここからが実務です。筆者が今使っている手順を、そのまま書きます。
Step 1：変更前の本文を、丸ごと退避する
これだけは絶対に飛ばさないでください。
置換する前に、対象記事の本文をファイルとして保存しておきます。AIアシスタントに「これから触る記事の本文を、記事番号ごとにファイルに保存して」と頼めば作れます。
戻せる状態を作ってから触る。これがあるだけで、置換の怖さは半分になります。
なお、サーバー側の自動バックアップ機能も併用しています。契約しているサーバーに自動バックアップが付いているかは、一度確認しておく価値があります。
Step 2：置換する言葉の「揺れ」を先に洗い出す
3-2で書いた事故の対策です。置換の前に、同じ意味なのに書き方が違うものを一覧にします。
見るべきは3か所です。
| 場所 | 見落としやすい形 |
|---|---|
| 本文 | 大文字小文字違い・記号や数字が続く形 |
| URL（スラッグ） | 小文字だけの表記・ハイフン区切り |
| 画像のALT・ファイル名 | 英語表記のまま残る |
ここで出た一覧が、そのまま置換の対象リストになります。
Step 3：まず1本だけ置換して、公開ページを目で見る
いきなり全記事に流さないでください。1本だけ置換して、管理画面ではなく実際の公開ページを開いて確認します。
見るのは3点だけです。「置換した箇所が正しく変わっているか」「その前後の文章が意味として通っているか」「レイアウトが崩れていないか」。
管理画面上は正しく見えても、公開ページで崩れていることがあります。「反映されているつもり」で見落とす話はRank Mathでタイトルが反映されない原因にも書きました。
Step 4：残りを流す。ただし間隔を空ける
1本目が問題なければ、残りを流します。ここで1つコツがあります。
一気に連続で送らず、1本ごとに数秒あける。筆者は記事の更新も画像のアップロードも、必ず間隔を空けています。連続で叩くと3-3の403が出やすくなるためです。
自動で流す仕組みそのものの作り方はClaude CodeでWordPressに記事を自動投稿する方法にまとめてあります。
Step 5：置換後に「文脈チェック」をもう1周する
最後がこの記事の本題です。
置換が全部終わったら、もう一度AIに全記事を読ませて、外したもの・変えたものを前提にした文章が残っていないかを報告させます。
「◯◯」を「△△」に置換しました。
置換後の本文を読んで、次を報告して。
1. 古い前提のまま残っている説明文
2. 見出し・目次と本文の食い違い
3. リンク先が変わったのに、リンクの文字が古いままの箇所
ここまでやって初めて「直った」と言えます。Step 5をやらないなら、Step 1〜4は全部やった意味が半分になります。
内部リンクを足す側の作業も同じ考え方で回しています（Claude Codeで内部リンクを一括設置する方法）。
PR / アフィリエイトリンク
社長：「Step 5、正直めんどくさいと思ったけど…やらないと意味半減か。」
策：「はい。置換は手段で、目的は記事が正しく読めることです。目的の確認を飛ばすと、手段だけ実行した状態で終わります。」
凛：「『バナー消えたからヨシ』って言ってた誰かさんのことね。」
社長：「…はい、俺です。」
Claude：「補足します。Step 1の退避があれば、Step 5で問題が出ても戻せます。この2つはセットで意味を持ちます。」
5. よくある質問（FAQ）
Q1. プラグインを使うのと、AIに頼むのはどちらがいいですか？
両方使います。置換そのものはプラグインが速くて確実です。AIに任せるのは「置換前の洗い出し」と「置換後の文脈チェック」です。役割が違うので、どちらか一方という話ではありません。
Q2. 置換で記事が壊れたら、元に戻せますか？
WordPressには「リビジョン」という過去の状態を残す機能があるので、1本ずつなら戻せます。ただし大量に置換したあとに1本ずつ戻すのは現実的ではないので、Step 1の退避を別に取っておくほうが早いです。
Q3. データベースを直接書き換える方法は使わないのですか？
筆者は使いません。速いのは事実ですが、失敗した時に戻す難易度が跳ね上がります。非エンジニアが最初に触る場所ではないと考えています。
Q4. 公開済みの記事を書き換えると、検索順位に影響しますか？
言い回しを大きく変えると動くことがあります。筆者は「公開済み記事に触るのは、直さないと間違いになる箇所だけ」と決めています。誤りの修正や古い情報の更新は、むしろやるべき作業です。
Q5. 何記事くらいから一括置換を考えるべきですか？
10本を超えたあたりが目安だと思います。それ以下なら手で開いたほうが速いです。ただし「揺れの洗い出し」と「置換後の点検」は、記事数に関係なくやる価値があります。
Q6. AIに全記事を読ませると、時間はどれくらいかかりますか？
筆者の環境では、100本近い記事の点検を頼んでも、待つのは数分です。自分で全部読み返すより圧倒的に速いので、ここをケチる理由はありませんでした。
6. まとめ｜一括置換は「文字」ではなく「文脈」を直す作業
長くなったので、要点を3つに絞ります。
- 置換できた ≠ 直った。バナーやリンクを外しただけでは、それを前提にした本文が孤児として残ります。見出し・目次・誘導文の3点セットで確認してください。
- 「0件でした」を信じない。大文字小文字・記号の続き・URLの中は、機械にとって別の文字です。書き方を変えて探し直すまで、確認は終わっていません。
- 退避と点検はセット。変更前の本文を保存してから触り、置換後にもう1周読ませる。この2つがあれば、置換は怖い作業ではなくなります。
「AIに丸投げ」ではありません。置換はツールに、点検はAIに、判断は人に。この3分割にしてから、筆者は公開済み記事を触るのが怖くなくなりました。
次に読むべき記事
- Claude Codeで内部リンクを一括設置する方法｜非エンジニアが49記事分を壊さずに貼った手順
- WordPress REST APIが403になる原因｜画像だけ弾かれた話と直し方
- Claude CodeでWordPressに記事を自動投稿する方法と、1年運用してわかった落とし穴5つ
- Claude Codeでエラーが出た時の対処法｜非エンジニアが詰まった実例と切り分け手順
- アフィリエイトリンクを貼る場所の正解｜クリック率9.7%でも成果ゼロだった配置
- Claude Code副業の始め方と実践事例｜AIを”ひとり社員”にした13ヶ月の全記録
PR / アフィリエイトリンク
※ 本記事は Claude Code（筆者が使用中のAIアシスタント）自身が、筆者の実体験を元に執筆しています。 ※ 本記事にはアフィリエイトリンクが含まれます。
