【新機能】Snowflake Horizon Context がプレビューとなったので dbt コネクタで dbt platform のモデルを Horizon Catalog に取り込んでみた

かわばたです。

2026年10月12日にHorizon Contextがプレビューとなりました。

本記事では、Horizon Context の dbt コネクタで、dbt platform のジョブ成果物を Snowflake Horizon Catalog に取り込みます。題材は dbt Labs のサンプルプロジェクト jaffle-shop です。モデル間リネージ・description・テスト結果の表示と、ロールごとの見え方を確認します。

https://docs.snowflake.com/en/user-guide/snowflake-horizon/connectors/dbt/dbt-cloud

https://github.com/dbt-labs/jaffle-shop

Horizon Context と dbt コネクタの概要

Horizon Context は、Snowflake Horizon Catalog に組み込まれたコンテキストレイヤーです。Snowflake 内のオブジェクトに加えて、外部データベース・BI ダッシュボード・パイプラインのメタデータとリネージを 1 つのカタログで扱います。外部システムからメタデータを読み取るのがメタデータコネクタで、Snowsight の Catalog » Connections から作成します。

https://docs.snowflake.com/en/user-guide/snowflake-horizon/horizon-context

dbt コネクタは dbt 本体には接続しません。dbt が生成するビルド成果物(manifest.json、catalog.json、run_results.json)を読み取ります。読み取ったモデルを、Horizon Catalog に接続済みのウェアハウスのテーブル・ビューに対応付けます。既存のオブジェクトに追加されるのはモデル間リネージと dbt の情報だけで、データ自体は対象外です。

Snowflake World Tour 2026 の「Snowflakeでゼロから構築する、信頼性の高いセマンティックレイヤー」のセッションでも一部取り上げられていました。

詳細は次の記事をご確認ください。

https://dev.classmethod.jp/articles/snowflake-trusted-semantic-layer-swttokyo26/

対応状況と要件

公式ドキュメントの記載を整理すると次のとおりです。

dbt platform と dbt Core の違いは、成果物の取得方法にあります。dbt platform はスケジュール実行されるジョブから dbt Cloud API 経由で取得し、以降はジョブの実行に合わせて自動で更新されます。dbt Core は接続作成時に 3 ファイルをアップロードし、プロジェクトを変更したら再アップロードする手動運用です。本記事で検証するのは dbt platform です。

設定の流れ

1. dbt platform で、Generate docs on run を有効にしたジョブを作り、1 回実行する
2. dbt platform でサービストークンを作る
3. Snowflake の Catalog » Connections で dbt 接続を作り、ジョブ ID とサービストークンを入力する
4. 閲覧するロールに、コネクタへの USAGE を付与する

前提条件

• dbt platform の Enterprise プラン
• dbt platform の Account admin 権限(サービストークンとジョブの作成に使います)
• Snowflake の Enterprise Edition 以上のアカウント
• Snowflake の ACCOUNTADMIN ロール(接続の作成と、ロール・ユーザーの作成に使います)
• 閲覧確認用のユーザーを 1 つ作れること

https://docs.snowflake.com/en/user-guide/snowflake-horizon/connectors/access-control

Snowsight でオブジェクトを作成するときは、選択中のプライマリロールだけの権限で判定されます。閲覧の確認では逆に、ユーザーが保持するすべてのロールの権限が合算されます。閲覧確認用ユーザーには、確認したいロール以外を付与しないでください。

検証環境

事前準備

jaffle-shop をデプロイする dbt platform プロジェクトを用意する

あらかじめ Snowflake に JAFFLE_SHOP_DB を作成します。dbt platform の Connection には、このデータベース内でスキーマ・テーブル・ビューを作成でき、使用するウェアハウスを利用できるロールを設定します。

USE ROLE ACCOUNTADMIN;
CREATE DATABASE JAFFLE_SHOP_DB;

jaffle-shop は GitHub のテンプレートリポジトリです。本記事では、.github/ を除いた内容を検証用リポジトリの jaffle_shop/ フォルダにコピーし、dbt platform のプロジェクト設定で Project subdirectory に jaffle_shop を指定しました。

デプロイ環境 prod の設定は次のとおりです。

1. Orchestration → Environments → Create environment → Deployment で環境を作る。種類は General
2. Connection profiles で Snowflake の Connection と Deployment credentials を設定する。Database は JAFFLE_SHOP_DB、Schema は MAIN

3. Studio IDE または dbt Cloud CLI で、seed データを 1 回だけ読み込む

dbt seed --full-refresh --vars '{"load_source_data": true}'

jaffle-shop のサンプル seed は load_source_data 変数が true のときだけ有効になるため、dbt seed だけでは読み込まれません。Studio IDE で実行する場合は、開発環境の Database も JAFFLE_SHOP_DB にしておきます。generate_schema_name マクロは、seed を RAW スキーマに、モデルを環境の既定スキーマに作ります。読み込み後、JAFFLE_SHOP_DB.RAW に RAW_CUSTOMERS など 6 テーブルがあれば問題ありません。

本記事で確認するリネージは、customers モデルに至る次の経路です。

raw_customers ─ stg_customers ─┐
                               ├─ customers
raw_orders ─ stg_orders ─ orders ┘

description とテストを調整する

jaffle-shop の models/marts/customers.yml には、モデルと列の description と、customer_type 列の accepted_values テストがあります。description が Horizon Catalog にどう出るかと、失敗したテストがどう出るかを見るため、テストの許容値から returning を外して意図的に失敗させます。persist_docs は設定しません。

# models/marts/customers.yml(抜粋)
      - name: customer_type
        description: Options are 'new' or 'returning', indicating if a customer has ordered more than once or has only placed their first order to date.
        data_tests:
          - accepted_values:
              arguments:
                values: ["new"]  # 検証用。returning を外して意図的に失敗させる

変更を commit し、main に merge します。accepted_values の arguments: は dbt 2.x の書き方です。

ジョブを作成する

Horizon Catalog が成果物を読めるように、Deploy ジョブを公式ドキュメントの構成で作ります。場所は Orchestration → Jobs → Create job → Deploy job で、環境は prod です。

1. Generate docs on run を有効にする(catalog.json の生成に必要)
2. Commands に dbt compile --full-refresh と dbt build を順に設定する
3. Run now で 1 回実行する

dbt compile --full-refresh は、増分モデルを含めたリネージを持つ manifest.json を作るために必要です。テスト結果は dbt test または dbt build の実行から読み取られ、dbt compile と docs 生成では実行されません。

本記事では Run now による初回取り込みまでを確認します。継続してメタデータを更新するには、公式ドキュメントに従ってジョブのスケジュールを設定してください。公式ドキュメントの案内は毎日 4:00 の実行で、Horizon Catalog 側の取り込みより前に完了させる前提です。設定したタイムゾーンも確認してください。

実行すると、accepted_values テストの失敗で実行は Error になります。公式ドキュメントでは、テスト失敗で Error になった実行も取り込みに使えると記載されています。表示の確認は後述の「テスト結果を確認する」です。

コンパイルが失敗した実行は取り込みに使わないでください。不完全な manifest.json によって、モデルが Horizon Catalog から消える可能性があると公式ドキュメントに記載されています。

ジョブを開き、URL の末尾の数字をジョブ ID として控えます。

https://<access-url>/deploy/<account-id>/projects/<project-id>/jobs/<job-id>

サービストークンを作成する

トークンの作成場所は Account settings → Service tokens → Create service token です。
トークンの値は作成時にしか表示されないため、この時点で控えておいてください。

※今回は検証用に Account Admin 権限のサービストークンを使用しています。通常は、公式ドキュメントで案内されている Job Viewer と Account Viewer に権限を限定してください。

接続を作成するロールを決める

今回は ACCOUNTADMIN で接続を作成しました。接続を作成したロールがコネクタの所有者になり、以降の Configure や削除もそのロールで行います。

ACCOUNTADMIN 以外のロールで作成する場合に必要な権限は、公式ドキュメントでは次のとおりです。保存先のデータベースとスキーマを接続ウィザードで新規作成するときは、MANAGE METADATA CONNECTORS と CREATE DATABASE だけで足ります。既存の保存先を使うときは、そのデータベースへの USAGE とスキーマへの CREATE METADATA CONNECTOR が代わりに必要です。本記事ではこの構成は試していません。

-- 保存先を新規作成する場合(参考)
GRANT MANAGE METADATA CONNECTORS ON ACCOUNT TO ROLE <role_name>;
GRANT CREATE DATABASE ON ACCOUNT TO ROLE <role_name>;

閲覧ロールとユーザーを作成する

閲覧の確認には、HC_CATALOG_VIEWER ロールだけを保持するユーザー CATALOG_VIEWER_USER を使います。この時点では JAFFLE_SHOP_DB のオブジェクトを見る権限だけを付け、コネクタへの USAGE は付けません。

USE ROLE ACCOUNTADMIN;

CREATE ROLE HC_CATALOG_VIEWER COMMENT = 'Horizon Catalog read-only viewer';
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE HC_CATALOG_VIEWER;
GRANT USAGE ON DATABASE JAFFLE_SHOP_DB TO ROLE HC_CATALOG_VIEWER;
GRANT USAGE ON ALL SCHEMAS IN DATABASE JAFFLE_SHOP_DB TO ROLE HC_CATALOG_VIEWER;
GRANT REFERENCES ON ALL TABLES IN DATABASE JAFFLE_SHOP_DB TO ROLE HC_CATALOG_VIEWER;
GRANT REFERENCES ON ALL VIEWS IN DATABASE JAFFLE_SHOP_DB TO ROLE HC_CATALOG_VIEWER;

CREATE USER CATALOG_VIEWER_USER
  PASSWORD = '<パスワード>'
  DEFAULT_ROLE = HC_CATALOG_VIEWER
  DEFAULT_SECONDARY_ROLES = ()
  DEFAULT_WAREHOUSE = COMPUTE_WH
  MUST_CHANGE_PASSWORD = TRUE;
GRANT ROLE HC_CATALOG_VIEWER TO USER CATALOG_VIEWER_USER;

REFERENCES は、データを読まずにオブジェクトの存在と列定義だけを参照できる権限です。このロールには SELECT を付けていないため、カタログでテーブルは見えてもデータは参照できません。

ALL を使った権限付与は、実行時点で存在するオブジェクトが対象です。後からモデルを追加する場合は再付与するか、対象範囲を検討したうえで FUTURE を併用してください。

リネージの閲覧には、アカウントの VIEW LINEAGE も必要です。既定では PUBLIC に付与されていますが、取り消している環境では閲覧ロールに付与してください。

-- PUBLIC から VIEW LINEAGE を取り消している場合
GRANT VIEW LINEAGE ON ACCOUNT TO ROLE HC_CATALOG_VIEWER;

試してみた

接続前のリネージを確認する

比較のため、dbt コネクタを作る前に Snowflake 標準のリネージを確認します。Catalog » Explorer で JAFFLE_SHOP_DB.MAIN.CUSTOMERS を開き、Lineage タブを選びます。

dbt が発行する CREATE OR REPLACE TABLE ... AS SELECT と CREATE OR REPLACE VIEW は Snowflake のリネージの記録対象のため、コネクタがなくても RAW_ORDERS → STG_ORDERS / ORDER_ITEMS → ORDERS / STG_CUSTOMERS → CUSTOMERS のリネージが出ています。この時点では、dbt モデル名・テスト結果・dbt の description は表示されない状態です。

dbt 接続を作成する

ACCOUNTADMIN で Snowsight の Catalog » Connections を開きます。Data pipeline tools の dbt を選びます。

接続フォームの入力値は次のとおりです。

Next を押すと Load data ステップに進み、dbt のメタデータが取り込まれます。
Load data が完了すれば問題ありません。

作成されたコネクタは SQL でも確認できます。今回の検証では name は DBT、owner は ACCOUNTADMIN でした。Display Name の dbt が大文字の識別子になっています。

USE ROLE ACCOUNTADMIN;
SHOW METADATA CONNECTORS;

モデル間リネージを確認する

Catalog » Explorer のツリーに DBT のデータソースが追加され、配下に jaffle_shop → dbt Tests と models(marts、staging)が表示されます。確認するのは models → marts → customers の Lineage タブです。

接続前と同じ JAFFLE_SHOP_DB.MAIN のオブジェクトがグラフに並び、各グループのヘッダーに dbt のアイコンが付いています。dbt モデルが Snowflake のテーブル・ビューに対応付けられた状態です。グラフの上には、dbt の customers.yml に書いたモデルの description が表示されています。

description の表示を確認する

Snowflake 側の JAFFLE_SHOP_DB.MAIN のテーブルと、dbt コネクタ配下の customers モデルで、description の表示を比較します。

今回は persist_docs を設定していないため、Snowflake 側のテーブル・列には dbt の description をコメントとして反映していません。Snowflake オブジェクト側の Description 列は空でした。

一方、dbt コネクタ配下の customers モデルには、persist_docs がなくても dbt で定義したモデル・列の description が表示されました。

公式ドキュメントの「Snowflake の場合はネイティブのオブジェクト説明を使う」は、Snowflake オブジェクト側の description の話です。dbt の description を Snowflake のテーブル・列のコメントにも反映するには、dbt の persist_docs でコメントとして書き込みます。

テスト結果を確認する

accepted_values テストを意図的に失敗させたジョブの結果が、Horizon Catalog にどう表示されるかを確認します。
DBT → jaffle_shop の下に dbt Tests の項目があり、テストごとに名前・Status・対象の列とテーブル・最終実行日時が並ぶ一覧です。今回は 24 件のうち、customers の CUSTOMER_TYPE に対する accepted_values だけが Fail でした。

ロール別の可視性を確認する

閲覧ロールだけを持つ CATALOG_VIEWER_USER で Snowsight にサインインします。
この時点ではコネクタへの USAGE を付けていません。

上記のとおり、ツリーに JAFFLE_SHOP_DB は表示されますが、DBT のデータソースと CONNECTORS データベースは表示されませんでした。公式ドキュメントでは、コネクタへの USAGE が無いロールには、コネクタが収集したメタデータとリネージは表示されないと記載されています。

ACCOUNTADMIN に戻り、閲覧ロールへコネクタの USAGE を付与します。<connector_name> は SHOW METADATA CONNECTORS の name 列の値で、今回の検証では DBT でした。

USE ROLE ACCOUNTADMIN;
GRANT USAGE ON DATABASE CONNECTORS TO ROLE HC_CATALOG_VIEWER;
GRANT USAGE ON SCHEMA CONNECTORS.METADATA TO ROLE HC_CATALOG_VIEWER;
GRANT USAGE ON METADATA CONNECTOR CONNECTORS.METADATA.DBT TO ROLE HC_CATALOG_VIEWER;

CATALOG_VIEWER_USER でページを再読み込みすると、DBT のデータソースと CONNECTORS データベースが表示され、jaffle_shop 配下のモデルと description も確認できました。ACCOUNTADMIN で見たときと同じ表示になれば問題ありません。

コネクタへの USAGE は、収集されたメタデータの可視性だけを制御します。USAGE を付与しても、保存済みのサービストークンが公開されたり、dbt platform 自体へのアクセス権が付与されたりすることはありません。

制限事項・注意点

最後に

dbt platform の jaffle-shop を dbt コネクタで取り込み、Snowsight 上でモデル間リネージとテスト結果を確認してみました。
dbt Tests やリネージが見られるのは良いですね！
ジョブの実行結果なども見られると幅が広がるなと感じました。

この記事が何かの参考になれば幸いです！