Adobe CommerceのLive Searchに、もう在庫のない商品が出てくる理由

お客様がストア内を検索し、商品を見つけ、クリックした先で在庫切れになっている。あるいは検索結果に出ている価格が先週のものになっている。管理画面のカタログは正しく、商品データも正しいのに、検索結果だけが誤っている。

この点はLive SearchとAIレコメンドが実際に何をもたらすかを書いたときにも簡単に触れました。あれらの導入案件では、Live Searchの商品データを正確に同期させ続けることに相応の連携作業が必要で、とりわけ在庫と価格が絶えず動くカタログでそうでした。これはAIの問題ではなくデータパイプラインの問題であり、独立して説明する価値があります。

Live Searchはデータベースを読んでいない

ここが多くのチームの盲点であり、以降のすべてはここから導かれます。

Live SearchはSaaSサービスです。お客様が検索窓に入力したとき、ストアフロントが問い合わせているのは自社のMySQLカタログではありません。問い合わせ先はAdobeのサービスであり、そのサービスが答えを返す元になっているのは、以前にストアがそこへ書き出したカタログの写しです。その写しを保守しているのがSaaS Data Export拡張機能（新しいタブで開きます）です。

つまり「管理画面では商品が正しい」と「検索結果でも商品が正しい」は、別々の主張です。前者はデータベースが正しいと言っているだけで、後者は書き出しのパイプラインがその修正を届けきったと言っています。この2つは、どこも壊れているように見えないまま、何日もずれ得ます。

商品の変更が検索インデックスに届くまで

Adobeはこの流れを一連の連鎖として文書化（新しいタブで開きます）しています。どの環が落ちても症状は同じになるため、知っておく価値があります。

1. 変更の検知。 Mviewがcatalog_product_entityなどのテーブルで変更行を検知し、変更ログに記録します。
2. フィードのインデックス作成。 フィードインデクサーが変更ログを読み、フィード項目を組み立てます。
3. 収集。 プロバイダーが各フィードのスキーマに沿ってフィールドデータを集めます。
4. ハッシュによる重複排除。 コンテンツハッシュで実際に変わったものを判定し、変更のないデータは再送しません。
5. 送信。 バッチがAdobeのFeed Ingestion Serviceへ送られます。
6. ステータスの書き戻し。 応答が項目ごとにフィードテーブルを更新します。
7. リトライ。 失敗分はスケジュールに従って再送されます。

どれも即時ではなく、すべてがcronの上で動いています。

Adobe自身の目安では、商品の更新は数分以内にインデックスされ、増分更新には15〜20分かかることがあり、インストール直後の初回インデックスは30分を超えることがあります。cronが正常でない場合や、大規模なカタログ操作の後ろで変更ログが滞留している場合、これらの数字はどれも当てになりません。

更新を静かに止めてしまう設定

本題のなかで最も鋭い落とし穴がここです。継続的な変更は部分同期によってサービスへ届きますが、部分同期が動くのは、cronが有効で、かつインデクサーがUpdate by Scheduleモードのときだけです。

インデクサーをUpdate on Saveに戻すと、フィードインデクサーが読むべき変更ログが存在しなくなります。エラーは出ません。管理画面は正常に見えます。カタログがLive Searchへ届かなくなるだけで、それを知らせてくれるのはお客様です。

これは2.4.8へのアップグレードと直結します。Adobeは新規インストールとアップグレードにおける既定のインデクサーモードをUpdate on SaveからUpdate by Scheduleへ変更しました。この既定は今や味方になります。ただしそれは、別の調査の途中で誰かがインデクサーをUpdate on Saveに戻し、そのまま元に戻し忘れたストアを守ってはくれません。

「送信済み」は「反映済み」ではない

管理画面には、これに対する実際の答えが System > Data Transfer > Data Feed Sync Status にあります。フィードごとに4つの状態が示されます。

さらに、元のレコード数に対する送信済みレコード数、変更ログの滞留量、各インデクサーがどのモードかも表示されます。前節の問題を最短で捕まえられるのがこの画面です。

Adobe自身の文書にある注意書きを、そのまま押さえておく価値があります。5分の確認で済むか2日の捜索になるかを分けるからです。書き出しが成功しても、連携先サービスの下流でそのデータが利用可能になっているとは限りません。 Submitted to serviceが意味するのは、ストアがデータを引き渡したということだけです。検索インデックスがそれを取り込み終えたという意味ではありません。

誤っている1件のSKUを突き止める

カタログ全体ではなく特定の商品だけがおかしいときは、連鎖のどの環がそれを取りこぼしたのかが問題になります。Adobeのトラブルシューティング記事（新しいタブで開きます）は、フィードテーブルを直接見に行く方法と、そのままコピーして使えるクエリを載せています。

対象のSKUをcde_products_feedで照会し、feed_dataのJSON内にあるskuとstoreViewCodeの値で突き合わせます。行が返らなければ、その変更はそもそもフィード項目になっていません。原因は上流の変更検知かフィードのインデックス作成にあります。行はあるのに古い場合は、そのmodified_atを商品自体の更新時刻と比べ、次にscopes_website_data_exporterで最終書き出し時刻を確認します。この比較ひとつで「そもそも収集していない」と「収集したが送信していない」が切り分けられます。両者は原因も対処も異なります。商品属性にはcde_product_attributes_feedという別のフィードがあり、商品自体は存在するのに特定の項目だけ誤っている場合は、そちらを個別に確認する価値があります。

手作業でパイプラインを動かす場合は次のとおりです。

• bin/magento cron:run --group=saas_data_exporter で同期を即時実行
• bin/magento indexer:reindex cde_products_feed で商品フィードを再構築
• bin/magento saas:resync --feed products で新規・更新・過去に失敗した項目を再送

--cleanup-feedの扱いには注意してください。 これはData Space IDが変わった状態から復旧するためのAdobeの手順に登場するもので、日常のトラブルシューティングではなく環境の全面再構築のためのものだとAdobeは明示しています。再同期が一度でうまくいかなかったから付け足す、という種類のフラグではありません。

在庫と価格が頻繁に動く場合がなぜ難しいのか

1日に2回しか変わらないカタログは、ここまでの話の影響をほとんど受けません。商品編集の反映が15分遅れても、それは見えません。

難しくなるのは、在庫と価格が絶え間なく動く場合です。プロモーションを回し、マーケットプレイスのチャネルを持ち、ERPが一日中更新を送ってくる小売事業者にとっては、それが通常状態です。こうなると変更ログは静まる時がなく、書き出しは常に稼働し、書き出された写しがカタログと食い違う窓が、ときどきではなく開きっぱなしになります。

そしてこれが、この件がしばしば検索の問題ではないと判明する理由でもあります。在庫数が上流のERPやPOSからカタログに遅れて届いているなら、Live Searchは受け取った時点ですでに誤っていた数字を忠実に書き出しているだけです。パイプラインは誤った入力に対して正しく仕事をしています。原因が2つ上流のシステムにあるのに検索インデックスから調べ始めることが、この問題で1週間を失う最もありがちな道筋です。

在庫が実際にウェブストア、マーケットプレイス、実店舗と複数の場所に同時に存在する小売事業者にとって、根本的な解決は1つの書き出しをさらに追い込むことではなく、商品・価格・在庫について単一の信頼できる情報源を持つことです。それはWOW Syncが解決するために存在する問題であり、ここまで述べたすべての上流に位置します。

Live Searchの結果とカタログが食い違っていて、原因究明に1週間かけたくないのであれば、ご相談ください。

---

出典：Adobe Experience LeagueのSaaS Data Exportガイド（新しいタブで開きます）、SaaS Data Exportによるデータ同期（新しいタブで開きます）、Data Feed Sync Status（新しいタブで開きます）、Live Searchのカタログが同期されない場合（新しいタブで開きます）。加えて、当社のAdobe Commerceカタログにおける連携の経験に基づいています。