社内資料を探すAIに、顧客や注文の記録から予測する道具を足す

文書の回答に、業務の予測を組み合わせる

社内AIへ「来月、どの顧客へ先に連絡すべきか」と頼む。 顧客対応の規程は探せても、それだけでは優先順位は決まらない。 過去の注文を集計し、今後の購入を予測し、担当者が連絡できる件数まで考える必要がある。 これは本稿が置く想定業務だが、文書を読む仕事から予測を使う仕事へ進むとき、何が増えるかを具体化できる。

NVIDIAが10月21日に発表したAgent Toolkitの拡充は、この組み合わせを製品構成として示している。 Agent Knowledge Foundationには、関連情報を探すNemotron Retrieverと、構造化データから予測するKumoが並ぶ。 表を文章へ変えてLLMへ読ませる方法に加え、データの形に合う予測モデルを道具として呼ぶ選択肢がある。

発表日と技術の登場日は分けておきたい。 Kumo Tabularの技術発表は9月29日で、Kumo Anomalyのモデルカードには6月29日という公開日がある。 今回の発表で注目するのは、すべての予測技術が新しく生まれたことではなく、検索と予測を企業向けエージェントの構成にまとめて提示した点だ。

顧客への連絡を決めるまでに必要な三つの答え

冒頭の依頼には、性質の違う三つの問いが含まれる。 「連絡するときの社内ルールは何か」「最近、誰の注文が減ったか」「これから誰の注文が途絶えそうか」だ。 担当者が最終的に一枚の候補一覧を見るとしても、各欄を作る方法と確かめ方は異なる。

検索した文章を生成の根拠に使う検索拡張生成（RAG）は、原論文でも外部の情報を参照して回答を生成する仕組みとして扱われる。 そこへ注文の集計や予測結果を渡せば、LLMは説明をまとめられる。 ただし、説明が自然に読めることから、元の予測がよく当たるとは判断できない。

SQLも予測モデルを呼んだり、保存済みの予測結果を取り出したりできる。 ここで区別したいのは言語や画面の種類ではなく、返した値が「記録の計算結果」か「まだ確定していない結果の推定」かである。 筆者は、この区別を説明文にも残すことが、予測する道具を業務AIへ足す際の出発点だと考える。

一枚の表と、顧客から注文へつながる表

予測を別の道具へ渡す場合、入力も文章とは変わる。 Kumo Tabularには、答えが分かっている行と、答えを予測したい行を分けて渡す。 分類なら各クラスの確率、回帰なら数値を返す。 事前学習済みのモデルが既知の例を参照して新しい行を予測する文脈内学習なので、利用のたびにモデルの重みを更新する必要はない。

ただし、顧客の情報は一枚の表に収まるとは限らない。 顧客表に一人一行、注文表に一注文一行、商品表に一商品一行があり、それぞれを識別子で結んでいる場合がある。 単一表の予測へ渡すなら、購入回数や最後の注文からの日数などを先に集計する方法を取れる。 どの期間をまとめるかによって、予測へ渡る情報も変わる。

Kumo Relationalは、関連する複数の表を使う予測に対応する。 モデルカードは、行の表現と、関係を通じて情報を渡す処理を組み合わせると説明する。 基になったKumoRFM-2の論文では、表を手作業で一枚に平坦化せず、関連する記録と時刻を扱う設計を示している。 この方法では、どの関係をたどれば予測に役立つ記録へ届くかが重要になる。

表をまとめる作業が減っても、データの意味を決める作業は残る。 列の意味を扱う公式文書や時刻列の文書があるのは、そのためだ。 注文を結ぶ顧客ID、金額の単位、行が利用可能になった時刻が誤っていれば、モデルに渡す記録も変わる。 「学習し直さない」は「確認するデータがない」という意味にはならない。

公開されている顧客離反の例を、どこまで使えるか

この処理を具体的に追えるのが、NVIDIAの公式文書が案内するAdventureWorksの例だ。 概要ページでは、顧客と注文の履歴から、活動中の顧客が今後90日間に注文しなくなるかを予測する。 ノートブックの案内は、四つの表から関係を表すグラフを作り、PQLで予測を依頼すると説明している。 接続先のKumo Relational NIMと、指定されたデータファイルが必要になる。

ここでの「離反」は、顧客の気持ちを直接測ったものではない。 注文しない期間を定めて、記録から判定できる出来事に置き換えている。 年に一度だけ購入する顧客にも同じ90日を使えば、業務上の意味が変わる。 この例を自社へ持ち込む際には、モデル名を選ぶ前に、誰について、どの期間の、何を予測したいかを決める必要がある。

PQLの公式手順には、顧客ごとの今後30日間の注文金額を指定する別の例がある。 対象顧客、予測する金額、未来の期間を明示できる点に意味がある。 自然言語の依頼を受けたLLMがこの問いを組み立てる構成でも、期間や顧客の指定が正しいかは別に検査する仕事となる。

顧客ごとの予測と、日ごとの需要予測も同一ではない。 Kumo Forecastは時刻と数値の履歴から将来の値を返し、Kumo Anomalyは時系列の異常を検出する。 問いが「誰が買わなくなるか」なのか「来週の販売量はいくらか」なのかで、入力と評価方法を選び直す。 同じKumoという名称だけで、これらの道具を交換できるとは考えないほうがよい。

予測した日に知り得た記録だけを渡す

期間を定めた予測では、過去のデータを使っているだけでは十分でない。 たとえば9月30日に予測する想定なら、10月に確定したキャンセルや、後から更新された顧客区分を入力に混ぜると、その日に使えなかった情報で評価してしまう。 これが情報漏洩の一例だ。 評価では当たって見えても、本番の予測時には同じ入力を作れない。

Kumoの時刻列の文書は、行が利用可能になった時刻と、有効でなくなった時刻を指定して、予測の基準日時に合う情報を選ぶと説明する。 単に日時型の列があることと、その列が利用可能性を表すことは異なり、最終更新日時がそのまま使えるとは限らない。 過去の時点での特徴量を復元する考え方は、Feastのpoint-in-time joinsにもある。 予測の道具が変わっても、いつ知り得た値かを揃える必要は続く。

結果を受け取った後も時刻を落としたくない。 公式の結果仕様は、対象の識別子であるENTITYと、該当する場合の基準日時ANCHOR_TIMESTAMPを使って、後段のデータへ結び付けるよう説明する。 行の並びだけで顧客名を付けたり、先月の確率を今日の値として示したりすれば、推論が成功しても別の判断へ渡ってしまう。

説明文にも同じ注意が要る。 Kumoの説明機能は、関連する記録などの構造化された寄与情報と、別途設定する言語モデルによる任意の要約を分けている。 筆者なら、要約から元の寄与情報と基準日時へ戻れる形で担当者へ渡す。 寄与した記録の説明を、その顧客が離反する原因や、連絡すれば改善するという因果の証明に読み替えてはいけない。

ベンチマークの順位から、自社での予測評価へ

こうした準備をしてまで試す理由はある。 KumoRFM-2の著者らは、15の関係データベースにまたがる41の予測課題で評価し、教師あり学習や他の基盤モデルとの比較結果を報告している。 顧客の購買などを扱うRelBenchや、ERPなどを加えたRelBench v2が比較の材料になっている。 文章生成の成績から業務データへの適性を推測するより、対象に近い予測課題で比較する根拠がある。

NVIDIAの10月21日の解説は、RelBench V1の分類課題で、専門家が特徴量を設計した勾配ブースティング木に対し、平均AUROCで約4ポイント上回ったと報告する。 AUROCは正例と負例の順位を分ける性能を測る指標であり、この差は連絡後の売上が4%増えるという意味ではない。 集計済みの一枚の表だけを受け取る方法に加え、専門家が関係を特徴量へ変えた方法との比較がある点は、関連する表を使う意義を判断する材料になる。

ただし、この結果から自社の既存モデルを一律に置き換える判断はできない。 TabArenaの研究は、評価方法、調整に使う時間、複数モデルの組み合わせが比較へ影響し、勾配ブースティング木も実用的な表データで強い比較対象だと示す。 BeyondArenaの研究は、時系列やグループで分ける課題まで評価を広げる。 顧客や季節が変わる仕事では、無作為に行を分けた評価だけで結論を出したくない。

予測確率を業務のしきい値に使うなら、順位以外の確認も必要になる。 10月9日のTabReliBenchは、表向け基盤モデルを予測性能、確率分布、集団別の較正などで比較し、指標によって順位が変わることを報告した。 較正とは、たとえば80%と予測した集団で、実際にもおよそ80%の出来事が起きるかという対応である。 同論文の比較対象にKumoは含まれないため、Kumoの確率が正しい、あるいは誤っているという直接の証拠には使えない。 それでも、正答や順位の良さから確率の信頼性まで推定せず、別々に測る理由になる。

冒頭の想定業務なら、既存の「最後の注文からの日数で並べる」方法や現在の予測モデルを基準に置き、同じ過去の締切日から候補を作る。 担当者が実際に連絡できる件数で、後に注文が途絶えた顧客をどれだけ含んだか、確率が実績と合うかを比べる。 データの準備、推論、担当者の確認にかかった時間も記録する。 これは本稿の評価提案であり、実施済みの効果測定ではない。

最初に任せるのは、確認できる候補一覧

候補の予測がよくても、連絡の効果は別に確かめる必要がある。 注文しなくなる可能性が高い顧客と、連絡によって購入が増える顧客は、同じとは限らない。 誰に連絡すれば効果があるかを判断するには、予測を当てる評価に加え、比較条件を設けた施策の検証が要る。 予測モデルを呼べることから、売上の改善までを一続きの実績として扱うべきではない。

その区別を保つため、筆者はまず、根拠を確認できる候補一覧を作る仕事から始めることを勧める。 顧客ID、予測の基準日時、対象期間、確率、参照した記録を残し、LLMが規程や過去の対応履歴と合わせて説明する。 担当者は重複連絡や対応済みの顧客を外し、限られた件数を選べる。 予測を使う利点と、確認や修正の負担を、この段階で比較できる。

業務データ向けモデルを足すと、規程を読む処理、記録を計算する処理、未知の結果を推定する処理を組み合わせて、一つの依頼へ答えられる。 各処理の出典、時刻、評価を保って渡せるなら、社内AIは説明の作成から、次の行動を選ぶための資料作成へ進める。 その判断には、モデルの順位よりも、担当者が確かめて使える予測が増えたかを置きたい。

本稿は公式文書と論文の比較であり、Kumoの推論実行、自社データでの精度、処理時間や費用、施策の効果は測定していない。 公開ノートブックは利用手順の根拠として扱い、企業での導入効果とは区別した。