【ITニュース解説】SalesWhy: I Built an AI That Explains Sales Drops — Then a Generic LLM Beat My Own Pipeline

SalesWhyは、小規模な事業者、たとえばEtsyで手作りのキャンドルや陶器を販売しているような店主が、突然売上が落ち込んだときに、その原因を素早く、そして分かりやすい言葉で説明してくれるAIツールだ。この店主は日々の業務に忙しく、データアナリストのような専門家を雇う時間もお金もない。売上が急落した原因が天気なのか、競合店の影響なのか、あるいは自分自身のミスなのか、現状ではスプレッドシートを眺めたり、ただ勘に頼ったりするしかない。SalesWhyはそんな状況を解決するために作られた。

このツールは、ShopifyやEtsyなどの販売プラットフォームから出力される注文データ（CSVファイル）をそのまま受け取る。特別なフォーマット変更は不要だ。ファイルが読み込まれると、SalesWhyは主に三つの情報を提供する。一つ目は、実際の売上がどうだったか、そして本来ならどうあるべきだったかを示すグラフだ。売上が特に低かった週は色分けされ、ラベルが付けられる。二つ目は、売上低下の可能性が高い原因を順位付けしたリストだ。例えば、「商品の価格が上がった」「送料が高くなった」「在庫切れの商品があった」といった具体的な原因が挙げられ、もしデータから明確な原因が見つからなければ「ファイル外の原因かもしれない」と正直に伝える。三つ目は、わずか三文で書かれた、誰にでも理解できる簡潔な説明文と、サプライヤーやビジネスパートナーにWhatsAppなどで共有しやすい画像ファイル（「ledger slip」と呼ばれる）だ。月額5〜10ドル程度の利用料で、自分のビジネスの数字について悩む時間を減らせるとすれば、多くの小規模事業者にとって魅力的な提案となるだろう。

SalesWhyの仕組みは、いくつかの重要なルールに基づいて構築されている。最も重要なのは、AIの言語モデルが売上低下の「原因そのもの」を判断することは決してない、という点だ。言語モデルの役割は、あくまでシステムが数値に基づいて既に決定した原因を、人間にとって分かりやすい言葉に変換することに限定されている。

具体的な処理の流れ（パイプライン）を見てみよう。まず、予測の段階では、TabPFNというローカルで動作するオープンソースの機械学習モデルが使われる。このTabPFNは、ショップの過去の売上データから、次の日の売上がどのくらいになるべきかを予測する。TabPFNの大きな特徴は、複雑な設定（ハイパーパラメータチューニング）が不要なため、新しい販売者のCSVデータがアップロードされても、数秒で自身を再学習して予測を開始できることだ。次に、SalesWhyは実際の売上がこの予測値を2日以上連続で大幅に下回った（または上回った）期間を特定する。これが「問題の窓」としてフラグが立てられる。

この「問題の窓」が特定されると、システムは自動的に原因分析の段階へ進む。フラグが立てられた期間中の商品の価格、送料、現在販売中の商品数（アクティブプロダクト数）といった要素を、その期間の前の14日間の平均値（ベースライン）と比較する。そして、これらの要素の中で最も大きく変動したものに順位を付け、それが売上低下の最も可能性の高い原因として特定される。もし、これらの数値がどれも大きく変動していなければ、システムは「原因不明」と正直に報告する。この段階までは、すべて数学的な計算と統計分析に基づいた決定だ。

最後に、特定された原因をユーザーに伝えるための説明生成の段階に入る。ここで初めて、Gemma 3（4B）という別の言語モデルが登場する。このGemma 3は、ユーザーのコンピューター上でOllamaというツールを通じてローカルに動作する。Gemma 3の役割は、例えば{"cause": "stockout", "change_pct": 43.5}（原因：在庫切れ、変動率：43.5%）といった機械的な情報を、「在庫切れが原因で売上が43.5%減少しました」といった具体的な三文の短い説明文に、英語やテルグ語で変換することだ。CSVファイルの列を自動で認識してマッピングする機能や、例えば「もし値上げしていなかったら売上はXくらいだったでしょう」といった仮定のシミュレーション機能、さらに売上データを詳細に掘り下げて分析する機能、そして説明を画像ファイルとして出力する機能などは、すべて一般的なPythonプログラミング言語とFastAPIというWebフレームワークを使って実装されている。複雑なAIエージェントフレームワークは、このツールには必要なかった。

このツールは開発者自身のデータセットを用いて厳密な評価が行われた。具体的には、Olistというeコマースのデータセットに、値上げ、在庫切れ、送料高騰といった明確な原因を持つ30件の合成された売上低下シナリオを意図的に挿入した。そして、SalesWhyがこれらの原因を正しく特定できるかを検証した。

SalesWhyの開発において、オープンソースのAIモデルを活用したことは非常に重要だった。これにより、商用APIでは得られない三つの具体的なメリットと、一つの予想外の発見があった。一つ目は「コスト」だ。小規模事業者が毎週数回「なぜ売上が落ちたのか」を調べるには、1クエリあたりの費用が限りなくゼロに近い必要がある。ローカルで動作するGemmaモデルは、PCの既存の処理能力以外には追加費用がかからないため、このビジネスモデルを可能にした。二つ目は「プライバシー」だ。TabPFNとGemmaの両方が、ユーザーのCSVファイルがアップロードされた同じマシン上で動作する。これは「企業が主張するプライバシーポリシー」ではなく、ユーザー自身が確認できる「事実」として、データの安全性を担保する。

そして三つ目のメリットは、開発者自身も予期しなかった重要な発見につながった。公平な比較のために、汎用的な大規模言語モデル（Gemini API）に同じ生データを与え、「なぜ売上が落ちたのか？」という何の制約もない質問を投げかけた。開発者は、自身の設計した論理的で決定論的なパイプラインが簡単に勝利すると予想していたが、結果は違った。汎用LLMは53.3%の正答率を示し、SalesWhyのパイプラインの36.7%を上回ったのだ。これは、LLMが表形式のデータ予測に苦戦するという一般的な認識とは逆の結果であり、開発者自身もこの事実に真剣に向き合った。

もちろん、汎用LLMがすべて優れていたわけではない。SalesWhyの決定論的なパイプラインにはない、ある種の欠点も持ち合わせていた。汎用LLMは、時には自信満々に間違った答えを出すことがあった。例えば、売上低下の真の原因である「価格変更」ではなく、その結果である「注文が減った」という症状を原因として挙げることがあったのだ。一方、SalesWhyは「価格、送料、在庫」のいずれか、または「不明」としか答えない。もっともらしいが誤った答えをでっち上げることは構造的にできない。汎用LLMの正答率が17ポイント高かったとしても、この「自信過剰な誤答」というガードレールが本当に価値があるのかは、まだ議論の余地がある問題だと開発者は正直に報告している。

このオープンイノベーションの価値は、まさにこの点にある。開発者は自身のツールが汎用LLMに性能で劣っていたとしても、その理由を正確に理解し、隠さずに公開することができた。それは、すべてのコンポーネントがオープンソースであり、内部を完全に検査できたからこそ可能だったのだ。

SalesWhyの開発過程は、DEVLOG.mdというドキュメントに詳細に記録されている。そこには、開発中のバグや試行錯誤の全て、そして汎用LLMが自身のパイプラインを上回った瞬間までが刻まれている。また、最初のユーザーとして、開発者自身がUIの説明なしにツールを試したところ、「UIが退屈すぎる」という正直なフィードバックを得た。このフィードバックが、現在のアプリに採用されているヘッダーのデザインや色分けされた表示、カスタムスタイルのグラフといった改善につながった。次のステップは、実際のEtsyやShopifyの販売者に使ってもらい、彼らからの生の声を聞くことだと開発者は考えている。