今年も現地参加して良かった！Snowflake Summit 2026！
LayerX のデータチームが Snowflake Summit 2026 に現地参加し、基盤移行の成果と「The Agentic Enterprise」の実装に向けた新たな視点を共有した。
キーポイント
Snowflake Summit 2026 の概要と規模
2026 年 6 月にサンフランシスコで開催され、2 万人以上の参加者を集めた同社最大のカンファレンスで、500 超のセッションが行われた。
LayerX の Snowflake 活用進化
BigQuery から Snowflake への移行を完了し、単なる DWH からプロダクト機能や業務基盤として深く統合するまでに成長した。
Data Superheroes 選出と参加意識の変化
チームの貢献が評価され「Snowflake Data Superheroes」に選出され、技術習得から「次に何を解くか」という課題解決志向へ視点がシフトした。
The Agentic Enterprise の実装への期待
今回の参加の主要目的として、AI エージェントが自律的に業務を遂行する「Agentic Enterprise」の実現に向けた技術動向への注目が示された。
AI Agent の差別化要因はデータとメタデータ
モデル自体の性能ではなく、自社固有のデータや指標定義、権限ルールといったメタデータを「ハーネス」として活用することが、業務で使える AI Agent を実現する鍵となる。
本番運用に向けた Snowflake の役割
今年の発表は新機能の羅列ではなく、Snowflake 上で自社データに基づき安全に AI Agent を本番運用するための部品が揃ったことを示している。
AI ワークロードをデータ基盤の延長として統合する
AI エージェントは外部に追加するのではなく、データ、メタデータ、権限、ガバナンスと同じ環境内で動かすことで、鮮度やコンプライアンスの障壁を減らし、問題発生時の切り分けと改善サイクルを加速できる。
重要な引用
Snowflake Summit 2026 は 2026 年 6 月にサンフランシスコのモスコーニ・センターで開催された、Snowflake 社が年次で主催する最大のユーザーカンファレンスです。
いまでは単なる DWH としてではなく、プロダクト機能や日々の業務を支える基盤として Snowflake を活用しています。
今年は「Snowflake を使って、次に何を解くべきか」を考えるために参加しています。
モデルそのものは競争優位ではない。同じモデルは競合も使える。差がつくのは自社固有のデータと、その組み合わせ方だ
テーブルやカラムの意味、指標定義、データの鮮度、リネージ、権限、利用履歴、業務ルール。これらは単なる管理情報ではなく、AI Agent の振る舞いを決めるハーネスになります
AI Agent を現実の業務成果につなげるには、データを中心に据える必要がある
影響分析・編集コメントを表示
影響分析
この記事は、Snowflake の利用が単なるデータ蓄積から AI エージェントを駆使した自律的な業務変革（Agentic Enterprise）へと進化していることを示す重要な証言です。大規模なユーザーコミュニティにおける実装事例の共有により、他社組織の DX 戦略や技術選定に対する参考価値が高いと言えます。
編集コメント
Snowflake の利用が DWH から AI エージェント基盤へと進化している実例として、業界のトレンドを先取りした組織の姿勢がうかがえる。
こんにちは。バクラク事業部 BizOps データグループの @civitaspo です。2026 年 6 月にサンフランシスコで開催された Snowflake Summit 2026 に現地参加してきました。本記事では、その様子や感想をレポートしようと思います。
image 不本意な形で X のトレンド に載ることになり… 私のコスプレが話題になったようです笑
Snowflake Summit 2026（以下、Summit）は、2026 年 6 月にサンフランシスコのモスコーニ・センターで開催された、Snowflake 社 が年次で主催する最大のユーザーカンファレンスです。Snowflake の最新技術と AI の未来を語る基調講演に始まり、500 を超えるセッションやハンズオン（実習）が行われました。今年の参加者は 20,000 人を超え、日本からは 400 人を超える人々が参加しました。
今年は LayerX から @civitaspo が現地参加してきました。Summit への参加は今年で 3 年連続です。2024 年に初めて参加した当時、私たちはまだ Snowflake を本格導入する前の段階でした。「Snowflake で何ができるのか」を学びに行くことが主な目的だったことを覚えています。それから 2 年が経ち、バクラクのデータ基盤は BigQuery から Snowflake への移行を進め、いまでは単なる DWH（データウェアハウス）としてではなく、プロダクト機能や日々の業務を支える基盤として Snowflake を活用しています。
ありがたいことに、その取り組みやコミュニティへの貢献を評価いただき、今年は Snowflake Data Superheroes にも選出いただきました。
この変化によって、私自身の Summit との向き合い方も大きく変わりました。今年は「Snowflake を使って、次に何を解くべきか」を考えるために参加しています。
昨年、一昨年の Summit 参加レポートも合わせて読んでいただけると、この 1 年の変化が伝わるかと思います。
tech.layerx.co.jp tech.layerx.co.jp
The Agentic Enterprise の実装へ
今年のキーノートのテーマは「The Agentic Enterprise」でした。CEO の Sridhar Ramaswamy は、AI が「約束」や「実験」の段階を超え、現実の業務成果を生み出す段階に入ったことを繰り返し語っていました。
印象的だったのは、話の中心が「AI Agent 周辺のエコシステム」だったことです。同じフロンティアモデルを誰もが使えるようになっていく中で、企業ごとの差分は、自社固有のデータ、その意味づけ、そして業務の中で安全に使い続ける仕組みに移っていく。Snowflake はその変化を、The Agentic Enterprise という言葉で表現していたように感じました。
その観点で見ると、今年の発表は単なる新機能の羅列ではなく、「企業が自社データの上で AI Agent を本番運用するための部品」が揃ってきたことを示すものだったと思います。本記事では個別機能を網羅的に紹介するのではなく、この Keynote を起点に、Snowflake の上で AI ワークロードを本番運用していくために、私たちが何を準備し、何を実践していくべきかを考えてみます。
データで AI Agent をコントロールする
Sridhar が Keynote で繰り返していたのは、「モデルそのものは競争優位ではない。同じモデルは競合も使える。差がつくのは自社固有のデータと、その組み合わせ方だ」という話でした。同じフロンティアモデルを多くの企業が使えるようになるなら、モデルを呼び出せること自体は差別化になりません。差がつくのは、そのモデルに何を読ませ、何を根拠に判断させ、どの範囲で行動させるかです。
AI Agent は、賢いモデルを使えば勝手に業務を理解してくれるものではありません。どのデータを参照してよいのか。どの指標定義に従うべきなのか。どのデータが最新なのか。どの操作は許可され、どの操作は禁止されるのか。こうした前提を与えなければ、業務で使える AI Agent にはなりません。
その前提を作るのが、データとメタデータです。テーブルやカラムの意味、指標定義、データの鮮度、リネージ（系譜）、権限、利用履歴、業務ルール。これらは単なる管理情報ではなく、AI Agent の振る舞いを決めるハーネスになります。
このハーネスが弱いと、AI Agent はそれらしい答えを返せても、業務上は使いにくいものになります。正しい指標を選べない。古いデータを参照する。見るべきではないデータに触れる。根拠のない判断をする。こうした問題は、モデルを強くするだけでは解けません。
だからこそ、Snowflake 上に蓄積してきたデータとメタデータを、AI Agent のハーネスとしてどう使うかが重要になります。自社データは、AI Agent に情報を与えるためだけのものではありません。AI Agent の行動範囲を定め、業務の文脈に沿って動かすための土台でもあります。そのため、自社で保有するデータを AI Agent をコントロールするためのデータとして再定義する必要があります。
AI ワークロードをデータ基盤の延長で動かす
次に重要になるのは、それらを AI ワークロードから切り離さないことです。Keynote でも、AI Agent を現実の業務成果につなげるには、データを中心に据える必要があると語られていました。データが分断され、ガバナンスが効いていない状態は、AI 活用の大きな障壁になります。だからこそ、AI ワークロードはデータ基盤の外側に足すものではなく、データ、メタデータ、権限、ガバナンスと同じ環境の中で動かす必要があります。
ここで重要になるのが、Snowflake の One Product としての価値です。2024 年の Summit レポートでも、Data（データ）、Compute（計算）、AI（人工知能）、Security & Governance（セキュリティとガバナンス）、Collaboration（コラボレーション）が一つのプロダクトとして統合されていること、そして大量のデータが存在する場所でワークロードを動かせることの価値について書きました。
データを別の環境へ移すと、通信コスト、通信環境のセキュリティ担保、データ鮮度の担保、コンプライアンス確認などが必要になります。一方で、Snowflake 上で完結できるなら、その障壁を減らし、AI やデータプロダクトの開発に集中できます。
AI ワークロードでは、この構図がさらに重要になります。Snowflake にデータとメタデータがあり、その同じ環境で AI ワークロードも動かせる。データの鮮度、権限、監査、意味定義、計算、検索が一つの体験としてつながる。これによって、AI Agent の回答を業務判断に使い、期待と違う結果が出たときには、データ、定義、権限、実行ロジックのどこに問題があるのかを切り分け、次の改善につなげられます。
One Product の価値は、データを移動しないことだけではありません。データ、メタデータ、計算、権限、ガバナンス、AI 実行が一つの環境でつながり、AI Agent を使った業務改善のサイクルを速く回せることにあります。The Agentic Enterprise（エージェント型企業）を実装していくなら、AI Agent をデータ基盤の外側に足すのではなく、データ基盤の延長として動かせる状態を作る必要があります。
Snowflake 上での AI Agent 実装を、組織で取れる手段にする
今年の Summit で見えてきたのは、この One Product の価値を AI ワークロードへ広げるための実装の型です。Semantic View（セマンティックビュー）で構造化データの意味を定義し、Cortex Search（コルテックス・サーチ）で非構造化データを検索可能にし、Cortex Agent（コルテックス・エージェント）がそれらを束ねる。去年は個別の新機能として見えていたものが、今年は「Snowflake 上で AI Agent を作るならこう組む」という型として見えてきました。
これは、Snowflake 上で AI を動かすことが、単に LLM（大規模言語モデル）を呼び出す話ではなくなってきたということです。Snowflake 上にあるデータとメタデータを活かし、検索や意味定義と組み合わせながら、業務文脈を持った AI Agent（AI エージェント）を組み立てる話になってきています。
ただし、AI Agent 開発の基盤は Snowflake だけではありません。AWS など、アプリケーションが動いている環境にも AI ワークロードを実装する選択肢があります。既存サービスとの接続、低レイテンシなオンライン処理、プロダクト機能への組み込み、デプロイや監視の運用を考えると、アプリケーション側で動かす方が自然なワークロードもあります。
一方で、Snowflake 上のデータを活かし、分析、検索、要約、判断支援を行うワークロードは、Snowflake 上で完結させる価値が大きい領域です。データ移動を減らし、鮮度、権限、監査、意味定義を既存のデータ基盤の延長で扱えるからです。
重要なのは、どちらか一方に寄せることではありません。Snowflake 上で AI Agent を作ると何が得意で、どこに制約があり、どのユースケースに向いているのかを理解しておくことです。それが分かっていなければ、実際の課題に向き合ったときに、Snowflake を選ぶべきか、アプリケーション側で実装すべきかを判断できません。
そのためには、小さくても実際に作ってみる必要があります。Semantic View（意味的ビュー）、Cortex Search、Cortex Agent を組み合わせ、データ基盤の利用者が触れられる形で AI Agent を試す。回答の質だけでなく、権限の扱い、データ鮮度、指標定義との接続、アプリケーション側との責務分界も確認する。そうした経験があって初めて、「この問いは Snowflake 上の AI Agent で解けそうだ」「この処理はアプリケーション側に寄せた方がよさそうだ」という判断ができるようになります。
The Agentic Enterprise を自分たちの現場で実装していくなら、最初から大きな AI Agent 基盤を作る必要はありません。まずは Snowflake 上で AI Agent を作り、使い、向き不向きを理解することです。データとメタデータを動かさずに AI ワークロードへつなげる実装を、必要なときに取れる技術的な手段として、組織に持たせていく必要があります。
開発速度を落とさないガバナンスを設計する
Platform Keynote の Trust パートでは、AI Agent を本番運用するためのセキュリティ・ガバナンス機能が多く発表されていました。Agent Identity（エージェントアイデンティティ）、Data Movement Policies（データ移動ポリシー）、Multi-party Approvals（複数者承認）、Trust Center AI Security Checks などです。
これらの発表から見えたのは、AI Agent を既存のガバナンスの中で扱えるようにする方向性です。どの AI Agent が、どの権限で、どのデータにアクセスしたのか。データをどこへ出そうとしたのか。高リスクな操作に承認を挟めるのか。こうした論点を、AI Agent ごとの個別実装に閉じず、プラットフォーム側の仕組みとして扱えるようになってきています。
ここで重要になるのは、管理者がすべてを個別に見なくてもセキュアに運用できる設計です。AI Agent が数個であれば、個別にレビューし、個別に権限を付け、個別に例外対応する運用でも回ります。しかし、組織の中で AI Agent が増えていくと、そのやり方はすぐに限界を迎えます。1000 個の AI Agent に対して 1000 個のポリシーを手で作る運用では、現場は進めなくなります。管理者もレビューに追われ、どこにリスクがあるのかを見通しにくくなります。
必要なのは、AI Agent ごとの細かい審査を増やすことではなく、共通の境界を先に決めることです。たとえば、本番データに対する破壊的な操作は許可しない。特定のデータ分類は外部へ持ち出せない。高リスクな操作には承認を必須にする。AI Agent が使える外部ツールの範囲を制限する。こうした、組織として越えてはいけない線を共通ポリシーとして定義します。
そのうえで、個別の AI Agent に必要な権限は、ユースケースやチームの文脈に応じて委譲できるようにします。現場は、自分たちの持つ権限の範囲で AI Agent を作れる。管理者が定義した外側の境界は越えられない。この二層に分けることで、AI Agent が増えても運用をスケールさせやすくなります。
中央で制御する範囲と、チームに委譲する範囲を早めに決めておくことが重要です。ここを曖昧にしたまま AI Agent を増やすと、後から個別レビューと例外対応が積み上がります。安全性を担保したい場面ほど、管理者が全部を見る運用に寄りがちですが、その形では開発速度が落ちます。現場が迷わず使える共通ポリシーを先に作ることが、AI Agent を組織に広げるための前提になります。
競争優位性は、評価して改善し続ける仕組みで作る
今年の Keynote やセッションでは、AI Agent を作るための部品がかなり揃ってきたことが分かりました。一方で、作った AI Agent をどう評価し、どう運用し、どう改善し続けるかについては、まだ確立された方法論が少ないように見えました。
ここに競争優位性が生まれる余地があります。フロンティアモデルを呼び出すことは、すでに難しくありません。AI Agent を構成するための機能も、今後さらに整っていきます。差がつくのは、AI Agent を作った後です。その AI Agent が本当に業務成果につながっているのか。以前より良くなっているのか。コストに見合っているのか。これを測り、改善し続けられるかどうかが重要になります。
評価すべきものは、回答の正しさだけではありません。ユーザーの意図を解決できたのか。人手の確認や修正を減らせたのか。回答を受けたユーザーが次の行動に進めたのか。失敗したときに、適切に人間へ引き継げたのか。変更を加えたときに、以前できていたことが壊れていないか。こうした観点まで見なければ、AI Agent が業務で使える状態になっているかは判断できません。
コストも同じです。ストレージやコンピュートのコスト管理は成熟してきましたが、AI Agent における「成果あたりのトークン」や「成果あたりの AI コスト」は、まだ比較するための基準がありません。モデル単価が下がっても、利用量が増えれば総額は下がりません。AI Agent が業務に浸透するほど、単純な利用量ではなく、成果とコストを結びつけて見る必要があります。
だからこそ、最初から大きな評価基盤を作るというより、AI Agent ごとに何を成功とみなすのかを定義し、品質とコストを継続的に見直せる状態を作ることが重要です。Snowflake 上で AI Agent を動かすなら、データ、実行履歴、利用状況、コストを近い場所で扱えるため、この評価と改善のサイクルも組みやすくなります。
競争優位性は「AI Agent を作った」ことでは生まれません。評価方法がまだ固まりきっていない今だからこそ、自社の業務に合わせて、何を成功とみなし、どう測り、どう安く正確にしていくかを先に作る価値があります。AI Agent を作る力ではなく、継続して改善し続ける運用能力こそが、これからの差分になるはずです。
まとめ
今年の Keynote では、The Agentic Enterprise を実装する段階に入ったというメッセージと、実装するためのパーツが Snowflake に揃ったというメッセージを受け取りました。
あとは、そのパーツを自分たちのデータ、ガバナンス、評価の仕組みに接続し、実際に使える形にしていく段階です。Snowflake 上で AI Agent をどう動かすのか、どこまでをデータ基盤に寄せ、どこからをアプリケーション側に置くのか。安全に広げるための境界をどう引き、品質とコストをどう見続けるのか。今年は、小さく作り、使い、失敗し、判断基準を増やしていく。その経験を組織の中に積み上げて、結果を出すサイクルがどんどん回る年にします。
やっていき！！
今年のセッションも最高だった！
image今年は、昨年と比較して、どのセッションも予約が取りにくい状況でした（白抜きの予定は予約確定できなかった予定）
今年のセッションも最高でした。今年は、自社とは事業領域や規模が大きく異なる企業の Snowflake 活用事例を中心に回りました。なかでも印象に残ったのが Canva と OpenAI です。Canva は聞けた 2 つのセッションがどちらも良かったので、それぞれ紹介します。
Canva①：コスト最適化と階層型ストレージ
Canva の 1 つ目は、Snowflake のコスト最適化に関する発表です。Canva は 600 以上の Snowflake アカウントと 100 以上のデータサービスを抱えています。中央のデータ基盤チームだけでコストを管理しきるには規模が大きすぎるため、Resource Metadata Service という独自システムを開発し、コスト帰属（cost attribution）のカバレッジを 35% 未満から 85% 超まで引き上げ、80 以上のチームが、Snowflake を含む複数ベンダーのコストをセルフサービスで確認できるようにしていた点が印象的でした。
実装面もかなり具体的でした。FOCUS（FinOps Open Cost and Usage Specification）で請求データを標準化し、https://github.com/get-select/dbt-snowflake-monitoring (の fork 版) を使って、クエリ単位のコストに紐づける。コストを各チームが自分で見て判断できる状態にする、を大規模に実践していました。
さらに、2025 年に年間 121% 増加したストレージへの対応として、Iceberg テーブルを S3 上に配置する階層型ストレージを導入し、S3 の Storage Class 変更と組み合わせて最大 74% のストレージコスト削減を実現していました。Iceberg をコスト最適化の実装手段としてここまで具体的に使っている事例は初めて見たので、興奮しながら聞いていました。
Canva②：セマンティックレイヤーで「信頼できる AI 分析」をつくる
Canvaのもう1つは、AIアナリティクスとセマンティックレイヤーの話でした。彼らが取り組んだのは「メトリクスの不整合」への対策です。同じ「リテンション」が3チームで違う定義を持ち、その定義がdbtモデル・BIツール・アドホッククエリに散らばっている。信頼できる数字を使うには担当者にDMするしかなく、誰に聞くかで答えが変わる。この、人間のデータサイエンティストが日々困っている不整合が、そのままAIの信頼性も損なう、という指摘が刺さりました。
このセッションが良かったのは、AIがデータでつまずく原因を、どの層で解くのかに切り分けて見せてくれたことです。「そもそもどのデータを使えばいいか分からない」「使えても意味を取り違える」という上流の問題は、データアーキテクチャ（信頼できるデータを、ドメインごとに所有者を決めて整えること）で解く。「指標をどう計算するか」「複雑なSQLを正しく書けるか」という下流の問題は、セマンティックレイヤー（Snowflake Semantic View）で解く。この両方がそろって初めて、AIは正しい答えを返せる、という整理でした。そのうえで「AIをDWHに繋ぐだけでは魔法は起きない。むしろ既存の問題を悪化させる」と釘も刺していました。
正直、「データを整えてSemantic Viewを足せば正答率が上がる」という結果だけなら「そうだよね」で終わる話なのですが、私が良いと思ったのは、そこに至るプロセスでした。AI活用を始める前に、データサイエンティストへのヒアリングから始め、「そもそもメトリクスとは何か」を定義し直し、ディメンションの命名規則やドメインごとの所有者を地道に決めていく。また、正答率まで実測してからリリースし、継続的な改善を行っていました。この泥臭い積み重ねこそが、信頼できるAIの土台なんだと思いました。クラウドDWHは手軽な分、定義もモデルも場当たり的に増えます。意図して設計し、測り続けない限り、データアーキテクチャは勝手には良くならない。前半に書いた気づき1や3を、現場の苦労ごと見せてくれたセッションでした。
OpenAI：研究データプラットフォーム Deep Dive
そして OpenAI の研究データプラットフォームのセッション。とにかく規模が桁違いで、現在 10 ペタバイト規模、年末までに 100 ペタバイト規模への拡大を見込んでいるとのこと。1 日あたり数百テラバイト、ピーク時には 1 ペタバイトを超えるデータを取り込み、その 70% を RL（強化学習）サンプルデータが占める、という世界です。
研究者が毎日使う RL Sample Viewer のクエリを高速に保つために、クラスタリングキーを実験 ID のみから event_day + experiment_id の複合キーへ変更してチャーン問題を解消した話や、マテリアライズドビューの無効化問題を、ベーステーブルからメトリクスのスカラー値だけを抜き出した軽量なテーブル使って回避して部分バックフィルを可能にした話など、Snowflake を限界まで使い込んだチューニングの知見が惜しみなく共有されていました。モデルのリリースサイクルが 16 ヶ月から 6 週間に短縮された背景に、こうしたデータ基盤のスケーラビリティがある、という話は痺れました。ちなみに React フロントエンドの 99% を Codex で生成している、という小ネタも今年らしさを感じました。
現地参加して良かった！
今年の Summit でも、現地参加することでしか味わえない体験が多数ありました。
Snowflake 開発チームとの議論（CEC）
今年は、CEC（Customer Engagement Center）で Snowflake の開発チームと直接話す機会をいただきました。今回ディスカッションしたのは、クエリコンパイラチームとセキュリティチームの 2 チームです。具体的な中身はここでは控えますが、製品をつくっている当事者と直接話すと、議論が一気に具体的になり、背後にある思想まで聞けるのは非常にありがたい体験で、現地参加の意義をいちばん感じた時間でした。
imageセキュリティチームと営業担当と私
今年もたくさんの Snowflake Community メンバーと交流することができました。期間中は毎晩、様々な場所で交流の場が提供されていて、「データ」という一点に特化して、業界も事業規模も異なる人たちと熱量高く語り合えるのは、何物にも代えがたい時間です。
今年は現地で DataOps Night in SF にも登壇させていただきました。来年は Snowflake Summit の登壇を目指したいです。
(おまけ) Summit 参加者向けの事前決起会イベント
昨年に続き、今年も Summit を存分に楽しむための事前オフラインイベントの企画に参加させていただきました。実は、今年はユーザーグループのある地域で、同時開催を目論んでいたのですが、残念ながら九州から Snowflake Summit に参加する人を見つけられず、九州会場は実現できませんでした… 悔しい！
もっともっと九州に Snowflake の良さを伝えていくぞ、という決意を新たにしました。九州で Snowflake が気になっている方、ぜひ一緒にやりましょう！
おわりに
この記事では、Snowflake Summit 2026 の参加レポートをお届けしました。今年の Summit は「The Agentic Enterprise」をテーマに、AI が実験段階を超え、本番で成果を出すフェーズに入ったことを宣言する内容でした。一方で、その土台にあるのは結局「自社のデータ」と「それを安全に扱うガバナンス（Governance）」だという、私たちが 2 年かけて積み上げてきた取り組みの延長線上にあるメッセージでもありました。前半に書いたとおり、今年は AI Agent による成果を出し始める年だと思っています。業務に根づいたデータ基盤を足場に、その上で AI Agent を動かす一歩を、現場の手でもう一段進めていきます。
LayerX では一緒にデータ基盤を作ってくれる仲間を募集しています。ちょっとでも興味のある方は一度ぜひお話しましょう！
SnowVillage に参加しよう！
日本には、SnowVillage という Snowflake コミュニティがあります。Snowflake やそのエコシステムを学び、切磋琢磨するコミュニティです。Snowflake を知りたいという方はぜひ参加しましょう。
Snowflake Summit 2026 の Recap イベントに登壇します
Summit の振り返り（Recap）イベントに登壇します。現地で見聞きしてきた熱量を、できる限りそのままお届けしたいと思っています。予定の合う方はぜひご参加ください！
原文を表示
こんにちは。バクラク事業部 BizOps部 データグループの@civitaspoです。2026年6月にサンフランシスコで開催された Snowflake Summit 2026 に現地参加してきました。本記事では、その様子や感想をレポートしようと思います。
不本意な形で[Xのトレンドに載ることに... 私はコスプレをしていたようです笑](https://cdn-ak.f.st-hatena.com/images/fotolife/c/civitaspo/20260617/20260617101241.png)
Snowflake Summit 2026（以下、Summit）は2026年6月にサンフランシスコのモスコーニ・センターで開催された、Snowflake社が年次で主催する最大のユーザーカンファレンスです。Snowflakeの最新技術とAIの未来を語る基調講演に始まり、500を超えるセッションやハンズオンが行われました。今年の参加者は20,000人を超え、日本からは400人を超える人々が参加しました。
今年はLayerXからは@civitaspoが現地参加してきました。Summitへの参加は今年で3年連続です。2024年に初めて参加した当時、私たちはまだSnowflakeを本格導入する前の段階でした。「Snowflakeで何ができるのか」を学びに行くことが主な目的だったことを覚えています。それから2年が経ち、バクラクのデータ基盤はBigQueryからSnowflakeへの移行を進め、いまでは単なるDWHとしてではなく、プロダクト機能や日々の業務を支える基盤としてSnowflakeを活用しています。
ありがたいことに、その取り組みやコミュニティへの貢献を評価いただき、今年はSnowflake Data Superheroesにも選出いただきました。
この変化によって、私自身のSummitとの向き合い方も大きく変わりました。今年は「Snowflakeを使って、次に何を解くべきか」を考えるために参加しています。
昨年、一昨年のSummit参加レポートも合わせて読んでいただけると、この1年の変化が伝わるかと思います。
tech.layerx.co.jp tech.layerx.co.jp
The Agentic Enterprise の実装へ
今年のキーノートのテーマは「The Agentic Enterprise」でした。CEOのSridhar Ramaswamyは、AIが「約束」や「実験」の段階を超え、現実の業務成果を生み出す段階に入ったことを繰り返し語っていました。
印象的だったのは、話の中心が「AI Agent周辺のエコシステム」だったことです。同じフロンティアモデルを誰もが使えるようになっていく中で、企業ごとの差分は、自社固有のデータ、その意味づけ、そして業務の中で安全に使い続ける仕組みに移っていく。Snowflakeはその変化を、The Agentic Enterpriseという言葉で表現していたように感じました。
その観点で見ると、今年の発表は単なる新機能の羅列ではなく、「企業が自社データの上でAI Agentを本番運用するための部品」が揃ってきたことを示すものだったと思います。本記事では個別機能を網羅的に紹介するのではなく、このKeynoteを起点に、Snowflakeの上でAIワークロードを本番運用していくために、私たちが何を準備し、何を実践していくべきかを考えてみます。
データで AI Agent をコントロールする
SridharがKeynoteで繰り返していたのは、「モデルそのものは競争優位ではない。同じモデルは競合も使える。差がつくのは自社固有のデータと、その組み合わせ方だ」という話でした。同じフロンティアモデルを多くの企業が使えるようになるなら、モデルを呼び出せること自体は差別化になりません。差がつくのは、そのモデルに何を読ませ、何を根拠に判断させ、どの範囲で行動させるかです。
AI Agentは、賢いモデルを使えば勝手に業務を理解してくれるものではありません。どのデータを参照してよいのか。どの指標定義に従うべきなのか。どのデータが最新なのか。どの操作は許可され、どの操作は禁止されるのか。こうした前提を与えなければ、業務で使えるAI Agentにはなりません。
その前提を作るのが、データとメタデータです。テーブルやカラムの意味、指標定義、データの鮮度、リネージ、権限、利用履歴、業務ルール。これらは単なる管理情報ではなく、AI Agentの振る舞いを決めるハーネスになります。
このハーネスが弱いと、AI Agentはそれらしい答えを返せても、業務上は使いにくいものになります。正しい指標を選べない。古いデータを参照する。見るべきではないデータに触れる。根拠のない判断をする。こうした問題は、モデルを強くするだけでは解けません。
だからこそ、Snowflake上に蓄積してきたデータとメタデータを、AI Agentのハーネスとしてどう使うかが重要になります。自社データは、AI Agentに情報を与えるためだけのものではありません。AI Agentの行動範囲を定め、業務の文脈に沿って動かすための土台でもあります。そのため、自社で保有するデータを AI Agent をコントロールするためのデータとして再定義する必要があります。
AIワークロードをデータ基盤の延長で動かす
次に重要になるのは、それらをAIワークロードから切り離さないことです。Keynoteでも、AI Agentを現実の業務成果につなげるには、データを中心に据える必要があると語られていました。データが分断され、ガバナンスが効いていない状態は、AI活用の大きな障壁になります。だからこそ、AIワークロードはデータ基盤の外側に足すものではなく、データ、メタデータ、権限、ガバナンスと同じ環境の中で動かす必要があります。
ここで重要になるのが、SnowflakeのOne Productとしての価値です。2024年のSummitレポートでも、Data、Compute、AI、Security & Governance、Collaborationが一つのプロダクトとして統合されていること、そして大量のデータが存在する場所でワークロードを動かせることの価値について書きました。
データを別の環境へ移すと、通信コスト、通信環境のセキュリティ担保、データ鮮度の担保、コンプライアンス確認などが必要になります。一方で、Snowflake上で完結できるなら、その障壁を減らし、AIやデータプロダクトの開発に集中できます。
AIワークロードでは、この構図がさらに重要になります。Snowflakeにデータとメタデータがあり、その同じ環境でAIワークロードも動かせる。データの鮮度、権限、監査、意味定義、計算、検索が一つの体験としてつながる。これによって、AI Agentの回答を業務判断に使い、期待と違う結果が出たときには、データ、定義、権限、実行ロジックのどこに問題があるのかを切り分け、次の改善につなげられます。
One Productの価値は、データを移動しないことだけではありません。データ、メタデータ、計算、権限、ガバナンス、AI実行が一つの環境でつながり、AI Agentを使った業務改善のサイクルを速く回せることにあります。The Agentic Enterpriseを実装していくなら、AI Agentをデータ基盤の外側に足すのではなく、データ基盤の延長として動かせる状態を作る必要があります。
Snowflake上でのAI Agent実装を、組織で取れる手段にする
今年のSummitで見えてきたのは、このOne Productの価値をAIワークロードへ広げるための実装の型です。Semantic Viewで構造化データの意味を定義し、Cortex Searchで非構造化データを検索可能にし、Cortex Agentがそれらを束ねる。去年は個別の新機能として見えていたものが、今年は「Snowflake上でAI Agentを作るならこう組む」という型として見えてきました。
これは、Snowflake上でAIを動かすことが、単にLLMを呼び出す話ではなくなってきたということです。Snowflake上にあるデータとメタデータを活かし、検索や意味定義と組み合わせながら、業務文脈を持ったAI Agentを組み立てる話になってきています。
ただし、AI Agent開発の基盤はSnowflakeだけではありません。AWSなど、アプリケーションが動いている環境にもAIワークロードを実装する選択肢があります。既存サービスとの接続、低レイテンシなオンライン処理、プロダクト機能への組み込み、デプロイや監視の運用を考えると、アプリケーション側で動かす方が自然なワークロードもあります。
一方で、Snowflake上のデータを活かし、分析、検索、要約、判断支援を行うワークロードは、Snowflake上で完結させる価値が大きい領域です。データ移動を減らし、鮮度、権限、監査、意味定義を既存のデータ基盤の延長で扱えるからです。
重要なのは、どちらか一方に寄せることではありません。Snowflake上でAI Agentを作ると何が得意で、どこに制約があり、どのユースケースに向いているのかを理解しておくことです。それが分かっていなければ、実際の課題に向き合ったときに、Snowflakeを選ぶべきか、アプリケーション側で実装すべきかを判断できません。
そのためには、小さくても実際に作ってみる必要があります。Semantic View、Cortex Search、Cortex Agentを組み合わせ、データ基盤の利用者が触れられる形でAI Agentを試す。回答の質だけでなく、権限の扱い、データ鮮度、指標定義との接続、アプリケーション側との責務分界も確認する。そうした経験があって初めて、「この問いはSnowflake上のAI Agentで解けそうだ」「この処理はアプリケーション側に寄せた方がよさそうだ」という判断ができるようになります。
The Agentic Enterpriseを自分たちの現場で実装していくなら、最初から大きなAI Agent基盤を作る必要はありません。まずはSnowflake上でAI Agentを作り、使い、向き不向きを理解することです。データとメタデータを動かさずにAIワークロードへつなげる実装を、必要なときに取れる技術的な手段として、組織に持たせていく必要があります。
開発速度を落とさないガバナンスを設計する
Platform KeynoteのTrustパートでは、AI Agentを本番運用するためのセキュリティ・ガバナンス機能が多く発表されていました。Agent Identity、Data Movement Policies、Multi-party Approvals、Trust Center AI Security Checksなどです。
これらの発表から見えたのは、AI Agentを既存のガバナンスの中で扱えるようにする方向性です。どのAI Agentが、どの権限で、どのデータにアクセスしたのか。データをどこへ出そうとしたのか。高リスクな操作に承認を挟めるのか。こうした論点を、AI Agentごとの個別実装に閉じず、プラットフォーム側の仕組みとして扱えるようになってきています。
ここで重要になるのは、管理者がすべてを個別に見なくてもセキュアに運用できる設計です。AI Agentが数個であれば、個別にレビューし、個別に権限を付け、個別に例外対応する運用でも回ります。しかし、組織の中でAI Agentが増えていくと、そのやり方はすぐに限界を迎えます。1000個のAI Agentに対して1000個のポリシーを手で作る運用では、現場は進めなくなります。管理者もレビューに追われ、どこにリスクがあるのかを見通しにくくなります。
必要なのは、AI Agentごとの細かい審査を増やすことではなく、共通の境界を先に決めることです。たとえば、本番データに対する破壊的な操作は許可しない。特定のデータ分類は外部へ持ち出せない。高リスクな操作には承認を必須にする。AI Agentが使える外部ツールの範囲を制限する。こうした、組織として越えてはいけない線を共通ポリシーとして定義します。
そのうえで、個別のAI Agentに必要な権限は、ユースケースやチームの文脈に応じて委譲できるようにします。現場は、自分たちの持つ権限の範囲でAI Agentを作れる。管理者が定義した外側の境界は越えられない。この二層に分けることで、AI Agentが増えても運用をスケールさせやすくなります。
中央で制御する範囲と、チームに委譲する範囲を早めに決めておくことが重要です。ここを曖昧にしたままAI Agentを増やすと、後から個別レビューと例外対応が積み上がります。安全性を担保したい場面ほど、管理者が全部を見る運用に寄りがちですが、その形では開発速度が落ちます。現場が迷わず使える共通ポリシーを先に作ることが、AI Agentを組織に広げるための前提になります。
競争優位性は、評価して改善し続ける仕組みで作る
今年のKeynoteやセッションでは、AI Agentを作るための部品がかなり揃ってきたことが分かりました。一方で、作ったAI Agentをどう評価し、どう運用し、どう改善し続けるかについては、まだ確立された方法論が少ないように見えました。
ここに競争優位性が生まれる余地があります。フロンティアモデルを呼び出すことは、すでに難しくありません。AI Agentを構成するための機能も、今後さらに整っていきます。差がつくのは、AI Agentを作った後です。そのAI Agentが本当に業務成果につながっているのか。以前より良くなっているのか。コストに見合っているのか。これを測り、改善し続けられるかどうかが重要になります。
評価すべきものは、回答の正しさだけではありません。ユーザーの意図を解決できたのか。人手の確認や修正を減らせたのか。回答を受けたユーザーが次の行動に進めたのか。失敗したときに、適切に人間へ引き継げたのか。変更を加えたときに、以前できていたことが壊れていないか。こうした観点まで見なければ、AI Agentが業務で使える状態になっているかは判断できません。
コストも同じです。ストレージやコンピュートのコスト管理は成熟してきましたが、AI Agentにおける「成果あたりのトークン」や「成果あたりのAIコスト」は、まだ比較するための基準がありません。モデル単価が下がっても、利用量が増えれば総額は下がりません。AI Agentが業務に浸透するほど、単純な利用量ではなく、成果とコストを結びつけて見る必要があります。
だからこそ、最初から大きな評価基盤を作るというより、AI Agentごとに何を成功とみなすのかを定義し、品質とコストを継続的に見直せる状態を作ることが重要です。Snowflake上でAI Agentを動かすなら、データ、実行履歴、利用状況、コストを近い場所で扱えるため、この評価と改善のサイクルも組みやすくなります。
競争優位性は「AI Agentを作った」ことでは生まれません。評価方法がまだ固まりきっていない今だからこそ、自社の業務に合わせて、何を成功とみなし、どう測り、どう安く正確にしていくかを先に作る価値があります。AI Agentを作る力ではなく、継続して改善し続ける運用能力こそが、これからの差分になるはずです。
まとめ
今年のKeynoteでは、The Agentic Enterprise を実装する段階に入ったというメッセージと、実装するためのパーツがSnowflakeに揃ったというメッセージを受け取りました。
あとは、そのパーツを自分たちのデータ、ガバナンス、評価の仕組みに接続し、実際に使える形にしていく段階です。Snowflake上でAI Agentをどう動かすのか、どこまでをデータ基盤に寄せ、どこからをアプリケーション側に置くのか。安全に広げるための境界をどう引き、品質とコストをどう見続けるのか。今年は、小さく作り、使い、失敗し、判断基準を増やしていく。その経験を組織の中に積み上げて、結果を出すサイクルがどんどん回る年にします。
やっていき！！
今年のセッションも最高だった！
今年のセッションも最高でした。今年は、自社とは事業領域や規模が大きく異なる企業のSnowflake活用事例を中心に回りました。なかでも印象に残ったのが Canva と OpenAI です。Canvaは聞けた2つのセッションがどちらも良かったので、それぞれ紹介します。
Canva①：コスト最適化と階層型ストレージ
Canvaの1つ目は、Snowflakeのコスト最適化に関する発表です。Canvaは600以上のSnowflakeアカウントと100以上のデータサービスを抱えています。中央のデータ基盤チームだけでコストを管理しきるには規模が大きすぎるため、Resource Metadata Service という独自システムを開発し、コスト帰属（cost attribution）のカバレッジを35%未満から85%超まで引き上げ、80以上のチームが、Snowflakeを含む複数ベンダーのコストをセルフサービスで確認できるようにしていた点が印象的でした。
実装面もかなり具体的でした。FOCUS（FinOps Open Cost and Usage Specification）で請求データを標準化し、https://github.com/get-select/dbt-snowflake-monitoring (のfork版) を使って、クエリ単位のコストに紐づける。コストを各チームが自分で見て判断できる状態にする、を大規模に実践していました。
さらに、2025年に年間121%増加したストレージへの対応として、IcebergテーブルをS3上に配置する階層型ストレージを導入し、S3のStorage Class変更と組み合わせて最大74%のストレージコスト削減を実現していました。Icebergをコスト最適化の実装手段としてここまで具体的に使っている事例は初めて見たので、興奮しながら聞いていました。
Canva②：セマンティックレイヤーで「信頼できるAI分析」をつくる
Canvaのもう1つは、AIアナリティクスとセマンティックレイヤーの話でした。彼らが取り組んだのは「メトリクスの不整合」への対策です。同じ「リテンション」が3チームで違う定義を持ち、その定義がdbtモデル・BIツール・アドホッククエリに散らばっている。信頼できる数字を使うには担当者にDMするしかなく、誰に聞くかで答えが変わる。この、人間のデータサイエンティストが日々困っている不整合が、そのままAIの信頼性も損なう、という指摘が刺さりました。
このセッションが良かったのは、AIがデータでつまずく原因を、どの層で解くのかに切り分けて見せてくれたことです。「そもそもどのデータを使えばいいか分からない」「使えても意味を取り違える」という上流の問題は、データアーキテクチャ（信頼できるデータを、ドメインごとに所有者を決めて整えること）で解く。「指標をどう計算するか」「複雑なSQLを正しく書けるか」という下流の問題は、セマンティックレイヤー（Snowflake Semantic View）で解く。この両方がそろって初めて、AIは正しい答えを返せる、という整理でした。そのうえで「AIをDWHに繋ぐだけでは魔法は起きない。むしろ既存の問題を悪化させる」と釘も刺していました。
正直、「データを整えてSemantic Viewを足せば正答率が上がる」という結果だけなら「そうだよね」で終わる話なのですが、私が良いと思ったのは、そこに至るプロセスでした。AI活用を始める前に、データサイエンティストへのヒアリングから始め、「そもそもメトリクスとは何か」を定義し直し、ディメンションの命名規則やドメインごとの所有者を地道に決めていく。また、正答率まで実測してからリリースし、継続的な改善を行っていました。この泥臭い積み重ねこそが、信頼できるAIの土台なんだと思いました。クラウドDWHは手軽な分、定義もモデルも場当たり的に増えます。意図して設計し、測り続けない限り、データアーキテクチャは勝手には良くならない。前半に書いた気づき1や3を、現場の苦労ごと見せてくれたセッションでした。
OpenAI：研究データプラットフォーム Deep Dive
そして OpenAI の研究データプラットフォームのセッション。とにかく規模が桁違いで、現在10ペタバイト規模、年末までに100ペタバイト規模への拡大を見込んでいるとのこと。1日あたり数百テラバイト、ピーク時には1ペタバイトを超えるデータを取り込み、その70%をRL（強化学習）サンプルデータが占める、という世界です。
研究者が毎日使うRL Sample Viewerのクエリを高速に保つために、クラスタリングキーを実験IDのみから event_day + experiment_id の複合キーへ変更してチャーン問題を解消した話や、マテリアライズドビューの無効化問題を、ベーステーブルからメトリクスのスカラー値だけを抜き出した軽量なテーブル使って回避して部分バックフィルを可能にした話など、Snowflakeを限界まで使い込んだチューニングの知見が惜しみなく共有されていました。モデルのリリースサイクルが16ヶ月から6週間に短縮された背景に、こうしたデータ基盤のスケーラビリティがある、という話は痺れました。ちなみにReactフロントエンドの99%をCodexで生成している、という小ネタも今年らしさを感じました。
現地参加して良かった！
今年のSummitでも、現地参加することでしか味わえない体験が多数ありました。
Snowflake開発チームとの議論（CEC）
今年は、CEC（Customer Engagement Center）でSnowflakeの開発チームと直接話す機会をいただきました。今回ディスカッションしたのは、クエリコンパイラチームとセキュリティチームの2チームです。具体的な中身はここでは控えますが、製品をつくっている当事者と直接話すと、議論が一気に具体的になり、背後にある思想まで聞けるのは非常にありがたい体験で、現地参加の意義をいちばん感じた時間でした。
今年もたくさんのSnowflake Communityメンバーと交流することができました。期間中は毎晩、様々な場所で交流の場が提供されていて、「データ」という一点に特化して、業界も事業規模も異なる人たちと熱量高く語り合えるのは、何物にも代えがたい時間です。
今年は現地で DataOps Night in SF にも登壇させていただきました。来年は Snowflake Summit の登壇を目指したいです。
(おまけ) Summit 参加者向けの事前決起会イベント
昨年に続き、今年もSummitを存分に楽しむための事前オフラインイベントの企画に参加させていただきました。実は、今年はユーザーグループのある地域で、同時開催を目論んでいたのですが、残念ながら九州からSnowflake Summitに参加する人を見つけられず、九州会場は実現できませんでした… 悔しい！
もっともっと九州にSnowflakeの良さを伝えていくぞ、という決意を新たにしました。九州でSnowflakeが気になっている方、ぜひ一緒にやりましょう！
おわりに
この記事では、Snowflake Summit 2026の参加レポートをお届けしました。今年のSummitは「The Agentic Enterprise」をテーマに、AIが実験段階を超え、本番で成果を出すフェーズに入ったことを宣言する内容でした。一方で、その土台にあるのは結局「自社のデータ」と「それを安全に扱うガバナンス」だという、私たちが2年かけて積み上げてきた取り組みの延長線上にあるメッセージでもありました。前半に書いたとおり、今年はAI Agentによる成果を出し始める年だと思っています。業務に根づいたデータ基盤を足場に、その上でAI Agentを動かす一歩を、現場の手でもう一段進めていきます。
LayerXでは一緒にデータ基盤を作ってくれる仲間を募集しています。ちょっとでも興味のある方は一度ぜひお話しましょう！
SnowVillageに参加しよう！
日本には、SnowVillageというSnowflakeコミュニティがあります。Snowflakeやそのエコシステムを学び、切磋琢磨するコミュニティです。Snowflakeを知りたいという方はぜひ参加しましょう。
Snowflake Summit 2026のRecapイベントに登壇します
Summitの振り返り（Recap）イベントに登壇します。現地で見聞きしてきた熱量を、できる限りそのままお届けしたいと思っています。予定の合う方はぜひご参加ください！
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み