Snowflakeの導入事例

自前で作った集計画面の手入れが重くなり、顧客ごとの要望のたびに開発者が取られて本体の改良が遅れていた。

採用の担当者も決まった画面の数字ではなく、今どこで詰まっているかを知りたがっていた。

1. 自社でBIを作り続けるのをやめた
2. データの土台をSnowflakeに移した
3. 分析とAIをThoughtSpot Embeddedに任せた
4. KPIの決め方と画面の使い心地は自社で持つ
5. 自社画面にAIを組み込み質問の見本を並べた

公開から3か月で850社を超える顧客が新しいAIの画面を使い、AIエージェントへの質問は1,000件を超えた。

利用者が作って共有したLiveboardは35,000件を超えた。

顧客・マーケティング・取引のデータが別々の場所に散らばり集計の中身もそろっていなかった。

どの広告が予約につながったのか分からず投資の判断ができなかった。

1. 各ツールのデータをSnowflakeへ自動で取り込む
2. dbtで共通の定義にそろえ検証まで回す
3. 顧客モデルをGoogle AdsやHubSpotへ流す
4. レポートと分析はTableauとHexで見る
5. 客層と接点ごとに予算の配分を組み替える

広告費の配分を見直して前年よりROASが100%以上伸びた。

データ基盤まわりの作業は週およそ200時間分が浮き合併したGetmyboatのデータも6週間でつながった。

メルマガでは売り切れやすい大きな公演ばかりを載せていて、規模の小さい公演は埋もれていた。

一人ひとりの好みに合う公演を届けられずにいた。

1. Snowflakeの顧客データを毎日Amazon S3へ上げる
2. そのデータをPersonalizeに渡しおすすめ公演を作らせる
3. 作った結果をBrazeとつなぎメルマガ本文に差し込む
4. AWSと組みデータを整える流れを2日で用意した
5. 公開前に従来のメルマガと比べる試験で効き目を確かめた

メールを開いた人あたりの売上が49%増え、クリックからの購入率は250%伸びた。

紹介する公演の幅も5.2倍に広がった。

営業担当が顧客を調べて打ち合わせの準備をするのに、8〜9種類のツールやダッシュボードを行き来していた。

データの土台も成長に追いつかず、解決率や満足度といった大事な数字を集めるだけで手間がかかっていた。

1. Snowflake上に営業向けWebアプリを作った
2. 散らばっていたデータを1か所に集めた
3. Cortex AIが評価の傾向を読み要約資料を自動で組み立てる
4. 担当者は資料を見てどの顧客に力を入れるかを決める
5. 新規の個別メールはAIが下書きし人が確かめてから出す

顧客向けの分析資料は3〜4時間かかっていたものが10分未満ででき、毎月およそ500本を手作業なしで用意している。

営業全体で月2,000時間以上が浮き、金額にして約140万ドルの効果を見込む。

携帯の回線を狙った詐欺SMSが広がり、利用者を守りきれていなかった。

データも古い仕組みに分かれて置かれ、取り込みが止まるたびに人手で直していた。

1. 課金や通話の記録を持つSingleviewを取り込み元にする。
2. 変わった分だけをFivetranのCDCでSnowflakeへ送った。
3. 通話とメッセージの付帯情報からいつもと違うSMSを見つける。
4. 詐欺と判断したSIMは自動で止めた。
5. SMSを遮断する別の仕組みも合わせて入れる。

詐欺SMSはネットワーク全体で99%減り、見つけるまでの速さは以前の最大5倍になった。

2月の詐欺の通報のうちSparkの利用者は1.8%だった。

毎日の顧客データが数十億件に増え、データを削らずに全部預かるという約束を守れる基盤がなくなっていた。

500を超えるブランドの処理が互いに影響し合う心配もあった。

1. 顧客の行動履歴をSnowflakeにためて縮めず学ばせる
2. ブランドごとに処理を分け他に響かないようにした
3. 510以上のDynamic Tablesを1時間ごとに更新する
4. AIが対象者を選びメッセージを一人ずつ変える
5. 比較用のグループを残して効果を確かめる

AIが選んだ対象者は人が選んだ場合より成果が19%高く、顧客生涯価値は平均33%上がった。

3日かかっていた過去データの更新は40分、重い分析の問い合わせは77秒で返るようになった。

部門ごとにデータの決め方も呼び名もばらばらで、全社の指標を並べて見られなかった。

集約するデータウェアハウスも連携の土台も無かった。

1. 請求や顧客管理や財務のデータをSnowflakeへ集約する
2. 600以上のノーコードのコネクタで取り込みの流れを設定する
3. AIによるデータ品質のチェックを通した
4. 整えたデータだけをデータマートとAPIで社内へ提供する
5. この土台の上で20以上のAIの取り組みを進めた

AI向けのデータの下ごしらえにかかる時間が90%減り、年間で約3万6500時間分の作業が浮いた。

クラウドデータウェアハウスのROIは512%になった。

投資データの誤りを見つけるのに、人が決めた基準値で警告を出していた。

誤った警告が大量に出て担当者が1件ずつ中身を確かめていた。

1. Snowflake上にAlpha Data Platformを作った
2. 投資の全工程で生まれるデータを1か所に集めた
3. ディープラーニングのモデルで時価の不自然な点を判定させた
4. モデルの学習を重ねて誤った警告を外していった
5. 人は残った警告だけを見て確かめる

本当に確認が要る例外は100%見つけたうえで、誤った警告を87%なくした。

データ運用チームの生産性は25倍になり、労務コストは50%下がった。

サービスの質を測るのに、抜き取った記録や極端に評価が高い低い例だけを人が読んでいた。

全部のやり取りを見る手立てが無かった。

1. Snowflakeにためた電話やメールのやり取りを材料にした
2. 電話の音声をWhisperで文字にした
3. 文字にしたやり取りをLLMに読ませ満足度と不満の原因を判定させた
4. 長い会話を扱えるかで2つのLLMを比べLlamaを選んだ
5. 品質チームはStreamlitの画面で結果を見て研修に使う

利用者とのやり取りを100%AIが分析するようになった。

最初に動く形は2か月で作れた。

マーケティングの部門ごとに顧客データが分かれていて、細かい条件で客を絞り込めなかった。

高級ホテルに関心のある層を選び出すことも前のツールではできなかった。

1. 2019年から使うSnowflakeの上にHightouchのCDPを載せた
2. 業務側が決めた一つの用途で試作する
3. 高級ホテルに関心のありそうな層を選び出せるか確かめた
4. 事業部ごとに項目とつなぎ先を足す
5. 200人以上に研修をして毎月の集まりで定着を見た

初期のテストから2か月で本番に移した。

キャンペーン用の条件抽出はデータ部門に3週間待つ形から数日で自分でできる形になり、依頼のデータ取り出しは85%速くなった。

前のシステムでは重い顧客レポートの処理に1時間以上かかった。

会員制度を広げてほぼその場のデータで客に伝えたいのに、部門ごとにデータが分かれる形も避けたかった。

1. 3つのクラウド基盤を比べてSnowflakeを選んだ
2. 客との接点のデータを集めて一つにまとめた
3. テーブルを15分ごとに更新する
4. 自由に見る所と決まった帳票でツールを使い分ける
5. 項目を隠す機能で担当者ごとに見える範囲を分けた

2月に相談を始めて6月には顧客360がつなぎ込みまで含めて動いた。

いちばん重いレポートの処理は約80%速くなり、1時間以上かかっていたものが数分で出る。

Snowflakeで処理した顧客データは892 GBになった。

顧客のIT環境はサーバーが数百台に及び、監視の通知も膨大だった。

異常が出てから動く進め方では業務が止まる事故を防ぎきれなかった。

1. 運用ログと監視データをSnowflakeに集めた
2. ServiceNowのチケットをほぼリアルタイムに取り込む
3. Snowflake MLのモデルが事故へ発展する確率を出す
4. 出た確率をServiceNowへ書き戻し担当者が順番を決める
5. 2分かからずに診断をまとめ人が中身を見て手を打つ

復旧までの平均時間が54〜70%短くなった。

重大な障害は30%減り、SLAの達成度も38%上がった。

通販から一般の小売へ売り場が広がり、扱うデータが一気に増えた。

少人数のデータ担当では集計と管理が追いつかなかった。

1. AWS上にSnowflakeを置きdbtとAmazon S3につないだ
2. Zendeskの問い合わせデータをSnowflakeへ直接取り込む
3. 取り込んだデータから困りごとの報告書を作る
4. 報告書を商品とECの担当へ渡しサイトや商品を手早く直した
5. Snowflake Intelligenceで意見を普通の言葉で調べる

処理を自動にしたことで月200時間が浮いた。

市場と商品と販路ごとの動きも追えるようになり、売り方の見直しが早くなった。

過去の遅れは後から確認できても、この先どうなるかを読むことができなかった。

自前で持っていた仕組みは保守に手を取られ、大きな問い合わせが一つ走るだけで処理が滞った。

1. 社内のデータベースをやめAWS上のSnowflakeへ移した
2. 移行に21か月かけうち6か月で基幹システムのデータ構造を作り直す
3. 各部署が自分でデータを取りに行けるデータメッシュの形に変えた
4. 依頼を一つのチームが順番にさばくやり方をやめる
5. 文章の質問をSQLに直し結果を図で返す仕組みを載せた

ラストワンマイルのレポートは12時間から1時間になり、丸1日かかっていた月次の締めも2時間で終わるようになった。

運用のコストは50%下がった。

15の領域にまたがる約6,000のデータセットを抱え毎月10,000人を超える人が使うため処理の速さが追いつかなかった。

重くて複雑な処理を安く速く回せる置き場が足りなかった。

1. 社内基盤Cloud Data HubにSnowflakeをつないだ。
2. 大きな処理だけをSnowflakeに任せる形にする。
3. 整備と修理の記録のデータレイクをSnowflake上へ移した。
4. 単純な1テーブルの処理はApache IcebergとAWSに残す。
5. 権限は他の基盤で許可した範囲をそのまま引き継いだ。

整備データの処理は前の基盤と比べて平均コストが25%下がった。

販売からサプライチェーンまで18か月で60件の使い道がSnowflake上で動いている。

5,000本を超える油井の坑底圧を人手で求めるやり方は本数が多すぎて回らなかった。

1本あたり5万ドルのセンサーを入れる方法も費用が見合わなかった。

1. SnowflakeのData Hubに30以上の仕組みのデータを集めた。
2. 時系列データと坑井の構成データを共有機能でwhitson+へ渡した。
3. whitson+が物理モデルとデジタルツインに通して計算する。
4. 出てきた坑底圧を同じ共有の仕組みで自社へ返す。
5. APIをつくらずに双方向でやり取りする形にした。

5,000本を超える油井で坑底圧が毎日自動で出るようになった。

社員は社内データの95%に直接触れるようになり月およそ900万件のクエリが動いている。

データの受け渡しや変換の作り込みは手間がかかり同じ作業の繰り返しが多い。

依頼がたまって結果を出すまで待たされる状態が続いていた。

1. Snowflakeの上にデータ仕事を任せるエージェントを作った
2. 利用者は取り込みたいデータと欲しい形を普通の言葉で伝える
3. 取り込みから反映までの処理の流れをそのまま組み立てさせた
4. おかしな値やエラーを知らせデータの置き方の設計も引き受ける
5. 営業や経理はSlackから言葉で質問し自分で数字を見る

インフラの費用が約40%下がり、分析担当の作業量は50%減った。

使っていた Amazon Redshift は新しい道具とのつなぎ込みが遅れ、運用の手間も重かった。

専門の人を増やすか基盤を移すかの判断を迫られていた。

1. 外部のコンサルに任せず4人の社内チームで移行を進めた。
2. 試し実装を小さな移行として作り込み本番でも使い回した。
3. 繰り返しの多い書き換えをAIに任せ移行スクリプトを作らせた。
4. RedshiftからSnowflakeへのSQLの書き換えをAIにさせた。
5. 計画は大枠だけ決めて取り込みや変換やBI連携を同時に進めた。

4人のチームが約200TBの移行を4か月で終え、月々の基盤費用は50〜60%下がった。

分析の処理は4倍速くなり、実行時間は2〜3時間から30〜45分になった。

自社サービスの10年分の利用データとCRMが別々の場所にあり、キャンペーンのたびに手でデータを抜き出す必要があった。

準備に数か月かかり四半期に1本しか出せなかった。

1. Snowflakeの利用状況や取引の記録をClayに取り込む
2. Salesforceの顧客情報と外部データと突き合わせる
3. 解約防止ページを5回以上見て流通総額5万ドル超の条件でリストを作る
4. ClayのAIエージェントがどれだけ売上を守れるかの文面を書く
5. リストと文面をOutreachへ流しChili Piperで面談を入れてもらう

キャンペーン全体で商談化率が20%上がり、アウトバウンドからの面談化率も12%上がった。

電話からの成約率は10倍になり、四半期に1本だったキャンペーンを8本同時に回せるようになった。

チームごとに別々のツールとデータを持っていて、利用者の動きを全体で見る画面が無かった。

数字をもとに事業を決めるのが難しかった。

1. Snowflakeを唯一の正しいデータの置き場に決めた
2. 配信と広告の数字を1か所にまとめる
3. Snowflake CoWorkで自社のエージェントを9日で作った
4. エージェントに広告の戦略とキャンペーンの検討を任せる
5. 担当者は出てきた案を見て決める

上級のアナリストが5日かけていたキャンペーンの報告が3分で出るようになった。

データの取り込み費用は6分の1に下がった。

世界各地の拠点と買収が重なってデータの置き場がばらばらになり、古い自社設置のシステムにも頼っていた。

社内に似たデータ事業が並び、同じ作業を二重にやっていた。

1. 社内のデータを1か所に集めて分析できるか試した
2. 最初に債券の取引データを載せる
3. 構造化と非構造化のデータを流す経路を組んだ
4. Secure Data Sharingで顧客へ直接届ける
5. 直接つながない顧客には取り出しの処理を用意した

新しいものを出すまでの時間が50%短くなり、200人を超える社員がデータを自分で見られるようになった。

基盤にかけた費用も元が取れている。

自社に置いたSQLサーバーでは購読数や顧客管理の商用データしか扱えず、アプリやサイトの行動データと組み合わせられなかった。

扱う件数が数十万から数百万に増えて処理も追いつかなくなった。

1. 古いコードは引き継がずSnowflake中心に組み直した。
2. 取り込みはMeltano・変換はdbt・管理はAirflowに分担させた。
3. 2か月でデータベースと集計用の置き場を立ち上げた。
4. 社内のシングルサインオンとつないで利用権限を整えた。
5. 本番の複製環境で新しいコードを先に試し停止を避けた。

データ処理の費用が40%下がり、データの更新は4倍速くなった。

13TBのデータを読者の分析に使えるようになり、社内のデータの約90%がSnowflakeを通るようになった。

AWSとDatabricksと自作のソフトに処理が分かれていて費用と手間が大きかった。

Sparkのクラスタ管理や環境をまたぐ実行が要るため、機械学習のモデルを本番に出すまでが安定しなかった。

1. 保管先だったSnowflakeへ処理そのものを移した。
2. PythonのコードはHexで書きModelbitから本番へ出した。
3. dbtのモデル実行もSnowpark側でつないだ。
4. Sparkのクラスタ管理と環境をまたぐデータ移動をやめた。
5. 個人情報を消す処理はSnowparkのコンテナ基盤で動かした。

個人情報を消す処理の費用は75%下がった。

1億件を超える診療の記録を30分かからずに消せるようになった。

買収で増えた子会社ごとに分析の土台が違い、全体をまとめて見た数字が出せなかった。

処理のやり方も使う言葉もばらばらだった。

1. 2020年にSnowflakeを分析の中心に据えた。
2. 800本のパイプラインで各社のデータを1か所へ流した。
3. 共通の用語集を作り同じ定義のレポートを配った。
4. 各社が使ってきた道具はそのまま使える形にした。
5. 実行の回数と更新の頻度を見直した。

データの取り込みは2時間30分から50分になった。

毎日のモデル計算も3時間半近くから40分に短くなり、選んだデータモデルの費用は94%下がった。

前の環境は行数で料金が決まり、契約額は約20万ドルから年48万ドル近くまで膨らんだ。

作りを変えられず、回り道の処理が分析の足を引っぱっていた。

1. 顧客向け分析基盤の土台にSnowflakeを選んだ
2. 18か所に散った広告データをSnowflakeへ集める
3. 集めたデータを整えて顧客ごとのダッシュボードを作る
4. 古い環境を動かしたままレポートから順に移した
5. 顧客ごとの使用量を追い請求と値付けの根拠にする

データにかかる費用は約75%下がり、年に数十万ドルを浮かせた。

レポートとダッシュボードの表示は50%速くなった。

部署ごとに別のシステムとデータを持っていて、全体をまたいだ取り組みが進めにくかった。

オペレーターは1件ずつ状況をつかむのに時間がかかっていた。

1. 全社に散らばっていたデータをSnowflakeへ寄せた
2. オペレーター向けに1画面のアプリを作った
3. APIで引き出した情報をCortex AIが要約して画面に出す
4. オペレーターは要約で車の位置と契約を確かめる
5. 天気のデータも取り込み故障の起きやすさを読む

電話1件あたりの対応時間が30%短くなり、年間で数百万ポンドのコスト削減になった。

分かったことを実行に移すまでの期間も数か月から2〜3日になった。

取引先ごとに電池の診断データの形式がばらばらで、そろえる手間が大きかった。

データの量も多く自前で組んだ仕組みでは追いつかなかった。

1. 車や蓄電システムから届く診断データをSnowflakeへ入れる
2. 取り込みから保存と変換までを同じ場所で回した
3. 形式のばらつきはパイプラインで直す
4. 整えたデータから劣化の進み方と故障の兆しを読む
5. 読み取った結果を取引先に戻して電池の状態を見せる

電池の寿命は最大30%伸びた。

集めた診断データは100億件を超え、5ギガワット時分の蓄電情報も扱っている。

社内のどのチームもデータを使うのに全体の方針が無く、ばらばらのデータを価値に変えられなかった。

エンジニアが少なくオンプレミスの仕組みの手入れに分析担当の時間が取られていた。

1. データの約70%をSnowflakeへ移し残りも読めるようにした
2. 標準のコネクタで基幹システムやSalesforceとつないだ
3. Cortex AIで需要の見通しと店頭おすすめを業務チームに見せた
4. メールや表計算にしか無いデータをStreamlitのアプリで集めた
5. 業務チームごとに約20枚のダッシュボードをTableauで作った

需要予測の精度が8〜15%上がり、データを使う人の開発の手間は用途によって50〜100%減った。

分析担当は仕組みの手入れから離れ、価値の高い仕事に回れるようになった。

Amazon Redshiftはデータ量が増えるとクラスタの手直しが必要で処理が遅れた。

データの質問に答えるにはSQLを書いて分析する手間がかかり、顧客側もSQLを扱えず自分でデータを見られなかった。

1. 過去データ20TBをETLの流れを作ってSnowflakeへ移した
2. 移行のあいだは旧環境と並べて動かし止まる時間を抑えた
3. 移したデータをnovaにまとめ社内も顧客も同じ数字を見られる形に整えた
4. Streamlitで試作を作り普通の言葉で質問して答えを受け取れるようにした

複雑な問い合わせの処理が5倍速くなり、データの取り出しは24時間から12秒になった。

データサイエンティストが15〜20時間かけていた作業は自動で回るようになった。

新しい法人顧客へ見積もりを出すとき、担当者が他社の価格や為替や費用を自分で調べていた。

管理者と営業と分析の担当が資料を探すのに年間で合わせて2,500時間を使っていた。

1. ばらばらのデータの置き場をSnowflakeへ一つにまとめた
2. 社内でハッカソンを開きアイデアの1つを製品にする
3. Cortex AIでMistralを動かし他社の公開価格を自動で集めた
4. 集めた情報を社内のデータと合わせ価格の案をその場で出す
5. 営業に値付けの目安を見せ競争力が弱いときは代わりの出し方を示す

見積もりのための調べ物が自動になり、営業の進みが速くなって年に数千時間が空いた。

ハッカソンのアイデアは2週間半で本番まで届いた。

複数の通信網やアプリから届く契約者のデータが別々の場所にあり、顧客に通信の状況をまとめて見せられなかった。

前の基盤は処理に時間がかかり、監視の仕組みも自前で用意する必要があった。

1. 通信網と自社アプリのデータをSnowflakeに集める。
2. 取り込みにApache Kafkaとdbtを接続する。
3. 集めたデータでデータサイエンティストが解約予測モデルを作る。
4. BrandIQが分析に変えてブランド担当の画面に出す。
5. Snowflakeの通知で不調や容量の残りに気づく。

前の仕組みと比べて実行の速さが2倍になり、データ取り込みの遅れも20%減った。

顧客は複数のシステムを見に行かなくても機器の接続や利用の傾向を1つの画面で確かめられるようになった。

決済を扱う場としてカードの盗用や偽の店舗を使った資金洗浄に備える必要があった。

担当者が目で見て不正を見つけるやり方では、取引の伸びに追いつかなくなっていた。

1. 予約と決済のデータをSnowflakeに集める。
2. 本番のデータベースから短い間隔で更新する。
3. 盗用カードや偽の店舗の兆候をモデルに学ばせる。
4. モデルが取引を点検し疑わしいものを確認用の列に回す。
5. 回ってきた取引は人が目で確かめて判断する。

新しい機械学習の仕組みを動かし始めた段階で、不正な取引が80%減った。

取り込みの費用は約95%下がり、いまは月に2,000万件のクエリを処理している。

人事や給与や財務のデータが別々のツールに分かれていて、必要な数字をそろえるだけで手作業が増えていた。

担当者は原因や傾向をつかめず判断が勘に頼りがちだった。

1. 顧客のHRと給与のデータをSnowflakeへ集約した
2. 取り込みと処理の流れをDBTやAirflowで組んだ
3. 人件費の異常値と欠勤の傾向を毎日出した
4. 業種別のベンチマークは週ごとに更新する
5. Power BIのダッシュボードをWebアプリに埋め込んだ

Snowflakeのデータをもとにした分析を7,000社へ届け、大企業から中小企業まで働き方を数字で見られるようにした。

個別の助言を売る新しい仕事も生まれた。

採用のデータが古い社内システムに散らばり、候補者の予測が出るまでに何週間もかかっていた。

繁忙期は採用にかかる費用が2〜3倍にふくらみ、内定後の辞退が最大30%まで上がる市場で動きが後手に回っていた。

1. SnowConvertで重要な処理をそのまま移した
2. SAPやATSとzero-ETLのコネクタでつなぎ入り口を1つにまとめた
3. Snowparkに機械学習のモデルを載せ過去データを学ばせた
4. 候補者ごとの入社確率を入社25〜30日前に返す
5. 辞退しそうな人を早く見つけ引き止めを先に取る

入社するかどうかの予測が80%の精度で25〜30日前に出るようになり、辞退による採り直しの費用を抑えられた。

総保有コスト（TCO）は70%減ってデータの照会は10倍速くなった。

電力の仕入れを毎日決めるのに、予測は顧客の契約ごとにモデルを用意していて維持の手間が重かった。

太陽光パネルの発電の異常も過去の平均をExcelに出して人が見比べていた。

1. 天気や過去の使用量や契約の情報をSnowflakeへ集めた
2. 契約ごとのモデルを1つのモデルにまとめた
3. 1時間ごとの電力の使用量を契約期間にわたり予測する
4. 太陽光パネルの発電の実績をモデルで見張った
5. 画面はStreamlitで作り意見をもらって直した

モデルを1つにまとめて学習のコストは75%下がり、精度は落ちなかった。

数十万件の予測を作るのにかかる時間も短くなり数分で終わるようになった。

古い社内システムでは各部署が手作業で集計しないと数字が出なかった。

顧客や代理店の動きも見えずデータが最新かどうかも信用できなかった。

1. Snowflakeのデータ基盤をAzure上に作る
2. 古いオンプレミスの仕組みからデータを移した
3. 分析はQlik・変換はdbt・流れはDagsterをつなぐ
4. 書類はAIが自動で読み取り請求受付の処理に回す
5. 突き合わせも自動にして各部署が同じ数字を見る形にした

AIを入れたことで自動車保険の請求受付が30〜40%速くなった。

3か月で380時間分の作業が自動になった。

工場には何千もの機械がありそれぞれ数百の部品や設定が効率に響く。

人手ですべてを見て最適な状態に保つのは無理だった。

1. 工場のデータをSnowflakeに1か所へ集める
2. 製造現場の前提が読み取れる意味づけのデータを足す
3. Cortex AIとRelationalAIで言葉で検索できるようにする
4. 数百の項目を読ませて故障の予兆と直し方を出させる
5. 設備をつなぐだけで使えるアプリとして配る

NASAのC-MAPSSデータで試したところ2週間の調整で世界の上位3位に入る精度が出た。

設備の最適化から10万ドルを超える新しい売上も生まれた。

顧客のリスクは100を超える提供元の情報を突き合わせないと順位が付けられなかった。

新しく見つかった脆弱性の中身をつかむにも何時間もかかっていた。

1. Snowflakeを全データの置き場にする
2. 100を超える脅威情報の提供元をつなぐ
3. 顧客ごとの事業の前提と重ねてリスクの点数と優先順位を出す
4. 生成AIでCVEに人が読める説明を付けさせる
5. 最後の判断は人が見る形を残す

CVEの中身をつかむまでの時間は数時間から数分に縮んだ。

以前なら数日かかった処理も1時間で終わるようになった。

会員が急に増えてデータは前の年の2倍3倍になり、それまでのデータ基盤では維持と拡張が追いつかなかった。

収益の予測もCSVファイルに頼っていた。

1. RedshiftとDremioからSnowflakeへデータを移した
2. 全社のデータをSnowflakeで検索できるようにした
3. 財務の責任者と組みSnowparkとHexで収益予測のモデルを作る
4. モデルが財務データのパターンと傾向を自分で見つける
5. モデルが扱う軸を3倍に増やしてCSV頼りを減らした

Snowparkで作ったモデルで財務の予測が3倍速くなった。

データを1か所にまとめたことで毎日20時間分の計算が要らなくなり、月に数万ドルを節約できた。

外に使えるデータはあっても形がばらばらで、危険度を測る役に立てにくかった。

前の仕組みではPythonとSQLサーバーで読み込みを試しても、1ファイルの試作から先へ進めなかった。

1. 国が公開するlidarデータ6,500ファイルをSnowflakeへ取り込んだ
2. Snowpark上でLAZとLAS形式を読むライブラリを動かし点群を表へ変換した
3. 地理空間の機能とH3の空間インデックスで建物と木の高さや距離を計算した
4. 引受の担当者が高さデータで平らな屋根の割合を確かめて条件を決める

6,500ファイル約10TBの処理は中規模のSnowparkウェアハウスで100時間で終わった。

建物ごとの危険度を細かく測れるようになり、洪水や風の被害の見立ても具体的になった。