Snowflake Summit 26の初日がAIスタック判断を一変させた：データ重力がモデル重力を凌駕する時代へ

2つの発表。1つのプラットフォーム。両方の主要フロンティアモデルファミリー。

Snowflake Summit 26はサンフランシスコで今日開幕し、同社が2月から段階的に準備してきた一連の製品ニュースが発表されました。Snowflakeのプレスリリースによると、初日の製品セットにはCortex AISQL（パブリックプレビュー）、Snowflake Intelligence（一般提供開始）、Adaptive Compute、Openflow、Snowflake Marketplace上のエージェント製品、レガシー移行用のSnowConvert AIが含まれています。

開幕基調講演にはSnowflake CEOのSridhar Ramaswamy氏とAnthropicのDaniela Amodei社長が登壇します。今年初め、SnowflakeはOpenAIとの2億ドルの複数年パートナーシップを開示し、GPT-5.2をSnowflakeの境界内に取り込みました。Cortex AI FunctionsとCortex REST APIからネイティブに利用可能です。2つのフロンティアモデルファミリー。同じデータ境界。同じガバナンスプレーン。

この組み合わせがCTOのアーキテクチャの問いを変えます。以前の問いは「どのモデルをライセンスするか？」でした。新しい問いは「どのデータ重力の中で推論を実行するか？」です。

初日に実際に出荷されたもの

初日の製品のうち3つはCTOが真剣に注目する価値があります。

重要なポイント

• 2億ドル：SnowflakeのOpenAIとの複数年パートナーシップのコミットメント。GPT-5.2をCortex AIにネイティブで取り込む（Snowflake-OpenAI共同発表、2026年2月2日）
• 2万人超：Snowflake Summit 26の6月1日から4日にわたる予想参加者数（Snowflake Summit 26公式通知）
• 2：Snowflakeガバナンス境界内でネイティブに呼び出し可能なフロンティアモデルファミリー（OpenAI GPT-5.2とAnthropicのClaude）

Cortex AISQL。 テーブルとステージに格納されているテキスト、画像、音声などの非構造化データを含む、SQLクエリから直接呼び出せる生成AI。新しい製品カテゴリではありませんが、SQLの内部からのサーフェスが重要です。データアナリストはワークフローを離れることなくモデルへプロンプトを送れます。プロビジョニングが必要な別のAIやML（機械学習）プラットフォームはなく、管理すべきモデルサービングインフラもなく、推論の実行時にデータが外に出ることもありません。すべての呼び出しが管理された境界内で行われます。

Snowflake Intelligence（一般提供開始）。 データクラウドのエージェントインターフェース層。データに接続するために別のプラットフォームの上にエージェントを構築するのではなく、エージェントランタイムがデータと同じ境界内に座ります。推論はレコードが存在する場所で行われます。これにより、過去12ヶ月間エンタープライズのエージェントデプロイを妨げてきたデータレジデンシーとガバナンスの問いが解決されます。

Adaptive ComputeとOpenflow。 見出しほど注目されませんが、運用上は重要です。Adaptive ComputeはワークロードをAIのワークロードが分析のワークロードのように振る舞わないことを考慮しながら独立してオートスケールします。AIのワークロードはバースト性が高く、GPU集約的で予測不能です。Openflowはカスタムパイプラインなしに運用データを境界内に取り込むデータ移動層です。両方が、Snowflake内でAIを実行することとSnowflake外から呼び出すことの摩擦を軽減します。

「データ重力がモデル重力を凌駕する」が正しい読み方である理由

Snowflake-OpenAIパートナーシップがフレームを変えます。

今年2月まで、AIアーキテクチャに関するCTOの会話はこのような感じでした。「主要モデルを選ぶ必要がある。汎用知性はOpenAI、長文脈分析はAnthropicのClaude、マルチモーダルにはGemini。次に、それらを呼び出すサービング層を構築する。それから自社システムとの間のデータ移動を管理する。」モデルが重力の中心でした。その他はすべて統合のための配管でした。

そのモデルが崩れつつあります。MicrosoftはOpenAIをAzureの内部に入れました。AnthropicはAWS BedrockとSnowflakeにネイティブで組み込まれています。Googleは自社のモデルをデータ・分析製品の内部に入れました。Databricksはデータプラットフォーム上で独自モデル層を提供します。フロンティアモデルは、ワークロードレベルでのアーキテクチャを左右するほど希少でも差別化されてもいなくなっています。ますます交換可能になっています。

交換可能でないのはあなたのデータです。 顧客レコード、サポートチケット、取引履歴、契約。そのデータはどこかにあります。移動するには費用がかかります（法的、運用上、政治的に）。したがって、データがすでに存在する場所が、AIの作業が行われなければならない場所になりつつあります。

これをデータ重力テストと呼びます。AIのワークロードについて問いてください：データは今どこにあり、そのデータを他の場所に移して推論を実行するコストはいくらか？答えが「Snowflakeにあり、移動にはパイプライン作業で数百万ドル、エグレスフィー、さらにガバナンスレビューがかかる」なら、適切な推論場所は移動を最小化するものです。今日、多くのエンタープライズにとって、その場所はSnowflake自体です。

これはSnowflake固有の点ではありません。位置的な点です。同じロジックは、データのほとんどがMicrosoftにある組織にとってはMicrosoft Fabricに、Databricksにある組織にとってはDatabricksに有利に働きます。データを所有するプラットフォームがエージェントランタイムを得ます。

CTOが今週答えるべき3つの問い

Snowflake Summitは今後72時間で大量の価格表、パートナーのケーススタディ、機能比較を生み出します。3つの問いに答えるまで、それらは何の意味もありません。

問い1：運用データは今日実際にどこにあるか？ 正直に答えてください。「どこに置きたいか」ではありません。どこに座っているか？顧客データ、取引履歴、製品テレメトリの70%がすでにSnowflakeにあれば、新しいエージェントサーフェスは、公開ベンチマークでどのモデルが技術的に優れていても、デフォルトで運用AIのワークロードを獲得します。データがS3、Postgresのレプリカ、ウェアハウス中間層のないSalesforceインスタンスにまたがって分散している場合、まだデータ重力主導の判断をしていません。まずデータ統合の判断をしています。

問い2：AIロードマップ上の次の3つのワークロードに実際に必要なモデルは何か？ モデルを選ばないでください。ワークロードの要件を選んでください。ワークロードAが長文脈の文書分析を必要とする場合、それはClaudeの領域です。ワークロードBがコード生成とエージェント的ツール使用を必要とする場合、GPT-5.2またはClaudeのどちらでも機能します。ワークロードCが安価な大量分類を必要とする場合、より小さいフロンティアモデルまたはプラットフォーム上のオープンウェイトモデルのどちらかです。まずワークロードとモデルを対応付け、次にデータプラットフォームがネイティブにその呼び出しをサポートするか確認してください。サポートする場合は良いことです。サポートしない場合、問いはモデルをデータに持ってくるか（Cortex、Bedrock、Azure AI Foundry経由）、データをモデルに移すか（より多くのエグレス、より多くのパイプライン作業、より多くのガバナンスレビュー）になります。

問い3：1年間のガバナンスコミットメントは何か？ 2026年にどのデータ境界が推論ワークロードをホストするかについて行う判断は固着します。2027年に別のベンダーが優れた機能を出荷したからといって、ランタイムを再構築することはありません。少なくとも18ヶ月間の運用スケーリングに対応できるプラットフォームを選択してください。つまりデータレジデンシー、監査証跡、アクセスコントロール、モデルのロールバック、その境界内に次世代モデルが現れる信頼できるロードマップを意味します。

Snowflakeに運用データのほとんどがある1,500人規模のSaaS企業のCTOは、来四半期ではなく今週ワークロードとモデルの対応付けを実施すべきです。Cortex内のエージェントMarketplaceはすでに、現在スタンドアロンサブスクリプションとして購入しているポイントソリューションと競合するパートナー構築エージェントを提供し始めています。

これをMicrosoft BuildとDatabricksに対してどうマッピングするか

Snowflakeは真空の中で発表しているわけではありません。Microsoft BuildはWindows Agent Framework、Windows Agent Store、Azure AI Foundry拡張など独自のエージェントプラットフォームプッシュとともに6月2日から3日に開催されます。DatabricksのData+AI Summitは6月中旬に独自のモデル層とエージェントプッシュとともに開催されます。

3つのポジションは類似したアーキテクチャに収束しつつありますが、異なるデータ重力の中心から出発しています。

Snowflakeの賭け：エージェントランタイムとしてのデータウェアハウス。運用データと分析データがSnowflakeにある場合に最も強力です。AIの作業が構造化データと企業管理の非構造化資産に重いウエイトがある組織に最適です。

Microsoftの賭け：エージェントプラットフォームとしてのWindowsとAzure。従業員がMicrosoft 365で生活し、開発ツールがAzure上で動作している場合に最も強力です。AIの作業がナレッジワーク、文書、開発者ワークフローに重いウエイトがある組織に最適です。

Databricksの賭け：エージェントの基盤としてのレイクハウスとモデルサービング。データエンジニアリングが成熟しており、AIの作業が生成AIだけでなくMLモデルのデプロイに重いウエイトがある場合に最も強力です。

ほとんどのエンタープライズは一つを選びません。主要と副次の境界を持つことになります。合理的なデフォルト：顧客向けデータがすでに存在する境界を主要として選び、いずれにせよ従業員の生産性境界（おそらくMicrosoft）で一部のエージェントワークロードを実行することを受け入れてください。このデュアル姿勢は問題ありません。問題なのは4つの主要な賭けを同時に行い、明確なランタイムの所有権なしに終わることです。

AIワークフォース投資に関するエグゼクティブ意思決定フレームワークにおいて、データ重力テストはワークフォーススキルテストと並行して位置づけられています。両方の問いが同じ答えに収束します：どのように埋没した投資を避けるか？

今四半期取締役会にブリーフィングすべきこと

Summitのニュースは今後2週間以内にプレス報道を通じて取締役会に届きます。その前に準備してください。

4枚のスライドで要点をカバーできます。スライド1：現在の運用データの所在地（正直な答え）。スライド2：18ヶ月のAIロードマップ上の3つのワークロードとそれぞれのモデル要件。スライド3：主要として確約するデータ境界とその理由、1年間のガバナンス姿勢とともに。スライド4：存在することを受け入れる副次境界（生産性のためにおそらくMicrosoft）と統合アプローチ。

避けたいこと：取締役会メンバーがSummitの要約を読んで「なぜSnowflake Intelligenceを使っていないのか？」と聞くのに、答えが「運用データがそこにないから」という状況です。さらに悪いのは「プレスリリースが印象的だったから移行中です」という場合です。取締役会の問いが正しい軸に向くよう、データ重力の現実を明確にしてください。

セールスパイプラインにおけるAIエージェントへの運用シフトについて詳しくは、セールススタック内で同じデータ重力のロジックが適用されます。顧客レコードを所有するプラットフォームがセールスエージェントランタイムを所有します。

今週のSummitは、誰がどの機能を出荷したかについて多くのノイズを生み出します。シグナルは構造的です。フロンティアモデルは今やホストされたコモディティです。データプラットフォームは今やエージェントランタイムです。これが今後18ヶ月間すべてのCTOが答えることになるアーキテクチャの問いです。

さらに詳しく

• リーダーが職場のAIについて誤解しているガバナンスギャップ
• AIコパイロット対AIエージェント
• AI ROIの測定
• 200人規模の企業の12ヶ月AIワークフォースロードマップ

FAQ

これはデータをSnowflakeに移すべきということですか？

必ずしもそうではありません。データ重力はモデル重力を凌駕しますが、データがすでにある場所は埋没した状態です。運用データの70%がすでにSnowflakeにあれば、そこのエージェントサーフェスはデフォルトでワークロードを獲得します。データがMicrosoft FabricやDatabricks、AWSにある場合、正しい答えはその境界にネイティブなエージェントランタイムを使用することです。クロスプラットフォームの移行はAI機能だけではほとんど正当化されません。管理された顧客データのテラバイトを移動するコストは、次の18ヶ月間のプラットフォーム間のモデル品質の差異よりもほぼ常に高くなります。

Snowflake内のGPT-5.2はOpenAIから直接のGPT-5.2と同じですか？

ほとんどのユースケースで機能的にはそうです。運用上はそうではありません。Snowflake内では、呼び出しがガバナンス境界内で行われるため、顧客データが境界を離れることはありません。トークンコストはOpenAI API契約ではなくSnowflakeクレジットを通じて請求されます。レート制限とクォータの仕組みも異なります。規制を受けるワークロード（医療、金融サービス、データレジデンシールール下のもの）については、境界内バージョンが監査において守りやすくなります。実験的な用途には、直接のOpenAI APIの方が多くの場合シンプルです。

自社インフラで独自モデルを運用するのはどうですか？

コスト経済性、レイテンシ、データの機密性がホストされたフロンティアモデルから外れる特定のワークロードには引き続き有効です。ただし、トレードオフは変化しました。OpenAIとAnthropicのどちらも主要なデータプラットフォームにネイティブで入るようになった今、独自モデルを運用する運用上のケースは1年前より狭くなっています。残っているメインの機会は、非常に大量の分類（小型のファインチューニング済みモデル）、厳格なオンプレミス要件、カスタムトレーニングが汎用フロンティアモデルを実際に上回る専門的な業界モデルです。ほとんどのナレッジワークと顧客向けAIにとって、境界内フロンティアモデルが今年のデフォルトになるでしょう。