🔥
dbt Cloudで「カスタムスキーマに出力されない」悪戦苦闘記（要約版）
この記事は、dbt Advent Calendar 2025の2日目の記事です。
記事を移行したため、本記事は要約版です。よろしければ以下記事をご覧ください。
dbt Cloudを使ってデータモデリングをしていると、モデルを開発者ごとのスキーマや、stg、martsといった環境ごとのスキーマに振り分けたいというニーズが出てきます。
しかし、dbt_project.ymlに+schemaを設定しても、なぜかモデルが意図通りに出力されず、デフォルトのスキーマにテーブルが作成されてしまうという問題に直面しました。
この問題の根本原因を特定し、最終的に「隠れたUI設定」への依存から脱却し、透明性の高いコードベースの構成（Configuration as Code）へと移行するまでの過程を記します。
1. 根本原因：カスタムマクロによる設定の上書き
-
初期症状:
dbt_project.ymlで+schema: marketingのようにカスタムスキーマを設定しても、ジョブ実行時に反映されない。 -
直接原因: プロジェクト内に存在する
generate_schema_nameというカスタムマクロが、dbt_project.ymlの標準ロジックを上書きしていた。 -
問題の核心: カスタムマクロ内の条件分岐が、
target.name == 'prod'の場合にのみカスタムスキーマを適用するロジックだったが、開発時に実行していたJobのtarget.nameが不明だったため、常にデフォルトスキーマにフォールバックしていた。
2. 最初の解決策と課題：UIの奥深くの「罠」
-
最初の解決:
target.nameはdbt Cloudの各Jobの「Advanced settings」内にある隠れたフィールドで設定されていることが判明。ここにprodを設定することで、問題は一時的に解決した。 - 新たな課題（脆い構成）: このUI奥深くの設定はバージョン管理されず、可視性も低いため、極めて属人的な「隠れた罠」となり、チームのスケーラビリティを著しく阻害する脆い構成であることが判明。
3. 最終的な解決策：環境変数によるコード化
- 目標: UIへの依存をなくし、構成をコードとして管理（Configuration as Code）する。
-
最終手段:
generate_schema_nameマクロの条件分岐を、target.nameからdbtの組み込み関数であるenv_var("DBT_ENV_NAME", "dev")（環境変数）に切り替えた。 - 結果: dbt Cloudの「Environments」で一度環境変数を設定すれば、マクロのロジックがシンプルかつ透過的になり、Jobごとの隠れた設定が不要となった。スケーラブルで透明性の高い運用フローが確立された。
まとめ：dbtエンジニアが学ぶべき教訓
-
generate_schema_nameマクロを最初に疑う: スキーマ出力に問題がある場合、カスタムマクロのロジックを確認することが最優先。 -
UI設定より環境変数を優先: 保守性の高いプロジェクトのためには、UIの隠れた設定ではなく、
env_varを使ったコードによる設定を常に優先すべきである。
詳細のコードなどは、こちらからご覧ください。
この記事が役に立ったと感じたら、ぜひX（@aelabdata）をフォローください！
日々のアナリティクスエンジニアとしての学びや、記事の更新情報を発信しています。
Discussion