Snowflake Intelligence:概要・料金・コスト監視

Snowflake Intelligenceは、ai.snowflake.comからアクセスできる新しいUIです。自然な言葉でデータに質問するだけで、チャートやテーブル、自然言語によるインサイトを添えた回答が即座に返ってきます。Snowsight UIの複雑さに触れたくないビジネスユーザー向けに切り出された独立アプリで、データベースやスキーマ、ロール、クエリ履歴などを意識する必要はありません。SQLを書く必要も、アナリティクスエンジニアからの回答を待つ必要もなく、シンプルなチャット画面だけで完結します。構造化データ(Cortex Analyst経由)、非構造化データ(Cortex Search経由)、そしてカスタムツールを横断的にオーケストレーションするAIエージェントが、ビジネスの全体像を描き出します。

いわばSnowflakeデータ版のChatGPTですが、社内チームが構築したエージェントとセマンティックモデルを活用するため、自社のビジネス定義をきちんと理解し、アクセス制御も尊重され、ハルシネーションも抑えられています。

これによりビジネスサイドのユーザーは、「Q4の製品カテゴリ別売上を見せて」といった質問を自分の言葉で投げかけられます。どのテーブルに売上データがあるのか、製品がどう分類されているのかを把握しておく必要はありません。サプライチェーン担当のアナリストが「冬物ジャケットについて顧客はどんな問題を報告している?」と聞けば、構造化された売上データと非構造化のサポートチケットの両方からインサイトを引き出せます。どのツールを使い、結果をどう組み合わせるかはエージェントが判断します。

もちろん、正しく動かすには事前のセットアップが必要ですし、油断するとコストがじわじわ膨らむこともあります。仕組み、料金、そして請求額を抑えるコツを順に見ていきましょう。

Snowflake Intelligenceの中核となるのが「エージェント」です。エージェントとは、1つ以上のセマンティックビュー、セマンティックモデル、Cortex Searchサービス、各種ツールに接続されたAIモデルのこと。仕組みは「設定」と「利用」という2つのフェーズに分かれます。

フェーズ1:インフラとエージェントのセットアップ

まずはIntelligence用のデータベースとスキーマを用意します。

-- Create the Intelligence database
CREATE DATABASE IF NOT EXISTS snowflake_intelligence;
GRANT USAGE ON DATABASE snowflake_intelligence TO ROLE PUBLIC;

-- Create schema for agents
CREATE SCHEMA IF NOT EXISTS snowflake_intelligence.agents;
GRANT USAGE ON SCHEMA snowflake_intelligence.agents TO ROLE PUBLIC;

-- Grant agent creation privileges
GRANT CREATE AGENT ON SCHEMA snowflake_intelligence.agents TO ROLE your_admin_role;

Snowflake Intelligenceは標準ではユーザーのデフォルトロールとウェアハウスを利用するため、これらが各ユーザーに設定されているかを確認しておきましょう。

フェーズ2:構造化データ向けセマンティックビューの構築

セマンティックビューは、ビジネス用語を実際のデータベーススキーマに紐づける役割を担います。売上がfact_sales.amt_total_excl_taxに入っていることをユーザーに覚えさせる代わりに、「revenue」をビジネス概念として定義しておくイメージです。

セマンティックビューは、Snowsightのウィザードから作成するか、YAMLファイルをアップロードして作成できます。ウィザードを使う場合の手順は次のとおりです。

1. AI & ML → Cortex Analystへ移動
2. 「Create new」→「Create new Semantic View」をクリック
3. テーブルとカラムを選択
4. ビジネスメトリクスとリレーションを定義
5. サンプル質問を追加

裏側ではYAMLファイルが生成されます。セマンティックビューは、ビジネスユーザーの言葉づかいとデータベーススキーマの構造のあいだのギャップを埋めてくれる存在です。最小限の例を見てみましょう。

name: revenue_analysis
description: "Sales and revenue metrics by product and region"
tables:
  - name: sales
    description: "Daily sales transactions"
    base_table:
      database: analytics_db
      schema: sales
      table: fact_daily_sales
    dimensions:
      - name: product_category
        expr: product_category
        data_type: STRING
        description: "Product category"
    facts:

コードを展開

ポイントは、説明文と同義語を抜かりなく整えること。ユーザーが「total sales」と尋ねても、定義しているのが「gross revenue」だけならエージェントは意図を読み取れないかもしれません。

YAMLはSnowsight上で直接編集することも、ウィザード経由で編集することもできます。

フェーズ3:非構造化データ向けCortex Searchサービスの作成

実装方法の詳細はCortex Searchに関するブログ記事で紹介しています。ここでは簡単な例だけお見せします。

ドキュメントやサポートチケットなどのテキストデータには、次のように設定します。

-- Create search service on your document table
CREATE CORTEX SEARCH SERVICE support_tickets_search
  ON ticket_text
  ATTRIBUTES customer_id, ticket_date, severity
  WAREHOUSE = search_warehouse
  TARGET_LAG = '1 hour'
  AS (
    SELECT
      ticket_id,
      ticket_text,
      customer_id,
      ticket_date,
      severity
    FROM support.tickets
  );

Cortex Searchは、ドキュメント、会話ログ、トランスクリプトなど、テキスト量の多いデータのインデックス作成と検索に向いています。

フェーズ4:エージェントの作成と設定

ここで各要素を結びつけます。Snowsightでの手順は次のとおりです。

1. AI & ML → Agents → Create agentへ移動
2. 「Create this agent for Snowflake Intelligence」を選択
3. ユーザーに表示する名前を設定
4. セマンティックビューをCortex Analystツールとして追加
5. Cortex Searchサービスを追加
6. オーケストレーションの指示を設定
7. ロールベースのアクセス権を設定

これでエージェントは構造化データと非構造化データの両方にアクセスでき、両者を横断してオーケストレーションできるようになります。ユーザーが質問を投げると、エージェントは次の処理を行います。

• 質問を解析する
• 使うツールを判断する
• セマンティックビューに対してクエリを実行する(Cortex AnalystがSQLを生成)
• 非構造化データを検索する(Cortex Search経由)
• 結果をまとめ、可視化を生成する

フェーズ5:Intelligenceを使う

ユーザーはai.snowflake.comからIntelligenceにアクセスします。サイドバーには次の3項目だけのシンプルなナビゲーションが並びます。

New Chat:

Agents:

Recent(チャット履歴)

多くのユーザーはまず「New chat」から始めるはずです。エージェントとデータソース(autoが推奨)を選び、質問を入力するだけ。

質問するとエージェントは深い思考モードに入り、推論のステップを順に表示しながら回答を組み立てていきます。

回答が確定すると推論の詳細はデフォルトで折りたたまれますが、「show details」をクリックすればいつでも思考プロセスを振り返れます。

個人的に大きな弱点だと感じるのは、分析結果を保存して何度も見返すことができない点です。「一度チャットして、レポートを何度も確認する」といった使い方ができません。他のAIエージェント系ツールでは、分析をダッシュボードやフォルダにピン留めし、特定の分析だけを更新するといった操作ができますが、Snowflake Intelligenceの場合、毎日同じ質問をしたければ、その都度チャットに戻って最新データで再実行するよう依頼する必要があります。定期レポートの運用としては、お世辞にも快適なUXとは言えません。

Cortex Agents、ひいてはSnowflake Intelligence自体には、基盤となるCortex SearchおよびCortex Analystの利用料以外に独自のコストはありません。それぞれのトピックは詳細記事にまとめていますので、以下にリンクします。ここでは各コストコンポーネントを簡潔に整理しておきましょう。

Cortex Analystのコスト

Cortex Analystは、構造化データや半構造化データへのクエリを伴う質問を処理します。これがtext-to-SQLにかかるAIコストです。Cortex Analystが生成したSQLを実行する際には別途ウェアハウスのコストが発生します。AIサービス側の課金はトークン単位ではなくリクエスト単位で、Snowflake Service Consumption Tableによると、Cortex Analystは多くのモデルで100リクエストあたり6.7クレジットを消費します。

Cortex Searchのコスト(非構造化データ向け)

Cortex Searchは、非構造化データに対するチャットでの問い合わせを処理します。検索サービスはインデックス作成時と検索時の両方でクレジットを消費し、現時点では1時間あたり8クレジットです。

Cortex SearchおよびCortex Analystの記事では、それぞれの監視方法をより詳しく解説しています。Intelligenceのコストは複数のサービスタイプにまたがって発生するため、全体を捉えるには包括的なクエリが必要です。記事末尾には、Snowflake Intelligenceで使われるすべてのサービスをまとめて監視できるクエリも紹介しているので、ぜひチェックしてみてください。

Cortex Analystの利用状況を追跡する

誰がCortex Analystを最も使っているか、生成されたクエリをどのウェアハウスが実行しているかを把握できます。

-- Daily Cortex Analyst requests and costs
SELECT
  DATE_TRUNC('day', start_time) AS usage_date,
  SUM(request_count) AS total_requests,
  SUM(credits) AS analyst_credits,
  username
FROM snowflake.account_usage.cortex_analyst_usage_history
WHERE start_time >= DATEADD(day, -30, CURRENT_DATE())
GROUP BY DATE_TRUNC('day', start_time), username
ORDER BY usage_date DESC, analyst_credits DESC;

AIサービス全体のコストを追跡する

Cortex Search、Document AI、AISQL関数など、AI関連のコストをまとめて把握できるクエリです。

-- AI Services consumption by service type
SELECT
  DATE_TRUNC('day', usage_date) as day,
  service_type,
  SUM(credits_used) as credits
FROM snowflake.account_usage.metering_daily_history
WHERE service_type = 'AI_SERVICES'
  AND usage_date >= DATEADD(day, -30, CURRENT_DATE())
GROUP BY DATE_TRUNC('day', usage_date), service_type
ORDER BY day DESC, credits DESC;

Intelligenceクエリのウェアハウスコストを監視する

残念ながら、エージェントが生成したクエリをピンポイントで特定する手段は用意されていません。ウェアハウスやロールでのフィルタは可能ですが、これらのクエリIDだけを抽出できる専用のログはないのが現状です。以下はウェアハウスでフィルタする例です。どうやってエージェント由来のクエリを識別するかを事前に決め、それに合わせて環境を整えておくとよいでしょう。

-- Warehouse consumption from Intelligence agent queries
-- Requires naming or tagging your Intelligence warehouses
SELECT
  DATE_TRUNC('day', start_time) as usage_date,
  warehouse_name,
  SUM(credits_used_compute) as compute_credits,
  SUM(credits_used_cloud_services) as cloud_credits,
  SUM(credits_used) as total_credits,
FROM snowflake.account_usage.warehouse_metering_history
WHERE warehouse_name IN (
  'INTELLIGENCE_WAREHOUSE',
  'ANALYST_WAREHOUSE',
  'SEARCH_WAREHOUSE'
)
  AND start_time >= DATEADD(day, -30, CURRENT_DATE())

コードを展開

Cortex Searchの動作を追跡する

-- Cortex Search service usage
SELECT
  DATE_TRUNC('day', start_time) AS usage_date,
  service_name,
  database_name,
  schema_name,
  SUM(credits) AS search_credits,
  SUM(credits) * 2 AS cost_usd
FROM snowflake.account_usage.cortex_search_serving_usage_history
WHERE start_time >= DATEADD(day, -30, CURRENT_DATE())
GROUP BY DATE_TRUNC('day', start_time), service_name, database_name, schema_name
ORDER BY usage_date DESC, search_credits DESC;

Intelligenceコストの統合ビュー

このクエリではコンポーネント別にIntelligenceのコストを分解できるため、コストを押し上げているのがクエリ件数なのか、検索処理なのか、ウェアハウスのコンピュートなのかを見極められます。

-- Complete Intelligence cost rollup
WITH analyst_costs AS (
  SELECT
    DATE_TRUNC('day', start_time) AS day,
    'Cortex Analyst (AI requests)' AS component,
    SUM(credits) AS credits
  FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_ANALYST_USAGE_HISTORY
  WHERE start_time >= DATEADD(day, -30, CURRENT_DATE())
  GROUP BY 1
),
search_costs AS (
  SELECT
    usage_date AS day,
    'Cortex Search (Serving + Indexing)' AS component,
    SUM(credits) AS credits

コードを展開

Snowsightで個別のセマンティックビューを監視する

Snowsight UIでAI ML → Cortex Analyst → Semantic Views → Monitoringへ進むと、個々のセマンティックビューの利用状況を確認できます。

ダッシュボードだけでなくアラートも設定する

先ほどの監視クエリも、誰も実行しなければ意味がありません。Snowflakeで監視したい指標があれば、SQLをスケジュールタスクとNotification Integrationで組み合わせ、SlackやTeamsへアラートを飛ばすカスタムモニターを作成できます。もっと手軽に監視を始めたい方は、SELECTのモニター機能もぜひご覧ください。

Intelligenceのワークロードに合わせてウェアハウスをライトサイジングする

先述の料金はtext-to-SQLのAIコストをカバーするものです。Cortex Analystが生成したSQLを実行する際には、別途ウェアハウスのコストが発生します。Analystクエリ用にはまずX-SmallまたはSmallのウェアハウスから始めるのがおすすめです。SQLの生成自体は安価ですが、過大なウェアハウスを使うと実行コストが一気に跳ね上がります。

セマンティックビューを戦略的に設計する

セマンティックビューの設計が雑だと、エージェントは遅く高コストになります。次の原則を意識しましょう。

狭く始め、段階的に広げる。最初は主要なテーブル3〜5個と頻出の質問に絞りましょう。スコープを適切に絞ったセマンティックファイルは、結果の精度と正確性を高めます。テーブルはあとからいくらでも追加できます。

検証済みクエリリポジトリを追加する。これは検証済みSQLとセットになった例示質問で、精度を大きく引き上げます。ユーザーが似た質問をしたとき、Cortex Analystがこれらの例を参照できるようになります。

verified_queries:
  - name: "total revenue last quarter"
    question: "What was total revenue in Q4?"
    sql: |
      SELECT SUM(revenue_amount)
      FROM fact_sales
      WHERE sale_date >= '2024-10-01'
        AND sale_date < '2025-01-01'
    verified_result: 1250000.00

分かりやすい名前と同義語を整える。テーブル名がdim_product_category_masterであっても、ビジネスサイドに馴染みのある名前で定義しておきましょう。

dimensions:
  - name: product_category
    synonyms: ["category", "product type", "product class"]
    description: "High-level product grouping (Electronics, Clothing, etc.)"

ユーザーやロール単位の利用クォータを設ける

Snowflake Intelligenceにはユーザー単位のクォータ機能は組み込まれていませんが、エージェントが利用するウェアハウスにリソースモニターを設定することで実質的に同等の制御を実現できます。

-- Create a resource monitor for Intelligence usage
CREATE RESOURCE MONITOR intelligence_monthly_quota
  WITH CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 75 PERCENT DO NOTIFY
    ON 90 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

-- Assign to Intelligence warehouses
ALTER WAREHOUSE intelligence_warehouse
  SET RESOURCE_MONITOR = intelligence_monthly_quota;

Cortex Searchサービスを最適化する

検索コストはサービスの設定次第で大きく変わります。次のポイントを押さえましょう。

適切なtarget lagを設定する。ドキュメントの更新頻度が低いなら、更新間隔を長めにとります。

-- For static documentation
CREATE CORTEX SEARCH SERVICE product_docs_search
  ON document_text
  TARGET_LAG = '24 hours'  -- Instead of default 1 hour
  ...

可能な限り検索対象を絞り込む。エージェントが直近のドキュメントしか必要としないなら、フィルタを追加しましょう。

CREATE CORTEX SEARCH SERVICE support_tickets_search
  ON ticket_text
  ATTRIBUTES customer_id, ticket_date, severity
  WHERE ticket_date >= DATEADD(year, -1, CURRENT_DATE())
  ...

Snowflake Intelligenceは、自然言語を介して非エンジニアでも企業データにアクセスできるようにし、構造化データと非構造化データをシームレスに横断します。コストを抑える鍵は、SQL生成を担うCortex Analyst、クエリを実行する仮想ウェアハウス、非構造化データを扱うCortex Search、そしてそれらを束ねるLLMオーケストレーションという各コンポーネントを理解することです。

まずは最も重要な指標に絞ったセマンティックビューから小さく始め、利用状況をきめ細かく監視しながら、コストの動きを掴んだ段階で少しずつ広げていきましょう。何より大切なのは、コストが請求書に跳ね返る前に検知できるよう、監視クエリにアラートを仕込んでおくことです。

Snowflake Intelligenceをどんなふうに活用されているか、ぜひ教えてください。どんなユースケースでコストに見合う価値が出たか、どこで最大のROIを実感できたか、現場のリアルな声をお待ちしています。

Jeffは、インサイトの自動化やデータを活用したビジネスプロセス制御に15年以上携わってきたデータ&アナリティクスコンサルタントです。技術面ではSnowflake + dbt + Tableauを得意とし、業務領域では公益事業、臨床試験、出版、CPG、製造業の経験があります。お気軽にご連絡ください:[email protected]