SnowflakeのSnowWorkがデータウェアハウスをSales Opsのアクション層に変えた。アクセスを開放する前に行うべき5つの問いの監査

データウェアハウスはデータを保存する場所でした。Snowflakeはそれを実行基盤に変えました。そしてSales Operations（Sales Ops）は、誰も正式に引き継がせていなかった領域を管理する立場になっています。

Snowflakeが実際にリリースしたもの

Snowflakeの発表によると、Project SnowWorkは2026年3月18日にリサーチプレビューとして公開されました。ビジネスユーザーがコードを書かずに、データチームへの依頼なしに、管理されたSnowflakeデータ上で直接マルチステップのワークフローを実行できるエージェント型AIプラットフォームです。

このプラットフォームは財務、営業、マーケティング、オペレーション向けのロール対応プロフィールを搭載しています。各プロフィールはその機能に特有の用語とKPIを理解しています。営業プロフィールのユーザーはSnowWorkにテリトリー割り当ての再優先化、複数のデータソースにまたがるpipelineレポートの取得、取締役会向けプレゼンテーションの作成を依頼できます。エージェントはタスクを計画し、管理されたデータに対して直接実行します。

SnowflakeはSales Opsを主要な受益者として明示しました。同社は「繰り返しの多いレポート作業を自動化し、コードなしで複数のデータソースをまたいで作業し、数日ではなく数分でプレゼンテーション用の成果物を生成できる」とうたっています。これは確かな機能です。しかし、最初のユーザーがログインする前にSales Opsが答えなければならない問いも伴っています。

さらにもう1つの層があります。5月27日、SnowflakeはNatomaの買収意向を発表しました。Natomaはエージェント型企業向けのMCP（Model Context Protocol）ガバナンスのスタートアップです。Natomaはサーバーレジストリ、IDレイヤー、アクセスポリシー基盤を追加し、SnowWorkのエージェントがSalesforceやHubSpotなどのCRMプラットフォーム、VPC、オンプレミスシステムに対して確認されたガバナンスのもとで横断的に機能できるようにします。CIO.comの報道によると、Natomaのレイヤーはこれまでガバナンスが存在しなかったエージェント型システムにポリシー適用をもたらすために特別に設計されています。

SnowWorkとNatomaを組み合わせたスタックは、データウェアハウスの役割を受動的な保管庫から能動的な実行基盤へと変えます。この変化は理論上のものではありません。すでにプレビュー段階にあります。

重要なポイント

• Snowflakeは2026年3月にSnowWorkをリサーチプレビューとして公開し、ロール対応のエージェント型プロフィールで財務、営業、マーケティング、オペレーションのユーザーを対象としています。
• Snowflakeの株価は2026年5月28日から29日にかけて36%上昇しました（IPO以来最大の上昇）。第1四半期の業績、AWSとの拡大パートナーシップ、Natomaの買収発表が要因です（CNBCより）。
• Natomaの買収が完了すると、MCPガバナンスが追加され、SnowWorkのエージェントはSnowflake内だけでなく、Salesforce、HubSpot、VPC、オンプレミスシステムにも対応できるようになります。

なぜこれはITではなくSales Opsに関係するのか

ITはインフラへのアクセスを管理します。しかしSales Opsは、そのインフラに存在する定義を管理しています。セグメントロジック、テリトリールール、quotaの割り当て、商談ステージの基準です。

ビジネスユーザーがSnowWorkに「マウンテンウェストテリトリーのアカウントを再割り当てして」と依頼した場合、エージェントはデータウェアハウスに現在存在するセグメントロジックに基づいて書き込みを実行します。そのロジックが古く、スプレッドシートから部分的にしか移行されていないか、あるいは特定のフィールドで微妙に誤っている場合、エージェントは誤った定義に基づいて実行します。大規模に、自律的に。

データウェアハウスがアクション層になるということはこういうことです。誤ったデータ定義と誤ったビジネス上の意思決定との距離が縮まります。従来のウェアハウスでは、誤った定義は誤ったレポートを生み出します。誰かがレビューで気づきます。エージェント型ウェアハウスでは、誤った定義は誤ったアクションを生み出します。そしてそのアクションは連鎖することがあります。

Sales Opsはこれらの定義の意味を常に管理してきました。しかし、定義がレポートに存在していたとき、曖昧さのコストは混乱した数字でした。今、そのコストは実行されたワークフローです。ガバナンスの対象領域が拡大しており、AIセールスオペレーターとして行動することの意味を理解することはもはや任意ではありません。

明るい面として、Sales Opsはここで有利な立場にあります。ITが持っていないコンテキストを理解しているからです。第3四半期に行われたテリトリー分割がデータ層にまだ完全に反映されていないことを知っています。誰も削除しないが誰も使わないレガシーのquotaカラムがどれかを知っています。この組織的な知識は、まさに事前展開の監査が必要とするものです。

Sales Opsのための5つの問いの監査

ビジネスユーザーがSnowWorkのインターフェースに触れる前にこれらを実施してください。

1. エージェントが書き込みを行う可能性がある各指標の定義を誰が管理しているか?

上位10つのKPIから始めてください。クローズ済み受注の収益、ステージ別のpipeline、quota達成率、テリトリー割り当て、セグメントメンバーシップです。各指標について、最後に定義を更新した人物、定義が存在する場所（ウェアハウス、CRM、スプレッドシート、またはそのすべて）、その人物が今も在籍しているかどうかを特定してください。これらの3つの問いに答えられない指標は、エージェントアクセスの準備ができていません。AIを活用したCRMデータの衛生管理は前提条件であって、あれば良いものではありません。

2. スプレッドシートに残っているテリトリー、セグメント、quota（Snowflakeに入っていないもの）はどれか?

SnowWorkはウェアハウス内に存在するものに対して動作します。第2四半期のテリトリー再セグメンテーションがデータチームへのチケット待ちでGoogleスプレッドシートに残っている場合、SnowWorkはそれを把握していません。「テリトリーカバレッジを最適化して」というエージェントへの依頼は第1四半期のデータに基づいて最適化されます。営業ユーザーに対してSnowWorkを有効化する前に、公式のデータモデルと実際の作業データがある場所とのギャップを監査してください。自動化されたリードルーティングロジックとリアルタイムのアカウント階層再割り当ては、それらが稼働するデータの質に依存しています。

3. エージェントがテリトリーを誤って再割り当てしたり、商談ステージを動かしたりした場合のロールバックパスは何か?

必要になる前に定義してください。誰に通知されますか? Salesforceでの差し戻しプロセスはどうなりますか? NatomaのMCPレイヤーからのCRMへの書き戻しは監査イベントを生成しますか、それとも手動の担当者アクションと同一に見えますか? 有益なテスト: 過去12ヶ月間の実際のテリトリー再割り当てエラーを1つ選び、今日どのように差し戻すかを確認してください。次に、そのプロセスがエラーの原因が人間ではなくエージェントだった場合でも機能するかどうかを確認してください。

4. 「読み取りできる」と「実行できる」のアクセスをどのように段階化し、そのポリシーはどこに存在するか?

読み取りアクセスと実行アクセスは異なるリスク領域です。営業担当者がpipelineレポートを読むのは標準的です。営業担当者がSnowWorkを使ってプレゼンテーションを作成するのは小さな一歩です。営業担当者がSnowWorkを使ってアカウントを再割り当てしたり、商談ステージを動かしたりするのははるかに大きな一歩です。Natomaのガバナンスレイヤーはポリシー適用を追加しますが、そのポリシーを作成するのはITではなくSales Opsです。AIアクセスのためのデータ分類はSnowflakeオブジェクトをアクセス階層にマッピングするためのフレームワークを提供しています。最初のパイロットが始まる前に、アクセス階層にマッピングしてください。

5. エージェントが提案してステージが動いた場合、その監査証跡はどこにあるか?

この問いは2つの理由で重要です。1つ目はforecastの精度: エージェントの移動がステージ数を膨らませたり、下げたりした場合、把握する必要があります。2つ目はコーチング: エージェントが提案し、担当者が承認したことで商談ステージが動いた場合、それは担当者が独自に判断した場合とは異なるコーチングの会話になります。AIによって実行されたアクションの監査証跡はオプションのインフラではありません。人間とエージェントがワークフローを共有するシステムで説明責任を維持する方法です。

FAQ

Snowflake Project SnowWorkとは何ですか?

SnowWorkはSnowflakeのエージェント型AIプラットフォームで、2026年3月にリサーチプレビューとして公開されました。ビジネスユーザーがコードを書いたりデータチームを巻き込んだりすることなく、管理されたSnowflakeデータ上で直接、マルチステップの自律的なワークフローを実行できます。ユーザーはその機能の典型的な用語とKPIを理解するロール対応のインターフェースを通じて操作します。Sales Opsにとっては、テリトリー分析、pipelineレポート作成、プレゼンテーション作成などのタスクをデータエンジニアではなくビジネスユーザーがトリガーできることを意味します。

SnowWorkは通常のBIツールやCRMレポートとどう違いますか?

BI（Business Intelligence）ツールはデータを読み取り、可視化を返します。CRMレポートはフィルタリングされたスナップショットを取得します。SnowWorkはワークフローを計画して実行します。複数のステップを連鎖させ、NatomaのMCP（Model Context Protocol）ガバナンスレイヤーを通じてシステムに書き戻し、グラフだけでなくプレゼンテーションや再割り当てアクションなどの成果物を生成できます。この区別が重要なのはエラーのモードが変わるからです。誤ったBIチャートは誤ったチャートです。誤ったSnowWorkのワークフローは、稼働中のシステムに対して取られた誤ったアクションです。

Sales Opsはビジネスユーザーが直接SnowWorkを使うことを許可すべきですか?

許可すべきですが、今すぐではなく、監査なしでは許可できません。上記の5つの問いは導入を遅らせるためのチェックリストではありません。お客様のチームが管理するデータに対してエージェントが行動することを許可する前の最低限のデューデリジェンスです。SnowWorkから最も恩恵を受けるユーザー、つまり営業担当者、営業マネージャー、オペレーションアナリストは、真の時間節約を体感するでしょう。リスクはツールにあるのではありません。何があるか分からないうちに扉を開けてしまうことにあります。

今週すべきこと

• 1週間のパイロット計画を立てる。1チーム、1ワークフロー、1つのロールバックテストを対象に実施します。理想的なパイロットワークフローは、担当者が現在30〜60分かけて、単一の成果物（テリトリーレポート、forecastデッキ、アカウントリスト）を生成しているものです。エージェントバージョンを手動バージョンと並行して実行し、アウトプットを比較してください。
• Sales Opsがレポートする上位10つのKPIについて、指標定義のオーナーシップを監査する。各指標について、定義を管理している人物、定義の在処、Snowflakeに完全に入っているかスプレッドシートに残っているかを確認します。
• パイロット開始前にロールバックテストを設定する。パイロットワークフローが実行できる最もリスクの高いアクション（誤った場合に最も下流への影響が大きいもの）を選び、差し戻しのパスが機能することを確認してから文書化してください。
• 今すぐデータチームとアクセス階層の話し合いを始める。Natomaのガバナンスレイヤーは、アクセスポリシーを適用するインフラをSnowflakeに提供します。Sales Opsはそのポリシーの内容を定義する必要があります。その話し合いは1回のSprintより長くかかります。プレッシャーのかかる前に始めてください。

関連リソース

• AIセールスオペレーターとは
• AIを活用したSales Ops対従来のSales Ops
• Sales OpsがAIにおいて最高のROIユースケースを持つ理由
• 通話からCRM更新まで自動的に
• 企業はAI支出とデータで収益目標を達成できていない
• SalesforceとSlackにおけるOpenAIワークスペースエージェント