Databricksの導入事例

顧客ごとにデータを別のクラウド環境で持つ決まりにしていた。

取り込みのたびにエンジニアが専用のスクリプトを書く必要があり手間が大きかった。

1. 顧客ごとにDatabricksのワークスペースを用意する
2. Fivetranの接続とdbtのプロジェクトも顧客ごとに作る
3. 決められた担当者だけが触れるようにする
4. クリックや閲覧のデータを取り込みdbtのSQLで変換を定義する
5. 整えたデータを機械学習へ流し広告費の配分を予測する

1件のデータ連携は100〜150時間から10時間になり、夜通しで最大20時間かかっていた処理も4〜5時間で終わるようになった。

切り分けにかかる時間は全体の50%から20%未満へ下がり、受けられる顧客は30%増えた。

Databricks上でRAGチャットボットのPoCを進めていたが、回答の精度が悪いときに原因がチャンク分割か検索か質問か回答生成かを見分けられなかった。

全部に手を入れるしかないと感じ、着手点が決まらない状態が続いていた。

1. LLMOpsの勉強会と書籍で可観測性を知り既存コードに手を入れた
2. コード生成AIに相談し関数ごとにMLflowのトレース用デコレーターを付けた
3. アプリを動かしExperimentsで記録の抜けを見つけ順に見えるようにした
4. 自動トレーシングも戻す前提で試し重複する記録は後から外した
5. 検索で返った文書とチャンクの単位で中身を確かめた

約1ヶ月このやり方を続け、検索結果が同じ文書内のチャンクに偏る現象を見つけて検索ロジックの見直しにつなげた。

どの工程が悪いのかを部品ごとに見分けられるようになり、気持ちの負担も手間も大きく減った。

チケット・飲食・物販・アンケートなど30か所からデータが入るのに別々のシステムに散らばっていた。

同じ人が試合とライブに来ても別のファンとして記録され、試合後のアンケートへの返事に最大15日かかることもあった。

1. Databricksで物販や飲食など種類ごとにデータをまとめる
2. ECの買い物とレジの買い物を1人の購入履歴としてつなぐ
3. アンケートやチャットボットの声も同じ場所に集める
4. Data 360へ流しファン1人ごとのプロフィールにする
5. Agentforce Marketingがメール内容を人ごとに変えて送る

30か所に分かれていたデータが1人ごとのプロフィールにまとまり、来場や購入やメールの開封に合わせた案内を送れるようになった。

ブランドをまたいで同じ人だと分かるようになった。

外部サービスごとに自前の接続部品を作る必要があり1つ仕上げるのに2か月ほどかかっていた。

技術の分からないチームは必要なデータが届くまで数週間から数か月待たされていた。

1. 外部サービスからのデータ取り込みをFivetranに寄せる。
2. Databricksへデータを集めて一か所にまとめた。
3. 既成の接続先が無いデータはConnector SDKで部品を作る。
4. 社内で作ったLLMのエージェントに部品のコードを書かせた。
5. 出てきたコードは人が確かめてから本番へ載せる。

接続部品を作る時間が98%減り2か月かかっていた作業が最短1日で終わるようになった。

後回しになっていたUXチームのデータも1日で取り込めた。

古いシステムが何本も残り、同じデータがあちこちに重なっていた。

費用がふくらみ、社内と顧客に影響する障害も起きていた。

1. 古いものを直さずFivetranとDatabricksで新しい基盤を作り直した
2. 200超のデータ源をFivetranでレイクハウスへ取り込む
3. 夜間のまとめ処理をやめ変更分をそのまま反映する形にした
4. 集めたデータの上で生成AIを動かし社内文書から答えさせる
5. 信託証書はAIに下読みさせ担当者は要点だけを見る

取り込みの費用は1年で約50%下がり、機械学習の性能とその場のSQLの速さは30%上がった。

年1万5000件の信託証書の確認は45分から5分になり、年およそ1万時間の削減が見込める。

一括処理を前提にした古い仕組みでは、リアルタイムの状況や機械学習に回せるデータを用意できなかった。

移行に4年かかる計画のままでは市場の動きに置いていかれる恐れがあった。

1. ばらばらのデータの置き場をDatabricksの基盤へ1つにまとめた
2. すでにあるMicrosoft環境に合わせAzure上へ置いた
3. Apache Sparkで大量の運航データをさばく
4. Unity Catalogで誰がどのデータを使えるかを一元管理する
5. 予測の層を作り出発時刻と到着時刻をその場で直す

新しいデータの取り込みにかかる時間が50%以上減り、4年かかる予定だった移行を12か月で終えた。

不具合への対応も5つの手順から2つになった。

社内に大量のデータがあっても取り出せるのは技術の分かる人だけだった。

SQLを書けない人はデータサイエンティストの手が空くのを待つしかなかった。

1. Databricks上でClaudeを動かす形にした。
2. 社内のエージェントgooseからMCPで道具やデータベースにつなぐ。
3. gooseが質問を受けSQLを書いて実行し結果を返す。
4. 複雑な分析は3.5 Sonnet手順の多い依頼は3.7 Sonnetを使う。
5. つなぎ込みはOAuthの短い期限の資格情報にした。

エンジニアの75%が週に8〜10時間以上を減らした。

1万人のうち約4,000人が使い利用は1か月で2倍になった。

40か国以上を相手にする分析の体制を一から作る必要があった。

Pythonのノートブックだけでは数百のモデルを費用を抑えたまま回すのが難しかった。

1. Microsoft Azureで全世界のデータ倉庫を作った
2. 下ごしらえとBIの計算はDatabricksに任せる
3. DataRobotをAPIでつなぎ古い仕組みのデータも同じ流れに乗せた
4. 続けると決めたモデルだけを各市場向けに学習し直す
5. 価格の最適化や需要予測を同じ画面で作り本番の精度も追う

試作にかかる時間は半分以下になり、車と部品の価格の最適化はPythonで書いていた約16週間から3〜4週間に縮んだ。

本番で100を超えるモデルが動き、分析の部隊は5人から世界で230人に増えた。

中南米の小売店へ同じ内容の案内を一斉に配るやり方しかなく、店ごとの買い方の違いに合わせられなかった。

毎週すべての店に合う内容を人手で用意するのは無理があった。

1. 機械学習で店ごとにまだ買っていない商品を毎週選ぶ
2. 似た店の買い方や近所の傾向に伸ばしたい商品の優先度を足した
3. 生成AIが候補を店ごとのメッセージへ書き起こす
4. 言い回しと画像と誘導の文言を店ごとに変えた
5. Amplitudeに行動データを集めDatabricksで購入までを追う

生成AIで作った案内のクリック率は11%となり、生成AIを使わないものより約8ポイント高かった。

以前は1週間かかっていた分析が数分で終わるようになった。

井戸の仕上がりのデータが形のばらばらなメールで届き、技術者が手で中身を確かめていた。

井戸の名前が長く複雑で読み違いも起きやすく、次の判断が遅れていた。

1. UiPathで受信メールを読み解くエージェントを作った
2. Databricksのエージェントで正しさを採点させた
3. ロボットが受け取りから処理の完了までをつなぐ
4. 誤りのある届け出は理由を添えて送り主へ自動で返す
5. 信頼が固まってから人の最終確認を外した

検証の済んだデータがそのまま技術者へ届くようになり、手作業の確認はなくなった。

1台のロボットが数十の処理を支え、他のチームへも広げられるようになった。

古いアプリと昔ながらのやり方のままで住人の求める速さに追いつけなかった。

データがばらばらに残り問い合わせへすぐ答えられる形になっていなかった。

1. 半年かけて住人や理事会や事業の責任者から直に話を聞いた
2. チャットとSMSで住人に答える生成AIの窓口HODAを作った
3. 土台はMicrosoft Azureに置きDatabricksに検索を担わせた
4. 現場にHODA Simulatorを渡して練習と切り分けに使わせた
5. 管理者は受け持ちのデータの汚れを直してから住人へ出した

公開から週3,000〜6,000件のやり取りがあり、最初の8か月で64,000人以上が登録した。

週あたりの未回答は約27%減り、SMSへの案内を入れてから週の利用者が60%増えた。

会社が伸びるにつれデータの依頼が増え続け、Power BIでは追いつかなくなっていた。

その都度のレポートは1本作るのに最大1週間かかり、経営層が売上をすぐ見られなかった。

1. Databricksに倉庫を作りCRMやERPなどのデータを1か所へ集めた
2. よく使っていたPower BIのレポートをLiveboardで作り直した
3. 商品の種類・拠点・顧客・営業担当ごとに掘り下げられるようにした
4. JIRAのデータも入れて依頼の残りと対応の速さを見るLiveboardを作った
5. 製造現場の分析も作り手作業のレポートを置き換えた

手作業のレポート50本をやめ、社内のクエリは300%増えた。

使う人は以前のBIツールの2.5倍になり、ThoughtSpotの利用者は10人から50人へ増えた。

買収と事業拡大が重なってデータがツールごとに分かれていた。

新しく買った会社のデータをつなぐには数か月かかり、部門をまたぐ許可取りにも数週間を要した。

1. Databricksにデータ基盤をまとめた。
2. Unity Catalogで権限を一本化する。
3. 行や列の単位で隠して安全に渡せるようにした。
4. Genie Codeに表を探させてクエリとノートブックを作らせる。
5. 会話型のAI Modeにlakebaseをつないで記憶の層にした。

社内の月間利用者は1,500人を超え、基盤をまとめたことでインフラと運用のコストが65%下がった。

以前は数日から数週間かかっていた役員向けダッシュボードを1時間以内で出せるようになった。

セキュリティ担当はインフラやクラウドや外部業者の監査ログを大量に抱えていた。

生のログが散らばったままで脅威の検知や調査の土台が無かった。

1. 監査ログをパイプラインでDatabricksへ流す。
2. 生のイベントの形をそろえてDelta tableに入れる。
3. Unity Catalogで閲覧の範囲を管理する。
4. 整えたデータで脅威の検知と調査と監査の分析を進める。
5. Codexにデータを引かせ人が中身を確かめる。

脅威を見つけるまでが速くなり、同じデータを何度も取り込む無駄が減った。

誰が何を見たかの記録が残る形のまま、セキュリティの運用を広げられるようになった。

古い仕組みと増え続けるデータで分析が追いつかなかった。

世界中の拠点に置く補修部品をどれだけ持てばいいのかも分からず在庫の担当者が困っていた。

1. 社内基盤の中核にDatabricksを置きデータを1か所へまとめた
2. 同じ作業環境で大きなデータを触れるようにした
3. 全拠点と全部品で1万回を超えるシミュレーションを回した
4. BIツールから大規模データへ直接問い合わせる形にした
5. 購買の履歴から一人ひとりに合う特典を出す仕組みも作った

在庫予測モデルの実行が数日から数時間になり在庫の持ち方が良くなって年間の費用も減った。

250人以上のアナリストと800人の現場のデータ担当者がデータを自分で扱えるようになった。