アパレルECのコーデ提案文とレビュー分析をClaude Codeで時短する実務手順
アパレルECのささげ業務担当向け。コーディネート提案文の量産とレビュー分析を、コピペ可能なプロンプトと検証スクリプトで時短する手順をまとめました。
金曜の夕方、新作50型ぶんの商品ページを月曜公開にしたい、と言われた日のことです。
写真は撮り終わっている。採寸も済んでいる。でも、1型ごとに「着回しの提案文」を3パターン書いて、過去のレビューから売れ筋の訴求も拾って入れてくれ、と。50型 × 3パターンで150本。さらにサイズ感や生地の不満を読み取って商品説明に反映してほしい、と続きます。
僕はそのとき、レビューのコピペ用タブを20個開いたまま、夜の11時に「今日は無理だ」とつぶやいていました。アパレルECのささげ業務は、写真や採寸が終わってからのテキスト作業で必ず詰まります。
このとき助かったのが Claude Code でした。提案文の下書きとレビューの仕分けを任せ、僕は「これはブランドの言い方じゃない」を直す側に回る。そうしたら150本が一晩で形になりました。今日はその段取りを、コピペで使える形で渡します。
この記事の要点
- アパレルECのコーデ提案文は「型・シーン・サイズ感」をAIに渡すと一気に下書きが出る。人は語尾とブランドトーンだけ直す
- レビュー分析は「★だけ集計」で終わらせない。サイズ感・生地・配送の3軸でタグ付けして商品改善に回す
- AIに任せるのは下書き・分類・要約。値引き判断・在庫文言・景表法に触れる断定は人が必ず止める
- 商品名や型番だけ渡せば回る。顧客の氏名やメールはAIに渡さないのが個人情報の鉄則
- 50型の提案文で手作業4時間が30分前後に縮んだ。ROIは時給換算でも見合う
アパレルECのささげ業務、どこで詰まるのか
読者像をはっきりさせます。この記事は、アパレルECで商品ページを作る人を想定しています。撮影・採寸・原稿(これを「ささげ」と呼びます)を回し、公開後はレビューを見て改善する。1人で複数ブランドを掛け持ちしていることも多い役割です。
業務フローはだいたいこうです。
- 入荷した新作を撮影し、採寸する
- 商品名・素材・サイズ表を入力する
- コーディネート提案文や着回し文を書く
- 公開し、レビューが溜まってきたら傾向を読む
- サイズ感や生地の不満を、次の商品説明や仕入れに反映する
手戻りが起きるのは、3と5です。提案文は1本書くのに15分かかり、50型あれば丸一日。レビュー分析は「★3が多いな」で止まりがちで、なぜ★3なのかを言語化しないまま次の入荷が来ます。結果、同じサイズ感クレームが半年繰り返される。これがアパレルEC運営の地味な消耗です。
Claude Code に触れるのが初めてなら、先にClaude Codeの始め方ガイドで環境だけ整えておくと、この先の手順がそのまま動きます。
Use case 1:コーデ提案文を1型3パターンで下書きする
最初に効くのが提案文の量産です。型番・カテゴリ・素材・想定シーンを渡すと、トーン違いの下書きが3本出ます。人がやるのは取捨選択と語尾の調整だけ。
任せる範囲と人が判断する範囲を表で分けます。
| 工程 | AIに任せる | 人が必ず判断する |
|---|---|---|
| 着回しのアイデア出し | ○ 候補を5案出す | 自社の在庫にある組み合わせか確認 |
| 提案文の下書き | ○ シーン別に3本 | ブランドの言い方・語尾に直す |
| 素材やお手入れの記述 | △ 叩き台のみ | 洗濯表示と矛盾しないか確認 |
| 「最安」「絶対」などの断定 | × 出させない | 景表法・薬機法の観点で削除 |
提案文づくりのコピペ用プロンプトはこれです。商品ページに貼る前提で、過剰な断定を避ける指示を入れてあります。
あなたはアパレルECのコピーライターです。以下の商品について、
着回し提案文を3パターン書いてください。
# 商品情報
- 型番: KN-2026SS-014
- カテゴリ: オーバーサイズニット
- 素材: コットン60% アクリル40%
- 色: アイボリー / モカ
- 想定シーン: 通勤、休日のカフェ、近所の買い物
# 条件
- 各パターン120〜160字、語尾は「です・ます」
- 着回す相手アイテム(ボトムスや小物)を必ず1つ入れる
- 「最安」「絶対」「医学的」などの断定や効能表現は使わない
- サイズ表記は触れず、雰囲気とシーンに集中する
出力は次の形式:
パターン1: 本文
パターン2: 本文
パターン3: 本文
ポイントは「断定を使わない」を条件に入れること。アパレルは景品表示法に触れやすく、「絶対に痩せて見える」みたいな表現を後で消す手間が地味に重い。最初の指示で禁じておくと、直しが減ります。
Use case 2:レビューを3軸でタグ付けして商品改善に回す
2つ目はレビュー分析です。星の数を数えるだけなら表計算で足ります。価値が出るのは、自由記述を「サイズ感・生地/品質・配送/梱包」の3軸に仕分けして、改善アクションまで言葉にしたときです。
レビュー分類のチェックリストを置きます。AIの出力をこの観点で見直すと、抜けが減ります。
- サイズ感の言及を「大きい/小さい/普通」で分類できているか
- 生地への不満を「薄い/チクチク/毛玉」など具体語で拾えているか
- 配送・梱包の話を商品評価と混ぜていないか
- 同じ不満が何件あるかをカウントしているか
- 改善アクションが「次の入荷」か「説明文の修正」かに振り分けられているか
レビュー仕分け用のプロンプト雛形です。集計しやすいよう、表形式で返させます。
以下はある商品のレビュー本文です。1件ずつ次の3軸でタグ付けし、
最後に改善提案を3つ出してください。
# 軸
1. サイズ感: 大きい / 小さい / 普通 / 言及なし
2. 生地・品質: 良い / 不満(内容) / 言及なし
3. 配送・梱包: 良い / 不満(内容) / 言及なし
# 出力
| No | サイズ感 | 生地・品質 | 配送・梱包 | 一言要約 |
表のあとに「## 改善提案」として、入荷時に直す点と
商品説明文で先回りできる点を分けて書く。
# レビュー本文
(ここに1件1行で貼り付け)
「説明文で先回りできる点」を出させるのがコツです。たとえば「思ったより薄い」が5件あれば、生地を変える前に商品説明へ「軽い着心地の薄手素材です」と書くだけでギャップが減る。仕入れを変えずに★が上がることは珍しくありません。
Use case 3:提案文の品質を機械でチェックする
3つ目は検証です。150本の提案文を人の目だけで確認すると、文字数オーバーや禁止ワード混入が必ずすり抜けます。そこを機械の門番に任せます。
下のスクリプトは、生成した提案文の入った JSON を読み、文字数と禁止ワードを自動チェックします。Node.js があればそのまま動きます。アパレルECで地雷になりやすい断定表現を NG_WORDS に並べてあるので、自社の表現規則に合わせて足してください。
import { readFile } from "node:fs/promises";
// チェック対象: [{ id, text } ...] の配列を入れた JSON
const items = JSON.parse(await readFile("./proposals.json", "utf8"));
const NG_WORDS = ["最安", "絶対", "必ず痩せ", "医学的", "No.1", "日本一"];
const MIN = 120;
const MAX = 160;
let ng = 0;
for (const item of items) {
const len = [...item.text].length; // 全角もう1文字で数える
const hits = NG_WORDS.filter((w) => item.text.includes(w));
const problems = [];
if (len < MIN || len > MAX) problems.push(`文字数 ${len}(${MIN}-${MAX}想定)`);
if (hits.length) problems.push(`禁止ワード: ${hits.join(", ")}`);
if (problems.length) {
ng++;
console.log(`NG ${item.id}: ${problems.join(" / ")}`);
}
}
console.log(`\n合計 ${items.length} 本中 ${ng} 本が要修正`);
process.exit(ng === 0 ? 0 : 1);
proposals.json はこんな形です。提案文生成のときに、この形で出してもらえば連携が楽になります。
[
{ "id": "KN-2026SS-014-A", "text": "やわらかな印象のオーバーサイズニット。…" },
{ "id": "KN-2026SS-014-B", "text": "通勤にもなじむきれいめの一枚。…" }
]
このスクリプトを公開前に1回回すだけで、禁止ワード混入と文字数崩れは公開前に止まります。CLAUDE.md にこうしたルールを書いておくと毎回拾ってくれるので、CLAUDE.md の書き方もあわせて目を通すと運用が安定します。プロンプトをもう一段詰めたい人はプロンプトエンジニアリングの応用が参考になります。
導入前と後で何が変わったか
数字で見ると効果がはっきりします。あくまで僕の手元の概算ですが、目安として置きます。
| 作業 | 導入前 | 導入後 |
|---|---|---|
| 提案文50型×3本 | 約4時間(1本15分換算の一部) | 約30分(下書き+語尾直し) |
| レビュー100件の傾向把握 | 約2時間 | 約20分 |
| 公開前の文字数・禁止ワード確認 | 目視で漏れあり | スクリプトで自動・漏れ0 |
ざっくり、提案文とレビューで月あたり10時間前後が浮きました。時給2,000円で換算しても月2万円ぶん。浮いた時間を撮影ディレクションや仕入れ判断に回せたのが、金額以上に効いています。
AIに任せる範囲と、人が必ず止める線
便利だからと全部任せると、アパレルECでは事故ります。線引きをはっきりさせます。
任せていいのは、下書き・分類・要約・形式チェックです。提案文の叩き台、レビューのタグ付け、改善案の候補出し。ここはAIが速い。
人が必ず止めるのは次です。
- 値引き・セール文言の最終判断(原価と利益に直結する)
- 「絶対」「最安」などの断定や効能表現(景表法・薬機法のリスク)
- 在庫数や入荷時期の記述(誤記が欠品クレームになる)
- ブランドの世界観に関わる言い回し(機械的な語尾は離脱を生む)
非エンジニアのチームでこの線引きを共有するなら、非エンジニアのためのClaude Code入門を一読してもらうと、任せていい作業の感覚がそろいます。
個人情報とセキュリティの注意点
ここは雑にできません。レビュー分析では、本文に購入者の名前や注文番号、住所の一部が紛れていることがあります。これをそのままAIに貼るのは避けます。
実務での約束ごとはシンプルです。
- AIに渡すのは商品名・型番・カテゴリ・素材・公開済みのレビュー本文まで
- 顧客の氏名・メール・電話・注文番号・住所はマスキングしてから渡す
- レビュー本文に個人名が混じっていたら、貼る前に置換する
- 社外秘の原価や仕入れ先名は入力しない
レビューの個人名は、貼り付け前にエディタの置換で「様」「さん」付きの固有名を伏字にするだけで多くは防げます。手間に見えて、ここを飛ばすと一発で信用を失うので必ずやります。
よくある質問
Q. 生成した提案文がどれも似た言い回しになります。 A. プロンプトに「3パターンはトーンを変える(きれいめ/カジュアル/リラックス)」と明示してください。シーンだけ変えても語彙が寄るので、トーンの軸を別に足すと散らばります。
Q. レビューが数百件あって貼りきれません。 A. 一度に全部入れず、50件ずつ分けて同じプロンプトで回し、最後に集計表だけ統合してください。件数が多いほど、Use case 3 の検証スクリプトで機械集計に寄せる価値が上がります。
Q. ブランドトーンを毎回指示するのが面倒です。 A. ブランドの語尾・禁止語・好む言い回しを CLAUDE.md にまとめておくと、毎回の指示が要らなくなります。チームで共有できるのも利点です。
Q. 出てきた文章をそのまま公開していいですか。 A. 下書きとして扱ってください。語尾とブランドトーン、そして断定表現のチェックは人が通す前提です。Use case 3 のスクリプトは補助で、最終判断ではありません。
実際に試した結果
冒頭の「50型を月曜公開」を、実際にこの段取りで回しました。
提案文は、型番と素材とシーンを渡して3パターンずつ生成。150本の下書きが20分ほどで出て、僕がやったのは語尾の統一と、2本に混じっていた「きっと一番似合う」という断定の削除だけでした。検証スクリプトに通したら、文字数オーバーが7本、禁止ワードが2本。これを公開前に拾えたのが大きかった。
レビュー分析では、★3の理由が「サイズが大きめ」に集中していると分かり、商品説明へ「ゆったりめの作りです」と先回りで書きました。次の入荷を待たずに打てる手があると分かったのが収穫です。
結局いちばん効いたのは、AIに任せる作業と自分が止める作業を最初に分けたことでした。下書きはAI、トーンと断定とサイズの最終判断は人。この線を引いてから、夜11時に「無理だ」とつぶやく回数が減りました。チームで同じ流れを整えたい場合は、研修・相談で運用ルールごと設計するのが早道です。
外部の景品表示法の基礎は、消費者庁の表示規制の解説に目を通しておくと、断定表現の線引きが自分の言葉で説明できるようになります。
無料PDF: Claude Code はじめてのチートシート
まずは無料PDFで基本コマンドと最初の使い方をまとめて確認してください。登録後はそのままテンプレート集や導入相談にも進めます。
スパムは送りません。登録情報は厳重に管理します。
Claude Codeを仕事で使える形にしませんか?
まず無料PDFで基本を固め、繰り返し使う作業はGumroad教材へ、チーム導入や権限設計は導入相談へ進めます。
この記事を書いた人
Masa
Claude Codeの実務活用、導入設計、収益導線改善を検証しているエンジニア。10言語の技術メディアを運営中。
関連書籍・参考図書
この記事のテーマに関連する書籍を楽天ブックスで探せます。
※ 当サイトは楽天市場のアフィリエイトプログラムに参加しています。上記リンクから商品をご購入いただくと、運営者に紹介料が支払われる場合があります。
関連記事
制作会社がClaude Codeに触らせる前に決める権限チェックリスト
クライアントサイトを壊さずにAI編集を使うための、制作会社向け権限と確認の型です。
SaaSサポートのバグ報告をClaude Codeで再現手順に変える実務フロー
問い合わせ文をそのまま開発へ投げず、再現手順、証拠、次の一手に整えるサポート向け手順です。
Obsidianの古いメモをClaude Codeの指示書に変える10分ルーチン
Obsidianに溜めたメモが毎回ゴミになる人へ。事実・決定・未確認に仕分けして、Claude Codeがそのまま動ける指示書に変える朝の10分の型を紹介します。