Cortex Analystとは
Cortex Analystは、Snowflakeが提供するフルマネージドのtext-to-SQLサービスです。ビジネスユーザーは自然言語で質問するだけで、クエリを1行も書かずにSQLベースの回答を得られます。利用方法は2通り。Snowflake Intelligence(Snowflakeに組み込まれたAIエージェントのインターフェース)から使う方法と、自社アプリケーション(StreamlitアプリやSlackボット、Microsoft Teams、独自のWebチャットUIなど、ユーザーが普段使うあらゆる業務ツール)に組み込めるREST API経由で使う方法です。基盤には大規模言語モデルが使われ、主にClaude Sonnet、Mistral Large、Llamaが採用されています。さらにセマンティックモデルを通じて、業務上のコンテキストを理解します。
本ガイドでは、Cortex Analystの使い方をひととおり押さえたうえで、コストの監視と制御の方法を解説します。
Cortex Analystの仕組み
Cortex Analystは、大規模言語モデルとセマンティックモデルを組み合わせ、自然言語の質問を正確なSQLクエリに変換します。セマンティックモデルは業務用語とデータベーススキーマの橋渡しを担い、LLMが正しいSQLを生成するために必要なコンテキストを与えます。
セマンティックモデルの作成
セマンティックモデルの作成方法は2通りあります。
- Snowsightのウィザードを使う:Snowsightで「AI & ML " Cortex Analyst」に進み、ガイド付きセットアップでセマンティックビューを作成します。テーブルの選択、ディメンションとメトリクスの定義、サンプル質問の追加までウィザードが順を追って案内してくれるため、最も手軽に始められます。
- YAMLファイルをステージにアップロードする:セマンティックモデルをコードとして管理したい場合は、セマンティックモデル仕様に沿ってYAMLファイルを作成し、Snowflakeのステージにアップロードします。
どちらの方法でもCortex Analystは動作します。ウィザード方式ではセマンティックビュー(スキーマレベルのオブジェクト)が作成され、YAML方式ではモデルファイルがステージに格納されます。
Cortex Analystを使う
セマンティックモデルの準備ができたら、ユーザーにアクセス権を付与します。
-- アクセスが必要なユーザーにCORTEX_USERロールを付与
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE analyst_role;
あとはアプリケーションから、自然言語の質問を添えてCortex Analyst APIを呼び出すだけです。
1import requests
2import json
3
4response = requests.post(
5 f"https://{account}.snowflakecomputing.com/api/v2/cortex/analyst/message",
6 headers={
7 "Authorization": f"Bearer {token}",
8 "Content-Type": "application/json"
9 },
10 json={
11 "messages": [{\
\
12 "role": "user",\
\
13 "content": [{\
\
14 "type": "text",\
\
15 "text": "前四半期の売上トップ5の製品は?"\
```\
\
Expand Code\
\
Cortex Analystはマルチターンの会話に対応しており、直前のクエリを踏まえたフォローアップ質問もできます。\
\
Snowflake IntelligenceからCortex Analystを利用する場合は、別途エージェントを作成する必要があります。詳しくは[こちら](/blog/snowflake-intelligence-overview-pricing-cost-monitoring)をご覧ください。\
\
Cortex Analystの料金体系\
Cortex Analystの課金はトークン単位ではなくメッセージ単位です。課金対象はHTTP 200が返った成功レスポンスのみで、メッセージのトークン数にかかわらずコストは一定です。Snowflake Service Consumption Tableによれば、1メッセージあたりのクレジット数は固定で、現時点では100メッセージあたり6.7クレジットです。
主なコスト要因は2つ。
\
- 自然言語クエリ1件=1メッセージ:「売上はいくら?」と聞けば、課金対象のメッセージが1件発生します。\
- 1クレジット3ドルとすると、10件の質問で2ドルです。あっという間に積み上がるように見えるかもしれませんが、得られる業務価値とのバランスで判断すべきです。目的は常にSnowflakeコストを最小化することではなく、ビジネス価値を最大化することにあります。\
- SQL実行に伴うウェアハウスコスト:メッセージ料金に含まれるのはAIによるtext-to-SQL生成の部分だけです。生成されたSQLを実行する際には、別途ウェアハウスのコンピュートコストが発生します。
\
Cortex Analystの使用状況を監視する方法\
Snowflakeは、Cortex Analystのコストを追跡するための主要なビューを提供しています。
CORTEX_ANALYST_USAGE_HISTORY:データは1時間単位で集計されるため、クエリIDは含まれません。
このビューでは、Cortex Analystのクレジット消費が1時間単位で集計されており、ユーザーごとのメッセージ数とクレジット消費量を確認できます。
\
1-- 過去30日間のCortex Analyst日次利用状況をユーザー別に確認\
\
2SELECT\
\
3 DATE_TRUNC('day', START_TIME) AS usage_date,\
\
4 USERNAME,\
\
5 SUM(REQUEST_COUNT) AS total_messages,\
\
6 SUM(CREDITS) AS total_credits\
\
7FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_ANALYST_USAGE_HISTORY\
\
8WHERE START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())\
\
9GROUP BY 1, 2\
\
10ORDER BY total_credits DESC;\
```\
\
このビューにはSTART\_TIME、END\_TIME、REQUEST\_COUNT(メッセージ数)、消費CREDITS、USERNAMEが含まれます。これにより、誰がCortex Analystのコストを生み出しているかをユーザー単位で把握できます。METERING\_HISTORYビューは`WHERE SERVICE_TYPE = 'AI_SERVICES'`でフィルタできますが、Cortex Analyst以外のコストも含まれる点に注意してください。\
\
### SQL実行に伴うウェアハウスコストを監視する\
\ここではいくつかの選択肢があります。専用のウェアハウス、ユーザー、ロールを用意する方法もあれば、Cortex Analystアプリから発行されたクエリにタグを付ける方法もあります。普段クエリの帰属管理に使っている手法をそのまま当てはめ、自社に合った方法を選んでください。\
\
Cortex Analyst活用のベストプラクティス\
\
ダッシュボードだけでなくアラートも設定する\
上記の監視クエリも、誰も実行しなければ意味がありません。Snowflakeで監視したい項目は、SQLをスケジュールタスクで包み、Notification Integrationと組み合わせれば、SlackやTeamsにアラートを送るカスタム監視を構築できます。もっと手軽な監視機能をお探しであれば、SELECTのモニター機能もぜひご検討ください。
\
ロールでアクセスを制御する\
デフォルトではCORTEX_USERロールがPUBLICロールに付与されているため、すべてのユーザーがアクセスできる状態になっています。全社一律のアクセスを避けたい場合は、PUBLICから権限を取り消し、特定のロールにのみ付与してください。
-- Cortex Analystの利用を特定チームに限定
USE ROLE ACCOUNTADMIN;
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE data_analysts;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE finance_team;
このちょっとした変更だけで、組織全体への無秩序な広がりを抑えられます。
\
セマンティックモデルを最適化する\
よく作り込まれたセマンティックモデルは、リトライや失敗クエリの発生を減らします。データベース全体をそのまま公開するのではなく、特定の業務領域に絞り込みましょう。よくある質問には検証済みクエリを用意しておくと精度が上がり、無駄なAPI呼び出しを減らしながらユーザー体験も向上します。
検証済みクエリのリポジトリを追加しましょう。これは、検証済みSQLとセットになった質問例で、精度を大きく引き上げます。ユーザーから類似の質問が来たとき、Cortex Analystはこれらの例を参照できます。
\
1verified_queries:\
\
2 - name: "total revenue last quarter"\
\
3 question: "What was total revenue in Q4?"\
\
4 sql: |\
\
5 SELECT SUM(revenue_amount)\
\
6 FROM fact_sales\
\
7 WHERE sale_date >= '2024-10-01'\
\
8 AND sale_date < '2025-01-01'\
\
9 verified_result: 1250000.00\
```\
\
**わかりやすい名前を付け、シノニムを追加しましょう。**テーブル名が`dim_product_category_master`のように分かりにくい場合は、業務側で通じる名前で定義します。\
\
```yaml\
1dimensions:\
\
2 - name: product_category\
\
3 synonyms: ["category", "product type", "product class"]\
\
4 description: "High-level product grouping (Electronics, Clothing, etc.)"\
```\
\
### ウェアハウスコストの帰属方法を決める\
\
前述のとおり、Cortex Analystが生成したSQLのコストをどう帰属させるかをあらかじめ決めておきましょう。専用ウェアハウスを使う方針もあれば、ロール単位で帰属させる方針もあります。\
\
### デフォルトのウェアハウスサイズは最小限に\
\
Cortex Analystのクエリの大半は比較的シンプルな集計です。XLサイズのウェアハウスはまず必要ありません。\
\
### ユーザーへの周知を徹底する\
\
最大のコスト調整レバーはユーザーの行動です。次の点を理解してもらえれば、\
\
- 10件の質問で数ドルのコストが発生する\
- 複雑な質問は何度かやり直しが必要になることがある\
- 漠然とした質問ほど大きなウェアハウスクエリを引き起こす\
\
…自然と慎重な使い方が身についていきます。コスト例や良い質問の作り方をまとめた社内ドキュメントを用意するのがおすすめです。\
\
まとめ\
Cortex Analystはデータ活用の民主化を一気に進める強力なツールですが、他のAIサービスと同様、放置するとコストが思わぬ形で膨らみかねません。
細かな粒度で追跡するならCORTEX_ANALYST_USAGE_HISTORYを活用し、ロールベースのアクセス制御を実装し、コスト効率の良い使い方をユーザーに伝えていきましょう。これらを徹底すれば、予算面の不安を抱えることなく、組織全体にCortex Analystを展開できます。
忘れてはならないのは、Cortex Analystの本当のROIは「SQLを書く手間が減ること」ではなく、「ビジネスユーザーがより早く答えにたどり着き、より良い意思決定ができるようになること」だという点です。チームを後押しするために多少のクレジットを使うことは、意思決定の遅れや分析リソースの誤配分による損失と比べれば、十分に価値ある投資です。
ぜひデータとの対話を楽しんでください。そしていつものように、Cortex Analystでの成功事例があればぜひお聞かせください!
Jeffは、インサイトの自動化とデータを活用した業務プロセスの制御において15年以上の経験を持つ、データ&アナリティクスコンサルタントです。技術面ではSnowflake + dbt + Tableauを得意とし、業界面では公益事業、臨床試験、出版、CPG、製造業に携わってきました。お気軽にご連絡ください。[email protected]。\