Snowflakeを導入している会社で「AIを活用したい」という話が出ると、たいてい現場とベンダーのあいだで宙に浮く問いが一つあります。

「で、結局いくらかかって、何が変わるのか」。

この問いに答えられないまま、ツールの名前——CortexだClaudeだ——から議論を始めると、決まって迷子になります。順番が逆だからです。先に決めるべきは「誰の、どの仕事を、AIに任せるか」。ツールは、それが決まれば自動的に決まります。

本コラムは、その決め方を1枚の地図にします。技術の話ではなく、役割分担の話です。

地図の結論を先に置きます。

社員のデータ分析は Cortex が担う。Claudeは"窓口"に座るのではなく、仕組みを組み立てる人を助け、複数システムをつなぐ橋渡しをする。機械学習は専門職が担う別の仕事だが、その予測結果は最終的に社員が日常使う分析画面に表示される。データはどの処理経路をたどってもSnowflakeの外に出ない。

この一行が腹落ちすれば、これから出てくるAIの話も、迷わず置き場所が決まります。

道は「3つの問い」で分かれる

AIの使いどころは、突き詰めると3つの問いに集約されます。これが地図の幹線道路です。

現場で出てくる問い任せる先担い手
社員が自分でデータを分析したい（SQLを書かずに）Cortex全社員
複数のシステムや文書をまたいで作業させたいClaude一部の人
予測や独自モデルをつくりたいCortex ML / ML Jobs専門職

※ Cortex ML（Cortex ML Functions）はSQLで使える予測・異常検知機能。ML JobsはPythonで書いたカスタムモデルをSnowflake上で実行できる機能。いずれもSnowflakeが提供するMLサービスで、データは外に出ない。

ポイントは、これが「Cortex対Claude」という製品の勝ち負けではないこと。論点は「Snowflakeの中で完結する仕事か、その外にはみ出す仕事か」です。実はClaudeのAIはCortexの内側でも動いています。だから問いは「Claudeを使うか否か」ではなく、「どの場所で動かすか」になります。

王道：社員が自分でデータを聞ける状態をつくる

意思決定者にとって一番わかりやすい成果はこれです。「経理部の誰もが、SQLもBIツールも触らず、ふつうの日本語で『先月の地域別売上は？』と聞けば、グラフで答えが返ってくる」。

この王道を担うのが Cortex です。仕組みはこうです。社員が日本語で質問すると、AIが裏でSQLに翻訳し、Snowflakeの中で実行し、答えを返す。このとき、会社のデータも質問文も、Snowflakeの外には一切出ません。 アクセス権限も普段のまま効くので、見ていい人しか見られない。

意思決定者目線でのうれしさは2つです。情報漏洩の最大の心配——「外部AIにデータが渡る」——が、そもそも発生しない。そして、データ部門に依頼を投げて何日も待つ、という渋滞がなくなる。

ただし、効果には前提が1つあります。「粗利」「離脱」といった自社固有の言葉を、AIが正しい計算に翻訳できるよう、言葉の定義を整える作業が要ります。ここが整っていないと、それっぽいが間違った数字が返ってきます。Cortexの精度は、ツールの良し悪しより、この下ごしらえで決まります。

この下ごしらえは、AIプロジェクトで最も軽視され、最もつまずく工程だ。詳しくは「AIが使えるデータ」とは何かも参照してほしい。

Cortex Analystをはじめ、Cortexでできることの全体像はSnowflake Cortexでできること――自然言語分析から機械学習までにまとめています。

Claudeの居場所：「窓口」ではなく「つくる人」と「橋渡し役」

ではClaudeはどこにいるのか。よくある誤解は「全社員のAI窓口にClaudeを座らせる」というものですが、実はこれは向いていません。Claudeの主役の場は別にあります。

つくる人。 上で触れたCortexの仕組みも、社員に届けるアプリも、言葉の定義の整備も、誰かが組み立てる必要があります。その組み立てを担うのがClaude（開発を助ける道具として）です。

橋渡し役。 Snowflakeのデータ＋社内ドライブの文書＋Slackの会話＋Webの情報——これらをまたいで一つの仕事を片づける。Snowflake1つで閉じない問いは、Claudeの独壇場です。

逆に言えば、毎日まわる定常的なデータ分析は、Cortexが回せばよく、その瞬間にClaudeを呼ぶ必要はありません。この「使わなくていい場面を見極められる」ことが、かえってAI活用の説得力になります。

なぜClaudeを「全社の分析窓口」にしないのか

意思決定者が判断するうえで、ここの線引きは知っておく価値があります。Claudeを分析窓口に据えようとすると、次の点で割に合いません。これは欠陥ではなく、それがCortexの担当領域だからです。

  • データが標準では社外に出る。 Claudeが読んだ内容はAnthropic側に渡ります。出さないためには自社クラウド内に閉じる特別な配備が要り、その分コストと制約が増えます。
  • 数字の一貫性が保ちにくい。 上で述べた「言葉の定義」が効かず、人によって違う数字が出かねない。
  • 全社配布のアプリではない。 個々のPCで動くアシスタントであって、中央で配って統制する分析基盤ではありません。

だから設計の定石はシンプルです。定常的な分析はCortexへ。橋渡しと"つくる"はClaudeへ。

DSBの見解：Claude Desktopは「考える道具」であり「データを読む道具」ではない

Claude Desktopの強みは、複数の情報源をまたいで文脈を理解し、判断や文章生成を助けることにあります。一方、業務分析に本質的に必要なのは「正確な数値を、権限通りに、一貫した定義で返す」ことです。

同じ質問を10人がしたとき、10人が同じ数字を見られるか——Claude Desktopは会話の微妙な違いで結果が変わりえます。Cortexはセマンティックモデルと呼ばれる定義ファイルに「粗利とはこの計算式」「離脱とはこの条件」をあらかじめ登録しておくことで、誰が聞いても同じ答えが返ってきます。経営判断に使う数字にブレは許されません。

ただし、このセマンティックモデルの整備は決して軽い作業ではありません。全社で使う指標の洗い出し、計算式のSQL化、部門間の定義の統一——「まず1部門・10指標」から始めても数週間から1か月程度かかります。Cortexの精度はツールの良し悪しより、この整備の質で決まります。だからこそ私たちは、導入の初期段階からこの工程に関わることを重視しています。

Claude Desktopは業務改革の文脈では強力な武器です。しかし「分析」というスコープに限れば、私たちはそれをCortexの仕事と位置づけています。

機械学習は「別の人たちの仕事」

「来月の需要予測」「異常検知」といった機械学習は、社員の日本語分析とは別のトラックで考えます。意思決定者が押さえるべきは中身ではなく、誰がやって、成果がどこに戻るかの2点だけです。

担い手は専門職です。軽い予測ならアナリストがSQLの範囲で（プログラミング不要で）できますし、本格的な独自モデルはデータサイエンティストがつくります。重い計算はSnowflakeが肩代わりするので、「うちのPCは非力だから」は理由になりません。

そして大事なのは、できた予測結果が、結局あの「社員が日本語で聞ける窓口」に戻ってくること。専門職がつくり、社員はそれを"見るだけ"。つくる工程は、やはりClaudeが手伝えます。

既にSageMakerなどのML基盤をお使いなら：モデルの中身や精度は基本的に変わらない。変わるのは"配管"——データを動かす手間と、統制が何箇所に分散するか——だ。「ノートブックが使えるから」程度の理由なら、もうSnowflake側で足りる。迷ったら、今ある分析を1つSnowflakeで再現して実測すれば、低リスクで答えが出る。

お金と責任の線引き

経営判断で最後に効くのは、コストと統制の境界です。3つだけ覚えれば足ります。

  • Cortexで完結するなら、何も外に出ない。 統制は最も厳格で、追加の漏洩対策コストもかからない。まずここを基盤にするのが堅い。
  • Claudeを使うなら、推論の結果がAnthropicに渡る。 「絶対に外に出さない」が要件なら、自社クラウド内に閉じる配備（Bedrock等）を選ぶ。安全になる代わりに、設定と費用の手間が乗る。
  • "閉じているつもりで閉じていない"が一番危ない。 「外に出さない」を満たさない配備形態も存在します。ここは契約・設計の段階で必ず詰めます。

「Bedrockを使えばClaudeでも安全に分析できる」という声もありますが、コスト面でも差が出ます。下表はClaude（Bedrock経由）を全社の分析窓口にした場合の概算です。

ケースユーザー数・クエリ数/日月間クエリ数月額（ドル）月額（円）
小規模10人・10件2,000件約$34約5,400円
中規模50人・20件20,000件約$340約54,000円
大規模200人・50件200,000件約$3,400約544,000円

※ Claude Sonnet（Bedrock）の料金をもとに試算。入力3,000トークン＋出力500トークン/クエリ想定。1ドル＝160円換算。Snowflakeクエリ実行コスト・Bedrock基本料は含まない。

Cortexを使う場合、LLM推論はSnowflakeクレジット内に含まれるため、この上乗せが発生しません。分析クエリの量が増えるほど、Cortexで完結させる優位性は大きくなります。

この境界は、導入前の設計段階で決めるのが鉄則です。後から変えると、接続部分の作り直しで費用が膨らみます。

明日からの順路

「次に何を決めるか」で言えば、順番はこうです。各ステップで投資対効果を確かめてから次へ進むのが、社内で説明のつく進め方です。

  1. 社員が日本語でデータを聞ける入口（Cortex）を、まず1部門で立ち上げる。 同時に「言葉の定義」を整える。ここで"効くか"を実地で確かめる。
  2. 効果が見えたら、部門を広げる。 権限設定で「見ていい人しか見られない」を担保しながら公開する。
  3. 予測が要る領域だけ、専門職に機械学習を任せる。 成果は1の窓口に戻すので、社員の使い勝手は変わらない。
  4. 複数システムをまたぐ仕事や"つくる"作業が要る層にだけ、Claudeを重ねる。

最初からClaudeを全社展開するより、Cortexで定常分析の土台を固めてからClaudeの出番を絞るほうが、「いくら投じて、何が変わったか」を一段ずつ示せます。

まとめ――地図の一行

社員のデータ対話は Cortex。Claudeは"つくる人"と"橋渡し役"。機械学習は専門職が担い、その結果はSnowflakeに格納され社員の画面に届く。境界はSnowflakeの中で閉じる。

Snowflakeを使う会社にとって、AI活用は「ツール選び」ではなく「役割分担」です。この地図を1枚持っておけば、次に出てくるAIの話も、迷わず置き場所が決まります。

DSB Consultingでは、Snowflake環境でのAI活用設計からCortex導入支援まで対応しています。AI活用の現状や課題について、まずは無料でご相談ください。