「Snowflake利用企業のAI活用地図」では、分析のスコープでClaude Desktopに違和感があると書きました。その理由は、生データがSnowflakeの外に出ることへのガバナンス上の懸念でした。
ただし、こう考えると話が変わります。「Cortexに集計・推論を任せ、その結果だけをClaudeに渡して解釈させる」。この分担ならデータガバナンスの問題はどこまで解消されるか。そしてBedrockは本当に必要か。本稿で整理します。
そもそもなぜClaudeが欲しかったのか
出発点を確認します。Snowflake Cortexは「Cortexでできること」で整理した通り、自然言語での集計・予測・異常検知・文書検索まで対応しています。ではなぜClaude（生成AI）が欲しくなるのか。
Cortexが返せるのは「事実」です。「地域Aの離脱率が先月比12ポイント上昇した」という数値は出せる。しかし「なぜそうなったのか」「意思決定者にどう説明するか」「次に何をすべきか」という解釈・文章化・意思決定支援の層は、Cortexが担う仕事ではありません。そこにClaudeの出番があります。
役割を分けると何が変わるか
「Cortexで処理、Claudeで解釈」に分けた場合、データの流れはこうなります。
Claudeが触れるのは集計値のみで、生の顧客データや個人情報は渡りません。「データをSnowflakeの外に出してはいけない」という懸念の対象は生データであり、この構成ではその部分をCortexが遮断しています。
Claudeが加わることで何が変わるか
Cortex単体では報告書の「語る力」に限界があります。Claudeが介在することで以下が変わります。
| 項目 | Cortexだけ | Cortex＋Claude |
|---|---|---|
| 数値の取得・集計 | ○ | ○（Cortexが担う） |
| 異常・変化の検知 | ○ | ○（Cortexが担う） |
| 原因の仮説立案 | △（限定的） | ○（Claudeが担う） |
| 経営層向けの文章化 | × | ○（Claudeが担う） |
| 「次に何をすべきか」の提示 | × | ○（Claudeが担う） |
| 社外情報との文脈連結 | × | △（Claudeの学習範囲内で） |
「良い分析報告書」が求めるのは、数値の正確さだけでなく、読み手が次の行動に移れるだけの筋の通った説明です。その層をCortexに求めるのは役割の逸脱であり、Claudeが補完する設計が自然です。
具体的な流れ――分析設計から報告書まで
「全国の店舗の販売金額を12ヶ月推移で出して、上位・下位グループの違いを比較したい」という依頼を例に、実際の手順を追います。
① Claudeに分析を設計させる
まず社員がClaude Desktopにビジネス課題を伝えます。
全国の店舗の販売金額を分析したい。12ヶ月推移と、上位・下位グループの違いを経営会議で報告できる形でまとめてほしい。
Claudeは「何を見るべきか」を設計して返します。
以下の順で分析します。①12ヶ月の月別販売金額合計と前年同月比、②累計販売額で上位25%・下位25%に分類、③グループ間で平均単価・商品構成比・成長率のばらつきを比較。Cortex Analystに次の3つの質問を投げてください。
② ClaudeがCortex向けの質問を作る
ClaudeがCortex Analystに投げる自然言語クエリを出力します。社員はそれをCortex Analystに貼るか、MCP連携（外部ツールとClaudeをつなぐ仕組み）があればClaudeが自動実行します。
| クエリ | 内容 |
|---|---|
| 1本目 | 直近12ヶ月の月別・店舗別販売金額を取得して |
| 2本目 | 累計販売金額で店舗を4分位に分けて、上位25%と下位25%の一覧を出して |
| 3本目 | 上位・下位グループそれぞれの平均単価・商品カテゴリ別構成比・月別成長率を比較して |
③ Cortexが数値を返す
Cortex Analystが各クエリをSQLに変換して実行します。返ってくるのは集計テーブルと数値のみです。
上位グループ：平均単価 ¥4,820 / メンテナンス系比率 23% / 月別成長率ばらつき ±3%
下位グループ：平均単価 ¥3,210 / メンテナンス系比率 9% / 月別成長率ばらつき ±22%
④ 数値をClaudeに渡して報告書を作る
社員がCortexの出力をClaudeに貼り付けて依頼します。
Cortexから結果が返りました。[数値を貼り付け] これを経営会議向けの報告書にまとめて。
Claudeが数値を解釈して報告書を生成します。
上位・下位の差は「単価」ではなく「商品構成」にあります。上位店舗はメンテナンス系が23%を占め、下位店舗は低単価の洗車が中心です。客数の差ではなく、一顧客あたりの購買内容の差が収益格差を生んでいます。打ち手はメンテナンス提案の強化で、下位店舗の単価を1.5倍に引き上げる余地があります。
役割の整理
| 誰が | 何をするか |
|---|---|
| 社員 | ビジネス課題をClaudeに伝える |
| Claude | 分析を設計し、Cortexへの質問を作る |
| Cortex | SQLを実行して数値を返す |
| Claude | 数値を解釈して報告書にする |
| 社員 | 報告書をもとに意思決定する |
BedrockはHave toか
Claudeを使う手段は大きく2つあります。Anthropic APIを直接使う方法と、AWS Bedrock経由で使う方法です。
| Anthropic API | AWS Bedrock | |
|---|---|---|
| データ学習への利用 | 契約上なし（APIデフォルト） | 契約上なし |
| 既存セキュリティ統制への統合 | 個別に設定が必要 | IAM・VPC・CloudTrailに乗れる |
| 経営・法務への説明 | 「Anthropicのサーバーに渡る」 | 「AWSの中で閉じている」 |
| 導入ハードル | 低い（APIキーのみ） | AWSアカウント設定が要る |
| コスト | 従量課金 | 従量課金（若干割高な場合あり） |
「集計結果しか渡さない」構成であれば、Anthropic APIでも社内ルール次第では通せます。Anthropic APIはデフォルトでビジネスデータを学習に使いません。
ただし、集計値に個人が特定できる情報が含まれる場合（特定顧客の購買サマリーなど）、または金融・医療など法規制が厳しい業種では、BedrockによってAWS統制に乗せるほうが説明責任を果たしやすい。必須ではないが、推奨という立場です。
DSBの見解
「Cortexで集計・推論、Claudeで解釈・文章化」という分担は、データガバナンスと生成AIの利点を両立する現実的な設計です。生データをSnowflakeの外に出さず、Claudeには事実のみを渡す。この設計であれば、分析担当者が懸念すべきリスクの大半はCortex側で遮断されています。
残る問いは「集計値の中に何が含まれるか」です。個人識別につながる粒度の集計値を渡す場合は、Bedrockによって企業のセキュリティ統制に乗せることを検討してください。そうでなければ、まずAnthropicのAPIで試してから必要に応じてBedrockに移行する順序で十分です。
Cortexが「何が起きているか」を明らかにし、Claudeが「それをどう読むか」を語る。この役割分担が、分析担当者の手間を減らしながら、報告書の質を上げる現実的な道筋だとDSBは考えます。