月次のHP分析処理を自動化してみた。情報収集→分析→レポート作成を一気通貫で自動化

きっかけ：レポート作成そのものが工数を食っていた

Webサイトの運用支援では、月次で「現状はどうか」「何が課題か」「次に何をすべきか」をクライアントに報告する機会があります。この作業、地味に工数がかかります。GA4を開いて数字を拾い、Search Consoleでクエリを確認し、Screaming Frogでクロールして技術的な問題がないか見る。3つのツールを行き来しながら手作業で数字を集め、文章にまとめる——ここに毎月同じ時間を使うのは非効率だと感じていました。

そこで、GA4・Google Search Console・Screaming Frogのデータを機械的に収集し、「現状分析 → 課題特定 → アクションプラン」まで一気通貫で生成するパイプラインを作りました。まずは自社サイト（atau-dd）で運用し、精度を確認してからクライアントサイトへ展開する方針です。

設計方針：3ソースは統合取得しない

複数のデータソースを扱う分析基盤というと、まずGA4・GSC・クロールデータを1つのテーブルに統合したくなります。ただ今回は、あえて統合取得しない設計にしました。

• GA4はセッション・コンバージョンなどの行動データ
• GSCは検索での露出・順位というGoogle側の評価データ
• Screaming Frogはサイト構造そのものの技術的健全性

これらは性質が異なるため、無理に1つのスキーマに統合すると、かえって「どのソースの数字か」が曖昧になります。個別に取得し、レポート生成の段階で人（Claude）が突き合わせて解釈する方が、月次のような低頻度・高文脈の分析には向いていると判断しました。Screaming FrogにはGA/GSCとの統合機能もありますが、これはマクロ分析には使わず、個別URLを深掘りするときの補助にとどめています。

全体アーキテクチャ

hp-analytics/
├── _shared/
│   ├── templates/        # レポート・PDFシェルのテンプレート
│   └── scripts/          # Screaming FrogクロールとPDF生成の共通スクリプト
├── atau-dd/               # 自社サイト
└── client-<name>/         # クライアントサイト（1クライアント1ディレクトリ）
    ├── CLAUDE.md           # サイト固有情報・過去の知見の蓄積場所
    ├── action-plan-tracker.md
    └── reports/YYYY-MM/report.md

データ取得の役割分担は次の通りです。

• GA4: Google公式のanalytics-mcpをMCP経由で利用
• GSC: コミュニティ製のGSC用MCPを利用（1リクエスト5,000行の上限があるため、大規模サイトは期間・URLセグメントを分割して取得）
• Screaming Frog: あえてMCP化せず、Bashツールから直接CLIを叩く

認証は全ツール共通でADC（Application Default Credentials）を使い、分析用のGoogleアカウントをクライアントのGA4・GSCに「閲覧者」として招待してもらう運用です。書き込み権限は付与していません。

こだわったポイント1：Screaming FrogだけMCP化しなかった

3ソースのうち2つはMCP経由、Screaming FrogだけはBashツールからCLIを直接呼び出しています。理由は、Screaming Frogのエクスポート項目名がバージョンによって変わり、指定した項目名が存在しない場合に警告なく黙って失敗するためです。

これをMCP越しに隠蔽してしまうと、失敗に気づけないままレポートに欠損データが混ざるリスクがあります。そこで共通スクリプト（run-screaming-frog-crawl.sh）では、クロール実行前に必ず--help export-tabsで現バージョンのタブ名一覧を取得し、指定項目がすべて存在するかを確認してから実行するようにしました。1つでも不一致があればクロールごと中止します。

AVAILABLE_TABS="$("$SF_BIN" --help export-tabs 2>&1)"
for tab in "${EXPORT_TABS[@]}"; do
  if ! grep -qF "$tab" <<< "$AVAILABLE_TABS"; then
    echo "警告: タブ '${tab}' は現バージョンに存在しません" >&2
    missing=1
  fi
done

「便利だからとりあえずMCP化する」のではなく、ツールの失敗モードを見てから統合方法を選ぶようにしています。

こだわったポイント2：初回モードと定例モードを自動判定する

月次レポートには「初回」と「2回目以降（定例）」で必要な情報量が違います。初回は基準値づくりのためGA4・GSC・SFを広く洗い出す必要がありますが、定例は前月のアクションプランの効果検証が主目的になります。

このモード判定を、reports/配下の当月フォルダを除いた過去月にreport.mdが実在するかどうかで機械的に行うようにしました。単純に「サブフォルダの有無」で判定しないのがポイントです。生データ（raw-data/）の収集はレポート執筆より先に行われるため、当月フォルダ自体は分析開始時点ですでに存在し得ます。フォルダの存在ではなく、成果物（report.md）の存在で判定することで、誤判定を防いでいます。

こだわったポイント3：アクションプランの表記ゆれを潰す

アクションプランはaction-plan-tracker.mdという単一の台帳で月をまたいで蓄積し、ステータスは「未着手」「対応中」「完了」「保留」の4語に固定しています。「進行中」「済」のような表記ゆれを許すと、翌月以降にAIが前月の未完了項目を機械的に拾えなくなるためです。完了した項目も行を削除せず履歴として残し、定例モードでは「未着手」「対応中」の項目を効果検証の最優先対象として扱います。

小さなルールですが、これがないと数ヶ月分のレポートを積み重ねたときに「結局あの課題は対応したんだっけ」を人力で追う羽目になります。

実際に自社サイトで走らせてみたら

まず自社サイト（atau-dd）で初回分析を実行してみました。結果、こちらが気づいていなかった問題が複数見つかりました。

• サイトマップが3ヶ月近く再取得されていなかった。最終ダウンロードが5月下旬で止まっており、それ以降に追加したブログ記事を含む主要ページがGoogleに一度も発見されていない状態でした。URL検査で実査した主要8ページは全件「URL is unknown to Google」。
• 問い合わせフォームの送信がGA4のコンバージョンとして計上されていなかった。イベント自体は発生していたのに、キーイベント未登録のためKPIである問い合わせ数がレポート上に表れない状態でした。
• 一方でScreaming Frogのクロールでは4xx/5xxエラーやリダイレクトチェーンは0件と、技術的な衛生状態自体は良好であることも確認できました。

どれも致命的な設定ミスというほどではありませんが、「毎月人力で見ていたら気づくのに時間がかかっていたはず」の類の問題です。3ソースを機械的に突き合わせたことで、サイトマップ・インデックス状況・コンバージョン計測という別々のツールにまたがる問題を一度に洗い出せたのは、狙い通りの結果でした。

これから

現在はクライアントサイトへの横展開を進めている段階です。クライアント向けにはレポートをPDF化する仕組み（表紙・ヘッダーフッター・見出しスタイルを共通テンプレートで統一）も用意しており、納品物としての体裁を整えているところです。

自社サイトの運用でパイプラインの精度を確認してから外に展開する、という進め方は、以前紹介したAIチャットボットの開発でも取った方針と同じです。まず自分たちの現場で実際に使い、粗が見えたら直す。そのサイクルを積み重ねることが、結局はクライアントへの提供価値の質につながると考えています。

おわりに

月次レポートは「作ること」自体が目的ではなく、そこから次のアクションが生まれることに意味があります。今回のパイプラインは、レポート作成の工数を減らすだけでなく、人力では見落としがちな複数ソースにまたがる問題を機械的に拾い上げる仕組みとしても機能し始めています。

Webサイトの分析や改善にお悩みの方は、チャットボット経由・お問い合わせフォームどちらからでもお気軽にご相談ください。