G-gen の本間です。BigQuery の自動化機能であるスケジュールドクエリ（Scheduled queries）を解説します。

概要

スケジュールドクエリとは

スケジュールドクエリ（Scheduled queries）とは、BigQuery において SQL クエリの実行を自動化し、指定したスケジュールで繰り返し実行できる機能です。

日本語の公式ドキュメントでは「スケジュールされたクエリ」と表記されていますが、当記事では実務でも馴染みのある「スケジュールドクエリ」で表現を統一します。

データ分析の現場では、毎日特定の時間に集計レポートを作成したり、1 時間ごとに生データを集計用テーブルに書き込んだりするタスクが頻繁に発生します。スケジュールドクエリを使用することで、外部のオーケストレーションツールやサーバーを用意することなく、BigQuery 単体でこれらのバッチ処理を自動化できます。

またスケジュールドクエリは、BigQuery Data Transfer Service（以下、DTS）の仕組みをベースに提供されています。そのため、内部的には DTS の転送設定として管理されます。

参考 : クエリのスケジューリング
参考 : BigQuery Data Transfer Service の概要

BigQuery の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp

ユースケース

スケジュールドクエリは、以下のようなユースケースに役立ちます。

毎日深夜に、前日分のログデータを集計して日次レポート用テーブルを更新する
1 時間ごとに、生データから不要なカラムを除外したクレンジング済みテーブルを作成する
定期的に特定のクエリを実行し、結果を別のデータセットにあるテーブルへエクスポートする

料金

スケジュールドクエリ自体の機能利用に対する追加料金は発生しません。無料で使用できます。

ただし、スケジュールによって実行された SQL クエリがスキャンしたデータ量に応じて、通常の BigQuery クエリ料金（オンデマンド料金または容量制料金）が発生します。また、クエリ結果を保存するテーブルのストレージ料金も通常通り発生します。

参考 : BigQuery の料金

主な機能と特徴

スケジュール設定

クエリを実行する頻度は柔軟に設定できます。2026年6月現在、以下のような指定方法がサポートされています。

スケジュールの種類	詳細
事前定義された頻度	分、時間、日、週、月
カスタムスケジュール	App Engine Cron 形式による柔軟な日時指定
オンデマンド	スケジュールなし（任意のタイミングで手動実行）

カスタムスケジュールを使用することで、「毎月第 1 月曜日の朝 9 時（1st monday of month 09:00）」や「毎日 10 時から 14 時の間、30 分おき（every 30 minutes from 10:00 to 14:00）」といった複雑なスケジュールにも対応できます。

参考 : クエリのスケジューリング - スケジュールされたクエリを設定する

クエリ結果の書き込み

書き込み方式の概要

スケジュールドクエリの代表的なユースケースは、先述の通りログの定期的な集計や、データマートの作成（ELT 処理）です。そのため、スケジュール実行されたクエリの処理結果は、別のテーブル（ターゲットテーブル）に書き出して保存するのが一般的です。

スケジュールドクエリで処理したデータをターゲットテーブルに書き込むには、主に2つの方法があります。1つは SQL 文内で DML（データ操作言語）を使用する方法、もう1つはスケジュールの設定で「クエリ結果の宛先テーブル」を指定する方法です。

DML を使用した書き込み

クエリの SQL 文内に INSERT、UPDATE、DELETE、MERGE などの DML を直接記述して、テーブルのデータを操作します。複雑な条件でのデータ更新や、複数テーブルに対する柔軟な処理を行う場合に適しています。

参考 : データ操作言語（DML）を使用してデータを更新する

宛先テーブルを指定した書き込み

クエリには SELECT 文のみを記述し、スケジュール設定画面で「クエリ結果の宛先テーブル」オプションを有効化して書き込み先を指定する方法です。この機能を使用する場合、ターゲットテーブルへの書き込みモードとして以下の 2 つから動作を選択します。

モード	動作
テーブルの上書き（`WRITE_TRUNCATE`）	既存のターゲットテーブルのデータをすべて削除し、今回のクエリ結果で完全に置き換えます。
テーブルへの追加（`WRITE_APPEND`）	既存のターゲットテーブルのデータを保持したまま、今回のクエリ結果を末尾に追記します。

ランタイムパラメータの利用

スケジュールドクエリでは、クエリの実行予定時間を動的に表すランタイムパラメータを SQL 文中で使用できます。

利用可能なランタイムパラメータは以下の 2 つです。

パラメータ	説明
@run_time	クエリが実行される予定のタイムスタンプ（UTC）
@run_date	クエリが実行される予定の日付（UTC）

これらを SQL の WHERE 句などに使用することで、「実行時点の前日分のデータだけを抽出する」といった動的な処理ができます。これにより、スケジュール実行のたびに毎回同じデータ全体を無駄にスキャンしたり、処理したりすることを防ぐことができます。

以下の SQL は、実行時点の「前日分」のデータだけを抽出する動的なフィルタリングの例です。

SELECT
  user_id,
  COUNT(event_id) AS event_count,
  @run_date AS summary_date
FROM
  `my-project.raw_data.events`
WHERE
  -- イベント発生日（event_date）が「実行日の前日」であるデータを抽出
  event_date = DATE_SUB(@run_date, INTERVAL 1 DAY)
GROUP BY
  user_id

なお @run_date や @run_time は UTC（協定世界時）で評価されます。日本時間（JST）を基準とした厳密な日次バッチ処理を行う場合は、SQL 内でタイムゾーンの変換（DATE(@run_time, 'Asia/Tokyo') など）を考慮して設計してください。

参考 : クエリのスケジューリング - 利用可能なパラメータ

権限と IAM ロール

クエリの実行主体

スケジュールドクエリには、「スケジュールを設定・管理するプリンシパル（ユーザー）」と「指定した時間に実際にクエリを実行するプリンシパル」の2つが関与します。

スケジュールドクエリを実行するプリンシパルは、デフォルトではスケジュールを設定したユーザーとなります。

この状態で運用を続けると、ユーザーの異動や退職によってアカウントが削除されたり、権限が変更された際に、クエリが失敗する原因になり得ます。

そのため、本番環境の運用では、サービスアカウントをクエリの実行主体として指定することが推奨されます。これにより、スケジュールを設定したユーザーが異動して権限が変更されたり、退職してアカウントが削除されてもスケジュールドクエリに影響が出ないため、安全に運用できます。

BigQuery の認証・認可の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp

スケジュール作成者に必要な権限

スケジュールの設定画面を操作し、ジョブを登録するユーザーには以下の権限が必要です。

目的	必要な IAM ロール	割り当て対象
スケジュールの作成と管理	BigQuery 管理者（`roles/bigquery.admin`）	プロジェクトレベル
サービスアカウントの割り当てと選択	サービスアカウントユーザー（`roles/iam.serviceAccountUser`）サービスアカウント閲覧者（`roles/iam.serviceAccountViewer`）	実行を委譲するサービスアカウント

クエリ実行主体に必要な権限

バックグラウンドで実際にクエリを実行し、データの読み書きを行うアカウントやサービスアカウントには、以下の権限を付与します。

目的	必要な IAM ロール	割り当て対象
クエリの実行	BigQuery ジョブユーザー（`roles/bigquery.jobUser`）	プロジェクトレベル
ソースデータの閲覧	BigQuery データ閲覧者（`roles/bigquery.dataViewer`）	プロジェクトまたはデータセットレベル（抽出元）
ターゲットへの書き込み	BigQuery データ編集者（`roles/bigquery.dataEditor`）	プロジェクトまたはデータセットレベル（書き込み先）

BigQuery の仕様として、「BigQuery データ編集者（roles/bigquery.dataEditor）」ロールにはデータの閲覧権限も含まれています。そのため、データの抽出元と書き込み先が同じデータセット内で完結する場合や、プロジェクトレベルでBigQuery データ編集者ロールを付与する場合は、ソースデータに対して別途「BigQuery データ閲覧者（roles/bigquery.dataViewer）」ロールを付与する必要はありません。プロジェクトやデータセットをまたいで処理を行う場合のみ、抽出元のデータセットに対して閲覧権限を付与してください。

参考 : クエリのスケジューリング - 必要な権限

注意点と制限事項

毎正時（00分）指定における重複実行のリスク

スケジュールを「毎時 00 分（例 : 09:00）」など、「正時」のタイミングに設定すると、内部的なトリガーが複数回起動してしまい、同一のクエリが重複して実行される事象が稀に発生します。

結果として、追記モード（WRITE_APPEND）の際にデータが二重に取り込まれてしまうリスクがあります。これを防ぐため、公式ドキュメントでも 08:58 や 09:03 など、正時から数分ずらしたスケジュールを設定することが推奨されています。

参考 : クエリに関する問題のトラブルシューティング - スケジュールされたクエリが重複して実行される

実行遅延の可能性

スケジュールドクエリの基盤である DTS の仕様上、秒単位での厳密な実行タイミングが保証されているわけではありません。リソース状況等により、実際の実行時刻に遅延（Pending）が発生する可能性がある点に留意して設計してください。

また、Google Cloud の一般的なベストプラクティスとして、「クエリ A の完了を待ってからクエリ B を実行する」といった依存関係の制御や、高度なエラーハンドリングが必要なワークロードにおいては、スケジュールドクエリではなく、Dataform や Cloud Workflows といった専用のワークフロー管理サービスの利用が推奨されています。

概要