仕入先の仕様書・カタログから商品ページの説明文・特長・サイズ表を作り、仕様書に無いことを書いていないかを点検する

処理の起点を決める

商品マスタに「文章作成待ち」の印が付いたことを起点にします。 印を付けるのは、仕様書を保存した仕入担当です。最小構成では、EC運営課の担当者が印の付いた行を朝に一覧で見て、1点ずつ ChatGPT に渡します。

印を仕入担当に付けてもらうのは、仕様書がそろったことを確かめる人を決めるためです。 仕様書が一部しか届いていない状態で文章を作り始めると、後から届いた仕様書との食い違いを探す作業が生まれます。そろっていないものは「仕様書待ち」のまま止めます。

半自動化の段階では、Google Apps Script の時間主導のトリガーで1時間ごとに商品マスタを見て、印が付いた行を順に処理します。 処理が終わった行は「確認待ち」に変え、失敗した行は印を残したままにします。 印の残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の2つです。 書き方の手引が無いと、ChatGPT は毎回違う順番と文体で書きます。使ってはいけない表現の一覧が無いと、仕様書に無くても一般的によく見る言い回しを入れてきます。 どちらも今は担当者の頭の中にあるもので、最初にシートに書き出します。

カテゴリごとに必ず書く項目は、手引の中で表にします。 収納用品なら外寸・内寸・耐荷重、布製品なら素材の組成と洗濯の可否、電気製品なら定格と付属品。この表があることで、「仕様書に記載なし」を項目として拾えます。 項目の一覧が無ければ、書かれていないことに気づく手がかりがありません。

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

最小構成では、担当者が仕様書のファイルを ChatGPT の画面に添付し、商品マスタの行と手引と一覧を指示文の後ろに貼ります。貼るものは毎回同じ並びにします。 並びが毎回違うと、出てくる表の質も毎回違います。

半自動化の段階では、Google Apps Script が商品マスタの行からフォルダを特定し、仕様書のPDFを読み込んで OpenAI API に送ります。手引は全カテゴリ分を毎回渡さず、その商品のカテゴリの部分だけを渡します。 関係の無いカテゴリの「必ず書く項目」まで渡すと、収納用品に洗濯の可否を書こうとします。

表計算の仕様書は、シートの中身を文字の表にしてから渡します。 色ごとの重さが列で並んでいる仕様書は多く、列と色の対応が崩れると、全色に同じ重さが載ります。 1色1行の形に直してから渡します。

AIへ渡す前に整形する

1. 仕様書がそろっているかの確認 … 商品マスタの色・サイズの展開の数と、仕様書に載っている展開の数を比べます。足りなければ「仕様書待ち」に戻します
2. ファイルの形式の確認 … PDFと画像はそのまま渡し、表計算は1色1行の文字の表に直します。メール本文の仕様はテキストにしてフォルダに保存します
3. ファイルの大きさの確認 … 1ファイル50MB、1回のリクエストの合計50MBが上限です。超えるカタログは、該当する商品のページだけを切り出します
4. 複数の商品が載ったカタログの切り出し … 1冊のカタログに数十点が載っているときは、該当する型番のページだけにします
5. 版の確認 … 同じ型番の仕様書が2つあるときは、新しい日付のものだけを渡し、古いものは別のフォルダへ移します
6. 単位の確認 … 仕様書の寸法がmmかcmかを、表の見出しから拾って印を付けます

4番目と5番目を軽く見ないでください。 カタログ1冊を丸ごと渡すと、隣のページの商品の素材や寸法を取り込みます。 古い仕様書が残っていると、改良前の重さで書きます。どちらも、出てきた文章を読んだだけでは気づけません。

AIに処理させる

させるのは、仕様書の記載だけを材料に下書きを作ることと、その1文ずつに根拠の箇所を付けることです。

右端の列が、この構成でいちばん大事なところです。 書けないところを空けたまま返させます。埋まった下書きより、空いた下書きのほうが、人の確認は速く終わります。

1行目がいちばん起きやすい失敗です。 「収納ボックス」と分かると、ChatGPT は一般的な収納ボックスの長所を知っているので、「湿気に強い」「積み重ねられる」を仕様書に無くても書きます。 たいていは本当にそうですが、その商品の仕様書に書かれていなければ、自社に根拠がありません。

指示内容を固定する

あなたはECサイトの商品登録の担当者です。
添付した仕様書の記載だけを材料に、商品ページの下書きを作ってください。
仕様書に書かれていないことは、一般的に正しいと思われることでも書かないでください。

【作るもの】
1. 項目の一覧 … 書き方の手引の「必ず書く項目」ごとに、仕様書の記載を写す
2. 説明文 … 手引の見出しの順と文体で、200〜300字
3. 特長 … 3〜5個の箇条書き
4. サイズ表 … 色・サイズの展開ごとに1行

【厳守事項】
- 説明文と特長は1文ずつに分け、それぞれに根拠にした仕様書の箇所
  （ページ、表の見出し、該当する文字列）を書いてください。
- 根拠の箇所を書けない文は、文を残したうえで「根拠なし」としてください。
  消したり、言い換えて根拠があるように見せたりしないでください。
- 必ず書く項目のうち、仕様書に記載が無いものは「仕様書に記載なし」と
  してください。推測で埋めないでください。
- サイズ表の数値と単位は、仕様書に書かれたとおりに写してください。
  mmをcmに直す、丸める、外寸と内寸を言い換えることをしないでください。
- 色・サイズの展開ごとに数値が違う場合は、展開ごとに写してください。
  1つの展開の数値を、ほかの展開に流用しないでください。
- 他の商品や他社品との比較を書かないでください。
- 【使ってはいけない表現】の語は使わないでください。仕様書にその語が
  あるときだけ使い、その文に根拠の箇所を書いてください。
- 表示が法令に照らして適切かどうかの判断は書かないでください。

【商品マスタの行】{master_row}
【書き方の手引（このカテゴリの部分）】{style_guide}
【使ってはいけない表現】{ng_words}

「一般的に正しいと思われることでも書かない」を冒頭に置かないと、根拠なしの文が増えます。 生成AIは商品の種類から長所を補うのが得意で、何も言わなければ親切のつもりで書き足します。禁じるのは、商品の種類から書き足すことそのものです。

「消したり、言い換えたりしない」も明記します。 根拠の付かない文を消せと言うと、根拠があるように見える言い回しに変えて残します。 文を残させて印を付けるほうが、人が見つけやすくなります。

出力形式を固定する

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

{
  "product_code": "",
  "spec_file": "",
  "fields": [
    { "name": "外寸", "value": "", "source": "", "status": "found | not_in_spec | unreadable" }
  ],
  "description": [
    { "sentence": "", "source": "", "grounded": true }
  ],
  "features": [
    { "text": "", "source": "", "grounded": true }
  ],
  "size_table": [
    { "variant": "", "outer": "", "inner": "", "weight": "", "unit": "", "source": "" }
  ],
  "ng_word_hits": [
    { "word": "", "sentence": "", "in_spec": false }
  ],
  "questions_for_supplier": []
}

1つ目の理由は、根拠の有無を1文ずつの真偽で持てることです。 grounded が false の文だけを一覧で抜き出せば、人が確かめる範囲が決まります。 自由文の下書きでは、どの文に根拠があるのかを人がもう一度読み直すことになります。

2つ目は、fields の status から仕入先への質問が自動で組めることです。 not_in_spec の項目を並べたものが questions_for_supplier になり、仕入担当がそのまま仕入先へ送る問い合わせの下書きになります。

3つ目は、サイズ表を商品マスタの列に直接写せることです。 size_table は展開ごとの行になっているので、Google Apps Script で商品マスタの寸法の列へ書き出せます。unit を別の欄に持たせているのは、単位の換算を後段で人が決めるためです。

半自動化では、このJSONの形を Structured Outputs のスキーマで固定します。 必須の項目が抜けない、status に決めていない値が入らないことは仕組みで担保されます。ただし、source に書かれた箇所が本当に仕様書にあるかは別の話です。 そこは後段で、source の文字列が仕様書のテキストに含まれるかを Google Apps Script で照らします。

システムへ連携する

ECサイトとモールの管理画面へは、この構成から書き込みません。 掲載するのは人が確認を終えたものだけで、根拠なしの文が残ったまま公開される経路を作らないためです。 管理画面への一括登録は、確認済みの行だけを対象にした別の手順にします。

商品マスタへの書き込みは、状態の列とサイズの列に限ります。 販売価格や在庫の列には触りません。

人が確認する

人が確かめるのは、次の3つです。 根拠の付いた文の言い回しは、読みやすさを直す程度に流し読みします。

1. grounded が false の文 … 仕様書のどこかに書かれていて根拠の箇所を拾えなかっただけか、本当に仕様書に無いかを確かめます。無ければ消すか、仕入先に資料を求めます
2. サイズ表の数値 … 仕様書の該当箇所と、1行ずつ数値と単位を見比べます。この確認だけは省きません
3. not_in_spec の項目 … 仕入先へ確認するかを決めます。確認が取れるまで商品ページには書きません

2番目を省かないでください。 サイズ表は、文章としておかしくないので、間違っていても読んだだけでは分かりません。 仕様書と数字を見比べる以外に見つける方法がありません。

判定を覆したら、点検結果のシートに残します。 根拠なしと出たが仕様書にあった、根拠ありと出たが仕様書と違った。この記録が、指示文と手引を直す材料になります。

目標は、120点をならして1点10分です。 根拠なしの文が毎回多い仕入先は、仕様書そのものが薄いことが多く、AIではなく仕入先への依頼で直します。

例外に対処する

上の4行が大半を占めます。 どれもAIの問題ではなく、仕様書の受け取り方の問題です。 仕入先に「色ごとの重さを書いた一覧をください」と頼むほうが、指示文を工夫するより効きます。

記録を残す

• 渡した仕様書のファイル名と保存日時、版の日付
• ChatGPT に渡した指示文、手引、使ってはいけない表現の一覧のそのときの版
• 返ってきたJSONの全文
• 人が直した後の文章とサイズ表、および直した箇所
• grounded が false だった文と、その扱い（消した／仕様書にあった／資料を求めた）
• 仕入先へ確認した項目と、回答の日付と内容

2つ目で手引の版を残すのは、手引が後から変わるためです。 使ってはいけない表現を足したとき、過去の商品ページのどれを見直せばよいかは、当時の版が残っていないと決まりません。

4つ目の「人が直した後の文章」は、掲載した表示の根拠になります。 掲載後に問い合わせや指摘を受けたとき、どの仕様書のどの記載をもとに書いたかを示せる状態にしておきます。