![[登壇レポート]Modern Data Stack最新動向 ～買収・AI、激動の2025年～ #DataEngineeringStudy](https://devio2024-media.developers.io/image/upload/f_auto,q_auto,w_3840/v1759445660/user-gen-eyecatch/daalujhg05p8krbgveto.png)
[登壇レポート]Modern Data Stack最新動向 ～買収・AI、激動の2025年～ #DataEngineeringStudy
さがらです。
2025年9月30日に、「Data Engineering Study #31 公開企画会議 アドバイザーと語る気になる技術」が開催されました。（私がアドバイザーとなってから、初のData Engineering Studyでした！）
このイベントの中で、「Modern Data Stack最新動向 ～買収・AI、激動の2025年～」というタイトルで発表をしてきたので、本記事ではこのセッションの登壇内容についてまとめます。
登壇資料
相樂の登壇資料
参考：ikkiさんと吉田さんの登壇資料
参考までに、ikkiさんと吉田さんの登壇資料もリンクを貼っておきます！
イベント録画
頂いた質問について
※実際のセッションでは上手く回答できない面もあったので、それを補足する回答文書となっております。
Snowflake・Databricks、どちらを選べばいいの？
とても回答が難しい質問ですが、「現状どちらを選んでも良いため、実際に触ってもらって良いと感じた製品を選定してもらえれば間違いありません」というのが私の持論です。
例えば、Databricksは5年ほど前だとNotebookでSparkの処理を書いて分析するような印象が強くSQLを用いた一般的なデータウェアハウスのような使い方が出来ない印象がありましたが、現在ではPhotonやSQLウェアハウスのおかげで一般的なデータウェアハウスのように使用することができます。
一方でSnowflakeについても、データウェアハウスからスタートした製品で機械学習やレイクハウス方面が弱い印象があると思いますが、機械学習の一連のプロセスを支える機能も出ていますし、IcebergテーブルのサポートやOpen Catalogによりレイクハウスアーキテクチャにも対応しています。
また、SnowflakeとDatabricksどちらも利用する、というケースもレイクハウスアーキテクチャならば問題なく可能です。実際関連するイベントやブログも公開されています。
そのため、「現状どちらを選んでもよく、どちらを選んでも絶対に悪い選択肢ではない」というのが私の回答になります。
Modern Data Stackの進化により楽になる分野はどういう点で、データエンジニアはどういう点にリソースを割けるのか？
（これは当日全く上手く回答ができなくて失礼しました…）
まずざっくりと、Modern Data Stackはクラウドネイティブな技術を前提としたSaaSやOSS群のことを指すのですが、最近のModern Data Stackの進化により、以下の分野で楽になっていると思います。
- データロード
- データソースとDWHの認証情報だけ入れれば、スキーマの変化も追従して自動で差分検知データロードしてくれるようになった
- 閉域網のデータソースに対して、エージェントを入れることでよりセキュアにデータロードを行えるようになった
- データウェアハウス
- ストレージとコンピュートが分離したアーキテクチャにより、リソースに悩むことがなくなった
- 別アカウントへのデータシェアリングも物理的なコピー不要でできるように
- PythonやSparkで頑張らなくても、SQLだけでなんとかなる場面が増えた
- データ変換
- Gitでバージョン管理した開発・本番の分離が容易にできるようになった
- データテストも数行で簡単に定義できるようになった
- GUIでの変換の場合でも、Git管理が出来たり、GUIで作成したワークフローをウェアハウス側のクエリにプッシュダウンできるようになった
- データカタログ
- ただデータを登録するだけではなくて、データ品質、アクセスリクエストの制御、などカタログ上でできることが増えた
- データアプリ
- マネージドなインフラを提供してくれるため、ユーザーはアプリ開発に専念できるようになった
逆にリソースを割くべき領域は、以下の点と考えています。
- ネットワーク
- 閉域網のデータソースをクラウドDWHにロードするとき、イントラネットとクラウドDWHをセキュアに疎通させるとき、などネットワークに関する取り組みが重要なのはずっと変わっていないです
- データモデリング
- ユーザー側でユースケースに応じて設計しないといけない点は変わっていないです（実装はAIにより楽になっていると思いますが、それでも仕様をきちんと固めないとAIもこちらの意図に沿った実装はしてくれない）
- データマネジメント
- 実装がModern Data Stackにより楽になっても、そのデータを使うのは人間です
- 以下は一例ですが、このような観点でのデータマネジメントはやはり重要です
- どうやってデータを使ってもらうか（ikkiさんも仰っていた、「データ活用の総量を増やす」ことですね）
- たくさんあるデータソースの中で、どのデータソースを優先して整備するか
- どのデータの品質を優先度上げて担保するか
- 整備したデータ・ダッシュボードは使われているか、使われていないなら廃棄すべきか
- etc
- LLM活用 ※これは2025年10月時点の私の持論強めの意見ですが…
- LLMの活用に関しては各SaaSも機能開発を進めていますが、どうしてもLLM単体やLLMに特化したサービスのアップデートが異常に早く、SaaSだけでLLMを活用しようとすると用途が限定的になってしまう印象が2025年10月時点ではあります
- SnowflakeのCortex AISQLなど、SaaS独自で利用できる非常に便利な機能も出始めてはいます
- そのため、LLM活用を加速させたい場合には利用しているSaaSに閉じこもらず、OpenAI社やAnthropic社の提供しているサービスを試したり、別の生成AIを用いたサービスを試したり、ということを勧めたいです
- LLMの活用に関しては各SaaSも機能開発を進めていますが、どうしてもLLM単体やLLMに特化したサービスのアップデートが異常に早く、SaaSだけでLLMを活用しようとすると用途が限定的になってしまう印象が2025年10月時点ではあります
まとめると、データエンジニアリングの技術的なところは間違いなくModern Data Stackのおかげで楽になっているのですが、「そのデータ基盤をどう人間が使っていくか」という観点ではリソースを割いていかないといけない、と感じています。
宣伝
今回は10分という登壇時間であったため十分にModern Data Stackの最新情報を話すことができなかったのですが、11月6日にFindy社主催で開催されるData Engineering Summitではより深く、各ワークロード別の最新情報についてお話をする予定です！
以下のURLから、参加申込をお待ちしています！
