目次
- AIリライトは「成功しました」の前に「仕組み」を作る話
- リライトすべき記事をAIに判断させる仕組み
- 「どの記事を直すか」はAIが決める
- GSCデータで候補を自動抽出する方法
- AIの提案を受けて人間が判断する場面
- 人間がやることは事実チェックと捏造検出
- AIは文章を整えるのは上手いが、言っていないことを足す
- 捏造を防ぐ仕組み：CLAUDE.mdにルールを書く
- 「自分の記事」を守るのは結局人間の仕事
- 実装手順：Claude Codeでリライトする全工程
- Step 1 — CLAUDE.mdにリライト方針を定義する
- Step 2 — 競合分析→構成修正→本文リライト
- Step 3 — リライト後の効果を追跡する
- AIリライトで気をつけること
- 一次情報（体験パート）を削らない
- 順位が上がっている記事をいじりすぎない
- Googleの「有用なコンテンツ」基準との整合
- これから観測すること
- まとめ：AIリライトは「AI二段構造」で運用する
- よくある質問
- Q1: AIでリライトした記事はGoogleペナルティを受けないのか
- Q2: 効果が出なかったらこの仕組みはやめるのか
この記事は「効果が出ました」という話ではありません。
「いまこの仕組みで動かしていて、結果はこれから観測する」という実装記録です。
AIでブログ記事をリライトする方法を調べると、「こうやったら順位が上がった」「CTRが改善した」という記事が上位を占めています。それはそれで参考になるのですが、私がいま実際にやっていることとは違います。
私の運用は、こういう設計になっています。
- どの記事をリライトするかは、AIが候補を出す（GSCデータ・競合分析・KWボリュームから）
- AIのリライト提案を人間が読み返し、捏造を弾く
- リライト後の効果は、スクリプトで時系列追跡する（まだ検証中）
「成功体験を売る」記事ではないので、「リライトしてすぐに順位が上がる方法が知りたい」という方には物足りないかもしれません。
一方、「AIを使ってリライトの仕組みを作りたい」「自分の記事をAIに書き換えさせたときの品質管理が知りたい」という方には、実際に動かしている仕組みを見てもらえると思います。
AIブログ自動化の全体像についてはこちらのピラー記事にまとめています。この記事はその中の「リライト工程」を詳しく掘り下げたものです。
AIリライトは「成功しました」の前に「仕組み」を作る話
競合のリライト記事を10本読みました。
ほぼ全部が同じ型でした。「この記事を選んでリライトしたら、順位が●位上がった」「表示回数が●%増えた」という構成です。
実際に効果が出た記録を公開するのはとても誠実なことだと思います。ただ、私がいまやっていることは少し違う立場にいます。
リライト後であり、まだ効果を見れていない。
これが事実です。ryman-nurse.comでリライトは実施しています。ただし、リライト後の効果（順位変動・流入変化）がどうなったかは、まだ検証できていない段階です。
だから、この記事は「効果体験記」にできません。
代わりに書けるのは、「何を判断軸にリライトを進め、その効果をどう追跡しているか」という仕組みの記録です。これはこれで、読者にとって役に立つ情報だと思っています。理由は2つあります。
ひとつ目は、「効果が出た」という記事は読めるが、「どうやって仕組みを作ったか」を詳しく書いた記事は少ないから。ふたつ目は、仕組みを先に作っておかないと、効果が出ても再現できないから。
なので、この記事は「成功体験の紹介」ではなく「仕組みの設計と実装の記録」として読んでください。効果が出たら追記します。出なかったとしても、それも書きます。
リライトすべき記事をAIに判断させる仕組み
「どの記事を直すか」はAIが決める
競合のリライト記事では、「GSCを開いて、表示回数が多くてCTRが低い記事を探しましょう」「11〜30位の記事が狙い目です」という書き方が定番です。
判断基準を教えるという意味では正しい。ただ、私の運用はここが少し違います。
あなた（AI）の提案に従ってリライトしている。
これがインタビューで出てきた私の実際の言葉です。「どの記事をリライトすべきか」を、私自身が判断しているのではなく、AI（Claude）が出した候補リストを見て「これはやる」「これは今じゃない」と選別する形で動かしています。
競合記事は全て「人間が判断する基準」を語ります。私の運用は「AIに判断させる仕組みを作った」という点が違います。
具体的に何が起きているかというと、AIはこういう分析をして候補を出してきます。
- GSCデータから、順位11〜30位・表示回数100以上・CTR3%未満の記事を抽出
- 各記事の競合分析（上位記事との構成差・カバレッジ差）
- KWボリュームの確認（月間検索数が十分あるか）
- 現在の記事の体験・個別性がどの程度残っているか
これらを統合して「このリライトは優先度高・中・低」というリストを出してもらい、私が最終的に「やる/やらない」を決める形です。
GSCデータで候補を自動抽出する方法
GSCから「リライト候補になりそうな記事」を抽出するには、Google Search Console APIを使います。
手順は次のとおりです。
Step 1: GSCのSearchAnalytics APIでデータを取得する
from google.oauth2 import service_account
from googleapiclient.discovery import build
import pandas as pd
from datetime import datetime, timedelta
def get_rewrite_candidates(site_url, days=90):
"""
GSCから順位11〜30位のリライト候補を抽出する
Args:
site_url: GSCに登録したサイトURL（例: 'sc-domain:example.com'）
days: 集計期間（デフォルト90日）
Returns:
候補記事のDataFrame（URL, clicks, impressions, ctr, position）
"""
credentials = service_account.Credentials.from_service_account_file(
'service-account.json',
scopes=['https://www.googleapis.com/auth/webmasters.readonly']
)
service = build('searchconsole', 'v1', credentials=credentials)
end_date = datetime.today()
start_date = end_date - timedelta(days=days)
request = {
'startDate': start_date.strftime('%Y-%m-%d'),
'endDate': end_date.strftime('%Y-%m-%d'),
'dimensions': ['page'],
'rowLimit': 500
}
response = service.searchanalytics().query(
siteUrl=site_url,
body=request
).execute()
rows = response.get('rows', [])
df = pd.DataFrame([{
'url': row['keys'][0],
'clicks': row['clicks'],
'impressions': row['impressions'],
'ctr': row['ctr'],
'position': row['position']
} for row in rows])
# リライト候補の条件でフィルタ
candidates = df[
(df['position'] >= 11) & # 11位以下
(df['position'] <= 30) & # 30位以内
(df['impressions'] >= 100) & # 表示回数100以上
(df['ctr'] <= 0.03) # CTR 3%未満
].sort_values('impressions', ascending=False)
return candidates
このコードで「11〜30位かつ表示回数100以上かつCTR3%未満」という条件の記事一覧が取れます。
Google Search Consoleの検索パフォーマンスレポートの使い方でも同じデータを手動確認できますが、記事数が多いほどスクリプトで一括取得する価値が出てきます。
Step 2: 取得したデータをAIに渡して優先順位をつけてもらう
データが取れたら、Claude Codeに次のような指示文で優先順位づけを依頼します。
以下のGSCデータを読んで、リライト候補を優先度高/中/低に分類してください。
判断基準：
- 表示回数が多い（潜在流入が大きい）
- CTRが低い（タイトル・メタディスクリプションで改善余地がある）
- 順位が11〜20位（上位を狙える距離感）
- 競合分析で「体験・個別性が不足している」と判定された記事
出力形式：
| URL | 優先度 | 判断理由 | 改善の方向性 |
|-----|--------|---------|------------|
[GSCデータをここに貼る]
この指示文で出てくるリストが、私が「やる/やらない」を決める材料になります。
AIの提案を受けて人間が判断する場面
AIが出してくるリライト候補リストは、たとえばこんな形です。
| URL | 優先度 | 判断理由 |
|-----|--------|---------|
| /nurse-job-change/ | 高 | 表示回数850・順位14位・CTR 1.8%。タイトルのKW前置きで改善余地大 |
| /nurse-night-shift/ | 高 | 表示回数620・順位19位・CTR 2.1%。競合分析で体験パート不足を確認 |
| /nurse-clinic/ | 中 | 表示回数320・順位22位・CTR 3.2%。CTRは基準内だが順位伸びしろあり |
| /nurse-salary/ | 低 | 表示回数180・順位28位・CTR 2.8%。KWボリュームが小さくROIが低い |
このリストを見て、私が「これはやる」「これは後でいい」を決めます。
ポイントは、全部やらないことです。優先度が高い2〜3本に絞ります。全部やろうとすると中途半端になるし、効果の測定もぶれます。AIが候補を出してくれても、最終的に「今これに時間をかけるか」は人間の判断です。
人間がやることは事実チェックと捏造検出
AIは文章を整えるのは上手いが、言っていないことを足す
AIにリライトを任せてみると、文章は確かに整います。論理構造がきれいになって、読みやすくなることもあります。
ただ、問題が起きることがあります。
読み返したときに自分が言っていないことを捏造しているときは指摘して直した。
これが実際に起きたことです。AIがリライトした文章を読み返したとき、「自分はこんなこと言っていない」という部分が入っていることがありました。
具体的には、こういうパターンです。
- 体験を盛る: 「大変でした」という記述が「毎日睡眠も取れないほど追い詰められました」に変わっている
- 数字を作る: 実際には計測していないのに「約30%の改善が見られました」という記述が入っている
- 感情を美化する: 「モヤモヤしていた」という感覚が「深く反省し、自分の甘さに気づきました」に変わっている
- 結論を先取りする: まだ検証中のことが「この方法で確実に改善できます」と断言されている
このブログのCLAUDE.mdには「事実にないことを足さない」「感情を美化しない」というルールを書いています。ただ、AIはCLAUDE.mdを読んでいても、気づかず捏造することがあります。完璧ではありません。
だから読み返しが必要です。「この文章は自分が言ったことか」を一行ずつ確認する作業が、AIリライトにおける最も重要な人間の役割です。
AIリライトの失敗パターンについてはこちらの記事でも詳しく書いています。
捏造を防ぐ仕組み：CLAUDE.mdにルールを書く
完全には防げませんが、捏造の頻度を減らすために、CLAUDE.mdのリライト方針セクションに明示的なルールを書いています。
実際のCLAUDE.mdの記載はこんな形です。
## リライトの優先原則
リライト・新規記事問わず必ず実施する。
### 優先①：競合分析を必ず行う
- リライト対象記事の主軸キーワードでGoogle上位10サイトを調査
- 上位記事の構成・切り口・強み弱みを把握
- 「自分の記事が上位に勝てるポイント」「負けるポイント」を明示
- 出力先: drafts/articles/{slug}/00_competitor_analysis.md
### 優先②：書き手の体験を入れる
- 体験素材なしでリライトは進めない
- 既存素材で足りない場合は、ハロさんへの再インタビューが必要
- 一般論だけのリライトは禁止
## リライト時の禁止事項
- 既存の体験パートを削除しない（体験が記事の核）
- 事実にないことを足さない（数字・エピソード・感情の捏造禁止）
- 感情を美化しない（「つらい」を「絶望的だった」にしない）
- まだ検証中のことを確定事項として書かない
- ハロさんが言っていないことをハロさんが言ったかのように書かない
このルールをCLAUDE.mdに書いておくことで、Claude Codeがリライト作業に入るときに方針として参照します。ただし前述のとおり、これだけでは完全ではないので、最終的な読み返しが必要です。
体験を入れないリライトが薄くなる理由についてはこちらの記事で詳しく書いています。
「自分の記事」を守るのは結局人間の仕事
AIに任せきりにすると、「誰が書いても同じ記事」になります。
技術的にはきれいな記事かもしれません。でも、なぜあなたがその記事を書くのか、という理由が消える。
私が体験を重視するのは、SEO的な理由（一次情報がE-E-A-Tに有利）だけではなく、「自分の言葉で書いた記事でないと自分がつらい」という感覚があるからです。AIがリライトしても「これは自分の記事だ」と思えること。そのために読み返して、捏造を弾く。
この作業を省略すると、ブログ全体が「AI生成感のある記事の集まり」になってしまいます。その先に読者との信頼関係は作れません。
実装手順：Claude Codeでリライトする全工程
Step 1 — CLAUDE.mdにリライト方針を定義する
まず、CLAUDE.mdにリライト専用のセクションを作ります。このファイルがClaude Codeの「行動規範」になるので、ここに書いたことはすべてのリライト作業で参照されます。
最低限書いておくべき内容は次のとおりです。
## リライト方針
### このブログのリライトで守ること
**体験素材の扱い**
- 既存記事の体験パートは原則削除しない
- 体験が不足している見出しには、インタビューで得た素材を追加する
- 体験素材にない事実を足さない
**捏造の禁止**
- 筆者が言っていないことを筆者が言ったかのように書かない
- 数字・比率・期間を勝手に作らない
- 感情の強度を上げない（「疲れた」→「燃え尽きた」は禁止）
- まだ検証中のことを「確認済み」として書かない
**競合との差別化**
- 一般論だけのリライトは禁止
- 必ず筆者の体験・視点・感覚を残す
- 競合が書けない個別性（筆者固有のエピソード・数値・判断）を核にする
**見出し構成の変更**
- 競合分析（00_competitor_analysis.md）で「必須トピック」と判定された見出しを追加する
- 既存の体験見出しを削除しない
- 追加する見出しの文字数目安を守る（各H3: 300〜600字）
このセクションがあるだけで、Claude Codeのリライト提案の質が上がります。方針が不明確だと「なんとなく整えた記事」が返ってきます。方針が明確だと「この見出しは体験が入っていないので追加が必要です」という提案が来ます。
Step 2 — 競合分析→構成修正→本文リライト
CLAUDE.mdが整ったら、実際のリライト作業に入ります。私の流れはこうです。
Step 2-1: 競合分析
Claude CodeのWebSearch + WebFetchを使って、対象記事の主軸キーワードで上位10記事を調査します。指示文はこうです。
以下のキーワードで Google 上位10記事を調査して、
drafts/articles/{slug}/00_competitor_analysis.md を作成してください。
キーワード: [ここにKWを入れる]
調査内容:
1. 各記事の見出し構成
2. カバレッジ表（どのトピックが何記事で扱われているか）
3. 上位記事に共通する「弱点」
4. 自記事が勝てるポイント・負けるポイント
5. 「必須カバー」と「個別性で勝負」のトピック分類
Step 2-2: 構成の修正
競合分析が終わったら、現在の記事構成と比較して「何を追加すべきか」「何は削っていいか」を整理します。この作業も指示文で依頼します。
00_competitor_analysis.md の競合分析と、
現在の記事（下記URL）を比較して、
構成修正案を出してください。
現在の記事URL: [URL]
出力形式:
- 追加すべき見出し（カバレッジ的に必須だが現在ない）
- 削除候補の見出し（一般論のみで体験もなく競合に劣る）
- 体験素材を追加すべき見出し（現在一般論のみ）
- タイトル・メタディスクリプションの修正案
Step 2-3: 本文リライト
構成修正案が確定したら、本文のリライトです。指示文はこうです。
この記事をリライトしてください。
- 00_competitor_analysis.md の競合分析を参照すること
- 02_interview_material.md の体験素材を必ず使うこと
- 既存の体験パートは削除しないこと
- 一般論だけの見出しには、体験素材から追加できるエピソードがあれば提案すること
- 体験素材にない事実は追加しないこと
- 感情を美化しないこと（原文の温度感を保つ）
- リライト後の文字数目安: [目標文字数]字
対象ファイル: drafts/articles/{slug}/04_draft_v*.md
Step 3 — リライト後の効果を追跡する
リライトした記事の効果を観測するために、track_rewrite_effect.pyを使っています。このスクリプトは、GSC APIと連携して、リライト前後のクリック数・表示回数・平均順位を時系列で記録します。
コマンドは3つです。
register: リライト公開直後にベースラインを記録する
python scripts/track_rewrite_effect.py register \
--slug nurse-job-change \
--post-id 2635 \
--expected-clicks 30
このコマンドを実行すると、data/rewrite_tracking.jsonにエントリが作られます。--expected-clicksは「このリライトで目標にしているクリック数」で、後の効果判定に使います。
update: チェックポイントのデータを取得する（毎週月曜自動実行）
python scripts/track_rewrite_effect.py update
cron（またはWindowsのタスクスケジューラ）で毎週月曜に自動実行する設定にしています。実行すると、data/rewrite_tracking.jsonの全エントリについてGSC APIからデータを取得し、チェックポイント（1週後・1ヶ月後・3ヶ月後）に記録します。
report: 効果サマリを出力する
python scripts/track_rewrite_effect.py report
出力例はこうです。
=== リライト効果レポート ===
生成日時: 2026-05-07
slug: nurse-job-change | post_id: 2635
リライト日: 2026-04-01
目標クリック数: 30/月
チェックポイント:
baseline (2026-03-25): clicks=12, impressions=680, pos=18.3
1週後 (2026-04-08): clicks=14, impressions=710, pos=17.1 → clicks +16.7%
未到達 1ヶ月後 (2026-05-01): データ収集中
未到達 3ヶ月後 (2026-07-01): 設定済み
判定: 観測中（1ヶ月後データ待ち）
このスクリプトの主要ロジック（registerコマンド部分）はこうなっています。
def register(slug: str, post_id: int, expected_clicks: int):
"""リライト記事のベースラインを記録する"""
# 現在のGSCデータを取得（過去7日分）
gsc_data = get_gsc_data(
site_url=os.getenv('GSC_SITE_URL'),
page_filter=f'/{slug}/',
days=7
)
entry = {
'slug': slug,
'post_id': post_id,
'rewrite_date': datetime.today().strftime('%Y-%m-%d'),
'expected_clicks': expected_clicks,
'checkpoints': {
'baseline': {
'date': datetime.today().strftime('%Y-%m-%d'),
'clicks': gsc_data['clicks'],
'impressions': gsc_data['impressions'],
'position': gsc_data['position'],
'ctr': gsc_data['ctr']
},
'1week': None, # 1週後に自動取得
'1month': None, # 1ヶ月後に自動取得
'3month': None # 3ヶ月後に自動取得
}
}
# data/rewrite_tracking.json に追記
tracking_file = Path('data/rewrite_tracking.json')
tracking = json.loads(tracking_file.read_text()) if tracking_file.exists() else []
tracking.append(entry)
tracking_file.write_text(json.dumps(tracking, ensure_ascii=False, indent=2))
print(f"登録完了: {slug} | baseline: clicks={gsc_data['clicks']}, pos={gsc_data['position']:.1f}")
.envファイルには以下の設定が必要です。
GSC_SITE_URL=sc-domain:your-domain.com
GOOGLE_APPLICATION_CREDENTIALS=service-account.json
リライト後の再公開手順についてはこちら、frontmatter更新→再投稿の流れについてはこちらをご覧ください。タイトル・メタディスクリプションの改善はSEOメタ自動生成の記事も参考になります。
AIリライトで気をつけること
一次情報（体験パート）を削らない
リライトで最もよくある失敗は、既存の体験パートを削ってしまうことです。
「この見出し、論理がつながっていないな」と思うと、AIは整合性を取るために、体験エピソードを削って一般論で補完することがあります。文章としては読みやすくなりますが、記事の核心が失われます。
対策は前述のとおり、CLAUDE.mdに「既存の体験パートは原則削除しない」と明記することです。それでも削られた場合は、読み返しで検出して差し戻します。
順位が上がっている記事をいじりすぎない
リライト候補を絞るときに、「どの記事を触らないか」も重要な判断です。
順位が上昇中の記事、または安定して1〜10位にある記事は、大幅リライトのリスクが高いです。構造を変えると、Googleが記事を再評価するプロセスが走り、一時的に順位が下がることがあります。
「直す必要がない記事を直さない判断」も、AI候補リストに含めています。AIは「この記事は順位が安定しているためリライト優先度は低」と判定して候補から外します。
Googleの「有用なコンテンツ」基準との整合
AIリライトを実施することで、Googleのペナルティを受けないかという心配をする方もいると思います。
Google検索セントラルの「有用なコンテンツの作成」では、「人々のために、人々が実際に役に立つと感じるコンテンツを作成する」ことが評価される旨が示されています。AI生成であること自体が問題なのではなく、「有用でないコンテンツ」が問題です。
一次情報（体験・実測データ・判断プロセスの記録）がある記事をAIで整えることは、有用性を下げる行為ではありません。問題になるのは、一次情報がない一般論だけの記事をAIで量産することです。
私の運用では、体験を削らず、捏造を弾くことで「一次情報があるリライト後の記事」を維持することを優先しています。
これから観測すること
現時点の状況をまとめておきます。
- リライト実施済み記事数：数本（ryman-nurse.comで実施）
track_rewrite_effect.pyで追跡中の指標：クリック数・表示回数・平均順位- 次のチェックポイント：1ヶ月後（2026年6月初旬）
- 最終判断時期：3ヶ月後（2026年8月）
仮説は次のとおりです。
「AIが候補を出し、人間が捏造を弾く運用」で、リライトした記事の順位は改善するか。
正直、まだわかりません。仕組みとしては理にかなっていると思っていますが、仕組みが良くても順位が上がるかどうかは別の話です。競合の質・KWの競争状況・Googleのアルゴリズムの変化など、コントロールできない要素があります。
ただ、「仕組みなしにリライトを続けるより、仕組みを作ってリライトする方が長期的には改善しやすい」という考えは変わりません。
効果が出たら、この記事に追記します。出なかったとしても、それも書きます。
まとめ：AIリライトは「AI二段構造」で運用する
この記事で書いたことを3行でまとめます。
- どの記事をリライトするかはAIに判断させる（GSC + 競合分析 + KWボリュームから候補を抽出し、人間が最終判断）
- AIのリライト提案を人間が読み返し、捏造を弾く（自分が言っていないことが書かれていたら指摘して直す）
- 効果は
track_rewrite_effect.pyで時系列追跡する（ベースライン → 1週後 → 1ヶ月後 → 3ヶ月後。まだ検証中）
この3つを「AI二段構造」と呼んでいます。AIが判断を出し、人間がそれを事実チェックしながら実行する。成功体験ではなく、いまこの設計で動かしている、という記録です。
AIブログ自動化の全体像はピラー記事「AIでブログを自動化する5ステップ」にまとめています。C14（この記事）はその中の「リライト工程」を深掘りしたものです。他のステップも興味があればご覧ください。
よくある質問
Q1: AIでリライトした記事はGoogleペナルティを受けないのか
一般論：
Googleは、AI生成コンテンツそのものをペナルティ対象にしていません。Google検索セントラルの方針では、「人々が実際に役に立つと感じるコンテンツ」かどうかが基準です。問題になるのは、一次情報がない薄いコンテンツを大量生成することです。
私の考え：
私の運用では、体験パートを削らず、AIが書いた捏造を弾くことで、一次情報を維持した状態でリライトしています。「AIが整えた」ではなく「AIが提案し、人間が事実確認して確定した」記事であれば、有用なコンテンツの基準を下回ることはないと考えています。
実際にペナルティが来るとしたら、それは「体験・一次情報がない状態でAIに丸投げした記事を量産した場合」だと思っています。
Q2: 効果が出なかったらこの仕組みはやめるのか
一般論：
リライトの効果は、一般的に3ヶ月以上の観測が必要とされています。Googleがリライトを再インデックスしてから、順位が安定するまでに時間がかかるためです。1〜2週間で判断するのは早すぎます。
私の方針：
3ヶ月後のデータを見てから判断します。「効果が出たら追記する。出なかったらそれも書く」というのがこの記事で最初に宣言したスタンスです。
仕組みをやめるかどうかの判断は、3ヶ月後のデータを見てから決めます。もし効果が出なかったとしても、「判断をAIに委ねる」「捏造を弾く」という運用自体は続けると思います。それは効果測定とは別の、「自分の記事の品質を守る」という理由があるからです。
この仕組みが正解かどうかは、3ヶ月後にならないとわかりません。仕組みを作って動かしている、というのが今の正直なところです。
同じようにリライトを仕組み化したい方は、一緒に検証していきましょう。
リライトの仕組み全体（CLAUDE.md全文・track_rewrite_effect.pyのコード全文・GSCデータの読み方と判断フロー）は、noteで詳しく公開しています。この記事ではコードの断片を見せましたが、noteではスクリプト全文と、実際のリライト前後の記事比較を含めた内容にしています。「仕組みの全体像を手元で再現したい」という方はnoteもご覧ください。
関連 note 記事
AI に記事を書かせようとしてうまくいかなかった話は note で書いています。リライトでも同じ「AI が言っていないことを書く」問題に通じます。
