既存の商品説明文を、AIで一括リライトする手順

商品説明文の一括リライトは、1件ずつ書かせる作業ではなく「型」を作って回す設計の話だ。事故るのは文章の質ではなく、SKUごとの型番・仕様・価格が混線する点。生成前にマスタの値を差し込み変数で渡し、生成後に機械で突き合わせる。防ぐ設計の中心はこの2つになる。

一括リライトは「文章生成」ではなく、型＋差し込み変数＋検証というパイプラインの設計である
危ないのは文体ではなく、他SKUの型番・仕様・価格が本文に紛れ込む「混線」である
最初から全SKUに展開しない。1商品→10商品→カテゴリ単位の順で型を固める

「一括で書き直して」が事故るのは、量産時にSKUの情報が混線するから
前提の確認：商品マスタは「型番・仕様・価格の正本」になっているか
プロンプトを「型」にする：共通ルールとSKUごとの差し込み変数を分ける
実務手順：抽出→生成→検証→反映の4ステップ
検品を機械に寄せる：突合・文字数・NG表現のチェック設計
展開の順序：1商品→10商品→カテゴリ単位と、途中で出る失敗の兆候
「型を作って回せる」経験は、社外でどう評価されるか
よくある質問

「一括で書き直して」が事故るのは、量産時にSKUの情報が混線するから

「うちの商品、300点ぜんぶ説明文を書き直しておいて」。理由は毎回違う。ブランドのリニューアル、型番の改定、モール側の表記ルールの変更、前任者が書いた文体のばらつき。それでも依頼の形はいつも同じで、期限だけが先に決まっている。

担当者はまず商品管理の一覧を開く。表示件数を100件に切り替えて、下までスクロールする。3ページある。1件3分で書けたとしても15時間だ。他の業務を止めずにこの時間を捻出するのは難しい。だから生成AIに投げる、という判断そのものは正しい。

問題はその次だ。多くの場合、最初にやるのはチャット画面を開いて商品名を貼り、「これのEC用の説明文を書いて」と打つことである。返ってくる文章は読みやすい。1件目は感心する。10件目あたりから、同じ言い回しが並びはじめる。そして100件目を過ぎたころ、誰も気づかないまま、別の商品の仕様が混ざった説明文がCSVに入る。

一括リライトで起きる事故は、大きく3つに分けられる。

混線：直前に処理した別SKUの型番・容量・対応機種が、次のSKUの本文に紛れ込む
追加：与えていない機能や素材をAIが補って書く。「防水」「食洗機対応」のような、それらしいが商品マスタに存在しない属性が生える
量産：全SKUが同じ骨格・同じ形容詞になり、カテゴリページに並べたときに商品同士の違いが消える

このうち、目視で気づけるのは3番目だけだ。文体の単調さは読めば分かる。だが型番「XT-3200」が「XT-3020」になっていることは、300行のCSVを目で追っても手が止まらない。文章としてはまったく自然だからである。

文章はうまい。中身が別の商品だ。

この種の誤りは、公開した直後には表面化しない。表面化するのは、届いた商品を開けた購入者が「注文したものと型番が違う」と問い合わせてきたときだ。一次対応するのはCSの同僚で、原因を辿ると商品ページの記載に行き着く。書き直しを指示した上長ではなく、CSVをアップロードした担当者の名前がそこに残っている。

別の記事で、商品ページの制作をAIに任せてよい工程と人が確定すべき工程に分ける、という整理を書いた。そこでは「商品説明文の本文（初稿）」をAIに任せてよい側に分類している。本記事はその続きにあたる。任せてよいと分類したはずの工程が、なぜ数百件まとめて回した瞬間に事故るのか。原因は文章生成の精度ではなく、量産のしかたを設計していないことにある。

1件ずつチャットに投げる方式は、数十件までなら成立する。100件を超えると、投げた順番によって出力が変わり、どの商品にどの指示を出したかを人間が覚えていられなくなる。再現できない作業は検証もできない。だから焦点は「うまく書かせる」ではなく「混ぜない」「同じ条件で回す」に移る。ここから先は文章術ではなく、工程設計の話になる。

前提の確認：商品マスタは「型番・仕様・価格の正本」になっているか

生成に着手する前に確認することが1つだけある。書き直しの材料になる値が、どこか1か所に、列として存在しているかだ。ここが崩れていると、後工程で何を組んでも検証ができない。

手順としては、まず現行データを書き出す。楽天RMSなら商品管理からCSVをダウンロードする形になるが、CSVでの一括編集は最初から有効になっているとは限らず、機能の申込設定が必要になるケースがある。Shopifyは管理画面の商品管理からエクスポート、カラーミーショップは「商品の一括管理」、BASEはCSV商品管理のAppを入れて書き出す。画面名と操作手順は改称・UI変更が入ることがあるため、着手前に各社のヘルプセンターで現行の名称を確認してから進めたい。「一括編集」という一般名称だけで社内やベンダーと話すと、どの画面の話をしているのかが噛み合わなくなる。

書き出したCSVを開く。型番の列を探す。列が無い。型番は商品名の末尾に括弧書きで入っている——この状態は珍しくない。容量やサイズも同じで、独立した列ではなく説明文の本文中にしか書かれていないことがある。

ここで一度、手を止めたほうがいい。型番も仕様も現行の説明文の中にしか無いということは、「書き直す対象」と「書き直すときに参照する正しい値」が同じ場所にあるということだ。この状態でAIに「今の説明文を読んで、もっと良い文章に直して」と頼むと、古い仕様がそのまま新しい文章へ引き継がれる。前任者が3年前に書いた「対応OS」の記述が、そっくり新品の顔をして再登場する。

そのため、生成の前に商品マスタ側を整える。整えるといっても、全項目を完璧にする必要はない。生成で使う値だけでいい。実務上、最低限そろえたいのは次の5つである。

商品管理番号（商品URL／ハンドル）：更新対象を特定するキー。これが無いと反映ができない
正式な商品名：販促文言（「送料無料」「大人気」など）を混ぜていない、商品そのものの名称
型番・品番：独立した列にする。商品名から切り出す
仕様：サイズ、容量、素材、対応機種など。項目ごとに列を分ける。1セルに全部詰めない
訴求ポイント：その商品を選ぶ理由を、事実ベースで1〜3個。ここだけは人が書く

この整備は面倒に見えるが、実は一括リライトそのものより資産価値が高い。列として構造化された商品マスタは、説明文の生成だけでなく、広告文、商品フィード、比較表、モール横断の在庫管理にも使い回せるからだ。逆にここを飛ばすと、次に別のモールへ展開するときにまた同じ作業をやることになる。

境界事例が1つある。バリエーション（親子）商品だ。色違い・サイズ違いを1つの商品ページにまとめている場合、説明文は親側に1本しか無い。しかし仕様（サイズ・重量・対応機種）は子ごとに違う。ここを整理しないまま生成に入ると、親の説明文に特定の子の仕様だけが書かれる、という中途半端な状態になる。

したがって着手前に「SKU単位で回すのか、商品（親）単位で回すのか」を決めておく。親単位で回すなら、子の仕様は一覧表として本文に入れる前提で列を用意する。SKU単位で回すなら、そもそも説明文をSKUごとに持てるカートなのかを先に確認する。この判断を後回しにすると、生成が終わってから全件やり直しになる。

プロンプトを「型」にする：共通ルールとSKUごとの差し込み変数を分ける

ここが一括リライトの背骨にあたる。やることは単純で、全SKUで変わらない部分と、SKUごとに変わる部分を、物理的に別の場所へ置く。前者を共通ルール、後者を差し込み変数と呼ぶ。

スプレッドシート上では、共通ルールを1つのセル（あるいは別シート）に1回だけ書く。SKUの値は行ごとに列で持つ。生成のたびに両者を結合して1本のプロンプトを組み立てる。この形にすると、文体を直したいときに触るのは共通ルールの1セルだけになる。300行のプロンプトを300回直す必要がなくなる。

共通ルールに書く内容は、おおむね3ブロックに分かれる。

制約：与えた値の範囲だけで書くこと。書かれていない機能・素材・効果を補わないこと。情報が足りない項目は、推測せず空欄として出すこと
出力仕様：構成（導入／特長／仕様／使用シーンなど）、各ブロックの目安文字数、使ってよいHTMLタグ、使わない表現、口調
出力形式：見出しとキャッチと本文を分けて返させる。1つの塊で返させない

差し込み変数のほうは、商品名、型番、カテゴリ、仕様の各項目、訴求ポイント、想定利用シーンあたりを列として持ち、プロンプトの中に決まった位置で埋め込む。ここで実務上いちばん効くのは、次の一点だ。

型番はAIに書かせない。文の外側で結合する。

つまり、生成させるのは本文の散文部分だけにして、型番・容量・対応機種のような「1文字違うと事故になる値」は、生成結果の外側でテンプレートとして連結する。「型番：{{型番}}」という行を、生成後に機械的に付け足す。こうすると、混線という事故そのものが構造的に発生しなくなる。プロンプトで「型番を正確に書いてください」と念を押す対策は、確率を下げるだけで、ゼロにはできない。生成物に含めないという設計だけが確実に効く。

散文の中でどうしても型番に言及したい場合は、生成結果の中に型番文字列が現れたときに突合チェックへ回す（後述）。「言及させない」か「必ず検証する」かの二択で、どちらでもない状態を作らないことが大事だ。

禁止表現の扱いにも注意点がある。共通ルールの文中に直接ずらずら書くと、追加・削除のたびにプロンプト本体を編集することになり、誰がいつ何を足したのかが追えなくなる。禁止語は別シートにリストとして持ち、プロンプト組み立て時に読み込む形にする。運用の途中で「この言い回しはモールの表記ルールに引っかかった」と分かったとき、リストに1行足せば以降の全生成に効く。

もう1つ、地味だが取り返しがつかない設計がある。入力列と出力列を絶対に同じセルにしないことだ。元の説明文が入っているセルに生成結果を上書きすると、比較する相手が消える。何が変わったのかを説明できなくなり、差し戻しもできない。列は「現行説明文」「生成プロンプト」「生成結果」「検品ステータス」「承認フラグ」と分けて持つ。生成プロンプトを列として保存しておくのは、後から「なぜこの文章になったか」を辿るためで、これが無いと事故の原因調査が推測になる。

実務手順：抽出→生成→検証→反映の4ステップ

ここまでの設計を、実際の作業順に並べ直す。4ステップに分ける。

1. 抽出。 各カートの管理画面からCSVを書き出し、スプレッドシートへ取り込む。ここで最初にやるのは、書き出した生CSVを日付つきで別名保存することだ。「20260828_normal-item_元データ」のような名前で1枚残す。反映の失敗から戻れる唯一の経路がこのファイルになる。作業シートはコピーのほうを使う。

2. 生成。 行ごとに共通ルールと差し込み変数を結合し、APIを呼んで結果を出力列へ書き戻す。GASなどから回す場合、いくつか決めておくことがある。まず、書き戻しは行番号ではなく商品管理番号をキーにする。並列で投げたり途中で失敗して再実行したりすると、行の順序は簡単にずれる。キーで書き戻す設計なら、順序が崩れても正しい行に戻る。次に、1回のバッチ件数を決める。数十件単位で区切り、途中で止まっても「どこまで終わったか」がステータス列で分かるようにする。全件を一度に投げると、途中でエラーが出たときにどこから再開すればいいのか分からなくなる。

3. 検証。 機械チェックを先に通し、その後に人が読む。順番が逆だと、人が読む対象に明らかな不良品が混ざる。機械チェックの中身は次のh2で扱う。人の確認では、全件を読むのではなく、機械チェックで引っかかった行と、カテゴリごとのサンプルを読む。読んだ人が承認フラグ列にチェックを入れる。ここで運用として決めておくのは、生成を回した人と承認する人を分けることだ。自分が回した結果は、無意識に「たぶん大丈夫」の方向で読む。1〜2名体制で分担が難しい場合でも、生成した日と確認する日をずらすだけで見え方が変わる。

4. 反映。 承認フラグが立っている行だけを書き出す。フィルタで未承認行を除外してからCSVを出力する。ここを面倒がって全行アップロードすると、確認していない文章が公開される。

アップロード時の注意はカートごとに違う。Shopifyのインポートでは、既存商品を更新するつもりで一致するハンドルの上書き設定を選ばないと、同じ商品が新規として重複登録される。楽天RMSは商品管理番号（商品URL）を見て更新対象を判定するため、この列が1文字でも違うと別商品扱いになる。また、更新したい列だけを含んだCSVを作るか、全列を含んだCSVを上げるかで影響範囲が変わる。全列を上げるということは、説明文以外の列も現在のシートの値で上書きするという意味だ。作業中に価格列を触っていたら、それも一緒に反映される。

アップロードは戻せない。戻せるのは、前のCSVを取ってあるときだけだ。

ステップごとに「誰がやるか」を決めておくと、体制が小さくても回る。型（共通ルール）を決めるのは1人でよく、むしろ1人であるべきだ。複数人が思いつきで共通ルールを触ると、どのバージョンで生成された文章なのかが分からなくなる。生成の実行は誰でもよい。承認だけは、その商品カテゴリの仕様を説明できる人がやる。この3つの役割が同一人物になる場合は、せめて工程の間に時間を空ける。

検品を機械に寄せる：突合・文字数・NG表現のチェック設計

300件の生成結果を人が全部読むのは現実的ではない。件数が増えるほど、人の集中力はもたなくなる。だから検品は、機械が判定できるものと人にしか判定できないものに分け、前者を全件に、後者を絞り込んだ行に当てる。

機械側に寄せられるチェックは、主に5つある。

必須要素の包含：そのSKUの型番・容量・対応機種など、本文に必ず入るべき値が含まれているか
他SKU値の混入：全商品の型番リストを用意し、自分以外の型番が本文に現れていないかを照合する。混線を捕まえるのはこの検査だ
数値の裏取り：本文中の数字を抜き出し、マスタの仕様列に存在しない数字が出ていないかを見る。「約2年」「最大8時間」のような、それらしい数値が生えていないかの確認になる
文字数：上限と下限。カート側には説明文欄の入力上限があるため、超えると反映時に落ちるか途中で切れる
禁止語：別シートの禁止語リストと突き合わせ、該当した行にフラグを立てる

実装はスプレッドシートの関数でも足りる。型番リストとの照合は、本文セルに対して各型番の出現を数え、自分の型番以外のヒット数が1以上なら要確認、という形で組める。凝ったスクリプトを書く必要はない。重要なのは検査の内容ではなく、検査結果が1行1判定の列として残ることだ。後から「何件が引っかかり、何件を直したか」を数えられる状態にしておくと、型の改善に使える。

チェック列は、シートのいちばん右にまとめて並べる。全部緑になっている行は飛ばし、赤が付いた行だけをフィルタで抜き出して上から開く。300件のうち赤が20件なら、人が読むのは20件と、カテゴリごとの抜き取りサンプルだけになる。この形にして初めて、一括リライトは片手間の業務時間に収まる。

もう1つ、量産特有の検査を足しておきたい。重複度だ。生成結果の先頭50字だけを抜き出した列を作り、その値が何件重複しているかを数える。同じ書き出しが20件並んでいれば、それは差し込み変数の情報量が足りていないサインである。文章の問題ではなく、入力の問題だ。

ここで線を引いておく。機械が見つけられるのは、答えを持っている項目だけだ。型番が違うことは、正しい型番を持っているから判定できる。だが「この表現がこの商品カテゴリで使ってよいものか」は、比較対象を持っていないので機械には判定できない。モールごとに商品ページの表記ルールは異なるため、生成物をそのまま公開する前提で組まず、社内で既に運用している表現ルールの確認フローに必ず乗せること。表現の適否そのものの判断は、この記事の範囲を超える。

そして最後の関門は人のままにしておく。承認フラグの列は自動で埋めない。ここを自動化した瞬間、パイプラインの中に誰も見ていない経路ができる。

展開の順序：1商品→10商品→カテゴリ単位と、途中で出る失敗の兆候

型ができたら全件に流したくなる。だが最初に回す件数は1件でいい。順序は、1商品→10商品→カテゴリ単位→全件と広げる。各段階で見ているものが違うからだ。

1商品の段階で見るのは、型が意図どおりに動くかではなく、同じ入力から同じ品質が出るかである。同じ1商品で3回生成し、3本を並べる。構成がばらつく、文字数が大きく揺れる、指定していない項目が回によって生えたり生えなかったりする——このどれかが起きているなら、共通ルールの指定が緩い。ここで直しておくと、後の300件が全部楽になる。

10商品の段階で初めて量産特有の問題が見える。同一カテゴリから10件選んで回し、生成結果の先頭50字だけを縦に読む。全部が「〜な毎日に、ちょっとした変化を。」で始まっていたら、その型は300件に流してはいけない。この段階で混線も初めて観測できる。1件ずつ生成していた頃には存在しなかった事故が、ここから出はじめる。

カテゴリ単位の段階では、50〜100件を回して機械チェックの引っかかり率を見る。ここで見るのは文章ではなく数字だ。要確認件数の割合が、事前に決めた許容線を超えているかどうかを見る。そしてこの段階から先へ進むかどうかの判断基準を、着手前に決めておく。「要確認が3割を超えたら型に戻る」といった線を先に引いておかないと、目の前の要確認件数を手で直して先へ進んでしまう。手で直せてしまうことが、いちばん危ない。型の欠陥が、担当者の残業として吸収されて見えなくなるからだ。

途中で出る失敗の兆候は、おおむね次の3つに整理できる。

修正量が件数に比例して減らない：型ではなく個別対応で回している。件数を増やすほど工数が線形に増える
承認フラグが溜まる：読む人がボトルネックになっている。生成本文が長すぎる可能性が高い。出力を短くするか、読む単位をカテゴリで区切る
生成結果がどれも似る：差し込み変数の情報量が足りない。訴求ポイント列が空欄のまま回していないか確認する

段階展開には、事故防止とは別の効能もある。効果を測る余地が残ることだ。全SKUを一度に書き換えると、その後に数字が動いても、原因が説明文なのか、季節なのか、同時期のクーポンなのかを分けられない。カテゴリ単位で順に入れ替えていけば、まだ書き換えていないカテゴリが比較対象として残る。もっとも、ECの数字は施策以外の要因で簡単に動くので、これは厳密な実験ではない。公開前後で何がどう動いたかを、書き換えた日付と一緒に記録しておくくらいの精度で十分だ。記録が無いと、次の書き直しのときにまた同じ議論を最初からやることになる。

「型を作って回せる」経験は、社外でどう評価されるか

ここまでの工程を振り返ると、AIが担当したのは散文を書く部分だけである。人がやったのは、商品マスタを正本にすること、型番を生成物から外すと決めたこと、承認者を分けたこと、展開の順序と撤退ラインを引いたこと。どれもプロンプトの巧拙とは関係がない。業務を工程に分解して、事故が起きる箇所を先に潰すという判断である。

やっかいなのは、この経験が言語化しにくいことだ。転職サイトの職務経歴の欄を開いて、1行書いて、消す。「生成AIを使って商品説明文を作成」と書いてしまうと、誰がやっても同じ、ツールを触っただけの作業に見える。実際にやったのは、300SKUを事故なく通すための工程設計なのに、書けた文字はツール名だけになる。

ここには純粋な疑問がある。自分がやっているこの種の仕事は、社内の評価とは別に、社外の市場でどう値付けされるのか。型を作って量産を回せるEC担当者の経験が、社外の市場でどう評価されるかという論点は、この記事の範囲を超えるので別の記事に分けてある。書き方の話ではなく、経験の棚卸しの話として読んでほしい。

ひとつだけ、今日からできることを挙げるとすれば、作業のログを残しておくことだ。対象件数、要確認として弾かれた件数、型を何回作り直したか、反映後に見つかった誤りの件数。作業中はただの管理列だが、これは後から自分の仕事を説明する唯一の材料になる。数字の無い経験は、どんなに難しい仕事でも「AIで効率化しました」の一行に丸められてしまう。

よくある質問

チャット画面だけで一括リライトはできるか

数十件までなら成立する。ただし、どの商品にどの指示を出したかが記録に残らないため、後から検証も再実行もできない。100件を超えるなら、表計算シートに入力列と出力列を持ち、生成プロンプトを保存する形へ切り替えたほうがいい。件数の問題というより、検証可能性の問題である。

型番や仕様をAIに書かせないなら、AIは何を書いているのか

導入文、使用シーンの描写、特長の言い換え、構成の整理といった散文の部分だ。事実として確定している値（型番・容量・素材・対応機種）は商品マスタが持っており、生成結果の外側で結合する。役割を分けると「AIが間違えた」という事故の余地がそもそも小さくなる。

何件からこの仕組みを組む価値があるか

一律の分岐点は出せない。判断材料は3つある。件数、更新の頻度、商品マスタの整備状況だ。1回きりの50件で、マスタも整っていないなら、手で書いたほうが早いことが多い。逆に、年に何度も表記ルールが変わる、モールを複数持っている、今後もSKUが増えるという条件が揃うなら、件数が少ないうちに組んだほうが安い。組む対象は説明文ではなく商品マスタなので、他の用途にも効く。

既存の説明文をAIに読ませてリライトさせるのは駄目なのか

駄目ではないが、参照元をどちらにするかを先に決める必要がある。既存の説明文を参照元にすると、そこに含まれる古い仕様や誤記をそのまま引き継ぐ。マスタ側が正本として整っているなら、既存の説明文は「トーンの参考」として渡し、事実はマスタから渡す、という分け方ができる。両方を無条件に渡すと、どちらを優先したのかが出力から判別できなくなる。