【月間4,000表示でCTR 0.02%】AIが勝手にSEOの「穴」を見つける——GSC×GA4完全自動分析パイプラインの全設計図

月間4,000回以上Google検索に表示されているのに、クリック率がたった0.02%——。

この事実を、私は自分のサイトで「発見」しました。手動のGSCチェックでは見落としていた致命的なボトルネックです。

しかも見つけたのは私ではなく、AIが自律的に検出して、Slackに通知してきたのです。

この記事では、Google Search Console（GSC）とGoogle Analytics 4（GA4）のデータをClaude Codeで自動取得し、全記事を自動スコアリングして改善対象を検出する「完全自律SEO分析パイプライン」の設計と実装を、実データとともに公開します。

はじめに：SEOを「手動で見る」時代は終わった

多くのサイト運営者が毎週やっていること——GSCを開いて検索パフォーマンスを確認し、GA4で直帰率を見て、Excelに転記して分析する。

私も同じことをしていました。しかし111記事を運営するようになると、全記事のパフォーマンスを手動で追うのは物理的に不可能です。

Ahrefs、SEMrush、Rank Trackerなどのツールは優秀ですが、結局は**「人間がダッシュボードを見に行く」**という構造は変わりません。

私が構築したのは、その逆のアプローチです：

GSC APIから検索順位・表示回数・CTRを自動取得
GA4 APIからセッション数・滞在時間・直帰率を自動取得
3軸スコアリングで111記事をS/A/B/C/Dランク自動判定
Quick Wins（あと少しでTOP3に入れる記事）を18件自動検出
低CTR記事・高直帰率記事を即座に特定
結果をSlackに毎朝自動通知

人間がやることは、朝Slackを見て「この記事のタイトルを直すか」と判断するだけです。

システム全体像：日次パイプラインのアーキテクチャ

パイプラインは4つのステップで構成されます。毎日GitHub Actionsのcronで自動実行され、全データはSupabaseに集約されます。

┌────────────────────────────────────────────────┐
│          Daily SEO Pipeline (JST 06:00)         │
├────────────────────────────────────────────────┤
│                                                  │
│  Step 1: GSC Fetcher                            │
│  ├─ googleapis (OAuth2認証)                     │
│  ├─ 1,259クエリ / 119ページ取得                 │
│  └─→ gsc_query_analytics + gsc_page_analytics   │
│                                                  │
│  Step 2: GA4 Fetcher                            │
│  ├─ @google-analytics/data (Service Account)    │
│  ├─ 51ページの行動データ取得                     │
│  └─→ ga4_page_analytics                         │
│                                                  │
│  Step 3: Article Scorer                         │
│  ├─ SEO (40%) + Engagement (40%) + CV (20%)     │
│  ├─ 111記事をS/A/B/C/Dランク判定               │
│  └─→ article_quality_scores                     │
│                                                  │
│  Step 4: Opportunity Detector                   │
│  ├─ Quick Wins / Low CTR / High Bounce / 下降    │
│  ├─ 21件の改善機会を検出                         │
│  └─→ seo_improvement_opportunities              │
│                                                  │
│  → Slack通知 + CORTEX学習ループ統合              │
└────────────────────────────────────────────────┘

技術スタック：

データ取得：googleapis（GSC）、@google-analytics/data（GA4）
ストレージ：Supabase（PostgreSQL + RLS）
実行環境：GitHub Actions cron（毎日JST 06:00）
通知：Slack Bot API
統合：CORTEX自律ループ（AI-to-AI会話ベースの意思決定システム）

全コードはTypeScriptで記述し、各ステップが独立して失敗を処理します。Step 1が失敗してもStep 2以降は実行される設計です。

スコアリングアルゴリズム：3軸評価でS〜Dランク判定

AIキャリア相談＆実務AI活用はこちらから無料相談AIキャリア相談＆実務AI活用は
こちらから無料相談

記事の「良さ」を1つの指標で測ることはできません。検索に強い記事が読まれているとは限らず、読まれている記事が検索に強いとも限らない。

このシステムでは3つの軸で評価し、加重平均でoverall_scoreを算出します。

SEOスコア（全体の40%）

要素	比重	計算方法
CTR相対評価	30%	実際のCTR ÷ 順位別期待CTR × 100
平均順位	30%	1位=100pt, 5位=80pt, 10位=50pt, 20位=20pt
表示回数	20%	対数スケール（1000+=100, 500+=80, 100+=60）
クエリ多様性	20%	何種類のキーワードで検索されているか

期待CTRカーブは検索順位から算出します。1位は約30%、2位は15%、3位は10%。この期待値に対して実際のCTRが何%かで評価します。つまり5位でCTR 5%なら「5位にしては優秀」、1位でCTR 10%なら「1位にしては低い」と判定されます。

エンゲージメントスコア（全体の40%）

要素	比重	高評価の基準
平均滞在時間	30%	180秒以上 = 100pt
直帰率（逆数）	30%	30%未満 = 100pt
スクロール深度	20%	75%以上 = 100pt
セッション数	20%	対数スケール

コンバージョンスコア（全体の20%）

要素	比重	高評価の基準
CV率	50%	セッション比10%以上 = 100pt
イベント密度	50%	セッション比5以上 = 100pt

グレード判定

overall_score = SEO × 0.4 + Engagement × 0.4 + Conversion × 0.2

S: 80〜100（圧倒的に強い記事）
A: 65〜79（主力記事）
B: 50〜64（改善余地あり）
C: 30〜49（要テコ入れ）
D:  0〜29（抜本的改善が必要）

実際の結果

111記事をスコアリングした結果がこちらです。

グレード	記事数	割合
A	1	0.9%
B	10	9.0%
C	28	25.2%
D	72	64.9%

Sランク記事はゼロでした。つまり全記事に改善余地があります。A+Bの11記事が主力で、残り100記事は改善の余地が大きい。

上位5記事を見ると：

順位	記事	スコア	SEO	ENG	表示	検索順位
1	codex-app	65.0 (A)	65	68	63	10.5
2	claude-code-ai-to-ai-blog	62.5 (B)	79	52	200	6.6
3	ai-google-workspace	62.4 (B)	63	68	218	8.8
4	openclaw-vs-claude-code	62.0 (B)	80	50	1,665	5.6
5	claude-code-agent-design	60.1 (B)	79	46	530	5.1

4位のopenclaw-vs-claude-codeはSEOスコア80と圧倒的に強いですが、エンゲージメントスコアが50と低い。つまり「検索には強いが読了率が低い」という構造的な課題が見えます。

Quick Wins検出：順位4〜15位で眠っている記事

Quick Winsとは「Googleに既に評価されているが、TOP3に入りきれていない記事」のことです。

このシステムでは以下の条件で自動検出します：

検索順位が4〜15位
表示回数が100回以上

なぜ4〜15位か？　1〜3位はそのまま維持すべき記事。4〜15位は「あと少しの改善で大幅にクリック数が伸びる」ゾーンです。検索順位が1位上がるだけでCTRは倍増するケースもあります。

検出結果：18件

優先度	記事	順位	表示回数
high	openclaw-vs-claude-code	5.6	1,665
high	claude-code-agent-design	5.1	530
medium	ベクトルDBおすすめ9選	11.7	621
high	ai-to-ai-blog-auto-generation	6.6	200
high	nands.tech (トップページ)	5.1	128

最も衝撃的だったのは低CTR検出です。

CRITICAL: 「AIエージェントとは」記事
  → 月間 4,241回表示
  → CTR 0.02%（クリック数ほぼゼロ）
  → 期待CTR: 約1.5%（順位10.8位）
  → 期待値の1.3%に対して0.02%

月間4,000回以上Googleに表示されているのに、ほぼ誰もクリックしていない。これはタイトルとメタディスクリプションに致命的な問題があることを意味します。手動チェックでは完全に見落としていました。

同様に「RAGとは」記事も505表示でCTR 0.00%。これらの記事はタイトル1行の改善で、月間数百クリックを獲得できるポテンシャルがあります。

クロスポスト最適化：Zenn・Qiita・noteへの自動優先度判定

検出された改善機会は、単に記事を修正するだけでなく「どのプラットフォームにクロスポストすべきか」も自動判定します。

プラットフォーム別の判定ロジック

Zenn（技術深掘り）：Quick Win記事にボーナス+20pt。技術キーワード（tech, code, api, claude, ai）を含む記事にさらに+15pt。Zennからの被リンクはGoogleのSEO評価を上げる効果があるため、Quick Win記事のクロスポスト先として最適です。

Qiita（How-to/Tips）：Quick Win記事にボーナス+25pt。How-toキーワード（guide, setup, tutorial, tips）を含む記事にさらに+15pt。下降トレンドの記事には+20ptで再露出を図ります。

note（オピニオン/カジュアル）：高直帰率の記事にボーナス+20pt。スコアが低い記事に+15pt。元記事で離脱が多い場合、noteで別の切り口から書き直すことで新しい読者層を開拓します。

優先度判定

immediate : スコア70以上（今すぐ投稿）
this_week : スコア50〜69（今週中に投稿）
this_month: スコア30〜49（今月中に投稿）
skip      : スコア30未満（クロスポスト不要）

CORTEX自律ループとの統合

このSEO分析パイプラインは、単独で動くツールではありません。既存のCORTEX自律ループ——AI同士がDiscord上で永続的に会話しながらSNS戦略を最適化するシステム——に統合されています。

学習信号の拡大

CORTEXの学習ループは従来5つの信号源で動いていました：

SNSエンゲージメント（X/LinkedIn/Threads）
投稿時間帯パターン
バイラル構造分析
Discord/LINE/Slack会話ログ
クロスポストエンゲージメント

今回の統合で7つに拡大しました：

GSC検索パフォーマンス（NEW）
GA4コンテンツエンゲージメント（NEW）

これにより「SNSでバズった投稿が、検索でも評価されているか？」「検索で見つかった記事が、実際に読まれているか？」というチャネル横断の分析が可能になりました。

AI-to-AIループでのSEOレビュー

CORTEX自律ループにseo_reviewトピックを追加しました。AI-Aが定期的にSEOデータを参照し、「この記事のタイトルを改善すべき」「この記事をZennにクロスポストすべき」といった提案を自律的に生成します。

週次SEOレポートも自動生成され、以下の情報がSlackに届きます：

グレード分布の推移（改善傾向/停滞/悪化）
Top 5記事とBottom 5記事
Quick Winsの進捗状況
改善機会の新規検出数と解決数

実績：数字で見る効果

指標	数値
GSCから取得したクエリ数	1,259
GSCから取得したページ数	119
GA4から取得したページ数	51
スコアリング完了記事数	111
Quick Wins検出数	18
低CTR記事検出数	3
改善機会合計	21
パイプライン実行時間	約30秒
手動分析と比較した工数削減	週30分 → 0分

特筆すべきは4,241表示/CTR 0.02%の記事の発見です。これは手動で毎週GSCを確認していても見落としていた「隠れた機会損失」でした。タイトル改善だけで月間60〜80クリックの増加が見込めます。

導入のポイント

自分のサイトに同様のシステムを導入する場合のポイントをまとめます。

必要なもの

Google Cloud ConsoleでSearch Console APIとAnalytics Data APIを有効化
GSC用OAuth2認証（Desktop app型のクライアントID）
GA4用サービスアカウント（GA4プロパティに閲覧者ロールで追加）
Supabase（無料枠で十分）
Claude Code（記事スコアリングロジックの実装環境）

テーブル設計

最低限必要なテーブルは3つです：

gsc_page_analytics：ページ別の検索パフォーマンス（表示・クリック・CTR・順位）
ga4_page_analytics：ページ別の行動データ（セッション・直帰率・滞在時間）
article_quality_scores：3軸スコアとグレード

カスタマイズのポイント

期待CTRカーブはサイトのジャンルによって異なります。テック系ブログとECサイトでは検索1位のCTRが大きく違うため、自サイトのデータを3ヶ月以上蓄積してからカーブを調整することを推奨します。

スコアの重み配分も同様です。コンテンツマーケティング重視のサイトならエンゲージメントの比重を上げ、EC/リード獲得重視ならコンバージョンの比重を上げてください。

GSCデータは2〜3日遅延します。昨日のデータはまだ確定していないため、3日前のデータを取得する設計にすると安定します。

AIキャリア相談＆実務AI活用はこちらから無料相談AIキャリア相談＆実務AI活用は
こちらから無料相談

よくある質問

Q. 既存のSEOツール（Ahrefs, SEMrushなど）との違いは何ですか？

既存ツールは「データを見る」ためのダッシュボードです。このシステムは「データを見て、判断して、報告して、次のアクションまで提案する」自律パイプラインです。人間がダッシュボードを開く必要がなく、改善候補がSlackに届きます。さらにCORTEX自律ループと統合することで、SEOデータがSNS投稿戦略やブログトピック選定にリアルタイム反映されます。

Q. 無料で運用できますか？

GSC APIとGA4 APIは無料です。SupabaseのFreeプランでテーブル作成・データ蓄積が可能です。Claude Codeのサブスクリプション内でスコアリングロジックを実行するため、LLM APIの追加料金はかかりません。実質的に追加コストゼロで運用できます。

Q. 111記事のスコアリングにどれくらい時間がかかりますか？

約30〜60秒です。GSCとGA4のAPI呼び出しが主なボトルネックで、スコアリング自体は純粋な数値計算のため高速です。GitHub Actions cronで毎日JST 06:00に自動実行すれば、朝出社時にはSlackでレポートを確認できます。

Q. Quick Winsを検出した後、具体的にどう改善すべきですか？

順位4〜10位の記事はタイトルとメタディスクリプションの改善が最も効果的です。具体的な数字やベネフィットをタイトルに含めること、メタディスクリプションに検索意図への直接的な回答を含めることで、CTRが2〜3倍になるケースがあります。順位11〜15位の記事は内部リンクの強化とコンテンツの網羅性向上が有効です。

Q. Google APIの制限はありますか？

GSC APIは1日あたり25,000リクエスト、GA4 Data APIは1日あたり10,000リクエストの制限があります。日次1回のバッチ実行であれば、数百ページ規模のサイトでも制限に達することはまずありません。

目次