ECサイトに付く商品レビューを、品質・サイズ・配送・説明との違いの区分で分類して担当へ回し、週次の要点にまとめる

処理の起点を決める

日次のシナリオは、「受信」シートに新しい行が追加されたことを起点にします。 Watch New Rows は新しい行が追加されたときに動く監視のモジュールで、Make のスケジュールで定期的に確かめます。スケジュールは、CSVを取り込む朝の時刻に合わせて「Daily」で1日2回にします。 朝の取り込み分と、昼に追加で取り込んだ分を拾うためです。

スケジュールには、一定間隔、1回、毎日、平日、毎週、毎月、日付指定、オンデマンドがあり、毎日の設定では1日に複数の実行時刻を持てるとされています。一定間隔の最短の長さは契約のプランによるとされているので、新商品の発売日のように1時間ごとに回したい日がある場合は、プランを先に確かめます。

週次のシナリオは、「Weekly」で毎週月曜の7時に動かします。 前の週（月曜から日曜）の分類結果だけを対象にします。

Watch New Rows には、1回の実行で扱う件数の上限の欄があります。 セールの翌朝のように取り込みが多い日は、上限に当たって次の実行に回ることがあります。上限に当たったかどうかを実行の記録で見て、当たる日が多いなら実行時刻を増やします。

入力データを集める

質を決めるのは、区分の定義です。 「思っていた色と違う」をどこに入れるかを決めておかないと、第3章の（c）がAIでもそのまま起きます。定義には、含めるものと同じくらい、含めないものを書きます。

レビューの投稿者の名前やニックネームは、取り込みません。 分類に要るのは本文と星の数と商品だけです。

データの取得方法を決める

レビューは、各サイトのレビュー管理画面から、前日分をCSVで書き出して「受信」シートに追記します。書き出しの形式はサイトごとに違うので、列の対応表を作り、取り込むときに同じ列にそろえます。 サイトにレビューのAPIやWebhookがある場合は、そちらで受け取ってもかまいません。

サイトをまたいで同じレビューIDが重なることがあるので、「サイト名＋レビューID」を一意の鍵にします。 同じ鍵の行が「分類済み」にあれば、分類し直さずに飛ばします。

AIへ渡す前に整形する

1. 列をそろえる … サイトごとに違う列名を、サイト名・レビューID・商品コード・星の数・タイトル・本文・投稿日にそろえます
2. 本文の無いレビューを外す … 星だけのレビューは分類に回さず、件数だけを数えます
3. 重複を除く … 「サイト名＋レビューID」が「分類済み」にあれば飛ばします
4. 商品コードの照合 … 商品マスタに無い商品コードは、セット商品や終売品のことが多いので、商品不明 の印を付けて分類は続けます
5. 投稿者の情報を落とす … ニックネーム、年代、性別のような項目は取り込みません
6. 本文の個人情報の印 … 本文に電話番号やメールアドレスのような書き込みがあれば、印を付けてカスタマーサポートへ回します

1. ショップからの返信を外す … 管理画面のCSVに、自社が書いた返信の列が含まれることがあります。本文と一緒に渡すと、返信に書いた「ご迷惑をおかけしました」から不満の区分が付くので、取り込むときに列を外します

2番目の件数は、週次の要点で使います。 星だけのレビューは区分を付けられませんが、星の分布の変化は傾向の手がかりになります。

AIに処理させる

させるのは、本文を読んで区分を付け、区分ごとに根拠の一文を写し、緊急度を付けることだけです。

「サイズ・仕様」と「説明との違い」を分けるのが、この区分のいちばんの肝です。 「思ったより小さい」は印象で、「記載の寸法より2cm小さい」は記載との食い違いです。前者は商品ページの見せ方の話、後者は表示の誤りの話で、直す担当と急ぎ具合が違います。

緊急度は3段階にします。 緊急 は、けが・発火・異臭・誤飲など安全に関わる記載、要対応 は返品・交換の希望と説明との違い、通常 はそれ以外です。

最後の行がいちばん起きやすい失敗です。 星2で本文が「また買います」のレビューに、星の数に引きずられて品質の区分を付けます。区分は本文の記載だけで決めさせます。

逆向きの失敗もあります。 星5で「とても気に入っています。ただ、2回洗ったら色落ちしました」というレビューは、称賛の印象が強く、品質の区分が落ちがちです。「ただ」「でも」「残念なのは」の後ろに不満が書かれることが多いと指示に添え、文の後半まで読ませます。

指示内容を固定する

あなたはECサイトの商品レビューを、社内の担当へ回すために区分けする担当です。
レビューの本文に書かれていることだけで判断してください。

【区分の定義】{区分の定義シートの内容}

【付け方】
- 当てはまる区分をすべて付けてください。1つに絞らないでください。
- 区分ごとに、根拠にした本文の一文をそのまま evidence に写してください。
  要約や言い換えをしないでください。
- 「サイズ・仕様」と「説明との違い」は分けてください。
  商品ページの記載や写真との食い違いが本文に書かれているときだけ
  「説明との違い」にしてください。印象の違いは「サイズ・仕様」です。
- 星の数から区分を推測しないでください。本文に不満が書かれていなければ、
  星が低くても不満の区分を付けないでください。
- 不具合の原因を推測して書かないでください。
- 緊急度は次のとおりです。
  緊急：けが、発火、異臭、誤飲、やけどなど安全に関わる記載がある
  要対応：返品・交換・返金の希望、または説明との違いがある
  通常：それ以外
- どの区分か決められないときは、labels を空にして undecidable を true にしてください。
- 本文に電話番号・メールアドレス・住所のような個人の情報があれば、
  personal_info を true にし、その内容は evidence に写さないでください。

【商品】{商品名}／{カテゴリ}／{サイズ展開}
【星の数】{星}
【タイトル】{タイトル}
【本文】{本文}

「1つに絞らない」を最初に書かないと、いちばん目立つ区分だけが付きます。 サイズの不満と配送の不満が並んでいるレビューで、文章の量の多いほうだけが選ばれ、もう一方の担当に届きません。

「印象の違いはサイズ・仕様」を例と一緒に書くのは、ここがいちばん揺れるからです。 定義のシートに例文を5つずつ置き、指示に差し込みます。揺れたレビューは、例文として定義のシートに足していきます。

週次の要点の指示は別に持ちます。 集約した「商品×区分」の束を渡し、件数の多い順に、根拠の一文を2つずつ添えて要点を書かせます。件数は Make の側で数えた値を渡し、AIに数えさせません。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "review_key": "モールA_R123456",
  "labels": [
    { "category": "サイズ・仕様", "evidence": "思っていたより一回り小さかったです。" },
    { "category": "配送", "evidence": "届いた箱の角がつぶれていました。" }
  ],
  "urgency": "通常 | 要対応 | 緊急",
  "undecidable": false,
  "personal_info": false
}

JSONの形は、Claude API の構造化出力で固定します。 構造化出力はスキーマに沿った応答を制約付きのデコードで保証するもので、output_config.format に type: "json_schema" とスキーマを渡して使います。enum は文字列などで使えますが、大文字と小文字の違いまでは保証されないとされているため、区分の値は日本語にし、Make の側で比較するときも表記をそろえてから比べます。

Make の Anthropic Claude のアプリには、Simple Text Prompt、Create a Prompt、Make an API Call のモジュールがあります。 スキーマの指定を細かく渡したい場合は、Make an API Call でメッセージの API を呼び、output_config を含めます。

1つ目の理由は、区分ごとに担当へ回せることです。 labels が配列なので、ルーターの手前で区分ごとにバンドルを分ければ、1件のレビューが商品担当と物流の両方に届きます。

2つ目は、根拠の一文で担当の確認が速くなることです。 Slack の投稿には、本文全体ではなく区分の根拠の一文を先頭に置き、本文全体はその下に付けます。物流の担当は、配送の一文だけを読めば足ります。

3つ目は、undecidable でフォールバックに回せることです。 区分を付けられなかったものは、ルーターのどの経路の条件にも当たらず、フォールバックの経路で確認待ちに入ります。

週次の要点は、次の表の形で受け取ります。 件数の列は Make の集約で数えた値を差し込み、AIが書くのは「要点」の列だけです。

「前の週」の列を置くのは、増えたものから読めるようにするためです。 件数の多さより、急に増えた商品のほうが、商品担当にとって急ぎの話です。

システムへ連携する

ルーターの経路は、緊急を先頭に置きます。 経路は順に処理されるため、緊急の経路を最初にしておけば、安全に関わるレビューが他の経路の処理を待たずにカスタマーサポートへ届きます。 2番目以降に、返品・交換の希望、説明との違い、品質、配送の順で並べます。

レビュー管理画面とECサイトへは書き込みません。 掲載・非掲載の切り替えや返信は、担当が管理画面で行います。

人が確認する

人が必ず見るのは、緊急 と、フォールバックに入ったものです。 それ以外は担当のチャネルに届いたものを担当が読み、確認済みを付けます。

1. カスタマーサポートが 緊急 をその日のうちに見る … 安全に関わる記載は、購入者への連絡や商品の確認が要るかを判断します
2. カスタマーサポートがフォールバックを見る … 区分を付けて「分類済み」を直します。直した区分は、定義の例文の候補にします
3. 各担当が自分のチャネルを見る … 対応したら確認済みを付けます
4. マーケティング担当が週次の要点を確かめる … 件数の多い「商品×区分」の根拠の一文が、要点の文と合っているかを見ます
5. 毎週、確認済みになっていないものを数える … 3日たっても確認済みにならないものを、週次の要点に載せます

2番目を省かないでください。 フォールバックに入るレビューは、区分の定義のすき間を教えてくれます。直したものを例文に足すほど、フォールバックが減ります。

自動で振り分けたものも、毎週20件だけ抜き取って見ます。 称賛・その他だけに分類されて誰にも投稿されなかったレビューから選び、不満の区分が抜けていないかを確かめます。投稿されなかったものは、誤っていても誰の目にも触れないので、ここだけは抜き取りで補います。

目標は、1,200件をならして1件1分です。 担当が根拠の一文を読んで確認済みを付ける時間と、緊急・フォールバックの確認、週次の要点の確認を合わせた平均です。

例外に対処する

いちばん上の行は、件数は少なくても最も重い例外です。 緊急の判定を外すと、けがにつながる不具合のレビューが通常の流れに埋もれます。指示の緊急の例を広めに取り、迷うものは緊急に倒すほうが安全です。

記録を残す

• 取り込んだレビュー（サイト名、レビューID、商品コード、星の数、本文、投稿日）
• 分類の結果（区分、根拠の一文、緊急度、判定不能、個人情報の印）と、分類した日時
• 人が区分を直した記録 … どのレビューの、どの区分を、どう直したか
• 担当のチャネルに投稿した日時と、確認済みを付けた人と日時
• 週次の要点の下書きと、マーケティング担当が直した確定版
• 区分の定義と対応表の版と、変えた日

3つ目の直した記録が、定義を育てる材料です。 同じ直しが続く区分は、定義の「含めないもの」が足りていません。

最後の行は、区分ごとの件数を月をまたいで比べるために残します。 定義を変えた月は、件数が増減しても傾向の変化とは限りません。