第3回 Cloud Run JobsでGSCデータを毎朝自動取得する方法【Cloud Scheduler】

Pythonプログラムが完成しても、パソコンやCloud Shellから手動実行しているだけでは継続的なデータ基盤とはいえません。毎日決まった時刻に処理を動かし、失敗した場合に実行履歴を確認できる状態まで作る必要があります。

第3回となるこの記事では、前回作成したGSC取得プログラムをCloud Run Jobsへデプロイし、Cloud Schedulerから日本時間の毎朝5時に起動します。処理はGoogle Cloud上で実行されるため、自宅のパソコンを起動しておく必要はありません。

最後に、Scheduler経由で再実行してもBigQueryの行数が単純に2倍にならないことを確認します。ここまで完了すると、Gemini Sparkで利用する前提となるGSCデータの自動取得基盤が完成します。

この記事で完成する状態
シリーズ構成
前回までに必要な設定
Cloud Run Jobへ初回デプロイする
1. 途中で質問された場合
BigQueryに保存されたデータを確認する
Cloud Scheduler APIを有効化する
Scheduler専用サービスアカウントを作成する
1. 1．サービスアカウントを作成する
2. 2．この画面ではロールを追加しない
SchedulerアカウントにCloud Run実行権限を付ける
1. 1．IAM画面を開き「アクセスを許可」をクリックする
2. 2．プリンシパルの追加とロールの割り当て
毎朝5時に実行するCloud Schedulerジョブを作成する
1. 1．Cloud Shellを起動する
2. 2．Schedulerジョブを作成する
Cloud Schedulerからテスト実行する
再実行でデータが重複していないことを確認する
第3回のまとめ

この記事で完成する状態

PythonプログラムがCloud Run Jobsへデプロイされている
サービスアカウントでGSC取得とBigQuery保存が成功する
Cloud Schedulerが毎朝5時にCloud Run Jobを起動する
Scheduler専用アカウントには起動権限だけが付与されている
同じ期間を再取得してもBigQueryに重複しない
GSCデータの毎朝自動取得基盤が完成する

シリーズ構成

目次：GSC自動取得からGemini Spark分析までの全体像
第1回：Google CloudとBigQueryの初期設定
第2回：PythonでGSC APIデータを取得・保存
第3回：Cloud Run JobsとCloud Schedulerで毎朝自動実行
第4回：BigQueryのデータをGemini Sparkで分析

前回までに必要な設定

この記事は、第1回と第2回が完了していることを前提にしています。

Google CloudとBigQueryの初期設定が完了している
blog-analytics-runnerサービスアカウントに必要な権限がある
Cloud ShellにPythonプロジェクトが作成されている
main.pyなどの文法チェックが完了している

Cloud Run Jobへ初回デプロイする

ここから実際にクラウド上へ配置します。ただし、まだ定期実行は設定しません。引き続きCloud Shellを利用していきます。

次のコマンドをそのまま実行してください。

gcloud run jobs deploy blog-analytics-gsc \
  --source . \
  --region asia-northeast1 \
  --service-account blog-analytics-runner@lennonsoft-blog-analytics.iam.gserviceaccount.com \
  --tasks 1 \
  --max-retries 1 \
  --task-timeout 30m \
  --memory 1Gi \
  --cpu 1 \
  --project lennonsoft-blog-analytics

この設定内容は次のとおりです。

ジョブ名	blog-analytics-gsc
リージョン	東京
実行アカウント	blog-analytics-runner
同時実行タスク	1
失敗時の再試行	1回
最大実行時間	30分
メモリ	1GB
CPU	1

Cloud Run Jobでは、実行時に使用するサービスアカウントを指定できます。今回は、Search ConsoleとBigQueryの権限を設定したblog-analytics-runnerを指定しています。この作業は少し時間がかかります。

途中で質問された場合

Artifact Registryのリポジトリを作成する確認が出た場合は、yを入力してEnterを押してください。

リージョン候補を聞かれた場合は、asia-northeast1 を選びます。

デプロイ完了後に、Execute the job now? などと聞かれた場合は、今回はNを選んでください。最初の実行は、デプロイ状態を確認してから別タスクで行います。

Job [blog-analytics-gsc] has successfully been deployed.

と出ると、Cloud Run Jobの作成は完了しています。

ここからデプロイしたCloud Run Jobを実行し、GSC APIからBigQueryまで正常に処理できるか確認します。

Cloud Shellで次を実行してください。

gcloud run jobs execute blog-analytics-gsc \
  --region asia-northeast1 \
  --project lennonsoft-blog-analytics \
  --wait

このコマンドは、ジョブ実行が終わるまで待ち、成功または失敗を表示します。成功した場合は、最後に次のような表示が出ます。

Execution [blog-analytics-gsc-xvj8w] has successfully completed.

4サイトのGSC取得処理とBigQuery保存処理まで正常終了しています。

BigQueryに保存されたデータを確認する

次にBigQueryを開きます。Cloud Shellは閉じなくて構いません。

1．BigQueryを開く

Google Cloud Console左上の三本線メニューをクリックしBigQuery→Studioと進んでください。

2．対象プロジェクトを確認する

BigQuery Studioが開いたら、左側の「エクスプローラ」を確認します。

次のプロジェクトlennonsoft-blog-analyticsが表示されていることを確認してください。

その下には、作成済みのデータセットblog_analyticsが表示されていると思います。

blog_analytics の左側にある三角形をクリックすると、今回自動作成されたテーブルが表示されるはずです。

3．新しいSQLクエリを開く

BigQuery Studio画面上部にある、ボタンを押して新しいSQLクエリを作成します。すると次のように「無題のクエリ」が作成され、クエリエディタ画面になります。

空白になっていると思いますが、既に別のSQLが入っている場合は、削除して構いません。

4．確認用SQLを貼り付ける

クエリエディタに、次のSQLをそのまま貼り付けてください。

SELECT
  site_id,
  MIN(data_date) AS start_date,
  MAX(data_date) AS end_date,
  COUNT(*) AS row_count,
  SUM(clicks) AS total_clicks,
  SUM(impressions) AS total_impressions
FROM
  `lennonsoft-blog-analytics.blog_analytics.gsc_query_page_daily`
GROUP BY
  site_id
ORDER BY
  site_id;

5．SQLを実行する

貼り付けたらクエリエディタ上部の青い、実行ボタンを押してください。

6．確認する内容

処理が終わると、画面下部の「クエリ結果」に表が表示されます。

結果に自分のサイトが表示されることを確認してください。私の場合は下記の4サイトが表示されているので成功です。

ai_lennonsoft
hytale_lab
lennonsoft
witcher4

日付は、今回取得した期間である次の範囲になっているはずです。

start_date：2026-07-25
end_date：2026-07-31

保存された明細データを確認する

同じBigQueryのクエリエディタで、現在のSQLを削除して、次を貼り付けて実行してください。

SELECT
  site_id,
  data_date,
  page,
  query,
  device,
  country,
  clicks,
  impressions,
  ctr,
  position
FROM
  `lennonsoft-blog-analytics.blog_analytics.gsc_query_page_daily`
ORDER BY
  data_date DESC,
  impressions DESC
LIMIT 20;

今回は、ページURL・検索キーワード・端末・国などが正しく入っているかを確認します。

なお、今回のテーブルはかなり細かい粒度です。

日付 × ページ × クエリ × デバイス × 国

この形は分析には強いですが、データ量は増えやすいです。今後、GA4やAdSenseも追加することを考えると、明細テーブルとは別にSparkが読みやすい集計テーブルを作る設計が必要です。

次は自動実行の設定へ進みます。まずCloud Scheduler APIを有効化します。

Cloud Scheduler APIを有効化する

次は、完成したCloud Run Jobを毎朝自動実行するための準備です。今回はCloud Scheduler APIの有効化だけ行います。スケジュール自体はまだ作成しません。

1．左メニューからAPIライブラリを開く

Google Cloud Console左上の三本線メニューをクリックし、APIとサービス→ライブラリの順に進んでください。

もし前回の画面から移動するときにBigQueryから

「作業が保存されていません。終了してもよろしいですか」と聞かれたら、保存せずに終了ボタンを押しても構いません。

2．Cloud Scheduler APIを検索する

APIライブラリの検索欄に、Cloud Scheduler APIと入力します。検索結果から、似た名前の別サービスではなく、正確に「Cloud Scheduler API」を選んでください。

3．APIを有効化する

API詳細画面で、有効にするをクリックしてください。

Cloud Schedulerを使ってCloud Run Jobを定期実行するには、対象プロジェクトでCloud Scheduler APIを有効にする必要があります。

Scheduler専用サービスアカウントを作成する

1．サービスアカウントを作成する

Google Cloud Console左上の三本線メニューからIAMと管理→ サービスアカウントと進んでください。

そして画面上部の、サービスアカウントを作成をクリックします。

次の画面のように内容を入力後、作成して続行ボタンを押してください。

サービスアカウント名：Blog Analytics Scheduler
サービスアカウントID：blog-analytics-scheduler
サービスアカウント説明：Cloud Schedulerからブログ分析用Cloud Run Jobを起動する専用アカウント

自動で作成されるメールアドレス：
blog-analytics-scheduler@lennonsoft-blog-analytics.iam.gserviceaccount.com

2．この画面ではロールを追加しない

「権限」と「アクセス権を持つプリンシパル」は何もせずそのまま完了ボタンを押してください。

注意点

このアカウントはデータを取得・保存するのではなく、Cloud Run Jobを起動するだけです。なので次のようなロールは付けないでください。

オーナー
編集者
BigQuery Data Editor
BigQuery Job User

SchedulerアカウントにCloud Run実行権限を付ける

今回は、作成したScheduler専用アカウントに「Cloud Run Jobを起動する権限」だけを追加します。

1．IAM画面を開き「アクセスを許可」をクリックする

Google Cloud Console左上の三本線メニューから、IAMと管理→ IAMと進んでください。

次に、IAM画面にある、アクセスを許可をクリックしてください。

Schedulerアカウントは、まだプロジェクト単位のロールを持っていないため、一覧から探して編集するのではなく、新しいアクセス権として追加します。

2．プリンシパルの追加とロールの割り当て

アクセス権付与の画面になったら、下記のようにプリンシパルの追加とロールの割り当てを行います。

プリンシパルの追加
blog-analytics-scheduler@lennonsoft-blog-analytics.iam.gserviceaccount.com

ロールを割り当てる
Cloud Run 起動元

このロールには、Cloud Runサービスを呼び出す権限とCloud Run Jobを実行する権限が含まれます。

入力が終わったら保存ボタンを押してください。

毎朝5時に実行するCloud Schedulerジョブを作成する

今回はCloud Shellからスケジュールを作ります。毎朝5時にGSC取得を開始する設定です。

1．Cloud Shellを起動する

Google Cloud Console右上にある、次のアイコンをクリックしてください。

2．Schedulerジョブを作成する

Cloud Shellに次のコマンドをそのまま貼り付けて実行してください。

gcloud scheduler jobs create http blog-analytics-gsc-daily \
  --location asia-northeast1 \
  --schedule "0 5 * * *" \
  --time-zone "Asia/Tokyo" \
  --uri "https://run.googleapis.com/v2/projects/lennonsoft-blog-analytics/locations/asia-northeast1/jobs/blog-analytics-gsc:run" \
  --http-method POST \
  --oauth-service-account-email "blog-analytics-scheduler@lennonsoft-blog-analytics.iam.gserviceaccount.com" \
  --oauth-token-scope "https://www.googleapis.com/auth/cloud-platform" \
  --description "毎朝5時に4サイトのGSCデータを取得してBigQueryへ保存" \
  --max-retry-attempts 1 \
  --project lennonsoft-blog-analytics

この設定内容は次のとおりです。

Schedulerジョブ名	blog-analytics-gsc-daily
実行時刻	毎朝5:00
タイムゾーン	日本時間
実行対象	blog-analytics-gsc
認証	blog-analytics-scheduler
失敗時の再試行	1回

Cloud Run Jobの定期実行では、Cloud Run Admin APIの:runエンドポイントへPOSTし、OAuthサービスアカウントで認証します。時刻は--time-zone "Asia/Tokyo"を明示しているため、日本時間の毎朝5時として処理されます。

正常に作成されると、次のような情報が表示されます。

name: projects/lennonsoft-blog-analytics/locations/asia-northeast1/jobs/blog-analytics-gsc-daily
schedule: 0 5 * * *
timeZone: Asia/Tokyo
state: ENABLED

Cloud Schedulerからテスト実行する

Cloud Shellで次のコマンドを実行してください。

gcloud scheduler jobs run blog-analytics-gsc-daily \
  --location asia-northeast1 \
  --project lennonsoft-blog-analytics

正常に実行要求を送れた場合は、エラーが表示されず入力待ちに戻るか、実行を開始した旨が表示されます。

このコマンドはCloud Run Jobの完了を待つものではなく、Schedulerから起動要求を送るテストです。実行後、30秒から1分ほど待ってから、次のコマンドを実行してください。

gcloud run jobs executions list \
  --job blog-analytics-gsc \
  --region asia-northeast1 \
  --project lennonsoft-blog-analytics \
  --limit 3

一覧の一番上に新しい実行が追加され、SUCCEEDEDになっていれば、次の経路すべてが正常です。

Cloud Scheduler
→ Scheduler専用サービスアカウント
→ Cloud Run Job
→ GSC API
→ BigQuery

再実行でデータが重複していないことを確認する

Schedulerからもう一度取得処理を動かしたため、同じ期間のデータが二重登録されていないか確認します。

左上の三本線メニューから、BigQuery → Studioを開いてください。以前のクエリエディタをそのまま使って構いません。現在のSQLを削除し、次を貼り付けます。

SELECT
  site_id,
  MIN(data_date) AS start_date,
  MAX(data_date) AS end_date,
  COUNT(*) AS row_count,
  MAX(fetched_at) AS latest_fetched_at
FROM
  `lennonsoft-blog-analytics.blog_analytics.gsc_query_page_daily`
GROUP BY
  site_id
ORDER BY
  site_id;

「実行」を押してください。

確認するポイントは、行数が前回とほぼ同じであることです。

同じ期間のデータを削除してから再登録しているため、単純に2倍にはならないはずです。

これでGSCデータの自動取得基盤は完成です。

毎朝5時に実行
↓
直近7日分を再取得
↓
同じサイト・同じ期間の既存データを削除
↓
最新データへ置き換え

次はGemini Sparkから読みやすい形にするため、BigQueryの明細データから「サイト別・ページ別の集計データ」を作る段階へ進みます。ここは重要です。今の明細テーブルをSparkにそのまま読ませると、データ量が多く、分析も不安定になりやすいためです。

第3回のまとめ

これで、4サイト分のGSCデータを毎朝5時に取得し、BigQueryへ自動保存する仕組みが完成しました。パソコンを起動しておく必要はなく、Cloud Scheduler、Cloud Run Jobs、Search Console API、BigQueryの経路がクラウド上で完結します。

ただし、現在の明細テーブルは「日付 × ページ × クエリ × デバイス × 国」という細かい粒度です。このままGemini Sparkへ渡すとデータ量が多く、分析の目的も伝わりにくくなります。

第4回では、BigQuery上にページ別・サイト別の集計ビューを作り、Googleスプレッドシートへの出力を経て、Gemini Sparkが分析しやすいデータへ整えます。

第4回：BigQueryのGSCデータをGemini Sparkで分析する