散らかったサイトの診断を始めるとき、最初に用意するのは Search Console（GSC）と Google Analytics 4（GA4）のデータです。管理画面を開いて CSV をダウンロードして AI に渡す運用でも始められます。ただし、その運用では毎回手で取り直すことになり、しばらくすると AI が古い CSV を根拠に提案を続けます。
結論から書きます。GSC と GA4 のデータは、AI が自分で API から取れる状態にします。管理画面からの手動エクスポートではなく、スクリプト 1 本でその場の最新データを取る形にすると、診断の土台が常にライブになります。
- GSC からは「ページ」「クエリ」「ページ×クエリ」の3種類を取る
- GA4 からは月別のセッション・PV・ユーザー数を取る
- GSC は直近3日分のデータが未確定なので、終了日を3日前にする
- 認証ファイルの置き場所をプロジェクトごとに分けると、片方が壊れたときに両方が止まる
この記事は、散らかったサイトを AI で作り変えるマニュアルの「診断」の最初の作業です。診断のまとめ記事で使う全データが、ここでそろいます。
目次
この作業で決まること
この作業が終わると、AI が診断のたびにライブのデータを取れる状態になります。人が管理画面を開いてCSVをダウンロードする手順は、以降の作業からなくなります。
ライブで取れるのは次の4つです。
- GSC のページ別データ（URL・クリック・表示回数・CTR・掲載順位）
- GSC のクエリ別データ（検索語ごとの実績）
- GSC のページ×クエリの2次元データ（同じクエリにURLが複数出ていないかを1列で判定できる）
- GA4 の月別データ（PV・セッション・ユーザー・エンゲージ）
ライブのデータが無いと何が起きるか。AI は前回取った CSV を根拠にします。1 週間前の順位で「この記事を直す」と提案し、すでに修正済みの記事をもう一度直そうとします。ライブに差し替えると、提案の対象が常に今のサイトになり、同じ記事を短い間に何度も触る失敗を防げます。
よくある失敗：Looker Studio や管理画面の画像を AI に渡して診断させること。画像は数値を正確に読めず、絞り込みも AI 側ではできません。CSV として API から取るほうが安定します。
前提：この記事の前に必要なもの
- AIに渡す4つの前提がファイルとして用意されていること
- Python が動く環境と、GSC・GA4 の所有権を持った Google アカウント
- Google Cloud Console で OAuth クライアント ID（デスクトップアプリ）を作れること
- 自分のサイトが GSC に登録済みで、GA4 のプロパティ ID が分かること
GSC と GA4 の仕様や設定方法は Search Console ヘルプと Google Analytics ヘルプの記載に従います。
AIに渡すもの
AI に書かせるのは、次の2本のスクリプトです。
- GSC 取得スクリプト：OAuth のデスクトップフローで認証し、「ページ」「クエリ」「ページ×クエリ」の CSV を data/ 以下に保存する
- GA4 取得スクリプト：GSC と同じ OAuth クライアント ID を使い、月別の指標を CSV に保存する
AI には次の3つを渡します。
- サイトの URL と GA4 のプロパティ ID：GSC は末尾のスラッシュまで含めて正確に書く
- 認証ファイルの置き場所：OAuth クライアントの JSON と、保存されるトークンの保存先
- 保存ファイル名の規約：以降のスクリプトが読む名前を固定する（例：gsc_28days_pages.csv、gsc_28days_page_query.csv、ga4_monthly.csv）
ファイル名を固定する理由は、診断・採点・リライトの各スクリプトがこの名前で読みに来るからです。名前が揺れると、別のスクリプトが「ファイルが無い」で止まります。
手順
- Google Cloud Console で OAuth クライアント ID を作る
種類は「デスクトップアプリ」。ダウンロードした JSON を、認証用の共通フォルダに置きます。わたしの構成では、プロジェクトの外側に shared/credentials/ を切り、そこに gsc_oauth_credentials.json を1つだけ置いています。
- GSC と GA4 のそれぞれで、Google アカウントに読み取り権限があることを確認する
GA4 側は、Site Kit か管理画面でプロパティ ID（数字の文字列）を控えておきます。
- GSC 取得スクリプトを AI に書かせる
認証は OAuth デスクトップフロー、トークンは別ファイル（例：gsc_token.json）に保存して以降は自動更新。取得期間は「今日の3日前」を終了日にして、28日間と16ヶ月間の2本を取ります。GSC は直近3日分が未確定なので、3日前を終了日にします。
- ページ×クエリの2次元データも同時に取る
dimensions を ["page","query"] にして取ります。1 ページで 25,000 行の上限があるので、ページネーションで startRow を進めて最後まで取り切ります。これがあると、1クエリに対して自分のURLが2本以上出ているかどうかを CSV の1列で判定できます。
- GA4 取得スクリプトを AI に書かせる
認証は GSC と同じクライアント ID を使い、スコープだけ analytics.readonly に差し替えます。トークンファイルは GSC と別の名前（例：ga4_token.json）にします。dimensions は yearMonth、metrics は sessions / screenPageViews / activeUsers / newUsers / engagedSessions / averageSessionDuration を取ります。
- 初回だけブラウザで認証する
両スクリプトを 1 回ずつ実行し、ブラウザでログインしてトークンを保存します。2 回目以降は、リフレッシュトークンで自動更新されるので操作は要りません。
- 出力ファイルを AI の読み取り対象に登録する
AI が毎回最初に読むファイル（Claude Code なら CLAUDE.md）に、CSV の保存先を書きます。以降は「GSC を見て」で足ります。
完了条件
- ☐
python3 scripts/gsc_api.pyとpython3 scripts/ga4_api.pyが、認証を聞かずに実行できる - ☐ data/ に GSC の 28 日ページ・クエリ・ページ×クエリの3種の CSV が保存されている
- ☐ data/ に GA4 の月別 CSV が保存されている
- ☐ GSC の終了日が、今日の3日前になっている
- ☐ 認証ファイルの置き場所が、プロジェクトの外側で一元化されている
- ☐ CSV のファイル名が固定され、以降のスクリプトがこの名前で読みに行く
実際に起きた失敗
認証ファイルの参照先がずれて、GSC が5週間、GA4 が67日間取れていなかった
わたしは自分のサイトを複数持っていて、プロジェクトごとに取得スクリプトを置いています。あるとき、認証用の共有フォルダを別の場所に移しました。片方のプロジェクトは参照先を新しいパスに直したのですが、もう1本の GSC 取得スクリプトは旧パスのままになっていました。
結果、GSC のデータ取得が5週間止まりました。失敗したのではなく、トークンが切れた時点から静かに動かなくなっていたので、画面上はしばらく気付きません。古い CSV を使って AI が診断を続けていました。
同じドリフトは GA4 側でも起きました。GSC は直したのに、GA4 の取得スクリプトは旧パスのままで、67日間データが更新されていませんでした。
対策は2つです。
- 認証ファイルの置き場所は、プロジェクトの外側で一元化する。プロジェクトごとに credentials を複製しない。
- データの最終更新日を、取得直後に出力する。取得スクリプトが日付のサマリを出し、翌日のレビューが「◯日前のデータ」と認識できるようにする。無言で止まるのが一番危ない。
直近3日分のデータで順位が揺れて見える
GSC は直近3日分のデータが未確定で、徐々に数値が増えていきます。終了日を「今日」にすると、同じクエリの順位や表示回数が日によって動いて見え、AI が「掲載順位が下がった」と誤って判定しやすくなります。
終了日を「今日の3日前」に固定すると、順位の見かけ上の揺れが消えます。取得スクリプトでは end = today - 3日 を既定にして、--start と --end を手で渡したときだけ上書きできるようにしています。この挙動は Search Console ヘルプに書かれています。管理画面でも同じ扱いです。
よくある質問
Q. サービスアカウントではなく、OAuth デスクトップフローを使うのはなぜですか？
A. 自分のサイトを自分の Google アカウントで運用しているので、デスクトップフローのほうが設定が少なくて済みます。初回だけブラウザでログインすると、以降はリフレッシュトークンで自動更新されます。チーム運用でサービスアカウントが必要な場合は、GSC のユーザー追加と GA4 のプロパティ権限の追加が別で要ります。
Q. GSC の16ヶ月データは毎回取るべきですか？
A. 毎日は要りません。28日データは日次で取り、16ヶ月データは週に1回で足ります。16ヶ月は Google が返す上限なので、長期の傾向を見るときの材料になります。
Q. 直近3日分を無理に取りたいときはどうしますか？
A. 取れますが、確定していない数値なので、判断の根拠には使いません。順位の変動を眺めるだけなら差し支えありませんが、リライト対象の判定や統合の判断には、確定後のデータを使います。
関連記事
次の作業
- 全記事の台帳を作り、「今のサイト」をAIの判断の基準にする
- GSC のスナップショットを週次で保存し、順位の差分レポートを作る
- サイトに必要なのは大規模・中規模・小規模どの修正か
