「AIでリライトすれば早い」のは確かだ。ただ、どの記事を直すかを間違えると手間だけかかり、AIが書いた数字を確かめずに載せると、かえって信頼を落とす。本記事では、AIを使った記事リライトの方法を、Search Consoleでの記事の選び方→7つの手順→そのまま使えるプロンプト→失敗と対策→効果測定の順に解説する。あわせて、LIF Tech編集部がClaude Codeを使って1日で136本の記事を更新した実際の記録と、その過程で見つかった誤情報も公開する。
この記事の前提：実例の数字は、2026年10月11日にLIF Tech（本サイト）で行った作業の記録から取っている。リライトの効果は判定前（途中経過は10月25日、判定は11月8日の予定）のため、本記事では「順位が上がった」とは書かない。判定が出たら追記する。
この記事でわかること
- AIでリライトすると効果が出やすい記事・出にくい記事の見分け方
- Search Consoleで直す記事を選ぶ具体的な基準と、記事を4タイプに分ける方法
- AIリライトの7つの手順（図解）と、手順ごとのプロンプト例
- ChatGPT・Claude・Geminiでのやり方と使い分け
- リライトで変えてはいけないものと、あわせて見直したい内部リンク
- 実例：1日136本の更新で見つかった誤情報と、タイプ別のビフォーアフター
- コピペで使えるAIリライトのチェックリスト
- AIリライトで起きやすい失敗と、人が判断すべきこと
- 効果を正しく測るための比較のしかた
執筆：佐藤 祐介（株式会社LIFRELL 代表取締役／業界歴15年・マーケティング支援 累計500社以上）1. AIで記事をリライトするメリットと、気をつけたいこと
AIを使ったリライトの一番のメリットは、調べる・比べる・書き直す作業の速さだ。検索語の整理、上位記事との見比べ、古い記述の洗い出し、見出しや文章の書き直しといった作業を、人が1本ずつやるよりはるかに短い時間で回せる。
一方で、気をつけたいことが2つある。
- AIは、もっともらしい数字や事実を作ってしまうことがある。料金・発売日・統計などを確かめずに載せると、誤情報を量産することになる
- 「新しくした」だけでは順位は上がらない。検索している人が知りたいことに、前より的確に答えられているかが大事だ
つまりAIリライトのコツは、速さはAIに任せつつ、「どれを直すか」と「本当に正しいか」は仕組みで担保することにある。この記事の手順は、その2つを前提に組み立てている。
2. リライトする記事の選び方——Search Consoleで「直せば伸びる記事」を探す
リライトは、全記事を一律に直すより、伸びしろのある記事から順に直すほうが効率がよい。Search Consoleの「検索パフォーマンス」で、ページごとの表示回数・クリック数・平均掲載順位を見て選ぶ。
表示回数で優先順位を決める
| 表示回数（直近28日） | 考え方 | LIF Techでの扱い |
|---|---|---|
| 多い（300回以上） | すでに検索で見られている。少しの改善がクリックに直結しやすい | 最優先でリライト（23本） |
| 中くらい（100〜299回） | 検索語との相性はある。中身の不足を埋めると伸びやすい | 次にリライト（31本） |
| 少ない（1〜99回） | 検索意図とずれているか、評価がまだ低い | 軽い点検にとどめ、効果測定の比較用に残す |
| 0回（3か月） | インデックスされていない可能性が高い | 原因を調べて、直す・統合する・noindexにするを判断 |
記事を4つのタイプに分けて、直し方を決める
選んだ記事は、ページごとに「どんな検索語で、何位に表示されているか」を確かめ、次の4タイプに分ける。直し方がタイプごとに違うからだ。
| タイプ | 状態 | 直し方 |
|---|---|---|
| ① 順位はあるのにクリックが少ない | 5〜10位前後で表示されているが選ばれていない | タイトルと説明文を実際の検索語に合わせる。冒頭で答えを言い切る |
| ② 11〜20位で止まっている | 内容が上位の記事に負けている | 上位記事にあって自分の記事にない話題を、章として足す |
| ③ 検索語と中身がずれている | 例：「料金」で表示されているのに料金の章がない | 検索の意図に合う章を作り、記事の主題もそちらに寄せる |
| ④ 情報が古い | 料金・仕様・名称が変わっている | 公式情報で最新化し、根拠のない数字は消す |
実際に分けてみると、1本の記事が複数のタイプにまたがることも多い。たとえばLIF Techでは、「料金」で12位に表示されているのに料金の章が弱い記事（③④）や、存在しないモデル名で検索されているのに記事が古いモデルのままの記事（④）が見つかった。
3. AIリライトの7つの手順（図解）
LIF Techで実際に回している流れを図にすると次のとおりだ。ポイントは、「書き換える」の前後に、選ぶ・確かめる・検証する工程を必ず入れることにある。
青＝AIに任せやすい工程、黄＝人が必ず確かめる工程、緑＝効果測定。
STEP 1：直す記事を選ぶ
Search Consoleの「検索パフォーマンス」→「ページ」タブで、期間を28日にして表示回数順に並べる。前章の基準で、最初に直す記事のまとまり（たとえば「表示300回以上」）を決める。直す前の表示回数・クリック数・平均順位は、この時点で記録しておく。あとで効果を比べる基準になる。
STEP 2：検索語と上位記事を見る
記事ごとにページで絞り込み、「クエリ」タブで主な検索語と順位を確認する。表示が多い検索語で実際にGoogle検索し、上位3〜5記事の見出しを見比べる。自分の記事に足りない話題が、そのまま次の章の候補になる。
【プロンプト例：足りない話題を洗い出す】 次の「自分の記事の見出し」と「上位記事の見出し」を比べて、 上位記事にはあって自分の記事にない話題を、検索する人にとっての重要度が高い順に5つ挙げてください。 それぞれ、なぜ必要かを1行で添えてください。推測で事実を補わないでください。 自分の記事の見出し：（貼り付け） 上位記事の見出し：（記事ごとに貼り付け）
STEP 3：タイプを決める
検索語と順位から、前章の①〜④のどれに当たるかを決める。直す範囲を先に決めておくと、AIに「全部書き直して」と頼んで記事の良い部分まで崩してしまう事故を防げる。
STEP 4：公式情報で事実を確かめる
AIリライトで一番大事な工程だ。料金・発売日・仕様・名称・統計など、数字や固有の事実は、公式ページ（提供元のサイト・ヘルプ・リリースノート・官公庁の資料など）だけで確認する。比較サイトやまとめ記事の数字は使わない。公式で確認できない数字は、記事から外すか「公式サイトで要確認」と書く。
【プロンプト例：事実確認の依頼】 次の記事に出てくる料金・日付・仕様・統計をすべて抜き出し、一覧にしてください。 そのうえで、それぞれを提供元の公式ページだけで確認し、 「公式で一致」「公式と違う（正しい値と出典URL）」「公式で確認できない」の3つに分けてください。 公式で確認できないものを推測で埋めないでください。各項目に確認したURLと日付を付けてください。 記事本文：（貼り付け）
STEP 5：書き換える
STEP 3で決めた範囲だけを書き換える。新しく足す章は、上位記事の後追いではなく、自分たちにしか書けない情報（実際に試した手順、公式の数字から計算した試算、現場で起きたこと）を入れると差が出る。タイトルと説明文は、実際に表示されている検索語を前に置く。
【プロンプト例：章の追加とタイトル案】 この記事は「（主な検索語）」で（順位）位に表示されています。 STEP 4で確認した事実（貼り付け）だけを使って、次を作ってください。 1. 冒頭に置く「結論」の段落（3〜4文） 2. 足りない話題「（STEP 2で出た話題）」の章（見出し＋本文） 3. 検索語を前に置いたタイトル案を3つ（32字前後）と、説明文案（120字前後） 確認した事実にない数字や固有名詞は使わないでください。
STEP 6：保存前と公開後に検証する
保存の前に、書き換えた本文が元の記事より極端に短くなっていないか（LIF Techでは元の95%以上を目安にしている）と、最後の見出しまで残っているかを確認する。保存したら、公開ページを開いて、タイトル・説明文・追加した章が反映されているかを確かめる。CMSのプラグインによっては、編集画面で入れたタイトルや説明文が保存されないことがあるからだ。
STEP 7：再登録を申請し、効果を測る
Search Consoleの「URL検査」で、書き換えたページの再クロールを依頼する。1日に申請できる件数には上限があるので、待ちリストを作って毎日上から申請していく。効果は書き換えから2〜4週間後に、書き換え前と同じ日数の期間で比べる（第10章）。
4. ChatGPT・Claude・Geminiでのリライトのやり方と使い分け
どのAIでも、第3章の手順そのものは同じだ。違いが出るのは、記事の本文や調べた資料をどう渡すかと、事実確認をどこまで任せるかだ。ここでは、どのAIを使う場合にも共通するやり方と、使い分けの考え方をまとめる。
共通のやり方：1回で全部やらせない
- 1回目は「診断」だけ：記事本文・主な検索語と順位・上位記事の見出しを渡し、「足りない話題」「古くなっていそうな記述」「根拠のない数字」を洗い出させる。この段階では書き換えさせない
- 2回目は「事実確認」：洗い出した数字や事実を、提供元の公式ページで確認させる。出典URLと確認日を必ず書かせる
- 3回目で「書き換え」：確認できた事実だけを使って、決めた範囲（章の追加・冒頭の結論・タイトル案など）を書かせる
1回の指示で「最新にして書き直して」と頼むと、確認していない数字が混ざりやすく、記事の良い部分まで書き換えられやすい。工程を分けるだけで、事故はかなり減る。
使い分けの考え方
| やりたいこと | 向いている使い方 |
|---|---|
| 1本ずつ、文章の質を重視して直したい | チャット画面に本文と資料を貼り、上の3回に分けて進める。ChatGPT・Claude・Geminiのどれでもできる |
| Googleドキュメントで原稿を管理している | 原稿のある場所と連携できるAIを使うと、貼り付けの手間が減る |
| 何十本もまとめて直したい | Claude Codeのようにファイル操作やブラウザ操作までできるエージェント型のツールで、Search Consoleの数字の取り出しから保存・確認までを一連の流れにする（LIF Techの方法） |
| 最新の料金や仕様を確かめたい | Web検索ができる状態で使い、必ず「公式ページだけ」「出典URLを残す」と指示する |
どのAIを使うかより、工程を分けることと、確認できない数字を使わせないことのほうが、仕上がりへの影響は大きい。
5. 実例：LIF Techで1日に136本を更新した記録
ここからは、LIF Tech編集部が2026年10月11日に行った作業の記録だ。使ったのは、AnthropicのClaude Code（デスクトップアプリ）と、ログイン済みのブラウザを操作できるClaude in Chrome、それにSearch ConsoleとWordPressだ。
| 項目 | 数字 |
|---|---|
| この日に更新した記事 | 136本（うち新規14本）。内容の書き換えのほか、事実の訂正・タイトルの見直し・コード表示の修正を含む |
| 表示300回以上の記事 | 23本を点検し、大半を書き換え（効果測定の第1グループ） |
| 表示100〜299回の記事 | 31本を診断：書き換え25本、統合2件、確認のみ4本 |
| 3か月表示0の記事 | 43本を診断。うち41本が「クロール済み - インデックス未登録」 |
| noindexにした記事 | 35本（検索需要がほぼないイベントの現地レポート。会社の実績として公開は続ける） |
AIリライトの途中で見つかった誤情報
公式情報との照合（STEP 4）で、公開済みの記事から次のような誤りが見つかった。どれも、AIに「最新にして」と頼むだけでは見落としやすい種類のものだ。
| 見つかった問題 | 何がまずかったか | 直し方 |
|---|---|---|
| 設定手順が、提供元がもう保守していない古い方式のまま | 読者が古い手順で設定してしまう | 公式ドキュメントの現行の手順に全面差し替え |
| 助成金の助成率が古い（または誤った）値 | 読者が申請の判断を誤る | 官公庁の最新の支給要領の値に訂正し、版の日付を明記 |
| 存在しないモデル名で検索されているのに、記事は旧モデルのまま | 検索した人の疑問に答えていない | 「そのモデルは存在しない」と公式のモデル一覧で明記し、最新モデルの章を追加 |
| 買収された企業が「〇〇傘下」のままになっていた | その後、買収が取り消されていた | 公式発表と報道を分けて、経緯を時系列で書き直し |
| 料金プランが旧体系のまま | 今は存在しないプランや数え方を案内していた | 公式の料金ページの現行プランに差し替え |
| 出典のない相場表・株価・年収 | 根拠を示せない数字が並んでいた | 削除し、「何で費用が決まるか」や公式の求人に載っている数字に置き換え |
| 以前の転送設定のせいで、書き直した記事が404ページに飛ばされていた | せっかく直した記事が、読者にもGoogleにも見えていなかった | 転送設定を無効化し、表示を確認 |
最後の例は、記事の中身ではなくサイトの設定の問題だった。2本の記事を1本に統合して転送を設定しようとしたとき、転送先の記事そのものが、昔の設定で別のページに飛ばされていることに気づいた。統合で転送を設定するときは、転送先がさらに別の場所へ転送されていないかまで確認する必要がある。
タイプ別のビフォーアフター（実際に直した3本）
どの記事も、Search Consoleで「どんな検索語で何位に表示されているか」を見たところから直し方を決めている。数字は書き換え前の直近28日（2026年10月8日までのデータ）だ。
| 記事のテーマ | 書き換え前の状態 | 見立て | やったこと |
|---|---|---|---|
| メモアプリの情報漏洩リスク | 「アプリ名＋危険性」で9.4位、「アプリ名＋情報漏洩」で3.8位。記事はAIへの学習利用の話が中心で、アプリ自体が危ないかには答えていなかった | ③ 検索語と中身のずれ | アプリ本体・同期・プラグインの安全性を、提供元の公式ページ（セキュリティ・外部監査・プラグインの安全対策）で確認した章を冒頭近くに追加。タイトルも「〇〇は危険？」から始まる形に変更 |
| AIエディタの課金とClaude | 「エディタ名＋課金＋Claude」で6.4位。記事は2つのツールの役割分担の話で、課金の仕組みは書いていなかった | ①③ 順位はあるのに答えがない | 冒頭に「エディタの中でClaudeを使う場合と、Claude Codeを使う場合で支払い先が変わる」という結論の章を追加。公式の料金ページとドキュメントで、プランごとの月額と利用枠の仕組みを確認して表にした |
| 新しい職種に未経験からなれるか | 「職種名＋未経験」で5.1位、28日で表示169回・クリック11回。冒頭に答えがなく、職種経験者向けの話から始まっていた | ① 順位はあるのにクリックが少ない | 冒頭に「職種が未経験の人」と「業界自体が未経験の人」で答えが違うことを示す結論の章を追加。転職サイトの求人検索で、未経験可の求人が実際に何件あるかも確認して書いた。出典を確認できない年収の表は外した |
3本とも、新しい情報を足す前に、記事がその検索語にまだ答えていない部分を探している。AIに「もっと詳しく」と頼むより、検索語と記事の中身のずれを先に見つけるほうが、直す場所がはっきりする。
作業の分担——AIに任せたこと、人が決めたこと
| AIに任せたこと | 人が決めたこと |
|---|---|
| Search Consoleの数字の取り出しと記事の分類、上位記事との比較、公式ページでの事実確認、本文の書き換え、保存と公開ページでの検証 | どのグループから直すか、記事の統合や転送、noindexにするか、クライアント名を出さないなどの公開範囲、効果測定のやり方 |
記事の統合・noindex・削除のように、元に戻しにくい判断や、サイト全体の評価に関わる判断は、AIの提案を見たうえで人が決めた。
6. AIリライトで起きやすい失敗と対策
| 失敗 | 起きること | 対策 |
|---|---|---|
| 出典のない数字をそのまま載せる | 誤情報が広がり、記事全体の信頼が落ちる | 数字は公式ページだけで確認。取れないものは消す |
| 置き換えの範囲を間違えて本文が消える | 記事の後半がまるごと消えた状態で公開してしまう | 保存前に「元の長さの95%以上か」「最後の見出しが残っているか」を確認 |
| タイトルや説明文が保存されていない | 中身を直しても検索結果の見え方が変わらない | 公開ページのタイトルと説明文を実際に読んで確認する |
| 日付だけ新しくする | 中身は変わらず、効果も出ない | 更新日は、中身を直したときだけ変える |
| 全記事を一度に直す | 何が効いたのか分からなくなる | 一部の記事は手を入れずに残し、比較の基準にする |
| 転送・統合の設定ミス | 直した記事が表示されない | 転送先の表示まで実際に開いて確認する |
LIF Techでも、作業中に「保存の処理とページの移動が重なって、タイトルだけ反映されない」ことが何度かあった。処理を2段階に分け、保存のあとで公開ページを必ず開いて確かめるようにして防いでいる。
コピペで使えるAIリライトのチェックリスト
【選ぶ】 □ 直す前の表示回数・クリック数・平均順位・主な検索語を記録した □ 記事のタイプ（①クリック少／②11〜20位／③意図のずれ／④古い）を決めた □ 直さずに残す記事（比較用）を決めた 【確かめる】 □ 料金・日付・仕様・名称・統計を、すべて公式ページで確認した □ 確認できなかった数字は削除したか「要確認」と書いた □ 比較サイト・まとめ記事の数字を使っていない □ 確認したURLと日付を記録した 【書き換える】 □ 冒頭で検索語への答えを言い切っている □ 上位記事にあって自分の記事になかった話題を足した □ 自分たちにしか書けない情報（試した手順・試算・現場の事例）を入れた □ タイトルと説明文の前のほうに、実際の検索語を入れた □ 取引先の実名や、許可のない数字を書いていない 【検証する】 □ 本文が元の95%以上の長さで、最後の見出しまで残っている □ 公開ページで、タイトル・説明文・追加した章が表示されている □ FAQを直したら、構造化データも同じ内容に直した □ 転送や統合を設定したら、転送先の表示まで確認した □ 再クロールを申請（または待ちリストに追加）した
7. リライトで変えてはいけないもの
リライトは「直す」ことに目が行きがちだが、すでに評価されている部分を壊さないことも同じくらい大事だ。次のものは、理由がない限り変えない。
| 変えてはいけないもの | 理由 | どうしても変えるとき |
|---|---|---|
| 記事のURL | これまでに集まった評価や外部からのリンクがURLに付いている | 301リダイレクトで新しいURLに転送する。転送先がさらに転送されていないかも確認する |
| すでに順位が付いている見出し・段落 | Search Consoleで表示されている検索語に答えている部分は、評価の源になっている | 検索語ごとに、どの段落が答えているかを確認してから直す。言い回しを変えるより、情報を足すほうを優先する |
| 公開日 | 公開日を新しく見せる操作は、読者にもGoogleにも誤解を与える | 中身を直したときは「更新日」を変え、何を更新したかを記事内に書く |
| 記事の主題 | 主題を大きく変えると、これまでの検索語との相性が崩れる | 別の主題を扱いたいなら、新しい記事を作って内部リンクでつなぐ |
LIF Techでも、主な検索語で1〜2位に表示されている記事は、情報が古くなっていないかの確認にとどめ、大きく手を入れなかった。
8. リライトとあわせて見直したい内部リンク
記事を直したら、その記事へのリンクと、その記事からのリンクも見直すと効果が出やすい。サイト内のリンクは、読者を関連する記事に案内するだけでなく、Googleに記事どうしの関係を伝える役割もある。
- 評価の高い記事からリンクする：表示回数が多い記事から、直した記事へ自然な文脈でリンクを張る
- まとめ記事と個別記事をつなぐ：たとえばツールの入門記事から、インストール・エラー対処・料金などの個別記事へリンクし、個別記事からは入門記事へ戻れるようにする（LIF TechではComfyUIの入門記事と4本の個別記事をこの形でつないだ）
- リンクの文字を具体的に：「こちら」ではなく、リンク先の内容が分かる言葉にする
- 統合した記事へのリンクを付け替える：記事を統合して転送を設定したら、サイト内のリンクも新しいURLに直す。転送に頼りきらない
- リンク切れを確認する：削除や下書きに戻した記事へのリンクが残っていないかを確認する
9. AIに任せないほうがいい判断
- 記事の統合・削除・noindex：一度やると戻しにくく、サイト全体の評価に関わる
- クライアントや取引先の情報をどこまで出すか：実名や成果の数字は、許可のあるものだけにする
- 公式で確認できなかったことをどう書くか：「書かない」か「未確認と明記する」かを決めておく
- 効果の判定：数字の上下がリライトのおかげかどうかは、比較の条件をそろえて人が判断する
10. リライトの効果を正しく測る方法
リライトの効果は、順位の上下だけを見ても判断できない。サイト全体の評価やGoogleのアップデートでも数字が動くからだ。次の3つをそろえて比べる。
- 同じ日数で比べる：書き換え前の28日と、書き換えから2〜4週間後の28日を比べる
- 手を入れていない記事と比べる：同じ時期に直していない記事の動きも見て、サイト全体の上下と分けて考える
- 記録を残す：記事ごとに、直す前の表示回数・クリック数・平均順位・主な検索語と、何を直したかを書いておく
LIF Techでは、表示300回以上の23本と、100〜299回の31本をそれぞれ別のグループとして記録し、表示1〜99回の記事は手を入れずに比較用として残している。結果が出たら、この記事に追記する。
11. AIリライトに使ったツール
| ツール | 使い方 |
|---|---|
| Google Search Console | 記事ごとの表示回数・順位・検索語の確認、再クロールの申請 |
| Claude Code（デスクトップアプリ） | 作業全体の進行、数字の整理、記事の書き換え、記録ファイルの作成 |
| Claude in Chrome | ログイン済みのブラウザでSearch ConsoleやWordPressを操作 |
| WordPress（REST API） | 記事の本文・タイトルの保存と、公開ページでの確認 |
Claude Codeの料金やプランの選び方はClaude Codeの料金、外部ツールとつなぐ設定はClaude CodeのMCP設定方法で解説している。
工程ごとにAIモデルを使い分ける（API料金で考える）
大量の記事をAPI経由で処理するなら、すべての工程に最上位のモデルを使う必要はない。工程ごとに求められる力が違うからだ。2026年10月11日時点の公式の料金（100万トークンあたり、入力／出力）は次のとおり。
| モデル | 料金（入力／出力） | 公式の位置づけ |
|---|---|---|
| Claude Opus 5.5 | $4／$20 | 迷ったときの第一候補とされる上位モデル |
| Claude Sonnet 5.5 | $2／$10 | 範囲がはっきりした日常の作業や資料作成向け |
| Claude Haiku 5.5 | $0.10／$0.50（入力10万トークン超は$0.50／$2.50） | 分類・要約・補助のエージェント向け。複雑なコーディングには勧めていない |
| GPT-6.1 Sol | $2／$10 | 上位のAstraの5分の1の単価で、それに迫る性能とされる |
| GPT-6 Luna | $0.10／$0.50 | 件数の多い定型処理向け |
この料金と位置づけから考えると、たとえば次のような分け方ができる。
- 検索語の分類やタイプ分け（STEP 1〜3）：件数が多く判断も定型的なので、HaikuやLunaのような安いモデルで足りることが多い
- 事実確認（STEP 4）：公式ページを読み比べて食い違いを見つける作業なので、ある程度の読解力が必要。中位以上のモデルで、出典URLを必ず残させる
- 本文の書き換え（STEP 5）：文章の質と、確認した事実だけを使う指示への忠実さが大事なので、上位のモデルを使う価値がある
なおLIF Techの今回の作業は、APIの従量課金ではなく、Claude Codeのデスクトップアプリ上で行った。モデルごとの細かい使い分けより、確認の手順を崩さないことを優先している。
この記事を書いた人
記事の改善を、戦略から実行まで一緒に
この記事のリライトの進め方は、自社メディアの運営で実際に回しているものです。サイトの診断から記事の改善、効果の測定まで、マーケティング全体を伴走する支援をしています。
運営：株式会社LIFRELL
12. この記事で使った管理シート（無料ダウンロード）
リライトと記事テーマの選定で実際に使った表を、テンプレートにした。書き方の例を入れた「記入例」シートと、空欄の記入用シートが入っているので、使い方を見ながら自社用に書き換えて使える。
【無料ダウンロード】SEOタイトル・説明文の改善シート（Excel）
今と新しいタイトル・説明文を並べ、字数を自動で数える。直す前の表示回数・クリック・順位と、直した日も残せる。
【無料ダウンロード】記事テーマの選定シート（Excel）
採用・却下と理由・判定基準の3シート。ロングテール比率・同音異義語・競合の捕捉率の3つで「本当に取れる検索か」を判断する。想定流入は自動計算。
【無料ダウンロード】記事の正確性チェックリストと出典表（Excel）
記事に出てくる数字・日付・料金・固有名詞を1行ずつ、出典と確認日といっしょに記録する表です。AIに下書きを任せても、公開前に「どこで確かめたか」をすぐに示せる記事になります。
入っているシート：正確性のルール・出典表・公開前チェックリスト（ほかに「はじめに」と記入例）。
【無料ダウンロード】SEOの体制表と月次スケジュール（Excel）
SEOを進めるチームの役割分担と、毎月の記事制作・リライト・計測・報告の予定を一枚で管理するシートです。施策の優先順位も、効果と手間の点数から自動で出せます。
入っているシート：体制表・月次スケジュール・施策の優先順位・月次報告の項目（ほかに「はじめに」と記入例）。
リライトしても検索結果に出てこない記事の調べ方は、「クロール済み - インデックス未登録」の原因と対処で詳しく書いている。
サイト運営・SEOでAIを使った実例は、AIでサイト運営・SEOを回す実例まとめにまとめている。
この記事で紹介したものを含め、実務で使っている依頼文とプロンプトはAI業務の依頼文・プロンプトテンプレート集にまとめている。
よくある質問
Q. AIでリライトするとGoogleの評価が下がりませんか？
A. Googleは、コンテンツがAIで作られたかどうかではなく、役に立つかどうかを見ると案内している。問題になるのは、確かめていない情報を量産することだ。事実を公式情報で確認し、検索する人の疑問に前より的確に答えられていれば、AIを使うこと自体は問題にならない。
Q. どの記事からリライトすればいいですか？
A. Search Consoleで表示回数が多いのに順位が5〜20位前後で止まっている記事からがおすすめだ。すでに検索で見られているので、少しの改善がクリックにつながりやすい。
Q. 更新日を新しくするだけでも効果はありますか？
A. 中身が変わっていなければ、効果は期待しにくい。更新日は、内容を実際に直したときだけ変えるのがよい。
Q. リライトの効果はいつ分かりますか？
A. 再クロールされてから評価に反映されるまで時間がかかるため、書き換えから2〜4週間後に、同じ日数の期間どうしで比べるのが目安だ。
Q. AIに事実確認まで任せても大丈夫ですか？
A. 確認の作業そのものはAIに任せられるが、「公式ページだけを見る」「確認できないものは推測で埋めない」「出典URLと日付を残す」というルールを最初に決めておくことが前提だ。最終的に載せるかどうかは人が判断する。
Q. リライトのときにURLを変えてもいいですか？
A. 基本的には変えないほうがよい。URLにはこれまでの評価や外部からのリンクが付いている。どうしても変える場合は、古いURLから新しいURLへ301リダイレクトを設定し、転送先がさらに別の場所へ転送されていないかも確認する。
Q. 1日に何本までリライトできますか？
A. 作業の速さより、確認の質で決めたほうがよい。LIF Techでは1日に136本を更新したが、内容まで書き換えた記事は一部で、ほかは事実の訂正やタイトルの見直しなどだ。Search Consoleの再クロールの申請にも1日の上限があるので、書き換えた本数より申請の順番待ちが先に詰まる点にも注意したい。
執筆：LIF Tech編集部（株式会社LIFRELL）。本記事の実例は2026年10月11日の作業記録にもとづく。各ツールの仕様や料金は変わることがあるため、最新情報は各公式サイトで確認してほしい。
