1つの商品レコードから20種類のチャネル向けアセットを生成

チャネル横断の商品データフィールドマッピングを最も効果的に行うには、1つの正規商品レコードを維持し、各フィールドをチャネル仕様に対応付け、表示だけを変換し、公開前にすべての出力を検証します。商品情報の事実は固定したまま、タイトル、箇条書き、説明文、フィード、広告、メール、SNS素材を配信先に応じて変更します。

1つの正規レコードですべてのチャネルに対応する#

正規レコードとは、商品の識別情報、属性、販売データ、メディア、承認済みの訴求表現を統制したものです。特定のマーケットプレイス、ストアフロント、広告プラットフォーム、SNSの慣例を組み込まず、最も正確で再利用しやすい単位で事実を保持する必要があります。

長い商品説明文を唯一の正しい情報源として扱わないでください。段落形式の情報は、検証、更新、再利用が困難です。色、素材、寸法、互換性、機能、根拠のある利点を個別のフィールドに保存し、各チャネルの要件に従って組み立てます。

信頼できるマッピングパイプラインは、次の5段階で構成されます。

1. ソース： ERP、PIM、サプライヤーファイル、DAM、コマースプラットフォームから取得した元の値。
2. 正規レコード： 明確な定義と管理責任を持つ、正規化されたフィールド。
3. チャネル仕様： 必須フィールド、許容値、長さの規則、nullの処理。
4. 変換： 連結、ローカライズ、単位変換、書式設定、コピー生成。
5. 検証： 自動チェックを行い、判断が必要な箇所を人が確認。

この構造により、マッピングが明確になります。Catsyの商品データマッピングガイドで説明されているように、マッピングでは、構造や形式の違いを考慮しながらシステム間のフィールドを接続します。商品データの値を、文書化されていないコピー＆ペースト作業によって配信先フィールドへ入力してはいけません。

マッピングテーブルには、少なくとも次の列を含めます。

マッピング列	目的
source_field	データ提供元システムの元フィールド
canonical_field	マスター商品レコードで統制されるフィールド
destination_field	チャネルが要求するフィールド
scope	商品、親、バリエーション、オファー、市場、ロケール
transform_rule	書式設定、変換、連結、生成の規則
required_when	フィールドが必須になる条件
null_policy	省略、継承、ブロック、明示的な空値の送信
validation_rule	長さ、型、列挙値、関係性、内容のチェック
owner	ソース値の修正を担当するチーム
schema_version	マッピング承認時に使用したチャネル仕様

この仕様により、「商品データを送る」という作業が、検証可能な一連の判断に変わります。

正規商品レコードに含めるべきフィールド#

正規スキーマでは、事実と表示、商品とオファーを分離する必要があります。実際のフィールド名は異なっても、その意味は一貫していなければなりません。

フィールドグループ	推奨される正規フィールド	マッピングの指針
識別情報	product_id, parent_id, sku, gtin, mpn, brand	識別子は文字列として保存します。先頭のゼロを維持します。コピーからGTINやMPNを生成してはいけません。
分類	product_type, category_path, target_audience, use_case	管理された参照テーブルを使用して、社内カテゴリーを各チャネルの分類体系に対応付けます。
バリエーション構造	variant_axis_1, variant_value_1, variant_axis_2, variant_value_2	色やサイズなど、販売可能なバリエーションを作る属性を定義します。親レベルとバリエーションレベルの値を混在させてはいけません。
説明用の事実	product_name, material, color, pattern, dimensions, weight, capacity, compatibility	チャネルへマッピングする前に、単位と列挙値を正規化します。追跡できるように、サプライヤーの元の値も保持します。
利点と訴求表現	feature_facts, approved_benefits, claim_evidence, prohibited_claims	承認済みの事実のみからコピーを生成します。根拠のない最上級表現、認証、性能に関する主張をブロックします。
販売情報	regular_price, sale_price, currency, sale_start, sale_end, availability, condition	オファーデータを市場と販売者ごとに分離します。価格と日付の関係を検証します。
メディア	primary_image_url, alternate_image_urls, video_url, image_alt	アセットの順序と使用権を明確に保持します。エクスポート前に、必須アセットへアクセスできることを検証します。
コンプライアンス	country_of_origin, warning_text, age_range, ingredients, care_instructions	必要に応じて、義務付けられた文言をそのまま保持します。承認を得ずに規制対象の文言を言い換えてはいけません。
ローカライズ	locale, localized_name, localized_features, localized_description	翻訳された事実とチャネル固有のコピーを区別します。翻訳元のロケールと承認状況を記録します。
ガバナンス	source_system, source_record_id, updated_at, approved_at, content_status	これらのフィールドを使用して、古いエクスポートの検出、競合の解決、変更の監査を行います。

3つの区別によって、多くのマッピングエラーを防げます。

第一に、product_idとskuは同じものではありません。1つの商品に複数の販売可能なバリエーションが含まれる場合があり、各SKUは特定の商品を識別します。親レベルのコピーでは共通の商品を説明できますが、バリエーションレベルの出力には正しい差別化要素を含める必要があります。

第二に、値が欠けていることと、値が偽であることは異なります。water_resistantが不明な場合、「いいえ」にマッピングしてはいけません。nullのままにするか、情報補完の処理へ回すか、チャネルが回答を必須とする場合は公開をブロックします。

第三に、正規化された値と表示用の値には異なる役割があります。寸法は、明示的な単位を持つ一貫した数値フィールドに保存します。その後、配信先とロケールの要件に従って書式を整えます。「10 in / 25.4 cm」を管理されていない単一のテキスト値として保存してはいけません。

Productrueによるチャネル別商品データの概要は、中心的な課題を理解するうえで参考になります。配信先ごとに、同じ基礎商品情報から異なる情報を選択し、異なる形で提示する必要があります。

1つのレコードから生成できる20種類のチャネル向けアセット#

次のマトリクスは、統制された1つのレコードから20種類の出力を作成する方法を示しています。max_title_charsのような一般的な制約名は、各チャネルの公式スキーマに記載された最新の値へ置き換えてください。チャネル要件は変化するため、前提を商品データへ直接埋め込まず、規則をバージョン管理します。

#	チャネル向けアセット	主な入力	変換と拒否の規則
1	ストアフロントの商品タイトル	brand, product_name, バリエーション値	ストアフロントの命名順序を適用します。商品名が空の場合や、未承認のバリエーション接尾辞がある場合は拒否します。
2	PDPの短い説明文	product_name, approved_benefits, target_audience	主な利点と想定用途を1つずつ選択します。裏付けとなる事実がない訴求表現は拒否します。
3	PDPの特徴箇条書き	feature_facts, materials, dimensions, compatibility	有用な事実に優先順位を付け、一貫した形式に整えます。重複または矛盾する箇条書きは拒否します。
4	PDPの長い説明文	承認済みの事実、利点、ユースケース、お手入れ情報	仕様を変更せず、読みやすい説明文を作成します。未対応のHTMLや禁止された訴求表現は拒否します。
5	PDPの仕様表	寸法、重量、素材、容量、モデルデータ	ロケールに応じてラベルと単位を表示します。不正な数値や単位が欠けている値は拒否します。
6	コレクションカード	product_name, primary_image_url, regular_price, sale_price	バリエーションの違いを削除せずにタイトルを短縮します。画像または通貨が欠けている場合は拒否します。
7	サイト内検索レコード	名前、識別子、カテゴリー、同義語、バリエーション値	管理された同義語と正確な識別子をインデックス化します。無関係なキーワードの詰め込みは拒否します。
8	オーガニック検索スニペット	商品名、カテゴリー、主な利点、ブランド	設定された制限内でタイトルと説明文を生成します。商品を識別できなくなる切り詰めは拒否します。
9	マーケットプレイスの商品タイトル	ブランド、商品タイプ、主要属性、数量、バリエーション	マーケットプレイスで承認されたタイトル順序を適用します。長すぎるタイトル、語句の重複、必須属性の欠落は拒否します。
10	マーケットプレイスの箇条書き	機能、寸法、互換性、同梱物	購入判断に重要な情報を優先します。配信先で禁止されている宣伝表現は拒否します。
11	マーケットプレイスの説明文	承認済みの事実、利点、使用方法、お手入れ情報	未対応のマークアップとチャネルに適合しない書式を削除します。箇条書きと矛盾する事実は拒否します。
12	マーケットプレイスの拡張コンテンツ概要	利点、特徴の階層、メディア、比較フィールド	レコードをデザイナーまたはテンプレート用のモジュールへ変換します。利用できないアセットや根拠のない比較は拒否します。
13	マーケットプレイスの検索語句	カテゴリー用語、同義語、モデル識別子	重複を削除し、仕様で必要とされる場合は表示タイトルと重複する語句を除外します。禁止された競合他社の用語は拒否します。
14	ショッピングフィード項目	ID、タイトル、説明文、URL、画像、価格、在庫状況、識別子	値をフィードスキーマに合わせてシリアライズします。必須識別子が欠けている場合や、価格と通貨が一致しない場合は拒否します。
15	ソーシャルコマースの商品情報	商品名、バリエーションデータ、価格、在庫、メディア	商品を配信先の分類体系と許容値へマッピングします。未マッピングのカテゴリーや親を持たないバリエーションは拒否します。
16	検索広告セット	商品名、承認済みの利点、オファー、ランディングページURL	承認可能な組み合わせを複数作成します。期限切れのオファーや、ランディングページと一致しないコピーは拒否します。
17	ソーシャル広告クリエイティブ概要	オーディエンス、ユースケース、利点、画像、動画	訴求角度を選択し、必要なアセットを指定します。商品レコードで裏付けられていないオーディエンス向けの訴求は拒否します。
18	メールの商品ブロック	商品名、画像、価格、利点、URL	オファーを再利用可能なモジュールへ要約します。古いセール日付、トラッキング規則の欠落、無効なURLは拒否します。
19	SMSまたはプッシュ通知のプロモーション	短い商品名、オファー、期限、URL	設定された制限内で不可欠な情報だけを使用します。不明確な期限や在庫切れの商品は拒否します。
20	短尺動画スクリプト	ユースケース、機能に関する事実、実演手順、承認済みCTA	フック、実演、根拠、行動喚起を組み立てます。商品では実行できない実演は拒否します。

すべての商品で、20種類の出力を一度に作成する必要はありません。このマトリクスを基準にすれば、生成できるアセット、必要な入力、出力をブロックすべき理由を安定して判断できます。

重要なのは、正規フィールドからチャネルフィールドへ向かう流れです。マーケットプレイスの商品タイトルをメールの入力として使用すると、エラーや書式上の慣例が配信先間で広がります。どちらのアセットも、承認済みの正規フィールドを参照する必要があります。

事実を固定し、表示だけを変更する#

すべてのフィールドを、次の3種類のいずれかに分類します。

• 固定された事実： 識別情報、寸法、素材、梱包数量、互換性、価格、在庫状況、コンプライアンス文言。
• 管理された解釈： 1つ以上の事実上の特徴に関連付けられた、承認済みの利点。
• チャネル向けの表示： 順序、トーン、長さ、書式、キーワードの強調、行動喚起。

チャネルごとに異なる属性を強調することはできますが、異なる事実を作り出してはいけません。マーケットプレイスの商品タイトルでは、サイズと梱包数量を優先する場合があります。SNSのキャプションでは、ユースケースから始める場合があります。メールの商品ブロックでは、実施中のオファーを最初に示す場合があります。この3つはすべて、同じSKU、バリエーション、価格条件、承認済みの商品機能を参照しなければなりません。

説得力のある文章は、事実の承認後に作成します。2026年に売れる商品説明を書くための10のコツは表示方法の改善に役立ち、より良い商品説明を作成する方法は強調すべき詳細を判断する際に役立ちます。どちらの工程でも、元の事実を上書きしてはいけません。

チャネル特有の言葉にも境界が必要です。短尺動画で効果的な表現が、マーケットプレイスの商品情報や規制対象カテゴリーに適しているとは限りません。プラットフォーム固有の表現を使用する場合は、正規レコードではなく配信先別の用語集で管理します。TikTokの言葉と「nudge」の意味に関するガイドは、チャネル用語に文脈が必要な理由を示しています。

構造化された事実は、一般的な商品情報やフィード以外でも重要になります。エージェント型コマースが商品コンテンツを購入インフラへ変えている仕組みで説明されているように、商品を選択して購入するシステムには、確実に解釈できる商品コンテンツが必要です。明確な識別子、属性、オファーデータ、関係性は、洗練された文章だけよりも再利用しやすい情報です。

10段階の監査で信頼できるベースラインを作る#

マッピングを変更したり、新しいアセットを生成したりする前に、マルチチャネルコンテンツ監査を使用して現状を記録します。

1. すべての有効な配信先をエクスポートします。 ストアフロント、マーケットプレイス、フィード、広告カタログ、ソーシャルコマースチャネルから、現在の商品レコードを収集します。エクスポート日時とチャネルアカウントを記録します。

2. データ提供元システムのスナップショットを保存します。 関連するERP、PIM、サプライヤー、DAM、コマースのフィールドを記録します。source_record_id、updated_at、ロケール、市場、管理責任を含めます。

3. 各フィールドの正規データ管理元を選択します。 価格はコマースシステム、寸法はPIM、承認済みメディアはDAMから取得する場合があります。フィールドごとに1つの管理元を指定し、代替元がある場合は文書化します。

4. フィールド辞書を作成します。 各フィールドの型、スコープ、単位、許容値、nullの処理、管理責任者を定義します。親、バリエーション、オファー、ロケール、市場のフィールドを区別します。

5. 配信先ごとにチャネル仕様を作成します。 required_fields、max_title_chars、max_description_chars、allowed_values、allowed_html、image_requirements、条件付き規則を記録します。仕様には日付とバージョンを付けます。

6. 既存のフィールドをマッピングします。 すべての配信先フィールドについて、正規データの取得元と変換方法を指定します。各フィールドを、直接、変換、連結、生成、継承、未マッピングのいずれかに分類します。

7. 表示用フィールドだけを生成します。 事実の承認後、Kua.aiのマルチチャネル商品説明ジェネレーターを使用して、統制された入力からチャネル固有のタイトルと説明文を作成できます。生成したコピーは、正規の事実レイヤーではなく配信先フィールドに保存します。

8. 最初に決定論的な検証を実行します。 編集レビューの前に、型、長さ、必須値、列挙値、識別子、単位、日付、価格、バリエーションの関係、URL、アセットの利用可否を確認します。

9. 出力をベースラインと比較します。 変更された事実、欠落フィールド、カテゴリーの再マッピング、短縮されたタイトル、削除された訴求、期限切れのオファー、変更されたバリエーション値を特定します。エクスポート全体を1つのまとまりとして承認せず、リスクの高い変更を確認します。

10. ロールバック用の参照情報とともに公開します。 ソースのスナップショット、マッピングのバージョン、生成された出力、承認記録、エクスポートファイルを保存します。チャネルが商品を拒否したり誤って表示したりした場合、該当する規則を特定して以前のバージョンへ戻せるようにします。

この取り組みを支える全体的な規律が、商品コンテンツ管理です。これには、一元的なガバナンス、情報補完、ローカライズ、配信が含まれます。Shopifyの商品コンテンツ管理ガイドでは、複数のコマース配信先にわたってこの作業を整理するための背景情報を確認できます。

ベースライン監査チェックリスト#

• 有効なすべてのSKUに、安定したproduct_id、sku、必要に応じた親との関係がある。
• 必須識別子が存在するか、文書化された例外がある。
• 親フィールドとバリエーションフィールドが分離されている。
• 数値に明示的な単位がある。
• カテゴリーが管理されたチャネル分類体系を通じてマッピングされている。
• 承認済みの利点が、それを裏付ける事実に関連付けられている。
• コンプライアンス文言が保持されている。
• 価格に通貨と市場の情報が含まれている。
• セール期間が有効で、期限切れではない。
• メイン画像へアクセスでき、正しいバリエーションに属している。
• ローカライズされたコンテンツに、ロケールと承認状況が記録されている。
• すべてのチャネル仕様に、管理責任者とバージョン日がある。
• 生成されたすべてのアセットを正規入力まで追跡できる。

検証ゲートで誤ったマッピングの公開を防ぐ#

検証では、一般的な「フィードに失敗しました」というメッセージではなく、具体的なコードを返す必要があります。有用な拒否理由には次のものがあります。

拒否コード	条件	修正担当者
MISSING_REQUIRED	条件付きまたは常に必須となる配信先フィールドが空である	カタログ管理者
INVALID_ENUM	値がチャネルの許容リストに含まれていない	分類体系またはチャネルの管理者
OVER_MAX_LENGTH	表示されたコンテンツが設定済みのチャネル上限を超えている	コンテンツ運用担当者
ORPHAN_VARIANT	SKUが、存在しないまたは無効な親を参照している	カタログ管理者
UNIT_MISSING	数値測定値に単位がない	商品データ管理者
IDENTIFIER_INVALID	識別子が設定された形式またはチェックに適合しない	カタログ管理者またはサプライヤー
PRICE_RELATION_INVALID	セール価格、通常価格、通貨、市場の値が矛盾している	コマース管理者
SALE_WINDOW_INVALID	終了日時が開始日時より前であるか、オファーの期限が切れている	コマース管理者
ASSET_UNAVAILABLE	必須画像または配信先URLを取得できない	メディアまたはウェブ管理者
CLAIM_UNSUPPORTED	生成されたコピーに未承認の訴求表現が含まれている	コンテンツ承認者
LOCALE_MISMATCH	コンテンツの言語が配信先ロケールと一致しない	ローカライズ管理者
SCHEMA_VERSION_STALE	エクスポートで古いチャネル仕様が使用されている	連携管理者

エラーと警告を分けます。必須識別子がない場合は、公開をブロックする必要があります。説明文が社内で推奨する文字数より短いだけなら、警告で済む場合があります。この違いを文書化し、作業待ちが多いことを理由に実際のエラーを無視しないようにします。

編集レビューでは、自動化だけでは確実に判断できない問題に焦点を当てます。具体的には、明瞭さ、誤解を招く強調、意味の重複、トーン、利点が商品情報の事実を正当に表しているかどうかです。レビュー担当者が、表示されたアセットの横でソースフィールドを確認できるようにします。

すべての出力を追跡できればベースラインは完成する#

有用なベースラインでは、公開された任意の値について次の5つの質問に答えられます。

1. どのソースシステムから提供されたか。
2. どの正規フィールドに保存されたか。
3. どの変換処理によって変更されたか。
4. どのチャネル規則によって検証されたか。
5. 最終出力を誰が承認したか。

いずれかの回答が、記憶、スプレッドシートのコメント、最後にフィードをアップロードした担当者の特定に依存する場合、そのマッピングはまだ運用上完成していません。

まず、代表的な1つの商品ファミリーについてフィールドマトリクスを作成します。単一商品、複数バリエーション商品、セール対象商品、ローカライズされたレコード、コンプライアンス文言を含む商品を対象にします。これらのケースが検証を通過したら、同じ統制パターンをカタログ全体へ展開します。

フィールド辞書とチャネル仕様を整備した後、Kua.aiを使用して、承認済みの商品情報の事実を配信先向けアセットへ変換します。監査済みの1レコードから始め、20種類すべての出力を検証し、生成された各フィールドとそのソースとのつながりを維持してください。

よくある質問#

チャネル横断の商品データフィールドマッピングとは何ですか？#

商品データフィールドマッピングとは、ソース値、正規商品フィールド、配信先チャネルフィールドのつながりを文書化することです。また、その過程で適用される変換、条件、検証規則、nullの処理も定義します。

たとえば、ERPの商品番号を正規のskuへ直接マッピングし、さらにマーケットプレイスの販売者SKUフィールドへマッピングできます。正規化された素材の値をチャネル属性へ入力する前に、管理された参照処理が必要になる場合もあります。どちらの経路も、マッピング上で確認できるようにします。

すべてのチャネルで同じ商品説明を使用するべきですか？#

同じ承認済みの事実を再利用する必要はありますが、すべてのチャネルで同一の表示を強制する必要はありません。配信先ごとに、フィールド構造、ユーザーの意図、書式、検索行動、コンテンツ規則が異なります。

各説明文は、同じ商品名、特徴、寸法、互換性、利点、コンプライアンスフィールドから生成します。チャネル仕様に従って、順序、長さ、トーン、書式を変更します。調整の過程で新しい仕様や訴求表現を追加してはいけません。

親フィールドとバリエーションフィールドはどのようにマッピングしますか？#

共通情報は親レベルに、販売可能な差異はバリエーションレベルに保存します。ブランド、商品ファミリー、一般的な説明文は親に属する場合があります。SKU、色、サイズ、バーコード、価格、在庫、バリエーション画像は、多くの場合、販売可能なバリエーションに属します。

継承方法を明示的に定義します。許可されている場合、バリエーションは親の説明文を継承できますが、別のバリエーションの色、識別子、画像、オファーデータを継承してはいけません。親との関係を解決できないバリエーションはすべてブロックします。

必須のチャネルフィールドが欠けている場合はどうしますか？#

事実に該当する値を推測または生成してはいけません。MISSING_REQUIREDを返し、該当する正規フィールドとその管理責任者を特定し、配信先がその値を要求する場合は商品をブロックします。

フィールドが任意の場合は、文書化されたnullの処理に従います。フィールドを省略するか、承認済みの親の値を継承するか、スキーマが明示的に要求する場合に限り空値を送信します。一時的な回避策が恒久的なマッピングにならないよう、例外を記録します。

チャネルマッピングはどのくらいの頻度で見直すべきですか？#

チャネルがスキーマ、分類体系、許容値、コンテンツポリシー、フィード応答を変更するたびにマッピングを見直します。商品タイプ、市場、ロケール、バリエーションモデル、ソースシステムを追加した場合にも見直す必要があります。

通常の管理では、大規模な季節更新の前に、現在のエクスポートと保存済みのベースラインを比較します。特に、セール期間、在庫状況、カテゴリーマッピング、画像URL、コンプライアンスフィールド、生成された訴求表現を確認してください。

AIですべてのフィールドを自動的にマッピングして作成できますか？#

AIは、ソースフィールドの分類、マッピング候補の提示、タイトル、箇条書き、説明文、広告、スクリプトなどの表示用フィールドの作成に役立ちます。一方で、識別子、価格、単位、日付、列挙値、バリエーションの関係、コンプライアンス文言は、引き続き決定論的な規則で管理する必要があります。

曖昧なマッピングやリスクの高い訴求表現には、人による承認を必須とします。最も安全なワークフローは、統制されたソースデータ、バージョン管理されたチャネル仕様、自動検証、重点的な編集レビューを組み合わせたものです。