Snowflake × Amazon Bedrock：生成AIで経営指標を読む分析基盤

ダッシュボードは「数字」を映し出しますが、その数字が「なぜそう動いたのか」までは語ってくれません。KPIの前週比、季節変動、突然のスパイク——その背景を言語化する作業は、いまも多くの現場で属人的で、レポート化に時間がかかります。本記事では、Snowflakeに集約した経営指標データをAmazon Bedrockの生成AIに読ませ、自然言語の要約や異常の「説明」を自動生成する分析基盤を、AWS実装の視点から解説します。External Access IntegrationとExternal Functionの2つの呼び出し方、データ境界とセキュリティ設計、そしてSnowflake Cortexとの使い分けまで、EMWが検証で先に潰してきた勘所を添えてまとめます。

01なぜSnowflakeのデータをBedrockに読ませるのか

BIダッシュボードは指標の「値」を可視化しますが、経営層が本当に知りたいのは「先週から売上が伸びた理由は何か」「この在庫回転率の落ち込みは異常か、季節要因か」といった解釈です。この解釈をアナリストが毎回手作業で言語化していると、属人化とレポート遅延を招きます。ここに生成AIを差し込み、指標の要約と異常の説明文を自動生成すれば、意思決定のリードタイムを短縮できます。

Snowflakeはすでに売上・在庫・行動ログといったデータの集約先になっていることが多く、そのすぐ隣で生成AIを回せるのが強みです。SnowflakeはAWS上で動くため、S3・IAM・KMS・PrivateLinkといったAWSのガバナンス機構をそのまま活かせます。EMWでも、大手飲料メーカー様や大手冷凍倉庫事業者様、中堅の営業専門企業様まで、低コストの小規模導入から大規模基盤まで複数業種でSnowflakeを構築・運用してきましたが、「集約済みデータの隣で生成AIを動かす」構成は業種を問わず効果が出やすい領域です。

02呼び出しの2ルート：External Access Integration と External Function

SnowflakeからAmazon Bedrockを呼ぶ経路は大きく2つあります。ひとつはSnowpark（Python UDFやストアドプロシージャ）からExternal Access Integrationを使ってBedrockのランタイムエンドポイント（bedrock-runtime）へ直接egressする方式です。Snowflakeの計算層の中でboto3を呼び出せるため、余分なAWSコンポーネントを増やさずに済み、現在はこちらが素直な選択肢になります。

もうひとつは従来型のExternal Functionで、Snowflakeの外部関数がAmazon API Gatewayを経由してAWS Lambdaを呼び、Lambda側でBedrockを叩く方式です。Lambdaにプロンプト整形やリトライ、他のAWSサービスとの連携ロジックを寄せられる一方、API GatewayとLambdaという運用対象が増えます。既存のLambda資産に前処理を集約したい、あるいはBedrock以外の処理も同じ関数で束ねたい場合に向きます。どちらもIAMロールによる認証を土台にしており、要件に応じて選択します。

03構成の作り方（最小構成）

External Access Integration方式の最小構成は、次の4つのオブジェクトとUDFで組み立てます。まずNETWORK RULEをMODE = EGRESSで作り、宛先にbedrock-runtime.<region>.amazonaws.comを許可します。次にSECURITY INTEGRATIONをTYPE = API_AUTHENTICATION／AUTH_TYPE = AWS_IAMで作成し、Snowflakeが引き受けるAWS側のAWS_ROLE_ARNを指定します。続いてCLOUD_PROVIDER_TOKEN型のSECRETを作り、これらを束ねるEXTERNAL ACCESS INTEGRATIONを定義します。

最後に、そのIntegrationとSecretを紐づけたPython UDF（またはプロシージャ）を書き、内部でboto3のbedrock-runtimeクライアントを生成してinvoke_modelを呼びます。認証は長期的なアクセスキーではなく、IAMロールから発行される短期的なSTS一時認証情報で行われる点が重要です。UDFの引数としてシステム指示・入力テキスト・モデルIDを渡す設計にしておくと、モデルの差し替えがSQLだけで完結します。

04ユースケース：KPIの自然言語要約と異常の「説明」

実装で最も効くのは「LLMに生ログを丸投げしない」ことです。まずSnowflake側でSQLの集計とウィンドウ関数を使い、前週比・移動平均・zスコアといった意味のある単位まで加工します。そのうえで、集計済みの小さな結果セットだけを生成AIに渡し、「今週のKPIを日本語で3行に要約」「zスコアが閾値を超えた指標について、考えられる背景を候補として説明」といったプロンプトで言語化させます。

この処理はDynamic Tablesと組み合わせると、元データの更新に追従して要約を定期的に再生成できます。出力先はSnowflakeのテーブルなので、そのままBIツールのコメント欄やSlack通知に流し込めます。異常検知そのものはSnowflake側の統計処理で行い、Bedrockはあくまで「検知された事象に説明を与える」役割に限定するのが、精度とコストの両面で安定します。

05データ境界とセキュリティ設計

経営指標を扱う以上、データがどこを通り、どこに残るのかを設計時に確定させます。認証はIAMロールと短期STS一時認証情報で行い、長期アクセスキーをSnowflake側に保持しないのが基本です。通信経路は、AWS PrivateLinkのbedrock-runtimeインターフェイスVPCエンドポイントを使えば、トラフィックがAWSネットワーク内に留まり、公共インターネットを経由しません。Snowflake側でこのプライベート接続を使う機能はBusiness Critical以上のエディションが前提になる点は、事前に確認しておきます。

Amazon Bedrockは、送信したプロンプトと補完結果を保存せず、基盤モデルの学習にも利用しない旨を明示しています。加えて、Snowflakeの保存データはデフォルトでAES-256の階層型キーモデルにより暗号化され（キーはSnowflakeが自動管理・ローテーション）、AWS KMSの顧客管理キーを組み合わせたい場合はTri-Secret Secure（Business Critical以上）を明示的に有効化します。残る論点は「どの列をLLMに渡すか」のガバナンスで、個人情報や機微な列はSnowflakeのマスキングポリシーやビューで事前に落とし、匿名化・集約した指標だけをプロンプトに乗せる運用にします。

06Snowflake Cortex との比較・使い分け

Snowflakeには、そもそも外部へ出ずに生成AIを使うCortexという選択肢があります。CortexのAISQL／LLM関数（AI_COMPLETEやCOMPLETEなど）は、Anthropic・OpenAI・Meta・Mistral・DeepSeekなどのモデルをSnowflakeのサービス境界内でホストして提供し、データを外に出さずSQLだけで推論を実行できます。自然言語で構造化データに問い合わせるCortex Analystもあり、KPI分析の多くはCortexだけで完結します。egress設計もIAMロールも不要で、立ち上がりが速いのが最大の利点です。

ではBedrock経由はいつ選ぶか。Cortexが提供していないモデルや特定バージョンを使いたい、組織としてBedrockに標準化しガバナンスを一元化している、Bedrock AgentCoreや他のAWSサービスと同じ土俵で統合したい——こうした要件がCortexの範囲を超えたときにBedrock連携が生きます。実務上は「まずCortexで試作し、要件が超えた部分だけBedrockに寄せる」段階的な使い分けが、コストと運用負荷のバランスが取りやすい進め方です。

07検証で先に踏み抜いた落とし穴

この構成は便利な反面、コストとレイテンシの罠が複数あります。EMWでは本番投入の前に検証環境でこれらを意図的に踏み抜き、設計に反映してきました。まず、検証で全行をLLMへ流す実装を試したところ、トークン課金と応答時間が急激に膨らむと分かったため、本番では前段のSnowflake集計を必須とし、1回のプロンプトに渡す行数に上限を設ける設計にしました。

次に、External Function経由のパターンでは、外部関数の呼び出しにタイムアウトやペイロードの制約があり、大量行を一度に処理すると失敗しやすいことを検証で確認しました。そこで本番ではバッチ分割と結果テーブルへのキャッシュを前提にし、同じ入力への再問い合わせを避ける設計としています。さらに、SnowflakeとBedrockのリージョン不一致がクロスリージョンのegressとコスト増を招くことも検証段階で把握し、本番ではリージョンを揃えました。こうした失敗を検証で先に潰す運用を積み重ねることで、EMWは重大障害0を継続しています。

08まとめ：数字に「意味」を添える基盤へ

Snowflakeに集約した経営指標を、Amazon Bedrockの生成AIで自然言語に翻訳する構成は、ダッシュボードの「値」に「なぜ」を添える強力な一手です。実装の要点は、External Access IntegrationとIAMロールで安全に呼び出すこと、LLMには集計済みの意味単位だけを渡すこと、PrivateLinkとマスキングでデータ境界を締めること、そしてCortexとの使い分けで過剰投資を避けることに集約されます。まずはCortexで小さく試し、要件が超えた領域からBedrock連携へ広げる——この順序であれば、コストと安全性を保ちながら生成AI分析基盤を育てられます。