2026年6月1日～4日にサンフランシスコで開催されたSnowflake社によるグローバルで最大のイベント「Snowflake Summit 2026」に参加しました。
データ基盤の構築やデータにまつわるPoCの担当者が、本イベント内のセッションで語られた「AIエージェント時代のデータエンジニアリング」 についてレポートします！
＊Snowflake Summit 2026ブレイクアウトセッションレポート第一弾として、Snowflake Summit 2026ブレイクアウトセッション編①AIエージェント時代のエンジニアの働き方を公開しております。

今回は、私が普段データ基盤の構築やPoCで向き合っているテーマ、データエンジニアリングのセッションからです。
データ基盤の現場にいると、「改善のための時間がいつまでも生まれない」感覚に覚えがある方は多いはずです。エンジニアリングではなく応急処置が日常になっている、会場で語られた事例は、その実感をそのまま裏づけるものでした。

本ブログでは、キーノート以外の2つのセッションから、特に印象的だった2つをご紹介します。

AIエージェント時代のデータエンジニアリング ポイントその①：エージェントを「同僚」にする鍵は、dbtの出力にある

米国のある自動車マーケットプレイスのデータ移行事例からご紹介します。
記事1でも触れた米国の自動車マーケットプレイスが内製した「自律型データエンジニアエージェント」は、エージェント時代の働き方を先取りしていました。
GitHubで「ready for a turbo」とコメントするとPRレビューを実行し、必要な情報を返してくれる。PRレビューは48倍、ジョブのトリアージは12倍に高速化したそうです。

エージェントがここまで働けるのは、エージェントに渡すメタデータが整っているからでもあります。
ここで効いてくるのが、dbt Fusion *の出力形式です。
dbt Core**はメタデータをJSONで吐き出していて、エージェントには重く、解析しづらい形でした。dbt Fusionではコンパイルのたびに列指向のParquet形式でアーティファクトを生成するようになり、プロジェクトの構造やリネージといったコンテキストを、エージェントが高速にクエリできます。エージェントの賢さは、こうした足回りの地味な改善に支えられています。
＊dbt Fusion: パフォーマンスと開発者体験を向上させるために開発された、次世代の実行エンジンです
＊＊dbt Core: オープンソースで提供されるコマンドラインインターフェース（CLI）ツールです

個人的にも、dbt Fusion がSnowflakeでも動くようになったのは大きい変化です。普段のデータ基盤づくりでも、今後ぜひ取り入れていきたいところです。

AIエージェント時代のデータエンジニアリング ポイントその②：オーケストレーション不要のパイプラインは、もう現実

「AIでAIを構築する」と題したパイプライン開発セッションでは、3つのデモで具体例を公開していました。

1. Dynamic Tablesによる自動リフレッシュ
2. Snowparkによる不正検知
3. SparkコードのDAG自動生成

順にご紹介します。

１つ目はDynamic Tablesです。ベーステーブルから複数のDynamic Tablesとビューを組むと、オーケストレーション設定なしで、データ到着に応じて自動リフレッシュされます。エンドツーエンドのレイテンシは最短1秒。さらに定義の中でSQLからAI関数（プロンプト＋モデル指定）を呼び出し、メニュー説明文を生成していました。モデルのホスティングもAPIキー管理も不要、「SQLからAI機能を呼ぶだけ」です。

会場にて撮影した写真

２つ目はSnowparkによる不正検知です。PostgresのデータをDB API（session.read）でほぼ一括に取り込み、ベクトル化UDFで特徴量を生成、ローカル学習したXGBoostをModel Registryに登録し、モデルを一度だけロードしてワーカー間で共有する。メモリ効率の良い大規模バッチ推論で、数百万件の取引にfraud scoreを付与していました。承認済みパッケージだけを使うprivate artifactoryの運用も、現場で効きそうな工夫です。

会場にて撮影した写真

３つ目は、既存のSparkコードをそのままSnowflake上で実行し、Pipeline BuilderとCortexがノートブック間の依存関係を解析してDAGを自動生成するという流れでした。

デモ1とデモ3では、[DCM Projects](https://docs.snowflake.com/ja/user-guide/dcm-projects/dcm-projects-overview)（Snowflakeのデータベースオブジェクトの変更を宣言的に管理する機能。執筆時点ではプレビュー）でplan → deployを行い、人が変更差分を確認してから本番反映していました。「全自動」ではなく「人が承認する自動化」である点が、実務に乗せるうえで欠かせないところです。

まとめ

2つのセッションに通底していたのは、データエンジニアの役割が「パイプラインの運用保守」から「ソフトウェアエンジニア／データプロダクトの作り手」へ移っている、という変化です。登壇者は一様に、黙々とコードを書くだけでは成り立たず、ステークホルダーとの関係構築や技術以外の視点も要る、と語っていました。
空いた時間の一部はエージェントに託し、人はエージェントが力を発揮できるよう、データのコンテキストを整える側へ回る。そうやってエージェントをうまく働かせる土台をつくれるかどうかが、これからのデータ組織の分かれ目になりそうだ、と感じたSummitでした。
次回は、AI活用の土台となる「データガバナンス」についてご紹介する予定です。

 本記事は、2026年6月4日時点の情報をもとに作成しています。製品・サービスに関する詳しいお問い合わせは、弊社Webサイトからお問い合わせください。
https://data-management.dentsusoken.com/snowflake/inquiry/

本サイトのブログ記事に加え、Snowflakeを中心としたデータエンジニアリング関連の技術的な情報を掲載したテックブログもWeb公開しております。
是非、こちらのテックブログもご覧ください。
https://zenn.dev/p/datatechblog