Snowflake Cortex Search:AIを活用した次世代エンタープライズ検索

■ Snowflake Cortex Searchとは何か?
Snowflake Cortex Searchは、Snowflakeが提供する純正のエンタープライズサーチです。Snowflakeのテーブルに格納された社内文書、製品カタログ、顧客からの問い合わせ履歴といった多様なテキストデータを、人間が日常的に使う自然言語で検索するための検索エンジンを、安全で簡単に構築・運用することを可能にします。
Cortex Searchは、REST APIやPython APIを通じて外部アプリケーションと連携できるため、社内システムだけでなく、お客様が直接利用するECサイトやモバイルアプリ向けに、高度なセマンティック検索機能を実装することも可能です。
■ Snowflake Cortex Searchは、どのような人・状況に適しているのか?
Elasticsearch (OpenSearch) のような高機能なエンタープライズサーチを導入・運用したいが、そのためのインフラ構築や運用管理に課題を感じている方
従来の検索エンジン導入では、例えばAWS環境において、IAMによる権限設定、データ転送ジョブの設計と監視など、多岐にわたる社内調整が必要でした。
Snowflake Cortex Searchを利用すれば、データが既にSnowflakeに格納されている場合、これらのインフラ関連の作業をSnowflakeプラットフォーム内で完結させることができます。Snowflakeのクレジット消費の範囲で利用を開始でき、インフラ管理のオーバーヘッドを大幅に削減します。
LLMを活用した、RAGチャットボットを構築したいが、その中核となる検索エンジンを手軽に用意したい方
Cortex Searchは、LLMとの連携を前提としたRAGの検索エンジンとして最適化されています。しかし、LLMの利用は必須ではありません。
純粋な高性能検索ソフトウェアとしても非常に強力であり、従来のキーワード検索では難しかった「あいまい検索」や「意味に基づいた検索」を、専門的なチューニングなしに簡単に実現できます。
■ Snowflake Cortex Searchのユースケース:アパレルECサイトにおける顧客体験向上
実際のSnowflake Cortex SearchのユースケースをアパレルECを例に解説します。
お客様がECサイトで商品を検索する際、必ずしも正確な商品名を知っているわけではありません。Cortex Searchは、そのような曖昧な表現による検索を強力にサポートし、お客様の「欲しいもの」との出会いを創出します。
例:お客様が「仕事で着られる きれいめ ブラウス」と検索した場合
従来のキーワード検索の場合:
「仕事」「きれいめ」「ブラウス」という全ての単語が、商品説明文などに一致している商品のみがヒットします。
「オフィスカジュアルに合うシャツ」や「通勤にも使えるトップス」といった、意味は近いものの表現が異なる商品は、検索結果から漏れてしまいます。
Cortex Searchの場合:
「仕事で着られる」 という検索の文脈を理解し、「オフィスカジュアル」「通勤スタイル」「ビジネスシーン向け」といった関連性の高い言葉を含む商品を自動的に候補として提示します。
「きれいめ」 というニュアンスから、「上品なデザインの」「きちんと感のある」「エレガントな印象の」といった意味を持つ商品も検索対象に含めます。
お客様が入力したキーワードと完全に一致しなくても、その意図に沿った商品を的確に提示できます。
Cortex Searchは言葉の表面的な一致だけでなく、その裏にある「意味」が近い商品に対して検索を行います。これは、特にアパレル業界のように、お客様が正確な商品名を覚えていない、あるいは感覚的な表現(例:「ちょっと羽織れるカーディガン」「肌触りの良いインナー」)で商品を探すことが多い場合に、非常に有効な機能となります。
■ Snowflake Cortex Search:導入から利用、更新までのスムーズな流れ
【準備】インテリジェントな検索基盤の構築
Step1:データソースの準備 – 検索対象となる知識の集約
検索対象となるデータを含むSnowflakeテーブルを用意します。これは、Cortex Searchが学習し、検索を行うためのデータソースとなります。
例えば、商品検索システムを構築する場合、商品名、商品説明文、商品の特徴(例:「UVカット」「吸汗速乾」)、カテゴリ、色、素材、顧客レビューといったリッチな情報を含む「商品マスタテーブル」がこれに該当します。
このテーブルには、検索対象のテキスト情報だけでなく、検索結果に表示したい付加情報(例:価格、在庫状況)や、検索結果を絞り込むための属性情報(例:サイズ、ブランド)も含めておくと、より高度で使いやすい検索が実現できます。
重要なポイント: 対象テーブルの「Change Tracking」機能を有効化しておく必要があります。これにより、元データが更新された際に、Cortex Searchのインデックスも差分から再構築され、常に最新の情報に基づいた検索が可能になります。
Step2:Cortex Searchサービスの作成 – AIによるインデックス自動構築
SQLコマンド (CREATE CORTEX SEARCH SERVICE) またはSnowflakeのGUIであるSnowsightの「AI & ML Studio」を通じて、Cortex Searchサービスを作成します。
この際、以下の主要な情報を指定します。
検索対象列: どの列のテキストデータを検索の主対象とするか(例:商品説明文)。
属性列: 検索結果に含めたり、フィルタリング条件として使用したりする列(例:カテゴリ、価格帯)。
埋め込みモデル: テキストをその「意味」を表す数値ベクトルに変換するためのAIモデルを選択します(日本語を含む多言語に対応したモデルも利用可能です)。
データソースクエリ: 実際にインデックスを作成する元となるデータを定義するSELECT文。ここで、必要な列を選択したり、簡単なデータ加工を行うこともできます。
このサービス作成プロセスの中で、Snowflakeはバックグラウンドで、指定されたテキストデータを自動的にベクトル化し、高速かつ高精度な検索を実現するためのハイブリッドインデックスを構築します。
Step3:インデックス構築完了とサービス利用開始 – すぐに使える検索API
インデックスの構築が完了すると、Cortex Searchサービスは検索クエリを受け付けられる状態になります。初期のインデックス構築時間はデータ量に依存しますが、一度構築されれば、すぐに利用を開始できます。【利用】アプリケーションへの検索機能の組み込みと活用
Step1:検索クエリの実行 – 多様なインターフェースからのアクセス
作成したCortex Searchサービスに対して、実際に検索リクエストを送信します。これは、ECサイトの検索バー、社内ポータルサイト、業務アプリケーションなど、様々なフロントエンドから行うことができます。
連携方法としては、主に以下の選択肢があります。
Snowflake Python API: Pythonで開発されたアプリケーションとのシームレスな連携に最適です。
REST API: Web標準のAPIであるため、様々なプログラミング言語や既存システムから柔軟に連携することが可能です。
SQLプレビュー関数 (SNOWFLAKE.CORTEX.SEARCH_PREVIEW): Snowflakeのワークシートなど、SQL環境から直接、手軽に検索サービスの動作確認やテストを行うことができます。
検索リクエストには、ユーザーが入力した検索キーワード、検索結果として返してほしい列の情報、検索結果を絞り込むための条件、表示件数などを柔軟に指定できます。
Cortex Searchの内部では、入力された検索キーワードも指定された埋め込みモデルによってベクトル化され、インデックス内のデータと意味的な類似度で比較されます。
Step2:検索結果の取得と表示 – ユーザーへの価値提供
Cortex Searchは、検索クエリとの関連性が高い順にソートされた検索結果を返却します。アプリケーションは、この結果(JSON形式など)を受け取り、ユーザーインターフェース上に分かりやすく表示します。例えば、商品画像、商品名、価格、関連スコアなどを表示することが考えられます。
【更新】データを最新に保つ方法
Step:データの自動更新とインデックスのインクリメンタルな再構築
検索対象の元テーブル(例:商品マスタテーブル)のデータが追加、更新、または削除されると、Snowflakeの変更追跡機能がこれらの変更を自動的に検知します。
Cortex Searchサービスは、サービス作成時に設定されたTARGET_LAG(目標遅延時間:例「1時間」「1日」)に基づき、定期的にこれらの変更を検知し、検索インデックスに反映します。
この更新処理は、変更があった部分のみを対象とする差分更新で行われるため、効率的かつ迅速にデータの鮮度を保つことができます。これにより、ユーザーは常に最新の情報に基づいた検索結果を得ることが可能になります。
ケーススタディ:アパレルEC
アパレル商品を題材に 手元のSnowflakeだけで動く検索エンジン を具体的に作ってみます。
1. 準備 ― 商品メタデータを用意
以下のような商品マスタがあると仮定します(例:retail_demo_db.products.apparel)。このテーブルのカラムを分類します。検索文脈を伝える検索対象列と絞り込み用の属性列です。
列 |
役割 |
サンプル |
product_id |
主キー |
PRD001 |
product_name |
商品名 |
ベーシックTシャツ |
description |
商品説明 (検索対象) |
柔らかい白色コットン生地のクルーネックTシャツ。ホワイトカラーで着回し自在。 |
category, subcategory |
カテゴリ階層 |
トップス, Tシャツ |
color, size |
属性列 |
白, M |
price |
価格 |
1,990 |
material |
素材 |
コットン100% |
gender |
想定性別 |
ユニセックス |
inventory |
在庫数 |
120 |
以下は、今回 retail_demo_db.products.apparel テーブルに格納されている商品メタデータの一部を表示したものです。
2. 構築 ― SQLでハイブリッドインデックスを生成
インデックス作成は たった 1 本の CREATE CORTEX SEARCH SERVICE 文 で完了します。
Snowflakeが裏側でベクトル化・インデックス構築・スケジューリングをすべて自動化してくれるため、運用負荷は抑えることができます。以下はインデックス作成の例となります。
CREATE OR REPLACE CORTEX SEARCH SERVICE retail_demo_db.products.apparel_search_service
ON description -- 検索主対象
ATTRIBUTES color, size, category -- フィルタ用属性
WAREHOUSE = retail_search_wh -- インデックス作成実行WH
TARGET_LAG = '1 hour' -- 目標遅延時間
EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0' -- 埋め込みモデル
AS
SELECT
product_id, product_name, description,
category, subcategory, color, size,
price, material, gender, inventory
FROM retail_demo_db.products.apparel;
上記ステートメントで指定した各パラメーターの役割は次のとおりです。
パラメータ |
説明 |
補足 |
ON |
検索対象列 |
- |
ATTRIBUTES |
属性列 |
WHERE 句で利用 |
TARGET_LAG |
目標遅延時間 |
例:'1 hour' で 1 時間以内に差分同期 |
EMBEDDING_MODEL |
埋め込みモデル |
品質・料金・リージョンで選択 |
WAREHOUSE |
インデックス作成用仮想 WH |
処理負荷に応じサイズ調整 |
※EMBEDDING列は、512トークンを超えないよう気をつけてください。512トークンを超えると最初の512トークンだけがSemantic検索に引っかかり、それ以降の文字はキーワード検索でのみヒットするようになります。お客様からのお問い合わせの文章など512トークンを超える場合は、SPLIT_TEXT_RECURSIVE_CHARACTER 関数を用いた分割後のベクトル化が一般的です。
3. 利用 ― SQLを使ったプレビュー
Snowflake には SNOWFLAKE.CORTEX.SEARCH_PREVIEW() 関数 が用意されており、
作成した Cortex Search Service を 本番アプリを組む前に 手早く検証できます。
以下の例では「雨の日におすすめの服」というクエリを投げ、関連度の高い上位 5 件を取得しています。
WITH search AS (
SELECT PARSE_JSON(
SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
'retail_demo_db.products.apparel_search_service',
$${
"query": "雨の日におすすめの服",
"columns": ["product_id","product_name","description",
"category","subcategory","color","price"],
"limit": 5
}$$
)
) AS payload
)
SELECT
f.value:product_id::STRING AS product_id,
f.value:product_name::STRING AS product_name,
f.value:description::STRING AS description,
f.value:category::STRING AS category,
f.value:subcategory::STRING AS subcategory,
f.value:color::STRING AS color,
f.value:price::NUMBER AS price
FROM search,
LATERAL FLATTEN(input => payload['results']) f;
以下は上記のクエリを実行した結果です。
“雨”という単語がなくても 意味的に近い 「ロングダウンコート」や「防風パーカー」などが上位に検索されており、完全一致検索との違いが確認できます。
この手順で検索品質を確認し、パラメータ(EMBEDDING_MODEL や TARGET_LAG)を調整したら、
次の「4.UI化 - Streamlit in Snowflake で会話型検索アプリの作成」へ移行することができます。
4. UI 化 ― Streamlit in Snowflake で会話型検索アプリの作成
Snowflake にはStreamlitランタイムが組み込まれているため、先ほどの検索サービスをバックエンドに据えた“会話型検索 UI”もコード 100行程度で完成します。
下記のスクリーンショットは、今回作成したデモアプリの画面です。
クエリ例:「暑い夏におすすめの服」
入力直後に検索ワードが吹き出しで表示され、続いてテーブル形式の検索結果が返却されます。
リネンシャツや速乾Tシャツなど、説明に “夏” が無くても “通気性” や “涼感素材” といった意味でマッチした商品を表示することができました。
これにより、SQLベースの検索構築から検索結果のプレビュー、さらには会話型UIによるユーザー体験までをスムーズに接続でき、PoCから実運用に向けたアプリケーション展開までを手軽に実現できます。
■ コストについて
Snowflake Cortex Searchのコストは、主に「① 初期構築コスト」と「② 月次運用コスト」の2つに分かれます。
これらは、Snowflakeの通常の仮想ウェアハウスやストレージの利用料とは別にかかる、Cortex Search専用のコストです。
1. 初期構築コスト:インデックス作成 (EMBED_TEXT)
これは、検索対象のテキストデータをAIが理解できるベクトル形式に変換(Embedding)するためのコストです。サービスの初回作成時に全データに対して発生し、その後はデータが追加・更新されるたびに、その差分に対して発生します。
- 課金単位: 100万トークンあたりのクレジット
- モデル別料金:
- snowflake-arctic-embed-m-v1.5: 0.03 クレジット / 100万トークン
- snowflake-arctic-embed-l-v2.0: 0.05 クレジット / 100万トークン
- voyage-multilingual-2: 0.07 クレジット / 100万トークン
【料金シミュレーション①:初期インデックス作成】
条件計算式
- 行数: 1,000万行
- 1行あたりの平均トークン数: 500
- 使用モデル: snowflake-arctic-embed-l-v2.0
- 10,000,000行 × 500トークン/行 ÷ 1,000,000 × 0.05クレジット = 250 クレジット
実際の金額(AWS 東京リージョン, Enterprise Editionの場合)
- 250 クレジット × $4.30 ≒ $1,075
- 145円/$ × $1,075 = 155,875円
2. 月次運用コスト:サービス維持 (Serving Compute)
これは、作成した検索インデックスをホスティングし、いつでも検索できるようにサービスを維持するためのコストです。サービスが有効である限り、継続的に発生します。
- 課金単位: インデックスのデータサイズ (GB) と時間 (月)
- 料金: 6.3 クレジット / GB・月
【料金シミュレーション②:月次運用コスト】
条件
インデックスの総データ量: 50 GB計算式
50 GB × 6.3 クレジット = 315 クレジット / 月
実際の金額(AWS 東京リージョン, Enterprise Editionの場合)
- 315 クレジット × $4.30 ≒ $1,354
- 145円/$ × $1,354 = 196,330円
※1クレジットあたりの費用は2025年6月時点のものです
※為替レートは2025年6月時点のレートを簡素化しています。
■ まとめ:AI検索はもっと手軽になる。Snowflake Cortex Searchが拓く未来
従来のエンタープライズ検索導入は、インフラ構築や専門的なチューニングなど、多くのハードルがありました。Snowflake Cortex Searchは、こうした課題を解決し、データが既にあるSnowflake上で、SQLを数行書くだけで高精度なAI検索エンジンを構築できる、まさに次世代のソリューションです。
本記事でご紹介したように、Cortex Searchを導入することで、以下のようなメリットがあります。
- インフラ管理からの解放: 面倒なサーバー設定やデータ転送ジョブの管理は不要。Snowflakeのセキュアな環境で完結します。
- SQLだけでAI検索を実現: Elasticsearchやベクトルデータベースの専門知識がなくても、セマンティック検索やあいまい検索を簡単に実装できます。
- 多様なユースケースへの対応: 社内ナレッジ検索から、顧客向けECサイトの高度な商品検索、RAGチャットボットの構築まで、API連携で柔軟に活用可能です。
- 明確で始めやすいコスト: Snowflakeのクレジット消費で利用を開始でき、スモールスタートにも最適です。
「社内に眠る膨大なドキュメントを有効活用したい」「お客様が本当に欲しいものを見つけられる検索機能で、売上を向上させたい」「話題の生成AIを、PoCから素早く本番導入につなげたい」
このような課題をお持ちでしたら、Snowflake Cortex Searchは最適な解決策となり得ます。アジアクエストは、クラウド基盤における豊富なAI活用のノウハウを活かし、お客様のデータ活用を強力にサポートします。
Cortex Searchの導入に関するご相談や、自社のデータでどのようなことが実現できるか、まずはお気軽にお問い合わせください。
Snowflakeを活用したデータ基盤構築サービスについて、さらに詳しく知りたい方は、こちらのページをぜひご覧ください。
付録
Snowflake Cortex Search が利用可能なリージョン
AWS
Region |
snowflake-arctic-embed-m-v1.5 |
snowflake-arctic-embed-l-v2.0 |
voyage-multilingual-2 |
US West 2(Oregon) |
✔ |
✔ |
✔ |
US East 2(Ohio) |
✔ |
✔ |
|
US East 1(N. Virginia) |
✔ |
✔ |
✔ |
Canada(Central) |
✔ |
✔ |
|
South America(São Paulo) |
✔ |
✔ |
|
Europe(Ireland) |
✔ |
✔ |
|
Europe (London) |
✔ |
✔ |
|
Europe Central 1(Frankfurt) |
✔ |
✔ |
✔ |
Europe(Stockholm) |
✔ |
✔ |
|
Asia Pacific(Tokyo) |
✔ |
✔ |
✔ |
Asia Pacific(Mumbai) |
✔ |
✔ |
|
Asia Pacific(Sydney) |
✔ |
✔ |
|
Asia Pacific(Jakarta) |
✔ |
✔ |
|
Asia Pacific(Seoul) |
✔ |
✔ |
Azure
Region |
snowflake-arctic-embed-m-v1.5 |
snowflake-arctic-embed-l-v2.0 |
voyage-multilingual-2 |
East US 2(Virginia) |
✔ |
✔ |
|
West US 2(Washington) |
✔ |
✔ |
|
South Central US(Texas) |
✔ |
✔ |
|
UK South(London) |
✔ |
✔ |
|
North Europe(Ireland) |
✔ |
✔ |
|
West Europe(Netherlands) |
✔ |
✔ |
✔ |
Switzerland North(Zürich) |
✔ |
✔ |
|
Central India(Pune) |
✔ |
✔ |
|
Japan East(Tokyo, Saitama) |
✔ |
✔ |
|
Southeast Asia(Singapore) |
✔ |
✔ |
|
Australia East(New South Wales) |
✔ |
✔ |
GCP
Region |
snowflake-arctic-embed-m-v1.5 |
snowflake-arctic-embed-l-v2.0 |
voyage-multilingual-2 |
Europe West 2 (London) |
✔ |
✔ |
|
Europe West 3 (Frankfurt) |
✔ |
✔ |
|
Europe West 4 (Netherlands) |
✔ |
✔ |
|
Middle East Central 2 (Dammam) |
✔ |
✔ |
|
US Central 1 (Iowa) |
✔ |
✔ |
|
US East 4 (N. Virginia) |
✔ |
✔ |