「Snowflake Summit 26」参加レポート！現地で見たAI実装の最前線

「Snowflake Summit 26」 は、Snowflake が年次で開催する顧客、パートナー、開発者向けカンファレンスです。2026年は6月1日から4日までの4日間、米国サンフランシスコの Moscone Center で開催されました。現地参加者は2万人を超え、日本からの参加者だけでも400名を上回っていたようです。富士フイルムビジネスイノベーションからは、若手自らが海外に行って現地で見て聞いて新しい気づきを得て欲しいという役員の意向（※）もあり、今回は30歳の私を含めた3人で参加してきました！

※「うまくいき過ぎた会社は、新しいことができない」CINOとCTOが語るイノベーションの起こし方 | 富士フイルムビジネスイノベーション

今年の通底テーマは“Making AI Real for Business”で、直訳すると「AIをビジネスで現実にする」になります。AIを技術トレンドや実証実験にとどめず、実際の業務価値・ビジネス価値の創出につなげていくという意思が込められたテーマ設定と受け止めました。

日程	Keynote	内容の焦点
初日（6/1）夕方	Opening Keynote	全体構想（AI Data Cloud、Agentic Enterprise）
2日目（6/2）午前	Platform Keynote	製品アーキテクチャと主要機能の開示
3日目（6/3）午前	Builder Keynote	開発者向けの実装デモと拡張機能

初日のKeynote会場の様子

Snowflake が打ち出した役割はもはやデータウェアハウスではありません。データとAIに関わるアプリとエコシステムを束ねるAI Data Cloud、そしてその上でエージェントが動くAgentic Enterprise の基盤、というのが新しい立ち位置です。AI Data Cloudは去年から言っていましたね。

何を見に行ったのか

生成AIの議論は、モデル名から始まり、モデル名で終わることが多くなりました。半年単位で主役が入れ替わる議論を、業界はもう何周も繰り返しています。ただし、現場の温度は少し違います。PoCで動いたAIが本番に乗せた途端に止まるとか、誰がどのデータを使ったかを説明できないことに気付くとか、モデルを差し替えた途端に、出力の再現性が崩れるとか...。私が「Snowflake Summit 26」に行った理由は、ここにあります。他社に提供するAI機能となると、データの権限、出力の説明責任、評価、コスト配賦、テナント分離の話を避けて通れません。このあたりを、米国の主要ベンダーと先進ユーザーがどこまで実装に落としているのか。それを確認するために、現地に飛びました。

AI実装のカギはモデル以外にある

会場で繰り返し示された論点は、モデル選定の一段下の階層にありました。本番AIで先に詰まるのは、モデルの賢さではなく周囲の制御です。モデルは半年で入れ替わりますが意味定義、権限、監査、評価の設計は、入れ替えが効きません。入れ替えるたびに作り直すなら、本番運用には乗りませんね。Snowflake CEO の Sridhar Ramaswamy 氏は、Opening Keynote で Agentic Enterprise を実現する4つのコンポーネントを提示しました。

要素	内容
Enterprise Data and Context	企業自身のデータと業務文脈
AI Models	Claude、Gemini、GPT などの推論エンジン
Software and Applications	SAP、Salesforce、ServiceNow、Workday などの業務アプリ
Agentic Control Plane	全体を束ねてエージェントを実行可能にする制御層

Agentic Enterpriseとそれを取り囲むエコシステムの全体

今後新しく設計しなければならないのは、自社のデータと業務文脈をどう整えるか(Enterprise Data and Context)とエージェントをどの制御で動かすか(Agentic Control Plane)の2つみたいですね。

AI-Ready Dataというデータ層

Snowflakeを始め最先端のテック企業が提唱し続けているのがAI-Ready Dataです。業務上の意味、参照権限、鮮度、入手元と加工履歴、評価基準が紐づいた状態のデータを指します。
LLMに投げ込めるデータと、AIに責任を持って使わせられるデータは別物です。

観点	LLMに投げ込めるデータ	AI-ready data
意味定義	カラム名から推測	業務定義として明示
権限	一律で参照可	用途、テナント単位で制御
出所	個別	入手元、加工履歴、責任者が追跡可
評価基準	なし	品質、再現性、合格条件が定義済み

PoCで動かすときはよしなに揃えたものをLLMに渡せば良いのですが、本番で必要なのは本番に準じた環境とデータです。ここで効いてくるのが、セマンティック層 です。セマンティック層は、AIのための辞書ではなくて業務ユーザーが「売上」「顧客」「契約」を、どの粒度、どの計算式、どの利用条件で扱うかを宣言する層です。人間同士なら、曖昧な言葉でも会議中に確認できますがAIは確認せずに動きます。曖昧なままAIに指示してしまうと所謂ハルシネーションが起こります。SQLエラーなら失敗が見えますし権限エラーなら止まりますが、意味を取り違えたAIの回答は、見た目だけ整ったまま出力されてしまいます。社外向けのAI機能で一番怖いのは、止まることではなくて間違った意味で動き続けることかもしれません。

Agentic Control Planeという制御層

データを整えるだけでは足りません。誰の権限で、どの操作を、どこまで自動実行してよいか。その判断と記録をどこに置くかが、エージェントを実行主体として扱うときの設計対象になります。今回Opening Keynote で出てきた Agentic Enterprise には Agentic Control Plane という重要な要素があります。Summit 26 で発表された製品を並べると、輪郭が見えてきますね。

位置付け	機能	内容
開発エージェント	CoCo（旧 Cortex Code）	開発者向けデータ作成支援ツール。自然言語でデータ処理を記述でき、パイプラインの失敗原因を診断して修復案を提示することも可能。
業務ユーザー向け	CoWork（旧 Snowflake Intelligence）	個人専用のAIアシスタント。Gmail、Google Calendar、Google Docs、Jira、Salesforce、Slack と連携。Skills、MCP Connectors、Deep Research、iOS アプリ、Reusable Artifacts を備え、全機能が GA で提供されると発表。Samsung では1,000名のエグゼクティブが利用中とのこと。

CoCo は、開発者がデータ処理を書く現場に入ってきます。危ない操作には人間の承認を求める Human-in-the-Loop が組み込まれており、エージェントが暴走しないことを前提として設計されています。CoWork は、業務ユーザーの作業を支援します。注目すべきは、CoCo と CoWork の両方が、エージェントの動作範囲を業務側で制御することを前提に作られている点です。エージェントを「賢く」する競争ではなく、エージェントを「動かしてよい範囲に閉じる」競争に、製品設計の重心が移ってきているわけですね。

Snowflake CoWorkの発表

今回見た技術についてほんの一部を記載します。

データを動かさずに使う：Open Sharing

AI-Ready Dataの議論には、もう一つの含意があります。データを AI に使わせるためのデータの実態をどこに置くかという問題です。これまでのデータ基盤の常識はデータソースからデータを抜き出してDWHに流し込むことを前提に設計されていました。AIエージェントの時代ではむしろ逆に私は感じています。データはサイロに置かれたまま使えなくなる、という前提を捨てて、データを統合してAIが使える状態にすることが Agentic Enterprise の必須条件になっていきそうです。
Snowflakeが示した答えのひとつが、Platform Keynote で発表された Open Sharing です。プラットフォーム上のデータを、Iceberg REST Catalog 経由で、Spark、Databricks、Dremio、Trino など他のクエリエンジンから直接読めるようにする構造です。

IcebergでつなぐOpen Sharing

ETLが要らなくなる構造：Snowflake Postgres

Snowflake 上に PostgreSQL 互換のフルマネージドデータベースを提供するようです。業務アプリのバックエンドDBと、分析・AIが使うデータが、同じプラットフォーム上で同じデータを共有する構造になったというのは中々に革新的に思えました。
これまでの常識は、業務アプリは別の Postgres や OLTP DB に書き込み、そこから ETL や CDC で吸い上げて分析プラットフォームに流し込む。要はデータは2か所以上に物理的に分離して存在し、コピーと同期が発生することが多かったんです。
SSnowflake Postgresを使うと、業務アプリの書き込み先が Snowflake 上の Postgres になり、その同じデータを分析エンジンや AI エージェントが ETL なしで直接参照できます。
Postgresの登壇発表では "T Lives On - Kill the E and L" とまで言及されていました。

段階	従来	Snowflake Postgres
Extract	ソースDBから抜き出す/コピーする	Postgres から中間ストレージに直接書き込み（No Extract）
Load	DWHに流し込む	Catalog 経由で読む（No Load）
Transform	SQL等で加工	残る ※Business logic never goes away
同期	バッチまたは CDC を組む	自動同期

ETL のうち Extract と Load を消し、Transformation だけが残る。その上で、Postgres 側でも Snowflake 側でも、同じ SQL でビジネスロジックを書き続けられる。業務アプリのコード、業務トランザクション、分析クエリ、AIエージェントのデータアクセスが、同じプラットフォーム上で完結する世界です。ただし、これは Postgres のすべてのワークロードを Snowflake に集約するという話ではありません。応答性能、運用コスト、既存のDBとどう接続するかの設計は引き続き残りそうです。

Snowflake Postgresによる"T Lives On - Kill the E and L"

「Snowflake Summit 26」を通じて感じたのは、AI活用の議論が「作れるか」から「売って運用できるか」へ移りつつある、ということです。モデルを呼び出すこと、チャットUIを作ること、PoCで一定の精度を出すことは、以前よりも確実に簡単になっています。

一方で、顧客に提供するAI機能として継続的に運用するには、モデルの精度だけでは足りません。AIが参照するデータの意味を定義することや、どの情報にアクセスできるかを制御すること、実行結果を後から説明できるようにすることなど...。このあたりを設計しないままAIを本番に出すと、動くデモは作れても、売れるプロダクトにはなりません。

今回のSummitで見たものは、向いている方向は同じです。AIを業務データにつなぎ、業務アプリと接続し、必要な範囲で実行させ、その結果を説明できる状態に近づけることです。今回得た知見を、今後のAI機能開発やデータ基盤の設計に還元していきます。
そして、次に同じ場所へ行くなら、今度は「何が発表されたか」だけでなく、「自分たちは何を実装して、何を持ち帰って比較できるか」まで準備して臨もうと思います。

最後に少し、現地で見聞きしたものを残しておきます。

コミュニティが大きい！名刺がなくなった

今回の出張で得た一番大きなものは、現地で見たユーザーコミュニティの規模と熱量でした。「Snowflake Summit 26」 には2万人を超える参加者が集まり、日本からも400人以上が現地参加していました。 連日ネットワーキングの機会を設けてくださっていたので、2日目夜は日本人参加者向け、3日目は製造業界向けのレセプションにも参加してきました。普段あまり社外の方とやり取りするわけではないので名刺が有り余っていたはずなのですが、渡航参加前後で用意した名刺が消滅してしまいました。皆さん夜までパワフルでした。私も5日のうち4日は参加しました。そういった場で仲良くなった方もいます。毎日とっても楽しかったですね。

サンノゼ訪問

アメリカ出張の目的はカンファレンス参加だけではありません。初日午前、サンノゼの Plug and Play を訪問しました。大企業からスタートアップまで入居する米国のコワーキング兼アクセラレーター施設です。入口の壁一面に入居企業のロゴが並んでおり、日本企業のロゴも目につきます。富士フイルムビジネスイノベーションもサンノゼに拠点を置いており、FUJIFILM North America Corporation出向メンバーとも議論を交わしてきました。

Plug and Playに入居する企業の一部

Ramen "IPPUDO"の食べ比べもしました！

帰国した直後に福岡への出張があったので、帰国してほぼ徹夜状態で仕事をこなした後、そのまま福岡へ向かいました。流石に16時間時差は堪えましたが、今回の出張で思いました。つまりエンジニアは体力勝負！それとせっかくならと一風堂の食べ比べをしました。どちらも美味しかったです。