AIで商品の色・サイズ別の登録漏れを確認するときは、商品一覧の行数だけで判断しません。登録予定の組合せを先に決め、存在しない仕様を除き、同じ組合せの重複と想定外の行を分けます。予定が5種類で一覧も5行あっても、2種類が抜けていることがあります。
この記事では、架空のTシャツ1商品の登録準備表を使います。作るのは確認用の一覧で、商品登録や公開、在庫変更は行いません。AIの照合精度や、実際のEC管理画面を検証した例でもありません。
目次
商品とバリエーションの識別単位を分ける
Shopifyは、サイズや色などの選択肢の値を組み合わせたものを商品のバリエーションとして説明しています。例えば「青・S」は、その商品内の一つの組合せです。同社の説明では、バリエーションごとの在庫も別に管理します。Shopify:バリエーション(新しいタブで開く)
ここでは、この区別を参考に商品ID、色、サイズの3列を一つの照合キーとします。実際のシステムでは素材や販売地域なども関係するかもしれません。自社の商品の識別条件を確認してから列を決めます。SKU、管理システムのバリエーションID、今回の照合キーが同じ意味だとは仮定しません。
今回の対象は商品P01だけです。別商品の「青・S」をP01の登録済みとして数えないように、商品IDも残します。比較中に色名を勝手に統合せず、「青」と「BLUE」を同じ値にするなら、先に対応表を確定して原値も保持します。
色×サイズから、製造しない組合せを除く
次は架空の仕様表です。色はBLUEとWHITE、サイズはS・M・Lとします。ただし、WHITE・Lは製造しないという条件を置きます。これは説明用に確定した条件で、AIが一覧の欠け方から推測したものではありません。
表は横にスクロールできます
| 商品 | 色 | サイズ | 今回の登録予定 |
|---|---|---|---|
| P01 | BLUE | S | 対象 |
| P01 | BLUE | M | 対象 |
| P01 | BLUE | L | 対象 |
| P01 | WHITE | S | 対象 |
| P01 | WHITE | M | 対象 |
| P01 | WHITE | L | 製造しないため対象外 |
全組合せは2色×3サイズ=6種類です。製造しない1種類を除くので、今回の登録予定は5種類になります。全組合せを作る処理と、登録対象にする判断を分けてください。Pythonのitertools.productは直積を列挙する機能で、業務上どの組合せを販売するかは決めません。Python:itertools.product(新しいタブで開く)
「製造しない」と「一時的に在庫がない」も別です。登録済み商品の在庫が0という理由だけで、予定の組合せから外しません。逆に、未登録の組合せを在庫0と書き換えると、登録そのものの不足を隠してしまいます。
5行あっても、予定5種類がそろっていない
次は照合する架空の登録準備表です。行IDとSKUはすべて異なりますが、色とサイズには重複があります。この表に価格や在庫数は含めません。
表は横にスクロールできます
| 元行ID | 商品 | 色 | サイズ | SKU |
|---|---|---|---|---|
| V01 | P01 | BLUE | S | TS-BS |
| V02 | P01 | BLUE | M | TS-BM |
| V03 | P01 | WHITE | S | TS-WS |
| V04 | P01 | WHITE | S | TS-WS2 |
| V05 | P01 | BLACK | M | TS-KM |
V03とV04はSKUが違っていても、今回のキーでは同じ商品・色・サイズです。自動で一方を消したり、SKUが別だから別種類として数えたりせず、商品の識別条件が正しいかを確認する対象にします。実際には別素材などの区別があるなら、仕様表とキーの方を見直します。
V05のBLACKは、今回の仕様表にない色です。「新色の追加」と補完せず、想定外として元行へ戻します。仕様表が古い可能性もあるため、登録表の値を正しいとも、誤りとも断定しません。
未登録、想定外、重複をそれぞれ出す
表は横にスクロールできます
| 確認区分 | この例の結果 | 次に確かめること |
|---|---|---|
| 予定内で登録表にある組合せ | BLUE・S、BLUE・M、WHITE・Sの3種類 | 元行と仕様の対応 |
| 予定内だが登録表にない組合せ | BLUE・L、WHITE・Mの2種類 | 追加準備が必要か、仕様変更があるか |
| 予定外の登録行 | V05のBLACK・M、1行 | 色の仕様と元行 |
| 同じキーが複数ある組合せ | WHITE・Sの1組、V03・V04の2行 | 別商品条件か、重複登録か |
重複は「1組・2行・余分な行が1行」と数える単位を分けます。5行から重複分を1行分だけ除いても、残る4種類のうち1種類は想定外です。予定内の登録済み組合せは3種類なので、予定5種類との差は2種類になります。
元の5行は、予定内の異なる組合せを代表する3行分、同じキーの追加1行分、予定外1行分に分解できます。ただし「代表する3行分」は計数上の表現で、V03とV04のどちらを採用したという意味ではありません。両行の確認が終わるまで、自動で採用行を決めません。
WHITE・Lは仕様表で対象外なので、未登録2種類へ含めません。欠けているすべての直積を登録漏れとすると、この対象外まで追加候補へ入れてしまいます。
掲載例をコードと別の一覧で検算する
次のコードは、上の固定した架空表を照合するものです。行を辞書で上書きせずリストのまま読み、Counterで同じキーの出現数を残します。
from collections import Counter
from itertools import product
all_keys = {("P01", color, size)
for color, size in product(["BLUE", "WHITE"], ["S", "M", "L"])}
excluded = {("P01", "WHITE", "L")}
expected = all_keys - excluded
rows = [
("V01", "P01", "BLUE", "S", "TS-BS"),
("V02", "P01", "BLUE", "M", "TS-BM"),
("V03", "P01", "WHITE", "S", "TS-WS"),
("V04", "P01", "WHITE", "S", "TS-WS2"),
("V05", "P01", "BLACK", "M", "TS-KM"),
]
counts = Counter((p, color, size) for _, p, color, size, _ in rows)
actual = set(counts)
missing = expected - actual
unexpected = actual - expected
duplicates = {k: n for k, n in counts.items() if n > 1}
assert len(all_keys) == 6 and len(expected) == 5 and len(rows) == 5
assert missing == {("P01", "BLUE", "L"), ("P01", "WHITE", "M")}
assert unexpected == {("P01", "BLACK", "M")}
assert duplicates == {("P01", "WHITE", "S"): 2}
assert len(expected & actual) == 3
assert sum(counts.values()) == len(rows)
print("missing", sorted(missing), "unexpected", sorted(unexpected),
"duplicates", duplicates)
この固定例はローカルで実行しました。別の検算では、仕様表の6行を一つずつ元行へ対応づけ、予定内3種類、未登録2種類、予定外1行、重複1組2行を確認しています。
コードは実ファイルの読込み、列の欠損、SKUの重複、異なる商品の混入などを網羅する汎用検査ではありません。実務ではその検査を追加し、同じ行数でも組合せが偏った反例を含めます。入力表の行数が予定と一致するだけでは合格にしない条件を残してください。
AIへの依頼には、対象外の根拠と元行を付ける
架空の商品P01の仕様表と登録準備表を照合してください。
キーは商品ID・色・サイズの列の組です。SKUが異なることだけで別種類にしないでください。
BLUE/WHITEとS/M/Lの直積から、仕様表で製造しないWHITE・Lを除いた5種類が予定です。
予定内で存在する組合せ、未登録の組合せ、予定外の行、重複キーを別々に返してください。
重複は組数・元行ID・行数を残し、自動で片方を削除しないでください。
BLACKを新色と推測せず、WHITE・Lを登録漏れへ含めないでください。
元行にないSKUや仕様を作らず、不足と確認質問を返してください。
商品登録、公開、在庫更新は行いません。
依頼文と結果表は手製で、AIを実行した出力ではありません。確認質問は「BLUE・LとWHITE・Mは今回登録する予定のままか」「WHITE・Sの2行には、キーへ含めるべき別の仕様があるか」「BLACK・Mの仕様変更を示す資料はあるか」です。担当者へ問い合わせ済みという記録にも変えません。
登録の充足と、購入できる状態を分ける
組合せがそろっても、価格、画像、送料、販売地域、公開状態、在庫、実際の購入操作が正しいとは限りません。今回の到達点は、登録準備表に対する確認箇所が元行と対応していることです。商品の登録や販売開始を完了したという判定には使いません。
仕様が更新されたら、対象商品、仕様書の版、選択肢、対象外条件、元表の版、照合キーを残して再確認します。追加や削除の前に、確認が必要な2種類・1行・重複2行を担当者が判断できる一覧として渡してください。行数の一致よりも、どの組合せを用意する必要があり、どこが未確定かを説明できることが役立ちます。
参考資料
公式資料の確認日:2026年10月20日。商品、仕様、対象外条件、SKU、表、依頼文は独自の架空例です。掲載コードと別方式の組合せ照合をローカルで検査しました。実商品、AI実行、EC管理画面、登録・公開、在庫、購入操作、画面表示は未検証です。
