Snowflake Summit 2026 現地レポート Day3

JBS Data＆AIプラットフォーム部の中城です。2026年6月1日～6月4日にアメリカ・サンフランシスコで開催されたSnowflake Summit 26に参加しました。

本記事では、キーノートおよびHealthcare and Life Sciences関連セッションを中心に、Snowflakeが示したAgentic Enterpriseの方向性と、実業務にAIを組み込むうえで重要になる「コンテキスト」の考え方について紹介します。

なお、本記事では、イベントに参加して感じたことを素直につづります。通常の技術ブログと異なり、個人的な見解が含まれます。（2026/6/8 一部表現を見直し）

Snowflake Summit 2026は、AI Summitであり「Context Summit」でもあった

Snowflake Summit 2026は、AI Summitであり「Context Summit」でもあった

※個人の見解を多分に含みます。

Agentの前に、コンテキストを作れ

「AIを使って何ができますか」「RAGを作れますか」「Agentを業務に入れられますか」──ここ1、2年、顧客との会話の中で、この問いを受けることが一気に増えました。もちろん、できることは増えてます。生成AIの性能は上がり、RAGの構成も一般化し、MCPやAgentのような言葉も日常的に聞くようになっています。Snowflake、Databricks、Microsoft Fabric、各社のプラットフォームも、AIを前提に急速に進化しています。

それでも、自分の中にはずっと違和感がありました。

PoCは増えている
デモも増えている
提案も増えている

正直に言うと、そんなことを考えて少しだけ疲れを感じていました。

本番運用は本当に増えているのだろうか
業務に定着しているAIは、どれだけあるのだろうか
AIを試すことそのものが目的になっていないだろうか
顧客の役に立てているのだろうか

AI活用の提案をする。PoCを作る。一定の成果は出る。でもその後、業務に深く入り込まない。別の部署でまた似たようなPoCが始まる。モデルが変わり、ツールが変わり、また新しいPoCが始まる。

この「PoCループ」から、どうすれば抜け出せるのか。その問いを持って、Snowflake Summit 2026に参加しています。

最初は、ただただSnowflakeの新機能にわくわくしていました。Cortex、Snowflake Intelligence、CoCo、CoWork、Horizon、Agentic AI。当然、そうした発表を中心に見ています。

実際、発表された機能群は非常に強いものでした。AI、ガバナンス、セキュリティ、データ共有、相互運用性、開発者体験まで、隙がない。単に「AI機能を追加しました」という話ではなく、Snowflakeが次のデータプラットフォームの姿をかなり明確に描いていることが伝わってきました。

さらに、現地で何日もセッションを聞くうちに、見方は少し変わっていきました。今年のSummitで本当に繰り返し語られていたのは、AIそのものではありませんでした。

何度も出てきた言葉は、Context、Semantic、Governance、Trust、Ontology、Data Product、Workflow。つまり、Agentを動かす前に必要な「意味」と「信頼」の話でした。

途中から、こんな風に感じるようになりました。

Snowflake Summit 2026は、AI Summitではなかった。

これは、Context Summitだったのではないか。

第1章：モデルは差別化要因ではない

初日のKeynoteで、印象に残った言葉があります。「The model is not your unique advantage. Your data is.」モデルは、あなたの独自優位ではない。あなたのデータこそが優位性である。とてもシンプルな言葉ですが、かなり本質的だと思いました。

この数年、AIの議論はモデル中心でした。GPTがいいのか、Claudeがいいのか、Geminiがいいのか。どのモデルが一番賢いのか。どのモデルが一番速いのか。どのモデルが一番安いのか。もちろん重要です。

でも、それだけでは差別化できません。なぜなら、自社が使えるモデルは、競合他社も使えるからです。

SnowflakeのKeynoteでは、Agentic Enterpriseを実現するための要素としてEnterprise Data、AI Models、Business Applications、そしてAgentic Control Planeが語られていました。AIモデルだけではなく、企業データ、業務アプリケーション、ガバナンスされた制御層が必要だという話でした。

つまり、AIの価値はモデル単体では生まれない。モデルが、自社のデータ、自社の業務、自社のルール、自社の文脈に接続されたときに初めて価値になる。ここでいう「Your Data」は、単なるテーブルやファイルではない。

売上とは何か
顧客とは誰か
契約中の顧客だけを見るのか、見込み顧客も含めるのか
ある指標が悪化したとき、どの切り口で見るべきなのか
どこまでを自動化し、どこから人間が判断するのか

こうした業務上の意味まで含めて、初めて「Your Data」になる。差別化要因は、データそのものだけではない。

データに埋め込まれた、自社固有のコンテキストである。

第2章：なぜライフサイエンスのセッションを中心に回ったのか

今回、意図的にライフサイエンス・ヘルスケア領域のセッションを多く回りました。理由は、単にその領域に興味があるからだけではありません。顧客支援をしていて、ドメイン知識の必要性を強く感じるようになったからです。

データ基盤を作る
分析環境を整える
AI活用を提案する
RAGやAgentの構成を考える

しかし、ある時から自分の中で問いが生まれました。「自分は、扱っているデータのことを本当に理解しているのだろうか」

製薬企業や医療領域で扱うデータは、単なる業務データではありません。臨床データ、安全性データ、患者に関わるデータ、研究や開発の意思決定に関わるデータになります。そのデータが、どのように生まれ、どのように管理され、どのような品質基準を満たし、どのような意味を持っているのか。そこを理解せずに、データ基盤やAI活用だけを語っていいのだろうか。もちろん、医師や薬剤師、臨床開発担当者、臨床データマネージャーのようなドメイン専門家に勝てるわけではない。自分が専門家の代わりになることはできない。

それでも、少なくとも「自分が扱っているデータは何なのか」を理解したかった。そのために、臨床データマネジメント、バイオ技術者、バイオインフォマティクスの資格を取得しました。

そして今回のSummitでも、あえてヘルスケア・ライフサイエンスのセッションを中心に回りました。データ＆AIの最先端を知るためでもあります。でもそれ以上に、データの意味を知りたいと思いました。

Healthcare and Life Sciencesのパネルディスカッションでも、同じことを感じました。登壇者は、Vertex、Roche、UnitedHealth Group、医療提供者側のリーダーたちでした。製薬、保険、医療提供という立場は違う。しかし、共通していたのは、AIを単なる技術テーマとして語っていなかったことです。

冒頭で語られていたのは、患者アウトカムでした。

高リスクの患者をどう早く見つけるか
慢性疾患を持つ患者をどう支援するか
服薬アドヒアランスをどう改善するか
創薬や開発の意思決定をどう速く、正しくするか

AIの話をしているのに、出発点はモデルではない。出発点は、患者であり、業務であり、意思決定でした。

UnitedHealth Groupの登壇者は、自社の取り組みを「interoperable, trusted AI-ready
data at scale」と表現していました。相互運用でき、信頼でき、AIが使えるデータをスケールさせる、という意味です。この言葉を聞いたとき、かなり腑に落ちました。

AI Ready Dataとは、単にAIが読める形式にデータを整えることではない。患者、医師、保険者、製薬企業、それぞれの意思決定に耐えられるだけの意味と信頼を持ったデータにすることなのだと。だからこそ、ライフサイエンスのセッションを中心に回ってよかったと思っています。

AIの前に、データの意味と責任が問われる。

そこに、これからのAI活用の本質が見える気がしました。

第3章：AIの前に、患者がいる

GSKの「Digital Supply Networks in Clinical Trials」のセッションは、とても印象に残っています。テーマだけ見ると、臨床試験におけるサプライチェーンの話に見える。実際、治験薬をどう供給するか、どのように在庫や物流を管理するかという話です。しかし、冒頭で語られたのはシステムではなく、患者の話でした。

ある患者が治験に参加する。既存の治療選択肢がなく、臨床試験に期待している。遠方の施設まで移動し、スクリーニングを受け、条件を満たし、準備が整った。

しかし、当日、薬が届いていない。問題は、科学が失敗したことではない。薬が効かなかったことでもない。

サプライチェーンが失敗したことだった。

登壇者は、治験薬供給において「right drug, right patient, right time」が重要だと語っていた。正しい薬を、正しい患者に、正しいタイミングで届ける。

この言葉は、データ基盤やAI活用にもそのまま当てはまると思いました。正しいデータを、正しい人に、正しいタイミングで届ける。そして、その人が正しい判断をできるようにする。

GSKの発表では、Digital Supply Networkを構成する要素として、Connectivity、Visibility、Intelligence、Agility、Orchestrationが語られていました。最初に来るのはIntelligenceではない。Connectivityであり、Visibilityである。

つまり、AIが最初ではない。

まず、データがつながっていること。何が起きているか見えること。その上で初めて、Intelligenceが意味を持つ。

この順番はとても大事だと思いました。

第4章：「もう追加のダッシュボード」はいらない

GSKのセッションでもう一つ印象に残ったのは、ダッシュボードに対する言及でした。ここでの円グラフは作って終わりになりがちなダッシュボードと受け取りました、ダッシュボードが不要という意味ではありません。

登壇者は、こう話していました。

「We don’t want another pie chart.」もう追加の円グラフはいらない。

これは笑い話のようで、かなり本質的です。

円グラフは一例にすぎない。彼が言いたかったのは、見るだけで終わるダッシュボードはもういらない、ということと理解しました。これまでのデータ活用は、しばしばダッシュボードを作ることで終わっていました。

データを集める
可視化する
レポートにする

あとは現場が見て判断してください、という形です。しかし、現場は忙しい。医師も、看護師も、営業担当も、サプライチェーン担当も、調達担当も、ダッシュボードを見るために働いているわけではない。

Northeast Georgia Health Systemのセッションでも、似た話がありました。彼らは手術室向けに高度なダッシュボードを導入しました。外科医が自分で分析できる、非常によくできたツールです。しかし実際には、医師たちは忙しくて使わなかった。使う時間がない。久しぶりに開くと、使い方を忘れている。そこで彼らは、音声で質問できるAI Voice Assistantを作りました。

「先週の手術件数は？」
「ターンオーバータイムは場所別にどう違う？」
「どの手技で供給コストが高い？」

医師や現場担当者がいる場所で、そのまま問いを投げられるようにしました。ここで重要なのは、音声AIがすごいということではありません。その裏側に、700のメトリクスと400のディメンションを整備するという地道な取り組みがあったことです。現場の言葉で問いを受け取り、正しいデータに変換し、意味ある形で返すには、膨大な業務定義が必要になります。

AIを業務に入れるとは、チャット画面を作ることではありません。業務の問いを、データと結びつけることなのだと思います。

第5章：Semantic Layerだけでは足りない

今回のSummitで最も大きな気付きの一つは、Semantic Layerだけでは足りないということでした。OmniとCheckerの「AI Context Engineering」のセッションは、そのことをとても分かりやすく説明していました。

Checkerには、Snowflake上に6000以上のテーブルがあるという。そこにClaudeをMCPで直接つないで、同じ質問を何度か投げた。結果はどうだったか。

毎回違う答えが返ってきた。しかも、すべて間違っていた。彼らはこれを「Metric Drift」と呼んでいた。

なぜそうなるのか。AIはテーブル名やカラム名を見ることはできる。でも、その会社でその指標がどう使われているかまでは知らない。

たとえばCheckerには、FRT、First Reply Timeという指標がある。サポートリクエストに対して、人間が最初に返答するまでの時間を測る重要なSLA指標だという。しかし、AIはFRTという略語を知らない。90%という数値が何を意味するのかも知らない。どのキューで見るべきかも知らない。チャット、メール、電話でSLAの単位が違うことも知らない。

つまり、AIがデータを見られることと、AIが業務を理解できることは違う。

Omniのセッションで語られた言葉がとても印象的でした。

「The semantic layer defines calculations. AI context explains how to talk about them.」

Semantic Layerは計算を定義する。AI Contextは、その指標についてどう会話すべきかを定義する。

これはかなり重要だと思います。Semantic Layerは、売上やFRTの計算方法を定義する。
しかしContext Layerは、その指標をいつ、誰が、どう解釈し、どのような行動につなげるべきかを扱う。

計算の定義だけでは、AIは業務の会話に参加できない。

第6章：Contextは腐る

Workdayのセッションも、同じテーマをさらに深く掘っていました。彼らは、Trustworthy Data Agentを作る上で、Context Layerが必要だと語っています。

面白かったのは、Contextを3層に分けていたことです。

１つ目はTechnical Context。

カラム定義、テーブル定義、メトリクス定義、Semantic Viewのようなもの。

２つ目はStructural Context。

結合ルール、計算ロジック、セグメント定義、ドメイン固有の関係性。

３つ目はTacit Context。

エンジニアやデータアナリスト、業務担当者の中にある暗黙知。

この整理は非常に納得感がありました。

たとえば「Customer」という言葉を考えてみる。一般的には顧客である。しかしWorkdayのデモでは、BizOpsにおけるCustomerは、アクティブなMSAがあり、期限切れでないサブスクリプション契約を持つ存在として定義されていた。AIに「顧客数を業界別に出して」と聞く場合、この定義がなければ正しい答えにはならない。

さらに、Workdayのセッションではこんな表現も出てきました。

「Context can be stale. Context can rot.」コンテキストは古くなる。コンテキストは腐る。

これは本当にその通りだと思います。データカタログも同じでした。最初は頑張って整備する。でも半年後、誰も更新しなくなる。実態と定義がずれ、誰も信じなくなる。

Contextも同じです。だから彼らは「Treat context like code」と言っていました。Contextをコードのように扱う。バージョン管理し、更新し、検証し、フィードバックループを回す。

DataOps、MLOpsの次に、ContextOpsが必要になるのかもしれない。

第7章：データカタログは、Context Repositoryへ進化する

Atlanのブースでも、同じ方向性を感じました。従来のデータカタログは、どこにどんなテーブルがあるかを管理するものでした。

テーブル名
カラム名
リネージ
オーナー
タグ
説明文

もちろん、それも重要です。しかしAI時代には、それだけでは足りません。AIが業務上の問いに答えるためには、単に「このテーブルが存在する」ことを知っているだけでは不十分です。

そのテーブルが何を意味し、どの業務で使われ、どの指標と結びつき、どの定義が正とされ、どの利用パターンが信頼されているのか、そこまで理解しなければ、AIは正しい判断に近づけません。

Atlanのデモでは、Agents Studio、Context Agent、Metric Agent、Context、Engineering Studioのような概念が出ていました。SnowflakeやBIツール、SQL履歴、データリネージ、KPI定義、SOPなどからメタデータを集め、AIが使えるContext WindowやCognitive Repositoryを作るという話でした。

特に面白かったのは、Table Intelligenceの考え方です。このテーブルは何か、だけではない。

誰が、どんな質問をしているか。

どんなSQLがよく実行されているか。

どんなフィルタがよく使われているか。

つまり、人が実際にどうデータを使っているかまで、Contextとして取り込もうとしていました。

業務コンテキストは、ドキュメントの中だけにあるわけではない。人が日々データを使う行動そのものにも埋め込まれている。この流れは、Snowflake Horizon Catalogのセッションでもかなり明確に語られていました。

登壇者は、Agentがデータにアクセスできれば信頼できる答えが返る、というほど現実は単純ではないと話していました。なぜなら、コンテキストはデータベース、BI、ドキュメント、そして人の中にある暗黙知として分散しているからです。

アクセスできることと、理解できることは違う。

AIがテーブルに接続できても、それだけでは「どのテーブルを使うべきか」「どの指標が正式なのか」「どのダッシュボードが信頼されているのか」は分からない。データにたどり着けることと、そのデータを業務上正しく使えることの間には、大きな距離があります。

そこで示されていたのが、Horizon Contextの「Collect, Enrich, Activate」という考え方でした。まず、Snowflakeや外部データベース、BIツール、ETL/ELT基盤から、メタデータ、利用ログ、リネージを集める。次に、それらを人気度、認証済みの定義、Semantic View、データ品質、ビジネス用語で豊かにする。そして最後に、CoCoやCoWork、Cortex Agentがそのコンテキストを自動的に見つけ、使えるようにする。

ここで重要なのは、ユーザーやAgentが「どのSemantic Viewを使えばよいか」を事前に知っている必要がない、という点です。

たとえば、あるユーザーが自然言語で質問する。その裏側でAgentが関連するテーブルやSemantic Viewを検索し、信頼できる文脈を見つけ、それを使って答える。ユーザーは、どのデータベースに何があるかを知らなくてもよい。どのSemantic Viewが正式なのかを探しに行かなくてもよい。これは、かなり大きな変化だと思います。

従来のデータカタログは、人間がデータを探すためのものだった。これからのデータカタログは、AIが文脈を探すためのものになっていく。その意味で、データカタログはMetadata CatalogからContext Repositoryへ進化しつつある。

単なる台帳ではなく、AIが企業固有の意味を取り出すための基盤になる。

これも今年のSummitで感じた大きな変化でした。

第8章：Agentは業務知識の負担を取り除く

Sanofiの調達Agentのセッションも、とても象徴的でした。Sanofiは、購買業務にAgentic AIを組み込み、調達プロセスを再設計していました。

ここで印象に残った言葉があります。

「Remove the knowledge burden from employees.」従業員から、業務知識の負担を取り除く。

調達をしたい社員は、調達の専門家ではない。

カテゴリコードも知らない。

コストセンターも覚えていない。

どのフォームを使うべきかも分からない。

どのサプライヤを選ぶべきかも迷う。

従来は、それを社員に覚えさせていた。

しかしSanofiは、Conciergeという自然言語インターフェースから購買依頼を出せるようにしていました。社員がStatement of Workをアップロードすると、Agentが内容を読み取り、カテゴリやサプライヤ、コストセンターなどを補完し、Coupaの承認フローにつなげる。

これは、単なるAI導入ではない。自分には、BPRそのものに見えました。

ただし、従来型のBPRとは少し違う。従来のBPRは、業務プロセスを可視化し、標準化し、無駄を削り、システムに合わせて人間の仕事を変えるものでした。しかし、AI時代のBPRは、もう一段踏み込む。「人間が業務知識を覚えて操作する」前提そのものを変える。

調達担当者ではない社員が、カテゴリコードを覚える必要はあるのか。

コストセンターを暗記する必要はあるのか。

どの申請フォームを使うべきかを探す必要はあるのか。

Sanofiの事例は、こうした問いを突きつけていました。

AIを入れるとは、既存業務の画面を少し便利にすることではなく、業務知識の所在を、人間の記憶から、コンテキストを持ったシステム側へ移すことなのだと思います。

もちろん、AIがすべてを勝手に決めるわけではない。Human in the loopがある。信頼度が低い場合は人間が確認する。決定論的なワークフローと、確率的なAIを組み合わせている。

この考え方は重要です。

調達や医療、製薬、金融のような領域では、毎回違う答えを出すAIだけでは危ない。AIは抽出や分類、自然言語理解に使う。承認、監査、記録、コスト管理は決定論的に扱う。例外やリスクは人間が判断する。AIと業務プロセスの関係は、単純な自動化ではない。

BPRとContext Engineeringが重なったところに、Agentic AIの本当の価値が出るのだと思います。

Sanofiは、デジタル支出分類の取り組みで2500万ユーロの実削減を出したとも語っていました。これは、PoCではなくP&Lに効いた事例です。

ここにも、今年のSummitのメッセージがあります。

Agentは、便利なチャットボットではない。業務プロセスを変えるものだ。

第9章：ガバナンスはブレーキではない

もう一つ、Summit全体で繰り返し出てきたテーマがあります。Trustです。

Anthropicとの対談では、印象的な言葉がありました。

「Trust is an accelerant.」信頼は、加速装置である。

普通、ガバナンスやセキュリティは、AI活用を遅くするものだと見られがちです。個人情報があるから使えない。監査があるから進まない。規制があるから難しい。

しかし今年のSummitでは、逆の捉え方が多かった印象です。Trustがあるから、AIを広げられる。ガバナンスがあるから、現場に渡せる。権限制御や監査があるから、本番に出せる。

Healthcare and Life Sciencesのパネルでも、同じメッセージが繰り返されていました。

UnitedHealth GroupのRich Fisher氏は、競争優位についてこう語っています。

「Everyone increasingly will have access to similar models.」誰もが、似たようなモデルにアクセスできるようになる。

そのうえで、彼は差別化要因をこう表現しています。

「trust, context, and permissions」信頼、コンテキスト、権限。

これは、今回のSummit全体を象徴する言葉の一つだと思っています。

モデルでは差がつかない。では何で差がつくのか。

信頼できるデータがあるか。

そのデータに業務上の意味が埋め込まれているか。

誰が何を見てよいか、どの判断をAIに任せてよいかが制御されているか。

Rich氏はさらに、AIが正しい判断をするためには、business definition、business meaningを明示しなければならない、と語っています。

これもとても重要です。

AIは、意味が明示されていないデータに対して、勝手に正しい業務判断をすることはできない。テーブル名やカラム名だけでは足りない。そのデータが業務上どう扱われ、どの判断につながるのかを、企業側が明示しなければならない。

だから、ガバナンスはAIを止めるものではない。AIが安全に、かつ速く広がるための条件なのだと思います。

第10章：PoCループを抜けるために必要なもの

ここまでのセッションを通じて、自分の中で一つの答えが見えてきました。PoCで終わる理由は、モデル性能だけではない。

むしろ多くの場合、

データが信頼できない
業務定義が曖昧
コンテキストがAIに渡っていない
ワークフローに組み込まれていない
ガバナンスが後付け
誰が業務上の意味を所有するのか決まっていない
業務プロセスそのものが、AIを使う前提で再設計されていない

ことが原因なのだと思います。このパネルで最も直接的だった問いは、まさにPoCの話でした。

モデレーターはこう切り出します。

「Everyone has pilots, right? Not everyone has production-scale AI delivering ROI.」

誰もがPoCは持っている。

しかし、誰もがROIを生む本番規模のAIを持っているわけではない。これは、自身が感じていた違和感そのものでした。

PoCはできる。

デモもできる。

AIが答える画面も作れる。

でも、それが業務に入り、運用され、成果を出し続けるかは別問題である。UnitedHealth GroupのRich氏は、PoCから本番に進むために必要なものとして、
再利用可能で、信頼され、ガバナンスされたData Productを挙げていました。各ユースケースごとに毎回データを作り直し、毎回ガバナンスをやり直すのではなく、信頼できるデータを再利用できる状態にしています。

彼はこうも表現していました。

「stop rebuilding trust every time」毎回、信頼を作り直すのをやめる。

PoCが増える組織では、毎回データを集め、毎回定義を確認し、毎回権限や品質を確認する。そして、そのたびに時間がかかり、疲弊する。

AIをスケールさせる組織は、おそらく逆です。信頼を再利用できる形で資産化している。Data Product、Semantic Layer、Context Layer、Governanceを積み上げて、次のAI活用が速くなるようにしています。

Boston Scientificのセッションでも、似た話がありました。彼らはSnowflake上にデータウェアハウスを作った。技術的には多くのことを正しく行った。しかし、利用は広がらなかった。Excelが残り、シャドーITが残り、期待したほど意思決定は変わらなかった。

そこで彼らは、問いを変えました。

「What report do you need?」ではなく、「What decision are you trying to make?」

どんなレポートが欲しいのか、ではない。どんな意思決定をしたいのか。この問いは、今回のSummit全体を象徴していると思います。

AI活用の目的は、AIを使うことではない。

レポートを増やすことでもない。

意思決定と行動を変えることだ。

その意味で、PoCループを抜けるために必要なのは、AI実装だけではない。

BPRが必要なのだと思います。

AIを前提に、業務の入口、判断、責任分界、データの持ち方を再設計するBPRであると考えています。

RocheのRamesh氏の言葉も印象的でした。

「Deploying the tech is easy. Extracting the value requires change management.」

技術を導入するのは簡単だ。価値を引き出すには、チェンジマネジメントが必要だ。さらに彼は、技術変化は指数関数的に進む一方で、組織変化はもっとゆっくり進む、という趣旨の話をしていました。

AI活用で難しいのは、モデルを呼び出すことではない。業務を変えることだ。人の判断、プロセス、責任分界、データの持ち方を変えることだ。だからPoCループを抜けるには、AIの実装力だけでは足りない。必要なのは、信頼できるデータを再利用可能にすること。業務上の意味を明示すること。AIを現場のワークフローに埋め込むこと。

そして、組織がその変化を受け止められるようにすることだと考えます。

第11章：データAIエンジニアは、ドメインに寄るべきか

今回のSummitを通じて、自身のキャリア観にも影響がありました。データやAIに関わるエンジニアは、どこまでドメインに寄るべきなのか。以前から考えていた問いです。

技術を深めるべきか
業務を学ぶべきか
ドメインに踏み込むべきか

今の自分の考えは下記の通りです。

ドメイン専門家になる必要はない。しかし、ドメインのコンテキストを理解できる人になる必要はある。

医師ではない、薬剤師でもない、臨床開発の専門家でも臨床データマネージャーでもない。

でも、彼らが何を大事にしているのかを理解しようとすることはできる。

データがどのように作られたのか
どの定義が重要なのか
どこにリスクがあるのか
なぜそのワークフローになっているのか
なぜその判断に人間が必要なのか

こうした問いを持つことも、AI時代のデータに関わるエンジニアにとって、これまで以上に重要になっていくのではないかと思っています。

AIが生成するSQLをレビューする。

AI Agentが出した分析結果を判断する。

Semantic LayerやContext Layerを設計する。

そのためには、技術だけでなく、業務の意味に踏み込む必要がある。

Data Platformやアーキテクチャが重要であることは変わらない。これからは一層、ドメイン専門家や業務部門と一緒に、業務上の意味や判断基準を、データ・メタデータ・権限・ワークフロー・AI利用に落とし込む仕事が増えていく。

生成AIやAgentが業務に組み込まれると、これまで人や組織の中にあった業務上の意味や判断基準を、AIが扱える形で明示し、実装・運用していく必要がある。あえて言うなら、そうした領域をContext Engineeringと呼べるのではないか。

それは、ドメイン専門家の代わりになることではない。データ、業務、AIの間に橋を架けることだと考えています。

さいごに：モデルは変わる。コンテキストは残る

Summitを通じて、多くの新機能が発表されました。

CoCo
CoWork
Horizon Context
Cortex Sense
Agentic Search
Open Semantic
AI Guardrails
Agent Identity

どれも重要です。でも今回自分が持ち帰れたものは、新機能の一覧だけではなく下記のような知見でした。

モデルは変わる
Agentの作り方も変わる
MCPやA2Aのようなプロトコルも進化する
UIも変わる
最適なアーキテクチャも変わる

　でも、残るものがある。

業務用語の定義
メトリクスの意味
データ品質
リネージ
ガバナンス
権限
暗黙知
意思決定ルール
ワークフロー
ドメインコンテキスト

これらは、モデルが変わっても残る。むしろモデルが変わるほど、価値が増す。AI Ready Dataとは、AIが読めるデータのことではない。AIが業務文脈の中で判断できるデータのことだと思います。

Snowflake Summit 2026は、Agentic Enterpriseを掲げたイベントでした。しかし自分には、その裏側で一貫して語られていたメッセージとして、このようにも聞こえていました。

Agentの前に、Contextを整える。そして、Agentの利用を通じてContextを更新し続ける必要がある。

PoCループを抜けるために必要なのは、もう一つのAIデモではない。

自社の業務、自社のデータ、自社の判断基準を、AIが使える資産として残すことだ。

そして、AIを前提に業務そのものを問い直すことだ。

モデルは数か月で変わる。

ツールも変わる。

でも、コンテキストは残る。

今回のSummitで、Snowflakeはそのための道筋をかなり明確に示してくれたと思っています。

CoCo、CoWork、Horizon Context、Cortex Sense、Agentic Search、Open Semantic、AI Guardrails、Agent Identity。

個別の機能名だけを見ると、単なる新機能発表に見えるかもしれない。

でも、それらをつなげて見ると、Snowflakeが目指しているのは、AIを安全に、信頼できる形で、業務の中に組み込むためのプラットフォームなのだと感じます。

そのためには、自分たち自身も単なる実装者ではなく、顧客の業務コンテキストを理解する必要がある。

これからのデータAI人材の価値は、そのコンテキストを理解し、構造化し、AIデータと業務の間に橋を架けられるかどうかにある。

少なくとも僕は、今回のSummitでそう感じました。

長いことつらつら書いたけど、Snowflake Summit最高！、データ最高！！

安全に、そして最大限にSnowflake Summitを楽しめるよう支えてくださったSnowflakeの皆さま、現地で連日ディスカッションさせていただいたパートナー・ユーザー企業の皆さま、本当にありがとうございました。

今回のSummitを通じて強く感じたのは、Snowflakeが単に新機能を発表するだけでなく、顧客がデータとAIを使ってどのように価値を生み出せるかを、本気で考えているということでした。

その姿勢に触れたことで、私自身も「顧客に対してどのような価値を届けるべきか」「PoCで終わらせず、業務に定着するAI活用をどう支援できるか」を改めて考えるきっかけをいただきました。

そして、ここまで読んでくださった皆さまにも感謝しています。

この記事が、AI活用やデータ基盤のあり方について、少しでも考えるきっかけになれば嬉しいです。

今後ともよろしくお願いいたします。

Day1、Day2の様子についてもJBSメンバーがレポートしておりますので、
下記リンクからご確認ください。

Snowflake Summit 2026 現地レポート Day1 - JBS Tech Blog

Snowflake Summit 2026 現地レポート Day2 - JBS Tech Blog

　------
最後にいくつか現地のようすを共有します。
会場の写真

移動日の余った4時間で詰め込んだ現地調査（観光）
サンフランシスコ現代美術館

フィッシャーマンズワーフでクラムチャウダー

exploratorium（科学博物館）

AI学習データセットの画像群、なぜAIはキッチンの中の馬を認識するのが苦手なのか

来年はどこでしょうか。すでに開催が楽しみです。　