SELECT

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

By Jeff SkoldbergOct 9, 20257 min read

このページはEnglish、Deutsch、Español、Français、Italiano、Portuguêsでもご覧いただけます。

Snowflake Cortex Searchとは

SnowflakeのCortex Searchは、ベクトル検索・キーワード検索・セマンティック検索を組み合わせたフルマネージド型のハイブリッド検索サービスです。RAG(Retrieval Augmented Generation)アプリケーションやエンタープライズ検索の構築を想定して設計されており、埋め込み生成・インデックス作成・サービング基盤はすべてSnowflake側で自動的に処理されます。キーワードの一致だけを見る従来型の検索とは違い、Cortex Searchは検索クエリの意味をテキストデータと照らし合わせて検索します。たとえばカスタマーサポートのデータベースで「請求に関する問題」と検索すれば、その文言が本文に含まれているかどうかに関わらず、請求関連のチケットをまとめて取得できます。

当社のお客様もCortex Searchを幅広くご利用いただいていますが、最もよく寄せられる質問のひとつが「実際にいくらかかっているのかをどう把握すればよいか」というものです。

Cortex Searchが厄介なのは、コスト構造が従来のSnowflakeサービスよりも複雑な点です。起動・停止が単純なウェアハウスとは違い、Cortex Searchでは複数のコスト要素が同時並行で発生します。きちんと監視していないと、想定外に高額な請求を目にすることになりかねません。

それでは、まずCortex Searchの仕組みを押さえたうえで、課金要素と監視方法を見ていきましょう。

Cortex Searchの仕組み

Cortex Searchは内部的に、ベクトル検索(SnowflakeのArctic Embedモデルを利用)、キーワード検索、セマンティックリランキングを組み合わせたハイブリッド方式を採用し、関連性の高い結果を返します。サービスを作成すると、Snowflakeが埋め込み生成・インデックス作成・サービング基盤を自動で構築し、ソースデータを低レイテンシ配信に適した形に変換します。

カスタマーサポートのチケットを対象に、Cortex Searchをセットアップして利用する例を示します。

-- 1. Create sample data table
CREATE OR REPLACE TABLE support_transcripts (
    transcript_text VARCHAR,
    region VARCHAR,
    agent_id VARCHAR
);

INSERT INTO support_transcripts VALUES
    ('My internet has been down since yesterday, can you help?', 'North America', 'AG1001'),
    ('I was overcharged for my last bill, need an explanation.', 'Europe', 'AG1002'),
    ('How do I reset my password? The email link is not working.', 'Asia', 'AG1003'),
    ('I received a faulty router, can I get it replaced?', 'North America', 'AG1004');

-- 2. Create the Cortex Search service
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service

コードを展開

このとおり、AIに「Billing problems」の意味を解釈させ、該当する行を返しています。

SEARCH_PREVIEW関数は、ヒットごとの関連性スコアを含むJSON結果を返します。PARSE_JSONとFLATTENを組み合わせれば、どのトランスクリプトがクエリと最も関連性が高いかを、メタデータや信頼度スコアとあわせて整形済みのテーブル形式で取得できます。これにより、検索結果をアプリケーションや後続のSQL分析に容易に組み込めます。

地域や期間といったメタデータ列を使ったフィルタリングも可能で、意味的な理解と構造化フィルタの両方が必要なシーンに最適です。

-- Filter results by region
SELECT SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
    'transcript_search_service',
    '{
        "query": "password reset problems",
        "columns": ["transcript_text", "region", "agent_id"],
        "filter": {"@eq": {"region": "Asia"}},
        "limit": 10
    }'
);

Cortex Searchの料金体系

Cortex Searchの料金は、次の5つの要素で構成されます。

サービング用コンピュート:インデックス済みデータ1GBあたり月6.3クレジット(クエリの有無に関係なく常時稼働)
埋め込みトークン:インデックス作成時に検索対象列のテキストを処理する際の、100万トークンあたりのコスト。料金はモデルによって異なります。各モデルの単価はSnowflake Credit Consumption Tableを参照してください。2025年9月時点の例:
snowflake-arctic-embed-l-v2.0:100万トークンあたり0.05クレジット。SnowflakeのAIサービスのなかでも最も安価な処理のひとつです。
ウェアハウス用コンピュート:検索データのマテリアライズ・リフレッシュ・クエリ実行にかかる標準のウェアハウス料金
ストレージ:検索インデックスには標準のストレージ料金が適用されます(例:$23/TB/月)
クラウドサービス:通常は無料(日次ウェアハウス使用量の10%を超えた場合のみ課金)

具体例:カスタマーサポートチケット1,000万件、1件あたり平均500トークン、100万トークンあたり0.32クレジットの埋め込みモデルを使用するケース。

合計トークン数:1,000万行 × 500トークン = 50億トークン
埋め込みコスト:50億トークン ÷ 100万 × 0.05クレジット = 初期インデックス作成で250クレジット
- 1クレジット$3換算で$750
さらに継続的なサービングコスト:インデックスが50GBの場合、50 × 6.3 = 稼働を維持するだけで月315クレジット
- 1クレジット$3換算で$945

停止できるウェアハウスとは違い、Cortex Searchのサービングコストは止まることなく発生し続けます。100GBのインデックスは、クエリ量にかかわらず月630クレジット(1クレジット$3換算で約$1,890)。誰も検索していなくても、この費用はかかります。

Cortex Searchのコストと利用状況を監視する方法

Snowflakeは、Cortex Searchのコスト追跡用にACCOUNT_USAGEスキーマ内に2つの専用ビューを用意しています。CORTEX_SEARCH_DAILY_USAGE_HISTORYビューでは日次のコストを消費タイプ別(サービング・埋め込み)に確認でき、CORTEX_SEARCH_SERVING_USAGE_HISTORYでは時間単位のサービングクレジットを参照して利用パターンを把握できます。

日次の例:

-- Daily usage including serving and embedding costs
SELECT
    USAGE_DATE,
    DATABASE_NAME,
    SCHEMA_NAME,
    SERVICE_NAME,
    CONSUMPTION_TYPE,
    CREDITS,
    MODEL_NAME,
    TOKENS
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_SEARCH_DAILY_USAGE_HISTORY
WHERE USAGE_DATE >= CURRENT_DATE - 30
ORDER BY USAGE_DATE DESC, SERVICE_NAME, CONSUMPTION_TYPE;

注目すべき出力項目はconsuption_typeで、値はembed_text_tokensまたはservingのいずれかになります。

時間単位の例:

-- Hourly serving credit consumption
SELECT
    START_TIME,
    DATABASE_NAME,
    SCHEMA_NAME,
    SERVICE_NAME,
    CREDITS as hourly_serving_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_SEARCH_SERVING_USAGE_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY START_TIME DESC, SERVICE_NAME;

ご覧のとおり、これは時間別にクレジットを集計しただけの非常にシンプルな例です。

Cortex Search活用のベストプラクティスと推奨事項

これまで多くのチームでCortex Searchのコスト監視導入を支援してきた経験から、特に押さえておきたいポイントを紹介します。

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

上記の監視クエリも、誰も実行しなければ意味がありません。Snowflakeで監視したい対象は、SQLをスケジュールタスクで包み、Notification Integrationと組み合わせることで、SlackやTeamsへアラートを送るカスタム監視を構築できます。より手軽に監視機能を導入したい場合は、SELECTのmonitorsもぜひご検討ください。

開発中はサービスを停止する

自動停止できるウェアハウスとは異なり、Cortex Searchサービスは24時間365日サービングコストが発生します。開発やテスト中で使っていない時間帯は、検索サービスを停止しましょう。再開は数分で済みますが、継続的に発生するサービング料金はすぐに積み上がります。

インデックスのサイズは慎重に設計する

検索サービスに含めるすべての列は、検索対象であっても属性であっても、サービングコストを押し上げます。「念のため」で列を追加するのは避けましょう。最小構成から始め、必要になった時点で列を追加するのが鉄則です。10GBと100GBではインデックスのコスト差はかなり大きくなります。

埋め込みモデルのコストは個別に監視する

日次使用状況ビューのCONSUMPTION_TYPE列を確認し、サービングと埋め込みのコストを切り分けて把握しましょう。埋め込みコストの急増は、非効率なリフレッシュパターンや不要なフルリビルドの兆候であることが少なくありません。埋め込みコストが恒常的に高い場合は、データ更新パターンを見直してみてください。

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

検索コストは、サービスの設定次第で大きく変わります。以下のガイドラインを参考にしてください。

適切なターゲットラグを設定する。ドキュメントの更新頻度が低い場合は、リフレッシュ間隔を長めに設定しましょう。

-- 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())
  ...

増分更新には主キーを使う

データが頻繁に変わる場合は、検索サービスに主キーを定義しましょう。最適化されたリフレッシュ経路が有効になり、埋め込みコストとリフレッシュ時間の両方を大幅に削減できます。主キーがないと、スキーマを変更するたびにデータセット全体が再埋め込みされてしまいます。

-- With primary key - only changed rows get re-embedded
CREATE OR REPLACE CORTEX SEARCH SERVICE support_tickets_search
    ON ticket_description
    PRIMARY KEY (ticket_id)  -- Must be TEXT data type
    ATTRIBUTES status, priority, created_date
    WAREHOUSE = search_wh
    TARGET_LAG = '1 hour'
    AS (
        SELECT ticket_id, ticket_description, status, priority, created_date
        FROM support_tickets
    );

まとめ

Snowflakeにおける他のコスト監視と同様に、Cortex Searchの支出もACCOUNT_USAGEスキーマで把握します。上記の監視クエリを出発点に、何を監視すべきかを見極めたうえで、アラートや週次レポートをスケジュール化しましょう。注意すべきはサービングクレジットの急増(クエリ量の増加)と、データリフレッシュ時の埋め込みコストです。

目指すべきは必ずしもコストの最小化ではなく、支出に見合った価値を引き出すこと。こうしたパターンを理解することで、パフォーマンスと予算の両方を最適化できます。

Cortex Searchの導入を進めている方は、ぜひお気軽にご連絡ください。皆さんのチームでうまくいっている監視方法もぜひ聞かせてください。

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