Snowflake Summit 2025 Day2 レポート:Keynote

お世話になっております。primeNumberの庵原です！
この記事ではSnowflake Summit 2025のDay2でのKeynoteで発表された内容や様子について現地で見たもの聞いたものを速報形式でまとめてお送りいたします！

既存のSnowflakeが提供してきたDWHとしてのエコシステムからさらに進化して、「AI」「Agentic:自律的」「Simplicity:シンプルさ」「Interoperability:相互運用性」「TRUSTED: 信頼できる」あたりが大きなキーワードのように聞こえました。

Adaptive Compute

今まではWarehouseサイズの指定やスケーリングについては運用者が用途や使われ方によって管理者がその場で割り当てるWarehouseの許可の範囲を指定したり、クエリ実行者がその場で許可されているWarehouseを選択して利用することが可能でしたが、今回発表されたAdaptive Computeはこれまでのように利用者や管理者が 明示的にWarehouseサイズやスケーリング設定を選択・調整する必要がなくなる という点が大きな進化です。

容量課金型Snowpipe Ingest料金形態

今までのSnowpipeの料金形態は、Native TableやIceberg向けで課金形態が分かれていましたが、今回の発表で取り込み量（GB）ベースのシンプルな課金モデルになりました。
また最大平均で約50%程度のコスト削減が見込まれ、利用ユーザーは透明的な移行のなかでコスト削減まで行われるメリットが多い内容でした。

Snowflake Horizon Catalog強化

今までは タグ付与・機密データ分類・アクセスポリシーの見直し・証跡確認・バックアップ／DR の実装 といったガバナンス＆セキュリティ運用は、管理者が個別機能や外部ツールをまたぎながら手作業でチェックリストを回す、そんな“タスクリスト管理”に近いスタイルが主流でした。

結果として

• 「誰がどのデータに触れているのか把握が遅れる」
• 「機密列を追加してもタグ付け漏れが出る」
• 「パスワード運用や MFA 強制など“入口対策”が部署ごとにバラバラ」
• 「DR・バックアップの整合性や監査証跡を都度確認する負荷」

といった 属人化・穴あき運用 が避けられませんでした。

しかし今回発表された Snowflake Horizon の強化は、こうした“点在する手作業”を プラットフォームが丸ごと肩代わりしてくれる、という点が最大の進化です。

要するにガバナンス・セキュリティ・可観測性・事業継続・認証の全レイヤーを「設定する」のではなく「宣言（ポリシー）するだけ」で、あとはSnowflakeが自動的に運用してくれる形に進化しました。

Horizon Copilot

今までは 「このテーブルに機密データが混ざっていないか？」「誰が GDPR タグのついた列にアクセスしたか？」 といったガバナンス／セキュリティの質問が生じるたびに、運用者がタグ管理ビューをSQLでJOINしたり、複数のUI画面を行き来して監査ログをダウンロード → 手作業で突き合わせる、そんな“クエリ職人＋スプレッドシート”型の調査プロセスが必須でした。

しかし今回発表されたHorizon Copilotは、これまでのように 運用者がSQLを書いたりダッシュボードを掘り進める必要がなくなる、という点が大きな進化です。

Copilot に 自然言語で「リージョンEUに保管された未タグ付けの個人情報列を教えて」「過去7日でPIIタグのデータにアクセスしたロールを一覧にして」 と尋ねるだけで、Snowflakeが内部メタデータ・アクセスログ・Horizon Catalogを横断検索し、回答・根拠・推奨アクション（タグ付けやポリシー更新の SQL）まで自動生成してくれます。

まさに「データガバナンス版 Copilot」と呼べる体験が、宣言的ポリシーと自動可視化を備えたHorizonで実現します。

External Asset Catalog

今までは 「Snowflake の外側にあるデータパイプライン定義（Airflow や dbt）、BI ダッシュボード（Tableau／Power BI）、他DWH・DB（SQL Server、PostgreSQL、Databricks など）の所在や責任者をどう把握するか」が担当者の悩みの種でした。個別ツールやスプレッドシートで“資産台帳”を手作業で更新したり、変更があるたびにSlackやメールで状況をヒアリングして回る、そんな “人づてカタログ”が現実的な運用手段だったわけです。

しかし今回発表された External Asset Catalog は、こうした点在するデータ／パイプライン／BI レポートのメタデータ収集とカタログ化をSnowflakeが自動で肩代わりしてくれるという点が大きな進化です。

• OpenLineage・dbt・Apache Airflow などのパイプライン
• Tableau・Microsoft Power BI のワークブック／レポート
• SQL Server・PostgreSQL・MySQL・Oracle・Databricksなど外部DWH・データレイク

これらをSnowflake Horizonがスキャンして統一カタログに登録し、系統 (Lineage)・所有者・更新頻度・アクセス権をひと目で確認可能になり、検索・依存関係解析・タグ付け・ポリシー適用もSnowflake内部資産とまったく同じUIで行えます。

Snowflake OpenFlow

今まではバッチのSnowpipe/COPY、CDCやストリーミングのKafka連携・Streams/Tasks、さらにはSaaSやログ用に外部ETLやNiFiを別途運用するなど、データ形式や到達スピードごとに異なるツールと手順を組み合わせる必要がありました。

今回発表されたOpenFlowはこれまでのように利用者や管理者がバッチ・CDC・ストリーミング・非構造ファイルといった取り込み方式を意識してパイプラインを設計・切り替える必要がなくなるという点が大きな進化です。

ソースを選択してポリシーやターゲットを宣言するだけでSnowflakeが最適なエンジンを自動選択し、スキーマ変化追従や順序保証、リトライ、スケーリングまで統合的にハンドリングし、Snowflake管理環境とBYOC（自社VPC内実行）の両方を同一のUI/APIで提供します。

dbt Project in Snowflake SnowSight

※ 私が一番熱盛だと思う発表でした

今までは dbt 開発・テスト・本番デプロイ を行うには、
①ローカル or Cloud IDE で dbt プロジェクトを編集
②CI/CD でパッケージ化
③Snowflake へ model 実行ジョブを送信
④結果を SnowSight で確認

と、複数コンソールと外部ランナー を跨いだ煩雑なワークフローが必要でした。

しかし今回発表された “dbt Projects in SnowSight” は、これまでのように利用者や管理者が外部IDE・ランタイム・CI設定を個別に構築・運用する必要がなくなるという点が大きな進化です。

1. ブラウザ IDE（SnowSight Workspaces）内で dbt プロジェクトを直接編集
2. Git 連携と自動バージョン管理 をワンクリック設定
3. Snowpark コンテナでモデルを即時実行（依存パッケージもコンテナに自動バンドル）
4. 実行後は SnowSight 上でステージ間比較・データプロファイル・リネージ可視化 が即反映

つまり「書く→テスト→デプロイ→モニタリング」をSnowflake だけで完結でき、上でも紹介したAdaptive Computeがコンピュート最適化を自律化したのと同じ発想で、dbt Projects in SnowSight はELT開発ライフサイクルを自律化し、データエンジニアはコードに集中できるようになります。

直近発表されたdbt Fusionも使えるとのことでdbtのエコシステムを自身で作成しなくても、Snowflake上だけでCI/CDやランタイムの設定を行う必要がなくなったのはdbt Cloudの選択が数多の理由でできない人にとって強力なアシストになると思います。

Snowflake Postgres

今まではトランザクション系ワークロードはRDSやCloud SQLなど、別クラウドサービスのPostgreSQLを個別に立ち上げ、パッチ適用・スケール設定・バックアップ・レプリケーションをアプリごとに運用し、分析に回すには ETL／CDCでSnowflakeへ再取り込み、という二重基盤・二重運用が当たり前でした。

しかし今回発表されたSnowflake Postgresは、これまでのように利用者や管理者が独立したPostgreSQLクラスターを設計・監視・メンテナンスする必要がなくなる、という点が大きな進化です。

Snowflake のコンソールから “CREATE DATABASE … ENGINE = POSTGRES” と宣言するだけで、高可用クラスタリング・自動スケール・ポイントインタイム復旧・Horizon ガバナンス（RBAC／タグ／監査ログ）をフル継承したフルマネージド OLTPが即時利用可能になり、さらに行レベルの変更はSnowflakeテーブルへネイティブ複製されるため、運用と分析が同一セキュリティ境界・同一データコピーで完結し、開発者はアプリロジックに、データチームは価値創出にそれぞれ集中できます。

またこれはCrunchy Dataの買収が背景にあり、SnowflakeのPostgres利用における潮流や未来については喜田さんの記事が骨太で良記事だったので、こちらも是非ご覧ください。

https://ex-ture.com/blog/2025/06/03/snowflake-summit-2025-snowflake-crunchy-data/

SnowConvert AI & Migrate Assistant

今まではTeradata/Oracle/SQL Serverなど旧DWHのSQL・ストアド・ETLスクリプトを

1. 手作業で棚卸し
2. 互換性調査
3. Snowflake方言へ書き換え
4. 動作検証

という“人海戦術の移行プロジェクト”が当たり前でした。

今回発表されたSnowConvert AI & Migration Assistantはこれまでのように利用者やSIベンダーが数万行のコード解析や依存関係マッピングを手動で行う必要がなくなるという点が大きな進化です。

AIがソースDBを自動クロールしてSQL/DDL/マクロ/バッチを分類し、以下を一括で行ってくれます。

1. 互換ギャップをスコアリング
2. 変換プランを生成
3. Snowflake向けにコードを一括変換
4. ユニットテスト用テンプレートまで自動出力

Migration AssistantはGUIで「評価→変換→検証→カットオーバー」をウィザード化し、依存ラインや期間・コスト削減効果をダッシュボード提示。結果、移行リードタイムは月単位から日単位へ、変換ミスはAIの静的解析で事前検出できるため、データチームは新機能活用と価値創出に集中できます。

Gen2 Warehouse

今まではクエリ性能を高めたい場合、運用者が都度 「より大きいWarehouseサイズへ切り替える／マルチクラスターを許可する／クエリやクラスタキーをチューニングする」 といった手動対応を行いながら、コストとパフォーマンスのバランスを探るしかありませんでした。

今回発表されたGeneration 2(Gen2) Warehouse は、これまでのように利用者や管理者がサイズ変更や高度なチューニングに時間を割く必要がなくなるという点が大きな進化です。新世代のハードウェアとソフトウェア最適化により、コア分析ワークロードが平均2.1倍高速化し、DML（DELETE/UPDATE/MERGE）やテーブルスキャンも大幅に短縮され、既存ワークロードをそのまま実行するだけで恩恵を受けられ、料金体系やAPIも従来と変わらないため運用フローの修正は不要です。

Data Science Agent

今まではデータサイエンティストが

• Snowflake からデータをエクスポートして外部ノートブック／GPU 環境を構築
• feature 作成、前処理、ハイパーパラメータ探索をスクリプトで記述
• Airflow などで学習→推論ジョブをスケジューリング
• Model Registry 登録やデプロイ用 REST API を手動整備
• 精度劣化やデータドリフトを別ツールで監視

と複数ツールを跨いだ手運用が前提でした。

今回発表されたData Science Agentは、これまでのように利用者や管理者が モデル開発ワークフロー全体をコードで繋ぐ必要がなくなるという点が大きな進化です。

1. 自然言語orSQLで「顧客離反を予測するモデルを作成して」と指示するだけでAgentが、

• 訓練用データ抽出→特徴量生成→前処理パイプラインを自動生成
• 複数アルゴリズムとハイパーパラメータを並列サーチ
• ベストモデルをSnowflake Model Registryへ登録し、Snowpark Containerに即デプロイ

2. 推論エンドポイント、再学習スケジュール、ドリフト監視までワンクリックで継続運用可能
3. すべてHorizonのRBAC・リネージ・監査ログ下に統合されるため、ガバナンス一貫性を維持できる

Snowflakeはこの機能を 「データサイエンティストの生産性を劇的に高める Agentic Companion」と位置づけており、Private Previewで提供開始予定とのことです。

Cortex AISQL

今まではメール文やコールセンター音声を

1. テキスト化
2. Embeddings生成
3. 外部LLM API呼び出し
4. 結果をRDBに戻す

といった非構造データごとに別基盤を渡り歩く複雑なパイプラインが必須でしたが、今回発表されたCortex AISQLはこれまでのように利用者や管理者が別サービスへのETL・推論呼び出しを設計・運用する必要がなくなるという点が大きな進化です。

FILEデータ型に格納したテキスト・画像・音声を対象に、AI_FILTER(特徴抽出＋条件絞り込み)、AI_CLASSIFY、AI_TRANSCRIBE、AI_EMBED、AI_SIMILAR、集計関数AI_AGG/AI_SUMMARIZE_AGGなどをNative-SQLで直接呼び出せるため、「Snowflakeロゴを含むスクリーンショットを探す」「テクサポ案件の上位Pain Pointを集計する」といったマルチモーダル分析がワンショットで完結します。

生成・分類・要約・ベクトル検索までをSnowflakeエンジンがスケーリングも含め自律処理するため、データチームはビジネス課題の解決ロジックだけを自然言語／SQLで宣言するだけで済み、AI活用のスピードとガバナンス一貫性を同時に実現します。

デモもあったのですが、ジョインの条件が自然言語でできるなど、通常のSQLを触ってきた人からすると違和感しかない操作をしていましたが、意味的な結合を行うことで、構造データと非構造データを結合できる点や、テクサポの質問で過去すでに解決済みの回答と質問を結合することが自然言語+SQLでできる点が非常に強力性を感じました。

Semantic Views / Semantic SQL

今まではBIチームとデータサイエンティストがそれぞれLookerのExplore定義やTableau計算フィールド、Pythonコード内でKPIを別々に実装し、列名・粒度・フィルター条件のズレをExcelで照合して“定義書”を手作業で維持するしかありませんでしたが、今回発表されたSemantic Views / Semantic SQLはこれまでのように利用者や管理者が指標や階層の整合性を都度擦り合わせる必要がなくなるという点が大きな進化です。

Snowflake上に「sales_amount」「active_users」などのメジャー、ディメンション、階層、説明文を宣言的に定義すると、SQL・BI・LLM(例:Cortex AI SQLやChat系UI)の全レイヤーが同一セマンティクスを参照。さらにMarketplace共有やデータシェア先への自動伝搬、バージョン管理、アクセス制御もHorizonと統合されるため、KPIの「誰が本物か」論争は終了し、開発者はビジネスロジックの追加に専念できます。

これは事前の正確なディメンショナルモデリングを行ったデータ基盤上で機能するものなので、引き続きデータエンジニアリングを正しく行う必要がありますが、その上でどのディメンションとメジャーを組み合わせるのかや、このディメンションとメジャーを組み合わせてデータを結合させる、のようなことがただのSQLを利用するだけでは得られなかったインタラクティブ性を獲得できるかと思います。

Cortex Agents

今までは社内データを使ったチャットボットやRAGアプリを作るたびに、

• 外部LLM API接続、Embedding生成、ベクトル検索設定
• ツール呼び出しやアクション実行を Python でオーケストレーション
• Teams／Slack 統合やアクセス制御、リソーススケールを個別実装

、と複数サービスとカスタムコードを寄せ集める手作業が前提でしたが、今回発表されたCortex Agentsはこれまでのように利用者や管理者が対話フロー、RAG、ツール統合、デプロイ／運用を個別に構築する必要がなくなるという点が大きな進化です。

Snowflake UI で「データソース」「コンテキスト」「許可アクション」を宣言するだけで、プラットフォームが最適モデル選択、メモリ管理、スケーリング、監査ログまで自動ハンドリングし、生成したエージェントはワンクリックで Teams・Web ウィジェット・Marketplace へ公開可能。Horizon RBAC とタグ付けがそのまま適用されるため、開発者は業務ユースケースの定義に集中、ガバナンスチームは追加設定なしで統制を維持できます。

以前発表された際はCortex SearchとCortex Analystをプロンプトによって動的に機能選択を行ってくれる代物程度の認識でしたが、今回でさらにエコシステムの観点でも進化が感じられました。

Snowflake Intelligence

今までは経営層や現場ユーザーが「最新の売上と在庫を教えて」「この異常コストの原因を深掘りしたい」と思っても、

• アナリストがダッシュボードを更新
• 追加SQLを書いてCSV抽出
• 生成AI用にRAGパイプラインを構築

、と部門横断の“データ問い合せ”が都度プロジェクト化し、インサイト獲得まで数日〜数週間を要していました。

しかし今回発表されたSnowflake Intelligenceは、これまでのように利用者や管理者が BI 更新や生成AIワークフローを都度設計・運用する必要がなくなるという点が大きな進化です。

新しく用意されたUI上で自然言語で質問を投げるだけでHorizonカタログ、Marketplaceデータ、社内指標 (Semantic Views) を横断検索し、根拠付きの回答・推奨アクション・関連ダッシュボードへのリンク を即生成でき、さらにTeams／Slack連携、メール送信、ワークフロー実行など“次の一手”をボタン一つで自動実行 でき、処理の全ログはHorizon RBACと監査ログに統合されます。

結果、ビジネスユーザーは「聞く → 理解 → 行動」を数分で完結でき、データチームは基盤運用ではなく高度な分析と価値創出に集中できます。

1. “AI Agentic Data Cloud” という前提条件

Keynote全体を貫いていたメッセージは、あらゆるデータ操作をAIエージェントが肩代わりする世界観でした。ガバナンス（Horizon Copilot）やデータ統合（OpenFlow）、果ては問い合わせそのもの（Snowflake Intelligence）へと波及している思想は、Snowflakeが“AI Agentic”を単なる機能拡張ではなく、プラットフォーム全層の設計原理に据えようとしているように感じました。

2. 基盤整備は徹底的に Snowflake 側で

利用者が触れる前段の“面倒ごと”を全て撲滅する、という割り切りも印象的です。
Keywordとして”Get-out-of-box”のように、箱だしして即使いができるという意味合いで、設定の簡素化や学習コストの低減が前提が見えたようにも思えます。

Warehouseサイズも、外部BI/DBのメタデータ収集も、dbtのランタイムすら「Snowflakeが持つ／肩代わりする」方向へ振り切っており、私自身、データ活用文化を社内に根付かせる難しさを痛感してきましたが、**「基盤整備と運用はプロダクトに閉じ込め、ユーザー体験を自然言語に寄せる」**というアプローチは、組織文化ごとの差異を吸収できる現実解に感じます。

3. “使い方講座”より“自然言語”を優先している

SQLやTableauの研修を積み上げても、習熟スピードや部門間格差の壁はどうしても残ってしまう、それが現場の実感です。Snowflakeが示したCortex AISQL、Semantic Views、Cortex AgentsのAgenticなサービス群は、定義済みメトリクスを共通語彙にして、自然言語で質問→エージェントがデータ／ツールを裏で操作という流れを徹底させるで、文化醸成をゼロから頑張るより「自然言語をしゃべれれば誰でもデータを扱える」ほうが採用・現場定着のハードルが低いのでは?と感じました。

4. 実装とトランスファーの“筋肉”は依然として必要

とはいえ、AIに全部お任せ、で終わらないのが現実で、OpenFlow・External Asset Catalog・Semantic SQL のような“事実を正しく写し取るレイヤ”を先に整備し、KPI定義やタグ付けを組織横断で握るこの地味な作業をパッケージ化・自動化するのがSnowflakeの裏側の大きな狙いのようにも見えました。

5. “AIファースト”に賭けるリスクとリターン

最後に、AIエコシステム前提に舵を切ることのリスクも認識すべきだな〜と勝手に邪推していることも共有できればと思います。
モデル精度・コスト・倫理課題など流動的な要素が多く、Snowflakeですら“プレビュー”機能が多い段階(SummitのAnnouncingタイミングだからそれはそうな気もする)で、それでも私は「将来どの形の利用方法が勝つかわからないなら、まず自然言語で触れるハブを作っておく」という賭けに妙味を感じました。Snowflakeが提示した世界線は、そのハブとして機能しうる完成度と拡張性を見せており、データ活用の主戦場が“クエリを書く人”から“問いを投げる人”へシフトする兆しを強く示唆しているなぁと感じています。

いかがでしたでしょうか？盛りだくさんの機能紹介が見えたKeynoteの内容をお届けしました。この後も参加したSessionの内容等をアップしますので、是非そちらもご覧いただけますと幸いです！