Databricksの開発体験は、ここ最近かなり変わってきました。
特に大きいのが Genie Code です。
Genie CodeはDatabricks Workspace上でコードを生成・実行し、エラーのデバッグやPipelineの構築まで行えます。
さらにUnity Catalogのテーブル、カラム、LineageといったDatabricks内部の情報も利用できます。
一方、本番環境まで考えると Declarative Automation Bundles（旧Databricks Asset Bundles） も重要です。
Bundleを使うと、JobやLakeflow PipelineなどのDatabricksリソースをYAMLとしてコード管理できます。
Databricks自身もBundleを、Source Control、Code Review、Test、CI/CDといったSoftware EngineeringのプラクティスをDatabricksプロジェクトへ適用するためのIaCアプローチとして位置付けています。
ここで少し悩ましい問題があります。
Genie Codeを最大限使うならDatabricks Workspace上で開発したい。
しかしIaCやCI/CDを考えると、Gitにあるコードを基準にDatabricks環境を作りたい。
AIを使ったDatabricks開発では、この2つをどう組み合わせるのがよいのでしょうか。
Bundleを使うとDatabricksもコード中心の開発になる
Declarative Automation Bundlesを使うと、例えば次のような構成にできます。
project/
├── databricks.yml
├── resources/
│ ├── jobs.yml
│ └── pipelines.yml
├── src/
│ ├── bronze/
│ │ └── customer.py
│ ├── silver/
│ │ └── customer.py
│ └── gold/
│ └── customer.py
└── tests/
└── test_customer.py
Bundleでは、
- Python / SQL
- Job
- Pipeline
- 環境ごとの設定
- Test
などを1つのプロジェクトとして管理できます。
JobやPipelineの設定もWorkspace上のGUIだけではなく、Repository上のコードになります。
そのため開発フローも、
feature branch
↓
実装
↓
Test
↓
Pull Request
↓
Review
↓
Merge
↓
Bundle Deploy
という一般的なソフトウェア開発に近い形になります。
Databricks環境が必要なIntegration Testについても、必要に応じてtest用targetへBundleをdeployし、CIから実行できます。
重要なのは、
GitにあるコードからDatabricks環境を再現できる状態にしておくこと
です。
そこでGenie Codeをどう使うかが難しい
Genie CodeはDatabricks Workspaceの中で動きます。
そのため、
Databricks Workspace
↓
Genie Code
↓
Pipelineを修正
↓
実行して確認
という開発体験は非常に便利です。
特にデータエンジニアリングでは、
このテーブルにはどんなデータが入っている？
このPipelineが失敗している原因を調べて
このテーブルを使ってSilverを作って
といった、Databricks環境そのものを見ながら作業したい場面が多くあります。
Genie Codeはコードだけではなく、Unity CatalogやPipelineなどDatabricks内部の情報を利用できるため、このような作業と相性が良いです。
ただ、BundleによるIaCを前提にすると少し考える必要があります。
Workspaceを直接変更するとGitとの役割が曖昧になる
例えばGenie CodeでWorkspace上のPipelineを直接変更したとします。
Genie Code
↓
WorkspaceのPipelineを変更
↓
動作確認
↓
Gitにも変更を反映
これでも開発はできます。
ただしBundleを利用している場合、本来は、
Git
↓
Bundle
↓
Databricks
という流れでDatabricks環境を作りたいところです。
Workspace上でも変更し、Git上でも変更するようになると、
GitとWorkspaceのどちらが最新なのか
が分かりにくくなります。
例えばWorkspace側だけPipelineを変更した後に、
databricks bundle deploy
を実行すれば、Git側の定義によって変更が上書きされる可能性があります。
そのためBundleを使う場合は、
基本的にはGit側を変更し、Bundleを通してDatabricksへ反映する
という流れにした方がシンプルです。
Workspace内でGit + Bundleを使う方法もある
とはいえ、現在のDatabricksではBundleをWorkspace内で直接作成・編集できます。
Git Folder内にBundleプロジェクトを配置し、
Databricks Workspace
Git Folder
├── databricks.yml
├── resources/
├── src/
└── tests/
という構成にできます。
Databricks公式でも、Workspace上のGit FolderからBundleを作成し、編集・デプロイする方法が提供されています。
つまり、
GitHub
↕
Databricks Git Folder
↓
Genie Code
↓
Bundle
という開発も可能です。
Genie CodeとGit、BundleをすべてDatabricks Workspace内で扱えるので、DatabricksをIDEのように利用する開発スタイルです。
この方法はかなり便利そうです。
ただ、ここで別の選択肢も出てきます。
BundleによってDatabricksの大部分をコード管理するのであれば、Repositoryを直接扱えるCoding Agentで開発してもよいのではないか？
という考え方です。
Codex / Claude Code + Bundleという選択肢
Bundleを採用すると、JobやPipelineを含めてDatabricksプロジェクトの多くがRepository内に入ります。
例えば、
databricks.yml
resources/
jobs.yml
pipelines.yml
src/
bronze/
silver/
gold/
tests/
という状態です。
この構成は、CodexやClaude CodeのようなRepository全体を扱うCoding Agentとかなり相性が良いです。
例えば、
customerにcountry_codeを追加する。
Bronze、Silver、Pipeline定義、Testまで必要な変更を行って。
と依頼した場合、
src/bronze/customer.py
↓
src/silver/customer.py
↓
resources/pipelines.yml
↓
tests/test_customer.py
のように、Repository全体を横断して変更できます。
Bundleを使わずWorkspaceのGUIでJobやPipelineを管理していると、Coding Agentからはその設定が見えません。
しかしBundleを利用すれば、
Python
SQL
Job
Pipeline
Test
CI/CD
をRepository側へ寄せることができます。
Databricks自身も現在、外部AI Coding Agent向けのAgent Skillsを提供しています。
Databricks CLIでは、
databricks aitools install
によって、Codex CLI、Claude Code、GitHub CopilotなどにDatabricks用のskillsやpluginsを導入できます。
つまり、
Codex / Claude Code
↓
Databricks Agent Skills
↓
Bundle / Job / SQL
↓
Databricks
という開発方法も、Databricksが公式にサポートし始めています。
Coding AgentとGenie Codeは得意なものが違う
ここまで考えると、Genie CodeとCodex / Claude Codeを競合として考える必要はなさそうです。
大きく分けると、
Coding AgentはRepositoryに強く、Genie CodeはDatabricks環境に強い
と考えると分かりやすいです。
| 作業 | 向いているもの |
|---|---|
| Bundle YAMLの変更 | Codex / Claude Code |
| Repository全体の変更 | Codex / Claude Code |
| Unit Test / Integration Testの実装 | Codex / Claude Code |
| リファクタリング | Codex / Claude Code |
| CI/CDの修正 | Codex / Claude Code |
| 実データの調査 | Genie Code |
| Unity Catalogの探索 | Genie Code |
| SQLの試行錯誤 | Genie Code |
| Pipeline実行エラーの調査 | Genie Code |
| Notebookでの分析 | Genie Code |
例えば、
この変更によって影響するコードを全部修正して
という依頼ならCoding Agentが向いています。
一方、
なぜこのPipelineが遅い？
という調査では、
- 実データ量
- Table Schema
- Unity Catalog
- Lineage
- Pipelineの状態
など、Repositoryだけでは分からない情報が必要になります。
このような場面ではGenie Codeの方が自然です。
役割を分けると開発フローがシンプルになる
例えば次のように役割を分けます。
Developer
│
┌───────────┴───────────┐
│ │
Genie Code Codex / Claude Code
│ │
Databricks環境の調査 Repository編集
│ │
└───────────┬───────────┘
│
Git
│
Test
│
Bundle
│
Databricks
Genie Codeでは、
このテーブルにはどんなデータが入っているか
Pipelineがどこで失敗しているか
どのSQLがボトルネックになっているか
といったDatabricks側の情報を調査する。
その結果をもとに、実際の変更はRepository側で行います。
Codex / Claude Code
↓
Git
↓
Test
↓
Bundle
↓
Databricks
こうすればWorkspace上の変更とGit上の変更が混在しにくくなります。
CI/CDもAIが入っても基本は変えない
AI Coding Agentを使ってコードを書くようになっても、CI/CDそのものを変える必要はありません。
例えば、
Developer
│
Codex / Claude Code
│
▼
feature branch
│
├── Unit Test
├── bundle validate
└── 必要に応じてIntegration Test
│
▼
Pull Request
│
Review
│
▼
Merge
│
▼
GitHub Actions
│
bundle deploy
│
▼
Databricks
という流れです。
Databricks環境が必要なTestであれば、
CI
↓
Bundle test target
↓
Integration Test
という構成にできます。
AIがコードを書いたとしても、
AI
↓
Git
↓
Test
↓
Review
↓
Bundle
↓
Databricks
という流れは変えません。
現時点で考えられる構成
ここまでを整理すると、Databricksのデータ基盤では例えば次のような役割分担が考えられます。
| 領域 | ツール | 主な役割 |
|---|---|---|
| Cloud / Workspace基盤 | Terraform | Network、IAM、Workspaceなど |
| Databricksプロジェクト | Declarative Automation Bundles | Job、Pipeline、コード、環境差分 |
| コード管理 | Git | Databricks環境を再現するコードを管理 |
| Repository開発 | Codex / Claude Code | 実装、Bundle、Test、CI/CD |
| Databricks調査 | Genie Code | 実データ、Unity Catalog、SQL、Pipelineの調査 |
開発フローは、
Codex / Claude Code
↓
Git
↓
Test
↓
Review
↓
Bundle
↓
Databricks
を基本にする。
その横でGenie Codeを、
Databricks
↕
Genie Code
として使い、Databricks内部の情報が必要な調査やデバッグを担当させます。
まだ開発スタイルは一つに収束していない
現在のDatabricksを見ると、
Genie Code
+
Git Folder
+
Bundle in Workspace
というWorkspace中心の開発を強化しています。
その一方で、
Codex
Claude Code
Cursor
GitHub Copilot
+
Databricks Agent Skills
+
Databricks CLI
という外部Coding Agentからの開発も強化しています。
少なくとも現在の公式機能を見る限り、
Workspace中心で開発する
or
外部Coding Agent中心で開発する
という一つの形にはまだ収束していません。
AIをDatabricks開発のどこに置くかについては、まだ過渡期にあるように見えます。
まとめ
Declarative Automation Bundlesを使うことで、
Python
SQL
Job
Pipeline
Test
といったDatabricksプロジェクトの多くをRepository上のコードとして管理できます。
これはCodexやClaude CodeのようなRepository全体を扱うCoding Agentと非常に相性が良いです。
一方でGenie Codeには、
実データ
Unity Catalog
Lineage
Pipeline
Databricksの実行環境
といった、Repositoryだけでは得られないDatabricks内部のコンテキストがあります。
そのため現時点では、
Codex / Claude CodeはRepositoryを変更する。
Genie CodeはDatabricks環境を調査する。
という役割分担が一つの使いやすい形だと考えています。
そして、どのAIを使う場合でも、
AI
↓
Git
↓
Test
↓
Bundle
↓
Databricks
という開発フローを維持しておけば、今後Coding AgentやGenie Codeが進化しても、CI/CD全体を大きく変える必要はありません。
DatabricksのAI開発は、まだちょうど過渡期にいるように感じます。