dbt Cloud と dbt Core の違いと選び方：Analytics Engineer 試験に効く要点

どちらを使ってもモデリングの本質（ref・tests・macros・snapshots・docs・artifacts）は同じですが、運用とコラボレーションの体験は大きく異なります。

この記事では、安定した公式仕様に基づき、dbt Cloud と dbt Core の違いを試験で問われやすい観点に沿って解説し、現場での選定を素早く決めるためのチェックポイントを示します。

基本整理：Cloud と Core の位置づけ

dbt Core はオープンソースの CLI 実行環境です。モデルをコンパイルし、アダプタ経由で DWH（Snowflake、BigQuery、Databricks、Redshift、Postgres など）に SQL を投げます。スケジューラや Web UI、RBAC は含みません。

dbt Cloud はマネージドの SaaS で、Web IDE、ジョブスケジューラ、実行ログ、通知、認証・権限、メタデータ可視化、PR チェックなどを提供します。どちらも実際の計算は DWH 側で行われ、SQL の挙動は同じです。

• Cloud はチーム開発・運用の足回りをマネージド提供
• Core は自由度が高く、CI/CD・スケジューリングを自前で組む
• Artifacts（manifest.json など）は双方で共通の仕様

Core の接続定義（profiles.yml の例：Snowflake）

my_project:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: '{{ env_var('SNOWFLAKE_ACCOUNT') }}'
      user: '{{ env_var('SNOWFLAKE_USER') }}'
      password: '{{ env_var('SNOWFLAKE_PASSWORD') }}'
      role: ANALYST
      database: ANALYTICS
      warehouse: TRANSFORMING
      schema: dev_{{ env_var('USER') }}
      threads: 8
      client_session_keep_alive: true

実行・オーケストレーション設計

Cloud はジョブ定義とスケジューラを内蔵し、環境（Development/Deployment）単位で実行パラメータ、スケジュール、通知、リトライ、並列化を定義できます。PR ベースのチェックや、前回成果物に基づく差分実行（いわゆる Slim CI）も設定しやすいのが特徴です。

Core はスケジューラを持たないため、Airflow、Dagster、GitHub Actions、GitLab CI、Azure Pipelines、cron などを用います。state:modified+ と artifacts（manifest.json、run_results.json）を活用して差分実行を設計するのが定石です。

• バッチ実行と通知・再実行を最短で整備したい → Cloud
• 既存の統合オーケストレータに組み込みたい、細かな依存制御が必要 → Core
• 差分実行（Slim CI）は Cloud でも Core でも可能。Core は artifacts の保存場所を自前で用意

実行経路（Core パス）

実行経路（Cloud パス）

Core での Slim CI（GitHub Actions の最小例）

name: dbt Core CI
on:
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install dbt-snowflake
      - name: Restore previous artifacts
        run: |
          mkdir -p ci_state
          # 例: 前回の manifest.json をアーティファクトやストレージから取得して ci_state/ に配置
      - run: dbt deps
      - run: dbt build --select state:modified+ --state ci_state --profiles-dir . --target dev

開発体験・コラボレーション

Cloud の Web IDE はブラウザから接続設定・ブランチ操作・モデル実行・ログ確認・ドキュメント閲覧まで一気通貫です。新規メンバーのオンボーディングが速く、レビューでの再現性も高いのが利点です。

Core はローカル IDE（VS Code など）と CLI を組み合わせます。自由度が高い一方、Python/依存パッケージ、DWH へのネットワーク、シークレット、データサンプルの扱いなど環境差異を吸収する運用設計が鍵になります。

• ドキュメントは dbt docs generate で静的出力。Cloud ならホスティング込み、Core は自前で配信
• PR チェックで model/test を部分実行する文化を作るとレビュー効率が上がる
• Artifacts は常にバージョン管理 or 永続ストレージに保持し、差分実行の信頼性を高める

ドキュメント生成とローカル閲覧（Core）

dbt docs generate --target dev
# ローカルで一時サーバ起動
dbt docs serve --port 8080

セキュリティ・権限・監査

Cloud は SSO/SAML、RBAC、サービストークン、監査ログなどのガバナンス機能を提供します（利用可否はプランに依存）。接続情報は環境ごとに分離して安全に管理できます。

Core ではこれらを周辺基盤で補います。シークレットは環境変数で渡し、管理はクラウドのシークレットマネージャや Vault を用いるのが一般的です。権限制御は DWH のロール設計とオーケストレータ側の実行権限で行います。

• 資格試験では「組織的な RBAC/SSO/監査が必要 → Cloud」という判断が頻出
• Core 運用では least privilege の DWH ロールと実行用サービスアカウントを分離
• 接続情報は env_var 参照に統一し、リポジトリに秘匿情報を置かない

環境変数を用いた安全な接続（profiles.yml 抜粋）

outputs:
  prod:
    type: snowflake
    account: '{{ env_var('SNOWFLAKE_ACCOUNT') }}'
    user: '{{ env_var('SNOWFLAKE_USER') }}'
    password: '{{ env_var('SNOWFLAKE_PASSWORD') }}'
    role: '{{ env_var('SNOWFLAKE_ROLE', 'TRANSFORMER') }}'
    database: '{{ env_var('SNOWFLAKE_DB') }}'
    warehouse: '{{ env_var('SNOWFLAKE_WH') }}'
    schema: analytics

コスト・運用・拡張性のトレードオフ

Cloud はサブスクリプション費用が発生する一方、スケジューラや IDE、ログ・通知、UI での管理の運用負担を大幅に削減できます。小〜中規模やガバナンス要件が強い組織では TCO が下がることが多いです。

Core はソフトウェア自体は無償ですが、スケジューリング、モニタリング、権限、ログ保全、ドキュメント公開、メタデータ可視化などを自前で設計・保守します。既存のプラットフォームが整っている組織や高度なカスタマイズが必要な場合に適します。

• 短期の立ち上げ速度と少人数運用 → Cloud
• 既存 CI/CD と統合し運用標準化 → Core
• どちらも計算は DWH 側。DWH コスト設計（Warehouse サイズ/Auto-resume/クレジット上限）が重要

アダプタ導入とバージョン固定（例：Snowflake/Databricks）

pip install 'dbt-snowflake==1.8.*'
pip install 'dbt-databricks==1.8.*'
# 再現性のため requirements.txt / lock を活用

試験対策の要点と選定フレーム

Analytics Engineer 試験では、dbt のコア概念に加えて、運用・コラボレーションの観点で Cloud と Core の使い分けが設問化されやすいです。特に Slim CI、環境分離、権限、ドキュメント/Lineage、スケジューリングの所在を即答できると得点に結びつきます。

現場の選定は要件ドリブンで決めます。RBAC/SSO・監査・スケジューラ内蔵・最短立ち上げが重視なら Cloud。既存オーケストレータ統合・細かな依存制御・インフラ標準の徹底が重視なら Core。いずれも artifacts と state 管理の設計が成功の鍵です。

• 覚えるべき即答ポイント: Cloud=スケジューラ/IDE/RBAC/Lineage UI、Core=OSS CLI/自前オーケストレーション
• Slim CI= state:modified+ と前回 artifacts を使う差分実行（Cloud/Core 双方で可能）
• 両者とも DWH 上で SQL 実行。パフォーマンスは DWH 設計とモデル粒度に依存

選定チェックリスト（抜粋）

[ ] SSO/RBAC/監査が必須 → はい: Cloud 有力 / いいえ: Core も候補
[ ] 既存の統合オーケストレータに統合したい → はい: Core / いいえ: Cloud で内製省力
[ ] PR ごとの差分実行が必要 → 双方可（state 管理の容易さで比較）
[ ] ドキュメント/Lineage をすぐ可視化したい → Cloud 有利 / Core は自前ホスティング
[ ] 予算と運用体制 → TCO で試算（人件費+SaaS+DWH）

問題で確認

よくある質問