Claude Codeで過去記事を一括リライト|古い情報の検出と更新手順
この記事の要点
- 古い情報の検出と修正案づくりはClaude Code、公開判断は人が握る
- フォルダ単位で扱え、数十本の過去記事の棚卸しに向く
- 料金・ツール名・年号・統計など陳腐化観点をAIに渡し指摘一覧から出す
ブログ記事は書いて公開した瞬間から少しずつ古くなっていきます。料金は変わり、ツール名は変わり、去年の「最新」は今年の「古い情報」になります。とはいえ、何十本もの過去記事を1本ずつ手直しする時間は、正直どこの会社にもありません。
この記事では、ターミナルから使えるAIツール「Claude Code(クロードコード)」を使って、過去のブログ記事をまとめて点検し、古くなった箇所を洗い出して一括でリライトする手順を解説します。準備するもの、AIに何を渡すか、出てきた修正をどう確認して公開するか、という再現できる道筋まで、現場の目線でお伝えします。
Contents / 目次
結論。Claude Codeは「古い箇所の検出」と「下書き修正」を任せ、公開判断は人がやる

先に結論をお伝えします。過去記事のリライトでClaude Codeに任せるべきなのは、「古い情報の検出」と「修正案の一括作成」の2つです。最終的に公開してよいかどうかの判断は、必ず人が握ってください。この線引きを守るだけで、リライト作業は驚くほど軽くなります。
Claude Codeとは、Anthropic(アンソロピック)社が提供する、コードやファイルを読み書きできるAIツールのことです。もともとはプログラマー向けの開発ツールですが、ブログ記事のテキストファイルやHTMLを「読んで・直す」用途にもそのまま使えます。ターミナルから使うのが基本で、対応する環境は時期によって変わるため、最新の対応環境はClaude Code公式ドキュメントでご確認ください。
普通のチャットAIと何が違うのか。一番の違いは「複数のファイルをまとめて扱える」ことです。チャット欄に記事を1本ずつ貼り付ける必要がなく、記事ファイルが入ったフォルダを丸ごと対象にして「この中で古くなっている記述を全部探して」と頼めます。だから「数本の手直し」ではなく「数十本の棚卸し」に向いています。
まず、3つのやり方の向き不向きを整理しておきましょう。自社の状況がどれに当てはまるかを考えながら読んでみてください。
| やり方 | 得意なこと | 苦手・注意点 | 向いている場面 |
|---|---|---|---|
| 手作業でリライト | 細かいニュアンス調整。1本への思い入れ | 本数が増えると破綻する。抜け漏れが出る | 看板記事を1〜2本だけ磨くとき |
| チャット型AIに貼り付け | 1本ずつの相談・壁打ち | 毎回コピペが必要。何十本も回せない | 5本以内の単発リライト |
| Claude Codeで一括処理 | フォルダ単位の検出・修正案づくり | 最初の準備(ファイル化)が必要 | 過去記事をまとめて棚卸しするとき |
1本ずつ丁寧に相談したいならClaude Codeで過去記事をSEOリライト。対話しながら最適化する方法も参考になります。この記事では「まとめて棚卸し」の方に絞って解説していきます。
具体的なやり方。準備から一括リライトまでの手順

ここからが本題です。実際の進め方を、準備・検出・修正・確認の順に追っていきます。画面のボタン名はバージョンで変わるので、ここでは「何を・どの順番でやるか」というプロセスで説明します。
手順1。記事をテキストファイルとして1か所に集める
最初にやるのは、リライトしたい過去記事を「ファイル」として手元に集めることです。Claude Codeはファイルを読んで直すツールなので、まず直す対象がファイルになっている必要があります。
WordPressで運用しているなら、記事の本文(HTML)をエクスポートするか、コピーして1記事1ファイルで保存します。たとえば「article-001.html」「article-002.html」のように、1つのフォルダにまとめて入れておきます。ファイル名は連番でも記事スラッグでも構いません。大事なのは「このフォルダの中身が今回の作業対象だ」とはっきりさせることです。
いきなり全記事を対象にしないでください。最初は5本ほどの少数で試し、出力の品質と作業の流れを確認してから本数を増やすのが安全です。100本を一気に投げると、確認しきれずに事故ります。
手順2。「何を古い情報とみなすか」をAIに渡す
次に、Claude Codeに判断基準を渡します。ここが品質を分ける一番のポイントです。「古い情報を直して」とだけ頼むと、AIは何が古いのか分からず、的外れな修正をしたり、勝手に新しい数字をでっち上げたりします。だから「どういう記述を疑ってほしいか」を具体的に伝えます。
古くなりやすい記述には、はっきりとした型があります。点検してほしい観点をリスト化して渡しましょう。
- 料金・価格:「月額◯◯円」「無料プランあり」などの金額表記
- ツール名・サービス名:名称変更や提供終了が起きやすい固有名詞
- 数値・統計:「◯%」「◯年の調査では」など年や割合を含む記述
- 年号・時制:「今年」「最新の」「現時点では」といった時間に依存する言葉
- 機能の有無:「この機能は使えません」など、後から変わりうる仕様の断定
- リンク先:本文中のURLが今も生きているか
ここで重要な考え方があります。AIに「正しい最新情報に書き換えて」と任せきってはいけません。なぜなら、AIは事実を調べずに「もっともらしい数字」を作ってしまうことがあるからです。だから役割を分けます。AIには「ここが古い可能性がある」と指摘させ、正しい値の確定は人がやるのが基本形です。
手順3。出発点となる「たたき台プロンプト」を渡す
いまのAIは、ざっくり頼めば自分で指示を整えてくれます。だから作り込んだ長文プロンプトは要りません。出発点として、短いたたき台を渡し、あとは対話で詰めていくのが現実的です。次のような指示から始めてみてください。
このフォルダ内の記事ファイルを順番に読んで、次の観点で
「古い可能性がある箇所」を一覧にしてください。
・料金や価格の表記
・ツール名やサービス名
・年号や「最新」「今年」などの時制表現
・数値や統計(◯%、◯年の調査 など)
・本文中のURL
各指摘は[ファイル名/該当箇所の引用/なぜ古い疑いがあるか]
の形でまとめてください。
この段階では本文はまだ書き換えず、一覧だけ出してください。
正しい新しい値を勝手に作らず、「要確認」と記してください。
ポイントは最後の2行です。いきなり書き換えさせず、まず「指摘の一覧」を出させます。こうすると、人が一覧を見ながら「これは直す」「これは残す」を判断でき、AIの暴走を防げます。一覧を見て方針が固まったら、「1〜5番の箇所を、元のHTML構造を崩さずに直して」と次の指示を出します。
手順4。ルールをファイルにして毎回の指示を省く
同じ作業を繰り返すなら、ブランドのトーンや守ってほしいルールを1つのファイルにまとめておくと便利です。作業フォルダに方針メモのファイルを置いておき、指示のたびに「この方針メモも踏まえて直して」と一言添えれば、毎回ルールを説明し直す手間が省けます。たとえば次のような内容を書いておきます。
# リライトの方針メモ
## 文体
・です、ます調。専門用語には一言の補足を添える
・誇張した表現(絶対、必ず、最強)は使わない
## 守ること
・元のHTMLのタグ構造と見出しは原則そのまま残す
・事実や数値を新しく追加するときは「要確認」と印を付ける
・自分で調べていない統計や金額は断定しない
## 古い疑いを最優先で見る項目
・料金、ツール名、年号、統計、本文中のURL
このファイルを置いておけば、毎回「文体は〜で」と説明する手間がなくなり、複数記事でトーンがそろいます。ブランドの声をAIに覚えさせる「コンテナ」を1つ持っておくイメージです。
手順5。修正前後を見比べて、人が公開を判断する
修正案ができたら、必ず修正前と修正後を見比べます。AIに「どこをどう変えたかを、変更箇所の一覧で示して」と頼めば、変わった部分だけを集中して確認できます。ここで人がやることは3つです。事実の裏取り、トーンの確認、そして「直しすぎていないか」のチェックです。問題なければWordPressに反映し、下書きで保存してからプレビューで最終確認して公開します。
手順6。定期実行で「検出と下書き」を自動で回す仕組みにする
タイトルにある「自動更新」は、ここまでの手順のうち「古い箇所の検出」と「修正の下書き作成」を、人が手で起動しなくても定期的に走るようにすることで実現します(数値の確定と公開まで全自動にするわけではありません)。鍵になるのが、Claude Codeを画面操作なしで動かすヘッドレス実行(ターミナルから claude --print "指示" のように、対話画面を開かずコマンドで呼ぶ使い方)です。コマンドの正確なオプションや対応状況はバージョンによって変わるため、実行前に必ず公式ドキュメントで最新の仕様を確認してください。そのうえで、この呼び出しをMac標準の launchd か、レンタルサーバーなどの cron に登録すれば、決めた日時に点検を走らせる形にできます。再現できる形にすると、次のようになります。
まず、フォルダ・方針メモ・たたき台プロンプトをまとめた1本のシェルスクリプトを用意します(例:rewrite.sh)。
#!/bin/sh
# 記事フォルダに移動して、方針メモ+たたき台プロンプトでClaude Codeを起動
cd /path/to/articles || exit 1
claude --print "$(cat 方針メモ.md)
上の方針で、このフォルダ内の記事ファイルを点検し、
古い可能性がある箇所の一覧と、修正の下書きを report-$(date +%Y%m%d).md に
書き出してください。新しい数値や金額は勝手に確定せず「要確認」と記してください。" \
>> rewrite.log 2>&1
ヘッドレス実行で report-日付.md のようなファイルを書き出せるかどうかは、Claude Code側の設定によって変わります。設定や挙動はバージョンによって変わるため、詳しくは公式ドキュメントで確認してください。定期実行に登録する前に、まず手動で一度実行し、ファイルがきちんと作られることを確認してください。
次に、このスクリプトを定期実行に登録します。レンタルサーバーやLinuxなら crontab -e に1行足すだけです。
# 毎月1日の朝9時に自動で点検を走らせる(分 時 日 月 曜日 コマンド)
0 9 1 * * /path/to/articles/rewrite.sh
Macで常用するなら、cronの代わりに launchd(~/Library/LaunchAgents/ に plist を置いて launchctl load で登録)でも同じことができます。これで、人が毎回コマンドを打たなくても、決めた頻度で「指摘一覧」と「修正の下書き」が自動生成されます。運用で固定しておく点は次の通りです。
- 頻度を決める:cron/launchdの日時設定を、四半期に1回や料金改定が多い時期の翌月など、自社のペースで固定する
- 対象フォルダは固定する:新しく公開した記事をそのフォルダに追加していけば、スクリプトを変えずに毎回フォルダ単位で点検できる
- 同じ指示を使い回す:方針メモとたたき台プロンプトはスクリプトに埋め込んでおき、毎回同じ基準で走らせる
- 出力は下書きまで:自動で作るのは「指摘一覧」と「修正の下書き(report-日付.md)」まで。WordPressへの反映と公開は人がやる
自動化をどこまで進めてよいかの判断基準も、はっきり決めておきましょう。現実的な線引きは、金額・統計・固有名詞を含む修正は必ず人が一次情報で裏取りする/誤字・表記ゆれ・切れたリンクの差し替えなど事実判断が不要な修正は自動の比率を上げてよい、というものです。上のように検出と下書き作成までを定期実行で自動化し、公開だけは人が握る。この形を保ったまま実行頻度を上げていくのが、安全に更新し続けるコツです。いきなり公開まで全自動にすると、誤った修正がそのまま世に出てしまいます。
効果・成果イメージ。何本も抱える会社ほど効いてくる

この進め方の効果は「1本あたりの時短」よりも「抱えている本数に効く」点にあります。手作業のリライトは記事が増えるほど現実味を失いますが、検出と下書き作成をAIに任せれば、人は「確認と判断」だけに集中できるからです。
具体的にイメージしてみましょう。仮に1本のリライトに、これまで本文確認と書き直しで60分かかっていたとします。Claude Codeに「古い箇所の一覧」と「修正案の下書き」まで作らせると、人の作業は確認と裏取りが中心になり、1本あたりの所要時間が短くなる可能性があります。短縮幅は記事の長さや内容の複雑さで大きく変わるので一概には言えませんが、本数が多いほど合計の削減効果は積み上がっていきます。
ここで成果を出している会社に共通するのは、「全部AIに任せる」のではなく「役割をきれいに分けている」点です。AIはコンテンツ作成のうち、下書き・構造化・バリエーション出しといった重たい作業を担い、人は独自の視点・事実確認・公開判断を担う。この協業の形が、品質を保ったまま量をこなすコツです。
もう1つの効果が、訪問者からの信頼を保てることです。古い数字や切れたリンクが残った記事は、それだけで読み手の信頼を損ないます。更新頻度そのものが検索順位を上げるわけではありませんが、料金やリンクが現状と合っていることは、記事の信頼性や使いやすさに直結します。リライトで情報を新しく保つことは、検索順位を直接操作する小細工ではなく、記事の信頼性そのものを底上げする取り組みだと考えてください。統計データの更新を仕組み化したい場合はAIがホワイトペーパーの統計を拾い直し自動更新する方法の考え方も応用できます。
よくある失敗と回避法

ここでは、私たちが現場でよく見かける失敗を3つ紹介します。どれも「やりがち」なものばかりです。先回りして知っておけば、ほとんど防げます。
失敗1。AIの修正をそのまま信じて公開してしまう
一番多い失敗がこれです。「古い◯◯円を最新の△△円に直しました」とAIが返してきたとき、その△△円が本当に正しいとは限りません。AIは調べずに、それらしい数字を作ることがあります。これを確認せず公開すると、間違った情報を堂々と載せることになり、かえって信頼を失います。
回避法はシンプルです。手順3で書いたように、新しい数値や金額には「要確認」の印を付けさせ、公開前に必ず一次情報(公式サイトなど)で裏取りします。AIは最終的な書き手ではなく、執筆アシスタントだと位置づけてください。
失敗2。直しすぎて記事の良さや構造を壊す
「ついでに全体も整えて」と曖昧に頼むと、AIは見出しを勝手に入れ替えたり、HTMLのタグ構造を崩したり、もともと良かった言い回しまで平均的な文章に書き換えてしまうことがあります。気づいたら、元記事の個性が消えて、のっぺりした文章になっていた、というのはよくある話です。
回避法は、指示の範囲をしぼることです。「今回は古い情報の箇所だけ直す。文章のトーンや構造は変えない」と明示します。方針メモ(手順4)に「元のHTML構造は原則そのまま残す」と書いておくのも効きます。
失敗3。指示が曖昧で、的外れな修正が返ってくる
「いい感じにリライトして」のような指示は、AIにとっては「何をすればいいか分からない指示」です。結果として、頼んでいない部分を変えたり、肝心の古い箇所を見落としたりします。AIを「入ったばかりの新人」だと思ってください。新人に「いい感じに」と言っても伝わらないのと同じです。
回避法は、具体的に伝えることです。「どのファイルの、どんな観点を、どう直すか」を言葉にします。最初は一覧だけ出させて、人が見てから書き換えを指示する二段構えにすると、的外れが激減します。
共通する考え方。3つの失敗はすべて「AIに判断を丸投げした」ときに起きています。AIに任せるのは作業、判断は人。この役割分担を崩さないことが、最大の回避法です。
使う側の落とし穴。導入前に知っておきたい現場の本音
ここまで読んで「便利そう」と感じてもらえたら嬉しいのですが、率直にお伝えしておきたい落とし穴もあります。きれいごとだけ並べても、実際に始めると詰まるからです。
まず、最初のハードルは「記事をファイルにする」段階です。手順1でさらっと書きましたが、WordPressから記事を取り出してフォルダに整える作業は、本数が多いと地味に手間がかかります。逆に言えば、ここさえ越えれば後は楽になります。最初の1回だけは腰を据えて準備する、と覚悟しておくと拍子抜けするほどスムーズに進みます。
次に、向き不向きがあります。Claude Codeのような一括処理が活きるのは「過去記事が数十本以上あり、定期的に情報を更新したい会社」です。記事が数本しかない、めったに更新しない、という場合は、正直チャット型AIで1本ずつ直すほうが早いです。本数と更新頻度を冷静に見て、自社が一括処理に値するかを判断してください。
もう1つ、見落とされがちなのが情報の取り扱いです。社外秘の数字や個人情報を含む文章をAIに渡すときは、社内ルールを確認しておくべきです。何を入力してよくて、何はダメなのか。ここを曖昧にしたまま走ると、後でトラブルになります。考え方の整理にはAIに入力してはいけない個人情報。AIセキュリティ社内ルールの作り方が役立ちます。
そして一番の本音をお伝えします。Claude Codeはターミナルから使うツールで、最初の環境づくり(インストールや認証)でつまずく人が一定数います。一度動いてしまえば「もっと早く使えばよかった」となるのですが、その最初の一歩で挫折してしまうと、せっかくの効率化にたどり着けません。「最初のセットアップと運用ルールづくりだけ伴走してもらう」という選び方は、現場ではとても現実的な妥協点です。ツールそのものより、自社の業務に合わせた使い方の設計のほうが、実は価値が大きいのです。
よくある質問
プログラミングが分からなくても使えますか
記事のリライト用途なら、コードを書く知識はほぼ不要です。AIには日本語で指示を出せます。ただし最初のインストールと認証だけはターミナル操作が必要なので、そこでつまずく人はいます。動き出せば、あとは会話で進められます。
AIが書き換えた内容は信用していいですか
文章の体裁を整える力は信用してよいですが、新しい数字や事実は必ず人が確認してください。AIは調べずに、もっともらしい数値を作ることがあります。金額や統計には「要確認」の印を付けさせ、公開前に公式情報で裏取りするのが安全です。
何本くらいから一括処理にする意味がありますか
目安として、過去記事が数十本以上あり、定期的に情報を更新したい場合に効果が出ます。数本しかないなら、チャット型AIで1本ずつ直すほうが早いことも多いです。まずは5本ほどで試し、手応えを見てから増やすのがおすすめです。
WordPressに直接つなげて自動更新できますか
API連携などで自動化する例はありますが、いきなり全自動にするのは危険です。誤った修正がそのまま公開されかねません。最初は「下書きまでAI、公開判断は人」の形を強くおすすめします。慣れてから少しずつ自動化を広げましょう。
まとめ。まずは5本から試してみましょう
過去記事のリライトは「やらなきゃ」と分かっていても後回しになりがちな仕事です。Claude Codeを使えば、古い箇所の検出と修正案づくりという重たい部分をAIに任せ、人は確認と判断に集中できます。大事なのは、作業はAI・判断は人、という役割分担を崩さないことです。
とはいえ、最初のファイル準備や環境づくり、自社に合った運用ルールの設計でつまずく方が多いのも事実です。ここまで読んで「仕組みは分かったけれど、自社でゼロから立ち上げるのは大変そう」と感じた方は、コレットラボのAI業務システム化支援にお声がけください。現状を整理して「どこから手をつけるか」を一緒に考えるだけでも構いません。まずは気軽にお話を聞かせてください。AI業務システム化の詳細はこちらからご覧いただけます。
30分の無料相談
現状をお聞きし、優先順位を一緒に整理します。
予約する →