DataOps Night 特別編～AI時代のデータエンジニアリング！Local LLM 活用法～

Transcript

1. LLM ストアマッピング カード明細の店舗名を LLM で読み解く ローカル LLM で70 万件を処理する © 2015 - 2026 Nowcast Inc. 1
2. 本⽇お話しすること 1 ナウキャストのData Holder Unitにおけるビジネス戦略 AI時代のデータレイヤーとしてナウキャストが⽬指していくビジネス戦略 2 店舗名をどう読み解くか 分解 → 検索 → 判定 → 運営会社まで、実際の画⾯で追う 3 70 万件をどう処理するか モデル選定‧ローカル LLM の運⽤‧バッチ処理‧コスト 3 まとめ この作りで効いていること © 2015 - 2026 Nowcast Inc. 2
3. ナウキャストのData Holder Unitにおけるビジネス戦略 © 2015 - 2026 Nowcast Inc. 3
4. Finatextホールディングスについて フィンテックソリューションを提供するFinatextグループの会社です 全グループの従業員は411名。福利厚生や、給与水準は全グループ共通です。 親会社 (4419) 事業概要 代表者 金融サービスの開発・運営 木下あかね データ&AIのプロダクトとソリューション 辻中仁士 リテール向けオンライン証券会社 小林紀子 少額短期保険会社 小山宏人 レンディングビジネス 大澤和明 ベトナムの開発チームの統括 Thai Lam © 2015 - 2026 Nowcast Inc. 4
5. 会社概要 ナウキャストはオルタナティブデータを活用した事業や、生成AIを用いて企業のDXを支援 する事業を展開する東大発のスタートアップ企業です クレジットカードデータやPOSデータ、位置情報データといった様々なオルタナティブデータを活用した企業の意思決定をサポートする事業 や、データ基盤構築支援や生成AI開発を通じ、世の中の意思決定を円滑にする事業を展開しております。 社名 株式会社ナウキャスト 代表者 辻中仁士 設立 2015年2月（2016年8月より株式会社Finatextと経営統合） 従業員数 84人(2026年3月末現在) 所在地 東京都千代田区九段北1-8-10 住友不動産九段ビル9F 資本金 70百万円 © 2015 - 2026 Nowcast Inc. 5
6. チーム概要 Data Holder Unit はナウキャストのデータサービスに活用するためのデータ整備を担当 Data & AI Solution Business Data Services Business Investment Research Unit 機関投資家向けに ビッグデータ分析 SaaSを提供。 Economic Research Unit Real Estate Unit 商圏分析や売上予 測モデルによる店舗 物件の診断サービス を不動産会社に提 供。 ビッグデータから計 算したマクロ指数を 官公庁金融機関等 に提供。 Engineering Team データエンジニアリングと生成AI活用に精通し たエンジニアリングチーム。 Consultant Team Data Holder Unit 提供元からデータを受領し、データパイプラインの構築を行うチーム。 データとAIを用いたDXに特化したコンサルティ ングチーム。 Data Service Platform Unit 事業横断でデータ基盤の高度化、R&Dなどを行うチーム。 © 2015 - 2026 Nowcast Inc. 6
7. Data AI Service事業 / Financial Research事業 オルタナティブデータの商社としての機能を持ちます エンドユーザー 官公庁・シンクタンク・投資家 投資家 不動産業界 ライセンスデータ データウェアハウス 解析 POSデータ 日本経済新聞 1,500店舗のスーパーマーケット データホルダー True Data 4,000店舗のスーパー、ドラックストア クレジットカードデータ 求人データ 人流データ TV広告データ JCB フロッグ KDDI エムデータ 130超の日本の web求人広告 サイト 携帯搭載の 地理データ 日本の全無料 チャンネルの TV広告データ JCBカードの 所有者・加盟店 他カード会社 BCN 2,600店舗の家電小売 © 2015 - 2026 Nowcast Inc. 7
8. AIの発展に伴うデータビジネス市場の変化 AIエージェントでの公開データ収集プロセスにおいて、以下のような課題が発生している 網羅的にデータを収集できない ヒストリーを遡って収集できない 個別企業などのユースケースには向いているが、ある特定のセ グメント(業種‧従業員規模‧売上規模等)を網羅的にデータ収 集することは難しい 分析に複数年のデータを活⽤したい場合、特定の年数しか遡れ ない、途中のとある年数が⽋落するなどの事象が発⽣する データが最新なのかの判断が難しい 権利が未整理 古いデータをとってきている場合に、情報元の発信⽇が判明し たとしても、最新の情報なのかはわからない エージェントが収集したデータは、著作権や肖像権などの整理 が曖昧なため、2次利⽤時のリスクが付き纏う AIのトークン使⽤料を最適化できない ソースが正しいかがわからない AIエージェントを⾃由にした場合、調査にトークンを消費しす ぎてしまう。制限内での調査では欲しい情報に到達しないな ど、コスト対⽐のアウトカムを最⼤化することが難しい AIのスクレイピング対象サイトの信頼性やハルシネーションを 防ぐ仕組みの構築を⾏うことが難しい © 2013 - 2026 Finatext Ltd. 8
9. AIの発展に伴うデータビジネス市場の変化 一方で内部データでは、以下のような課題が見受けられ、収集した外部データと簡単に紐づけられる わけではない データクレンジングの 膨大な工数 SFA/CRMの データの汚れ ✔ ✔ 営業の手入力に起因する重複レコードの発 生。表記揺れ<(株)と株式会社など>による 名寄せの限界 HPやMAツールからのデータ流入時に、同 名企業が別々のレコードとして流入 ✔ ✔ カナと漢字など、表記揺れのあるデータを マッピングする必要がある。 データをクレンジングする中で、業種やブラ ンドなど複数の階層を構造化する際の膨大 な工数 © 2015 - 2023 Nowcast Inc. システムの サイロ化 ✔ 社内システムに別々に格納されているデー タが紐づかないことで、部署間やグループ 間で法人にアプローチすることができない CONFIDENTIAL 9
10. AIの発展に伴うデータビジネス市場の変化 AI検索が増えた未来で発生すると考えられること ファクトに基づかない AIアウトプットが 社会に大量流通する AIがインターネット上の情報を消費し、同時に新たな情報を ⽣み出すようになる中で、ウェブはより⼤きく、より速く、 そしてよりノイズの多いものになっていく AIの賢さが上がっても、誤情報を与えられている場合におい ては、得られるアウトプットは精度が⾼いものではない ファクトに基づいたデータを 整備していることが価値の源泉になる AIが適切なアウトプットを出すために、 • 最新 • 正確 • ソースが明確 • 権利が適切 • カバレッジの広い そんなデータレイヤーを備えることが重要 © 2013 - 2026 Finatext Ltd. 10
11. 市場の変化を踏まえた AI時代のデータビジネス AI時代においては、単にデータを提供するだけでは価値が出にくくなっている。 従来 AI時代 企業が求めるのは、信頼性の高いデータをAIや 業務システムにそのまま接続でき、継続的に更 新・運用できるデータ活用基盤モデル データそのものを販売するモデル © 2013 - 2026 Finatext Ltd. 11
12. DHUが目指すビジネスの方針 • 全体感 ◦ AIの発展により、企業の競争力はAIモデルそのものではなく、AIが活用するための データをどれだけ整備・接続・運用できるかに移行している。 ◦ この変化により、データビジネスは単なる「データ販売」から、企業がAIや業務システム に継続的に活用できる「 AI-readyなデータ活用基盤」の提供へと変化 している。 ◦ DHUは、これまでデータ開拓・整備・提供・ソリューション化を担ってきた実績を活かし、 AI時代における企業のデータ活用を支える「 AI-readyデータレイヤー」として、 サービ スを展開する ※AI-readyなデータとは、AIや業務システムが継続的に利用できるように、名寄せ、構造化、 更新、権利処理、業務ロジックとの簡単な接続がなされたデータとして定義 © 2013 - 2026 Finatext Ltd. 12
13. 本方針に対してのローカル LLMの活用ユースケース これまでのデータクレンジングで培った知見やスキルを、他社向けのサービスとして展開 名寄せアプリケーション ✔ ✔ 新規ブランドの追加などの定常業務と承認プロセスの ワークフローを管理する アプリケーションを提供 ローカル LLMなどの新しい技術も取り入れることで、高 いセキュリティ要件と業務効率化を両立 データ分析機能提供 ✔ ✔ © 2013 - 2026 Finatext Ltd. クレンジングしたデータをリアルタイムで分析可能な機能を 提供 ナウキャストの3rd partyデータを併用することで、他社との シェア率比較などより実用的な分析を可能に 13
14. 店舗名をどう読み解くか © 2015 - 2026 Nowcast Inc. 14
15. この明細、どこで何に使ったお⾦でしょう？ ＱＰ∕CA4LA 池袋店 決済記号‧略語‧全⾓半⾓の混在。こうした店舗名が毎⽇⼤量に流れてくる ブランド‧業種‧運営会社が特定できて、はじめて分析に使えるデータになる © 2015 - 2026 Nowcast Inc. 15
16. この紐付けは、もともと⼈が1件ずつやっている LLM は、その作業をそのまま⾃動化している ⼈がやっていること 追いつかない理由 • 明細の店舗名を⾒て、社内のブラン • 新しい店舗は毎⽇発⽣する • • ド台帳のどれに当たるかを判断する 確定した結果は台帳に登録され、分 析に使われる 有名チェーンは正規表現ルールで⾃ 動化できるが、新しい店‧⼩さな店 はルールが作れない LLM との分担 • LLM が判定し、確信度が⾼いものは • • そのまま確定する 確信度が低いものだけ⼈が確認する ⼈が確定した結果は、LLM の精度を 測る正解データにもなる 全部を⾃動化するのではなく、⼈が⾒る件数を減らすのが⽬的 © 2015 - 2026 Nowcast Inc. 16
17. 全体像 — ⼈間が知らない店を調べる⼿順と同じ 決済データを外に出せないので、ローカル LLM で組んでいる ① 分解 ② 推定‧候補検索 ③ 判定 ④ 業種‧運営会社 店舗名を 決済記号 / 店名 / ⽀店名 に切り分ける ブランド名を推定し、 台帳から似た候補を引く 候補の中から 「同じブランドか」を LLM が判定する 業種を判定し、 運営会社を法⼈番号まで 特定する ▶ （Cortex Search） ▶ ▶ LLM に⼀発で解かせず、検索と LLM を交互に挟んで絞り込む 各段が判定理由と確信度を返すので、どの段で失敗したかが後から特定できる © 2015 - 2026 Nowcast Inc. 17
18. ① 分解 → ② 候補検索 — 切り分けて、台帳から候補を引く ① 分解 → ② 候補検索 ③ 判定 ＱＰ∕CA4LA ④ 業種‧運営会社 池袋店 デモ画⾯ — 分解結果と、台帳の検索結果 決済サービスの記号 ＱＰ（QUICPay） 店名 / ⽀店名 CA4LA 候補 1 CA4LA（カシラ） 候補 2 / 候補 3 類似する別ブランド名 / 池袋店 ここで候補を1つに絞らない。絞りすぎると、落とした正解は取り戻せない © 2015 - 2026 Nowcast Inc. 18
19. ③ 判定 — 「同じブランドか」を理由付きで決める ① 分解 → ② 候補検索 ③ 判定 ④ 業種‧運営会社 デモ画⾯ — 判定結果 判定 CA4LA に確定 確信度 100（完全⼀致） 判定理由 店名が台帳のブランド名と完全に⼀致するため 似ているかではなく、同じブランドかを意味で判断する 判断がつかなければ「該当なし」を返す © 2015 - 2026 Nowcast Inc. 19
20. ④ 業種‧運営会社 — 法⼈番号まで特定する ① 分解 → ② 候補検索 ③ 判定 ④ 業種‧運営会社 デモ画⾯ — 最終結果 ブランド CA4LA 業種 服飾‧雑貨 運営会社 株式会社カシラ（法⼈番号まで付与） 冒頭の「ＱＰ∕CA4LA 池袋店」が、ここまで埋まりました 台帳に無いブランドは、Web 検索で運営会社を調べて企業データと照合する © 2015 - 2026 Nowcast Inc. 20
21. 候補検索は Snowflake の Cortex Search Service 検索⽤のデータベースを別に⽴てず、データウェアハウスの中で完結させた やっていること 移⾏前 • ブランド台帳をそのまま検索⽤の索引にする • 全店舗 × 全ブランドの総当たりで突き合わせ • • ベクトル検索とキーワード検索を組み合わせる 台帳を更新すると索引が⾃動で追従する • 70 万件規模では約 47 時間かかっていた 約 47 時間 → 78 分 +16 ポイント 70 万件の処理時間 上位3件に正解が⼊る割合 © 2015 - 2026 Nowcast Inc. 21
22. 台帳で埋まらない店は、Web 検索で補う どの店舗で検索するか、結果をどの段に渡すかで、効き⽅が変わる どの店舗で検索するか • • • 何を検索するか LLM の確信度が低い店舗を対象に したが、効果はなかった 確信度は、正解しているかどうかと ほとんど関係がない 候補1位と2位のスコアが近い店舗 を対象にすると効いた • 店舗名そのままでは検索しない。推 • 定したブランド名で検索する 外に出る情報が減り、検索の精度も 上がる 結果をどう使うか • • • ブランド名の推定ではなく、判定に 渡す（表記のズレが起きない） Google の AI 要約（AI Overview） も取得する。返るのは 5〜6 割で、 取得できた時だけ課⾦される 1クエリ $0.0006。全店舗で検索し ても⽉ $420 程度 検索する店舗は、LLM の⾃⼰申告ではなく、検索結果のスコアで選ぶ © 2015 - 2026 Nowcast Inc. 22
23. 70 万件をどう処理するか © 2015 - 2026 Nowcast Inc. 23
24. モデルは、⾃分たちで測って選んだ ベンチマークの順位ではなく、この業務で使えるかどうかで決めた Gemma 4 を採⽤ 1台の GPU に載る範囲で、⽇本語とこの業務のデータで⽐較して決めた ⽐べたモデル 測った軸 • Gemma 4 / Qwen3.5 / DeepSeek-R1 / Nemotron / Phi-4 • ⽇本語の常識推論（JCommonsenseQA） • 1台の GPU に載る範囲で、⽇本語が扱えるものを候補にした • • 実際のマッピングデータでの正解率 Tool Calling が使えるか © 2015 - 2026 Nowcast Inc. 24
25. モデルを⼤きくするより、推論の効率を上げる 1台の GPU で全件を処理するので、推論の効率がそのまま処理時間になる 構成 投機デコーディングを有効にする • AWS の g6e.xlarge を閉域網に置き、vLLM を動かす（外部 • • への通信なし） OpenAI 互換の API で叩く 本番は 30 並列。1台に集中するので、上げすぎても待ち⾏列 が伸びるだけ • • • 次の数トークンを先読みし、本体モデルでまとめて検証す る。当たれば1回の推論で複数トークン進む 先読み⽤の別モデルは使わず、⼊⼒に出てきた並びをそのま ま候補にする（n-gram ⽅式） 店舗名や候補ブランド名がそのまま出⼒に現れるので、当た りやすい 約 17% ⾼速化 3トークン先読み‧採択率 43.8%‧GPU の追加なし © 2015 - 2026 Nowcast Inc. 25
26. 70 万件を処理するための3つの⼯夫 速くする前に、まず LLM を呼ぶ回数を減らす 減らす 同じ店舗名は重複を排除してから処理する。過去分の⼀括処理では対象が半分以下になった まとめる 検索は1件ずつ呼ばず、⼀括処理する関数に置き換えた。1件あたり 253 ミリ秒 → 6.6 ミリ秒 使い回す 分解の結果はキャッシュする。同じ店舗名が再び来たら LLM を通さない © 2015 - 2026 Nowcast Inc. 26
27. ローカル LLM だと、コストの構造が変わる 商⽤ API は処理した件数だけ増える。ローカル LLM は台数を増やさなければ増えない 商⽤ API を使う場合 ローカル LLM を使う場合 1件ごとにトークン単価がかかる。この規模で試算すると ⽉ 130 万円ほど かかるのは GPU インスタンスの費⽤だけ。同じ台数なら件数が 増えても変わらず、⽉ 数万円 処理件数 → 処理件数 → その差、数⼗倍。全件を処理し続ける⽤途では、これがそのまま効く © 2015 - 2026 Nowcast Inc. 27
28. まとめ © 2015 - 2026 Nowcast Inc. 28
29. この作りで効いていること 他の領域でも、そのまま使える形にするとこうなります ① 候補は広く出す ② 段を分ける • 絞るのは検索ではなく判定側 • 各段が理由と確信度を返す • 検索で落とした正解は、あとの処理 では取り戻せない • どの段で失敗したかが分かり、段ご とに直せる ③ LLM を呼ぶ回数を減らす • 速くする前に、LLM を呼ぶ回数その • ものを減らす 重複の排除‧キャッシュ‧⼀括処理 決済データを外に出せない制約の中で、70 万件をローカル LLM で処理しています © 2015 - 2026 Nowcast Inc. 29
30. © 2015 - 2026 Nowcast Inc. 30