AIで商品説明文を作る方法｜EC向けの下書き手順

AIでECの商品説明文を作るときは、文章を生成する前に商品情報の正本と、表示してよい表現を確定します。素材、サイズ、対象者、機能、注意事項、価格、在庫が曖昧なまま「魅力的に」と指示すると、存在しない性能や保証を補うおそれがあります。AIの役割は承認済みの商品Factを読みやすい文へ整えることです。仕様を決めたり、根拠のない訴求を作ったりする役割にはしません。

生成前に商品Factを一行ずつ確認する

商品DB、承認済み仕様書、仕入先資料など、社内で正本として指定した資料から情報を集めます。資料の版、更新日、商品SKUを記録し、別SKUの仕様が混ざらないようにします。説明文の必須項目は商品カテゴリで違います。食品、化粧品、家電など、法定表示や安全上の注意が関係する商品では、一般的なテンプレートだけで項目を決めず、担当部署の現行ルールを確認します。

表は横にスクロールできます

商品情報	入力例	確認すること
商品名・型番	正式名称、SKU	表示名と商品ページが一致するか
素材・寸法	仕様書記載値	単位、許容差、対象モデル
機能	承認済み仕様	実測・認証・条件が必要なclaimか
対象・用途	想定用途	使えない条件や年齢制限
使い方	説明書の手順	注意、保管、組み立て
価格・在庫	EC商品DB	更新の時刻、販売地域
表示上の注意	法務・品質の承認文	必須表現、禁止表現、根拠資料

入力できない情報は空欄のままにします。AIに空欄を埋めさせると、一般的にありそうな仕様を商品固有の事実のように作る可能性があります。寸法が未確認なら「サイズは要確認」として止め、近い型番の数値を流用しません。

タイトルと説明文は役割を分ける

商品タイトルは一覧の中で商品を識別し、説明文は購入判断に必要な特徴と条件を伝えます。同じ語を繰り返して検索語を詰め込むのではなく、商品名、型番、主要な差、用途などから読者が確認したい順に整理します。Google Merchant Centerのtitleとdescriptionも別属性として定義され、生成AIで作ったテキストを商品データへ使う場合は専用のstructured_title / structured_descriptionとdigital_source_typeを指定する仕様があります。feedへ送るときは現行仕様を確認します。

先に読み手と掲載場所を決める

同じ商品でも、検索結果一覧、商品詳細ページ、広告feedでは表示できる長さや役割が違います。掲載場所と文字数の制約を先に確認し、共通の商品Factから用途に合わせて文章を作ります。短い一覧タイトルへ注意事項を詰め込みすぎず、説明文で補うなど、情報の置き場所を分けます。ただし表示制約を理由に重要条件を隠してはいけません。

AIへ渡すbriefには、商品名、読者、掲載場所、必須Fact、文体、長さ、注意事項、出力形式を明記します。競合商品の説明や一般的な業界常識を商品Factの代わりに渡しません。商品データを使い回す場合は、生成後の文が元データと一致するかSKU単位で照合できる形にします。

説明文を作るprompt例

「以下の承認済み商品情報だけを使い、商品詳細ページ用の説明文を作成してください。対象読者は【読者】、長さは【範囲】です。機能、素材、サイズ、対象、注意事項は入力値を変えずに残してください。入力にない性能、効果、比較優位、保証、認証は追加しないでください。情報が足りない場合は文章を補完せず、確認が必要な項目を列挙してください。最後に、出力文と入力Factを対応表にしてください。」

promptは出力の正確性を保証しません。生成文と対応表を別担当者が確認し、AIが入力の意味を変えたり、条件を落としたりしていないか照合します。

固有情報を残す

商品名だけ入れ替えた同一文章を大量に作ると、商品ごとの違いが伝わらなくなります。素材の違いが用途や手入れに関係する、容量が適した利用場面を分ける、付属品が設置手順に影響するなど、商品固有Factから説明の違いを作ります。違いを説明できない場合、無理に別々の訴求文を作るのではなく、共通説明と個別の仕様欄を分ける方法もあります。

誤認につながりやすいのは、比較表現、効果の断定、最上級、数量限定、保証や安全性の主張です。消費者庁は、実際より著しく優良に見せたり、競合より優れていると事実に反して示したりする表示を優良誤認表示として説明しています。AIが「最高」「必ず」「業界No.1」などを追加したら、根拠が確認できない表現は削除し、表示の承認者に確認します。意図せず誤った表示になった場合も問題になり得るため、生成後レビューを省きません。

下書きの例を事実と表現に分ける

以下は方法を説明するための架空の入力例です。実在の商品仕様を表すものではありません。

• 承認Fact：収納ケース、外寸30×20×10cm、ポリプロピレン、ふた付き

• 未確認：耐荷重、防水性、食品利用可否

• 許可する訴求：サイズと素材、ふたが付属すること

• 禁止する訴求：重ねても壊れない、防水、食品を安全に保管できる

出力が「頑丈で水にも強く、食品保存にも最適」となった場合、文章が滑らかでも採用しません。入力にない耐久性・防水・適合性を増やしているからです。安全な文章は「ポリプロピレン製で、ふたが付属します。外寸は30×20×10cmです」のように、確認できた事実に限定します。読者にとって具体性が足りない場合は、AIに強い表現を作らせるのでなく、正本から利用場面や耐荷重などの情報を追加確認します。

生成後は差分でQAする

完成した説明文は商品ページ、商品画像、価格、在庫、送料、注意事項、返品条件と照合します。担当者が商品Factとの一致、読みやすさ、誇張、掲載制約を確認し、承認者が公開可否を決めます。記録には、SKU、元データの版、生成prompt、生成日、修正者、最終承認者、確認したsourceを残します。

表は横にスクロールできます

QA項目	不合格の例	対応
SKU一致	別サイズの商品情報が混ざる	正本を選び直し再生成
仕様一致	素材や寸法が欠ける・変化する	説明文を直してFact再照合
Claimの根拠	効果・耐久・安全を断定する	根拠を確認、なければ削除
掲載場所	一覧欄に長すぎる文を入れる	役割ごとに分割
在庫・価格	古い情報を記載	動的領域から表示するか更新
feed仕様	AI生成ラベルを落とす	Merchant Centerの現行属性を確認

商品数が多い場合は小さく試す

最初に全商品へ展開せず、形状や入力情報が異なる少数のSKUを選びます。仕様の充足度、生成文の修正数、必須表示の漏れ、担当者の確認時間を記録します。試験対象が少ない間は、全カタログで品質が上がったと結論づけません。

停止条件は、AIが入力にない機能を繰り返し補う、SKUを取り違える、法定・社内必須表示を落とす、元データの版が追えない、レビュー担当者が割り当てられていない場合です。原因がデータの不足なら商品DBを整え、promptだけで抑え込まないようにします。自動公開は、試行結果、返品や問い合わせなどの運用影響、承認フローを確認してから別途判断します。

Merchant Centerへ送る場合

Googleの公式仕様では、生成AIで作成した商品titleにはstructured_title、descriptionにはstructured_descriptionを使い、digital_source_typeへtrained_algorithmic_mediaを指定する要件が説明されています。画像用の生成AIメタデータとテキスト属性は別の扱いです。実際にfeedを作成する際は、商品データ仕様の現行ページ、対象feed形式、属性の必須条件を見直し、単に商品ページのHTMLへラベルを足せばよいと考えないでください。

商品説明文の品質は、読みやすさだけでなく、購入者の期待と実物が一致することです。商品情報を正本として管理し、AIが変えてよいのは表現だけと決めると、修正者は文章の整え方に集中できます。入力Factが足りない、根拠資料がない、例外を説明できない場合は、文章を生成せず商品情報の確認へ戻してください。

変更後の文章を商品台帳へ戻さない

AIが読みやすく整えた表現を、そのまま商品Factの正本へ書き戻さないでください。文章中の表現変更と、仕様そのものの変更が混ざると、次の生成に誤情報が再利用されます。新しい性能情報や寸法が必要だと分かった場合は、商品担当者が根拠資料を確認し、正本を更新した後で改めて生成します。修正者が出力文だけを直接直した場合も、修正箇所が事実変更なのか文体調整なのかを記録すると、次回のレビューで再発を防げます。

掲載後に問い合わせや返品理由が増えた場合は、すぐにAIの生成品質と決めつけず、商品ページ、画像、配送条件、実物仕様のどこに差があるか調べます。誤認表示の疑いがあるときは、公開文を一時停止し、根拠資料と承認履歴を担当部署で確認します。出力品質の改善だけでなく、商品情報と公開内容の更新手順も見直してください。地域、商品カテゴリ、掲載先で表示ルールが変わる場合は、共通の説明文だけで対応しきれない点を明確にし、対象地域ごとの承認文と担当者を決めてください。

商品仕様の確認担当と文章の承認担当が別の場合は、確認を依頼する時点でSKUと資料版を共有します。更新が必要なFactを文章担当だけで判断せず、正本管理者へ戻す経路を決めておきます。

AIものさしの判断

AIは「商品factを読みやすい文章へ変換する」工程に使うと安定します。

逆に、fact自体をAIへ考えさせる使い方は避けるべきです。

商品DBをsource of truthにし、AIは表現を整える役割に限定すると運用しやすくなります。