OfferShippingDetailsスキーマ

TL;DR — OfferShippingDetailsは、商品のマークアップに追加する小さなコードブロックです。 送料、配送先、配送にかかる期間という3つの情報をGoogleへ伝えます。Googleはその配送情報を 検索結果に表示できるようになります。2025年後半以降、配送情報の記述場所は2つあります。 カタログ全体の既定値を示す店舗レベルと、既定と異なる商品を示す商品レベルです。 OfferShippingDetailsは後者の商品レベルで使用します。

OfferShippingDetailsとは

商品ページを見る人は、送料や「3～5日で到着」といった案内を読めます。一方、検索エンジンは 単なる文章からその意味を推測しなければなりません。OfferShippingDetailsは、通常 JSON-LDとして追加し、共通の schema.org語彙を使って「送料は$5」「米国へ配送する」 「3～5営業日かかる」と明示するコードです。

これは商品ページのOfferの内部に置きます。価格と在庫状況を保持する同じOfferです （商品スキーマを参照）。 Googleはこの情報を読み取り、特にショッピング形式の検索結果で送料や配送予定の行を表示できます。

記述する3つの情報

OfferShippingDetailsは次の3要素をまとめます。

• 送料 — 配送にかかる費用（shippingRate）。
• 配送先 — 国や郵便番号の範囲など、条件が適用される地域（shippingDestination）。
• 配送期間 — 配送にかかる時間（deliveryTime）。倉庫から発送するまでの 処理時間と、配送業者が届けるまでの輸送時間を合計したものです。

2025年後半の大きな変更

以前は、商品レベルのこのマークアップが、構造化データで配送情報を宣言する主な方法でした。 2025年11月、Googleは店舗レベルの第2の方法を追加しました。すべての商品で繰り返す代わりに、 事業全体の配送ポリシーをShippingServiceで一度だけ宣言できます。Googleは現在、これを既定値として 使用し、既定と異なる配送条件の商品だけにOfferShippingDetailsを使うことを推奨しています。

要点は次のとおりです。

• すべてに同じ配送ポリシーを使う場合は、店舗レベルのShippingServiceで一度だけ宣言します。
• 特定の商品だけ配送条件が異なる場合は、その商品をOfferShippingDetailsで上書きします。

誤解を避けるための2つの注意点

• 必須ではなく、ランキングも上がりません。 配送マークアップを追加すると、検索結果に 配送情報を表示する資格を得られますが、順位が上がるわけではありません。構造化データに そのような効果はありません。
• 追加しても表示は保証されません。 Google Merchant CenterのフィードやSearch Consoleの 配送設定もある場合、それらが警告なしでマークアップより優先されることがあります。 この落とし穴はAdvancedタブで詳しく説明します。

各プロパティ、2025年11月の再編、複数の情報源が競合した場合の優先順位、通知されない失敗、 実際に動くJSON-LDまで確認するには、Advancedタブへ進んでください。

TL;DR — OfferShippingDetailsは、Offer配下のshippingDetailsにネストし、 shippingRate（MonetaryAmount）、shippingDestination（DefinedRegion）、 deliveryTime（handlingTime＋transitTime）を宣言するschema.org型です。 2025年11月以降は2階層構造の商品レベルの上書きを担います。Googleはカタログ全体の 既定値を組織レベルの**ShippingService（Organization.hasShippingService）で 一度だけ宣言し、条件が異なる商品にだけOfferShippingDetailsを使うことを推奨しています。 MerchantReturnPolicyと同じ組織レベル／Offerレベルの分担です。混同しやすい点は2つあります。 (1)「既定値は組織レベルで書く」と「競合時は商品レベルのマークアップが組織レベルより 優先される」は、軸が異なるため両方とも正しいこと。(2)** Rich Results Testに通っても、 Merchant Centerのフィード値やSearch Consoleの設定に全面的に上書きされ、リスティングが 拒否されるまでエラーが出ない場合があることです。shippingDetailsは推奨であって必須ではなく、 得られるのは表示資格であってランキング上昇ではありません。

何 OfferShippingDetails actually is

schema.orgの定義は簡潔です。“OfferShippingDetails represents information about shipping destinations.” (翻訳)「OfferShippingDetailsは配送先に関する情報を表します。」実際には、 shippingDetailsプロパティを介してOffer内に ネストするオブジェクトです。schema.orgはこのプロパティを*“information about the shipping policies and options associated with an Offer.”* (翻訳)「Offerに関連付けられた配送ポリシーと 選択肢に関する情報」と説明しています。商品スキーマを 構成する同じOffer内で、price、priceCurrency、availabilityと並びます。

1つの商品に複数のOfferShippingDetailsを宣言できます。これはエラーではなく想定された使い方です。配送先ごとに送料が異なる場合や、同じ配送先に料金と速度の異なる配送方法がある場合に使います。

November 2025 restructure: OfferShippingDetails vs. ShippingService

この変更を反映していないガイドが多いため、慎重に確認します。2025年11月12日、Googleは配送・返品ポリシーを共有する2つの方法を拡張しました（Google Search Centralブログ、同日公開のSearch Engine Journalの記事）。現在は、Merchant Centerと連携したサイトだけでなく、Googleの分類で販売事業者と判断されたサイトもSearch Consoleの設定で配送情報を直接指定でき、構造化データでは**組織レベルのShippingService**を宣言できます。

ShippingServiceはOrganization.hasShippingServiceで宣言する新しいschema.org型です。商品ごとに繰り返さず、事業の配送を説明する1ページで標準ポリシーを一度だけ記述できます。GoogleのShippingService資料は、“If you need to override your standard shipping policy for a specific product, specify one or more instances of the OfferShippingDetails type,” (翻訳)「特定の商品で標準配送ポリシーを上書きする必要がある場合は、OfferShippingDetails型を1つ以上指定してください」と説明し、Offer配下へネストするよう示しています。また商品レベルのポリシーは、“a more limited set of properties than those described here for shipping policies specified under Organization.” (翻訳)「Organization配下の配送ポリシーより利用できるプロパティが限定される」と明記しています。

したがって、記述方針は次のとおりです。

• 組織レベル（ShippingService）— 推奨される既定値。 標準ポリシーを一度だけ宣言します。Googleのmerchant listing資料には、“We recommend you provide a global shipping policy for your business under Organization markup instead… Only if some of your products have specific shipping policies for which you need to override your global shipping policy, or if you don’t provide a standard shipping policy for your business, use this property under Offer.” (翻訳)「事業全体の配送ポリシーはOrganizationマークアップで提供することを推奨します。全体ポリシーを上書きする固有の配送ポリシーを持つ商品がある場合、または標準ポリシーを提供しない場合だけ、このプロパティをOffer配下で使用してください」とあります。
• Offerレベル（OfferShippingDetails）— 上書き。 実際に配送条件が異なる商品、または組織レベルの既定値を宣言していない場合の代替として使います。

この仕組みは、同じポリシーを共有する大規模カタログで商品ごとの保守を減らすためのものです。MerchantReturnPolicyの構造、つまりOrganization.hasMerchantReturnPolicyで既定値を宣言し、Offer配下で上書きする構造を知っていれば、配送にも同じ設計が適用されたと考えられます。Googleはこの一連のプロパティを継続的に厳格化しており、2025年3月には返品ポリシーのreturnPolicyCountryを明示的な必須項目とし、11月にはShippingService層を追加しました。

変更の基になったschema.org提案（Google ShoppingのエンジニアIrina Tuduceが開始したGitHub issue #3617）は、“introduces a new type, ShippingService, that groups shipping constraints,” (翻訳)「配送制約をまとめる新しいShippingService型を導入する」とし、“redundant fields from ShippingRateSettings are therefore… deprecated.” (翻訳)「そのためShippingRateSettingsの重複フィールドは非推奨になる」と明記しています。重要なのは、OfferShippingDetails自体は非推奨ではないことです。役割が変更されただけで、削除されたのは関連するShippingRateSettings内の一部の重複フィールドです。

プロパティ, one by one

OfferShippingDetailsオブジェクト内では次のプロパティを使います。

• shippingRate — MonetaryAmount（またはShippingRateSettings）。schema.orgの定義は*“The shipping rate is the cost of shipping to the specified destination.”* (翻訳)「指定された配送先への送料」です。valueを0にすると送料無料を表します。2025年の再編ではShippingRateSettingsが拡張され、注文金額や重量に対する割合の送料にも対応しました。
• shippingDestination — DefinedRegion。“indicates (possibly multiple) shipping destinations. These can be defined in several ways, e.g. postalCode ranges.” (翻訳)「1つ以上の配送先を示し、郵便番号の範囲など複数の方法で定義できる」プロパティです。国（addressCountry）、地域、郵便番号の範囲で表せるため、商品に地域別の複数エントリを持たせられます。
• shippingOrigin — 同じくDefinedRegion。“Indicates the origin of a shipment, i.e. where it should be coming from.” (翻訳)「荷物の発送元」を示します。
• deliveryTime — ShippingDeliveryTime。“The total delay between the receipt of the order and the goods reaching the final customer.” (翻訳)「受注から商品が最終顧客へ届くまでの合計時間」です。単一の数値ではなく、後述する2つのプロパティの合計です。
• doesNotShip — 真偽値。“Indicates when shipping to a particular shippingDestination is not available.” (翻訳)「特定のshippingDestinationへ配送できない」ことを示します。
• hasShippingService — 新しい組織レベル型のShippingService。2階層を結びます。
• validForMemberTier — 会員ランク限定の送料無料など、配送方法をロイヤルティ／会員ランクへ関連付けます。
• weight / height / width / depth — 送料照合に使う梱包寸法です。

deliveryTime = handlingTime + transitTime

最も見落とされやすい点です。deliveryTime（ShippingDeliveryTime）は次の要素で構成されます。

• handlingTime — “The typical delay between the receipt of the order and the goods either leaving the warehouse or being prepared for pickup.” (翻訳)「受注から、商品が倉庫を出るか受け取り準備が整うまでの標準的な時間」です。発送前の自社処理時間を表します。
• transitTime — “The typical delay the order has been sent for delivery and the goods reach the final customer.” (翻訳)「配送に出してから最終顧客へ届くまでの標準的な時間」、つまり発送後の配送業者による輸送時間です。
• cutoffTime — “Order cutoff time allows merchants to describe the time after which they will no longer process orders received on that day. For orders processed after cutoff time, one day gets added to the delivery time estimate.” (翻訳)「当日処理を締め切る時刻を示し、締切後の注文では配送予定に1日を加える」ための値です。
• businessDays — 実際に注文を処理する曜日です。

購入者に「4～7営業日で到着」と表示する場合、処理時間（例: 1～2日）と輸送時間（3～5日）の合計であり、締切後の注文ではcutoffTimeにより1日加算されます。2つを根拠のない単一の輸送日数へまとめるのはよくある誤りです。

Is it 必要

いいえ。これは根強い誤解です。merchant listingの構造化データでshippingDetailsは推奨であって必須ではありません。必須なのはprice（merchant listingでは*“greater than zero”* (翻訳)「0より大きい」値）とpriceCurrency（ISO 4217）だけです。配送マークアップがなくても有効なProductリッチリザルトの対象になれます。

これと混同される別の要件があります。Google Merchant Centerヘルプによると、約30か国（オーストラリア、ブラジル、カナダ、西欧の多く、インド、日本、韓国、英国、米国など）の無料商品リスティングでは、マークアップ、Merchant Centerのフィード値、Search Consoleの設定のいずれかによる配送情報が必要です。必要なのは「何らかの方法で配送情報を提供する」ことであって、「shippingDetailsスキーマプロパティが必須」という意味ではありません。別々の要件です。

Multiple options と Google’s tie-break logic

複数の料金と速度の組み合わせ（例: 5～7日で5 USD、1～2日で15 USD）を列挙でき、多くの場合そうすべきなので、Googleには表示する1件を選ぶ規則があります。ShippingService資料とSEJの記事によると、同じ購入者と配送先に複数の候補が適用できる場合、最も安い選択肢とその配送速度を表示し、料金が同じなら最も速いものを選びます。安いが遅い方法を記載すると、それが表示される可能性があります。

Precedence: 何 wins いつ ソース conflict

ほぼ全員が混同する点なので、2つの別々の問いとして整理します。

質問A — 既定値はどこに記述すべきか？ 組織レベル（ShippingService）です。これが前述した記述上の推奨事項です。

質問B — 同じ商品の配送情報を複数の情報源が宣言した場合、Googleはどの値を実際に使用するか？ これは別の問いで、答えも異なります。GoogleのMerchant Center資料は、この優先順位のうち2つの関係を直接示しています。商品レベルの配送設定はアカウントレベルの設定を上書きでき、Content API for ShoppingまたはMerchant API経由の更新はMerchant Centerでの手動編集を上書きできます。構造化データも含めた以下の4段階の全体像は、これら2つの文書化された関係と整合するmagstagsによる実務上の整理であり、単一のGoogle公式資料そのものではありません。強い順に並べると次のとおりです。

1. ショッピング向けContent API / Merchant API（アカウントレベルの設定）— 最も強い。
2. Merchant CenterまたはSearch Consoleの配送設定。
3. **商品レベルのOfferShippingDetails**マークアップ。
4. **組織レベルのShippingService**マークアップ — 最も弱い。

一見すると逆転しているように見えます。ShippingServiceは記述を推奨される既定値ですが、競合時には商品レベルのOfferShippingDetailsがそれより優先されます。どちらも正しい説明です。「既定値をどこに置くか」と「競合時に何が勝つか」は異なる軸であり、両者の混同が実務で最も多い誤りです。magstagsは、“Stronger sources override weaker ones completely. There is no blending.” (翻訳)「強い情報源は弱い情報源を完全に上書きし、値が混合されることはない」と表現しています。

silent-failure trap

これは最も重要な実務パターンですが、Googleが直接文書化した内容と、十分な裏付けのある実務観察を区別する必要があります。Googleの資料は基礎となる仕組みを確認できます。商品レベルやアカウントレベルの設定はマークアップを通知なく上書きでき、Merchant Centerは不正確または不足した配送情報を理由にリスティングを不承認にできます。一方、Googleの資料が一連の流れとして明記していないのはmagstagsが報告する次のパターンです。OfferShippingDetailsがRich Results Testに完全に合格しても、優先順位の高いMerchant Centerのフィード値やSearch Consoleの配送設定に全面的に上書きされ、どこにもエラーが表示されないことがあります。表示送料が購入時の送料と一致しなければ、最終的なリスティング拒否だけが兆候になります。これはGoogleの保証ではなく、確認すべき有力な実務パターンとして扱ってください。magstagsは、Merchant Centerで編集した配送・返品ポリシーがSearch Consoleで30日間読み取り専用になる点も指摘しています。マークアップが表示されない場合は、変更する前に優先順位の上位を確認します。

Google vs. Bing

Googleとの非対称性は明確です。Bingには、Googleのmerchant listingやShippingService資料に相当する配送スキーマ専用の資料がなく、OfferShippingDetailsやShippingServiceの必須プロパティ表も、Googleの無料リスティングに相当する配送情報要件もありません。Bing Webmaster Toolsはschema.orgマークアップを一般的に検証しますが、配送専用機能は公開していません。commerce schemaハブで説明するProductGroupと同じ状況です。Bingから別の公式説明が出るまでは、Googleと同等だと推測せず、「一般的なschema.org対応はあるが、配送専用機能はない」と扱います。

Does it 役立つ rankings

いいえ。他の構造化データと同じ注意が必要です。merchant listingやナレッジパネルに配送情報を表示する資格を得られますが、ランキングシグナルではありません。John Muellerは一般論として明確に述べています。“Structured data won’t make your site rank better,” (翻訳)「構造化データでサイトの順位が上がることはない」。また別の目的で使用しても*“won’t cause problems, but you’re unlikely to see any visible change from it in Google Search”* (翻訳)「問題は起きないが、Google検索で目に見える変化が生じる可能性は低い」としています（Search Engine Roundtableによる紹介）。

“Is schema dying?” — quick disambiguation

2025年後半、Googleが2026年1月から*“remove support for [certain] structured data types in Search Console and its API”* (翻訳)「Search ConsoleとAPIで一部の構造化データ型のサポートを削除する」という記事を見たかもしれません（SEJ）。対象は利用の少ない無関係な一部の型であり、配送スキーマとは関係ありません。配送スキーマでは逆に、同じ時期の2025年11月にShippingServiceが追加され、機能が拡張されました。その週のMuellerの説明、“markup types come and go, but a precious few you should hold on to” (翻訳)「マークアップ型には盛衰があるが、維持すべき重要なものも少数ある」（SER）という見方が適切です。誤報を理由に有効な配送マークアップを削除しないでください。

どこ この sits

OfferShippingDetailsは構造化データサブクラスターのプロパティレベル型で、ProductやProductGroupとともにcommerce schemaハブの配下にあります。最も近い型はMerchantReturnPolicyで、配送ではなく返品に同じ組織レベルの既定値／Offerレベルの上書き構造を適用します。より広い語彙、非推奨化のサイクル、型の選び方はschema markupを、記述形式はJSON-LDを参照してください。

AI要約

Advanced版の要点をまとめます。

• 概要。 OfferShippingDetails（schema.org）はshippingDetailsを介してOffer配下にネストする構造化データです。shippingRate（MonetaryAmount）、shippingDestination（DefinedRegion）、deliveryTimeを宣言します。地域や料金／速度の区分ごとに、1商品へ複数記述できます。
• 2025年11月の2階層構造。 Googleはカタログ全体の既定値を組織レベルの**ShippingService（Organization.hasShippingService）で一度だけ宣言し、OfferShippingDetailsは商品ごとの上書きに限ることを推奨しています。MerchantReturnPolicyと同じ分担です。OfferShippingDetailsは非推奨になったのではなく、位置付けが変わりました**。削除されたのはShippingRateSettingsの重複フィールドだけです。
• deliveryTime = handlingTime + transitTime。 handlingTimeは発送前の倉庫処理時間、transitTimeは発送後の配送業者による輸送時間です。締切後の注文ではcutoffTimeにより1日加わります。単一の数値ではありません。
• 推奨であって必須ではない。 merchant listingで必須なのはprice（0より大きい値）とpriceCurrencyだけです。これとは別に、約30か国の無料商品リスティングでは何らかの配送情報が必要です。
• 混同される2つの軸。 (A) 既定値をどこに書くか → 組織レベル。(B) 競合時に何が勝つか → Content／Merchant API → Merchant Center／Search Console設定 → 商品レベルのOfferShippingDetails → 組織レベルのShippingServiceの順です。既定値は組織レベルで書くよう推奨されますが、競合時はOfferレベルの上書きがそれより優先されます。
• 通知されない失敗。 マークアップがRich Results Testに通っても、フィード値やSearch Console設定にエラーなく全面的に上書きされ、表示送料と購入時の送料が不一致なら後でリスティングが拒否される場合があります。Merchant Centerで編集したポリシーはSearch Consoleで30日間読み取り専用になります。
• 同順位の選択。 複数の方法がある場合、Googleは最も安いものを表示し、料金が同じなら最も速いものを選びます。
• ランキング要因ではなく、Bingに配送専用機能はない。 得られるのは表示資格だけです（Mueller）。2026年1月のSearch Consoleにおける一部型の終了は無関係で、配送スキーマは削減ではなく拡張されました。

公式ドキュメント

Googleとschema.orgの一次資料です。

schema.org

• OfferShippingDetails — 型そのものと全プロパティ表。
• shippingDetails — この型をネストするOfferのプロパティ。
• ShippingDeliveryTime — handlingTime、transitTime、cutoffTime、businessDays。
• ShippingService — 2025年11月の再編で追加された組織レベルの型。

Google

• Merchant listing（商品）の構造化データ — 必須／推奨プロパティと、「代わりにOrganization配下で全体配送ポリシーを提供する」という注意。
• 配送ポリシー（ShippingService）の構造化データ — 2025年11月の組織レベル資料、上書き関係、ShippingConditions。
• 返品ポリシー（MerchantReturnPolicy）の構造化データ — 構造が対応する関連型。
• Product構造化データの概要 — Product内でのOfferとshippingDetailsの位置付け。
• 無料リスティングの国別要件（Merchant Centerヘルプ） — 約30か国における配送情報要件。
• 対応する構造化データ属性と値（Merchant Centerヘルプ） — フィード属性とスキーマの対応。

Google — ブログ発表

• 配送・返品ポリシーを共有する新しい方法（2025年11月12日） — 現行仕様の発表（Search Console設定と組織レベルのShippingService）。
• 小売業者の配送データに対するSchema.orgの新サポート（2020年9月） — shippingDetailsの最初の発表。

schema.orgプロジェクト

• Issue #3617 — 組織レベルの配送提案 — ShippingServiceを導入したIrina Tuduceの提案。

出典からの引用

schema.orgとGoogleが公式に述べた内容です。ページ上で本文を取得できたものは、引用箇所へ直接移動するリンクを付けています。

schema.org — 型とプロパティ

• “OfferShippingDetails represents information about shipping destinations.” (翻訳)「OfferShippingDetailsは配送先に関する情報を表します。」 引用箇所へ
• shippingDetailsについて: “Indicates information about the shipping policies and options associated with an Offer.” (翻訳)「Offerに関連付けられた配送ポリシーと選択肢に関する情報を示します。」 引用箇所へ
• deliveryTimeについて: “The total delay between the receipt of the order and the goods reaching the final customer.” (翻訳)「受注から商品が最終顧客へ届くまでの合計時間です。」 引用箇所へ
• handlingTimeについて: “The typical delay between the receipt of the order and the goods either leaving the warehouse or being prepared for pickup.” (翻訳)「受注から、商品が倉庫を出るか受け取り準備が整うまでの標準的な時間です。」 引用箇所へ
• transitTimeについて: “The typical delay the order has been sent for delivery and the goods reach the final customer.” (翻訳)「注文が配送に出されてから商品が最終顧客へ届くまでの標準的な時間です。」 引用箇所へ

Google — 組織レベルの推奨事項（2025年の位置付け変更）

• “We recommend you provide a global shipping policy for your business under Organization markup instead… Only if some of your products have specific shipping policies for which you need to override your global shipping policy, or if you don’t provide a standard shipping policy for your business, use this property under Offer.” (翻訳)「事業全体の配送ポリシーはOrganizationマークアップで提供することを推奨します。全体ポリシーを上書きする固有の配送ポリシーを持つ商品がある場合、または標準配送ポリシーを提供しない場合だけ、このプロパティをOffer配下で使用してください。」 — Google Search Central、merchant listing資料。 引用箇所へ このセッションでライブページをテキスト抽出して得た引用です。最終版として扱う前に、ブラウザで正確な#:~:text=フラグメントを確認してください。

Google — 上書き関係（ShippingService側からの説明）

• “If you need to override your standard shipping policy for a specific product, specify one or more instances of the OfferShippingDetails type.” (翻訳)「特定の商品で標準配送ポリシーを上書きする必要がある場合は、OfferShippingDetails型を1つ以上指定してください。」 — Google Search Central、配送ポリシー資料。 引用箇所へ
• “Many merchants have shipping policies that outline the process of shipping purchased products for customers. When you add ShippingService structured data to your site, Google Search can use this information to display shipping information alongside your products.” (翻訳)「多くの販売事業者は、購入商品を顧客へ配送する手順を定めた配送ポリシーを持っています。サイトにShippingService構造化データを追加すると、Google検索はその情報を使って商品とともに配送情報を表示できます。」 引用箇所へ

GoogleのJohn Mueller — ランキング要因ではない

• “Structured data won’t make your site rank better.” (翻訳)「構造化データでサイトの順位が上がることはありません。」 紹介記事
• “Exactly. Understand that markup types come and go, but a precious few you should hold on to (like title, and meta robots).” (翻訳)「その通りです。マークアップ型には盛衰がありますが、titleやmeta robotsのように維持すべき重要なものも少数あると理解してください。」 紹介記事

schema.orgのGitHub提案（#3617）— 再編の理由

• “This change introduces a new type, ShippingService, that groups shipping constraints… Redundant fields from ShippingRateSettings are therefore… deprecated.” (翻訳)「この変更では、配送制約をまとめる新しいShippingService型を導入します。そのためShippingRateSettingsの重複フィールドは非推奨になります。」 提案を読む

Which shipping type すべき I 使用

「OfferShippingDetails、ShippingService、何も記述しない」のどれを選ぶかを1つの経路で判断します。これは記述場所を決める問いであり、競合時に何が勝つかという優先順位とは別です。優先順位は早見表を参照してください。

OfferShippingDetails — cheat sheet

2つの階層、2つの役割

主要プロパティ（OfferShippingDetails内）

deliveryTimeの内訳

優先順位 — 競合時に何が勝つか（強い → 弱い）

1. ショッピング向けContent API / Merchant API
2. Merchant Center / Search Consoleの設定
3. 商品レベルのOfferShippingDetails
4. 組織レベルのShippingService

問いは2つあります。既定値をどこに記述するか（組織レベル）と、競合時に何が勝つか（Offerレベルが組織レベルより優先）です。どちらも正しい説明です。“Stronger sources override weaker ones completely. There is no blending.” (翻訳)「強い情報源は弱い情報源を完全に上書きし、値が混合されることはありません。」

要点

• shippingDetailsは推奨であって必須ではありません。merchant listingで必須なのはprice（0より大きい値）とpriceCurrencyだけです。
• これとは別に、約30か国の無料リスティングでは何らかの配送情報が必要です。
• 複数のエントリを記述できます。Googleは最も安いものを表示し、同額なら最も速いものを選びます。
• ランキング要因ではなく、得られるのは表示資格だけです。
• 通知されない失敗: Rich Results Testに通っても、フィードやSearch Consoleの設定にエラーなく上書きされる場合があります。Merchant Centerで編集したポリシーはSearch Consoleで30日間読み取り専用になります。
• 2025年11月、OfferShippingDetailsは非推奨になったのではなく、位置付けが変更されました。

機能 JSON-LD

説明用の例です。公開前にRich Results Testとschema.org validatorで自サイトのコードを検証し、値がフィードや購入手続きと完全に一致することを確認してください。

1. OfferレベルのOfferShippingDetails（商品ごとの上書き）

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Merino Wool Beanie",
  "offers": {
    "@type": "Offer",
    "price": 29.00,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": 5.00,
        "currency": "USD"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "US"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": 0,
          "maxValue": 1,
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 2,
          "maxValue": 5,
          "unitCode": "DAY"
        }
      }
    }
  }
}

この例は、米国内の送料を5 USD、処理時間を0～1日、輸送時間を2～5日、つまり「約2～6営業日で到着」と示します。

2. 複数の配送方法（通常配送と速達配送）

shippingDetailsは配列を受け取ります。すべての区分を列挙し、Googleの選択規則（最安値、同額なら最速）を適用させます。

"shippingDetails": [
  {
    "@type": "OfferShippingDetails",
    "shippingRate": { "@type": "MonetaryAmount", "value": 5.00, "currency": "USD" },
    "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" },
    "deliveryTime": {
      "@type": "ShippingDeliveryTime",
      "transitTime": { "@type": "QuantitativeValue", "minValue": 5, "maxValue": 7, "unitCode": "DAY" }
    }
  },
  {
    "@type": "OfferShippingDetails",
    "shippingRate": { "@type": "MonetaryAmount", "value": 15.00, "currency": "USD" },
    "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" },
    "deliveryTime": {
      "@type": "ShippingDeliveryTime",
      "transitTime": { "@type": "QuantitativeValue", "minValue": 1, "maxValue": 2, "unitCode": "DAY" }
    }
  }
]

3. 送料無料

送料無料は、valueを0にしたshippingRateで表します。

"shippingRate": { "@type": "MonetaryAmount", "value": 0, "currency": "USD" }

4. 特定地域へ配送しない

{
  "@type": "OfferShippingDetails",
  "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "AU" },
  "doesNotShip": true
}

カタログ全体で1つのポリシーを共有する場合、組織レベルのShippingService（Organization.hasShippingService配下）が記述を推奨される既定値です。上記のOfferレベルのブロックは、実際に条件が異なる商品だけに使います。

Mistakes と myths

OfferShippingDetailsで繰り返される誤りは次のとおりです。

• 「ProductリッチリザルトにはshippingDetailsが必須。」 違います。配送情報の拡張では推奨プロパティです。必須なのはprice（merchant listingでは0より大きい値）とpriceCurrencyだけです。これとは別に、約30か国の無料リスティングでは何らかの配送情報が必要です。
• 「OfferShippingDetailsを追加すれば送料が必ず表示される。」 いいえ。優先順位の高いMerchant Centerのフィード値やSearch Consoleの設定が、有効なマークアップを通知なく上書きし、リスティング拒否までエラーが出ない場合があります。マークアップを変更する前に上位の情報源を確認してください。
• 「ShippingServiceがOfferShippingDetailsを置き換え、非推奨にした。」 いいえ。OfferShippingDetailsは引き続きOffer配下の上書きとして使います。非推奨になったのはShippingRateSettings内の一部の重複フィールドで、型そのものではありません。
• 2つの軸を混同する。 「既定値は組織レベルで記述する」（記述方針）と「競合時には商品レベルが組織レベルより優先される」（優先順位）は、異なる問いへの答えなので両方とも正しい説明です。
• deliveryTimeを1つの数値にまとめる。 handlingTime（自社の処理時間）とtransitTime（配送業者の輸送時間）の合計です。根拠のない単一の「配送時間」を公開すると両方を誤って表し、購入時の表示と異なれば拒否の原因になります。
• マークアップがフィードや購入手続きと一致しない。 強い情報源が値を完全に上書きするため、マークアップの送料がフィードや実際の購入時送料と異なる状態は、無害な重複ではなく拒否リスクです。完全に一致させてください。
• 「スキーマは衰退しているので配送マークアップも不要。」 2026年1月にSearch Consoleで終了する利用の少ない無関係な一部の型と配送スキーマを混同しています。配送スキーマは2025年11月に削減ではなく拡張されました。
• 「この構造化データはランキングに役立つ。」 いいえ。得られるのはリッチリザルトの表示資格で、順位上昇ではありません（Muellerが繰り返し説明しています）。

一般的な shipping-markup 問題

ValidatorはJSON-LDを受理するが配送データが誤っている

原因: 構文が正しくても、地域、送料、期間が古い場合があります。修正: マークアップを購入手続き、フィード、事業ポリシーのデータと照合します。

誤った配送先に配送情報が表示される

原因: 配送先の制約が不足しているか、誤った階層でモデル化されています。修正: 各配送サービスと配送先を明示的に対応付け、代表的な住所でテストします。

複数の配送情報源が一致しない

原因: ページのマークアップ、Merchant Center、アカウント設定が別々に管理されています。修正: 運用上の信頼できる基準を1つ選び、すべての表示面を同期します。

Validation tests

公開済み配送マークアップをテストする

実行するテスト — 代表的な商品ページを検証し、抽出された配送先、送料、処理時間、輸送時間を購入手続きと比較します。期待結果 — 表示資格を持つマークアップがユーザーに提示される内容と一致します。失敗の解釈 — マッピングまたは元データが不完全です。監視期間 — 即時。ロールバック条件 — 実質的に誤った配送条件を公開した場合は展開を取り消します。

情報源の一貫性をテストする

実行するテスト — 同じ商品と配送先について、ページのJSON-LD、フィード／アカウントの配送設定、購入手続きを比較します。期待結果 — 説明できない競合がありません。失敗の解釈 — 別々のシステム間で差異が生じています。監視期間 — ポリシー変更のたび。ロールバック条件 — 変更によって不一致が生じた場合は、直前の一貫した構成へ戻します。

テスト yourself: OfferShippingDetails Schema

OfferShippingDetailsの仕組みと、2025年11月の再編後の位置付けを確認する5問です。各問の答えを選んで確認してください。

時間を使う価値のあるリソース

関連記事

• 構造化データとは何か、どう使うか — スキーマ型、実装、検証、sameAsのリスクを扱う私のAhrefsガイド。この配送型が属する広い文脈を説明します。
• テクニカルSEO初心者ガイド — より広い技術領域における構造化データの位置付け。

講演

• 検索の仕組み（SlideShare）— クロール、レンダリング、インデックス、マークアップの利用方法を解説した講演です。通常の免責事項も適用されます。“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳)「これはシステムに対する私の理解であり、100%完全または正確とは限りません。」

公式資料

• Google — Merchant listingの構造化データと配送ポリシー（ShippingService） — 必須／推奨プロパティと組織レベル／Offerレベルの関係を定義する2つのリファレンス。
• Google — 配送・返品ポリシーを共有する新しい方法（2025年11月12日）— Search Console設定と組織レベルのShippingServiceの発表。
• schema.org — OfferShippingDetails・ShippingDeliveryTime・ShippingService — 語彙そのもの。
• schema.org提案 #3617 — 再編の基になったGitHub issue（GoogleのIrina Tuduce）。

業界資料

• Googleが販売事業者の配送ポリシー向け構造化データを公開（Search Engine Journal、Matt G. Southern、2025年11月12日）— 2025年11月の公開内容と選択規則を明確に説明した署名記事。
• Googleは2026年に構造化データの利用を縮小していない（Search Engine Journal、Roger Montti、2025年11月11日）— 2026年1月のSearch Consoleにおける一部型の終了と配送スキーマ拡張を区別します。
• Googleが返品ポリシーの構造化データ要件を更新（Search Engine Journal、2025年3月14日）— 関連する返品ポリシー型でreturnPolicyCountryを厳格化した変更。
• Search Consoleまたは新しいマークアップによるGoogleの配送・返品ポリシー（Search Engine Land）— Search Consoleとマークアップの選択肢。
• Googleの配送・返品設定（magstags）— 優先順位と通知されない失敗を詳しく扱う実務記事。“there is no blending” (翻訳)「値が混合されることはない」と説明しています。
• Googleがオンライン販売事業者向け配送ポリシーの選択肢を拡張（ppc.land）— 2025年11月の変更を裏付ける記事。

変更履歴