製品仕様変更チェックリストは事務作業ではありません。20 mm の改訂と、コンテナ1本分のクレームとの間にある距離そのものです。寸法を1つ変えたとき、実際に変えたのは、すでに9か所以上で公開されている数字です。多くのサプライヤーが更新するのは2か所——自分が覚えている商品ページの項目と、あとは何もありません。
残りはすべて、古い数字を発信し続けます。ショッピングフィード、製品画像、営業が先週メールで送った PDF、外装箱のケースマーク、箱の中に封入された取扱説明書。どれも「自分は間違っています」とは教えてくれません。教えてくれるのは買い手で、しかもたいていはコンテナが出港したあとです。
1つの寸法が同時に存在する9か所
製品仕様変更チェックリストとは、寸法・重量・材質といった数字が公開されているすべての場所を固定リストにしたもので、1回の改訂が、下流の誰かが不一致を見つける前にすべてに届くようにするためのものです。以下は「どれだけ早く痛むか」の順に並べています。
| # | 数字がある場所 | 項目または成果物 | 誰が読むか | 古いままだと何が壊れるか | 現実的な修正リードタイム |
|---|---|---|---|---|---|
| 1 | モールの商品属性 | 商品ページに表示される商品/製品寸法 | 買い手、購入ボタンを押す前に | サイズ違いの返品、「説明と異なる」クレーム | 数分 |
| 2 | モールの梱包属性 | 梱包寸法または配送寸法 | 配送業者と送料計算エンジン | 送料見積りの誤り、手数料の突合ずれ | 数分 |
| 3 | ショッピングフィード | product_length / product_width / product_height / product_weight |
Google ショッピング、比較エンジン、AI ショッピングエージェント | サイズで絞り込む検索から商品が消える/フィード警告 | 次回のフィード取得 |
| 4 | 自社サイトの構造化データ | schema.org の width / height / depth |
検索エンジンと回答エンジン | 自社サイトが自社の商品ページと矛盾する | 次回のデプロイ |
| 5 | 製品画像・寸法図 | ピクセル——数字が焼き込まれている | すべての買い手が、どのテキストよりも先に | ページ上でいちばん目立つ誤った数字 | 数日、デザイナーが入るなら |
| 6 | 拡張コンテンツと比較表 | モジュールの文言とモジュール画像 | ギャラリーの先までスクロールする買い手 | 自社の商品ページ内での無言の矛盾 | 数日、多くは再審査あり |
| 7 | カタログ、ラインシート、見積書 | 担当者がそのままメールに貼り付ける PDF | B2B バイヤー、調達エージェント、代理店 | 失効した数字を書面で見積もってしまう | 誰かが思い出したとき |
| 8 | 出荷書類と外装箱のケースマーク | 外装箱寸法、正味重量と総重量 | 通関、フォワーダー、荷受け側 | 積付け計画が狂い、貨物が留置または拒否される | 出荷ごと |
| 9 | 取扱説明書、組立説明書、パッケージ版下 | 印刷済みで、すでに在庫にある | エンドユーザー、納品後に | サポート問い合わせと星1レビュー | 次回の印刷ロット |
9か所、責任者は5種類、リードタイムは数分から印刷ロット1回分まで。製品データの変更管理の難所は、この非対称性に尽きます。数秒で直せる項目ほど記憶に残っていて、数日かかる場所ほど買い手が最初に見ます。行ごとに責任者の名前が書かれていない製品仕様変更チェックリストは、ただの願望リストです。
古い寸法はデータの問題のままでは終わりません。返品になり、返品には1個あたりの原価がありますが、実際に計算したことのある販売者はほとんどいません——返品コスト計算ツールは、返品率を経理が反応する金額に変換します。
同じ製品に正しい数字が複数ある理由
9か所を点検する前に、少し落ち着かない事実を受け入れてください。そのうち2か所の数字が食い違っていて、しかも両方とも正しい、ということがあり得ます。共有製品データを規定する GS1 のルールが特定の丸め方を強制し、しかも丸める方向は一方向だけだからです。
GS1 GDSN 包装測定ルール標準(Release 2.5、2016年9月承認)によると:
- ミリメートルは常に切り上げて整数ミリにします。99.3 mm は 100 mm になります。
- インチは常に切り上げて 0.05 インチ単位にします。2.942 インチは 2.95 インチになります。
- 単位系をまたぐときは、先に換算してから丸めます。1インチ = 25.4 mm を使います。
- 3つの線寸法は、同じ測定系・同じ単位で表記します。
- 必ず最大距離を測ります——突起、キャップ、フタ、パッケージに付属する同梱物も含め、無視しません。
これらを合わせて読むと、結論は明らかです。99.3 mm の部品は、GDSN 連携システムでは 100 mm として、ヤードポンド法の市場では 3.95 インチとして公開され、図面には 99.3 と書かれたままです。3つの数字、1つの部品、誤りはゼロです。
この標準は公差も公開しています。ケース単位のような非消費者向け取引単位では、GS1 の標準公差は奥行・幅・高さそれぞれ 4.0%、下限は 0.25 インチ(7 mm)、総重量は 4.0%、下限は 0.2 lb(0.1 kg)です。これより小さい改訂なら、ケースのデータを動かす必要がない場合もあります。これより大きい改訂なら、古い数字を持っているすべてのシステムは「未更新」ではなく「公差外」です。
もう1つ、正当な食い違いの原因があります。軸の呼び方です。GS1 は、製品のデフォルト正面——ブランドオーナーが販促に使う面——を基準に高さ・幅・奥行を決めます。工場の図面は、ほぼ間違いなく別の基準で長さ・幅・高さを取っています。どの軸がどれなのか、なぜ買い手が順序を読み違えるのかは、それ自体が落とし穴です。買い手が自分の書いた順番どおりに3つの数字を読むと決めつける前に、長さ・幅・高さの順序を確認してください。
製品寸法と配送寸法は別の項目です
これはチェックリスト全体でいちばん多い失敗です。どちらの項目も数字を受け付け、どちらも文句を言わないからです。
Google Merchant Center は両者を完全に分けており、有効な値の範囲すら共有していません:
| 製品測定の属性 | 配送寸法の属性 | |
|---|---|---|
| 属性 | product_length、product_width、product_height、product_weight |
shipping_length、shipping_width、shipping_height |
| 何を表すか | 製品そのもの | 製品が入って出荷される梱包 |
| 使える単位 | cm、in(重量:lb、oz、g、kg) | cm、in |
| 値の範囲 | cm と in で 1–3000 | 1–400 cm、1–150 in |
| 何に使われるか | 商品の発見と検索結果の正確性 | 配送業者が計算する送料 |
| 必須ルール | 3つすべてで同じ単位を使うこと。そうしないと情報は表示されません | いずれか1つを入れるなら、寸法属性はすべて入れること |
決め手は範囲の違いです。上限が 400 cm の項目は、もともと製品寸法を入れる場所ではありません。3000 cm を受け付ける項目は、もともと外装箱の送料を計算する場所ではありません。チームの誰かが同じ3つの数字を両方に貼り付けてきたなら、今この瞬間、どちらかが間違っています。
構造化データはさらに3つ目の語彙を持ち込みます。schema.org の Product には width、height、depth があり、length というプロパティは存在しません。それぞれ unitCode を持つ QuantitativeValue で表します。1回の改訂、3つの命名規則、3つのシステム、互いの画面を一度も見ない3人。自社サイトでこれが未入力なら、製品寸法の構造化データは9か所の中でいちばん安く直せます。
モールはもう1つ厄介さを足します。Amazon は Product Type Definitions API を通じて商品タイプごとの属性を JSON スキーマとして公開しているため、ある商品タイプに存在する寸法項目が、別の商品タイプにも存在するとは限りません。「複数プラットフォームで製品仕様を更新する」は1つの作業ではありません。スキーマの数だけ作業があります。
いちばん更新されない場所は画像です
表をもう一度見てください。1行目から4行目はテキスト項目で、運用担当者が午前中のうちに直せます。7行目から9行目は文書で、文書には改訂が要ることを全員が受け入れています。
何年も間違ったまま残るのは5行目です。数字がピクセルの中にあるからです。直すには、元ファイルを探し、作った人を探し、変更内容を伝え、待ち、確認し、すべてのチャネルに再アップロードすることになります。だから多くの会社での正直な答えはこうです——次に撮り直すときに直します。その「次」は来ません。
これは高くつきます。画像は買い手が最初に読むもので、社内で最後まで誰も点検しないものだからです。スペック表は流し読みされます。写真に印字された寸法は信じられます。
現実的な解決策は、寸法図をアートワークではなく、自社データのビューとして扱うことです。製品の実際のエッジに合わせて一度きちんと測り、注釈レイヤーを JPEG に統合せず編集可能なまま保持し、数字が変わったら各チャネルの画像仕様で書き出し直します。こうすれば5行目はデザイン案件から2分の編集作業に縮み、実際にやり切れる唯一の形になります。
これが現実的かどうかはツール選定で決まります。測るソフトウェア——寸法線を対象物の実際のエッジにスナップさせ、数字をそのジオメトリに紐づけ続けるもの——は、入力を変えれば正しく更新されます。もっともらしい注釈付き写真を生成するだけの画像生成は、何も測っていません。妥当そうに読める数字を作り出すだけで、検証できません。マーケティング用の背景画像ならそれで十分な取引です。買い手がクレームの根拠にする数字としては、足りません。見積書に添える仕様書も同じ理屈です。価値はデザインの見栄えではなく、記載されたすべての数字が実測にたどれることにあります。
製品仕様変更チェックリスト
この製品仕様変更チェックリストを変更申請のチケットにそのままコピーしてください。1周で完了、4グループ、誰が何を持つか迷いません。
マスターデータ
- 改訂後の数字を、改訂番号と日付を付けて、他のすべてがコピー元にするファイルに1回だけ記録した
- 単位と測定系を明示した(mm かインチか——「1180」だけで済ませない)
- GS1 の最大距離ルールに従い、突起・取っ手・キャップ・フタを含めて測った
- 今回の変更が 4% / 7 mm のケース公差を超えるかどうかを確認した。これが下流のどこまで波及するかを決める
買い手が見る項目
- いちばん大きいモールだけでなく、すべてのモールで商品/製品寸法を更新した
- 梱包寸法または配送寸法を別途更新し、梱包側の数字であることを確認した
- ショッピングフィードの製品属性を更新し、フィードを再取得して警告を確認した
- 自社商品ページの構造化データを更新した
画像と文書
- 寸法図または注釈付き写真を書き出し直し、掲載しているすべてのチャネルに再アップロードした
- 拡張コンテンツ、比較表、古い数字を含むすべての画像を差し替えた
- カタログ、ラインシート、見積書テンプレートを再生成し、共有ドライブとメールテンプレートから旧 PDF を削除した
紙と印刷
- パッキングリスト、インボイス、ケースマークのテンプレートを次回出荷分に向けて更新した
- 取扱説明書、組立説明書、パッケージ版下を次回の印刷ロット向けに申し送りし、既存在庫を数えた
- 失効した数字で出した見積書を特定し、買い手が自分で気づく前に伝えた
作業の順序
ここではスピードより順序が重要です。キャッシュされる工程と、機械に読まれる工程が混ざっているからです。
- まずマスターデータを凍結します。 まだ2人が数字を編集しているなら、以下すべてがその食い違いを引き継ぎます。
- 買い手が見るモールの項目を更新します。 変更がいちばん速く、痛みが出るのもいちばん速い場所です。
- フィードに触る前に画像を書き出し直します。 フィードとキャッシュが新しい画像 URL と新しい数字を同じサイクルで拾うので、不一致の窓が開きません。
- フィードを送信して再取得します。 商品が警告に引っかかっていないか確認します。却下された商品は、古いままの商品より悪い状態です。
- 文書を再生成します。 カタログ、ラインシート、見積書テンプレート——旧ファイルはリネームではなく削除します。
- 印刷は最後です。 印刷ロットは、このリストで唯一やり直しの利かない工程です。
そのうえで、ほとんど誰もやらないことを1つやってください。自社の製品名で検索し、ログインせずにスマートフォンで、買い手として自分の商品ページを読みます。見落としていた矛盾は、だいたい8秒で目に入ります。
よくある質問
検索順位を落とさずに商品ページの製品寸法を更新するには?
属性をその場で編集してください。データ項目を変えることは商品の再出品ではないので、商品ページの履歴は残ります。実際にダメージになるのは、「きれいにやり直す」ために商品を削除して作り直すことです。レビュー、販売履歴、買い手がブックマークした識別子が消えます。
商品寸法と梱包寸法の違いは?
商品寸法(製品寸法)は製品そのものを表し、買い手はそれで入るかどうかを判断します。梱包寸法(配送寸法)は運ばれる箱を表し、配送業者はそれで送料を計算します。Google Merchant Center はスキーマの段階で分離しています。product_length とその仲間は 3000 cm またはインチまで受け付け、shipping_length とその仲間は 400 cm または 150 インチが上限です。
寸法が変わったら製品画像も必ず変える必要がありますか?
はい。しかもリストの中で優先度が最も低いのではなく、最も高い成果物です。画像に印字された数字はスペック表より先に読まれ、買い手が指をさせるぶん、紛争では重く扱われます。注釈が JPEG に統合されていて編集可能な元データがないなら、今が写真の上に生きたレイヤーとして作り直すタイミングです。次の改訂が数分で終わるようになります。
寸法がどれくらい変わったら買い手に伝える必要がありますか?
商売の観点では、はまり具合・クリアランス・段積みに影響する変更なら伝えてください。これは閾値ではなく判断です。共有製品データについては公開された基準点があります。ケース単位に対する GS1 の標準公差は、寸法ごとに 4.0%、下限 7 mm です。この幅の内側ならデータ上のノイズです。外側なら、古い数字を持つすべてのシステムが公差外ということになります。
ミリメートルとインチ、どちらで公開すべきですか?
対象市場が要求する測定系で公開し、3軸すべてを同じ単位で公開してください。GS1 は3つの線寸法が1つの測定系・1つの単位を共有することを求めています。換算するときは、1インチ = 25.4 mm を使って先に換算し、あとから丸め、その単位の切り上げルールを適用します。すでに丸めた数字を換算するのが、3 mm の誤差が 6 mm の誤差になる経路です。
参考資料・出典
- Google Merchant Center ヘルプ —— Product length、product width、product height、product weight:単位、形式、値の範囲
- Google Merchant Center ヘルプ —— Shipping length、shipping width、shipping height:使用できる単位と値の上限
- GS1 —— 包装・製品測定標準(現行版)
- GS1 —— GDSN 包装測定ルール標準 Release 2.5(2016年9月承認):丸めルール、デフォルト正面、標準公差
- schema.org —— Product:width、height、depth と QuantitativeValue プロパティ
- Amazon Selling Partner API —— Product Type Definitions メタスキーマ(属性は商品タイプごとに定義される)
