dbt Analytics Engineer 試験：出題範囲・配点・申込の要点

本記事は、NicheeLabの視点でdbt Analytics Engineer試験を「出題範囲・配点・申込」の3点から整理し、受験対策と実務スキル定着を同時に進めるための現実的な勉強法を示します。

最新の試験仕様・ルールは変更される場合があります。必ず公式ドキュメントと試験ページを確認してください：dbt Docs（https://docs.getdbt.com/）、認定試験ページ（https://www.getdbt.com/certifications/analytics-engineer-certification-exam）

試験の概要とポリシー確認

dbt Analytics Engineer 試験は、dbt Core/Cloud の概念、モデリング、テスト、ドキュメント、運用（CI/本番運用）を横断的に問うシナリオ型の多肢選択問題が中心です。出題はコマンド挙動、選択記法、マテリアライゼーション、ソース管理、テスト戦略など、実務での意思決定に紐づきます。

所要時間、出題数、合格基準、受験料、再受験ポリシー、有効期限などは変更される可能性があるため、必ず公式の試験ページで最新を確認してください。多くの受験者が、dbt Fundamentals等の学習コンテンツを修了後に受験していますが、必須要件は時期により異なる場合があります。

対象者は、DWH/レイクハウス上でのELTモデリングや、Git/CIと連携したdbt運用に日常的に関わるアナリティクスエンジニア、データアナリスト、データエンジニアです。

• 形式：オンライン監督付き・多肢選択（ケースベース含む）
• 範囲：モデリング、テスト/ドキュメント、運用（CI/本番）、増分処理・スナップショット、Jinja/マクロ/パッケージ
• プロダクト中立性：dbt Coreを軸に、Cloud固有事項（Jobs/環境/Deferral/Artifacts）も想定
• 前提：SQL・DWHの基礎、Git/GitHubフロー、CLIの基本操作
• 公式の最新要項を必ず確認：https://www.getdbt.com/certifications/analytics-engineer-certification-exam

dbt開発〜本番の流れ（概念図）

全体でよく使うdbtコマンド（挙動イメージ）

dbt deps                       # パッケージ取得
dbt seed                       # CSVからseedテーブル作成
dbt run                        # モデルを実行（テストは含まない）
dbt test                       # テストのみ実行
dbt build                      # seeds/models/snapshotsとテストを一括実行
# PR CIでの一例（mainの成果物へdefer）
dbt build --select state:modified+ --defer --target prod

出題範囲の詳細

モデリングは、ref/sourceの正しい使い分け、ステージング・中間・マートの三層構成、マテリアライゼーション選択（view/table/incremental/ephemeral）が軸です。DAGの依存解決と選択記法（+、@、tag:、config:、state:）の組合せも頻出です。

テストはschema.ymlのgeneric（not_null/unique/relationships/accepted_values等）とsingular（SQLカスタム）を区別できること、ドキュメント（モデル記述、カラム記述、docs generate/serve、exposures）も実務観点から問われます。

運用では、dbt buildの意味、state比較とdeferralの活用、PR CIの最小実行、ジョブ/スケジュール、アーティファクト（manifest/run_results）の用途が焦点です。増分はunique_keyとmerge戦略、パーティション境界、完全再計算の切替（--full-refresh）と副作用を理解しておくと安全です。

• ref()/source()の依存と命名規則（stg/int/martsの役割）
• 選択記法：+（子/親の包含）、@（近傍選択）、state:modified、tag:、source: など
• マテリアライゼーション：view/table/incremental/ephemeralの向き不向き
• テスト：genericとsingular、ソーステスト、test選択（test_type:generic など）
• ドキュメント：モデル/カラム記述、docs generate、exposuresの責任境界
• 運用：dbt buildの範囲、CIでの--defer、ジョブと環境、アーティファクトの読み方

増分モデルの典型構成（Snowflake/BigQuery想定）

{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge',
    on_schema_change='append_new_columns'
) }}

with src as (
  select * from {{ source('app', 'orders') }}
)
select
  order_id,
  customer_id,
  order_ts,
  total_amount
from src
{% if is_incremental() %}
  where order_ts > (select coalesce(max(order_ts), '1900-01-01') from {{ this }})
{% endif %}

-- ポイント：
-- unique_keyはテスト（unique/not_null）と整合させる
-- フルリフレッシュ時は --full-refresh を明示して安全に切替

配点・問題形式・時間配分の考え方

配点の内訳や合格基準は時期により更新されます。一般的には、モデリング/テスト/運用が大きめの比重を占め、増分/スナップショット、マクロ/パッケージがそれに続く構成が多いです。公式の配点表が提示されている場合はそれを最優先してください。

問題形式は、設計判断を問うシナリオ（どのマテリアライゼーション/コマンドを選ぶか）、挙動の正誤（選択記法、state/deferral、テスト実行範囲）など。時間配分は、1問にかける時間を一定化し、長文シナリオは設計制約（DWH、SLA、再計算可否）を先にマークして選択肢をふるいにかけます。

減点なしの多肢選択であれば、迷ったら捨てずにマーク。見直し時間を最後に5〜10分確保するのが無難です。

• よく出る動詞：選べ、もっとも適切、最小の実行範囲、再処理を避ける
• 見極めポイント：dbt buildとrun/testの境界、stateと--deferの組み合わせ、+/@の含意
• DWH依存の仕様は公式Docsを前提に回答（Snowflake/BigQuery/Redshiftの差異に注意）
• 設計問題はSLA/可観測性/将来の運用負債から逆算して選ぶ

選択範囲指定の実務的パターン

# 変更点と下流をCIで検証（本番にdefer）
dbt build --select state:modified+ --defer --target prod

# 特定タグ配下のモデルとそのテストのみ
dbt build --select tag:finance --resource-type model

# 失敗したテストに関連するノードを再実行
dbt build --select result:error

# 近傍選択（@）で周辺ノードも対象に
dbt build --select @marts.orders

申込・受験手順と当日の流れ

申込は、dbtの認定サイトからアカウントを作成し、受験スケジュールを選択します。受験料、受験ウィンドウ、身分証明要件、動作環境チェック、再受験ポリシーは申込フロー内で明示されます。

当日は、静かな個室、安定したネットワーク、Webカメラ/マイク等の要件を満たし、受験プラットフォームの指示に従います。持ち込み可否（ノート、外部モニタ等）はプラットフォーム規約に準拠してください。

変更やキャンセル、再受験の待機期間、回数制限、有効期限・更新要件は公式ページの規定に従います。組織受験やバウチャー支払い、領収書の発行可否も同様に確認してください。

• 公式試験ページで最新の要項を確認し、事前にシステムチェックを実施
• 本人確認書類と氏名表記の一致を必ず確認
• 受験前に周辺機器・常駐アプリの整理（通知/同期系を停止）
• 遅刻・中断時の取り扱い、再受験条件は事前に把握

受験準備チェックリスト（例）

- アカウント作成・支払い完了
- 受験日時をカレンダー登録、30分前リマインダ
- システムチェック（ネット/カメラ/マイク）
- 公式要項の最終確認（身分証・規約・再受験）
- 試験直前は選択記法/state・deferralの要点を見直し

学習計画（2〜4週間）と頻出ポイント

Week1は公式チュートリアルでエンドツーエンドに通し、ref/source、三層構成、schemaテスト、docsの基本を押さえます。CIではdbt buildの範囲とrun/testの違いを体感します。

Week2は増分・スナップショット、state/deferral、選択記法の組み合わせを重点的に演習。PR CIで「変更点＋下流」の最小実行と、本番アーティファクトへのdeferを再現します。

Week3〜4は模擬シナリオを自作し、設計選択（マテリアライゼーション、キー設計、再計算戦略）を言語化。公式Docsで不明点を潰し込み、弱点領域を反復。

• buildの包括範囲（seeds/models/snapshots/tests）を明確に答えられるように
• state:modifiedと--deferの意図（PRで本番の完全DAGを想定した実行）
• unique_keyとテスト戦略の整合（特に増分/スナップショット）
• schema.ymlのドキュメント記述とexposuresの責任範囲
• マテリアライゼーションの向き不向きと切替時の副作用（--full-refresh）

schema.yml の例（テストとドキュメント、exposure）

version: 2
models:
  - name: fct_orders
    description: 受注ファクト。注文の粒度は1行=1注文
    columns:
      - name: order_id
        description: 受注ID（ユニーク）
        tests:
          - not_null
          - unique
      - name: customer_id
        tests:
          - not_null
sources:
  - name: app
    schema: raw
    tables:
      - name: orders
        columns:
          - name: order_id
            tests:
              - not_null
exposures:
  - name: revenue_dashboard
    type: dashboard
    url: https://bi.example.com/dash/revenue
    depends_on:
      - ref('fct_orders')
    owner:
      name: Analytics Team
      email: [email protected]

実務と試験をつなぐ観点

実務では、PRでの最小実行、失敗時の原因切り分け、アーティファクトの参照（run_results/manifest）、本番の安定性を損なわない再計算戦略が鍵です。試験でも同様の意思決定が問われます。

選択肢のトラップは、便利そうでも再処理コストやSLAを無視したアプローチ、DAGや選択記法の解釈ミス、テストとマテリアライゼーションの不整合など。常に「最小変更で検証し、安全に本番へ」と考えると誤答を避けやすくなります。

• CIでは build と state/deferral を組み合わせ、余計な完全再計算を避ける
• 増分はunique_keyと更新境界を明確化。フルリフレッシュの影響を理解
• ドキュメントとexposuresで依存・責任を可視化。監査/可観測性を担保
• runとtestの分離 vs buildの一体実行を状況で使い分け
• マクロ/パッケージは再利用・標準化の観点から最小のカスタムで始める

dbt Cloud Jobの典型設定（抜粋イメージ）

name: PR CI (defer to prod)
environment: dev
steps:
  - dbt deps
  - dbt build --select state:modified+ --defer --target prod
  - dbt docs generate
triggers:
  pull_request: true
  schedule: false
artifacts:
  exposure: true
  upload: run_results.json, manifest.json

問題で確認

よくある質問