Geminiで記事をリライトするプロンプト集｜SEO・AIO監査の手順

Geminiへ『この記事をSEO向けに改善して』と頼むと、読みやすくなっても、狙っていた読者や問い合わせ導線まで薄まることがあります。記事改善で必要なのは長い万能プロンプトではなく、診断、構成、追記、検証を分け、各段階で人が採否を決めることです。本記事では、そのまま貼れるプロンプトと、入力資料、確認表、失敗時の戻し方をセットで示します。

先に使い方

元記事を一度に書き換えさせず、検索意図の診断 → 不足論点 → 見出し案 → 範囲指定の追記 → 事実確認の順に分けます。公開中の本文は保存し、採用した変更と理由を記録します。

公開：2026年6月4日　最終リライト：2026年9月10日

Gemini記事改善プロンプトで最初に渡す情報
診断だけを依頼するプロンプト
見出し構成を直すプロンプト
H2単位で本文を補うプロンプト
比較表と手順を作るプロンプト
検索データを渡してリライトする方法
Geminiの出力を人が確認する項目
うまくいかないプロンプトと直し方
公開後に見る指標
改善前と改善後のプロンプトを比較する
1. そのまま使える差分診断プロンプト
魚見の実務フロー：Search Consoleから直すH2を決める
Geminiの記事改善は「監査・修正・検証」を分ける
最初にGeminiへ渡す情報
記事全体を監査するGeminiプロンプト
見出し構成だけを改善するプロンプト
本文をH2単位でリライトするプロンプト
SEOタイトルとdescriptionを改善するプロンプト
AIO・LLMO観点を監査するプロンプト
事実確認と最新情報の確認プロンプト
Search Consoleデータから改善優先度を決めるプロンプト
競合との差分を確認するプロンプト
公開前の最終監査プロンプト
Geminiで記事改善するときの失敗例
魚見の実務フロー：1記事ずつ合格させる
プロンプトの出力形式を固定する理由
まとめ
よくある質問
参照した一次情報

Gemini記事改善プロンプトで最初に渡す情報

Googleの公式ガイドでは、効果的な指示の要素として役割、タスク、文脈、形式が挙げられています。記事改善では、これに『変えてはいけないもの』と『根拠の扱い』を加えます。キーワードだけでは、読者の検討段階や記事の役割を判断できないためです。

入力項目	渡す内容	目的
読者	立場、経験、検討段階	説明の深さを合わせる
検索課題	記事を開いた直前の疑問	冒頭と構成を具体化する
記事の役割	定義、比較、導入、事例など	論点の混在を防ぐ
一次情報	公式URL、調査日、引用可能範囲	架空の根拠を防ぐ
自社情報	経験、実数、対象条件	固有価値を残す
制約	残す表現、禁止表現、文字数	ブランドと事実を守る
出力形式	表、見出し、修正理由	レビューしやすくする

診断だけを依頼するプロンプト

最初は書き換えを許可せず、問題の特定だけを依頼します。次のプロンプトへ本文、タイトル、想定読者、Search Consoleのクエリを付けます。

プロンプト例
あなたはWeb編集者です。本文を書き換えずに診断してください。想定読者は［読者］、記事の役割は［役割］、主な検索課題は［課題］です。各H2について、直接回答、判断材料、具体例、根拠、次の行動の有無を表にしてください。重複する見出しと、読者段階がずれる見出しも指摘してください。指摘には該当箇所を短く示し、推測で情報を補わないでください。

見出し構成を直すプロンプト

診断結果を確認した後、採用する問題だけを指定します。上位ページの見出しをコピーさせるのではなく、読者の判断順を作らせます。

プロンプト例
次の問題だけを解消するH2案を作ってください：［採用した問題］。読者が『理解→比較→実行→失敗回避』の順に判断できる構成にします。既存の固有事例［残す内容］は残してください。H2は10本以内、似た意味は統合し、各H2に答える読者の問いと必要な根拠を1行で添えてください。本文はまだ書かないでください。

H2単位で本文を補うプロンプト

記事全体の一括生成はページ間の類似性を高めやすく、誤りの確認範囲も広がります。最も弱いH2を一つずつ直します。

プロンプト例
H2［見出し］だけを改善してください。冒頭1〜2文で問いへ答え、その後に理由、実務例、判断基準、注意点を続けます。参照できる根拠は［資料］だけです。資料にない数字や仕様は作らず『確認が必要』と記載してください。既存文のうち［残す固有情報］は保持し、変更前後と変更理由を分けて出してください。

比較表と手順を作るプロンプト

比較記事では軸が曖昧な表、導入記事では動詞のない手順が生成されやすくなります。表は選択に使う軸、手順は完了条件まで指定します。

用途	追加する指示
比較表	比較対象、判断軸、向く条件、注意点、根拠を列にする
導入手順	担当者、入力、作業、完了条件、失敗時の戻し方を含める
チェックリスト	実行前にYes/Noで確認できる表現にする
FAQ	本文で答えていない導入直前の疑問だけを選ぶ

検索データを渡してリライトする方法

Search Consoleのクエリを渡す場合、個人情報や不要なURLを除きます。表示回数が多く順位が低い語は本文の不足、順位が高くCTRが低い語はタイトル・説明・検索結果の競合、クリック後のCVが低い語は記事と導線の不一致を疑います。すべて本文へ詰め込まず、既存記事とのカニバリも確認します。

対象URLと比較期間を決める
クエリを意図別にまとめる
記事の主役にする意図を一つ選ぶ
Geminiへ意図と現行見出しの対応だけを診断させる
不足する判断材料を一つずつ追加する
タイトル、本文、内部リンクを別々に確認する
公開日と変更点を記録して再計測する

Geminiの出力を人が確認する項目

公開判断の確認表

冒頭が具体的な読者課題から始まる
一次情報にない数字を追加していない
既存の経験・事例を消していない
各H2が別の判断を助ける
H3が言い換えだけになっていない
内部リンクの遷移先が文脈と一致する
FAQが本文の繰り返しではない
料金・仕様・日付を公式情報で再確認した
スマートフォンで表と文章が読める
変更後に順位・CTR・CVを測れる

うまくいかないプロンプトと直し方

依頼	起きやすい問題	直し方
SEOに強くして	一般論と関連語が増える	読者、役割、欠けている判断を指定
競合より詳しく	見出し順をなぞる	読者の判断順と独自資料を指定
全部書き直して	固有情報が消える	H2単位で残す情報を指定
FAQを増やして	本文と重複する	未回答の導入直前質問だけを抽出
最新情報を入れて	出典のない仕様が混ざる	参照URLと確認日を限定

公開後に見る指標

変更の効果は文字量では判断しません。検索意図が合ったかはクエリ別の表示回数・順位・CTR、読み進められたかはスクロールや内部リンク、成果につながったかはCTAクリック・フォーム開始・CVで見ます。AI検索を狙う場合も、引用の有無だけでなく引用元ページへの流入と問い合わせを分けて記録します。

改善前と改善後のプロンプトを比較する

記事改善では、指示を長くするより、判断材料と出力範囲を明確にします。次の例では、同じ記事を対象にしても確認しやすさが変わります。

指示	起きやすい出力	改善方法
この記事をSEO向けに改善して	全文が一般論へ書き換わり、変更理由が分からない	診断だけを先に出させる
競合より詳しくして	見出し数と文字数だけが増える	不足する判断材料を質問単位で列挙させる
FAQを10問追加して	本文と同じ回答が重複する	本文で未回答の導入前疑問だけに限定する
専門性を追加して	根拠のない経験談や断定が混ざる	使用できる実績、一次情報、執筆者の経歴を指定する

そのまま使える差分診断プロンプト

あなたはSEO編集者です。本文の書き換えはまだ行わず、次だけを表で返してください。
1. 主な読者が記事を開く直前に抱えている疑問
2. 現在の本文で直接回答できている疑問
3. 回答が不足している疑問
4. 根拠または一次情報が必要な主張
5. 削除した方がよい重複・一般論
6. 問い合わせ前の判断に必要な費用、手順、失敗例
各指摘には対象見出しと修正理由を付けてください。新しい文章は作成しないでください。

魚見の実務フロー：Search Consoleから直すH2を決める

リライト対象は、文章を読んだ印象だけで決めません。表示回数が増えているのに順位が低いクエリ、順位が高いのにCTRが低いクエリ、流入後にCVへ進まないページを分けます。Geminiにはクエリ、表示回数、クリック、順位、対象URL、現在の見出しを渡し、『どの検索段階が不足しているか』を診断させます。

Search Consoleから直近28日と前期間のクエリ・ページを出す
ブランド名や無関係なクエリを除き、表示増・CTR低下・順位停滞へ分類する
Geminiへ数値と現在のH2だけを渡し、不足する問いを出させる
H2一つだけを追記し、変更日と仮説を記録する
再クロール後、同じクエリ群の順位、CTR、CV導線を比較する

当サイトの運用でも、FAQや定義文を一律に増やすのではなく、検索クエリとページの役割を見て修正範囲を絞ります。AIの出力を完成稿として扱わず、編集判断を速める材料として使うことが、ページ間の類似化を防ぐポイントです。

Geminiの記事改善は「監査・修正・検証」を分ける

記事全文を貼り「SEOに強くリライトして」と頼むだけでは、検索意図、一次情報、既存順位、内部リンク、表現の重複を確認しないまま文章量だけが増えます。Geminiには、まず問題点と根拠を出させ、次に承認した範囲だけ直し、最後に修正後を再監査させます。

工程	Geminiの役割	人が確認すること
監査	検索意図、構成、根拠、読みやすさの不足を抽出	対策KW、読者、事業目的が正しいか
設計	残す・移動・統合・追加を提案	重複記事とカニバリを起こさないか
修正	指定範囲の本文・表・FAQを作成	事実、独自情報、トーン、著作権
検証	要件との差分と未解決点を再確認	公開表示、リンク、計測、検索成果

最初にGeminiへ渡す情報

対策キーワードは1記事1つを主軸にする
想定読者と解決したい課題
現在の記事本文、title、description、URL
Search Consoleのクエリ、表示回数、CTR、順位
競合記事の見出しと不足している論点
自社の一次情報、検証データ、事例
内部リンク候補とCTA
変更してはいけない事実・表現・構造

情報がない場合は、Geminiに推測で埋めさせず「不明」と記載させます。最新情報が必要ならGoogle検索によるGroundingを利用し、公式情報と確認日を付けます。

記事全体を監査するGeminiプロンプト

あなたはSEO・AIO・編集の監査担当です。次の記事をまだ書き換えずに監査してください。

【主キーワード】{1つ}
【読者】{役職・知識・状況}
【目的】{読後にできるようになること}
【検索データ】{クエリ・表示・CTR・順位}
【一次情報】{自社検証・事例・数値}
【本文】
---
{記事全文}
---

次の順で出力してください。
1. 検索意図を「知りたい・比較したい・実行したい」に分類
2. 残す見出し、移動する見出し、統合する見出し、追加する見出し
3. 事実確認が必要な箇所と確認すべき一次情報
4. 結論が遅い箇所、重複、抽象表現、読みにくい長文
5. AI回答に引用されやすい定義・表・手順・FAQの不足
6. 内部リンクを置く文脈とリンク先候補
7. 優先度（高・中・低）と修正理由

推測で事実を追加せず、不明は「要確認」としてください。

見出し構成だけを改善するプロンプト

上の監査結果を基に、本文は書かずH2・H3構成だけを再設計してください。

条件：
- 冒頭直後に結論と比較表を置く
- 基礎→選び方→手順→失敗→事例→FAQの自然な順番
- H2だけで記事の論理が分かる
- H3はH2の問いへ直接答える
- 同じ意味の見出しを重複させない
- 主キーワードを不自然に繰り返さない
- 各見出しに「読者の疑問」「使う一次情報」「推奨形式（文章・表・手順）」を付ける
- 既存記事と重複する論点は内部リンクへ分離する

本文をH2単位でリライトするプロンプト

承認した構成のうち、次のH2だけをリライトしてください。

【H2】{見出し}
【結論】{最初に伝える答え}
【根拠】{公式情報・自社データ・実務経験}
【禁止】存在しない数値、架空事例、未確認の断定、競合本文の模倣
【文体】簡潔な敬体。1文60字を目安。結論→理由→具体例→注意点
【形式】必要な場合だけ表または番号手順を使う
【内部リンク】{文脈とURL}

出力後に、追加した事実と根拠、要確認点、元文から削除した内容を一覧にしてください。

記事全体を一度に生成するより、H2単位で確認した方が論点の重複と事実誤認を抑えられます。長いコンテキストを渡す場合は、Google公式の推奨どおり資料を先に置き、最後に質問と出力条件を置きます。

SEOタイトルとdescriptionを改善するプロンプト

検索結果でのクリック改善案を作ってください。

【主キーワード】{1つ}
【現在title】{title}
【現在description】{description}
【平均順位・表示・CTR】{数値}
【記事の独自価値】{検証・比較・資格・一次情報}

titleを5案、descriptionを3案作成してください。
各案に、主キーワード、具体性、差別化、誇大表現の有無、想定文字数を付けてください。
記事本文にない実績・数字・「No.1」「必ず」などは使わないでください。

AIO・LLMO観点を監査するプロンプト

AIO・LLMOでは、キーワードを増やすより、問いに直接答える定義、条件付きの結論、比較軸、一次情報、更新日、著者情報を明確にします。AIに引用される保証はないため、引用可能な情報単位を整え、検索とユーザー行動で検証します。

この記事をAI回答で参照しやすい情報構造の観点から監査してください。

1. 40〜120字で直接答えられる定義があるか
2. 条件・例外・対象外が明記されているか
3. 比較表の軸と結論が一致するか
4. 手順に入力・判断・出力・確認があるか
5. 数値に期間・母数・測定方法・出典があるか
6. 著者・監修者・更新日・一次情報が明確か
7. FAQが本文の重複ではなく残る疑問へ答えるか

各項目を0〜2点で採点し、修正案を示してください。引用されると断定しないでください。

事実確認と最新情報の確認プロンプト

記事中の時点依存情報だけを抽出してください。
対象：料金、機能、モデル名、法令、統計、会社情報、提供地域、日付。

各項目について、
- 記事の記述
- 正誤を確認する一次情報
- 確認日
- 正しい表現
- 断定を弱める必要性
を表で出してください。

Google検索を使える場合も、公式サイト・公的機関を優先し、検索スニペットだけで確定しないでください。

Search Consoleデータから改善優先度を決めるプロンプト

状態	優先施策	見る場所
順位高・CTR低	title、description、検索意図の一致	クエリ別CTR
表示増・順位低	内容、内部リンク、一次情報を強化	クエリとページ
順位下落	競合差分、鮮度、カニバリを確認	期間比較
表示なし	インデックス、需要、役割を確認	URL検査とサイト構造

次のSearch Consoleデータを、ページ×クエリ単位で分析してください。
【期間A】{クリック・表示・CTR・順位}
【期間B】{比較期間}

CTR改善、順位改善、統合・分離、維持観測の4群に分類してください。
各URLへ主キーワードを1つ割り当て、重複候補を示してください。
表示回数だけで需要を断定せず、データ期間と変化率を明記してください。

競合との差分を確認するプロンプト

競合記事の文字数や見出しをそのままコピーするのではなく、検索意図の回収範囲、比較軸、根拠、使いやすい表、更新性を比較します。自社記事の独自価値がない部分は、一次検証や運用データで補います。

比較軸	確認内容
意図	基礎、比較、手順、トラブルのどこまで答えるか
具体性	画面、手順、料金、条件、失敗例があるか
根拠	公式情報、検証日、母数、著者経験があるか
回遊	関連記事へ自然に深掘りできるか
可読性	結論、表、箇条書き、スマホ表示が読みやすいか

公開前の最終監査プロンプト

修正後の記事を公開前監査してください。

A. 検索意図：結論、網羅性、主KWと見出し
B. 事実：出典、日付、数値、誇大表現
C. 独自性：検証、経験、判断基準
D. 構造：H1は1つ、H2/H3順序、表、FAQ
E. UX：冒頭、長文、重複、スマホ横幅
F. 内部SEO：内部リンク、アンカー、旧URL、canonical
G. CV：CTAの文脈、広告・PR表記

各項目を「合格／要修正」で判定し、要修正は該当箇所と置換案を出してください。
確認できない表示・リンク・計測は、合格にせず「実機確認」としてください。

Geminiで記事改善するときの失敗例

失敗	なぜ起きるか	修正
文章量だけ増える	目的と不足項目が曖昧	監査後にH2単位で修正
数値を作る	根拠不足でも補完する	不明は要確認、一次情報を指定
競合と似る	全文を模倣させる	比較軸だけ抽出し独自データで補う
構成が不自然	追記を末尾へ積む	残す・移動・統合・追加を先に設計
公開後に崩れる	文章監査だけで終了	PC/SP、表、画像、リンクを実機確認

魚見の実務フロー：1記事ずつ合格させる

当サイトの改善では、複数記事を一括で書き換えず、元記事を保存し、候補HTMLを作り、文字数・見出し・表・FAQ・内部リンク・監修枠を機械確認してから公開します。その後、PCとスマートフォンで横はみ出し、画像切れ、見出し順を確認します。

AIの出力品質だけでなく、戻し方と検証結果を残すことで再現性が上がります。プロンプトは完成品ではなく、評価結果に合わせて更新する運用資産です。

プロンプトの出力形式を固定する理由

毎回異なる順番で提案が返ると、修正の優先度や未確認事項を比較できません。監査結果は「該当箇所・問題・根拠・修正案・優先度」の5列、本文案は「変更前・変更後・変更理由・要確認」の4列など、用途ごとに形式を固定します。

出力	固定する項目	利点
監査	場所、問題、根拠、案、優先度	重大項目から処理できる
構成	H2/H3、疑問、根拠、形式	見出しの役割を確認できる
本文	変更前後、理由、出典	差分レビューしやすい
最終確認	合格、要修正、実機確認	未確認を合格扱いしない

Geminiの回答をそのまま公開せず、修正案の採否を記録します。採用しなかった理由も残すと、次回プロンプトで同じ不要提案が繰り返されるのを防げます。記事更新後は、順位だけでなくCTR、回遊、問い合わせ、表示崩れを確認し、プロンプト改善へ戻します。公開日と最終確認者も必ず毎回正式な社内記録として残してください。