AIでSEO記事をリライトする方法｜検索意図を守って古い情報を更新する

AIでSEO記事をリライトするときは、URL、中心となる検索意図、記事の役割を先に確認し、章単位で keep（維持）・update（更新）・delete（削除）を決めてから差分を編集します。AIに渡すのは「全文を書き直して」ではなく「この章のこの記述を、この根拠で置き換えてよいか」という提案依頼です。全面改稿が必要な場合もありますが、先に維持する固有情報を特定しないと、実測データや独自の説明まで失うリスクがあります。

この記事では、リライト前に1枚にまとめる refresh brief（更新方針書）のテンプレート、章ごとの keep・update・delete 判定表、そして更新後の効果を同条件で測るための記録フォーマットまでを順に解説します。新規記事の書き方と、主キーワードそのものを変える判断は扱いません。

情報確認日：2026年7月28日（日本時間）

結論：URLと中心意図を確認し、章単位の差分から検討する

この記事の結論

リライト対象はデータで選ぶ。指標の一時的な揺れと継続的な低下を分けてから着手する
着手前にrefresh briefを書き、URL・中心意図・記事の役割・維持する強みを記録する。変更が必要なら別記事化や統合も含めて先に判断する
章ごとに keep・update・delete を決める。判定なしにAIへ渡さない
AIには全文書き直しではなく、変更前と変更後を対にした差分の提案だけをさせる
更新した事実には一次情報のURLと確認日を必ず付ける
効果判定は再クロールと再処理、十分な表示回数を待ち、同じ条件の期間と季節性・外部変化を併記して比較する

リライト対象をデータで選ぶ

表示・CTR・順位・経過日数を見る

「なんとなく古そうな記事」から手を付けると、直しても何も変わらない記事に時間を使うことになります。Search Consoleのパフォーマンスレポートで4つの数字を並べ、どの記事のどこが弱っているかを先に特定します。

指標の定義は正確に押さえておく必要があります。ヘルプによると、表示回数は「サイトへのリンクが Google で閲覧された頻度」で、現在表示されている検索結果ページに項目が掲載されていればカウントされ、その項目が画面に表示されるまでスクロールされたかどうかは関係ありません。ただしカルーセルや展開領域の中にある項目は、スクロールで表示されたりクリックで展開されたりして初めてカウントされます。クリック数は「Google からサイトへのリンクがクリックされた頻度」で、同じリンクを複数回クリックしてもカウントは1回です。CTR（クリック率）はクリック数を表示回数で割った値です。

平均掲載順位には特に注意が要ります。Search Consoleは、property集計では同じ検索結果に同一propertyから複数の結果が出ても最上位の位置を報告します。page集計では対象URLごとに集計され、画面上のdimensionによって意味が変わります。複数掲載の下位位置はproperty集計の順位には個別に反映されないため、平均順位だけで判断せず、page・query別の表示回数とクリック数も確認してください。

既定の検索パフォーマンスレポートは過去3か月を表示します。長期推移を見るときは期間を広げ、季節性があるなら前年同期も比較します。最新日は暫定値で後から変わる場合があるため、確定した日だけで基準期間を作ります。またquery表は、privacy保護のための匿名化queryやdata truncationにより全件を示すものではなく、画面の表は最大1,000行です。query別の増減とchart合計が一致しないことを前提にします。大規模siteでは事前にbulk data exportを構成するとより多くの行を分析できますが、匿名化queryは含まれません。24時間view以外の日次dataはPacific Time基準なので、Analyticsや公開logとの日付ずれにも注意します。データの読み取り自体をAIに手伝わせる手順は「Search ConsoleのデータをAIで分析する方法」にまとめています。

一時的変動と継続的低下を分ける

数字が下がったからといって、すべてが記事側の問題ではありません。症状の出方によって、疑うべき原因も最初に打つ手も変わります。

データの出方	仮説の例	最初の確認	着手判断
表示回数は横ばい、CTRだけ低下	title link・snippetとqueryのずれ、SERP構成の変化、競合表示の改善	query別CTR、実際に表示されたtitle link・snippet、device・国を確認する	仮説が絞れれば小さな変更から
表示回数と順位が3か月以上かけて緩やかに低下	情報の陳腐化、検索意図や競合の変化、sitewide要因、技術的問題	page indexing、manual actions、ranking update、競合と本文の事実を確認する	記事固有の原因があれば高
順位は維持、表示回数だけ低下	query需要の低下、季節性、query mixの変化、表示機能の変化	前年同期、query別、国・device別を比較する	需要要因なら更新を急がない
特定のqueryだけが急落	回答不足、別URLへの入れ替わり、需要・SERP・競合の変化	query filter後にpageを確認し、前年同期と検索結果も見る	原因に応じて中〜高
全指標が数日で急落し、数日で戻る	暫定data、短期変動、site障害、indexing問題、ranking update	確定data、uptime、page indexing、Search Status Dashboardを確認する	原因不明のまま本文を変えない
設定したfact-check期限を迎えたが、指標は横ばい	価格・仕様・画面・制度など、変化しやすい事実の陳腐化	年数だけで決めず、変更頻度の高い主張を一次情報で点検する	誤情報があれば指標に関係なく更新

ヘルプの「一般的なタスクとユースケース」でも、期間比較で「差」の列を並べ替えると前の期間から大きな変化があったクエリやページを確認できること、CTRが低いページはスコアカードでクリック率を選んでから昇順に並べ替えると特定できることが案内されています。まずこの2つで候補を絞り、上の表で症状を切り分けてください。

現在の検索意図と記事の役割を確認する

中心keywordと読了後行動を確認する

対象が決まったら、本文を開く前に refresh brief を1枚書きます。これは「何を直すか」ではなく、「何を直さないか」を先に決めるための文書です。書かずに始めると、AIも人も、直しやすいところから触ってしまいます。

# refresh brief

target_url:     https://example.com/blog/csv-import-basics/
primary_kw:     CSV インポート
intent:         はじめてCSVを取り込む人が、最小手順を知って作業を終える
role:           basic（入門）
last_updated:   2025-11-04
refresh_reason: 対象ツールの上限値が2026-05に改定された／掲載順位が3か月継続して低下

## 維持する強み（消したら価値が減るもの）
- 実測したエラー画面の対応表（外部から被リンクを受けている）
- 「文字コードを先に決める」という独自の手順順序
- 手順を7ステップに収めている簡潔さ

## 変えないもの（fixed）
- URL
- 主キーワード（CSV インポート）
- H1の主題
- 記事の役割（basic。比較記事にはしない）
- 読了後の行動（最小手順で1回の取り込みを完了する）

## 更新する範囲（scope）
- 対応形式と上限値の数値
- 2026年時点の画面名称
- よくある質問に、表示が増えている未回答のqueryを2件追加

## 対象外（out of scope）
- ツール比較の追加（/blog/csv-import-tools/ の担当）
- 事例インタビューの新規取材

「維持する強み」の欄は、固有情報を無意識に失わないために使います。実測データ、独自の手順、参照されているsection、他にない図解などを、analytics、被link、読者feedback、制作記録で確認します。AIの出力は元の表現や細部を一般化することがあるため、置き換えてはいけない事実・例・根拠を明示します。ただし、固有部分にも誤りや陳腐化があればkeepにせず、根拠を保ったままupdateします。

読了後の行動も明文化します。「最小手順で1回の取り込みを完了する」という記事に、比較表と料金表を足すと、読者は手順を終える前に迷うかもしれません。Google検索セントラルも、siteをfreshに見せることや検索順位の改善を主目的として大量の追加・削除を行う姿勢を警告signとして挙げています。追記の可否は文字数ではなく、対象読者の疑問を解消し、読了後行動へ近づけるかで判断します。

別意図への全面改稿を避ける

リライトの依頼が「この記事、比較記事に作り変えたい」という形で来ることがあります。これはリライトではありません。検索意図が変われば、必要な構成も、満たすべき読者の期待も別物になります。既存URLの中身を入れ替えると、次の3つが同時に起こります。

元の意図で評価されていたqueryでの表示を失う
新しい意図では、そのURLに蓄積のない状態から始めることになる
元記事に張られていた内部リンクと外部リンクの文脈が合わなくなる

refresh briefの「変えないもの」に手を入れる必要が出たら、通常の差分更新を一度止めます。主keyword、H1の主題、記事の役割、読了後行動が大きく変わる場合は、新規記事、既存URLの再設計、記事統合のどれが読者とsite構造に適するかを別の判断として行います。常に既存記事を残して新規作成するとは限りません。内容が重複する2本を増やすと競合や保守負担につながるため、canonical、内部link、redirectを含む移行計画まで決めます。新規で書き起こす場合の手順は「AIブログ記事の書き方」を参照してください。

中心意図と役割が同じままで、事実が古い、根拠が弱い、答えていない質問があるという状態は差分更新に向いています。この線引きをrefresh briefの段階で行うと、作業途中のscope拡大を検知できます。

keep・update・deleteを章ごとに決める

古い事実・弱い根拠・不足質問を抽出する

記事全体を「古い／新しい」で判断せず、見出し単位に分解して1章ずつ判定します。抽出の観点は3つです。

古い事実：数値、上限、価格、対応形式、バージョン、画面名称、年号の記載。一次情報に当たれば正誤が確定する項目
弱い根拠：出典のない断定、「一般的に」「多くの場合」で始まる記述、確認日のない引用
不足質問：Search Consoleで表示回数を得ているのに、本文で答えていないquery

この3つを章に割り当てると、判定はほぼ自動的に決まります。実例として、入門記事1本を分解した判定表を示します。

章	現在の記述	判定	根拠	作業内容
1. 導入	「2025年時点では」と年を明記している	update	年の記載が古く、内容と噛み合っていない	年号の断定を外し、確認日の表記に置き換える
2. 対応形式と上限	「上限は50MB」	update	公式ドキュメントが2026年5月に200MBへ改定	数値を差し替え、出典URLと確認日を併記する
3. エラー画面の対応表	実測のスクリーンショット3点と原因の対応	keep	外部から被リンクを受けている。他記事にない一次データ	触らない。表現の微修正も行わない
4. 旧バージョンの手順	v2系の画面での操作説明	delete	v2の提供が終了し、参照する読者がいない	削除。第6章の現行手順へ本文中で誘導する
5. 用語解説	一般的な定義を8語ぶん列挙	delete	読了後の行動に寄与せず、手順の途中で読み進みを止めている	手順に必要な2語だけ本文中の注記へ移し、章ごと削除
6. 現行の手順	7ステップの操作手順	keep	この記事の主機能。簡潔さが強みとして brief に記載済み	触らない。ステップを増やさない
7. よくある質問	3問	update	表示回数のあるqueryのうち2件に本文が答えていない	2問を追加。既存の3問は据え置く
8. まとめ	各章の要約	update	削除した第4章・第5章への言及が残る	削除章への参照だけを差し替える

この例では、8章のうちupdateが4、keepが2、deleteが2です。件数の比率自体に正解はありません。各章を変える理由と変えない理由を明示し、必要のない全面置換を避けることが、この表の目的です。

評価されている固有部分を残す

keepと判定する根拠は「よく書けているから」だけでなく、可能な範囲で検証できる事実に置きます。

その章の見出しがアンカーとして外部から参照されている、または被リンクを受けている
自分で測った、撮った、試した結果が載っている（他所から持って来られない情報）
その章を目当てにしたqueryで表示回数を得ている
refresh brief の「維持する強み」に書き出してある

Google検索セントラルは自己評価の質問として、originalな情報・report・調査・分析、明らかな内容を超える洞察、他のsourceを書き換えただけではない付加価値を挙げています。固有部分は読者価値の候補なので、順位低下だけを理由に機械的に削らず、正確性と有用性を再確認します。

deleteの判定は慎重に扱います。その章が担っていた疑問が今も対象読者に必要なら、記事内の別sectionか適切な別記事で代替し、必要に応じて内部linkを残します。一方、product終了などで疑問自体が不要になった場合は、無理に代替先を作る必要はありません。削除理由と、link・目次・まとめ・構造化dataへの影響を判定表へ記録します。

AI下書きを差分で編集する

一次情報と確認日を付ける

AIに渡す依頼は「リライトして」ではなく「章ごとの変更提案を出して」です。次のプロンプトはそのまま使えます。

あなたは公開済み記事の更新担当です。以下の3点を読み、
章ごとの変更提案だけを出力してください。全文の書き直しはしないでください。

【1】refresh brief（変えないもの・維持する強み・更新する範囲）
（ここに貼り付け）

【2】現在の記事本文（見出しごとに章番号を振ったもの）
（ここに貼り付け）

【3】更新の根拠にできる一次情報（URL・該当箇所・確認日）
（ここに貼り付け）

【ルール】
- 【1】の「変えないもの」に該当する項目は、変更提案の対象にしない
- 【1】の「維持する強み」に挙がった章は原則keep。
  一次情報との矛盾や安全上の問題を見つけた場合は、変更せずblockerとして報告する
- 各章の判定は keep / update / delete のいずれか1つだけ
- updateは、置き換える前の文と置き換え後の文を必ず対にして書く
- 【3】に無い事実を新しく書かない。根拠が足りない章はneeds_source=yesとする
- deleteを提案する章は、その章が担っていた読者の疑問が
  今も必要かを判定し、必要なら代替先を書く
- title・H1・URLの変更は提案しない

【出力】章番号順に、次の列を持つ表で出力する
章番号, 見出し, 判定, 理由, 変更前, 変更後, 根拠URL, 確認日,
代替先, needs_source(yes/no), blocker

「変更前」を書かせるのは、適用対象を確認するためです。元文を完全一致だけで置換すると、同じ文が複数ある場合や空白・HTMLの差で誤適用し得ます。章ID、見出し、前後の文脈と合わせて一意に特定し、version管理上のdiffを人がreviewしてから反映します。存在しない文が「変更前」に入っていたら、その提案を採用せず、他の行も原文との対応を再確認します。

needs_source=yesやblockerが出た章は、自動適用せず人が一次情報を探します。根拠URLが書かれていても、そのpageが実在するか、該当記述があるか、対象version・地域・日付が合うかを確認します。更新した事実にはsourceと確認日を編集記録へ残し、読者に必要なものは本文または記事末にも示します。事実確認そのものの手順は「AIのファクトチェック手順」で扱っています。

title・H1・URL変更を慎重に扱う

変更の影響範囲は要素ごとに大きく違います。軽いものから順に扱ってください。

本文の差分：対象sectionと関連する目次・summary・構造化data・内部linkも確認する
H2・H3の文言：見出しのidも変える実装ではfragment linkが切れる可能性がある。参照されているanchor IDは維持するかredirect相当の案内を用意する
<title>：検索結果のtitle linkを改善する手掛かりだが、GoogleはH1、on-page text、anchor textなど複数sourceから自動生成する。変更後に実際の表示を確認する
H1：主題と視覚上のmain titleを示す重要な要素。中心意図を保つ範囲の明確化と、別意図への変更を分ける
URL：内部link、被link、canonical、redirect、計測の継続性へ影響する。差分更新では維持を基本とし、変更時はsite migrationとして扱う

原因を観察しやすくするには、可能な範囲で変更を小さく分け、公開日時と内容を記録します。ただし、誤情報の訂正と安全上の修正を測定のために遅らせてはいけません。また、titleだけを後から変えても、外部要因が動く通常の検索環境ではCTR変化の因果を断定できません。大規模siteで因果を測る場合は、比較可能なURL群を使ったSEO testの設計が別途必要です。

更新日の扱いにも注意が必要です。Google検索セントラルは自己評価の警告signとして、内容が大きく変わっていないのに新しく見せるため日付を変えていないかを挙げています。日付変更そのものを一律に禁止しているのではなく、見かけのfreshnessを作る操作を避けるという趣旨です。読者に影響する実質的な修正があれば、正確な更新日と変更内容を示します。表記修正だけなら、公開上の日付を動かさず編集logだけに残す判断もできます。

更新後の影響を測る

変更内容・公開日・確認日を記録する

更新の記録がないと、次に数字が動いたときに原因を特定できません。記事ごとに1レコードを残します。

- refresh_id:      rf-2026-07-28-03
  target_url:      /blog/csv-import-basics/
  deployed_at:     2026-07-28T11:20+09:00
  primary_kw:      CSV インポート     # 変更していないことの記録
  url_changed:     false
  h1_changed:      false
  title_changed:   false
  public_date_modified_changed: true
  sections:
    - id: 2
      heading:    対応形式と上限
      decision:   update
      before:     上限は50MBです
      after:      上限は200MBです
      source:     https://example.com/docs/limits
      checked_at: 2026-07-28
    - id: 4
      heading:    旧バージョンの手順
      decision:   delete
      reason:     v2の提供終了。第6章の現行手順で代替
    - id: 3
      heading:    エラー画面の対応表
      decision:   keep
      reason:     被リンクの参照先。独自の実測データ
  baseline_period: 2026-06-29..2026-07-26   # 更新前28日
  first_review_on:  2026-08-25               # 最初の観察日。固定の合格期限ではない
  gsc_filters:
    search_type: web
    country: all
    device: all
    data_state: final
  external_notes:
    - 2026-08-10 Google ranking update
  reviewer:        編集担当の識別子

url_changed・h1_changed・title_changedをfalseでも記録するのは、変更scopeを再現するためです。とはいえ、検索performanceには競合、需要、SERP、ranking update、sitewide変更も影響するため、「変えていない」だけで原因候補から完全に外せるわけではありません。keepと判定した章も理由付きで残し、次回は正確性を再点検してください。

少数の重要URLで早めの再処理を希望する場合は、URL検査toolから再クロールを依頼できます。これは更新後の必須操作ではなく、CMSや通常のcrawlでも変更は発見されます。個別URLの依頼にはquotaがあり、同じURLへ繰り返し依頼しても速くなりません。crawlには数日から数週間かかる場合があり、indexingや検索結果への反映も保証されません。多数のURLでは、正確なlastmodを含むsitemapと内部linkを整備します。

query・CTR・順位を同条件で比較する

効果の観察は、更新前に決めたfirst_review_on以降、再crawl・再処理され、十分な表示回数が溜まった段階で行います。前後比較の条件は可能な限り揃えます。

検索タイプを「ウェブ」に固定する
期間の長さと曜日構成を揃える。季節性があれば前年同期も併記する
国・デバイスで絞る場合は、前後で同じ条件にする
対象URLでフィルタし、クエリタブでquery別に見る
「差」の列で並べ替え、増えたqueryと減ったqueryを両方書き出す

見るべきは全体指標だけでなく、変更仮説に対応するsegmentです。よくある質問に2問足したなら、そのquery群の表示回数、クリック数、CTR、掲載pageを確認します。ただし、Search Consoleはすべてのqueryを表示せず、少ない母数の増減はぶれます。「増えたから変更が効いた」と即断せず、母数、前年同期、外部notes、未変更の比較pageも合わせて読みます。

減ったqueryの確認も重要です。deleteした章に対応するqueryが減っても、需要減少や匿名化の影響があり、削除だけが原因とは限りません。一方、読者が必要とする疑問を取りこぼした可能性があれば、代替sectionや内部linkを見直します。判定できなければ、誤情報を残さない範囲で観察期間を延ばし、新しい変更は別のrefresh IDとして記録します。評価結果にも、通常の前後比較は因果を証明しないことを記載します。AI検索側での引用のされ方まで含めた見え方については「AI検索時代のSEO」で扱っています。

よくある失敗

AIに全文を書き直させる

「この記事をリライトして」と目的や保持条件なしで全文を渡すと、実測データ・独自の手順・他にない図解まで一般化されることがあります。全面改稿が必要でも、keepするfact・例・assetを先に固定し、章単位のdiffでreviewしてください。機密情報や個人情報を外部serviceへ渡せるかも事前に確認します。

更新の実体がないのに日付だけ新しくする

Googleの自己評価では、内容が大きく変わっていないのに新しく見せるため日付を変えていないかが警告signとして挙げられています。日付だけを動かして更新の代わりにしないでください。意味のある更新がなければ、公開上の日付は維持し、点検した事実だけを内部logへ残します。

再公開直後に効果を判定する

crawlには数日から数週間かかることがあり、再クロールを繰り返し依頼しても速くはなりません。観察開始日は固定の4週間ruleではなく、再処理の確認、通常の表示回数、季節性、更新の緊急度で決めます。短期dataだけで次のSEO変更を重ねず、必要な訂正は測定を待たずに行います。

よくある質問

リライトと別記事化はどこで線を引きますか？

中心意図と読了後行動が同じなら差分更新に向き、大きく変わるなら通常のrefreshを止めて情報設計を見直します。ただし、別記事化が常に正解ではありません。既存URLの再設計、記事統合、新規記事のいずれが重複を増やさず読者に分かりやすいかを判断し、必要ならredirect・canonical・内部linkまで計画します。

リライトで文字数は増やしたほうがよいですか？

文字数そのものを目標にしないでください。Google検索セントラルは、Googleが好む特定の文字数があるという考えを否定し、siteをfreshに見せることなどを主目的とした大量の追加・削除を警告signとして挙げています。必要な疑問へ十分に答えた結果として、長くなる場合も短くなる場合もあります。

順位が下がった章から削っていけばよいですか？

Search Consoleは通常、見出し単位の順位を提供しません。queryとpageのdataだけで特定の章の価値を断定せず、読者行動、内部・外部link、内容の正確性も確認します。疑問が今も必要なら代替先を用意し、product終了などで不要なら理由を記録して削除します。

平均掲載順位が変わらなければ効果はなかったということですか？

いいえ。平均掲載順位は集計方法に注意が必要で、property集計では同一propertyの最上位結果が使われます。query・page別の表示回数、クリック数、CTR、掲載pageを確認し、dataの匿名化・truncationと外部要因も併記してください。

まとめ

SEO記事のrefreshでは、先に変える範囲と守る固有情報を決め、章単位でkeep・update・deleteを判定します。中心意図まで変わる場合は差分更新を止め、新規記事、統合、既存URLの再設計を別途判断します。Search Consoleの数値だけで原因を断定せず、indexing、需要、季節性、SERP、sitewide要因も確認してください。

AIに任せるのは根拠付き差分の提案までです。変更前、変更後、理由、source、確認日を対にし、原文の位置と一次情報を人が照合してから反映します。実質的な更新がないのに新しく見せるため日付だけを変える運用は避け、正確な公開情報と編集logを保ちます。

更新後は再crawl・再処理と十分な母数を待ち、同じ条件の期間、前年同期、外部notes、比較pageを使って観察します。前後比較だけで因果は証明できないため、結論の確度も記録してください。下書きの作成そのものを支援するツールを検討する場合は「AIライティングツールの比較」が選択肢の整理に使えます。