こんにちは。ナウキャストの Data Holder Unit 所属、マッピングチームでデータエンジニアをしている翁長です。
この記事では、2026 年度の社内 AI コンテストで優勝とテクノロジー賞をダブル受賞（！）した「ローカル LLM を活用したストアブランドマッピング」の取り組みについて紹介させてください。

明細名のカオスをローカル LLM でマッピングする

ﾗｸﾃﾝﾍﾟｲﾕﾆｸﾛｼﾝｼﾞﾕｸﾃ このカオスな文字列、何のブランドかすぐに分かるでしょうか。

答えは――「UNIQLO」です。
このように、クレジットカードの決済データに記録される加盟店の名前（以下、ストア名）は、決済システムが出力する生データそのまま。半角カナや文字切れ・決済手段との混在など、一見では正式なブランド名（ユニクロのように私たちが普段認識している名前）にたどり着けない文字列が日々大量に流れてきます。例えば iD/サンエー Air の本当のブランドは「サンエー」、iD と Air は決済手段。マツキヨ9999*3 は当然マツモトキヨシのとある一店舗ですが、店舗番号がノイズになって普通の Web 検索ではヒットしません。

私たちマッピングチームは、こうした汚いストア名を正しいブランドのマスターレコードに対応づける（マッピングする）システムを運営しており、毎日この種の「機械的に完璧なマッピングが難しいストア名」を月に数百万件単位で人手で読み解き続けてきました。これをローカル LLM でどこまで自動化し、人手のコストをカットできるのか――。今回はその試行と取り組みを紹介します。

なぜローカル LLM なのか

ストア名には、個人事業主の屋号や店舗オーナーの氏名が含まれているケース（例：山田太郎商店 など）もあり、これら決済履歴に紐づくデータは社内で厳格に管理すべき「機密情報」に該当します。そのため、ChatGPT や Gemini のような外部の公開 LLM API にデータを直接送信する選択肢は取っていません。社外秘の機密情報を含みうるデータは、すべて自前の閉じた環境で扱う方針です。

そのため、私たちは推論基盤である LLM を AWS 内の閉域網であるリソースに自前で構築する道を選びました。外への通信を一切持たない閉じた環境で、社内アプリだけがアクセスできる API を立てる形です。

モデルについては複数のオープンソース LLM を継続的にベンチマークしてきました。具体的には、日本語の常識推論能力を測る公開ベンチマーク JCommonsenseQA、実運用を模倣したストアブランドマッピングデータ、Tool Calling（LLM が外部関数を呼び出す機能）テストを揃えた評価スイートで、Qwen3.5 や DeepSeek-R1、Nemotron、Phi-4 といった主要モデルを順次評価しました。その中で 2026 年 5 月時点の我々のユースケースに必要な知識と速度を満たした Gemma 4 を採用しました。AWS のインスタンスサイズは g6e.xlarge。OSS の高速 LLM 推論エンジン vLLM 上で動作し、ランタイムではネットワークアクセスを一切持たない構成です。

「ローカル LLM は遅い、精度も期待できない」と思われがちですが（私もそう認識していた）、現代の量子化技術と vLLM の並列バッチ処理を組み合わせると、その印象はすぐに変わりました。Gemma 4 では、後述するストアブランドマッピング処理で 1,000 件のストア名を 3 分程度で処理できるレベルに達しており、学習データのカットオフは 2025 年 1 月ですが、日本国内の企業情報の知識をデフォルトでも実用レベルで保持していることに驚かされました。また、不足分は Web 検索で知識を補い、LLM 側にヒントを与えたうえで再推論することにより、精度も十分なレベルに達しました。

コストについては、外部の LLM API に比べると圧倒的に割安です。
ストアブランドマッピングを月 100 万件規模で回すことを考えてみます。社内ベンチマークの実測では、このワークロードは 4 つの Step での LLM コール合算で約 50 億トークンを消費し、g6e.xlarge 1 台での処理時間は約 20 時間ほどです。これをコスト効率の良い外部 API（GPT-5.4 mini 相当）に投げたとすると、公開価格をもとにした概算で月およそ 130 万円規模になります。一方、自前の g6e.xlarge はバッチが動いた時間ぶんの従量課金で済み、月およそ数千円規模。同じ処理でも 200 倍近いコスト差が生まれる計算です。

ローカル LLM と進めるストアブランドマッピング

「ストア名 → ブランド情報のマスターレコード」までを特定するのが、私達マッピングチームのストアブランドマッピングと呼ばれる工程です。
単純に「このストア名はどんなブランド？」とプロンプトを投げて一発で済ますことはできません。表記揺れの吸収、決済手段の判別、Web 検索による裏取り、ナウキャストが保持している数万件のブランドマスターレコードへの紐付け。実用ラインに乗せるには、少なくとも 4 ステップに分解する必要がありました。

ここからは具体例として iD/ｷﾂﾞﾅｽｼ ｼﾝｼﾞﾕｸﾃﾝ という 1 件のストア名を起点に、4 ステップが実際にどう動くか見ていきます。

Step 0: ストア名を構造化分解する

最初のステップは、LLM でストア名そのものを 「コア / 決済手段 / 支店名」など様々なパーツに分解することです。

例の iD/ｷﾂﾞﾅｽｼ ｼﾝｼﾞﾕｸﾃﾝ は次のように分解されます。

半角カナの全角化と、決済手段プレフィックスの分離がここで一気に片付きます。地名や店名の漢字推測（例: シンジュクテン → 新宿店）は後段の Step 1 / Step 3 に任せる設計です。

別ステップに切り出した理由は 2 つあります。1 つは入力品質の向上 — 決済プレフィックスや地名というノイズを除去してから次段に渡せば、ブランド推定が格段にきれいになります。もう 1 つは再利用性で、Step 1 のプロンプトを調整して何度も再実行する際に、重い分解処理をやり直さずに済みます。

Step 1: ブランド推定とサブブランドの組み立て

分解結果を入力に、LLM がメインブランド名を推定します。先の例なら、キヅナスシ を受けて、LLM が知識ベースから正式表記を当てに行き、メインブランドを きづなすし と推定します。

ここでストアデータに対し、推論のヒントになりそうな情報を付与することで、LLM の推論精度を上げる工夫もしています。例えば、購入明細の平均単価や購入者の属性など、ブランド推定に効きそうな情報を実証実験の中で判別し、付与することにより推定の精度を高めました。

このステップで工夫したものが、サブブランドを LLM に直接出力させないことです。LLM にサブブランドを任せると、地名や支店名をサブブランドとして出力してしまうケースが頻発し、ノイズとなります。そこでサブブランドはコード側のマッピングリストで組み立てる方針に切り替えました。

具体的には、決済手段の iD → iD、QP / QUICPay → QUICPay のような揺れをすべて正規化テーブルで一つの表記にまとめています。さらに イオンモール / デパート リウボウ のような商業施設名は、ホワイトリストで採用可否を制御。先の例なら、Step 0 で抽出した iD がそのままサブブランド ="iD" として確定するわけです。「LLM が得意な部分」と「ルールベースが得意な部分」を分けることが、後段のナウキャストブランドマスターへの名寄せ精度の向上に繋がります。

Step 2: Web 検索クエリ抽出

ブランド推定の結果を受けて、LLM に Web 検索用のクエリを生成させます。先の例なら、きづなすし 新宿 寿司 公式 のように、ブランドの公式情報にたどり着きやすい単語を組み合わせたクエリに書き換えます。このクエリを Web 検索に投げ、ブランドの公式 HP や SNS にたどり着きやすくします。検索結果は後段の Step 3 での名寄せの際に LLM への追加情報として渡し、精度向上に役立てます。

Step 3: ナウキャストブランドへの名寄せ

推定したブランド名をナウキャストブランドマスターへ紐付けます。ハンズ を 東急ハンズ に、というような表記揺れと正式名称の対応を解く工程です。先の例 きづなすし も、表記揺れを吸収したうえでマスター上の正式レコードに紐付けます。

ここの構成は 3 段です。まず、推定ブランド名とナウキャストブランドマスターの双方を Embedding ベクトル（多言語対応の埋め込みモデル multilingual-e5-small を使用）に変換し、Snowflake の VECTOR 型と類似度関数を使って類似度上位 k 件（top-k 候補）を取得。ベクトル類似度の計算は Snowflake 側で完結させる形です。次に、その top-k 候補に対して LLM がブランド同一性を判定し、matched / unmatched + 確信度 + 判定理由 を返します。最後に、LLM が unmatched と判定したものの top-k の中に類似度が高いブランドが残っているエッジケースについて、Web 検索で追加情報を取得して再推論を実施。

後述のとおり、ナウキャストブランドマスターには既に各ブランドに対して LLM で URL や説明などの情報を付与しているため、LLM での推論は単純な文字列の類似度だけでなく、ブランドの特徴や地域展開などの文脈も踏まえて判断できます。ハンズ というストア名が来たときに、Embedding 類似度では 東急ハンズ が上位に来るのはもちろんですが、LLM が「東急ハンズはライフスタイル雑貨店的な特徴があるけど、今回のストアは文脈的にそれとは違う感じがする」といった判断もできるようになっています。

ここまでで、iD/ｷﾂﾞﾅｽｼ ｼﾝｼﾞﾕｸﾃﾝ というストア名は、Step 0 で キヅナスシ / iD / シンジュクテン に分解され、Step 1 でメインブランド「きづなすし」+ サブブランド「iD」と推定され、Step 3 でナウキャストブランドコードに紐付いて店舗情報と一緒に保存されます。冒頭の ﾗｸﾃﾝﾍﾟｲﾕﾆｸﾛｼﾝｼﾞﾕｸﾃ も、同じパイプラインを通れば Step 0 で ラクテンペイ / ユニクロ / シンジュクテ のような全角カナに正規化され、Step 1 でメインブランド「UNIQLO」（サブブランド「楽天ペイ」）として推定され、Step 3 でマスター上の正式レコードに名寄せされます。

ブランド情報を Web 検索で収集、推論する自動化パイプライン

「このブランド、どこの会社のもので HP・SNS は？」を自動で集める処理です。ブランドの名称だけでは判断は難しいので、ブランドの URL や説明・特徴を Web から取得して、ナウキャストブランドマスターのレコードに情報を付与する工程になります。

ここは 2 つの処理を直列で繋いでいます。前段のブランド URL 検索では、Web 検索でブランドを検索 → LLM が結果から公式 URL や SNS リンクを補完 → もう一度 LLM で確信度スコアを付ける、という処理で HP / X / Instagram / LINE / Facebook の 5 種類の公式 URL を取得。後段のブランド説明文の作成では、取得した公式 HP をクロールし、業種・展開地域・特徴を構造化された情報として LLM に生成させる、という流れです。

「Web 検索 × LLM × クロール × LLM」と並べた小さなパイプラインですが、外部 API は事実情報の取得に、LLM は文脈理解と整形に、と役割を分けています。

各種設計の勘所

上に出した 2 つのパイプライン群の面白いところは、「LLM だけ」でも「Web 検索だけ」でも成立しないところです。

全件を Web 検索で裏取りすれば精度は間違いなく数 % 改善するとは思いますが、API コストも再推論分の時間もそのぶん発生します。そこで確信度 < 90 の低確信度帯にだけ Web 検索を呼ぶ設計にしました。これで API 呼び出しを 70% ほど削減しつつ、改善幅の主要部分を確保できました。やる・やらないの中間に最適点を置いた設計です。

Web 検索に投げるクエリを LLM に生成させる

生のストア名は機密性の観点から、弊社ではそのまま外部 API で送付するべきではないと考えています。分解したストア名から検索に有意義、かつ機密性の低い単語に変換し、LLM がブランド候補を推定し、それを検索に最適化したクエリとして書き直します。これで機密情報の越境を防ぎつつ、単純なストア名を直接 Web 検索に投げるだけの方式に比べると格段に精度が向上しました。

LLM とルールベースの役割分担

サブブランドの組み立てで触れたように、「LLM の柔軟さ」と「マッピングリストの確実さ」を組み合わせてマッピングを実現しています。LLM に判断させる部分を絞り込めば絞り込むほど、品質が安定し、デバッグが楽になっていきます。

すべてを LLM で解決しようとしない

ストア名の品質と出力の正解度次第ではありますが、確信度 ≥ 90 の高確信度帯を自動承認、それ以外を推定理由と Web 検索根拠付きでオペレーター（人間）に確認してもらいます。このような運用前提なら十分に成立します。ヒューマンチェックと LLM の役割分担を最初から織り込み、閾値を調整することで品質とコストのバランスを取る設計です。

まとめ

ここまで紹介してきた事例は、すでに私達のプロダクトに取り入れられ、日々稼働中です。

現時点では実証実験として 15 個ほどの実験が並んでおり、今回紹介した 4 ステップのストアブランドマッピング・ブランド URL 収集・ブランド説明文の生成以外にも、マッピングチームの業務をターゲットにしたローカル LLM を用いた処理を日々開発中。

有望な実験は、社内のマッピングバッチ処理基盤 NEMESIS へ クリーンアーキテクチャ + DDD で移植。各レイヤーに責務を分け直し、テストを付け、Airflow で日次のバッチパイプラインに組み込みます。実験段階で関数単位の責務境界を意識しておくと、この移植が一気に楽になりました。

ローカル LLM での様々な実験、チューニングのコミットが続いており、「アイディアからの実装、PoC、その後何も起きない」ではなく、実験から本番運用まで日常的な開発フローとして止まることなく回せています。

以上が AI コンテストで発表した、マッピングチームで進めているローカル LLM を活用したストアブランドマッピングの取り組みの紹介でした。

なお、ストアブランドマッピングでは、今回紹介した LLM パイプラインのほかに、キーワードと正規表現によるマッチングも併用しています。その Snowflake 上での処理を最適化した取り組みは Snowflake で先読み後読み正規表現を諦めない - RLIKE への分解アプローチ で紹介しているので、あわせてご覧いただけると嬉しいです。

我々ナウキャストのマッピングチームでは、明細データや生データに直接向き合い、様々なマッピング業務の中でローカル LLM 基盤を一緒に育て、新しい角度で生産性を向上させていきたい。そんなエンジニアの方々のご応募をお待ちしています。