azure-recipe-user
はじめに
2026年6月15日〜18日にサンフランシスコおよびオンラインで開催された、Databricks社主催の年間最大規模のカンファレンスイベント「Databricks Data + AI Summit 2026」（DAIS）では、多くの新機能や今後の方向性が発表されました。
本記事は、DAIS2026 のセッション「Agentic Data Engineering with Genie Code and Genie ZeroOps」で登壇者が説明していた内容をもとに、筆者が要点を日本語で整理した要約レポートです。
前半から中盤までは登壇者の説明要旨を中心に整理し、最後に筆者の所感をまとめています。
※ 厳密な逐語訳ではなく、ライブデモや説明内容をもとに整理した日本語要約レポートです。
※ 機能名や提供状況は、セッション時点の案内に基づいています。
エグゼクティブサマリー
- Genie Code は、単なるコード生成ツールではなく、データ探索・文脈理解・ワークフロー実行まで含めて支援する、データエンジニアリング向けのエージェントとして紹介された。
- デモでは、メダリオンパイプラインの構築 → Jira 連携 → Git / DABs への組み込み → ジョブ作成までを、会話ベースで一気通貫に進める流れが示された。
- Instructions / Skills / コネクタ によって、組織の作法や外部文脈をエージェントに持たせられることが示された。
- 後半では Genie ZeroOps も紹介され、失敗ジョブだけでなく、ジョブは成功しているが、データ品質の観点では問題がある状態まで含めた運用自動化の方向性が示された。
注意: 本記事は Databricks の公開セッション内容をもとにした非公式の日本語要約であり、著作権・知的財産権は Databricks に帰属します。
図1. セッション冒頭では、まず注意書きのスライドが表示された。
登壇者が提示していた問題意識
セッション前半で登壇者が問題提起していたのは、AI エージェントがソフトウェア開発を大きく変えつつあるのと同じ変化が、データの仕事（data work） にも起き始めている、という点でした。
図2. 登壇者は「Data work is different」として、データの仕事の難しさを整理していた。
そのうえで登壇者は、データの仕事は単なるコーディングではないことを強調していました。セッションでは、主に次の3点が難しさとして挙げられていました。
1. データの仕事は複数の文脈をまたぐ
登壇者は、データエンジニアリングではコードだけでなく、カタログ、意味定義、品質、ガバナンスなど、複数の文脈を横断して扱う必要があると説明していました。
2. 本当に難しいのは「コード」より「データ」
たとえコードが正しく動いても、
- 前四半期の売上データを使ってしまう
revenueの定義が複数あり、誤った意味で参照してしまう
といった理由で、正しく動くが、間違った結果を返すことが起こると説明されていました。
3. 本番投入して終わりではない
登壇者は、データパイプラインは本番に入ってから問題が起きると述べていました。具体例として、次のような状態が挙げられていました。
- データ変更による失敗
- サイレントな異常
- ジョブは成功しているが、データ品質の観点では問題がある状態
こうした背景から、登壇者は汎用的なコーディングエージェントだけでは不十分であり、データ向けに最適化されたエージェントが必要だと説明していました。
図3. Genie Code は、データ探索・パイプライン構築・ジョブスケジュールまで含めて「データ作業向け」に設計されている。
登壇者の説明では、汎用的なコーディングエージェントはコード生成そのものは得意でも、
- どのテーブルを使うべきか
- どの定義が正しいのか
- その処理が本番で安全に動くか
といった、データ特有の文脈まで自然に扱えるとは限りません。
Genie Code は、こうしたデータ探索・意味理解・品質・運用まで含めて支援する前提で設計されている点が、汎用エージェントとの違いとして語られていました。
Genie ファミリーにおける位置づけ
セッションでは、Genie ファミリーが次のように整理されていました。
図4. Databricks は Genie ファミリーを「AI with Data Intelligence」として整理していた。
| プロダクト | 主な対象・用途 | 役割 |
|---|---|---|
| Genie One | ビジネスユーザー | データに質問し、適切なクエリを組み立てて回答する |
| Genie Agents | 特定ユースケース | 特定の業務・用途に応じたエージェント体験を提供する |
| Genie Code | 技術ユーザー | データパイプライン、ML ワークフロー、ダッシュボードなどを構築する |
| Genie ZeroOps | 運用・保守 | 本番パイプラインを監視し、壊れたときに調査・修正する |
この中で、本セッションの中心に置かれていたのが Genie Code です。
また、セッションでは次のような採用状況も紹介されていました。
- キーノートでは、Lakeflow パイプラインの 60% が Genie Code で作成されていると紹介された
- 登壇者は、Databricks 上では人間よりも Genie Code のほうが多くのコードを書いていると述べていた
- 生産性は 3倍、4倍、10倍 レベルで向上していると説明された
※ いずれも、セッション内で紹介された数値・発言です。
図5. Genie Code は「そのデータを知っている長年の同僚」のように振る舞うことを目指している。
このスライドを使って登壇者が説明していたのは、Genie Code が単にコードを書くだけではなく、Unity Catalog を起点に、Instructions / Skills / Connectors を通じて組織知を扱うという設計です。
つまり、データの意味や作法を知らないままコードだけを出すのではなく、その組織で実際に使える形に寄せていくことが重視されている、という説明でした。
デモ① Genie Code でパイプラインを構築する
最初のデモでは、Databricks の Lakeflow Pipeline Editor 上で、不正検知用のメダリオンパイプラインを構築する様子が示されました。
高レベルな指示だけで始められる
最初の依頼はかなりシンプルでした。
- 不正検知のためのメダリオンパイプラインを
customersとtransactionsテーブルを使って- 作ってほしい
ここでは、完全修飾名を渡さずに指示している点が示されていました。
デモでは、Genie Code が自らカタログを検索し、関連するテーブルを探しにいく様子が示されていました。
登壇者は、「必要なデータを探す作業こそ、退屈で時間がかかる」と述べており、この部分を Genie Code が肩代わりする点を強調していました。
アーキテクチャ提案から実装まで進める
デモでは、Genie Code が検索後に次のようなメダリオン構成を提案していました。
- Bronze：取り込み
- Silver：検証・エンリッチメント
- Gold：集約・提供
そのまま進めると、必要なファイルを作成し、変換コードを書き、ドライランまで実行していく流れが示されました。
途中の変更内容は asset change list（変更一覧）で確認でき、必要に応じて会話しながら軌道修正できる構成になっていました。
Auto Approve で長いタスクを止めずに進める
デモでは Auto Approve も紹介されていました。
通常、ファイル削除など一部の操作では承認が必要ですが、Auto Approve を有効にすると、Genie Code は
- 何をしようとしているか
- それがユーザーの意図に沿っているか
を自動的に判断しながら進めると説明されていました。
そのため、長いタスクでも途中で何度も止まりにくく、会話を切らさずに一気に進める体験を目指していることが示されていました。
Instructions と Skills で組織の作法を覚えさせる
このデモでは、Genie Code のカスタマイズ方法として Instructions と Skills も紹介されました。
-
Instructions
すべての会話に共通して適用されるルール
例：すべてのテーブルにqualityの table property を付ける -
Skills
特定ワークフロー向けの知識
例：不正検知パイプラインでは README を特定フォーマットで作る
デモ上では、Genie Code が不正検知用のスキルを読み込み、テンプレートに従って README を自動生成する様子も示されていました。
Atlassian（Jira）コネクタで「チケットから作業を始める」
後半では Atlassian（Jira）コネクタ も登場しました。
デモでは、Jira の自分のチケットを取得し、その文脈を使って次の作業を提案する流れが示されました。
- フライト遅延ダッシュボードの作成
- 不正検知パイプラインの構築と週次スケジュール設定
さらに、すでに作成したパイプラインに対して「では週次ジョブも作りましょうか」と提案し、そのまま 毎週月曜 8:00 実行のジョブを作成する様子も紹介されていました。
デモ①のポイント
- Genie Code は、コード生成だけでなく、必要なデータ探索も支援する
- Instructions / Skills によって、チームの作法をエージェントに覚えさせられる
- Auto Approve により、長いタスクを途中で止めずに進めやすい
- コネクタ を使うと、Jira などの外部文脈からそのまま作業を始められる
デモ② 作ったパイプラインを Git 管理に組み込む
次のデモでは、作成したパイプラインを Git に載せて、本番向けの資産として扱える形にする流れが紹介されました。
未実装機能をカスタムスキルで補う
登壇者は、「パイプラインを Git に追加する機能は、当時まだ本番投入前だった」と説明したうえで、custom skill（カスタムスキル） を作ってその操作を補ったと紹介していました。
そのスキルでは、たとえば次のような流れが定義されていました。
- パイプラインの詳細を見る
- 関連ファイルを列挙する
- ホームフォルダ内の Git フォルダ候補を探す
- ユーザーには最小限の質問だけする
登壇者は、このスキル自体もほぼ Genie Code が生成したと説明していました。
DABs で UI 資産をコード化する
ここで使われていたのが Databricks Asset Bundles（DABs） です。
登壇者の説明では、DABs は Databricks 上の資産をソースコードとして管理するための仕組みであり、UI で作成したパイプラインを Git や CI/CD に接続できる形へ変換できます。
Python をその場で生成して実行する
デモでは、Genie Code がその場で Python コードを生成し、実行まで進める様子も示されました。
Git 追加専用の特別なツールがあるわけではなく、スキルの内容をもとに Genie Code が Python を生成し、
- ファイルを移動する
- YAML 設定を書く
- フォルダ構成を整える
といった処理を進めていました。
一度エラーが出ても、自分で修正できると判断し、その場で再試行して成功する様子も紹介されていました。
デモ②のポイント
- 未実装の操作でも、Skills でワークフローを補える
- Genie Code は、コードを生成して実行しながら作業を進められる
- DABs により、UI で作成した資産を Git / CI/CD につなげられる
Genie ZeroOps が目指す運用自動化
このセッションの主役は Genie Code でしたが、後半では本番運用を支援する Genie ZeroOps も紹介されました。
図6. 登壇者は、継続運用の負荷が大きいことを ZeroOps の背景として示していた。
なぜ ZeroOps が必要なのか
登壇者は、Genie Code によってパイプラインを速く作れるようになるほど、今度は保守対象が増えるという問題が出てくると説明していました。
そのうえで、
「1日に何百本もパイプラインを作れるようになっても、それをすべて人手で保守するのは無理だ」
という形で、ZeroOps の必要性を説明していました。
例① タイポによる失敗を自動で見つける
最初の例では、不正検知ジョブが失敗していることを ZeroOps が見つける、というシナリオが紹介されていました。
原因は単純で、最新コミットで country を home country に誤って変えていた、というタイポでした。
登壇者は、ZeroOps が次の流れを自律的に進めるものとして説明していました。
- 最近の失敗を見つける
- 原因を調査する
- 修正案を提示する
- ドライランまで行う
例② ジョブ成功時のデータ品質異常を検知する
別の例として、パイプライン自体は成功しているのに、売上が約50%減少しているという異常を検知するシナリオも紹介されていました。
紹介されていた流れは次の通りです。
- 機械学習ベースの異常検知が急激な変化を見つける
- ただし偽陽性の可能性がある
- ZeroOps が追加調査して、本物の不具合だと判断する
- 最近のコード変更が原因だと特定する
- 下流ダッシュボードへの影響まで見て、Critical として優先表示する
このケースでは、原因は NULL を含むデータに対する drop 文 で、上流データは変わっていないのに、ロジックがデータを誤って捨てていたことが分かったと説明されていました。
さらに ZeroOps は、修正案だけでなく、今後同じ不具合を捕まえられるようにテストケースまで更新するものとして紹介されていました。
ZeroOps で示されたこと
- 失敗ジョブだけでなく、ジョブ成功時のデータ品質異常も扱う
- 異常検知、原因調査、影響分析を通じて、重要な問題を優先表示する
- 検証はサンドボックスで行い、本番に直接変更を加えずに修正案を出す
- 修正だけでなく、再発防止のためのテスト更新まで支援する
セッション時点での提供状況
| 機能 | ステータス |
|---|---|
| パイプライン構築・スケジューリングなど | 利用可能 |
| コネクタ | ベータ（ワークスペースで有効化可能） |
| フルページ版の Genie Code | ベータとしてロールアウト済み |
| Genie ZeroOps | プライベートプレビュー予定（セッションでは 2026年7月ごろ と案内） |
※ 提供状況はセッション時点の案内に基づいています。最新情報は Databricks の公式情報をご確認ください。
ここまでの整理
ここまでの内容を踏まえると、登壇者がこのセッションで伝えていたメッセージは、次の3点に集約できます。
- Genie Code は、汎用的なコーディング支援ではなく、データの仕事そのものに最適化されたエージェントとして位置づけられている
- 価値の中心は「コードを書くこと」だけではなく、正しいデータを見つけ、組織の文脈を踏まえてワークフローを前に進めることにある
- その先には、Genie ZeroOps による本番運用の自動化まで含めた、より広いエージェント体験が構想されている
ここまでが登壇者の説明要旨です。以下は筆者の所感です。
筆者の所感
今回のセッションで筆者が特に印象的だったのは、Genie Code が単なる「コード生成ツール」ではなく、データエンジニアリングの前後工程まで含めて扱おうとしていた点です。
- データ探索
- 組織の作法の反映
- Git / CI/CD への接続
- 本番運用の監視と修正
こうした一連の流れを、会話ベースのエージェント体験でつなごうとしていることが、セッション全体から伝わってきました。
特に、Instructions / Skills / コネクタ の組み合わせは、エージェントに「何を知っていてほしいか」「どう振る舞ってほしいか」を移し込むための重要な仕組みに見えました。
今後こうした仕組みが一般化すれば、データエンジニアの役割は「すべてを自分で書く人」から、エージェントに文脈と基準を与え、レビューし、運用全体を設計する人へと変わっていくのかもしれません。
参考文献
- What’s new in Genie Code at Data + AI Summit 2026 | Databricks Blog
- Introducing Genie ZeroOps: Put your data and AI operations on autopilot | Databricks Blog
- Databricks DAIS 2026: Genie One, Agent Bricks, and What Builders Need to Know — ChatForest
お知らせ
本記事が参考になった方は、あわせて以下の日本語イベント・特設サイトもぜひご覧ください。
※ 各案内の詳細リンクは、公開時に差し替えてご利用ください。
DAIS2026 Recap イベント
現地参加が難しかった方や、主要トピックスを短時間で振り返りたい方向けに、Recapイベントを開催します。
セッションの要点整理や、日本企業での実装観点も交えてご紹介予定です。
▼ 開催概要・お申し込みはこちら
ナレッジコミュニケーション DAIS2026 特設サイト
DAIS2026で発表された注目テーマ、関連セッション、実務での活用ポイントを継続的に発信する特設ページです。
イベント情報の整理・社内共有にもご活用いただけます。
Databricks 導入支援サービスサイト
Databricksの導入検討から活用定着まで、課題に応じた支援メニューをご紹介しています。
「何から着手すべきか相談したい」という段階でも、お気軽にご覧ください。
databricks.kc-cloud.jp