dbt Cloud の Seed で作成されるテーブルを開発環境でのみ Source として扱う

2025.09.21
 はじめにdbt Cloud を使用する際、環境分離の制約で本番環境のデータを開発環境で利用できない場面があるとします。Seed を使うと、CSV ファイルから DWH 側のテーブルとして作成できます。また、Seed により作成されたテーブルはソースとして使用することも可能です。

開発環境以外では、本番環境相当のデータを使用できるとして、開発環境でのみ Seed を実行し、他環境と同じソースとして使用してみましたので、試した内容を記事としました。
 前提条件以下の環境で検証しています。
DWH：Snowflake
環境：Snowflake アカウントレベルで分離
PROD：
本番環境
target.name：prd
schema：prd

STG：
統合テスト環境。複数の開発者が作成したモデルをマージし、品質保証を行う環境
target.name：stg
schema：stg

DEV：
各ユーザーが新しいデータを開発する、個人の開発環境
target.name：dev
schema：デフォルト（dbt_<ユーザー名>）
本番環境のデータは使用できない設定と仮定


データベース構成
各環境（アカウント）で dbt による開発結果を出力する単一のデータベースを用意
例：<env>_db


ブランチ戦略
mainブランチと同期されたstgブランチを作成
stgブランチからfeature/xxブランチを派生させ、開発を行う
開発完了後、feature/xxからstgへブランチにマージする
STG 環境でテストが完了したら、stgブランチの変更をmainブランチにマージする

ジョブ構成
本番環境へのデプロイジョブ
mainブランチの変更を本番環境へ反映する
dbt buildを実行

STG 環境へのデプロイジョブ
stgブランチの変更を STG 環境へ反映する
カスタムブランチとしてstgを指定する
dbt buildを実行


 試してみる 事前準備Snowflake 側で3つのアカウントを用意し、各環境で環境を表す変数名を変更し、以下を実行しました。今回の設定上、開発環境アカウントではデータロード以降の内容（テーブル作成・データロード）は実行しないようにします。

これにより、dbt Cloud の出力先となるデータベースと生データ用のスキーマが作成されます。ステージング、本番環境では、本番と同様のデータがrawスキーマにロードされている設定となります。

サンプルデータは Quickstart で提供される jaffle_shop のデータを使用しました。

					
			--変数を定義
--環境名: prd, stg, dev 
SET env_name = '<env>';
--データベースを作成
SET db_name = concat($env_name,'_db');
create database if not exists identifier($db_name);

--スキーマを作成
use database identifier($db_name);
--raw
create schema raw;

--ウェアハウスを作成
create warehouse if not exists transforming;

/*==========
以降の内容は開発環境では実行しない
==========*/

--データロード
use schema raw;
--customers
create table customers 
( id integer,
  first_name varchar,
  last_name varchar
);

copy into customers (id, first_name, last_name)
from 's3://dbt-tutorial-public/jaffle_shop_customers.csv'
file_format = (
    type = 'CSV'
    field_delimiter = ','
    skip_header = 1
    ); 

--orders
create table orders
( id integer,
  user_id integer,
  order_date date,
  status varchar,
  _etl_loaded_at timestamp default current_timestamp
);

copy into orders (id, user_id, order_date, status)
from 's3://dbt-tutorial-public/jaffle_shop_orders.csv'
file_format = (
    type = 'CSV'
    field_delimiter = ','
    skip_header = 1
    );

--データを確認
select * from customers;
select * from orders;

		
		
最終的には、以下のパイプラインを作成するとします。この際、開発環境でのみ seed で作成されるテーブルをソースとして参照させます。
 Seed を環境ごとに有効化または無効化するSeed に関する設定項目は以下に記載があります。
https://docs.getdbt.com/reference/seed-configs
この内、General configurations 内に記載がある enabled プロパティを使用します。これにより、特定のリソースの有効化または無効化を制御できます。
ここでは dbt_project.yml内で以下のように設定しました。

					
			seeds:
  +enabled: "{{ target.name == 'dev' }}"
  jaffle_shop:
    +database: "{{ env_var('DBT_DATABASE') }}"
    +schema: raw

		
		
ポイントは以下の通りです。
target.name
前提条件として開発環境のtarget.nameはdevとしているので、開発環境で Seed が有効化される設定です。その他の環境では無効化されます

出力先データベース
今回の設定では各環境（アカウント）で dbt による開発結果を出力する単一のデータベースを用意しているため、こちらを出力先としています

出力先スキーマ
seed により出力されるテーブルを開発環境ではソースとして扱いたいので、他環境と同様に生データであることがわかる名称（raw）としています
カスタムスキーマ マクロは特に設定していないので、開発環境での実行時は、ユーザーごとに異なるdbt_<ユーザー名>_raw（{{ default_schema }}_{{ custom_schema_name | trim }}）の名称からなるスキーマに出力されます

https://docs.getdbt.com/docs/build/custom-schemas
 Seed により作成されるテーブルをソースに指定Seed を実行後に作成されるテーブルもソースに指定可能です。ここでは models ディレクトリ内に YAML ファイルを作成し、以下のように設定しました。

					
			version: 2

sources:
    - name: jaffle_shop
      description: This is a replica of the Postgres database used by our app
      database: "{{ env_var('DBT_DATABASE') }}"
      schema: "{{ 'raw' if target.name == 'prd' or target.name == 'stg' else target.schema ~ '_raw' }}"
      tables:
          - name: customers
            description: One record per customer.
          - name: orders
            description: One record per order. Includes cancelled and deleted orders.

		
		
開発環境以外では本番環境相当のデータを使用できる設定なので、raw レイヤーとなるスキーマが指定されます。開発環境ではtarget.schema ~ '_raw'により、開発者ごとのdbt_<ユーザー名>_raw（{{ default_schema }}_{{ custom_schema_name | trim }}）の名称からなるスキーマがこのソーススキーマとして使用されます。
 開発環境で実行seeds/jaffle_shopディレクトリ内に以下の CSV ファイルを配置しました。

ここでは簡単に他環境と同じデータからレコードを絞った形で配置しています。
customers.csv

					
			ID,FIRST_NAME,LAST_NAME
1,Michael,P.
2,Shawn,M.
3,Kathleen,P.
4,Jimmy,C.
5,Katherine,R.

		
		
orders.csv

					
			ID,USER_ID,ORDER_DATE,STATUS,_ETL_LOADED_AT
1,1,2018-01-01,returned,2025-09-10 15:27:29.140
2,3,2018-01-02,completed,2025-09-10 15:27:29.140
3,94,2018-01-04,completed,2025-09-10 15:27:29.140
4,50,2018-01-05,completed,2025-09-10 15:27:29.140
5,64,2018-01-05,completed,2025-09-10 15:27:29.140
6,54,2018-01-07,completed,2025-09-10 15:27:29.140
7,88,2018-01-09,completed,2025-09-10 15:27:29.140
8,2,2018-01-11,returned,2025-09-10 15:27:29.140
9,53,2018-01-12,completed,2025-09-10 15:27:29.140
10,7,2018-01-14,completed,2025-09-10 15:27:29.140

		
		
この状態から、開発環境でdbt seedを実行してみます。

下図は、生データから次の加工段階のビューとなるモデル作成時のログですが、ソースで指定のデータベース スキーマ（dbt_<ユーザー名>_raw）から作成されていることが確認できます。
Snowflake 側で確認すると、開発環境アカウントのデフォルトスキーマで各種モデルが作成されています。最終的なマートテーブルを見ると、ここでは seed により作成されたテーブルを使用しているので、レコード数が限られています。
 ステージング環境へのデプロイジョブを実行変更をstgブランチにマージ後、ステージング環境へのデプロイジョブを実行します。

事前準備で、ステージング環境では本番環境相当のデータをロードしているため、最終的なマートテーブルを確認すると開発環境よりもレコード数が多いことが確認できます。
ジョブのログを確認すると、ソースの YAML ファイルで指定した通り、環境ごとのデータベース内のrawスキーマが参照されています。
ジョブではdbt buildを実行することとしていますが、今回の設定上、開発環境以外では seed のリソースは作成されません。
 本番環境へのデプロイジョブを実行変更を main ブランチへマージ後、同様に本番環境へのデプロイジョブを実行します。

最終的なマートテーブルは、開発環境よりもレコード数が多いことが確認できます。
ジョブのログを確認すると、こちらもソースの YAML ファイルで指定した通り、環境ごとのデータベース内のrawスキーマが参照されています。
ステージング環境と同様に、今回の設定上、開発環境以外では seed のリソースは作成されません。
 本番環境で Seed を有効化してみる試しにdbt_project.ymlを以下のように変更し、本番環境で seed のリソースを有効化してみます。

					
			seeds:
  +enabled: "{{ target.name == 'dev' or target.name == 'prod' }}"
  jaffle_shop:
    +database: "{{ env_var('DBT_DATABASE') }}"
    +schema: raw

		
		
本番環境へのデプロイジョブを実行すると、下図のように seed のリソースが作成されます。スキーマ名は{{ default_schema }}_{{ custom_schema_name | trim }}となります（前提条件より、デフォルトスキーマはprd）。
注意点として、ソースの場合、実行順は考慮されないようです（ソースとして seed で作成されるテーブルを参照する場合、事前に seed の実行が必要）。
 さいごにSeed で作成されるテーブルを開発環境でのみソースに指定してみました。

ここでは設定しませんでしたが、seed によって作成されるテーブルカラムのデータ型も指定可能です。
https://docs.getdbt.com/reference/seed-configs#example-seed-configuration
こちらの内容が何かの参考になれば幸いです。