AI×MCPでSEO記事を効率リライトする方法【Claude Code/Codex対応】

既存記事のリライト、AIに任せたいけど結局スプシでデータ集めて毎回プロンプトを書き直していませんか。本記事では、Claude CodeとCodex CLIにGSC・Ahrefs・GA4のMCPを連携して、リライト候補抽出から効果測定まで一気通貫で回す5ステップワークフローを公開します。記事末尾でClaude Code / Codex CLI 2環境対応のプロンプトパッケージも無料配布。

「AIにリライトさせたら順位が落ちた」「AIで時短したいのに結局自分で全部書き直してる」。実務でAIリライトを使う担当者なら一度はぶつかる壁ではないでしょうか。そもそもリライトは順位下落リスクを抱えた施策で、データを見ずにAI任せでやれば失敗する確率がさらに上がります。

筆者はインハウスでSEO担当を2年務め、数万ページ規模のDB型サイトでAIを使った記事制作・リライトを大量に回してきました。コアアップデートでトラフィックが半減したサイトを8ヶ月で回復させ、その後アップデート前の約2.1倍のアクセスまで戻した経験があります。その過程で痛感したのは、AIリライトの成果は「プロンプトの質」よりも「AIに渡すデータの質」で決まるということ。GSCの順位データ、GA4のエンゲージメント、Ahrefsの競合分析、これらをAIに統合的に読ませて初めて、人間が手作業でやるよりも精度が高くて速いリライトが回せるようになります。

本記事ではそのワークフロー全体を、実際にinSiteブログの2記事で動かした実プロンプトと前後データ付きで解説します。

AIリライトのワークフロー全体像

本記事のワークフローは、リライト候補抽出から効果測定まで5ステップに分かれています。ChatGPTに記事を貼り付けて「リライトして」と頼むだけのスタイルではなく、データ取得から効果測定までを一連の流れで回す実運用ワークフローです。

なぜ5ステップに分けるのか

「AIに記事を貼り付けてリライトして」と頼む方法は最も手軽ですが、実務では3つの問題が起きます。

5ステップに分けると、それぞれの段階でユーザーが内容を確認・修正できます。AIが各ステップに集中できるので出力の品質も安定します。

5ステップの全体構成

MCP連携で得られる3つのメリット

5ステップを「AIにすべての元データを直接読ませる」ためにMCP（Model Context Protocol）を使います。MCPは生成AIに各種APIを共通プロトコルで繋ぐ仕組みで、Claude CodeやCodex CLIに公式対応しています。

「MCPの設定がちょっと面倒だな」と感じる方もいると思いますが、一度組んでしまえば以後すべての記事で再利用できます。具体的なツール選びとMCP環境の組み方は次章以降で解説します。

リライトに使える主要AIツールと選び方

AIリライトに使えるツールは大きく分けて「CLI型」と「Web型」の2種類です。本記事のワークフローを最大限活かすにはCLI型（Claude Code / Codex CLI）が圧倒的に有利ですが、Web型でも単発プロンプトとして使えます。

CLI型 vs Web型の比較表

Claude Codeを推奨する理由

本記事のワークフローを回すならClaude Codeが最適です。理由は3つあります。

「Claude Codeはターミナル使うから難しそう」と感じる方もいるかもしれませんが、最近は対話形式で動くため、Pythonコードを書く感覚は不要です。AIにファイルを操作させる権限を渡すだけで、後はチャットで指示を出していけます。

Codex CLIも同等に使える

OpenAI派のチームにはCodex CLIがおすすめです。OpenAIが公式提供する開発者向けCLIで、2025年からMCP対応しており、Claude Codeとほぼ同じ .mcp.json 形式で設定できます。Anthropicに依存したくない場合や、ChatGPT Plusをすでに契約している場合は、Codex CLIを選ぶと同じワークフローが回せます。

MCP環境構築（Claude Code / Codex CLI）

本記事のワークフローを動かすには、Claude CodeまたはCodex CLIに3つのMCPサーバー（GSC・Ahrefs・GA4）を連携する必要があります。各MCPの個別セットアップは別記事で解説しているため、ここでは「3つを統合した完成形の .mcp.json 」と起動確認の手順を共有します。

統合版 .mcp.json のサンプル

3つのMCPを同時に有効化する設定ファイルの例です。プロジェクトのルートに配置すれば、Claude CodeとCodex CLIで共通利用できます。

{
  "mcpServers": {
    "gsc": {
      "command": "npx",
      "args": ["-y", "@ahonn/mcp-server-gsc"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/your-service-account.json"
      }
    },
    "ahrefs": {
      "command": "npx",
      "args": ["-y", "@ahrefs/mcp-server"],
      "env": {
        "AHREFS_API_TOKEN": "your-ahrefs-api-token"
      }
    },
    "google-analytics": {
      "command": "ga4-mcp-server",
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/your-service-account.json",
        "GA4_PROPERTY_ID": "123456789"
      }
    }
  }
}

サービスアカウントJSONファイルのパス、Ahrefs APIトークン、GA4プロパティIDをご自身の環境に合わせて書き換えてください。なお、Ahrefs MCPはAhrefsの有料契約が必要です。契約していない場合はGSCとGA4の2つだけでも本ワークフローの大半は動きます（後述のSTEP2が「基本版」モードで動作）。

各MCPのセットアップ詳細

サービスアカウントの取得や権限付与など、各MCPの個別セットアップ手順は別記事で詳しく解説しています。

Claude Codeでの起動確認

.mcp.json を配置したプロジェクトでClaude Codeを起動すると、初回のみMCPサーバーの利用許可を求められます。すべて承認すると、AIへの最初の問いかけで以下のように確認できます。

利用可能なMCPツールを一覧表示してください。

GSC・Ahrefs・GA4の3カテゴリのツールが表示されれば、環境構築は完了です。

Codex CLIでの起動確認

Codex CLIはClaude Codeとほぼ同じ .mcp.json 形式に対応しています。設定ファイルを配置後、Codex CLIを起動して同様に「MCPツール一覧を表示」と頼めば確認できます。詳細なオプション差分はOpenAIの公式ドキュメントを参照してください。

詰まったらまずClaude Code/Codexに聞く

セットアップ中に環境変数のエラーや権限エラーで詰まることがあります。そんなときはまず、Claude Code/Codex本人にエラー内容をそのまま貼って質問するのが最速です。各CLIはターミナル操作とMCP仕様を理解した状態で動いているため、原因の特定から修正コマンドの提示までを一気に進めてくれます。

「公式ドキュメントを読み込ませた上で原因を分析して」「ログを確認して修正手順を提案して」のように依頼すれば、設定ファイルの直接編集まで対話だけで完結します。MCPは新しい規格なのでネット記事より公式情報のほうが確実で、CLIから直接公式ドキュメントを参照させるほうがブラウザで調べるより早いケースも多いです。

これで5ステップを動かす環境が整いました。ここからは、各ステップで実際に使うプロンプトを順番に解説します。

AIリライト5ステップのプロンプトパッケージを無料配布

ここまで紹介した5ステップのプロンプトと、関連するナレッジファイル・MCP設定サンプルを1つのパッケージにまとめて無料配布しています。本パッケージはMCP連携が必須のため、対応環境はClaude CodeとCodex CLIの2環境です。メールアドレスをご登録いただくと、ZIPファイルへのダウンロードリンクをお送りします。

※ご登録いただいたメールアドレスは、本パッケージの配布とinSiteからのお知らせ以外には使用しません。

パッケージの中身

エンジニア経験がなくても10〜15分でセットアップ完了できる設計です。

AIリライトを実行する5ステップのプロンプト解説

ここからは、5ステップで実際に使うプロンプトと、各ステップで押さえるべきポイントを順番に解説します。配布パッケージにはこれらのプロンプトの完全版が同梱されているので、内容を理解してから利用するとカスタマイズしやすくなります。

【STEP 1】リライト候補の自動抽出（GSC × GA4 複合分析）

最初のステップは「どの記事をリライトするか」をデータで自動抽出することです。感覚で「順位が落ちた気がする記事」を選ぶのではなく、定量条件で機械的に候補を出すことで、工数の無駄を排除できます。

このステップの目的

GSCの順位データとGA4のエンゲージメント指標を横断して、リライト優先度の高いページを抽出します。順位だけ見ると「順位は良いがCTRや滞在時間が悪い記事」を見落とすため、必ず両方のデータソースを使います。

プロンプト本体（要点）

あなたはSEOリライトの専門家として、データドリブンにリライト候補を抽出します。
GSC MCPとGA4 MCPを使って、対象サイトのリライト候補を優先度付きで抽出してください。

【ユーザー入力（実行前に確認）】
- 対象GSCサイトURL（例: sc-domain:example.com）
- 対象GA4プロパティID
- 分析期間（デフォルト直近90日）

【手順】
1. GSC MCPで以下を取得
   - detect_quick_wins (positionRangeMin=4, positionRangeMax=30, minImpressions=100, maxCtr=3)
   - enhanced_search_analytics (dimensions=page, rowLimit=100)

2. GA4 MCPで対象ページパスのscreenPageViews / sessions / averageSessionDuration / engagementRate を取得

3. 以下のスコアリングで優先度を判定
   - A（最優先）: 順位11-30位 かつ impression>200 かつ engagementRate>40%
   - B（高）: 順位4-10位 かつ CTRが順位平均より20%以上低い
   - C（中）: 順位1-10位 かつ engagementRate<30% かつ averageSessionDuration<60秒
   - D（低）: 順位31位以下 で impression>100

4. 上位10ページをマトリクス表で出力（URL/メインクエリ/順位/imp/CTR/PV/滞在/エンゲージ/優先度/方針仮説）

5. 優先度A・Bの上位3ページを推奨ターゲットとして提示

【重要】MCPコール前に取得計画を共有し、ユーザー承認を得てから実行

このプロンプトのポイント

「順位だけが良い」「滞在時間だけが良い」など片方の指標だけでは見落とされる記事を、4軸のスコアリング（順位×CTR×PV×エンゲージ）で網羅的に拾えます。優先度AとBの違いは「ジャンプ余地」と「現状の取れ高」のバランスで、Aは「2ページ目から1ページ目に押せば伸びる」、Bは「1ページ目内でCTR改善できる」と覚えてください。

なおAhrefs MCPを契約していなくてもこのSTEP1は完走できます。Ahrefsはあくまで「市場全体の文脈」を加える役割で、自サイトのデータ起点ならGSCとGA4だけで十分です。

【STEP 2】検索意図再分析+競合ギャップ抽出

STEP 2は、対象記事が「現状取れている検索意図」と「取れていない検索意図」を炙り出し、競合との差別化機会を明確にするステップです。このステップの精度がリライト全体の成果を左右するので、丁寧にやる価値があります。

このステップの目的

対象記事のGSCクエリデータと競合上位記事の見出し構造を比較し、3つの軸でギャップを抽出します。

プロンプト本体（基本版・Ahrefs MCPなし）

あなたはSEO検索意図分析の専門家として、対象ページの検索意図ギャップを抽出します。

【入力】
- 対象URL（STEP1で選定済み）
- 対象URLのメインキーワード

【手順】
1. GSC MCPで対象ページのクエリ別データを取得
   - pageFilter=対象URL, dimensions=query, 直近90日, 最大100クエリ
   - 各クエリのimpression / clicks / CTR / position

2. メインKWでGoogle検索し、上位5記事のURLを特定（WebSearch or 手動共有）

3. 上位3記事のHTMLをWebFetchで取得し、title / meta / H2/H3一覧 / 主要トピック / 文字数を抽出

4. 3軸でギャップを抽出
   - 軸A: 自記事独自トピック
   - 軸B: 上位記事は触れているが自記事に無いトピック
   - 軸C: GSCで30位以下のクエリ

5. 検索意図を3層で整理
   - 表層: メインKWの直接的な意図
   - 中間: 派生クエリから読み取れる「次に知りたいこと」
   - 根本: ペルソナの最終的な達成目標

6. 出力: ギャップマトリクス + 拡張すべき検索意図リスト + 削除候補
   → rewrite-projects/<日付>/02_intent_gap.md に保存

Ahrefs MCP契約者向けの拡張版

Ahrefsを契約している場合、上記の手順に加えて競合の取得KW全体を機械的に取れます。

基本版に加えて以下を実行
7. Ahrefs MCPでメインKWのvolume/KD/parent_topic/SERP特徴を取得（keywords-explorer-overview）
8. 上位3記事それぞれのsite-explorer-organic-keywords（mode=exact）で取れているKW上位30件を取得
9. 軸B（拡張すべき検索意図）に「競合は取れているが自記事が取れていないKW」を追加

このプロンプトのポイント

WebFetchだけでも競合の見出し構造は十分に取れます。Ahrefs拡張版が真価を発揮するのは「競合のKW分布を相対比較したい」「派生語のvolume優先度を判定したい」場合です。リライト目的なら基本版で完走可能、それ以上の戦略を立てたい時にAhrefsを足す、と覚えてください。

【STEP 3】リライト要件定義

STEP 3は「何を残し、何を削り、何を足すか」をAIに設計させるステップです。STEP1の優先度判定とSTEP2のギャップ分析を統合して、具体的な改修計画を作ります。

このステップの目的

要件定義シートを作り、リライトの方向性を1ページで一望できる形にします。これがあると次のSTEP4で「思いつきで書き換える」事故を防げます。

プロンプト本体（要点）

あなたはSEOリライトの設計者として、対象記事の改善方針を策定します。

【入力】
- 既存記事の本文（マークダウン or HTML）
- 01_candidates.md / 02_intent_gap.md
- ナレッジファイル: knowledge/google-helpful-content-guidelines.md

【手順】
1. 既存記事を読み、現在のH2/H3構造、各セクションの主張、文字数を抽出

2. 02_intent_gap.mdの「拡張すべき検索意図」と現状を照合
   - 既存セクションでカバー可能 / 新規セクション必要 / 再構成必要 を判定

3. リライト方針シートを作成
   - 基本設計（想定文字数、追加見出し、削除/統合する見出し、構成変更）
   - E-E-A-T強化箇所（Experience/Expertise/Authoritativeness/Trustworthiness）
   - CVR導線（既存CTAの評価、追加すべきCTA位置）
   - SEO最適化（タイトル変更案、メタディスク案、内部リンク、画像）

4. リスク評価
   - タイトル変更による順位下落リスク
   - 大幅構成変更による評価リセットリスク
   - リスクが高い場合は「段階的リライト」を推奨

5. rewrite-projects/<日付>/03_requirements.md に保存

【重要】既存記事で順位が安定（top10内）の場合は、構造変更を避けて追記中心の方針を採用

このプロンプトのポイント

タイトル変更は最も慎重に判断すべき項目です。Googleはタイトルを記事の主要なシグナルとして使うので、上位安定中の記事のタイトルを大幅変更すると順位が一気に下がるケースがあります。要件定義の段階で「タイトルは触らない」「メタディスクリプションだけ調整」のような判断を明文化することで、STEP4の暴走を防げます。

「リスクが高い場合は段階的リライト」というのも重要なポイント。一度に全H2を書き換えるのではなく、まず2〜3個の見出しだけ変更してGSCで様子を見る、という運用ができると失敗時のロールバックが現実的になります。

【STEP 4】本文リライト実行

STEP 4は本文を実際に書き換えるステップです。STEP 3で作った要件定義に従って進めます。

モードA・モードBの選択

実行前に2つのモードから選びます。

プロンプト本体（要点）

あなたはプロのSEOライターとして、03_requirements.mdに従って本文をリライトします。

【入力】
- 既存記事本文 / 03_requirements.md
- ナレッジファイル
  - knowledge/natural-japanese-writing.md（自然な日本語）
  - knowledge/ai-detection-prevention.md（AI臭排除ルール）
  - knowledge/insite-article-format.md（フォーマット規約）

【実行モード】
ユーザーがモードA（見出し承認制）/モードB（一括書き換え）を選択

【手順】
1. 03_requirements.mdの「基本設計」を確認
2. ユーザーに実行モードを確認
3. セクションを上から順に処理
   - 既存セクション（保持）: 必要な追記・補強のみ
   - 既存セクション（再構成）: 構造変更後、本文書き換え
   - 新規セクション: 検索意図と要件定義に従って執筆
   - 削除セクション: 削除（必要なら他セクションに統合）

4. モードAの場合: 各セクション完了時にdiff + 変更理由を提示し、承認後に次へ
5. モードBの場合: 全セクション完了後に全体diffをまとめて提示

6. 最終チェック（リード/H2導入文/PREP/内部・外部リンク/E-E-A-T配置）
7. rewrite-projects/<日付>/04_rewritten.md に保存

【AI臭排除の絶対ルール】
- 半角/全角コロン使用禁止
- 「セクション」「emダッシュ」禁止
- 「たとえば」→「例えば」漢字統一
- HTMLタグ近辺では **〇〇** ではなく <strong>〇〇</strong>

このプロンプトのポイント

ナレッジファイル（自然な日本語、AI臭排除ルール、フォーマット規約）を分離してプロンプトから参照させるのが要点です。同じナレッジを複数のリライト案件で使い回せるので、案件が増えるほどプロンプトの効率が上がります。

「AI臭排除の絶対ルール」は本文中に書くと長くなるので、ナレッジファイルに切り出してプロンプトから参照させるのが現実的。配布パッケージにはナレッジファイルのテンプレートも同梱しています。

【STEP 5】効果測定（GSC × Ahrefs × GA4 統合分析）

リライトを実施したら、必ず効果測定までAIにやらせます。「順位は上がったか」だけでなく、CTR・エンゲージメント・取れ始めたクエリまで複合判定することで、次の打ち手の精度が上がります。

このステップの目的

リライト前後21日間のデータを3ソース（GSC・Ahrefs・GA4）で比較し、改善効果と次の打ち手をAIに統合判定させます。

プロンプト本体（要点）

あなたはSEO効果測定の専門家として、リライトの成果と次の打ち手を提案します。

【入力】
- リライト対象URL
- リライト実施日: YYYY-MM-DD
- 比較期間: リライト前21日 vs リライト後21日（推奨は28日後に実行）

【手順】
1. GSC MCPで前後21日のクエリ別データを取得・比較
   - 各クエリのimpression / clicks / CTR / position の変化
   - 新たに取り始めたクエリ / 失ったクエリのリスト
   - 全体トラフィックの増減

2. Ahrefs MCPで前後比較（契約者のみ）
   - site-explorer-organic-keywordsで現時点のランクKW数
   - リライト前日付と比較し、Traffic Valueの変化を取得

3. GA4 MCPで前後21日のページパフォーマンス比較
   - screenPageViews / sessions / engagementRate / averageSessionDuration

4. 統合判定
   - 順位↑ + CTR↓ + 滞在↑: 内容は良くなった、タイトル/メタが弱い
   - 順位↑ + CTR↑ + 滞在↓: タイトルは良くなったが本文が薄い印象
   - 順位横ばい + 取れるクエリ↑: 方向性は正しい、もう少し時間が必要

5. 次の打ち手提案
   - タイトル/メタ再調整 / 特定セクションの追記 / 内部リンク強化 / 様子見

6. rewrite-projects/<日付>/05_measurement.md に保存

【重要】
- リライト後14日未満では結果が出にくいため警告
- コアアップデートが期間に含まれる場合は判定困難な旨を明示
- 順位下落が顕著な場合は緊急ロールバックを推奨

このプロンプトのポイント

単純な「順位が上がった/下がった」だけで判断しないことが重要です。例えば「順位は上がったがCTRが下がった」場合、本文は良くなったがタイトルが弱くなっているケースで、タイトルだけ再調整すれば追加の伸びが見込めます。3ソースの複合判定で、初めて「次に何を直すべきか」が見えてきます。

なお、Googleコアアップデートが比較期間に含まれている場合は判定が困難になります。リライトの効果測定中に大型アップデートが来たら、その時点で測定をリセットして28日後に再評価するのが現実的な運用です。

inSite（インサイト）

リライト後の記事もinSiteで一元管理・効果追跡

無料で試す →

inSite運営での実例｜2記事をリライトしてみた

本ワークフローを実際にinSiteブログの2記事に適用し、STEP 1〜3 までを通しで動かしました。本パートは「分析プロンプトを実際に動かしたらどんな出力が得られるか」のサンプルとしてもご活用ください。リライト後の3ソース前後比較データは2〜4週間後に本記事を更新して追記します。

ケース1 インデックスカバレッジの記事

対象URL: /blog/index-coverage/

STEP 1の出力｜優先度判定

STEP 1のスコアリングで「優先度A（順位11-30位 × impression>200 × エンゲージ>40%）」に分類された記事です。

GA4のエンゲージメント率60%・平均滞在105秒は記事の質としては十分。順位とCTR改善に振ったリライトで一気に伸びる構造です。

STEP 2の出力｜競合ギャップマトリクス

競合上位3記事（willgate / plan-b / oneder）のH2構造をWebFetchで取得し、自記事と比較した3軸ギャップ抽出の結果です。

検索意図を3層で整理すると、表層は「インデックスカバレッジの意味とGSCでの見方」、中間は「自分のサイトに出ているステータスやエラーの直し方（特にGSC通知メールが届いた人）」、根本は「検出→原因特定→修正→検証→再発防止までを自走できるようになりたい」です。

STEP 3の出力｜リライト要件シート

STEP 2のギャップ分析と既存構造から、AIが生成したリライト要件です。

ケース2 検索クエリの調べ方の記事

対象URL: /blog/search-query/

STEP 1の出力｜優先度判定

STEP 1で「優先度A」に分類された記事ですが、ケース1とは性質が違います。

注目すべきはGA4の平均セッション時間48秒・エンゲージメント率50%という低い数字です。本文の内容が薄い、もしくは検索意図とズレている可能性が高い記事です。

STEP 2の出力｜競合ギャップマトリクス

競合上位3記事（n-works / primenumbers / seohacks）の見出し構造から得られたギャップです。

検索意図を3層で整理すると、表層は「GSCで検索クエリを見る手順」、中間は「取得した検索クエリをどう読み解いて改善に使うか」、根本は「キーワードと検索クエリの違いを正しく理解した上で、データの限界も踏まえてPDCAを回したい」です。

STEP 3の出力｜リライト要件シート

2ケース通しての所感

両ケースとも現H2の構造は基本維持し、追記中心のリライトが安全という結論になりました。インデックスカバレッジ側は「メール通知起点の流入」と「SEOへの影響（動機付け）」、検索クエリ側は「クエリ分類によるE-E-A-T補強」と「GSC以外の調べ方拡張」が最大ROIです。両記事とも競合の独立H2で扱われている要素を素直に吸収しつつ、自記事の独自資産（ステータス一覧表/データ制限の章）は保護することで、順位低下リスクを最小化しながら取りこぼしクエリを回収できる構成になりました。

STEP 4・5は本記事公開後に実施、前後比較は追って追記

ここまでがSTEP 1〜3の実出力です。STEP 4の本文書き換えは本記事の公開と並行して実施し、STEP 5の効果測定はGoogleの再評価とGA4のエンゲージメント変化が出るまで2〜4週間後に行います。前後比較データが揃った時点で本記事を更新し、3ソース統合の判定結果を追記します。

inSite（インサイト）

リライト履歴の記録・効果測定の継続をワンプラットフォームで

無料で試す →

MCP環境を作れない人向けの単発プロンプト集

Claude CodeやCodex CLIの環境構築が難しい方向けに、ChatGPT WebやGemini Webでも使えるコピペ式のプロンプトを5本用意しました。精度はMCP連携版に劣りますが、CSVデータを手動で準備すれば動作します。

単発プロンプトの使い方

それぞれのプロンプトは「データを手動で集めて貼り付ける」形式です。GSCの「ページ別レポート」をCSVエクスポートして貼り付ける、競合上位記事の見出しを手動でコピーして貼り付ける、というように人間が中継役を担います。

単発1 候補抽出

以下のGSC「ページ別レポート」のCSVデータを分析し、リライト候補を優先度付きで抽出してください。

【判定基準】
- 優先度A: 平均掲載順位11-30位 かつ 表示回数100以上
- 優先度B: 順位4-10位 かつ CTRが順位平均より20%以上低い

【出力】
- 上位10ページの優先度マトリクス
- 推奨3ページと理由

【データ】
（ここにCSVを貼り付け）

単発2 検索意図ギャップ分析

対象キーワードと、競合上位3記事の見出し一覧から検索意図ギャップを抽出してください。

【入力】
メインKW: ○○○
競合1の見出し: ...
競合2の見出し: ...
競合3の見出し: ...
自記事の見出し: ...

【出力】
- 競合は触れているが自記事は触れていないトピック
- 自記事の独自トピック
- 拡張すべき検索意図（優先度付き）

単発3 リライト要件定義

以下の既存記事と検索意図ギャップ分析を元に、リライト方針シートを作成してください。

【入力】
- 既存記事本文
- 検索意図ギャップ分析結果

【出力】
- 想定文字数（現状/目標）
- 追加/削除/再構成すべき見出し
- E-E-A-T強化箇所
- リスク評価（タイトル変更/構成変更）
- 段階的リライトの推奨可否

単発4 節単位の本文リライト

以下の要件定義に従って、対象セクションを書き換えてください。

【AI臭排除ルール】
- 半角/全角コロン禁止
- 「セクション」「emダッシュ」禁止
- 「たとえば」→「例えば」
- 結論ファースト / PREP法
- 各H2直後に導入文必須

【入力】
要件定義: ...
変更対象セクション: ...

【出力】
- 変更前 / 変更後のdiff
- 変更理由

単発5 効果測定（手動データ）

以下のリライト前後データを統合分析し、効果と次の打ち手を提案してください。

【入力】
- 期間: 前21日 vs 後21日
- GSCデータ（クエリ別、CSV）
- GA4データ（PV/セッション/エンゲージ、CSV）

【出力】
- 順位 × CTR × エンゲージの複合判定
- 次の打ち手（タイトル/メタ/本文/内部リンク）
- 緊急対応が必要な場合のロールバック判断

これらは「とりあえず試してみたい」「MCP環境が整うまでの仮運用」として有効です。本格運用するならClaude Code/Codex CLIへの移行を強くおすすめします。

AIリライトの失敗パターンと回避策

AIリライトを実務で回していると、いくつか共通する失敗パターンに行き当たります。事前に把握しておくと、同じ事故を踏まなくて済みます。

よくある5つの失敗パターン

Google公式の見解との整合

AIで書いたこと自体はGoogleペナルティの対象になりません。Googleは2023年2月に「AI生成コンテンツに関するGoogle検索のガイダンス」を発表し、「コンテンツがどのように制作されたかではなく、その品質に重点を置く」と明言しています。

ただし、「大量生成されたコンテンツの不正使用（Scaled Content Abuse）」として、検索結果操作目的で量産されたページはペナルティ対象になります。本ワークフローのようにデータドリブンに「読者にとって価値が高まる方向」にリライトする限り問題はありませんが、「とにかく記事数を増やす」目的でAIを使うとペナルティリスクがあります。

作った記事の管理・効果測定はinSiteで

AIでリライトを効率化できるようになると、次の課題は「どの記事をいつリライトしたか、どんな効果が出たかを管理する」ことになります。リライト履歴をスプレッドシートで管理するのは50本を超えると現実的ではなくなり、手動の効果測定は工数がかかりすぎて続きません。

inSiteは、SEO担当者向けのサイト管理自動化ツールです。Search Consoleと連携して各記事のパフォーマンス・インデックス状況・内部リンク構造をまとめて可視化できるため、リライト後の効果追跡を仕組み化できます。

AIで「書く・直す」効率を上げたら、inSiteで「管理する・測る」効率も上げていきましょう。

inSite（インサイト）

AIリライトの管理・効果測定をワンプラットフォームで

無料で試す →

よくある質問(FAQ)

まとめ

AIリライトを実務で回していくときに大事なのは、「正解の1本のプロンプト」を探すことではなく、データ取得から効果測定までを再現可能なワークフローに落とし込むことです。本記事の5ステップを使えば、優先度の高い記事を機械的に抽出し、検索意図のギャップを埋めるリライトを安全に回し、効果を3ソースで複合判定するところまで、AIに任せられる範囲を最大化できます。

ぜひ配布パッケージをダウンロードして、自分のClaude Code/Codex環境にセットアップしてみてください。AIが対話でセットアップを案内してくれるので、エンジニア経験がなくても10〜15分で導入できます。

inSite（インサイト）

AIリライトの管理・効果測定を一元化

無料で試す →