オンラインと店舗の在庫を 検索とAIに読ませる構造化

オンラインでは在庫切れでも、店舗には在庫がある商品は珍しくありません。検索やAIで近くで買えると案内されるように、在庫情報をどう構造化するかという相談が寄せられます。
答えは2段階です。第一に、在庫の状態をチャネルごとに分けて表現します。オンラインの在庫と店舗の在庫を混ぜません。第二に、画面に見える在庫の文言と、構造化データの在庫の値を常に同じにしておきます。構造化データは、ページの内容を機械が読める形で書いておく記述です。この2つが崩れると、検索エンジンは在庫情報を信用しなくなります。AIも商品を推薦候補から外します。
この記事では、在庫情報がAIの推薦に与える影響と、実際に起きた隠れた品切れテキストの事例、チャネル別の表現方法、店舗情報との接続、更新の運用を整理します。
結論: チャネルで分け、画面と構造化データの値を一致させる
状況 | 画面の表示 | 構造化データの表現 |
|---|---|---|
オンライン在庫あり | 「在庫あり」「カートに入れる」 | Offer.availability = InStock |
オンライン在庫なし、店舗在庫あり | 「オンライン在庫なし。〇〇店で購入可能」 | オンラインのOfferはOutOfStock。店舗のOfferを別に持ち、availableAtOrFromで店舗を指す |
オンライン・店舗とも在庫なし | 「在庫なし」「入荷待ち」 | OutOfStock または BackOrder |
予約受付中 | 「予約受付中」 | PreOrder |
店舗受け取りのみ | 「店舗受け取り」 | InStoreOnly、または店舗のOfferのみ |

構造化データの表現には、Schema.orgのOfferとItemAvailabilityの語彙を使います。大事なのは語彙の選び方より、画面の文言との一致です。
重要な考え方: AIは、画面の文言と構造化データの値が食い違うページを、信用できない情報として扱います。在庫情報の構造化は、正確さより一貫性が先です。上の表の「画面の表示」と「構造化データの表現」を、自分の商品ページで見比べます。
在庫情報がAIの推薦に与える影響
AI検索が商品を推薦するとき、今買えるかどうかは主要な判断材料です。在庫切れと判断された商品は、価格や評価が良くても候補から外れます。
問題は、AIが在庫切れと判断する根拠が、画面に見える情報だけではないことです。HTMLの中にテンプレート由来の「在庫なし」というテキストが残っていると、画面に「カートに入れる」ボタンが出ていても、AIはそのテキストを読みます。そして商品を除外します。販売中の商品ページのソースで、「在庫なし」の文字を検索して確かめます。
事例: 隠れた品切れテキスト
年商400億ウォン(約40億円)規模の韓国ECブランドで、実際に起きたことです。販売中の商品ページに、非表示になっているだけで削除されていない「品切れ」のテキストが残っていました。人の目には正常な商品ページでした。ところがAIはそのテキストを読み、販売中の商品を推薦候補から外していた可能性があります。

改善では、まずこの隠れたテキストを取り除きました。画面の在庫表示と構造化データの値も一致させました。その後、画像にしかなかった商品説明をテキスト化しました。ボットログで取得状況を見ながら、商品・カテゴリページを優先的に改善しました。その結果、3か月でOrganic購入売上が約80%増えました。この改善の起点は、在庫表現の一貫性でした。
チャネル別の表現: オンラインと店舗を分ける
同じ商品に対して、オンラインと店舗のOfferを別に持つ構造が基本です。同じスニーカーでも、倉庫の在庫と渋谷店の在庫は別の棚です。
オンラインのOffer: 価格、availability、配送条件を持ちます。availabilityはオンラインの在庫状態を指します。
店舗のOffer: 店舗ごとに、availabilityと店舗への参照(availableAtOrFrom)を持ちます。店舗数が多いなら、主要店舗または「取扱店舗あり」を示す代表的な表現に絞ります。
画面の表示: 上の2つと同じ内容を、人が読める文言で表示します。「オンライン在庫なし。〇〇店・△△店で購入可能」といった形です。
店舗ごとの在庫を商品ページに表示できるかは、プラットフォームの機能次第です。表示できないなら、構造化データにも店舗別在庫は書きません。店舗での取り扱いありという粒度に留めます。画面にない情報を、構造化データにだけ書いていないかを確かめます。
店舗情報とのつなぎ方
店舗の在庫を意味あるものにするには、店舗自体を検索エンジンとAIに知ってもらうことが前提です。
要素 | 内容 |
|---|---|
店舗ページ | 店舗ごとにURLを持ち、名称・住所・営業時間・電話番号を可視テキストで表示 |
店舗の構造化データ | LocalBusinessまたはStoreで、名称・住所・営業時間を表現 |
商品ページから店舗への参照 | 店舗のOfferのavailableAtOrFromで店舗ページ(またはその@id)を指す |
Googleビジネスプロフィール | 店舗情報を一致させる。ローカル検索での「在庫あり」表示につながる |
商品ページと店舗ページが互いに参照し合っていると、AIはこの商品がこの店舗で買えるという関係を理解できます。まず店舗ページに、名称・住所・営業時間が可視テキストで載っているかを確認します。
更新の運用: 在庫は動く
在庫は日々変わります。構造化データの更新が遅れると、一貫性が崩れます。
項目 | 推奨 |
|---|---|
構造化データの更新タイミング | 画面の在庫表示と同じタイミング(同じデータソースから生成) |
sitemapのlastmod | 在庫変動では更新しない。価格・説明・仕様の変更時のみ |
検証 | 週次で、在庫切れ商品と在庫あり商品をサンプリングし、画面と構造化データの一致を確認 |
隠れたテキストの検出 | テンプレート変更後に、非表示要素内の在庫関連テキストを検索 |

在庫変動でlastmodを更新すると、クローラーは更新信号を信用しなくなります。在庫は構造化データで表現し、lastmodは内容の変更に限定します。在庫が動いたときにlastmodが変わっていないかを確認します。
一貫性を保ち続けるための運用
在庫の構造化は、設計した日ではなく、今日の状態で評価されます。商品数が多く、店舗数が多く、在庫が頻繁に動くほど負荷は上がります。画面と構造化データの一致を人が確認し続けるのは、現実的ではなくなります。
Search OSは、この一貫性の維持を運用として扱います。既存のプラットフォームは変えません。商品ページの可視テキストと構造化データの整合、隠れた在庫テキストの検出を継続的に検証します。店舗ページとの参照関係、sitemapとlastmodの運用も見ます。ボットログで、検索エンジンとAIクローラーが商品・店舗ページを実際に取得できているかを確認します。そのうえで、食い違いが生じた箇所を修正対象として整理します。在庫あり・在庫切れの商品を一つずつ選び、画面と構造化データを見比べるところから始められます。
よくある質問
店舗別の在庫数まで構造化データに書くべきですか
在庫数(inventoryLevel)は表現できます。ただし、画面に表示していない情報は書かないほうが安全です。頻繁に変わる値ほど、不一致のリスクが高まります。
オンラインが在庫切れのとき、ページをnoindexにすべきですか
しないほうが安全です。店舗在庫があるなら、そのページは店舗で買える情報として価値があります。OutOfStockを正しく表現し、店舗への案内を可視テキストで置きます。
在庫の構造化データはリッチリザルトに出ますか
Googleの商品リッチリザルトでは、在庫状況が表示されることがあります。ただし、この記事の主眼はリッチリザルトではなく、AIが商品を推薦するときの判断材料としての一貫性です。
あわせて読みたい
参考資料
Google Search Central: Product structured data
Google Search Central: Local business structured data
Schema.org: Offer, ItemAvailability
Google Merchant Center Help: Local inventory ads