AIを用いた大規模eコマース商品の属性混乱解決の実践的アプローチ

人々が電商の規模拡大について議論するとき、分散型検索、在庫管理、レコメンデーションエンジンなどの一見壮大な技術的課題に焦点を当てがちだ。しかし、実際に各電商プラットフォームを悩ませているのは、最も基本的な問題：商品属性値の不一致である。

属性値は商品発見システム全体を駆動している。これらはフィルタリング、比較、検索順位付け、レコメンデーションロジックを支えている。しかし、実際の商品カタログでは、属性値は決してクリーンではない。重複、フォーマットの乱れ、意味の曖昧さが常態だ。

例えば、「サイズ」のような一見単純な属性を見てみよう：[“XL”, “Small”, “12cm”, “Large”, “M”, “S”]
次に「色」：[“RAL 3020”, “Crimson”, “Red”, “Dark Red”]

これらを単純に見ると問題はなさそうだが、300万以上のSKUがあり、それぞれに数十の属性が含まれる場合、問題はシステムレベルの課題へと変わる。検索は混乱し、レコメンデーションは機能しなくなり、運用は手作業の修正に追われ、ユーザー体験は低下していく。

ブラックボックス思考の打破：ハイブリッドインテリジェントシステムの設計思想

この課題に直面したとき、重要なのは「ブラックボックスAI」の罠に陥らないことだ——神秘的に並べ替えを行い、誰も理解も制御もできないシステム。

正しいアプローチは、次の特性を持つパイプラインを構築することだ：

• 高い説明性
• 行動の予測性
• スケール可能な運用
• 人手による介入を受け入れる

最終的な解決策はハイブリッドAIパイプライン：LLMの文脈理解能力と明確なルール、そして人間のコントロールを組み合わせたものだ。必要に応じて賢く動作しつつも、常に制御可能な状態を保つ。これが「ガードレール付きAI」であり、制御不能なAIではない。

オフライン処理：規模拡大の土台

すべての属性処理はバックエンドのオフラインタスクで行われ、リアルタイム処理は避ける。これは妥協ではなく、戦略的なアーキテクチャの決定だ。

リアルタイムパイプラインは魅力的に見えるが、電商規模では次の問題を引き起こす：

• 予測不能な遅延変動
• 脆弱な依存関係
• 計算コストのピーク
• 運用の脆弱性

一方、オフラインタスクは次の利点をもたらす：

• 高スループット：大量データのバッチ処理を顧客システムに影響させずに実行
• 耐障害性：故障は常にユーザートラフィックに影響しない
• コスト管理：計算リソースを閑散期に調整可能
• 隔離保護：LLMの遅延は商品ページとは完全に独立
• 原子性一貫性：更新は完全に予測可能かつ同期される

数千万SKUを扱う場合、顧客システムとデータ処理パイプラインの隔離は極めて重要だ。

データクレンジング：投入と成果の比率が最も高いステップ

AI適用前に、厳格な前処理が必要だ。このステップは一見単純だが、効果は絶大だ。

クレンジングパイプラインには：

• 先頭と末尾の空白除去
• 欠損値の除去
• 重複排除
• 分類パスを構造化された文字列に簡略化

これにより、LLMに渡す入力はクリーンで明確なものとなる。大規模システムでは、小さなノイズも後の爆発的な問題に繋がる。ゴミ入力→ゴミ出力。これは百万単位のデータに対しても厳然たる法則だ。

LLMサービスの文脈付与

LLMは単なる属性値の文字列並べではなく、その意味を理解する。

このサービスは以下を受け取る：

• クレンジング済みの属性値
• カテゴリ情報（パンくずリスト）
• 属性のメタデータ

これらの文脈情報により、モデルは次のことを理解できる：

• 電動工具の「電圧」は数値順に並べるべき
• 衣料の「サイズ」は予測可能な順序（S→M→L→XL）
• 塗料の「色」はRAL規格（例：RAL 3020）を使用
• ハードウェアの「材料」には意味的関係（鋼→ステンレス→炭素鋼）が存在

モデルは次のような出力を返す：

• 順序付けられた値のシーケンス
• 完成された属性名
• 決定的なソートか文脈感知ソートかのフラグ

これにより、さまざまな属性タイプに対応でき、各カテゴリごとに硬直したルールをコーディングする必要がなくなる。

決定的なフォールバック：AI不要なときの判断

すべての属性にAIが必要なわけではない。むしろ、多くの属性は決定論的ロジックで処理したほうが効果的だ。

数値範囲、単位化された値、シンプルな集合は、次の利点を享受できる：

• 高速処理
• 完全に予測可能な順序付け
• 低コスト
• 歪みのない結果

パイプラインはこれらを自動的に識別し、決定論的ロジックを適用する。これにより、システムの効率性を維持し、不必要なLLM呼び出しを避ける。

権力のバランス：商家タグシステム

商家はコントロールを保持すべきであり、特に重要な属性についてはそうだ。したがって、各カテゴリには次のタグを付与できる：

• LLM_SORT — モデルに決定させる
• MANUAL_SORT — 商家が手動で順序を定義

この二重タグシステムにより、人間は最終的な決定権を持ちつつ、AIは大部分の作業を担う。さらに、商家はいつでもモデルの決定を上書きできることを知っており、信頼性も高まる。

データの永続化：MongoDBを唯一の事実源に

すべての結果は直接Product MongoDBに書き込み、アーキテクチャはシンプルに集中させる。MongoDBは以下の内容の唯一の運用ストレージとなる：

• ソート済みの属性値
• 完成された属性名
• カテゴリレベルのソートタグ
• 商品レベルのソートフィールド

これにより、変更の監査、値の上書き、カテゴリの再処理、他システムとの同期が直接操作できる。

検索層の閉ループ：データから発見へ

ソート完了後、値は次のように流れる：

• Elasticsearch — キーワード駆動の検索
• Vespa — セマンティック・ベクトル検索

これにより：

• フィルタリングオプションが論理的な順序で表示
• 商品ページに一貫した属性が反映
• 検索エンジンがより正確に結果をソート
• ユーザーのカテゴリ閲覧が直感的かつスムーズに

属性のソートの威力は検索に最も顕著に現れ、一貫性が最も重要となる。

システム全景：原始データからユーザーインターフェースまで

このシステムを数百万SKUで運用するために、バックエンドタスク、AI推論、検索統合を軸としたモジュール化されたパイプラインを設計した。

データフロー：

• 商品データは商品情報システムから取得
• 属性抽出タスクが属性値とカテゴリの文脈を取得
• これらはAIソートサービスに送信
• 更新された商品ドキュメントはProduct MongoDBに書き込み
• 出力同期タスクがソート結果を商品情報システムに逆書き込み
• ElasticsearchとVespaの同期タスクがそれぞれのインデックスを更新
• APIサービスは検索エンジンとクライアントアプリを連携

このフローにより、AIソートも手動設定も含めて、すべての属性値が検索、棚管理、最終的な顧客体験に反映される。

実際の変化例

乱雑な原始値がどのように変換されるか：

これらの例は、文脈理解と明確なルールを組み合わせて、クリーンで理解しやすいシーケンスを生成するパイプラインの能力を示している。

なぜリアルタイムではなくオフラインか？

リアルタイム処理を採用すると：

• 予測不能な遅延
• 高い計算コスト
• 依存関係の脆弱性
• 運用の複雑さ増大

一方、オフラインタスクは：

• バッチ処理の効率性
• 非同期のLLM呼び出し
• リトライロジックと死信キュー
• 人工監査のウィンドウ
• 完全に予測可能なコスト

わずかな遅延はあるが、その代償として大規模な一貫性と信頼性を実現できる。これが顧客にとって本当に価値のあることだ。

ビジネスへの効果

結果は非常に明確だ：

• 300万以上のSKUの属性が一貫性を持つようになった
• 決定論的な数値ソートによる予測可能性
• 商家による手動タグ付けによる細粒度コントロール
• よりきれいな商品ページと直感的なフィルタリング
• 検索の関連性向上
• ユーザーの信頼とコンバージョン率の向上

これは単なる技術的勝利だけでなく、ユーザー体験と収益の向上にもつながる。

核心的な示唆

• 規模においては純粋なAIよりもハイブリッドパイプラインが優れる。ガードレールは重要だ。
• 文脈情報はLLMの精度を大きく高める
• オフラインタスクはスループットと耐障害性の基盤
• 人手による上書きは信頼と受容性を築く
• クリーンな入力は信頼できるAI出力の土台

結び

属性値の並べ替えは一見単純だが、百万規模の商品を扱うとき、真の難題となる。LLMの知能と明確なルール、商家のコントロールを融合させることで、この見えないが普遍的な問題を、クリーンで拡張性のあるシステムに変えることができる。

これは教訓だ：最大の勝利は、しばしば見落とされがちなつまらない問題——毎日すべての商品ページに現れる問題——を解決することから生まれる。