Ubie テックブログPublicationへの投稿
🤖

AIエージェントのおかげでdbt開発の大部分を自動化した話

okiyuki
に公開
Tech
data
dbt
Cursor
生成 AI
tech

こんにちは、おきゆきです。Ubieでデータ関連業務を担当しています。

この記事では、dbtを利用したデータモデル開発プロセスにおいて、AI搭載エディタであるCursor Editorを活用し、dbt model開発の速度向上にとどまらず、その開発ステップの大部分をAIで自動化した事例について紹介します。

Ubieでは3000以上のdbt modelを運用していますが、事業やプロダクトが拡大するにつれて、dbt model作成のためのファイル規約の遵守、テスト記述、ドキュメント更新、Lightdashに必要なメタデータの定義といった定型的な作業が増加し、開発者の負担となるケースが見られます。SQLロジックの設計や分析といったより本質的な業務に集中したい、という思いは多くの開発者が共有するところではないでしょうか。

この課題に対し、Cursor Editor、特にその Agent機能 と Project Rules を活用することで、dbt開発における定型作業の多くを自動化し、開発効率を大幅に改善することができました。自分の体感ではSQLを書く部分、いわゆるText to SQLはまだ課題はありますが、SQLさえ書ければ、それ以降の工程をAgentにお願いすれば ほぼ人間が確認せずとも同等の精度のGitHub PRが作成されるという体験 ができるようになりました。

例えば、30分のミーティングが始まる前にSQLを渡し、Agentへdbt modelの作成を依頼しておけば、ミーティングが終わる頃には、CIがすべてパスし、GitHub PRがDraft状態で作成され、あとはマージするだけ、といったことが日常的に行えるようになりました。

その核となる「Project Rules」の設定・運用ノウハウについて解説します。dbtを活用されているエンジニアの方や、AI支援ツールによる開発効率化に関心のある方にとって、何かしらのヒントになれば幸いです。

あらためてCursor Editorとは？

Cursor Editor は、VS CodeをベースとしたAI搭載の開発エディタです。UbieではCursor Businessを導入したことも以前共有されました。

https://zenn.dev/ubie_dev/articles/2c474a1c5f71a8

コードの自動生成や編集、リファクタリング支援はもちろん、エディタ内でAIと対話しながらコードに関する質問を行ったり、エラーの原因分析や修正案の提示を受けたりすることが可能です。

dbt開発の自動化という観点では、特に以下の2つの機能が重要となります（執筆時点でバージョン0.47.8を利用しています）

  1. Agent機能: 特定のタスク（例：「この仕様でdbtモデルを作成してください」）を指示すると、AIが複数のステップに分解し、必要なファイル編集やコマンド実行を対話形式、あるいは自律的に進めてくれる機能です。

  2. Project Rules: プロジェクト固有のルール、例えばコーディング規約や標準的な開発手順、参照すべきドキュメントなどのコンテキストを与えるための機能です。これにより、AI Agentのタスク実行精度やプロジェクトへの適合性を高めることができます。

Ubieのdbt model開発のステップ

手元のSQLをdbt model化するためには以下のような複数のステップが必要になります。違う部分もあるかと思いますが、多くの企業で同じようなステップを行っているのではないでしょうか。

  • Step1. 社内独自で開発している dbt-helperを使ってdbt modelファイル群のテンプレートを作成する
  • Step2. SQLを更新
  • Step3. ローカルでdbt runを実行してエラーなくモデルが作成されるか確認
  • Step4. dbt-osmosis を実行してschema.ymlを更新
  • Step5. 必要に応じてdata_testsの追加やcolumn description、Lightdash metadataの修正を行い、schema.ymlを更新
  • Step6. ローカルでdbt testを実行してdata_testsがパスすることを確認
  • Step7. dbt modelの説明を記述するdocs.mdを更新
  • Step8. PRを作成しレビューを依頼する
    • pre-commit によりリンターが実行され、SQLフォーマットも修正される
    • PR作成後、自動的に複数のCIが実行される

dbt model開発の精度を高めるProject Rules

CursorのAgent機能は単体でも有用ですが、その能力を最大限に引き出すためには、プロジェクト固有の文脈やルールをAIに理解させることが不可欠です。ここで中心的な役割を果たすのがProject Rulesです。

dbt model開発における標準的な命名規則、コーディング規約、そしてレイヤーごとの開発手順などを詳細に定義したファイルをProject RulesとしてCursorに読み込ませています。Project Rulesは大きく分けて以下の3つを現在運用しています。

  • 共通的な部分（あらゆるdbt model開発で必要となる共通ルール。基本的にコンテキストとして渡します）
    • model.mdc, model_sql.mdc, model_docs.mdc, model_schema.mdc
  • ドメイン固有の部分（特定の事業・プロダクトのドメインや機能を説明するルール。コンテキストとして手動で渡します）
    • product_xxx.mdc, function_xxx.mdc, ...
  • トラブルシューティングや確認用（リファクタリング後のデータ比較など、dbt modelのリリース後に数値確認などに利用するルール。コンテキストとして手動で渡します)
    • bigquery_record_change_verification.mdc (社内のBigQuery MCPサーバーと合わせて利用します）

これらにより、Agentは私たちのプロジェクトの作法に則って、より正確にタスクを実行できるようになりました。今回はとくに共通的な部分の1つである model.mdc について説明します。

構成要素1. 命名規則

dbt modelを開発するリポジトリにおける命名規則を記述しています。とくにUbieではBigQueryをデータウェアハウスに利用していますが、dbt modelとの対応や各種データセットが意味するコンテキストを丁寧にインプットしています。

# 命名規則

## BigQueryとdbtモデルの命名の対応関係
- BigQueryテーブル: `<project_id>.<dataset_id>.<table_id>`
- dbtモデル名: ...
- dbtモデルディレクトリ: ...

## レイヤー別の命名規則
- Interface層(IF層):
  - データセット: `if_` + ソースデータセット名
  - テーブル: ソース名と完全一致 ...
- Data Component層(DC層):
  - データセット: `dc_` + ドメイン名
  - テーブル: ディメンションは`dim_`、ファクトは`fact_` ....
- Data Ware House層(DWH層):
  - データセット: `dwh_` + ドメイン名
  - テーブル: データの内容を反映した説明的な名前 ....
- Datamart層(DM層):
  - データセット: `dm_` + ドメイン名
  - テーブル: 分析や可視化の目的を示す説明的な名前 ....

構成要素2. コーディング規約

命名規則を定義した後、それに基づいたコーディング規約を記述しています。この規約を整備することで、AIが生成するSQLクエリが人間が書いたものにかなり近いものになったと感じています。コードの読みやすさが格段に上がり、レビューが容易になります。

# コーディング規約
- 規則やレイヤー間の参照ルールは .... 
- SQLの書き方は @model_sql.mdc を参照してください。
- FROM句で参照する際はBigQueryテーブルでの記法ではなく、dbtモデル名での記法に変換し、refやsource関数を必ず利用すること
- ....

構成要素3. 開発手順

先ほど紹介したUbieのdbt model開発ステップに沿って、各ステップで何をすべきかを丁寧に記述していきます。Ubieでは作成するdbt modelがどのレイヤー(層)に属するかで手順が異なるため、まずどの手順に属するかを特定させ、その手順に従って開発ステップを上から順に実行させます。

# dbtモデルの開発手順
- 以下に3つの節があります。dbtモデルを開発する際はどれかを選択して手順どおり実行してください
  - `1. ...層モデルの作成/更新`
  - `2. ...層モデルの作成/更新`
  - `3. ...層モデルの作成/更新`

手順内の各STEPの開発を進める前に、どのSTEPかを必ず宣言してください。宣言例は以下です。
...

特定の層のモデルの作成ステップごとに、細かく行うべき作業を記述します。

## ...層モデルの作成/更新

### 手順
- Step1. `dbt-helper`を使ってdbt modelファイル群のテンプレートを作成する
    # ... (dbt-helper コマンド例)
- Step2. SQLを更新
    # ... (SQL実装例)
- Step3. dbt runを実行してモデルの動作を確認
    # ... (dbt run コマンド例)
- Step4. dbt-osmosisを実行してschema.ymlを更新
    # ... (dbt-osmosis コマンド例)
- Step5. @model_schema.mdc を確認し、原則に応じてschema.ymlを更新する
- Step6. dbt buildを実行してモデルの動作を確認
    # ... (dbt build コマンド例)
- Step7. PRを作成しレビューを依頼する
    # ... (sqlfluff fix コマンド例)

### ...層モデルの作成/更新時の注意点
- 各Stepを一つずつ実行してください
- 各Stepの完了後、簡潔に進捗を報告してください
- 実行時にエラーが発生した場合は、即座に報告し、エラーの原因を同一データセット内のdbt modelを確認して分析してください。その後、原因分析結果にもとづき、修正アクションを実施してください。

このように、命名規則やコーディング規約に加え、レイヤーごとに詳細な開発手順を定義しています。手順の中には、私たちが内部で使用しているdbt-helper（dbt model雛形生成）やdbt-osmosis（メタデータの伝搬と生成）の具体的な利用方法やコマンド例、さらにはエラー発生時の対応フローまで含めています。

このProject Rulesを整備・改善し続けた結果、Agentによるタスク実行の精度は大きく向上したと感じます。たとえば、SQLを用意した状態でdbt modelの開発を依頼した場合、8〜9割程度の確率で期待通りのアウトプットが得られるようになりました。もちろん、時折意図しない挙動を示すこともありますが、多くの場合、定義された手順に従って開発作業を支援してくれます。


Step3 ~ Step5をAIエージェントが自動的に行ってくれている例

Cursor Agentによるdbt model開発の工夫

上記Project Rulesを読み込んだCursor Agentが開発作業を支援してくれますが、Agentを期待通りに動作させるための工夫をいくつか紹介します。

  • 複雑なタスクはAskから始める
    • Cursorのバージョン0.47.8ではAgentモードとは別にAskモードがあります。これはコードや説明の理解に適しており、直接のコード変更は行いません。まずこのモードで、実際に実行する計画（Plan）を記述させます。これでプランを確認後、Agentモードで自律的に実行させると精度が高まっているように感じます。
  • コンテキストを明示的にわたす
    • dbt model開発に必要なProject Rulesが読まれないケースがあるため、動作を安定させるにはチャット画面でProject Rulesを渡すことが効果的です。
      SQL修正後の続きの開発をAgentにお願いしている例
  • 古典的な静的解析・自動テストのガードレール
    • Agentにすべて判断させると、確実に守りたいルールが遵守されないケースもまだ多く見られます（編集してほしくない箇所、SQLのフォーマット、レイヤー間の参照ルール無視など）。また、現時点ではAgentの実行速度よりも古典的な静的解析のほうが速度が速く、効率も高まります。そのため、確実に守りたいガードレールを整備した上で、そのガードレールの中でAgentを実行させることが重要だと感じています。

社内の反応と定量結果

Agent機能とProject Rulesの活用により、現時点で私たちのdbt開発ステップは以下のように変化しました。

  • Step1. 社内独自で開発している dbt-helperを使ってdbt modelファイル群のテンプレートを作成する（🤖が✅）
  • Step2. SQLを更新（🧑‍💻の修正）
  • Step3. ローカルでdbt runを実行してエラーなくモデルが作成されるか確認（🤖が✅）
  • Step4. dbt-osmosis を実行してschema.ymlを更新（🤖が✅）
  • Step5. 必要に応じてdata_testsの追加・column descriptionの修正・Lightdash metadataを追加し、schema.ymlを更新（🤖がほぼ✅。一部🧑‍💻が修正）
  • Step6. ローカルでdbt testを実行してdata_testsがパスすることを確認（🤖が✅）
  • Step7. dbt modelの説明を記述するdocs.mdを更新（🤖が✅）
  • Step8. PRを作成しレビューを依頼する（🤖が✅）
    • pre-commit でリンターの実行・SQLフォーマットも修正される
    • PR作成後、自動的に複数のCIが実行される

この変化により、開発者はSQLロジックの設計・実装という本質的な作業にフォーカスできるようになりました。現在AIが精度の高いSQLを記述できるような改善(Step2の🤖化)を注力して進めています。

現時点でもすでに社内のエンジニアからポジティブな声があがっています：


また、直近社内でPR数1位でdbt model開発を行っているアナリティクスエンジニア @ktrru の開発量も、Agent機能のおかげでさらに向上しています。

Project Rulesの整備を3月上旬に集中的に行って以降、AIによるコード変更量が増加しました。本人の体感としても、Agentのおかげでdbt modelの開発量が増えているとのことです。


エンジニアがチャット経由で依頼し、AIが生成したコード量の時系列グラフ

まとめと今後

この記事では、dbt model開発においてCursor EditorのAgent機能を最大限に活用するための、Project Rulesの設定・運用方法について解説しました。Cursor Editorを使い始めた当初は、AIは完璧ではなく、期待通りに動作しないことも多々ありました。重要なのは、その結果を受けて「なぜ上手くいかなかったのか」「どのような指示やルールがあれば改善できるか」を考え、Project Rulesを継続的に見直し、改善していくことだと考えています。一方、Rulesを全部捨てて認識をリセットした話（with Gemini 2.5 Pro） で書かれているように「rulesが増大して辞書みたいになってきた結果、コンテキスト長の都合で内容が抜け落ち始めました」といった事象も発生する可能性があると思うので、引き続きベストプラクティスを探索していきたいと思います。さらに、投稿する前日にdbt MCP Serverが登場しました。これまでのProject Rules運用も大きく変わりそうで今後が楽しみです。

https://docs.getdbt.com/blog/introducing-dbt-mcp-server

当初はAgentにタスクを依頼しても失敗することが多く、「自分がやったほうが早いのでは？」と思うことも多々ありましたが、粘り強くProject Rulesの改修を重ねることで、そのように感じる場面も減ってきました。結果として、他のエンジニアの開発量も増え、組織全体の生産性向上につながったと感じています。開発の主導権（ドライバー）をAIに委ね、自分が助手席に回るといった意識の変化も重要だと感じています。

今後もこのようなアナリティクスエンジニアリングや、データと生成AIに関する知見を発信していきたいと思いますので、よろしければX（旧Twitter）もフォローいただけると幸いです！
https://x.com/okiyuki99

Ubie テックブログ
Ubie テックブログPublication

Ubie株式会社のテックブログです。 採用情報：recruit.ubie.life/engineer

Discussion