Google Cloud · Field note

Dataform 入門: Scheduled Queries の次に検討する宣言的アプローチ

Dataform は Scheduled Queries の完全置き換え先ではなく、宣言的アプローチへの入口です。依存関係・テスト・バージョン管理という Scheduled Queries の限界に直面したタイミングで、段階的に比重を移していける設計になっています。

Published

2026年5月9日

Read

12 min

Author

tgeas

Scheduled Queries が「次の壁」にぶつかるとき
Dataform の位置付け ── 「宣言型」とは何を意味するか
SQLX が解く問題 ── ${ref()} と assertions の最小例
実行モデルと料金 ── 動かす前に知っておく 2 つの構成
Cloud Composer・dbt との立ち位置 ── Dataform が不得意な領域
まとめ ── 1 SQLX から始める宣言的アプローチへの移行
参考文献

本記事では、BigQuery の Scheduled Queries を使ったデータパイプラインの次の選択肢として、Dataform の位置付けを整理します。設計上の違い、SQLX の基本文法と実行モデル、料金の考え方、Cloud Composer や dbt との立ち位置を順に整理します。Dataform の全体像を把握することで、「今の Scheduled Queries 構成をいつ・どこから変えるか」の判断材料を手に入れましょう。

Scheduled Queries が「次の壁」にぶつかるとき

BigQuery の Scheduled Queries は、定期的に SQL を実行してテーブルを更新する仕組みです。設定がシンプルで、BigQuery コンソールから数ステップで動き始める手軽さが魅力です。

ただし、BigQuery の公式ドキュメントは Scheduled Queries について次のように述べています。

これは最も簡単なスケジュール設定の手法ですが、外部依存関係のない単純なクエリチェーンの場合に限定することをおすすめします。

出典: Orchestrate workloads | BigQuery

この「単純なクエリチェーン」という括り書きが、実務で最初の壁になります。パイプラインが成長するにつれて、次のような問題が積み重なっていきます。

依存テーブルの増加と実行順序の管理。 A → B → C という変換の連鎖が増えると、Scheduled Queries は実行順序を自動で解決しません。時刻をずらしてスケジュールを組むことになりますが、上流が遅延したときの対処がカレンダー任せになります。

再実行とバックフィルの難しさ。 上流テーブルのデータが遡って修正されたとき、影響する下流クエリを洗い出して手動で再実行する必要があります。影響範囲の把握に時間がかかるうえ、再実行の手順がドキュメント化されていないと属人化します。

SQL ファイルの分散とバージョン管理の困難さ。 Scheduled Queries の SQL はコンソール上で管理されます。Git と連携する仕組みがなく、変更履歴が追えません。テーブルが 20 件、30 件と増えてくると、「どのクエリがどのテーブルに依存しているか」を把握する手がかりがコンソール画面だけになります。

こうした構造的な限界に直面したとき、次の選択肢として挙がるのが Dataform です。

Dataform の位置付け ── 「宣言型」とは何を意味するか

Dataform は 2020 年に Google Cloud に買収され、2023 年に一般提供（GA）となったサービスです。現在は BigQuery コンソールに統合されており、別途サービスへのアクセス手順なしに利用を開始できます。

公式には次のように定義されています。

データアナリストが BigQuery でデータ変換を行う複雑なワークフローを開発、テスト、バージョン管理、スケジュール設定するためのサービス。

出典: Dataform overview | Google Cloud

Scheduled Queries との最大の違いは、命令型か宣言型か、という設計哲学にあります。公式ドキュメントはこう説明しています。

DML では、データの変換方法を正確に BigQuery に指示することで命令型アプローチを取りますが、Dataform では宣言型ステートメントを記述し、Dataform がその状態を実現するために必要な変換を決定します。

出典: Introduction to data transformation | BigQuery

噛み砕くと、Scheduled Queries は「この SQL をこのタイミングで実行せよ」という命令を書く形です。一方 Dataform は「このテーブルはこのクエリ結果であるべき状態だ」と宣言する形で、実行計画の組み立ては Dataform 自身が行います。

「宣言型」という言葉は抽象的に聞こえますが、実務上の効果はシンプルです。テーブル間の依存関係を記述しておくと、Dataform が DAG（有向非巡回グラフ）── 上流から下流への依存を矢印でつないだフローチャートのようなもの ── を自動で構築し、正しい実行順序を決定します。依存関係の管理が手書きのスケジュール調整から解放される点が、Scheduled Queries との最も大きな設計上の差です。

SQLX が解く問題 ── `${ref()}` と assertions の最小例

Dataform の記述形式は SQLX と呼ばれます。SQL に config ブロックと Dataform 固有の関数を追加したファイル形式で、拡張子は .sqlx です。

最小限の SQLX ファイルは次のような構成になります。プレースホルダー your_project、your_dataset、source_table は実際のプロジェクト・データセット・テーブル名に置き換えてください。

config {
  type: "table",
  assertions: {
    nonNull: ["user_id", "event_date"],
    uniqueKey: ["user_id", "event_date"]
  }
}

SELECT
  user_id,
  event_date,
  COUNT(*) AS event_count
FROM ${ref("source_table")}
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY user_id, event_date

このファイルで 3 つの問題が同時に解決されます。

config { type: "table" } による出力種別の宣言。 table（毎回全件置換）、view（ビュー定義）、incremental（差分追記）の 3 種から選びます。出力先テーブルの管理方法をコードで宣言する形になるため、コンソール上の設定と SQL が乖離する問題がなくなります。

${ref("source_table")} による依存関係の記述。 ref() 関数に参照したいテーブル名を書くと、Dataform はそのテーブルへの依存を自動的に DAG に組み込みます。複数のファイルが同じテーブルを参照していても、参照元テーブルが先に実行されることを保証します。テーブル名が変わったとき、ref() の引数を変更するだけで依存関係が更新されます。

assertions によるデータ品質テストの宣言。 nonNull は指定列に NULL がないことを、uniqueKey は指定列の組み合わせが一意であることを検証します。テーブルを更新するたびにこのチェックが自動実行され、違反があるとワークフローが失敗します。品質チェックを別のクエリで書いて別スケジュールで実行する、という手間がなくなります。

実行モデルと料金 ── 動かす前に知っておく 2 つの構成

Dataform でパイプラインを定期実行するまでには、2 つの設定オブジェクトを理解しておく必要があります。

リリース構成（Release Configuration）。 Git リポジトリのどのブランチをコンパイル対象にするか、コンパイル頻度はどうするか、プロジェクト・スキーマをどう上書きするかを定義します。本番用・開発用といった環境の切り替えは、このリリース構成で制御します。

ワークフロー構成（Workflow Configuration）。 リリース構成を参照し、「何を実行するか（全アクション・タグ指定・特定テーブル選択）」と「いつ実行するか（cron スケジュール）」を設定します。この 2 層構造を通じて、コードとスケジュールが分離されます。たとえば「main ブランチのコードを毎日 6 時に全アクション実行する」という設定は、リリース構成（main ブランチ・毎日 6 時にコンパイル）とワークフロー構成（そのリリース構成を参照して全アクションを実行）の組み合わせで表現します。

スケジュール実行の手段はワークフロー構成だけではありません。公式ドキュメントは次の 4 経路を案内しています。

Dataform のワークフロー構成（最もシンプル）
Workflows + Cloud Scheduler の組み合わせ
Cloud Composer（Managed Apache Airflow）経由
Cloud Build トリガー経由

入口としては、まずワークフロー構成を使うのが最も設定コストが低い選択です。外部システムとの連携が必要になった段階で、Cloud Composer などへの移行を検討するのが自然な流れです。

料金の考え方。 Dataform 本体の利用料金は無料です（2026-05-09 時点、cloud.google.com/dataform/pricing）。実際に発生するコストは次の 3 つです。

BigQuery のクエリ実行料金（Dataform が発行するクエリのスキャン量に応じた課金）
Cloud Logging（実行ログの書き込みに応じた料金）
選択したスケジュール実行リソース（Cloud Composer などを使う場合はその料金）

BigQuery のオンデマンド料金は asia-northeast1（東京）で 1 TiB あたり 7.50 USD（1 USD = 155 円換算で約 1,163 円、2026-05-09 確認）です。Dataform の導入でクエリ量が増えるわけではありませんが、assertions の分だけ追加のスキャンが発生する点は把握しておく必要があります。

また、Dataform は asia-northeast1（東京）および asia-northeast2（大阪）リージョンに対応しています。BigQuery のデータセットと同じリージョンにワークフロー構成を置くことで、余計なネットワーク転送料金を避けられます。

Cloud Composer・dbt との立ち位置 ── Dataform が不得意な領域

Dataform、Scheduled Queries、Cloud Composer の 3 つは、BigQuery 公式ドキュメントに比較情報が掲載されています。公式の比較情報を参考に、Scheduled Queries も含めて独自に整理した比較は次のようになります（参照元: docs.cloud.google.com/bigquery/docs/orchestrate-workloads）。

項目	Dataform	Scheduled Queries	Cloud Composer
焦点	データ変換	限定的なスケジュール実行	ETL/ELT 全般
複雑さ	低	低	高
コードタイプ	JavaScript / SQL / Python ノートブック	SQL	Python
サーバーレス	はい	はい	いいえ（フルマネージド）
不得意な領域	外部サービスとの連携	依存関係があるパイプライン	低レイテンシ・イベントドリブン処理

Dataform が不得意とするのは、BigQuery 外のサービス（Salesforce・Pub/Sub など）を組み込んだオーケストレーションです。BigQuery のテーブル間の変換に特化した設計になっているため、外部 API の呼び出しや、ファイル転送を伴う複雑なフローは Cloud Composer が適しています。

また、イベントが届いたらすぐに処理する低レイテンシのリアルタイム変換には、Dataform よりも Dataflow の利用が適しています。Dataform は分単位以上のバッチ変換を前提とした設計です。

dbt との関係について。 構造上の違いとして明確なのは次の点です。

Dataform は Google Cloud マネージドで、BigQuery コンソールに統合されており、利用自体は無料です。dbt は Google Cloud 外のオープンソースプロジェクトであり、Cloud Composer 経由での統合手順が公式に案内されています（cloud.google.com/composer/docs/composer-2/dbt-composer-integration）。

SQLX と dbt の Jinja テンプレートは設計思想が近い部分もありますが、実行基盤・管理コスト・エコシステムの面で異なります。すでに dbt を使っている環境では、Cloud Composer 経由での運用継続も有力な選択肢です。

まとめ ── 1 SQLX から始める宣言的アプローチへの移行

Dataform は Scheduled Queries の「全置き換え先」ではありません。1 SQLX ファイルから並行運用を始められる宣言的アプローチへの入口であり、依存関係・テスト・バージョン管理という構造的な限界に直面したタイミングで、自然に比重を移していける設計です。

「Scheduled Queries のどの問題を解決したいか」で、移行の優先度を判断する材料は次のように整理できます。

実行順序の手動管理が限界になった → ${ref()} で依存関係を宣言することで解消できます
データ品質のチェックを別クエリで書いている → assertions に統合することで、テーブル更新と品質検証を同じファイルで管理できます
SQL の変更履歴が追えない → Dataform のリポジトリは Git 連携を前提とした設計のため、コードレビューと履歴管理が自然に組み込まれます
外部サービス連携や低レイテンシ処理が必要 → Cloud Composer や Dataflow との組み合わせを検討するタイミングです

1 本目の SQLX ファイルを書いて既存の Scheduled Queries の結果と照合してみるところから、移行の判断材料が積み上がっていきます。

参考文献