AI にデータパイプラインを作らせる基盤は月いくらか:BigQuery Data Engineering Agent と dbt State を 10 GB / 100 GB / 1 TB で試算

Google ドライブの表計算ファイルを入力に、BigQuery Data Engineering Agent と dbt でパイプラインを作る構成を、東京の料金表から 3 規模で月額に換算。AI に任せられる範囲と人に残る作業も整理します。

23分で読めます Data
表計算ファイルから AI が組んだパイプラインの箱を通り、データ量に応じて高さの違う 3 本の料金の棒へ流れ込む様子を表した抽象的なイラスト
この記事は AI が下書きを補助し、運営者が内容を確認して公開しています。

社内のデータを 1 か所にまとめる役を任された、1 人目のデータ担当の方向けの記事です。スプレッドシートや CSV を入力に、AI にデータパイプライン(データを取り込んで整える一連の処理)を作らせる構成を図にし、10 GB / 100 GB / 1 TB の 3 規模で月額を試算しました。読み終わると、上司に「構成図」と「月額の数字」と「人に残る作業」を説明できるようになります。

この記事で分かること:

  • Google ドライブ → BigQuery → dbt という小さく始める構成の全体像
  • 東京リージョン(データを置いて処理する地域)の料金表から計算した、3 規模の月額と、どの費用が大きくなるか
  • AI エージェントにできないことと、人が担当し続ける工程

ざっくり言うと

筆者が料金表から計算した結果、dbt State(後で説明する、dbt の従量課金の機能)を使わない場合、10 GB なら月 0.23 ドルで、ほぼ無料枠に収まりました。100 GB では月 18.84 ドル、1 TB では月 264.37 ドルになり、どちらも BigQuery のクエリ料金が 8 割前後を占めます。

dbt State を使い、モデル 20 個とテスト 40 個を毎日再利用すると、3 規模とも月 75.20 ドルが上乗せされます。合計は 75.43 / 94.04 / 339.57 ドルになり、小さな規模ではこちらが費用の中心です。

一方で、AI エージェントはパイプラインを「作る」ことはできても「実行する」ことはできません。だから、作られた処理の確認、実行とスケジュールの設定、結果のテストは人の仕事として残ります。

構成図:どの部品がどうつながるか

今回想定する構成は、Google ドライブ・BigQuery・Data Engineering Agent・dbt・Cloud Run jobs の 5 つの部品でできています。図 1 のとおり、AI が担当するのは処理を「書く」部分だけです。

Google ドライブのファイルが BigQuery に入り、Data Engineering Agent が処理を作り、人が確認して dbt で分析テーブルを作る構成図。AI・人・課金の印付き

BigQuery Data Engineering Agent(BigQuery の中で動く、パイプライン作成用の AI 機能)は、2026-04-22 に一般提供(GA)になりました(BigQuery リリースノート)。GA は正式な提供という意味です。

dbt(SQL で書いた変換処理を順番に実行し、テーブルを作るツール)は、エージェントとは別の部品として置いています。今回使った資料では、エージェントが dbt 用のファイルを直接作るという記載は確認できませんでした。そのため図 1 では、エージェントの出力を人が確認して dbt 側に取り込む流れとして描いています。

なぜ今この構成を検討する価値があるのか

BigQuery リリースノートなどによると、この 1〜2 か月で構成に必要な部品が続けてそろいました。図 2 の時系列のとおり、2026 年 9〜10 月に集中しています。

2026 年 4〜11 月の時系列。4 月 22 日エージェント GA、9 月中旬 dbt v2.0 と dbt State の GA、10 月 dbt の環境変数 DBT_AI_PROVIDER が改名、10 月 9 日東京リージョン対応、10 月 12 日 Cloud Run 予算上限停止 GA、10 月 27 日 Google ドライブ入力 GA

1 つ目は東京リージョンへの対応です。2026-10-09 から、エージェントは asia-northeast1(東京)のリージョナルエンドポイント(その地域のサーバーで処理を受け付ける窓口)で使えるようになりました。国内のデータを東京リージョンのまま試せます。

2 つ目は Google ドライブ入力の GA です。2026-10-27 から、スプレッドシート・CSV・JSONL のファイルをパイプラインの入力として渡せるようになりました。表計算ファイルが主なデータ源の会社にとって、入口のハードルが下がったと考えられます。

3 つ目は費用の安全装置です。Cloud Run の予算上限による停止(Budget spend caps)が 2026-10-12 に GA になりました(Cloud Run リリースノート)。Cloud Run の処理を予算で一時停止できる仕組みです。

AI エージェントにできること・できないこと

公式ドキュメントに書かれたエージェントの制限を、次の表にまとめました。

項目可否記載の要点
パイプラインの作成・修正可作成・変更・トラブル対応に使える
パイプラインの実行不可人が確認して実行・スケジュールする
指示に書いた URL の閲覧不可Web リンクは参照できない
ノートブックへの自然言語の指示不可一部のファイル種別は非対応
恒久的な指示の保存可GEMINI.MD に決まりを書ける

特に大事なのは「実行できない」という点です。原文では「The Data Engineering Agent cannot execute pipelines. You must review and run or schedule pipelines.」と書かれています。AI に頼むだけで毎日データが更新される状態にはなりません。

URL を読めない点もつまずきやすいところです。URL だけ渡しても中身は読まれないため、必要な情報は指示文や GEMINI.MD(エージェントに毎回守ってほしい決まりを書いておくファイル)に書き写す必要があります。

費用の部品:何の単位でいくらかかるか

費用の部品ごとに課金の単位を整理します。単価は 2026-11-05 時点で、BigQuery 料金・dbt State の課金・Cloud Run 料金・Gemini for Google Cloud 料金の各ページに載っていた値です。

GiB(ギビバイト)は 1,024 の 3 乗バイトで、約 1.07 GB です。TiB(テビバイト)は 1,024 GiB です。vCPU 秒は仮想 CPU 1 個を 1 秒使った量、GiB 秒はメモリ 1 GiB を 1 秒使った量です。オンデマンドとは、使った分だけ払う料金方式のことです。

部品課金の単位単価(2026-11-05 時点)毎月の無料枠
BigQuery クエリ(東京)読んだデータ量(TiB)7.50 ドル / TiB1 TiB
BigQuery ストレージ(東京・論理アクティブ)保存量(GiB・月)0.023 ドル10 GiB
BigQuery ストレージ(東京・論理長期)保存量(GiB・月)0.016 ドル同上
dbt StateDATT(1 日に再利用した対象の数)0.094 ドル / DATT1,000 DATT
Cloud Run jobsvCPU 秒・GiB 秒0.000018 ドル / vCPU 秒、0.000002 ドル / GiB 秒240,000 vCPU 秒、450,000 GiB 秒
Gemini in BigQuery のコア機能なし追加費用なし-
Data Engineering Agent 固有の料金記載を確認できなかった試算では 0 と置く-

dbt State は、前回から変わっていないテーブルの作り直しを省いたり、テストの結果を再利用したりする dbt の機能です。

課金単位の DATT(daily active target table)は、1 日に再利用された対象の数です。対象には、モデル・seed(CSV から作るテーブル)・snapshot(変更履歴を残すテーブル)に加えて、テストも 1 つずつ入ります。公式の例では、モデル 1 つに not_null と unique のテストが付いていると、モデルとテスト 2 つで 3 つと数えます。

同じ対象を同じ日に何回再利用しても 1 と数えます。dbt State は dbt 本体とは別の従量課金の製品です。使わなければ、この費用はかかりません。

Gemini in BigQuery のコア機能(SQL や Python のコード作成支援、Data canvas、データ準備)は追加費用なしと公式に書かれています。ただし、この記載に Data Engineering Agent の名前はありません。エージェント専用の料金は確認できなかったため、試算では 0 ドルと置きました。

3 規模の月額試算

試算の前提(筆者の仮置き)

使う量は料金表に無いため、次の条件を筆者が仮に置きました。

  • GB は GiB として扱います(1 TB = 1 TiB = 1,024 GiB)
  • 変換は 1 日 1 回、月 30 回実行し、毎回データ全体を 1 回読みます(モデルが前段のテーブルを読み直す分は含めていないため、実際の読み取り量はこれより増えることがあります)
  • 保存量はデータ量の 2 倍とします(取り込んだ元データと、変換後のテーブル)
  • ストレージは高めに見積もるため、すべて論理アクティブの単価で計算します
  • dbt のモデル(テーブル)は 20 個で、各モデルにテストを 2 つずつ付けます(テスト 40 個、対象は合計 60 個)
  • dbt State を使う場合は、60 個すべてが毎日再利用されたとします(DATT の最大値で、月 1,800 DATT)
  • 取り込みジョブは 1 vCPU・2 GiB で、1 回 2 分 / 10 分 / 60 分かかるとします

試算の結果

使った量から無料枠を引いて単価を掛けました(例: クエリ = (データ量 × 30 − 1,024 GiB) ÷ 1,024 × 7.50 ドル)。筆者が料金表から計算した結果が図 3 と次の表です。

10 GB・100 GB・1 TB の月額を部品別に並べた棒グラフ。クエリは 0.00、14.47、217.50 ドル、ストレージは 0.23、4.37、46.87 ドル、dbt State は 3 規模とも 75.20 ドル、Cloud Run は 0 ドル

規模月に読む量BigQuery クエリBigQuery ストレージdbt StateCloud Run合計(dbt State なし)合計(dbt State あり)
10 GB300 GiB0.000.2375.200.000.2375.43
100 GB3,000 GiB14.474.3775.200.0018.8494.04
1 TB30,720 GiB217.5046.8775.200.00264.37339.57

金額の単位はすべてドル / 月です。

10 GB では、月に読む量が 300 GiB で、クエリの無料枠 1 TiB に収まります。そのため dbt State を使わなければ、費用は無料枠 10 GiB を超えたストレージ分の 0.23 ドルだけです。dbt State を使うと、合計 75.43 ドルのうち 99.7% が dbt State になります。

dbt State を使わない場合、100 GB と 1 TB では、合計に占めるクエリ料金の割合が 76.8% と 82.3% になりました。dbt State を使う場合でも、1 TB ではクエリ料金が 64.1% を占めます。つまり、規模が大きくなるほど「何回読むか」が費用を決めます。

Cloud Run は仮置きの条件では無料枠内に収まりました。無料枠がないものとして計算しても、0.08 / 0.40 / 2.38 ドルです。ただし東京の jobs 単価は直接確認できず、東京を含む Tier 1 の既定単価で計算しています。

費用が発生し始める分岐点

クエリの無料枠は月 1 TiB です。1 日 1 回実行する場合、1,024 ÷ 30 = 34.1 GiB までなら毎日全体を読んでも無料枠に収まります。図 4 は、1 日に読む量ごとのクエリ料金です。

1 日に読む量ごとの月額クエリ料金の棒グラフ。34 GiB までは 0 ドルで、50 GiB で 3.49 ドル、1,024 GiB で 217.50 ドルまで増える

1 日に読む量月額クエリ料金(ドル)
10 GiB0.00
34 GiB0.00
50 GiB3.49
100 GiB14.47
200 GiB36.45
500 GiB102.36
1,024 GiB217.50

実行の頻度も大きく効きます。1 TB を 1 日 1 回ではなく 1 時間ごと(月 720 回)に全体を読むと、筆者の計算で月 5,392.50 ドルになりました。頻度だけで約 25 倍です。

dbt State はデータ量ではなく対象の数で決まる

dbt State の課金は、テストを含めた対象の数で決まり、データ量には左右されません。だから 3 規模とも同じ 1,800 DATT で、無料枠 1,000 DATT を 800 DATT 超えました。対象の数ごとの月額を筆者が計算しました(毎日すべてを再利用した場合の最大値)。

毎日再利用する対象の数(モデル+テストなど)DATT / 月月額(ドル)
20(モデル 20 個、テストなし)6000.00
339900.00
341,0201.88
401,20018.80
60(モデル 20 個+テスト 40 個)1,80075.20
1003,000188.00

1,000 ÷ 30 = 33.3 なので、テストを含めた対象が 33 個以下なら無料枠内です。テストを増やすと品質は上がりますが、dbt State の対象も同じ数だけ増える点に注意してください。なお、無料枠 1,000 DATT が期限なしで付くのはセルフホストの無料プランと Developer プランで、Starter は 2027-03-31 までと書かれています(dbt State の課金)。また、変わっていないテーブルの作り直しを省ければ、その分 BigQuery で読む量も減ると考えられます。

人の作業:AI と人の分担

エージェントは実行できないため、パイプラインを作るたびに人の工程が入ります。図 5 は、指示から再確認までの流れを、人と AI のレーンに分けたものです。

左に人、右にエージェントのレーンを置いた流れ図。人が指示し、AI が SQL を作り、人が確認・実行・テストし、失敗時は AI が直して人が再確認する

工程担当人がやること
指示を書く人目的・入力ファイル・命名の決まりを GEMINI.MD と指示文に書く
確認する人生成された SQL を読み、結合条件や集計の単位を確かめる
実行・スケジュール人実行し、毎日動くよう設定する
テスト人件数や合計が元の表と合うかを確かめる
修正AI と人失敗内容を AI に伝え、直った処理をもう一度確認する

1 回あたりの所要時間については、公式の情報を見つけられませんでした。そのため分数は書かず、最初の数回で実際の時間を記録して見積もりに使うことをおすすめします。

以前の構成との違い

筆者は以前、e-Stat × DuckDB × BigQuery × dbt の構成を記事にしました。そこでは Cloud Run の取り込みと、bronze / silver / mart の 3 層の dbt を人が設計していました。今回はその設計の下書きを AI に任せられる点が違いますが、実行と確認を人が持つ点は変わりません。

つまずきやすい点

dbt State の単価は公式の 2 ページで確かめる

dbt State の単価は、公式の課金ページと Service Consumption Table(dbt Labs の利用料金表)の両方で 1 DATT あたり 0.094 ドルです。単価の根拠にはこの 2 ページを使い、第三者のまとめは確認用にとどめるのが安全です。

dbt State はローカル実行でもアカウントが必要

dbt State は、手元のパソコンで dbt を動かす場合でも、dbt platform のアカウントでの認証が必要で、従量課金です(dbt State の概要)。また、Python モデルとカスタム materialization(dbt がテーブルやビューをどう作るかの方式。自分で定義したものをカスタムと呼びます)のモデルは再利用の対象外です。

環境変数の名前が変わった

dbt v2 では、環境変数(プログラムに設定を渡すための名前付きの値)DBT_AI_PROVIDER が DBT_ENGINE_AI_PROVIDER に改名されました(dbt リリースノート)。旧名を設定している場合は新しい名前に変えるよう書かれています。旧名がいつ使えなくなるかは書かれていません。

予算上限で止まるのは Cloud Run の処理

Cloud Run の予算上限による停止は、Cloud Run のワークロードを一時停止する仕組みです(Cloud Run リリースノート)。今回の試算で一番大きいのは BigQuery のクエリ料金なので、この機能だけでは費用の中心を止められません。読む量と実行頻度を自分で管理することが欠かせません。

ドライブのファイルを読むときの数え方

Google ドライブのファイルを入力にしたときの読み取り量の数え方は、今回の資料では確認できませんでした。試算は BigQuery に取り込んだ後に読む前提です。ファイルを直接何度も読む場合は、最初の月の請求で確かめてください。

まとめ

  • dbt State を使わなければ、10 GB 規模は月 0.23 ドルで、ほぼ無料枠に収まります。100 GB で月 18.84 ドル、1 TB で月 264.37 ドルと、筆者が 2026-11-05 時点の料金表から計算しました。dbt State でモデル 20 個とテスト 40 個を毎日再利用すると、3 規模とも月 75.20 ドルが加わります。
  • 大きな規模では BigQuery のクエリ料金が費用の中心で、「データ量 × 読む回数」で決まります。1 日に読む量 34 GiB と、dbt State で毎日再利用する対象(テストを含む)33 個が、無料枠を超える目安です。
  • エージェントはパイプラインを作れますが実行できません。確認・実行・スケジュール・テストは人の仕事として残ります。

次の一歩

自社のデータ量と実行頻度で試算し直したい方、構成の進め方を相談したい方は、お問い合わせからご連絡ください。AI が作った SQL の確認に不安がある場合は、BigQuery SQL レビューパックも用意しています。

参考にした一次情報