koki's blog

AI

「誰を推測するか」から「購入の意味」へ――銀行規模のLLMプロファイリング

ユーザー単位のLLM推論を取引パターン単位へ置き換え、検索可能な属性データベースを構築する研究を、手法、評価、実運用、再現性から解説します。

Xでシェア
目次

AI利用の明示

本記事の構成と本文は、OpenAIのコーディングエージェント「Codex」が作成しました。人間による内容確認はまだ実施していません。数値や主張は原論文と公開実装を確認して記載していますが、利用時は原文も確認してください。

この研究の価値は、購買履歴を読むLLMの推論単位をユーザーから、複数ユーザーに共有される取引パターンへ変えたことにあります。モデルを軽量化するのではなく、同じ意味を何度も推論しない設計によって、数千万人規模の処理を可能にしています。

取り上げるのは、Ryota Mitsuhashi、Tetsuro Morimura、Hirotake Itoによる「From “Who Is This User?” to “What Does This Purchase Mean?”」です。2026年9月17日にarXiv v1が公開され、ICDM 2026 Applied Research trackに採択されています。本稿では論文PDFと公式実装をもとに、仕組み、評価、実運用、再現可能な範囲を整理します。

1人ずつLLMに読ませる設計は大規模化しにくい

購買履歴から「幼い子どもがいる家庭」「健康を意識した生活を送る人」のような自然文のプロファイルを作るなら、各ユーザーの履歴をLLMへ渡す方法が最も素直です。しかし、この方法には三つの問題があります。

第一に、推論回数がユーザー数に比例します。論文は、数千万人のユーザーへ1人あたり1回推論するだけでも、公開APIの代表的な料金と1人あたり数千トークンという仮定では、全件処理が数万〜数十万ドル規模になり得ると試算しています。履歴が増えるたびに更新対象も生じます。

第二に、同じような購入をした人でも、LLMが生成する表現は揺れます。「子どもの教育を重視する親」と「教育熱心な保護者」は意味が近くても、文字列としては別物です。横断検索には別途、表現の正規化が必要になります。

第三に、毎回ユーザーの全履歴を読むと、過去に解釈済みの購入を繰り返し処理します。共通する行動が多いほど、重複計算も大きくなります。

論文は、この問題を問いの立て方から変えます。

従来: このユーザーはどのような人か？
提案: この購入パターンは何を意味するか？

ユーザー数を N、共有される取引パターン数を P とすると、LLM推論の対象は概念的に N 件から P 件へ変わります。人気商品へ行動が偏り、一定以上の頻度を持つパターン数が飽和する環境では、Pはユーザー数ほど速く増えません。

関連研究の中で何が新しいのか

購買・取引履歴から属性を得る研究は、本論文以前にも固定属性の分類、系列の埋め込み、LLMによる人物像生成などへ発展してきました。論文が新しく組み合わせたのは、取引パターン単位の推論と、固定選択式・自由記述式・属性別スコアを同時に生成する出力形式です。

方式 主な出力 推論単位・大規模化の方法 本論文との違い
固定属性の分類 年齢・性別などの固定ラベル ユーザー単位。教師あり分類 読みやすいが、事前定義した属性から出られない
取引系列の埋め込み 数値ベクトル ユーザー単位。自己教師あり学習など 下流処理には使えるが、自然文で直接検索しにくい
LLMによる人物像生成 自然文の人物像・ラベル ユーザー単位で生成し、類似度グラフなどで伝播 読みやすいが、初期表現はユーザーごとに作る
TnT-LLM LLMで作った分類体系のラベル 分類体系を生成後、軽量分類器へ蒸留 大規模化できる一方、出力は生成した分類体系に固定される
LLM4ES ユーザー埋め込み 取引系列でLLMを追加学習し、ユーザーごとに埋め込みを抽出 自然文属性ではなく、内部表現を利用する
個別のライフイベント検出 引っ越し・出産など固定イベント 業務固有の特徴量とイベント別モデル 対象イベントが限定され、統一プロファイルではない
本論文 固定属性＋自由文属性＋属性別スコア 複数ユーザーに共有される取引パターン単位 1回の推論で検索可能な複合表現を作る

これらはデータ、正解ラベル、評価目的が異なるため、表は精度の優劣ではなく設計上の位置付けを示しています。論文自身も、従来のライフイベント検出器や非LLM分類器との直接的な数値比較は行っていません。

Resolve・Profile・Tagの3段階

論文上のパイプラインは、商品や取引先の意味を整えるResolve、属性を生成するProfile、自由文を検索可能な語彙へまとめるTagで構成されます。

取引履歴
  ├─ Resolve: 商品名を解釈し、属性推論に必要な意味へ抽象化
  │       ↓
  │   単一商品の推論入力
  │
  └─ 頻出パターン抽出: 同時購入された商品の組み合わせを抽出
          ↓
      複数商品の推論入力
          ↓
Profile: パターンごとに固定属性・自由文属性・事前スコアを生成
          ↓
Tag: 自由文属性をクラスタ化してタグを付与
          ↓
パターンの結果をユーザーへ集約した属性データベース

この図では、単一商品と複数商品の二つの経路を分けています。論文の概念説明ではResolve・Profile・Tagという3段階に整理されていますが、公式実装の頻出組み合わせ抽出はResolveの後に直列実行されるわけではありません。生の購入データからFP-Growthで独立して実行され、事前計算した組み合わせをProfile相当のpredict_user段階が読み込みます。単一商品はResolve系の処理を通り、複数商品パターンは別経路から合流します。

Resolve：推論前に商品の意味を整える

商品名や銀行の取引先名には、略称、表記揺れ、ブランド、容量、包装といった情報が混在します。Resolveは商品ごとに外部情報が必要かを判断し、必要な場合だけWeb検索を使います。検索結果から根拠となる短い記述を選び、属性推論に有効な意味を残した表現へ書き換えます。

この段階は適合率を重視します。特定の人物属性を示す材料がない商品では棄権でき、曖昧な情報を無理に後段へ流しません。銀行で一意に取引先を特定できない場合も、そのパターンは推論対象から除かれます。

Profile：パターンごとに複合的な属性を作る

Profileでは、単一商品に加え、複数ユーザーに出現する商品の組み合わせも推論対象にします。組み合わせを使う理由は、単品よりも共起に意味があるからです。たとえば、粉ミルク、おむつ、ベビーベッドの同時購入は、それぞれを単独で見るより最近の出産を強く示唆します。

各パターンについて、LLMは1回の呼び出しで次の情報を生成します。

出力 役割
固定選択式属性 事前に定義した選択肢へ分類する。各項目に「不明」を持つ
自由記述式属性 固定スキーマへ収まりにくい人物像を短い自然文で表す
prior π(d) そのパターンの購入者に自由文属性dが当てはまる強さを0〜1で表す

公開データ用の固定スキーマは、人口統計7項目、心理・行動4項目、ライフイベント8項目です。自由記述式では各カテゴリで0〜3件の候補を生成します。固定選択肢は評価と集計を安定させ、自由文は固定分類では列挙しきれない長い裾の属性を補います。

π(d)は、論文がpriorと呼ぶ属性別の事前スコアです。利用時に高い閾値を使えば弱い推測を除きやすくなり、低くすれば候補を広く拾えます。ただし、校正済み確率ではありません。π(d)=0.8を「80%の確率で本人に当てはまる」と解釈することはできません。

Tag：自由文を検索できる単位へまとめる

自由文属性は柔軟ですが、同じ意味でも表現が変わります。そこでTag段階では、属性文を文埋め込みモデルで数値化し、UMAPで次元削減し、HDBSCANでクラスタ化します。最後にLLMが各クラスタを短いタグ名へ要約します。

公開データでは、ノイズと判定されたクラスタを除いて76タグが作られました。内訳は人口統計23、心理・行動23、ライフイベント30です。97,801商品のうち62,447商品、63.9%に少なくとも1タグが付き、1商品あたりの平均は1.05タグでした。

こうして得られるのは、元の履歴を完全保存した表現ではありません。具体的な商品名を属性へ変換し、さらにクラスタへまとめるため、情報は圧縮されます。その代わり、ユーザーを自然言語のタグで検索し、同じ概念を持つ集団として集計できるようになります。

複数パターンの属性をユーザーへどう集約するか

1人のユーザーは複数の商品・取引パターンに一致するため、パターンごとの出力が食い違うことがあります。論文の固定属性評価では、属性の性質に合わせて次の規則を使い分けます。

属性 パターンからユーザーへの集約 競合した場合の意味
転居 OR 一つでも「転居あり」のパターンがあれば陽性とする
年齢・収入 階級の代表値に対する加重中央値 極端な少数票へ引かれにくい中央の階級を選ぶ
性別・教育 最頻値 一致パターンから最も多く出た選択肢を採用する

たとえば、年齢について複数パターンが25–34、25–34、35–44を示せば、階級の代表値を使った加重中央値は25–34側になります。教育で「学士」が3票、「大学院卒」が1票なら最頻値の「学士」を採ります。転居は頻度ではなく、一つでも陽性なら陽性です。

自由文属性では、同じ属性が複数パターンから出たときにπ(d)を重みとして使います。属性ごとのスコアを保持することで、利用時に閾値を変え、候補の広さを調整できます。論文はこれを確率とはみなさず、順位付けに使える情報かを別途検証しています。

この集約は、ユーザー履歴をもう一度LLMへ渡して統合する処理ではありません。パターン生成時の結果を決定的な規則でまとめるため、既知パターンに一致するユーザーを追加しても、ユーザー単位のLLM推論は増えません。

公開データの評価設計

評価にはOpen E-Commerce 1.0が使われています。Amazonの購入履歴と自己申告アンケートを組み合わせたデータセットで、約5,027人、約185万件の購入、97,801商品を含みます。商品を3人以上が購入していることなどの絞り込み後、固定属性の評価には4,990人、タグを用いる評価には3,781人が使われました。

論文の中心的な問いは、属性データベースへ圧縮した後も、生の履歴が持つ情報を保てるかです。ただし、固定属性とタグ属性では、評価時のLLMの使い方が異なります。

評価 対象属性 生履歴側 属性DB側 指標
固定属性評価 年齢、性別、収入、教育、転居 LLMが生履歴から属性を直接予測 OR・加重中央値・最頻値で集約。評価時の追加LLM推論なし macro-F1、F1、MAE、順序尺度MAE
タグ属性評価 喫煙、飲酒、糖尿病、車いす利用、出産、妊娠、転居、失職、離婚など10属性 LLMが生履歴を読み、各属性の確率を出す 同じLLM・同じプロンプト形式が、タグ＋固定属性を読み確率を出す 属性別AUCとmacro-AUC
タグのみの除去実験 上記10属性 比較用の生履歴入力 固定属性を除き、タグだけを同じLLMへ渡す 属性別AUCとmacro-AUC

固定属性評価は意図的に非対称です。生履歴側にはLLMを使いますが、データベース側は前節の規則だけで答えを決めます。一方、タグ評価は入力表現以外の差を減らすため、両側に同じLLMを評価役として使います。

生履歴入力は競合製品ではなく、圧縮前の多い情報を持つ参照入力です。また、タグ評価では「タグ＋固定属性」の複合入力と「タグのみ」を比べ、固定属性が追加情報を持つかも確認しています。

固定属性の結果

  • 性別のmacro-F1は0.814から0.794
  • 収入の順序尺度MAEは1.252から1.272階級
  • 年齢MAEは8.22年から8.80年
  • 転居F1は0.128から0.287

転居のF1改善は、再現率が0.079から0.318へ上がった一方、適合率が0.337から0.262へ下がった結果です。候補を広く拾う方向に変わったため、用途によって良し悪しが異なります。

教育の順序尺度MAEも0.900から0.815へ小さくなりましたが、Spearmanの順位相関は0.154から0.038へ低下しました。最頻値による集約が中央付近へ予測を寄せた影響とされており、MAEだけから情報保持が改善したとは言えません。

タグを使う10属性の結果

同じLLMを評価役として使った10属性のmacro-AUCは次の通りです。

入力 macro-AUC
生の購入履歴 0.611
タグのみ 0.593
タグ＋固定属性 0.611

生履歴と「タグ＋固定属性」の属性別AUCを比べたWilcoxon符号付順位検定はp=0.922で、有意差は検出されませんでした。ただし、これは同等性試験ではありません。「差が見つからなかった」ことと「同じ性能だと証明した」ことは区別する必要があります。

属性別では、出産が0.791から0.743、妊娠が0.816から0.780へ下がりました。特定商品が強い情報になる属性では、商品名をタグへ圧縮する損失が表れています。失職と離婚は、全入力で95%信頼区間が偶然水準の0.5をまたぎました。

「タグ＋固定属性」は「タグのみ」を10属性中9属性で上回り、macro-AUC差は+0.018、Wilcoxon符号付順位検定はp=0.004でした。固定属性と自由文タグを組み合わせる設計には、タグだけでは持たない情報があることを示す結果です。

事前スコアは属性によって有効性が異なる

π(d)が自己申告の陽性・陰性を分けるかは、妊娠、車いす利用、糖尿病の3属性で検証されました。車いす利用はp=2.3×10^-4、Cliff’s δ=0.334、糖尿病はp=8.6×10^-3、δ=0.221でした。妊娠はp=0.17、δ=0.10で有意ではありません。

したがって、事前スコアには順位付けに使える情報が含まれる場合がありますが、すべての属性へ一律に使えるわけではありません。論文も確率としての校正は検証していません。

銀行では約5万パターンへ圧縮した

論文は、日本の大手銀行で稼働するシステムも報告しています。対象は数千万人規模です。Amazon商品とは異なり、銀行では「取引先口座名と入出金方向の組」をパターンとします。同じ企業でも、支払った人と報酬を受け取った人では役割が変わるためです。

半角カタカナの取引先名は、全文検索エンジンのTantivyとgBizINFOを使って法人名へ解決します。実運用の固定スキーマも公開データ用とは異なり、職業、常勤、非常勤、学生、退職者、子どもの有無、教育志向の7項目です。

頻出パターンが元の取引の約95%を覆うように閾値を設定すると、数千万人のユーザーが約5万パターンへ圧縮されました。論文の報告値は次の通りです。

指標 報告値
LLM推論対象数 ユーザー単位方式の約1/600
推定費用 トークン数と単価を同じと仮定したユーザー単位方式の約1/300
取引先を一意に解決できないパターンを除いた取引カバー率 82.6%
生成された意味タグ 約149

銀行データは機密のため、個人ごとの属性正解率や生の取引は公開されていません。約600倍の圧縮は実運用での処理規模を示す値であり、予測精度の検証はOpen E-Commerce上の実験に基づきます。この二種類の根拠を混同しないことが重要です。

また、同じ取引先でも方向によって異なるプロファイルが生成されます。家事代行、ベビーシッター、介護支援を提供する企業なら、出金側ではサービス利用者、入金側では従業員や業務委託者が候補になります。パターン定義に業務固有の文脈を含める重要性が分かる例です。

論文が示す限界

取引パターン方式は、複数ユーザーに共有される行動が多いほど有効です。反対に、希少な商品に重要な情報がある場合、購入順序や時刻が重要な場合、同じ商品でもユーザー固有の文脈で意味が変わる場合には、情報を失いやすくなります。

論文のパイプラインは時刻を入力として使わないため、「いつ買ったか」「どの順序で買ったか」を直接扱えません。頻出パターンへ絞ることで希少商品も落ちます。論文は、希少だが重要な履歴を持つユーザーだけユーザー単位推論へ戻す構成を将来の選択肢として挙げています。

評価にも制約があります。タグ評価の対象者は、評価する自己申告属性のうち少なくとも一つが陽性のユーザーへ限定されています。同じQwen3.5-27Bがデータベース構築と評価の両方へ使われるため、プロンプトを揃えて位置や文章量の偏りを抑えても、自己選好の偏りは残ります。非LLM分類器との対称比較、Resolve・Profile・Tagの要素別除去実験、モデル間比較、集約規則の比較は今後の課題です。

プライバシーについて、論文は購買や送金から人物属性を推測する処理がattribute inference attackと同じ構造を持つと明記しています。性的指向はスキーマから意図的に除外し、銀行では取引を外部へ出さず、オンプレミスのQwen3-30B-A3B-Instruct-2507を使っています。それでも、属性を広告配信へ使うことで、住宅や雇用などの機会が不公平に配分される可能性は残ると論じています。

ここからは導入上の考察

以下は論文で実証された結果ではなく、公開された設計と限界を踏まえた本記事の提案です。

導入判断では、まず利用者数を増やしたときに頻出パターン数が本当に飽和するかを測る必要があります。取引件数のカバー率だけでなく、少なくとも一つ有効なパターンへ一致するユーザーの割合も確認します。希少な取引が重要な業務では、該当ユーザーだけをユーザー単位推論へ送る補完経路が必要です。

品質監視では、商品・取引先の解決、属性生成、クラスタ割り当て、タグ命名、ユーザー集約を分けて記録すると、誤りがどこで生じたか追跡できます。特に集約規則は属性ごとに挙動が異なるため、平均指標だけでなく、順位相関、適合率・再現率、棄権率も見るべきです。

運用規程としては、推論しない属性、利用可能な目的、閲覧権限、保持期間、監査記録、本人による訂正や異議申立て、誤推論時の救済を定める必要があります。これらは論文が評価したモデル性能とは別の論点です。オンプレミス処理はデータ流出リスクを下げますが、推論と利用の正当性までは保証しません。

まとめ

この研究が示したのは、LLMの費用問題をモデル選択だけで解く必要はないということです。ユーザーごとに繰り返していた意味解釈を、共有可能な取引パターンへ移せば、推論結果を再利用し、一貫した属性語彙として検索できます。

一方、属性データベースは生の履歴を情報損失なく置き換えるものではありません。商品名、希少商品、時系列、個人固有の文脈を落とす代わりに、費用、検索性、一貫性を得る設計です。公開データでは生履歴と「タグ＋固定属性」のmacro-AUCがともに0.611でしたが、属性別には損失があり、同等性が証明されたわけでもありません。

実運用で問うべきなのは、「プロファイルを作れるか」だけではなく、どの意味を共有してよいか、どの情報を捨ててよいか、その推測を何に使ってよいかです。推論単位の変更は処理規模の問題を緩和しますが、プロファイルの妥当性と利用責任は別途設計しなければなりません。

補足：公開実装を試す

profiling-agent-open-ecommerceは、Open E-Commerce向けのパイプライン、設定、サンプル結果、オフラインテストをApache-2.0で公開しています。銀行向けのデータと実運用コードは含まれません。対応環境はUbuntu 24.04 LTSのx86_64で、macOSとWindowsは未検証です。

uv sync
uv run scripts/open_ecommerce/local/download_dataset.py
uv run python -m unittest tests.e2e.test_pipeline_e2e -v

オフラインテストは、LLM応答、検索結果、埋め込みを固定データへ置き換え、7段階のファイル入出力が接続されることを確認します。モデル品質や論文の数値を再現するテストではありません。

リポジトリの既定モデルは生成用のQwen3.5-4Bと埋め込み用のQwen3-Embedding-0.6Bです。論文の公開データ実験はQwen3.5-27Bとplamo-embedding-1bを使い、単一のNVIDIA A100 80GBで属性データベース構築に約33 GPU時間を要しました。Web検索も既定はDuckDuckGoですが、論文条件の再現にはSerper APIが指定されています。したがって、既定設定を実行しただけでは論文と同条件の再現にはなりません。

公開済みの複合パターンは2〜4商品からなる541件です。前述の通り、この組み合わせ抽出は生の購入データから独立して実行され、predict_userが結果を読み込みます。まずオフラインテスト、次に10件のサンプル、件数を制限した部分集合、全データの順に広げると、各段階の出力を確認しやすくなります。

参照