AIデジマ研究所

計測の土台を確かめる｜Search ConsoleとGA4の認証切れで判断がぶれる前に

2026-10-15 ・ 診断

診断を始める前に、Search Console と GA4 のデータが「今日の状態」で取れていることを確かめます。この確認を飛ばすと、どの記事から直すかの判断が、何週間も前のデータで固まったまま動きます。

結論から書きます。計測の土台は、認証ファイルの場所・自動取得の心拍・データの鮮度チェック、の3つで固めます。この3つのどれかが欠けると、取得が止まっていることに誰も気づけないまま、古いデータで記事を直し続けることになります。

この記事は、散らかったサイトをAIで作り変えるマニュアルの「診断」の作業です。全記事の採点やカニバリの判定を始める前に、ここを通してください。

この作業で決まること

この作業が終わると、AIが毎回ライブで Search Console と GA4 のデータを読める状態になります。あわせて、取得が止まったときに自分で気づける仕組みが入ります。

人が毎週コンソールにログインして CSV をダウンロードする運用はやめます。手動の取得は、忙しくなった週に抜けます。数週間してから「あのとき止まっていた」と気づく形で事故になります。

よくある失敗：ダッシュボードに数字が表示されているから計測は動いている、と判断すること。表示されているのは過去のデータです。最後に更新された日付を見ないと、取得が止まっていることに気づけません。

前提：この記事の前に必要なもの

Google Cloud Console の画面は Google の都合で変わります。手順の詳細はSearch Console API の公式ページとGA4 Data API の公式ページで確認してください。

AIに渡すもの

  1. OAuth のクライアント認証情報：Google Cloud Console でデスクトップアプリ用に作る gsc_oauth_credentials.json
  2. 取得スクリプト：Search Console からクエリ・ページ・表示回数・クリック・順位を取るもの、GA4 からセッション・ユーザー数・PV を取るもの
  3. 保存先の決まり：認証ファイルは絶対パスで参照する決まった場所に置く
  4. 自動実行の設定：macOS なら launchd、Linux なら cron
  5. 鮮度チェック：取得した CSV の最終更新日が決めた日数より古ければ、判定を止める

Search Console と GA4 は、同じ OAuth クライアント認証情報を使い回せます。GSC で webmasters.readonly の権限、GA4 で analytics.readonly の権限を要求するだけで、同じ Google アカウントなら両方のトークンが別ファイルに保存されます。

手順

  1. Google Cloud Console でプロジェクトを作る

新規プロジェクトを作り、Search Console API と Google Analytics Data API を有効化します。「認証情報」から OAuth 2.0 クライアント ID を「デスクトップアプリ」として作り、JSON をダウンロードします。

  1. 認証ファイルを絶対パスの決まった場所に置く

作業ディレクトリの中の shared/credentials/gsc_oauth_credentials.json のように、サイトごとではなく共有の場所に置きます。複数のサイトを同じ Google アカウントで運用している場合、1つのクライアント認証情報で全部まかなえます。

  1. GSC の取得スクリプトを初回実行する

スクリプトを実行すると、ブラウザが開いて Google ログインを求められます。ログインすると gsc_token.json が作られ、次回以降はブラウザが開きません。トークンは期限切れになるとリフレッシュトークンで自動更新されます。

  1. GA4 の取得スクリプトを初回実行する

同じ OAuth クライアント認証情報で、GA4 のスコープを求める形で再度ブラウザログインします。別ファイルの ga4_token.json が作られます。GA4 では、取得したいプロパティのプロパティID（9桁の数字）を GA4 の管理画面で確認してスクリプトに書きます。

  1. 取得スクリプトを launchd / cron に乗せる

手動実行をやめ、週1回など決まった頻度で自動的に走らせます。失敗時はログに残る形にします。

  1. 判定側に鮮度チェックを入れる

AIが参照する CSV について、「最終更新日が N 日より古ければ、採点やリライトの判定を止める」という処理を1か所に書きます。古いデータで判定が走り続ける事故を、ここで止めます。

  1. AIが毎回最初に読むファイルに、保存場所と最終更新日の確認方法を書く

前提ファイル（CLAUDE.md など）に「Search Console のライブデータは data/gsc_28days_pages.csv にある。最終更新日が7日より古ければ再取得する」と書き、AIが自分で鮮度を確かめられるようにします。

完了条件

実際に起きた失敗

相対パスで共有認証を参照して、GSC の取得が5週間止まっていた

自分のサイトの運用で、新しく公開する記事の本数を Search Console のデータで自動判定する仕組みを作ろうとしたときのことです。使う CSV を見ると、最終更新日が35日前の日付で止まっていました。

原因は、取得スクリプトが参照する OAuth トークンのパスにありました。トークンは共有の credentials ディレクトリに置いていましたが、スクリプトからは相対パスで参照していました。上位のディレクトリ名を途中で変えたとき、スクリプトのパスだけ古い名前を指したまま残り、トークンが読めなくなっていました。取得は失敗していましたが、スクリプトを定期実行の仕組みに乗せていなかったため、失敗したこと自体に誰も気づきませんでした。5週間の間、AIは6月19日のデータで記事の優先順位を決め続けていました。

同じ事故は GA4 側でも起きていました。GSC のパスを直した時点では GA4 のスクリプトを見ておらず、GA4 のトークンだけ古いパスを指したまま残って、取得が67日間止まっていました。

直し方は3つで、全部やりました。1つ目は、共有の認証ファイルは絶対パスか環境変数で参照する決まりにしました。2つ目は、取得スクリプトを launchd に登録し、週1回必ず走る心拍を持たせました。3つ目は、判定側に「CSV が N 日より古ければ止まる」というチェックを入れました。どれか1つでも入れておけば、5週間止まることは起きませんでした。

トークンを差し替える前に、読み取りだけで動作を確かめた

このとき、「トークンを新しいパスに差し替えれば直るはず」と決め打ちで作業を進めることもできました。ただ、差し替えた結果もう一度ブラウザ認証を求められると、作業時間が延びます。

そこで、新しい場所にあるトークンをスクリプトに読み込ませ、Search Console の sites().list() を叩いて、対象のサイトのプロパティに実際にアクセスできるかだけを先に確かめました。読み取りだけの操作なので、既存の設定を壊しません。アクセスできることを確認してから、参照先のパスを書き換えました。

AIに作業を任せるときも同じで、「直す前に、読み取りだけで現状を確かめる」ことを手順に書いておきます。AIが「直せるはず」と推測で書き換えを始めると、復旧が遅くなります。

よくある質問

Q. GSC と GA4 の認証を別々にする必要はありますか？
A. ありません。同じ OAuth クライアント認証情報を使い回し、GSC 用と GA4 用のトークンを別ファイルで持つのが簡単です。同じ Google アカウントなら、個人で持っている複数のサイトのプロパティにも、1つの認証で届きます。

Q. 定期実行は自分のPCでいいのですか？
A. 自分のPCで足ります。macOS なら launchd、Linux なら cron を使い、週1回など決まった時間に走らせます。大事なのは「決まった頻度で動く」ことです。手動実行をやめ、失敗したときにログが残る形にしてください。

Q. データが古いときに判定を止めると、作業が止まりませんか？
A. 古いデータで作業を進めるほうが、あとで戻れない事故につながります。「止める」の中身は、採点やリライトなどデータに基づく判断を一時停止することで、再取得を促します。判定が止まったという通知を自分に送る形にしておくと、気づいて取得を直せます。

関連記事

次の作業