Snowflake Summit 2026：実際にリリースされたもの、その意味

今回のSummitは、他のほぼすべての発表に関わる2つの名称変更で幕を開けました。Cortex CodeはCocoに、Snowflake IntelligenceはCoworkに改称されました。Cocoは開発者やビルダー向け、Coworkはコードではなく答えを求めるビジネスユーザー向けです。

本記事で取り上げる他の機能のほとんどは、Coco上で動作するか、Coworkにつながるものです。これがイベント全体を貫くテーマでした。

OpenFlowがヘッドレスに。OpenFlowはデータを抽出してSnowflakeにロードするツールで、Fivetranのようなツールや、Dagsterのようなオーケストレーターと直接競合します。Jeffは、OpenFlowのUIがこれまで使いにくかったと指摘しています。Snowflakeが提供した解決策は、Cocoから完全に操作できるヘッドレスでプログラマブルなオブジェクトモデルです。わかりにくいインターフェースをクリックして回る代わりに、やりたいことを記述すればエージェントが構築してくれます。

Snowflake DataStreamは、Snowflake上のKafkaです。Kafkaとワイヤー互換のため、理論上は既存のKafkaプロデューサーの接続先を新しいSnowflakeのURLに向けるだけで、中間バケットを介さずにデータがそのままテーブルに格納されます。Ianはこれをイベント最大級の発表の一つと評しました。リアルタイム取り込みにおける外部ベンダー依存のカテゴリーを丸ごと不要にするもので、SnowflakeネイティブテーブルとIcebergテーブルの両方で機能します。

Postgresデータミラーリングは、アプリケーション開発者にとって今回最大の発表かもしれません。スイッチを切り替えるだけで、Postgresのデータが変更データキャプチャ（CDC）を通じて自動的にSnowflakeに反映され、ETLパイプラインは不要です。従来のBIは本質的に鮮度が落ちます。バッチロードは1時間に1回、あるいは1日に1回しか実行されないため、前回のロード以降にソースシステムで起きたことはまだ反映されないのです。Postgresが運用データベースであるユースケースでは、このギャップが解消されます。Ianは、これをUnistoreが本来目指していたハイブリッドなトランザクション・分析パターンに対するSnowflakeの回答と見ています。しかも、そのアーキテクチャを自前で構築する複雑さは不要です。

Snowflake PostgresがGAに到達しました。あわせて、ビジネスクリティカルアカウント向けのプライベートリンク対応、顧客管理キー、そしてPGLakeと呼ばれる仕組みも発表されました。PGLakeは、JSONベースのカタログの代わりにPostgres自体をIcebergカタログとして使う方法です。Jeffはこれを、先に同様のカタログ代替の一手を打ったDuckLakeへの直接的な回答と見ています。

AIによるマイグレーションは88%の時間短縮をうたっています。この数字については、IanもJeffも保証できないとしています。Ianの見立てはこうです。「これはマーケティングの極みで、見栄えを良くするためにどこからともなく持ってきた数字です」。AI支援によるマイグレーションが速くなるという方向性のシグナルとして受け止めるべきで、予算計画の根拠にすべき数字ではありません。

このカテゴリーの発表は、単独で成立するというより、互いに積み重なる関係にあります。

• アダプティブコンピュートがGAになります。これは、ウェアハウスのサイジングをあまり意識せずに済むBigQueryのモデルに近づく、Snowflakeの一歩です。Summit前にSELECTが開催したこのテーマのウェビナーを踏まえたJeffの見解は、サイジングを考える余地はまだ残るものの、Snowflakeが向かう方向性は明確で、数年以内にデフォルトのコンピュートオプションになる可能性が高いというものです。Ianは重要な注意点を一つ挙げています。複数の顧客がアダプティブコンピュートをコスト削減機能だと思い込んでいましたが、そうではありません。手動チューニングなしでパフォーマンスを向上させるために設計された機能であり、請求額を下げるためのものではありません。
• インタラクティブワークロードは、低レイテンシー分析でClickHouseに対抗するために存在するインタラクティブテーブルとインタラクティブウェアハウスの上に構築されています。今回のリリースでは、クラスターサイジング、キー選択、プリキャッシングの改善が追加されました。
• インタラクティブコンパイラは、コンパイル時間の40倍高速化をうたっています。Jeffはこれを掘り下げましたが、インタラクティブワークロードのみに適用されるのか、標準のSnowflakeウェアハウスで実行されるすべてのクエリに適用されるのか、まだ完全には確信が持てていません。公開情報に一貫性がないため、推測するのではなく、不確実である点を明記しておきます。
• Unistoreエンジンの最適化もあわせてリリースされましたが、公開されている詳細は今のところ多くありません。

Ianのまとめはこうです。インタラクティブワークロードとUnistoreは、Snowflake上で高速なアプリケーション型の体験を構築するチームをまさに狙ったものです。アダプティブコンピュートは、より従来型のETLやBIのワークロードを対象としており、コストではなくパフォーマンスのための機能です。

AI Completeが、テキストと画像だけでなく音声と動画にも対応しました。

Cortex AI Function Studio（パブリックプレビュー）では、独自のカスタムCortex関数を構築できます。画像を含む行を指定し、特定の属性が写っているものをフラグ付けするよう指示すると、他の関数と同じように呼び出せる関数が返されます。プラットフォームチームは、広く展開する前に関数を検証できます。

xAIがモデルラインナップに加わり、Anthropic、OpenAI、Google、Meta、Mistral、DeepSeekと並びました。重要なのはGrok自体というより、それが示すシグナルです。Snowflakeは、プロバイダーごとに個別のAPIキーを管理するのではなく、既存のSnowflakeの認証情報でガバナンスを効かせながら、好きなLLMを利用できる安全な集約レイヤーとしての立ち位置を打ち出しています。

エージェンティック検索は、既存のCortex Searchと混同されがちです。違いはこうです。Cortex Searchは非構造化ドキュメントからテキストの抜粋や説明的な回答を返します。エージェンティック検索は、単一の決定的な答えを返すように設計されており、「2025年の日付が付いた契約は何件あるか」といった質問に対して、契約書の抜粋の山ではなく数字が返ってきます。

コードバンドルにより、Pythonを通常の.pyファイルのまま実行できます。これまでSnowflakeでPythonを実行するには、SQLストアドプロシージャでラップするか、ノートブックで作業する必要があり、どちらも通常のデバッグワークフローに対応していませんでした。今では、Pythonファイルをステージにアップロードして直接スケジュールできます。Ianは、ここまでにかかった時間の長さについて「定義するために別の言語でラップしなければいけない？それは望んでいたものではありません」と語りました。ストアドプロシージャの要件は開発者体験の中でも本当に扱いにくい部分であり、その撤廃は、ただPythonを書きたいだけのチームを取り込むうえで重要な意味を持ちます。

ML関連では、Cortex Training（プライベートプレビュー）により、QwenやMistralといったオープンモデルを自社データでファインチューニングできます。特定のデータセットで学習させることで、はるかに小さいモデルがはるかに大きいモデルを上回る性能を発揮したと報告されています。Snowflake Pipeline Builderは、Alteryxのようなツールに近い発想のドラッグ＆ドロップ式MLパイプライン構築インターフェースを追加し、Cocoによるひな形作成の支援も利用できます。ML向けのVS CodeおよびCursor拡張機能と、オンラインA/Bテストもパブリックプレビューに移行しました。

Streamlit on SnowflakeがGAに到達し、専用のStreamlitウェアハウスではなくコンテナランタイム上で動作するようになりました。コンテナプールの課金は1時間あたりフルウェアハウスクレジットのごく一部で済むため、Streamlitアプリの実行コストは大きく下がるはずです。

App Runtimeは、発見しやすさという現実の課題を解決します。Jeffは同じアプリをSnowpark Container ServicesとApp Runtimeの両方にデプロイして直接検証しました。機能面の違いは、App RuntimeのアプリがSnowsight内のAppsタブに表示されるため、社内の誰もが実際に見つけられる点です。Container Servicesで直接構築したアプリは、URLをあらかじめブックマークしている人がいなければ、誰にも見つけてもらえません。

Snap and Askでは、Coworkが生成したチャートを選択して、それについて直接追加の質問ができます。Snowflakeはライブデモを行わなかったため、今後のリリースを注視する以上に語れることはまだ多くありません。

Iceberg v3がGAに到達し、Snowflakeは、アトミックな挿入・更新・削除・マージの完全サポートを含め、Icebergベンダーの中で最も広範なv3サポートを提供していると主張しています。Iceberg RESTカタログにより、エンジンをまたぐワークフローも可能になります。DuckDBでデータを変換すると、共有カタログを通じてその変更がSnowflakeに反映されます。

Snowflakeマネージド型のIcebergストレージはAWSでGAとなり、AzureとGCPも近日対応予定です。基調講演のスライドには登場しなかったものの、知っておくべき構造的な変化が一つあります。独自のPolarisカタログを構築・管理する方式は完全に廃止されます。今後はすべてがデフォルトでHorizonカタログを経由し、その下でPolarisが動作しますが、ユーザーにその概念が見えることはありません。Iceberg型のテーブルを作成すれば、自動的にHorizonに表示されます。

SELECTの顧客ベースを踏まえた、Iceberg採用全般に関するIanの見解はこうです。採用は依然として2つのグループに集中しています。非常に大規模なデータセットと強力なエンジニアリングチームを持つデジタルネイティブ企業（CoinbaseやShopifyのような企業）と、その複雑さを管理できるエンジニアリング人員を抱える大企業です。Snowflakeがこの領域への投資を続けているのは、その参入障壁を下げるためです。

ウェビナー中にはPaul Horanから、行フィルタリングや列マスキングといったきめ細かなRBACがIceberg RESTカタログ自体にも及ぶのか、つまりAthenaなどを使うコンシューマーもSnowflakeユーザーと同じようにガバナンスされるのか、という質問が寄せられました。IanもJeffも確信を持って答えられませんでした。Jeffの経験則は、ガバナンスはSnowflakeレイヤー内に留め、REST APIは純粋にデータ移動のためだけに使うというもので、これは質問に答えるというより問題を回避するアプローチです。ガバナンスレイヤーをすべてのエンジンに重複して構築することなく、真のマルチエンジンアーキテクチャを作ろうとする人にとって、これは実際に未解決の課題のようです。

その他のデータ共有関連のアップデート：

• データの再共有に、コンシューマーがデータをさらに下流に再共有できるかどうかをプロバイダーが決められるフラグが追加されました。
• オープン共有により、相手側にSnowflakeアカウントもリーダーアカウントも不要で、REST APIを通じてSnowflake以外の顧客にデータを公開できます。
• クリーンルームもアップデートされましたが、これはIanもJeffも詳細に語れる自信がないと述べた領域です。
• ゼロコピーのエコシステムが拡大し、既存のSalesforce連携に加えて、SAP、Workday、IBM watsonx.data（この表記が正式で、誤記ではありません）が加わりました。

この最後の点については、IanもJeffも、その打ち出し方に少し異を唱えています。ゼロコピーアクセスのためにSalesforce Data CloudやSAP Business Cloudのようなものを構築すると、従来の方法でそのデータをSnowflakeにETLするよりもコストがかさむことが少なくありません。Jeffの見解は、これは実際にはコスト削減のための施策ではなくシンプルさのための施策であり、デフォルトでコストが下がると思い込むのではなく、その観点で評価すべきだというものです。

CoworkにはRedshift、Postgres、その他の外部サービスへのコネクタも追加され、MCPサーバーに近い形で機能します。Snowflakeはこれをライブでデモしました。エージェントが同じ会話の中でSnowflakeからデータを、Redshiftからエンリッチメント用データを取得し、一つの質問に答えてみせました。

Coco（旧Cortex Code）は、Snowsight全体、Horizonカタログ内、Workspaces内に、青いスパークルアイコンとして表示されるようになりました。特に知っておきたいのは次の点です。

• Coco for Desktopは、エージェントモード（チャット形式のインターフェース）と、標準的なVS Codeそのままの見た目のエディターモードを備えた、VS Codeの完全なフォークです。Jeffはテストを続けており、本当によくできていると評価していますが、メインの環境は依然としてVS CodeとClaude Codeプラグインの組み合わせです。Snowflake固有のタスクをCocoのほうが明らかにうまく処理できるケースで使っており、Cocoエコシステムへの移行度は15%程度と見積もっています。
• コアとなるSnowflakeのVS Code拡張機能に、画面上部の隅にあるスパークルアイコンからCortex Codeへ直接アクセスできる機能が追加されました。
• 公開スキルカタログがCocoのインターフェースの外にも存在し、CocoにはClaude用のプラグインもあります。
• クラウドエージェントがSnowsight内の分離されたサンドボックス環境で実行できるようになり、エージェント主導の変更が、触れるべきでないリソースを破壊するリスクがなくなりました。

Coworkでは、質問する前に適切なエージェントを選ぶ必要がなくなりました。オーケストレーターが、どの基盤エージェントがリクエストを処理すべきかを判断するようになり、非技術系ユーザーに多くを求めていたステップが不要になりました。

ユーザーごとのメモリーも新機能です。Claudeが会話全体でコンテキストを保持するのと同様に、Coworkは特定のユーザーが取り組んでいる内容に紐づいた個人的なスキルとメモリーを蓄積できるようになりました。

コネクタのエコシステムは、スライドの印象以上に広がっています。Slack、Teams、カレンダーの連携がすべてCoworkに流れ込むようになりました。Snowflakeがデモした例はこうです。Coworkに「今日の予定はどうなっている？」と尋ねると、カレンダーを確認して営業ミーティングに気づき、関連するSalesforceのアカウントメモを取得し、関連する言及がないかSlackの履歴を確認し、最も関連性の高いSnowflakeのデータを取得したうえで、そのミーティングに向けた実用的な準備サマリーを返してくれます。

スケジュールタスクと自動化では、定期的なチェックを設定できます。たとえば、待ち望んでいる機能について特定の製品リリースページを毎週確認するようCoworkに依頼する、といった使い方です。Jeff自身もこれを使って、複数のピン留めアーティファクト（Coworkの応答から保存したチャート）を1つのダッシュボードにまとめられる機能をSnowflakeがいつリリースするかを追跡しています。

Cortex Senseは、クエリ履歴、ダッシュボード、メタデータからコンテキストを構築して精度を高めます。これと直接どのようにやり取りするのかについては、IanもJeffもまだ明確には把握していません。

インテント駆動のガバナンスは、このセクションで最も興味深い発表かもしれません。ポリシーを手動で書く代わりに、たとえば「社会保障番号が一切公開されないようにする」といった意図を平易な言葉で記述すると、Snowflakeがアカウントをスキャンして違反を検出し、修正を支援してくれます。

ユーザー単位のAIクォータにより、アカウント全体の単一予算に頼るのではなく、1人あたり1日の支出に上限を設定できます。Jeffがクライアントに対して実践しているのは、一部のアカウントでClaude Sonnet 4.6を実質的に唯一の有効なモデルとして設定する方法です。OpusやFableといった新しいモデルが登場した今、Sonnet 4.6は効率的で価格も手頃だからです。こうすることで、誰かが誤ってはるかに高価なモデルにクエリを投げ、想定外の請求が発生する事態を防げます。

SnowflakeでのAI支出の管理に実際に取り組んでいるなら、The Unofficial AI Cost Optimization Manual for Snowflakeで、クォータ、モデル選択、そしてコストが実際にどこから発生するのかをさらに詳しく解説しています。

次世代アカウントレプリケーションは、ログベースの変更データキャプチャをリージョン間フェイルオーバーに活用し、バックアップは20倍高速化され、SLAも改善されました。Snowflakeは基調講演のステージ上で実際のデータを紹介しました。昨年の大規模なクラウド障害の際、300の顧客が手動の介入なしに自動でバックアップリージョンにフェイルオーバーしたとのことです。

Observe by SnowflakeはDatadog型のモニタリング製品ですが、まだ初期段階です。これはSnowflakeによるObserveの買収に由来するもので、IanもJeffも動作するデモやスクリーンショットをまだ見ていません。以前のSelect Star買収の一部が完全に定着するまでにかかった時間を踏まえると、Observeがそれより早くリリースされるとは期待しないほうがよいでしょう。

Natomaは、OktaであれMicrosoftであれ、既存のSSOプロバイダーを通じて、Coworkをビジネスエコシステムの他の部分（Slack、Salesforceなどのツール）に安全に接続する仕組みのようです。Snowflakeが共有したデータポイントの一つによれば、組織あたり平均225件以上の非承認の「シャドーAI」利用が検出されています。つまり、従業員がChatGPTや未承認のコーディングアシスタントのようなツールを、正式な承認なしに使っているということです。Jeffの見立てでは、NatomaはSnowflakeがCoworkをより広いビジネススタックに安全に接続するための仕組みになる可能性が高いものの、公開資料ではまだ明示されていません。

Summitの直後、ダイナミックテーブルに「フリーズ期間（frozen period）」機能が追加されました。特定のタイムスタンプより前のデータのリフレッシュを一切試みないようダイナミックテーブルに指示できるもので、「今日マイナス30日」のような相対的な式にも対応しています。上流の変更にかかわらず、特定の履歴レコードに手を付けずに保ちたい場合に便利です。

この総まとめのほぼすべてに、2つのパターンが見てとれます。第一に、Snowflakeは、外部ベンダーに頼らずにデータの出し入れをより安く簡単にするための投資を続けています。OpenFlow、DataStream、Postgresミラーリング、ゼロコピー連携は、すべて同じ方向を指しています。第二に、ほぼすべてがCocoまたはCoworkを経由するようになっており、プラットフォーム全体が向かう先は明らかです。

Snowflake以外のコスト管理に取り組んでいる場合、SELECTはSnowflakeに加えてDatabricksにも対応しており、BigQuery対応も今四半期中に提供予定です。

SnowflakeでのAIコスト管理が視野に入っているなら、特にユーザー単位のクォータとモデル選択が重要になった今こそ、The Unofficial AI Cost Optimization Manual for Snowflakeをダウンロードしてください。Jeffがまとめたもので、本記事で扱えた内容をはるかに超える深さがあります。