n8nでSEOリライトを自動化した方法｜GSC・GA4活用とフロー0統合の実践ログ

# n8nでSEOリライトを自動化した方法｜GSC・GA4活用とフロー0統合の実践ログ

GSC/GA4のデータを毎週取得しているのに、リライトだけ手作業になっていませんか。

私もJogtimeの運用で、データ取得と改善フローが分離されている状態がしばらく続いていました。

この記事では、n8nのフロー0（キーワード抽出）にリライト処理を統合し、GSC/GA4データを再取得せずに改善フローまで自動化した実装構成を公開します。rewrite_type（intro/body/cta）の判定設計・Drive上の既存記事取得・AIプロンプト設計・Slack通知まで、実際に動いた構成をそのまま残しています。

リライトフローをフロー0に統合した理由

最初はリライトを独立したフローとして設計しようとしていました。ただ、よく考えると独立フローにすると1つの問題が出ます。GSC/GA4データを二度取得しなければならないということです。

フロー0では毎週GSC/GA4データをバッチ取得してperformance_cache_jogtime.jsonに保存しています。このデータには、新規キーワード候補の抽出に使う検索クエリデータだけでなく、既存記事のGA4指標（直帰率・スクロール到達率・CTA率）も含まれています。

リライト候補の判定にはこのGA4指標がそのまま使えます。わざわざ別フローを立ち上げてデータを再取得するのは無駄です。フロー0のキーワードスコアリングノードでrewrite_candidates配列を生成し、新規キーワード処理の後にそのままリライトフローへ流す設計が最もシンプルでした。

フロー全体のつながりはこうなっています。

フロー0（Cron週次）
  → GSC/GA4バッチ取得
  → キーワードスコアリング
    → new_keywords（新規候補）
    → rewrite_candidates（リライト候補）
  → 新規キーワード処理（AI精査→Sheets追記）
  → Slack通知（新規キーワード）
  → リライト候補あり？（IF）
    → false: フロー0完了通知（Slack）
    → true:  リライト候補展開
              → リライトループ（1記事ずつ）
              → ループ完了後: フロー0完了通知

新規キーワードがゼロでもリライト候補があれば処理が走り、どちらも完了した段階でフロー0完了通知を送る構成です。

GSC/GA4データでrewrite_type（intro/body/cta）を判定する設計

リライトで一番重要なのは「どこを直すか」の判定です。全部まとめて直しても読者の行動は変わりません。GA4の指標から「どこで読者が離脱しているか」を逆算してrewrite_typeを決める設計にしました。

判定ロジックはキーワードスコアリングのCodeノードに含まれています。

const rewrite_candidates = (perfData.articles ?? [])
  .filter(a => a.ga4_sessions !== null && a.ga4_sessions >= 10)
  .map(article => {
    const b   = article.ga4_bounce_rate    ?? 999;
    const s50 = article.ga4_scroll_50      ?? 0;
    const s90 = article.ga4_scroll_90      ?? 0;
    const cta = article.ga4_cta_click_rate ?? 0;
    let priority     = 5;
    let rewrite_type = 'none';
    let rewrite_axis = '対応不要';

    if (b > 70 && s50 < 40) {
      priority     = 1;
      rewrite_type = 'intro';
      rewrite_axis = `直帰率${b}%・scroll_50が${s50}%。冒頭で記事の価値が伝わっていない。`;
    } else if (s90 > 20 && cta < 5) {
      priority     = 2;
      rewrite_type = 'cta';
      rewrite_axis = `scroll_90が${s90}%まで読まれているがCTA率${cta}%。`;
    } else if (s50 > 60 && s90 < 20) {
      priority     = 3;
      rewrite_type = 'body';
      rewrite_axis = `scroll_50は${s50}%だがscroll_90が${s90}%。本文中盤で離脱している。`;
    }
    return { slug, rewrite_type, rewrite_axis, priority, ...metrics };
  })
  .filter(a => a.rewrite_type !== 'none')
  .sort((a, b) => a.priority - b.priority);

3つのrewrite_typeの判定基準はこうなっています。

intro（冒頭離脱）： 直帰率70%超かつscroll_50到達率40%未満。記事を開いたけれど読まずに離脱しているパターンです。H1直下の導入文が読者の期待と合っていないケースが多いです。

cta（読了後CTA未踏）： scroll_90到達率20%超かつCTAクリック率5%未満。最後まで読んでいるのにCTAを踏んでいないパターンです。CTA直前のベネフィット訴求が弱いケースです。

body（中盤離脱）： scroll_50到達率60%超かつscroll_90到達率20%未満。前半は読まれているのに中盤で離脱しているパターンです。H2構成や具体例の薄さが原因になりやすいです。

セッション数10以上のフィルターを入れているのは、データが少なすぎる記事の誤判定を防ぐためです。

判断基準：

• 直帰率が高くてscroll_50が低い → intro（冒頭を見直す）
• scroll_90まで読まれているのにCTAが踏まれていない → cta（CTA直前を見直す）
• scroll_50は高いがscroll_90が低い → body（中盤を見直す）
• セッション数10未満 → 対象外（データ不足で誤判定リスクがある）

リライトループの構成とDriveからの記事取得

rewrite_candidatesはpriority順（1→2→3）にソートされた配列です。この配列をLoop Over Items（Batch Size: 1）で1記事ずつ処理します。ループ内のノード構成は以下です。

リライトループ（Loop Over Items）
  ├─ loop: リライト記事検索（Google Drive Search）
  │         → article.md検索・ダウンロード
  │         → meta.json検索・ダウンロード
  │         → リライトデータ統合（Code）
  │         → Slack着手通知
  │         → リライト構成案生成（OpenAI）
  │         → リライト構成案パース（Code）
  │         → リライト本文生成（Claude）
  │         → リライト本文パース（Code）
  │         → リライトmeta.jsonエンコード（Code）
  │         → article.md書き込み（VPS SSH）
  │         → meta.json書き込み（VPS SSH）
  │         → publish.mjs実行（VPS SSH）
  │         → article.mdアップロード（Drive PATCH）
  │         → meta.jsonアップロード（Drive PATCH）
  │         → 記事フォルダ削除（VPS SSH）
  │         → Slack完了通知（リライト）
  └─ done: フロー0完了通知（Slack）

Drive上の記事取得で詰まったポイントが1つあります。記事検索ノードのSearch Queryです。

={{ 'name contains \'' + $json.slug + '\'' }}

フォルダIDには引き継ぎプロンプトに記載したJogtime記事フォルダ（1zbUE4wQe_d11ZXv_mBbSwdMRkdIGPFZ3）を指定しています。最初はbizinets.biz側のフォルダIDが入ったままになっていて、記事が見つからない状態が続きました。移植時のフォルダID差し替え漏れが原因でした。

リライトデータ統合ノードでは、ループの出力・article.mdのダウンロード内容・meta.jsonの解析結果を1つにまとめています。

const loopData = $('リライトループ').first().json;
const articleBinary = $('article.mdダウンロード').first().binary?.data;
const article_md = articleBinary
  ? Buffer.from(articleBinary.data, 'base64').toString('utf-8')
  : '';
const metaBinary = $('meta.jsonダウンロード').first().binary?.data;
const meta = metaBinary
  ? JSON.parse(Buffer.from(metaBinary.data, 'base64').toString('utf-8'))
  : {};

rewrite_typeごとのAIプロンプト設計

リライトは2段階のAI処理で行っています。まずOpenAIで「どこを・なぜ・どう直すか」の構成案を生成し、次にClaudeで実際のリライト後本文を生成します。

第1段階：構成案生成（OpenAI）

OpenAIへのシステムプロンプトにはrewrite_typeごとの修正方針を明示しています。