在庫表示ブロック：在庫状況、配送、フルフィルメント

アベイラビリティブロック（在庫表示ブロック）は、購入者の最後の運用上の質問に答えます。この商品を入手できるか、どの方法で、いつ入手できるか？ 在庫、配送、店舗受取、取り寄せ、製造終了の情報を、バッジ、チェックアウトのツールチップ、配送ポリシーページに分散させるのではなく、1つの抽出可能なユニットにまとめます。

この要素が重要な理由

在庫情報は単なる安心感を与えるコピーではありません。それは購入の制約条件です。商品を選んだ購入者でも、選択したバリエーションが販売可能か、配送が希望の場所に届くか、実際の期限までに到着するかがページで確認できない場合、購入を断念する可能性があります。正確な在庫情報は、不確実性が最も高くつく瞬間に不確実性を低減します。

その心理は、人工的な緊急性ではなく、コントロールに関するものです。「残り2点」という表示は、その数字が真実で最新のものであれば、購入者がリスクを判断する助けになります。しかし、同じメッセージが何日も続いたり、リロード後にリセットされたり、購入者に対応できない倉庫を参照していたりすると、信頼を損なうことになります。有用なブロックは、読者が行動するために必要な情報（現在のステータス、配送先、方法、時期、条件、および次に取れるアクション）を提供します。

機械抽出可能性とは、クローラー、ショッピングエージェント、フィード、または支援技術が、バリエーションとそのフルフィルメント情報との関係性を保持できることを意味します。「在庫あり」の横にある緑の点は、意味的に弱いものです。どの色、どの場所、どの方法、どの時間帯に利用可能なのか？ラベル付けされたブロックは、完全な回答を保持できます。

鮮度が重要なのは、在庫が変動しやすいからです。コンテンツシステムはコマースの信頼できる情報源からステータスを取得する必要があります。一方、表示されるタイムスタンプとフォールバックポリシーにより、古いデータや利用できないデータを検出可能にします。検索エンジンやAIシステムは、購入者が見るのと同じ実質的な状態を確認できなければなりません。構造化データは矛盾したページを修復できません。

使用すべきタイミング

在庫やフルフィルメントが、読者が意図したアクションを完了できるかどうかを変える場合に、在庫表示ブロックを使用します。これは、物理商品ページ、在庫が選択に影響する商品一覧、チケットや在庫限定のオファー、およびエージェント向けに設計されたコマースデータエンドポイントに適しています。また、店舗受取、ローカル配送、受注生産のリードタイム、取り寄せ、予約注文、製造終了商品にも有効です。

サイズ、色、パック、状態、販売者、または場所によって回答が変わる場合は、購入可能なバリエーションごとにブロックをレンダリングします。選択したサイズが利用できない場合に、商品ファミリー全体で「在庫あり」と表示するのは誤解を招きます。マーケットプレイスに複数の販売者がいる場合、各オファーには独自の価格、在庫状況、配送約束、販売者情報が必要です。

以下のよくある類似ケースは、この要素の外に置くべきです：

• サービスチームの次の予約は予約スロットであり、在庫状況ではありません。
• 営業時間は営業時間・連絡先情報に属します。「営業中」は商品があることを意味しません。
• ソフトウェア機能のリリース状況は、アクセスが本当に容量制限されていない限り、製品ドキュメントまたはリリースドキュメントに属します。
• プロモーションの期限は、在庫状態ではなくオファー条件です。
• 一般的な配送ポリシーは注文全体のルールを説明します。在庫表示ブロックは、これらのルールをこの商品、配送先、時期に適用します。
• 「迅速出荷」などの小売業者のマーケティング文言は見積もりではなく、配送フィールドを占有すべきではありません。

要素作成ルール が優先されます。バッジ、カード、アコーディオンのスタイルではなく、目的によってブロックを選択してください。主な役割が、選択した商品を入手できるかどうか、およびその方法を提示することである場合、それは在庫表示ブロックです。

配置場所

主要ブロックは購入領域に配置し、購入者が在庫に影響するすべてのバリエーションを選択した後、数量コントロールと購入アクションの直前に配置します。この順序により、ページは「カートに入れる」を表示する前に、1つの真実の状態を計算できます。バリエーションコントロールが価格の上にある場合は、それらのコントロールの後にブロックを配置し、選択内容に合わせてアクセシブルな名前を更新します。

カテゴリページや一覧ページでは、該当する商品カード内にコンパクトなステータスを直接配置します。カードが正確に計算できない限り、配送先固有の日付については詳細ページにリンクします。購入ガイドやレビューでは、販売者と確認時間の横に編集上適格なステータスを配置します。出版社が在庫を管理していると暗示してはいけません。

ブロックは、価格と同じバリエーションと販売者を参照する場合に限り、価格の隣に配置できます。矛盾するバッジ、利用不可の商品に対する有効な購入ボタン、無関係なカウントダウンタイマー、または別の配送先に基づく配送主張の隣に配置してはいけません。ステータスとその次のアクションの間に、お客様の声、プロモーション用カルーセル、またはクロスセルを配置してはいけません。レビューの下に製造終了ステータスを隠し、以前の購入コントロールを表示したままにしてはいけません。

モバイルでの順序は以下のままにします：選択したバリエーション、在庫状態、配送または受取の選択肢、条件、そしてアクション。スティッキーな購入バーは短い状態を繰り返しても構いませんが、同じ情報源から導出され、完全なブロックと矛盾してはいけません。

構成要素

1. コンテキスト： 情報が適用される正確な商品、バリエーション、販売者、場所を特定します。
2. 在庫ステータス： 「在庫あり」「在庫わずか」「在庫切れ」「取り寄せ」「予約注文」「製造終了」などの管理された状態のいずれかを使用します。
3. 数量表示： 確認済みの数量または非数値的なしきい値ラベルを表示します。希少性を偽装してはいけません。
4. 配送先： 見積もりの対象となる国、地域、郵便番号、または選択された店舗を指定します。
5. フルフィルメント方法： 配送、ローカル配送、店舗受取、デジタル配送を区別します。
6. 配送または受取可能期間： 「近日中」ではなく、絶対日付または範囲を表示します。
7. 締切と条件： タイムゾーン、注文期限、営業日ベースの前提、メンバーシップ要件、または重要な場合の最小注文数を明記します。
8. 利用不可時のポリシーとアクション： 補充、代替品、取り寄せ、通知、またはアーカイブの動作を説明します。
9. 鮮度と情報源： 状態が解決された時刻と、それを提供した信頼できるサービスを記録します。
10. コマースアクション： 状態に応じて、購入、予約注文、ウェイティングリストに参加、別の店舗を探す、後継機種を表示などに一致させます。

デザイン例

すべてのバリエーションは、テキストと色の両方を使用し、選択された商品のコンテキストを保持し、タイムスタンプまたはリアルタイムソースの契約を公開します。

在庫あり・フルフィルメント選択肢あり。 商品が今すぐ販売可能な場合に使用します。オンライン在庫と店舗在庫を区別し、対象となる方法ごとに1つの見積もりを表示します。

在庫わずか。 管理されたしきい値を超えた場合にのみ使用します。安全で十分に最新の情報である場合にのみ正確な数を表示し、それ以外の場合は「在庫わずか」と表示し、タイムスタンプを保持します。

在庫切れ、補充予定あり。 取り寄せが受け付けられていない限り、即時購入アクションを無効にします。販売促進や供給データがそれをサポートする場合にのみ、予定期間を表示します。

取り寄せまたは予約注文。 これらの状態は区別して表示します。支払いの承認または請求のタイミング、出荷予定日または発売日、キャンセル条件、および混合カートが別々に出荷されるかどうかを明記します。

製造終了。 アクティブな購入コントロールとアクティブオファーのマークアップを削除します。有用な仕様とサポート情報を保持し、関係が確認された場合にのみ公式の後継製品を特定します。

店舗受取。 店舗名、準備完了時間、予約期間、身分証明要件を明記します。「近くで利用可能」だけでは、購入者が移動しなければならない場合には不十分です。

パラメータ

以下で「ソース」とは、レンダラーが値を取得する場所を指します。コマースシステムは、基盤となる主張に対する責任を負い続けます。

制御ステータスは、見た目ではなくコマースの真実にマッピングされます：in-stock、limited、out-of-stock、backorder、preorder、discontinued。「店舗受取のみ」のようなチャネル固有の値は、methodに属します。なぜなら、商品が在庫ありでありながら、受け取り方法が店舗受取のみの場合もあるからです。

構文とコード例

3つの形式はすべて、同じ選択されたSKU、状態、配送期間、ソース、およびアクションをエンコードします。プロジェクトでは、本番環境でその構文を使用する前に、対応するHugoまたはWordPressアダプターを登録する必要があります。

ポータブルMarkdownディレクティブ

:::availability{status=in-stock sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api"}
## Availability

In stock online and ready to dispatch.
Action: [Add navy Trail Jacket, size M to cart](https://example.com/cart/add/TJ-NV-M)
:::

Hugoショートコード

{{< availability status="in-stock" sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api" >}}
## Availability

In stock online and ready to dispatch.
Action: [Add navy Trail Jacket, size M to cart](https://example.com/cart/add/TJ-NV-M)
{{< /availability >}}

すべてのパラメータは名前付きです。この例では、位置パラメータと名前付きパラメータの混在を意図的に避けています。

WordPress

[availability status="in-stock" sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api"]
In stock online and ready to dispatch.
Action: <a href="https://example.com/cart/add/TJ-NV-M">Add navy Trail Jacket, size M to cart</a>
[/availability]

ネイティブWordPressブロックは、これらの値を単一のリッチテキストブロブではなく、型付き属性として保存する必要があります。初期状態にはサーバーサイドレンダリングが推奨されます。クライアントサイドのパーソナライゼーションは、同意または入力後に配送先と見積もりを調整する場合があります。

良い例と悪い例

良い例

ネイビートレイルジャケット、サイズM — オンライン在庫あり。 10001への配送は標準配送で8月31日～9月1日のお届け予定です。8月28日14:00 ETまでにご注文ください。店舗受取の在庫状況は別途確認されます。在庫と配送見積もりは2026年8月27日09:42 ET時点で確認済みです。

これは、状態を選択したバリエーション、配送先、方法、日付範囲、タイムゾーン、確認時間に結び付けているため、有効です。読者はアイコンを解釈したり、一般的なポリシーを開いたりせずに行動できます。

悪い例

🟢 急いで！在庫あり — すぐに売り切れます。まもなくお届け。残りわずか！

これは、「在庫あり」にバリエーション、販売者、チャネルがなく、「まもなく」に配送先や日付がなく、「わずか」に管理されたしきい値がなく、緊急性を監査できないため、失敗です。緑色のアイコンもテキストにない意味を伝えています。アイコンを赤に変えても、欠落した情報は修正されません。

スキーママークアップとアクセシビリティ

真正な購入可能な商品の場合、ブロックはProduct.offersにOfferまたはAggregateOfferを通じてデータを供給できます。制御された表示状態を、InStock、OutOfStock、BackOrder、PreOrder、Discontinued、LimitedAvailabilityなどの対応するSchema.orgのavailability URLにマッピングします。価格、通貨、販売者、商品の状態、URLはすべて同じオファーを記述していなければなりません。別のバリエーションや販売者に在庫があるからといって、InStockを使用してはいけません。

配送情報はOfferShippingDetailsに供給できます。配送先、処理時間、輸送時間、料金、対象となる方法は、表示されている約束と一致していなければなりません。製造終了商品に対してアクティブなOfferを出力したり、表示されるアクションがウェイティングリストになった後も古いオファーマークアップを残したりしてはいけません。

構造化データはコマース状態の出力であり、第二の在庫データベースではありません。可能な限り、同じ解決済みオファーから表示ブロック、フィード、JSON-LDを生成します。同じスケジュールで更新できない場合は、同期が完了するまで最も制限の少ない防御可能な状態を公開します。

アクセシビリティでは、すべてのステータスにテキストラベルが必要です。色、アニメーション、アイコンは補強に使用できますが、定義に使用してはいけません。更新内容は選択されたバリエーションに関連付けます。バリエーションや配送先の変更によってブロックが非同期に更新される場合、フォーカスや読者を予期せず移動させず、適切に設定されたライブリージョンを通じて簡潔な結果を通知します。カウントダウンの通知を毎秒繰り返すことは避けます。

配送コントロールには、「配送先の郵便番号」「受取店舗を変更」などの明示的なラベルが必要です。日付は、数値の順序が曖昧になる可能性がある場合、月を文字で含める必要があります。締切にはタイムゾーンが必要です。無効化された購入コントロールの近くには、その理由と有効な次のアクションを説明するテキストが必要です。ホバーなしでも完全な状態を利用可能にし、JavaScriptが失敗した場合のサーバーレンダリングフォールバックを提供します。

作成ルール

2～6語の制御ステータスで始めます：「オンライン在庫あり」「取り寄せ可能」「製造終了」など。続けて結果を記載します：出荷準備完了、予定発売日、または販売終了。1つのブロックは1つの選択されたオファーに対して使用し、倉庫記録ごとに1つのブロックを使用してはいけません。

絶対的な配送日付または2つの日付の範囲を使用します。見積もりが配送先によって変わる場合は、配送先を明記します。信頼できる見積もりがない場合は、見積もりを計算するために何が必要かを述べます。「通常」「近日中」「迅速」「届くはず」は、情報源のある範囲の代わりにはなりません。

主要ブロックは、1行のステータス、1～4行のフルフィルメント情報、必要な場合は10～45語のポリシー文1つ、および1つの主要アクションに抑えます。在庫わずかのラベルには承認されたしきい値が必要です。正確な数には最新の情報源が必要です。システム統合を通じて状態を継続的に確認し、コンテンツQAサイクルごとにフォールバックをテストします。

冷静で運用的な言葉を使用します。偽造された希少性、匿名の人気主張、無関係な割引、お客様の声、保証詳細、完全な返品条件、または一般的な配送ポリシーのコピーを決して含めてはいけません。予約注文を「在庫あり」と呼んだり、利用不可の商品を「注文可能」と表示して取り寄せと明記しなかったり、フルフィルメントシステムがサポートできない日付を約束したりしてはいけません。

製造終了商品については、「現在利用不可」ではなく「製造終了」と表示します。サポート、部品、マニュアル、または公式の後継製品が利用可能かどうかを説明します。

使用する投稿タイプ

postTypesフロントマターフィールドが、この実装マトリックスの情報源です。

QAチェックリスト

• ステータスが、商品ファミリー全体ではなく、選択されたSKU、販売者、チャネル、場所に適用されている。
• 在庫、販売可能性、フルフィルメント方法、配送タイミングが別々のフィールドであり、互いに矛盾していない。
• 在庫およびフルフィルメントの情報源が信頼でき、監視されており、コンポーネント契約に明記されている。
• 確認時刻が存在し、タイムゾーンを含み、ビジネスの鮮度許容範囲を満たしている。
• 正確な在庫数と在庫わずかのラベルが、販促的な緊急性ではなく、管理されたルールを使用している。
• すべての配送見積もりに、表示可能な配送先が指定または継承され、絶対日付または範囲を使用している。
• 取り寄せと予約注文の状態で、支払いタイミング、出荷予定日または発売日、キャンセル条件が説明されている。
• 在庫切れおよび製造終了の状態で、即時購入アクションが削除または置き換えられている。
• 表示コンテンツ、フィードデータ、チェックアウト動作、Offer構造化データが同じ状態を記述している。
• ステータスがテキストで伝えられ、動的な変更が適切に通知され、コントロールに明示的なラベルがある。
• ブロックが色、ホバー、アニメーション、パーソナライゼーション、JavaScriptなしでも意味を成す。
• モバイルおよびスティッキー購入処理が同じ情報源から導出され、正しい読み上げ順序を保持している。
• 3つの構文例すべてが、ソースや鮮度データを失うことなく、同じ型付きフィールドにマッピングされている。

FAQ

在庫表示ブロックに正確な在庫数を表示すべきですか？

在庫システムが信頼でき、在庫数が十分な速度で更新され、公開しても運用上またはセキュリティ上のリスクが生じない場合に限ります。それ以外の場合は、「在庫あり」「在庫わずか」「取り寄せ」「在庫切れ」などの管理されたステータスを使用してください。未確認の在庫数で緊急性を偽装してはいけません。

商品が在庫切れの場合、ブロックには何を表示すべきですか？

「在庫切れ」と表示し、補充が見込まれるかどうかを説明し、確認済みの日付または期間がある場合はそれを示し、再入荷通知などの関連する次のアクションを提供します。チェックアウトで注文を受け付けられない場合は、購入可能なOfferやアクティブな「カートに入れる」アクションを表示してはいけません。

取り寄せと予約注文はどのように区別すべきですか？

取り寄せ（バックオーダー）は、即時フルフィルメントが一時的に不可能な既存商品です。予約注文（プリオーダー）は、通常販売がまだ開始されていない商品です。状態を正確に表示し、支払いがいつ発生するかを明記し、不確実性がある場合も含めて出荷予定日または発売日を提示します。

在庫表示ブロックにOfferスキーマは必要ですか？

いいえ。構造化データがなくても、表示されるブロックは正確でなければなりません。ページが真正な購入可能なオファーを説明している場合、表示される状態はOfferのavailability値および配送詳細と一致する必要があります。編集上の言及や利用不可のカタログレコードは、アクティブなオファーとしてマークアップしてはいけません。

配送見積もりは地域によって個人化できますか？

はい、配送先が特定されており、個人化されていないフォールバックが利用可能な場合に限ります。動的な変更は支援技術に通知し、IP位置情報を確実なものとして使用せず、サーバー側でレンダリングされた在庫状態は、クローラーやJavaScriptを使用しないユーザーに対しても正確に保ちます。