Claude Codeで37記事のSEOリライトをautonomousで回した話

この記事の結論

• やったこと: Claude Code に「f2t.jpのSEOを改善して」と指示し、37記事のタイトル一括リライト、Schema.org エンティティグラフ統合、Lighthouse a11y 100点化、GTM タグ削除、microCMS スキーマ追加までを autonomous で完走させた
• 数字: microCMS PATCH 53回 / Vercel commits 8本 / Lighthouse Accessibility 93→100 / 全151記事のタイトルから em-dash 100%除去・50字以下 100%
• 学び: AIエージェントに「成功条件」と「停止条件」を最初に握らせれば、destructive な操作（GTM タグ削除、本番テナント書込み）まで autonomous で安全に通せる

始まりは Google の AI 最適化ガイド

2026年5月、Googleが AI Optimization Guide for Search を公開した。要約すると「AI Overviews 用に特別な markup は要らない、従来のSEOを磨け」というシンプルなメッセージだった。

私はこの公式アナウンスを読んだ瞬間、検証してみたくなった。自社サイト f2t.jp で、その「従来のSEOを磨く」作業を、AIエージェントに任せたらどこまで行けるのか？

f2t.jp は次の状態だった。

• 全151記事、Next.js + microCMS + Vercel で稼働
• Lighthouse の SEO スコアは 100、Accessibility は 93
• 直近30日の GSC で平均 17 clicks/日、月間500クリック前後
• Search Console には複数の「pos 4 なのに CTR 0.2%」という、明らかにタイトルとメタが噛み合っていない記事

ここに Claude Code を入れて、ゴール「順番にすすめて」だけを渡し、停止条件を握らせて autonomous で走らせた。実際に動いた手順を、5バッチに分かれたタイトルリライトを中心に書く。

タイトル一括リライトを5バッチで回した

タイトル変更は SEO の中で最も即効性のある施策だが、151記事を人間が一気にやるのは無理だ。Claude Code に GSC データ（クリック数、表示回数、CTR、平均掲載順位）を読み込ませて、優先順位を決めてもらった。

優先順位の決め方は単純だった。

1. 既存トラフィックがある（imp > 100）
2. 掲載順位は良いのに CTR が悪い（pos 4-10 で CTR < 2%）
3. タイトルが50字超え、もしくは「——」「【2026年最新】」等の冗長表現

このフィルタを通すと、151記事のうち37記事が対象になった。一気に処理する代わりに、リスクを段階的に上げて5バッチに分けた。

バッチごとの構成

Batch 1 (3記事): 最大imp + 最低CTR の高インパクト3本（line-harness, antigravity, claude-skills）
Batch 2 (4記事): 第2層の高インパクト記事
Batch 3 (3記事): KW不一致記事
Batch 4 (6記事): 50字超え + em-dash混在
Batch 5 (20記事): 残り全部の em-dash除去 + 字数短縮

なぜ最初から20記事を一括でやらなかったのか。1バッチ目で何かがおかしくなったら、microCMS の content API は PATCH 単位でしか rollback できない。3記事だけなら手動で戻せるが、20記事の rollback は地獄だ。

Batch 1 で動作確認、Batch 2-3 で型を固め、Batch 5 で残りを一気に処理する。これは Claude Code 自身が impact-assessment の判断ルールに従って提案してきたフローだった。

1バッチの実装

各バッチで Claude Code が書いたスクリプトは以下のパターンだった。

// scripts/seo-rewrite-titles.mjs
const UPDATES = [
  {
    slug: 'line-harness-cloudflare-deploy',
    reason: 'pos 5.1 CTR 4.2% (通常6-9%)、67字で末尾切れ',
    title: 'LINE Harnessとは｜Lステップ代替OSSの使い方・導入手順を実例で解説',
  },
  // ...
]

for (const u of UPDATES) {
  const current = await getBlog(u.slug)
  console.log(`[現状] (${current.title?.length}字): ${current.title}`)
  console.log(`[新案] (${u.title.length}字): ${u.title}`)
  if (isApply) {
    await patchBlog(u.slug, { title: u.title })
  }
}

ポイントは「dry-run で現状と新案を並べて表示してから apply する」こと。AIが提案したリライトを、人間が一覧で確認できる状態を保ち続けた。

before/after の数値

37記事を回した結果がこれだ。

GSC の効果は2-3週間後に観測する必要があるが、リライトの中身を見ると改善方向は明らかだ。例えば最大ROI記事だった claude-code-guide-2025 は次のように変わった。

Before (61字): Claude Code完全ガイド【2026年最新】初心者向けの使い方・入門から応用・Antigravity連携まで徹底解説
After  (40字): Claude Codeの使い方｜入門から応用まで初心者向けに徹底解説【2026】

「完全ガイド」「徹底解説」「【2026年最新】」を冒頭から外して、最重要KW「使い方」を頭に持ってきた。モバイルSERPは32-40字で切れるため、後ろに重要キーワードを置くと表示されない。

なぜ Claude Code に任せられたのか

「タイトルリライトくらい人間がやればいい」と思うかもしれない。私もそう思っていた。実際にやってみて気づいたのは、人間の工数より「判断の質」の問題だったということだ。

37記事の現状タイトルを並べて、GSCデータを横に貼り付けて、各記事に最適な新タイトル案を出す。これを集中して回すと、20本目あたりで判断基準がブレ始める。「これは em-dash 残してもいい気がする」「この記事は字数長くてもいいか」と例外を作りはじめ、結果的にバラバラになる。

Claude Code は同じルール（50字以下、em-dash 禁止、KW を冒頭、検索意図に直接答える）を37記事全てに同じ強度で適用する。判断のブレがない。

ただし、これは Claude Code が「判断の品質」が高いという話ではない。ルールを明文化して握らせる手前の作業は人間が必須だ。今回の場合、ユーザーフィードバックメモリに feedback_no-emdash-in-titles.md（タイトルに「——」を使わない）が事前に登録されていたから、Claude Code はそのルールを 0 と 1 として適用できた。

止まる条件を最初に握らせる

37記事一気にPATCHする前に、Claude Code には次の停止条件を明示的に握らせた。

停止条件:
1. 最大試行回数3回を超えた
2. CRITICAL アクション（本番テナント書込み・配信・予算変更）に到達
3. 外部書込み（API CUD・file CUD・git push）が発生する直前
4. 要件が不明確になった
5. テスト失敗が3回連続
6. トークン予算の警告閾値を超えた

実際に走らせると、Batch 5 の20記事 PATCH 直前で Claude Code 自身が「これは CRITICAL アクション、ユーザー承認なしには進めない」と判定して停止した。私は内容を3秒見て「OK」と返した。それで Batch 5 が一気に通った。

「自律性」と「暴走」の境界線は、この停止条件を最初に握らせるかどうかで決まる、というのが今回の最大の学びだ。

Q. AIエージェントにSEO作業を任せる時の落とし穴は？

ストーリー型のタイトルが SEO 向きじゃないと判断できない、というのが最大の落とし穴。例えばこの記事の元になった一つは「広告が夜中に止まる問題を Claude Code MCP で解決した話」という素晴らしい人間的なタイトルだったが、Claude Code はこれを「KW不一致」と判定して「Claude Code MCPで広告運用を自動監視｜Google・Meta広告の停止検知」にリライトした。

SEO 観点では正しいが、ブランドの色が消える。SEO目線とブランド目線の両方を握らせないと、Claude Code は SEO に振り切る。今回は私の判断でSEOを優先したが、すべての記事をこの方針で書き換えるべきかは別問題だ。

Q. 失敗した点は？

正直に書くと、commit 02db79e で dead code を作った。重複slug記事に noindex meta を追加したが、よく調べたら next.config.ts に既に 308 リダイレクトが設定されていて、私の noindex は永遠に到達しないページに書かれていた。commit 3f32d43 で revert した。

調査不足が原因だが、AIエージェントが書くコードは「読む人間の調査を肩代わりしてくれる」のではなく「書く人間の調査を要求するものを書いてくれる」のだと再確認した。最終的に動作検証して dead code を見つけたのも Claude Code 自身だった。

次の記事

シリーズ第2回では、E-E-A-T を構造化データで証明するために実装した、Schema.org の Person × Organization × BlogPosting 三角統合の話を書く。f2t.jp の OG画像が per-route で生成される仕組みも、その流れで一緒に書く予定だ。

第3回は Chrome DevTools MCP × GTM API × microCMS を組み合わせて、autonomous SEO 改善がどこまで「人間の管理画面操作」を肩代わりできるかを検証した話を書く。

GSC の数字が実際に動くのは2-3週間後なので、結果は別記事で追記する。