dbtを入れて1年半がたち、モデルは180本を超えました。リードエンジニアは、プルリクエストのたびに同じコメントを書いています。「このモデル、descriptionが空です」「主キーにuniqueテストがありません」。新しく入ったメンバーは、customer_id の説明を3つのモデルでばらばらに書いています。そこへ隣のチームから「SQLMeshに乗り換えれば全部片づく」という話が届きます。承認する側の経営企画からは「ツールを増やして、結局だれが面倒を見るのか」と聞かれます。

dbtの周りには便利な道具がたくさんあります。しかし、どれも解く困りごとが違います。困りごとを1つ選び、dbt本体の機能で足りないかを先に確かめる。それでも足りないときに周辺ツールを足す、という順番で考えると迷いません。

困りごとから逆引きする早見表

いま困っていることまずdbt本体で試すこと足りなければ入れると後で困ること
同じ列の説明を、層ごとに何度も書いているdoc blocks（{{ doc("...") }}）で説明を1か所にまとめるdbt-osmosis同じ列名で意味が違う列にも、上流の説明が入ってしまう
レビューで「説明が空」「テストが無い」と毎回指摘しているレビュー用のチェックリストを決めるdbt-checkpointルールを一度に増やすと、既存の違反でコミットが通らなくなる
開発用に本番テーブルを作り直すと、時間とDWHの費用がかかるdbt clone と --defer、state:modified で変更分だけ作るSQLMeshの評価移行の手間がかかる。dbtのパッケージ管理やincrementalの書き方がそのまま使えない
変更が下流のどこを壊すか、反映前に分からないstate:modified+ で影響する下流を選んで流すSQLMeshの評価同上
困りごとがまだはっきりしない本体だけで運用を続ける何も足さない特になし

本体だけでも、かなり片づきます。doc blocksはMarkdownファイルに説明を書き、各列から呼び出す仕組みです。dbt clone は、Snowflake・Databricks・BigQueryではゼロコピーのクローンで本番のテーブルを開発環境へ写します。それ以外のDWHでは、本番を参照するビューを作ります。モデルとテストの基本の組み方はdbtの3層構造とdbtのテスト設計にまとめています。

2026年に入って、dbtとSQLMeshの関係が変わった

ツールを選ぶ前に、ここ1年の動きを押さえておきます。SQLMeshを開発していたTobiko Dataは、2025年にFivetranに買収されました。2026年3月、FivetranはSQLMeshをLinux Foundationに寄贈すると発表しています。さらに2026年6月1日、Fivetranとdbt Labsの合併が完了しました。合併の発表と同時に、dbt Fusionエンジンの実行部分がdbt Core v2.0（アルファ版、Apache 2.0ライセンス）として公開されています。

つまり、「dbtの会社から離れるためにSQLMeshへ移る」という理由づけは成り立たなくなりました。どちらも同じ会社が関わっています。SQLMeshを選ぶ理由は、仕組みの違いで説明できる必要があります。

もう1つの影響は周辺ツールの対応です。dbt-osmosisがCIで動作を確かめているのはdbt Core 1.8〜1.11です。dbt Core v2.0への対応は、2026年10月時点のドキュメントに書かれていません。v2.0を試すなら、周辺ツールが動くかを先に確かめます。

dbt-osmosis：同じ列の説明を何度も書く手間を減らす

dbt-osmosisは、上流のモデルやソースに書いた列の説明を、下流の同じ名前の列へ引き継ぐOSSです。ライセンスはApache 2.0で、2026年10月時点の最新版は1.5.0です。

引き継ぎは直接の親だけでなく、ソースまでさかのぼった祖先すべてから行われます。下流に空でない説明が既にあれば上書きしません（--force-inherit-descriptions を付けたときだけ上書きします）。説明だけでなくタグも引き継ぐので、ソースに付けた PII タグが下流の列まで届きます。個人情報の列を一覧にしたい情シスにとっては、これだけでも入れる価値があります。

# dbt_project.yml：どのフォルダのYAMLを、どのファイル名で管理するか
models:
  my_project:
    +dbt-osmosis: "_{model}.yml"
pip install dbt-osmosis
# 変更が出るかだけを確かめる（変更が出るなら0以外で終了するので、CIで使える）
dbt-osmosis yaml refactor --dry-run --check
# 差分を確認してから反映する
dbt-osmosis yaml refactor --auto-apply

yaml organize はYAMLファイルの作成と移動、yaml document は説明・タグ・メタ情報の引き継ぎ、yaml refactor はその両方を1回で行います。

困るのは、同じ列名で意味が違う場合です。名前が同じなら、意味が違っても入ります。上流の amount が税抜きで、下流の amount が税込みなら、税抜きの説明がそのまま入ります。dbt-osmosisは名前が一致すれば引き継ぐので、意味が変わる列は名前を変えるか、下流で説明を明示して上書きを防ぎます。--add-progenitor-to-meta を付けると、どのモデルから引き継いだかが列のメタ情報に残り、レビューで確かめやすくなります。

dbt-checkpoint：レビューで毎回言うことを、機械に言わせる

dbt-checkpointは、コミットの前にdbtプロジェクトを検査するpre-commitフック集です。ライセンスはMITで、2026年10月時点の最新版は2.0.7（2025年5月）です。フックは約60あり、モデルの説明の有無、列の説明の有無、テストの種類と本数、ソースの鮮度設定などを検査できます。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v2.0.7
    hooks:
      - id: dbt-parse                      # 多くのフックが使う manifest.json を作る
      - id: check-model-has-description
      - id: check-model-has-tests-by-name
        args: ["--tests", "unique=1", "not_null=1", "--"]

多くのフックは manifest.json を読むので、先に dbt-parse を流します。--tests の引数の最後に -- を付け忘れると、pre-commitが引数とファイル名を区別できなくなります。

抜け道もあります。手元のpre-commitは git commit --no-verify で飛ばせます。ルールを確実に守らせたいなら、CIでも同じ検査を流し、違反があればマージできないようにします。既存のプロジェクトに入れる場合は、CIで変更したファイルだけを --files で渡すと、過去の違反で全員が止まる事態を避けられます。

時期やること終わったと言える目安
1〜2週目「全モデルに説明」「主キーにuniqueとnot_null」の2つだけを合意するルールを1枚に書き、チーム全員が読んでいる
3〜4週目CIで変更したファイルだけに2つのルールを適用する新しく作ったモデルで違反が出ていない
2か月目既存の違反を層ごとに片づける違反の一覧が週ごとに減っている
3か月目以降命名やタグのルールを1つずつ足すルールを足すたびに、理由が1行書かれている

この手間に見合うかを、例で試算します。年収800万円のリードエンジニアの会社負担は、給与の約3倍で年2,400万円です。年1,900時間で割ると、時給は約12,600円です。説明やテストの指摘に週3時間使っていれば、年48週で144時間、約181万円になります。この指摘の多くを機械に任せられれば、リードはレビューで設計の話に時間を使えます。金額はいずれも説明のための例です。

SQLMeshを検討するのは、開発環境の費用と変更の影響が痛いとき

SQLMeshはdbtと同じくSQLの変換を管理するOSSです。dbtとの違いは、環境と変更の扱い方にあります。

SQLMeshの開発環境は、モデルの版（スナップショット）への参照の集まりです。同じ定義のモデルが既に作られていれば、その物理テーブルを使い回します。本番への反映で計算し直す必要が無いときは参照を切り替えるだけで済み、ドキュメントはこれを追加の実行コストがかからない「Virtual Update」と説明しています。

sqlmesh plan は変更を分類して表示します。

変更の分類何が作り直されるか
Breaking（下流を壊す変更）変更したモデルと、その下流すべて
Non-breaking（列の追加など）変更したモデルだけ
Forward-only作り直さない。今後の実行から新しい定義を使う

dbtでも state:modified+ と --defer、dbt clone を組み合わせれば、変更分とその下流だけを作れます。違いは、dbtでは本番の manifest.json の受け渡しなどを自分たちで組み立て、SQLMeshでは同じことを仕組みとして持っている点です。

既存のdbtプロジェクトは、sqlmesh init -t dbt でSQLMeshから読み込めます。ただし、ドキュメントには次の制約が書かれています。

制約移行で起きること
モデルに埋め戻しの開始日が要る全モデル、またはプロジェクト全体に開始日を設定する
dbtで推奨されるincrementalの書き方がそのまま使えないincrementalモデルを書き換える
パッケージ管理の仕組みが無いdbt deps を使い続ける
seedの型推論がdbtと違う型を明示していないseedは、列の型を指定する

評価するなら、代表的なincrementalモデルを3〜5本選び、2週間ほど並行して動かします。開発環境づくりの時間とDWHの費用が、いまのdbtの運用と比べてどれだけ変わるかを数字で比べてから決めます。

DWHの費用の考え方はクラウドDWH入門に、指標の定義をdbtで管理する方法はセマンティックレイヤーの選び方に書いています。

よくある質問（FAQ）

dbt-osmosisとdbt-checkpointは一緒に使えますか?

使えます。役割が重ならないからです。CIでdbt-osmosisを先に流して説明を引き継がせ、そのあとdbt-checkpointで残った違反を検出します。自動で埋められるものは埋め、人が判断すべきものだけを指摘する形になります。

周辺ツールは、どの順番で入れればよいですか?

レビューの指摘が多いならdbt-checkpointから、同じ列の説明を何度も書いているならdbt-osmosisから入れます。困りごとが無いうちは入れません。ツールが1つ増えるたびに、dbtの版を上げるときの確認先も1つ増えるからです。

SQLMeshへの移行は現実的ですか?

新しいプロジェクトなら選択肢になります。既存のdbtプロジェクトは sqlmesh init -t dbt で読み込めますが、incrementalモデルの書き換えや開始日の設定が要ります。代表的なモデルで並行稼働を試し、開発環境の費用と手間がどれだけ減るかを確かめてから決めます。

dbtとSQLMeshが同じ会社の傘下になって、何が変わりましたか?

選ぶ理由が変わりました。SQLMeshは2026年3月にLinux Foundationへの寄贈が発表され、Fivetranとdbt Labsの合併は2026年6月に完了しています。「ベンダーを分けたい」という理由は使えなくなったので、環境の作り方や変更の扱いといった仕組みの違いで選びます。

dbt Core v2.0（Fusion）に移ると、周辺ツールは動きますか?

2026年10月時点では、dbt-osmosisのドキュメントが動作を確かめている範囲はdbt Core 1.8〜1.11で、v2.0への対応は書かれていません。dbt-checkpointも manifest.json を読む仕組みなので、v2.0が出力する内容で動くかを試す必要があります。移行前に、検証用のブランチで周辺ツールを流して確かめます。

出典

レビューのたびに同じ指摘を書いている状態から抜けるための最初の2つのルールづくりだけでも、壁打ちにどうぞ。初回相談（30分・無料）で一緒に整理できます。