リサイクルショップが買い取った家電・家具の型番と状態のメモから、店頭の値札と通販サイトの商品説明文を Azure OpenAI で下書きする
買い取った家電・家具の型番・状態のランク・傷のメモ・動作確認の結果から、店頭の値札の短い説明と、通販サイトの商品名と説明文の下書きを Azure OpenAI で作ります。担当者は1点ずつ書く代わりに、下書きを確かめて直します。
- 生成AI
- Azure OpenAI Service/Claude/Gemini
- 連携・自動化
- Power Automate
- 対象業界
- EC/小売
- 対象部門
- マーケティング/営業
- 対象業務
- 内容確認・チェック/書類作成
- 主な課題
- 属人化している/書類作成に時間がかかる/確認ミスが多い
- AIで行う処理
- 生成
- 主な効果
- 入力漏れ削減/品質標準化/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 半自動化
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 商品化の担当が、清掃と動作確認を終えた品物について、買取の管理の仕組みで査定の記録とチェック表を開く
- 値付けの担当が決めた販売の価格を確かめる
- 値札の印刷のソフトに、商品名・型番・製造年・ランク・ひとこと・付属品を打ち込む
- 通販サイトに載せる品物は、商品名と説明文を書く。似た品物の過去の説明文を探して書き換えることが多い
- 説明文と記録を見比べ、付属品・傷の場所・サイズが合っているかを読み直す
- 値札を印刷して貼り、通販サイトの管理画面に説明文と写真を入れて掲載する
- 人商品化の担当が清掃と動作確認を終え、チェック表を入れて、買取の管理の仕組みで在庫の状態を「値札待ち」にする
- 自動Azure Functions が「値札待ち」の品物を30分ごとに拾い、査定の記録・チェック表・採寸の値・販売の価格を取り出す
- 自動型番の表記を整え、店の言葉の一覧から、その品物のランクで使ってよい言葉と使えない言葉を選ぶ
- 自動Azure OpenAI が、記録だけを根拠に、値札のひとことと通販サイトの商品名・説明文を作る。文ごとに元にした記録の項目を付ける
- 自動Azure Functions が、型番・製造年・付属品・サイズが記録と一致するか、使えない言葉が無いか、文字数が収まるかを照らす
- 自動照らした結果を下書きと一緒に買取の管理の仕組みへ書き戻し、在庫の状態を「確認待ち」にする
- 人商品化の担当が下書きと照らした結果を見て、直してから「確定」を押す
- 人値札を印刷して貼る。通販サイトに載せる品物は、掲載の担当が写真と一緒に掲載する
各工程の詳しい説明を読む
- 商品化の担当が、清掃と動作確認を終えた品物について、買取の管理の仕組みで査定の記録とチェック表を開く
- 値付けの担当が決めた販売の価格を確かめる
- 値札の印刷のソフトに、商品名・型番・製造年・ランク・ひとこと・付属品を打ち込む
- 通販サイトに載せる品物は、商品名と説明文を書く。似た品物の過去の説明文を探して書き換えることが多い
- 説明文と記録を見比べ、付属品・傷の場所・サイズが合っているかを読み直す
- 値札を印刷して貼り、通販サイトの管理画面に説明文と写真を入れて掲載する
(a)1点ずつ書くのに時間がかかる。 値札のひとことは短いぶん、何を書くかに迷います。通販サイトの説明文は、過去の似た品物の文を探して書き換えるのが近道ですが、探す時間と、前の品物の記述が残る危うさがついて回ります。
(b)前の品物の記述が残る。 同じ型番の冷蔵庫の説明文を書き換えると、前の品物にあった製氷皿が、今回は欠けているのに「付属品:製氷皿」のまま載ることがあります。届いた客から「書いてあった物が無い」と連絡が来て初めて気づきます。
(c)言葉の使い方が人によって違う。 ある担当は Bのランクの品物を「きれいです」と書き、別の担当は Aのランクの品物にも「使用感あり」と書きます。客から見ると、店の言葉に基準が無いように見えます。 「動作良好」「完動品」も、どこまで確かめたら書いてよいかが決まっていません。
(d)確かめていないことを書く。 洗濯機の説明に「脱水も問題なし」と書いたが、チェック表では脱水の項目が空欄だった、ということが起きます。書いた本人は確かめたつもりでいます。 返品の申し出があったとき、どの記録をもとに書いたのかを後から示せません。
- 【人】 商品化の担当が清掃と動作確認を終え、チェック表を入れて、買取の管理の仕組みで在庫の状態を「値札待ち」にする
- 【自動】 Azure Functions が「値札待ち」の品物を30分ごとに拾い、査定の記録・チェック表・採寸の値・販売の価格を取り出す
- 【自動】 型番の表記を整え、店の言葉の一覧から、その品物のランクで使ってよい言葉と使えない言葉を選ぶ
- 【自動】 Azure OpenAI が、記録だけを根拠に、値札のひとことと通販サイトの商品名・説明文を作る。文ごとに元にした記録の項目を付ける
- 【自動】 Azure Functions が、型番・製造年・付属品・サイズが記録と一致するか、使えない言葉が無いか、文字数が収まるかを照らす
- 【自動】 照らした結果を下書きと一緒に買取の管理の仕組みへ書き戻し、在庫の状態を「確認待ち」にする
- 【人】 商品化の担当が下書きと照らした結果を見て、直してから「確定」を押す
- 【人】 値札を印刷して貼る。通販サイトに載せる品物は、掲載の担当が写真と一緒に掲載する
7番目が、この設計の分かれ目です。 下書きは記録に沿って作られますが、記録そのものが間違っていれば、下書きも間違います。 担当者は品物を目の前にして確かめられる唯一の人なので、確定はその人に残します。
5番目を機械の照合にしているのも、意図してのことです。 型番の1文字の違いや、付属品の有無は、記録と文字で照らせば漏れなく分かります。 生成AIに「記録と合っているか」を判断させると、見落としを見落とします。
02今回想定するシステム構成
査定の記録・動作確認のチェック表・採寸の値(買取の管理の仕組み) │【トリガー】在庫の状態が「値札待ち」(30分ごとに拾う) ▼ Azure Functions ├── 型番の表記を整える(全角・半角、ハイフン) ├── ランクに応じて、使ってよい言葉・使えない言葉を選ぶ ▼ Azure OpenAI(Chat Completions、構造化出力) │ 値札のひとこと/通販サイトの商品名と説明文/文ごとの根拠の項目 ▼ Azure Functions ── 型番・製造年・付属品・サイズの一致、使えない言葉、文字数を照らす ▼ 買取の管理の仕組みへ書き戻し(下書きの欄、照らした結果) ▼ 【商品化の担当が品物を見て確認・確定】 ├──▶ 値札の印刷 └──▶ 通販サイトへ掲載(掲載の担当が人の手で)
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 生成AI | Azure OpenAI(Microsoft Foundry) | Claude API、Gemini API |
| 連携 | Azure Functions(記録の取り出し、表記の整え、照合、書き戻し) | Power Automate |
| 保管 | 買取の管理の仕組み(下書き、照らした結果、確定した文) | SharePoint |
通販サイトへは、この構成から直接掲載しません。 下書きは買取の管理の仕組みの下書きの欄に戻し、担当者が確定した文だけを掲載の担当が載せます。 品物を見ていない人の文が、そのまま客に読まれる経路を作りません。
生成AIには Azure OpenAI(Microsoft Foundry)を使い、構造化出力で受け取ります。 公式のページでは、Chat Completions API では response_format に、Responses API では text.format に JSON スキーマを定義するとされています。すべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定します。 スキーマには最大100個のオブジェクトのプロパティ、入れ子は5段までという上限があるとされています。
Chat Completions API を選ぶのは、会話の履歴を持つ必要が無いからです。 Microsoft のデータとプライバシーのページでは、Responses API は複数回のやり取りのためにメッセージの履歴などを保存するとされています。品物1点ずつの下書きは1回の呼び出しで足ります。 同じページでは、プロンプトと出力は他の顧客や OpenAI には提供されず、基盤のモデルの学習にも使われないとされています。
03どうやって実装するのか
処理の起点を決める
買取の管理の仕組みで、在庫の状態が「値札待ち」になった品物を、Azure Functions が30分ごとに拾います。 状態を変えるのは、清掃と動作確認を終えてチェック表を入れた商品化の担当です。チェック表を入れる前に下書きが作られると、動作の記述が空のまま出てくるので、「値札待ち」に変える条件にチェック表の入力を入れておきます。
1点ずつ処理し、処理が終わった品物は「確認待ち」に変えます。 変えるのは書き戻しが成功したときだけにします。「値札待ち」のまま残っている品物の数が、そのまま未処理の数になります。
30分ごとにしているのは、店頭に出す時間に間に合えばよいからです。 商品化の担当は午前と午後にまとめて値札を貼るので、即時に作る必要はありません。 買取の管理の仕組みに状態の変化を外へ知らせる口があれば、そちらを起点にしてもかまいません。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 査定の記録 | 品目、メーカー、型番、製造年、状態のランク、傷・汚れ・においのメモ | 買取の管理の仕組み |
| 動作確認のチェック表 | 品目ごとに決めた項目(冷蔵庫なら冷蔵・冷凍・製氷・異音など)と、項目ごとの結果(良・不具合あり・未確認) | 買取の管理の仕組み |
| 付属品のチェック | 品目ごとに決めた付属品の一覧と、有・無の印 | 買取の管理の仕組み |
| 採寸の値 | 家具の幅・奥行き・高さ(cm) | 買取の管理の仕組み |
| 販売の価格と保証 | 値付けの担当が決めた価格、店の保証の有無と期間 | 買取の管理の仕組み |
| 店の言葉の一覧 | ランクごとに使ってよい言葉と、使えない言葉 | 自社で用意する一覧 |
質を決めるのは、2つ目と3つ目の「決めた項目」です。 チェック表が自由記述の欄1つだけだと、「動作OK」としか書かれず、何を確かめたのかが下書きに出せません。 品目ごとに項目を決め、項目ごとに結果を入れる形にしておくと、説明文に「冷蔵・冷凍・製氷の動作を確認しました」と、確かめた範囲だけを書かせられます。
「未確認」を選べるようにしておくのも大事です。 空欄と「未確認」は違います。空欄は入れ忘れかもしれませんが、「未確認」は確かめられなかったという記録です。 下書きでは「未確認」の項目を「当店では確認していません」と書かせ、空欄があれば下書きを作らずに戻します。
売主の情報は取り出しません。 査定の記録には、買取のときの本人確認の情報や連絡先が一緒に入っていることがあります。商品の説明には一度も要らないので、取り出す項目から外します。
データの取得方法を決める
買取の管理の仕組みから、在庫番号を鍵に必要な項目だけを取り出します。 外から読む口があればそれを使い、無ければ、仕組みが30分ごとに書き出すファイル(「値札待ち」の品物だけ)を Azure Functions が読みます。
| 取るもの | 何に使うか |
|---|---|
| 査定の記録(売主の情報を除く) | 商品名、型番、製造年、傷のメモの材料 |
| チェック表の項目と結果 | 動作について書いてよい範囲 |
| 付属品のチェック | 付属品と欠品の記述、照合 |
| 採寸の値 | サイズの記述、照合 |
| ランクと店の言葉の一覧 | 使ってよい言葉・使えない言葉の指示 |
記録の項目には、それぞれ短い記号を振って渡します。 傷のメモは D1、チェック表は C1〜C6、付属品は A1〜A4 のようにします。下書きの文ごとに、元にした記号を返させるためです。 担当者は確認の画面で、文の横の記号から元の記録をすぐに開けます。
同じ型番の過去の説明文は渡しません。 書き換えの材料にすると、第3章の(b)の「前の品物の記述が残る」が、生成AIの下書きでも起きるからです。言い回しの手本は、品目ごとに1つだけ、店が選んだ見本の文を渡します。
AIへ渡す前に整形する
- 売主の情報を外す … 取り出す項目を決めておき、それ以外は渡しません
- 型番の表記を整える … 全角を半角に、長音記号とハイフンの揺れを揃えます。整えた後の型番を、照合の基準にします
- 製造年の確認 … 製造年が空欄、または数字でないものは下書きを作らずに戻します
- チェック表の空欄の確認 … 品目ごとに決めた項目に空欄があれば、下書きを作らずに戻します
- ランクから言葉を選ぶ … 店の言葉の一覧から、その品物のランクで使ってよい言葉と使えない言葉を取り出し、指示に入れます
- 文字数の上限を入れる … 値札のひとこと(全角30字)、通販サイトの商品名(全角60字)、説明文(全角800字)の上限を指示に入れます
2番目を軽く見ないでください。 査定の担当がラベルから写した型番は、「NR-F50A」「NR-F50A」「NR-F50A」のように揺れます。 揃えないまま照合すると、正しい型番の下書きが「不一致」と出て、担当者が照合の結果を信用しなくなります。
3番目と4番目で戻すのは、下書きの側で補わせないためです。 製造年が無い家電の説明文を作らせると、型番から製造年を推して書くことがあります。 推した年は記録ではないので、戻して記録を埋めてもらいます。
AIに処理させる
させるのは、記録の項目だけを根拠に、値札のひとことと通販サイトの商品名・説明文を書き、文ごとに元にした記号を付けることです。
| させること | 中身 | 判断できないときの扱い |
|---|---|---|
| 値札のひとこと | 状態の要点を全角30字以内で。傷のメモとランクから | 書くことが無ければ空にし、note に理由を書く |
| 通販サイトの商品名 | メーカー、品目、型番、製造年、容量や大きさなど検索で探される語 | 容量は記録にあるときだけ入れる |
| 説明文の「状態」 | 傷・汚れの場所と程度。傷のメモから | メモに無い面は「記載の無い面も使用に伴う小傷がある場合があります」と定型文で |
| 説明文の「動作」 | チェック表で「良」の項目だけを、確かめた項目として並べる | 「未確認」の項目は「当店では確認していません」と書く |
| 説明文の「付属品」 | 有の印の付属品と、無の印の付属品(欠品)を分けて | 一覧に無い付属品は書かない |
| 説明文の「サイズ」 | 採寸の値をそのまま | 値が無ければ書かない |
| 文ごとの根拠 | 下書きの1文ごとに、元にした記号を付ける | 根拠の無い文は書かない |
「動作」の欄が、この構成でいちばん大事なところです。 「動作良好」「完動品」は、どの項目を確かめたかを言っていない言葉です。確かめた項目を並べて書けば、客は何が確かめられて何が確かめられていないかが分かります。 店の側も、返品の申し出があったときに、どこまでを確かめて売ったかを説明できます。
| させないこと | 理由 |
|---|---|
| 型番から仕様(容量、消費電力、機能)を推して書くこと | 記録ではない。違っていれば客の期待と食い違う |
| 「動作良好」「完動品」「問題なし」と書くこと | 確かめた範囲を言っていない |
| ランクに合わない言葉(Bに「美品」など)を使うこと | 店の基準と食い違う |
| 価格や値引きについて書くこと | 価格は値付けの担当が決め、仕組みが載せる |
| 「新品同様」「ほぼ未使用」と書くこと | Sのランクの基準に合うときだけ一覧から使う |
| 他の店や新品の価格と比べる書き方 | 根拠を示せない |
1行目がいちばん起きやすい失敗です。 型番が分かると、生成AIはその製品の容量や機能を知っているかのように書きます。型番の違う年式の機能が混ざることもあり、記録で確かめていない仕様は書かせません。 容量を商品名に入れたいときは、商品化の担当が本体の銘板を見て記録に入れます。
「実際より良く見せる」書き方に、店は責任を負います。 消費者庁のページでは、商品の品質や規格などについて実際のものよりも著しく優良であると示す表示を優良誤認表示として禁止し、故意でなく誤って表示した場合も規制の対象になるとしています。中古自動車の走行距離を少なく表示した例も挙げられています。下書きを記録に縛り、使えない言葉を照らすのは、この線を越えないためです。
指示内容を固定する
あなたはリサイクルショップで、買い取った品物の値札と通販サイトの説明文を
書く担当を手伝う立場です。下の【記録】に書かれていることだけを材料にしてください。
【書くもの】
1. 値札のひとこと(全角30字以内)
2. 通販サイトの商品名(全角60字以内)
3. 通販サイトの説明文(全角800字以内)。「状態」「動作」「付属品」「サイズ」
「ご注意」の順に見出しを立てる
4. 文ごとに、元にした記録の記号を source に入れる
【厳守事項】
- 記録に書かれていないことを書かないでください。根拠の記号が無い文は書かないでください。
- 型番から容量・機能・消費電力を推して書かないでください。
- 「動作」には、チェック表で「良」の項目だけを、確かめた項目として並べてください。
「未確認」の項目は「当店では確認していません」と書いてください。
- 「動作良好」「完動品」「問題なし」「新品同様」「格安」と書かないでください。
- このランクで使ってよい言葉:{allowed_words}
このランクで使えない言葉:{banned_words}
- 付属品は、有の印のものを「付属品」、無の印のものを「欠品」として分けてください。
- 価格・値引き・他店との比較を書かないでください。
- 型番と製造年は、記録の文字をそのまま写してください。
【見本の文(言い回しの参考。内容は使わない)】{sample_text}
【記録】{record_items} ← 記号付き(D1…、C1…、A1…、S1…)
「見本の文の内容は使わない」を明記しないと、見本の付属品や傷の記述が混ざります。 見本を渡すのは言い回しを揃えるためで、中身はその品物の記録だけから書かせます。
「使えない言葉」をランクごとに差し込むのは、指示を短く保つためです。 店の言葉の一覧をまるごと渡すと、どのランクにどの言葉が使えるかを生成AIが取り違えます。その品物のランクの分だけを渡します。
出力形式を固定する
次の形のJSONで受け取ります。
{
"stock_no": "",
"tag_note": { "text": "左側面に小傷あり。製氷皿欠品", "source": ["D1", "A2"] },
"ec_title": { "text": "", "source": ["S1", "S2", "S3"] },
"ec_body": [
{ "section": "状態 | 動作 | 付属品 | サイズ | ご注意",
"text": "", "source": [""] }
],
"unused_items": ["C5"],
"note": ""
}
1つ目の理由は、文ごとに根拠を持たせられることです。 担当者の確認の画面では、文の横に記号が並び、押すと元の記録が出ます。根拠の記号が付いていない文は、照合の段階で赤く表示します。
2つ目は、unused_items で使われなかった記録が見えることです。 傷のメモの2つ目が説明文に入っていなければ、ここに D2 が出ます。客に伝えるべき傷が抜けていないかを、担当者が一目で確かめられます。
3つ目は、section で説明文の組み立てを揃えられることです。 どの担当の品物も「状態」「動作」「付属品」「サイズ」「ご注意」の順に並ぶので、客は通販サイトのどの商品でも同じ場所を見れば、欠品と確かめた範囲が分かります。
文字数はスキーマで縛れません。 公式のページでは、文字列の minLength・maxLength・pattern・format はサポートされないキーワードとされています。Azure Functions が文字数を数え、上限を超えたら「あと何字短く」と付けて1回だけ作り直します。 それでも超えたら、担当者が削ります。
照合の結果は、次の形で書き戻します。
【照合の結果】在庫番号 R-24-01873
型番 ............ 一致(NR-F50A)
製造年 .......... 一致(2021年製)
付属品 .......... 不一致:説明文に「製氷皿」、記録は A2=無
使えない言葉 .... なし
根拠の無い文 .... 1文(ご注意の2文目)
未使用の記録 .... D2(扉の内側のパッキンの汚れ)
文字数 .......... 値札 22字/商品名 41字/説明文 612字 システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 買取の管理の仕組み | 読み取りの口または書き出しファイル | 「値札待ち」の品物の記録を読む。下書きと照合の結果を書き戻す |
| Azure OpenAI | Chat Completions API | 値札と説明文の下書き |
| 値札の印刷のソフト | 確定した文を仕組みから渡す | 担当者が確定した品物だけ |
| 通販サイトの管理画面 | 掲載の担当が貼る | 確定した商品名と説明文 |
書き戻すのは下書きの欄だけです。 確定の欄と、通販サイトに載っている文の欄には書きません。確認の途中の文が、店頭や通販サイトに出ることがありません。
デプロイの種類は、処理の場所で選びます。 公式のデータとプライバシーのページでは、Global や DataZone の種類でなければ、プロンプトと応答は顧客が指定した地域(geography)の中で処理されるとされています。Global の種類は、そのモデルが展開されているどの地域でも処理されうるとされています。扱うのは品物の記録で個人の情報は渡さないので、費用と速さを見て選んでかまいません。 社内の規程で処理の地域が決まっていれば、それに従います。
人が確認する
商品化の担当は、品物を目の前にして、照合の結果を先に見てから下書きを読みます。
- 照合の「不一致」を見る … 付属品、型番、サイズ。品物を見て、記録と下書きのどちらが正しいかを確かめます
- 根拠の無い文を見る … 消すか、記録を足して根拠を作るかを決めます
- 未使用の記録を見る … 抜けた傷のメモを説明文に足すかを決めます
- 下書きを品物と見比べる … 傷の場所、色の呼び方、においの有無。記録に書かれていない傷を見つけたら、記録のほうに足して作り直します
- 確定を押す … 値札の印刷と、通販サイトの掲載の待ちに回ります
4番目で記録を直すのが、この運用の約束です。 下書きだけを直すと、記録と下書きが食い違ったまま残ります。返品の申し出があったときに示すのは記録なので、記録のほうを正しくします。
目標は、900点をならして1点3分です。 照合で不一致が無い品物は、品物と下書きを見比べて1分ほどで確定できます。不一致や根拠の無い文が出た品物に、時間を使います。
例外に対処する
| 起きること | 対応 |
|---|---|
| チェック表に空欄がある | 下書きを作らず「値札待ち」から「記録の不足」に戻す |
| 型番が読めず、記録に「不明」とある | 商品名に型番を入れず、通販サイトには載せない。店頭だけで売る |
| 製造年が店の販売の目安より古い | 下書きを作らず、店長に回す。売るかは店長が決める |
| 照合で付属品が不一致 | 品物を見て、記録と下書きのどちらかを直す |
| 文字数が上限を超える | 1回だけ作り直す。それでも超えたら担当者が削る |
| 傷のメモに「水濡れの跡」「焦げ」がある | 下書きは作るが、店長の確認を必須にする |
| リコールの対象の型番だった | 下書きを止め、販売しない。照合の前に人が確かめる |
| 生成AIの応答が返らない | 「値札待ち」のまま残し、次の30分で再び拾う。3回続けば担当者が手で書く |
| 同じ品物を二重に拾う | 在庫番号で処理済みを見て、二度作らない |
7行目は、生成AIの仕事ではありません。 国民生活センターのページでは、所有している製品がリコールで回収・修理・交換などの対象になっていないかを、消費者庁のリコール情報サイトで定期的に確かめるよう勧め、対象と分かったらすぐに使用をやめ、メーカーなどに連絡するよう呼びかけています。買い取った家電を売る前に、型番をリコール情報サイトで確かめる工程を、値付けの段階に置きます。 下書きの仕組みには、その結果を「確認済み」の印として受け取るだけにします。
3行目の販売の目安は、店が決めるものです。 製造から何年の家電を売るかは、店の方針と保証の考え方で決まります。生成AIにも照合のプログラムにも決めさせず、目安を超えたものは人に回します。
記録を残す
- 下書きを作った日時、在庫番号、品目、ランク
- 生成AIへ渡した記録(記号付き)と、受け取った下書きの全文
- 照合の結果と、担当者が確定した文
- 担当者が直した箇所と、記録のほうを直したかどうか
- 値札を印刷した日、通販サイトに載せた日、売れた日
- 返品・問い合わせがあった品物と、その理由
4つ目が、言葉の一覧と指示を直す材料になります。 担当者が毎回同じ言い回しを直しているなら、見本の文か一覧のほうを直します。直した回数を品目ごとに数えると、どの品目の指示が弱いかが分かります。
最後の行は、記録の取り方を見直す材料になります。 「書いてあった物が無い」という問い合わせが特定の品目に偏るなら、その品目の付属品の一覧が足りていません。
04実装レベルの3段階
最小構成では、記録の書き出しが手作業です。 月900点には使えません。確かめるための段階です。 半自動化で、1点8分が3分になり、この段階が本記事の想定です。 書く時間と読み直しの多くが無くなり、担当者は品物を見て確かめる時間に使います。 本格構成は、確定の運用が定着してから進みます。 通販サイトへの登録を自動にすると掲載の担当の手間が減りますが、この試算には入れていません。 確定を押す前の文が登録される作りにしないことだけは、最初から守ります。
05工数削減シミュレーション
導入後 900件 × 3分 ÷ 60 = 45 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 店舗を数か所持ち、買い取った家電・家具を月に数百点以上、店頭と自社の通販サイトの両方で売っているリサイクルショップ。査定のときに型番・状態のランク・傷のメモ・動作確認の結果を買取の管理の仕組みに入力しているものの、値札と通販サイトの説明文は担当者がそれぞれ書いていて、書きぶりと点検の細かさが人によって違う場合。「美品」「動作良好」のような言葉の使い方を店の基準で揃えたい場合。
- 扱う点数が月に数十点で、店長が値札と説明文をすべて自分で書いている場合。査定の記録が紙の伝票だけで、型番や状態を文字のデータとして取り出せない場合(先に記録の入力から始めます)。ブランド品・貴金属・美術品など、真贋の判断が商品の説明の中心になる品目。なお、買取の価格と販売の価格の決定、状態のランクの判定、リコールの対象かどうかの確認は、この構成では代替できません。
07最小構成で試す方法
- 先月に通販サイトで売れた家電と家具から、品目の違う20点を選ぶ(問い合わせや返品があった品物を数点入れる)
- その20点の査定の記録とチェック表を、売主の情報を除いて書き出し、項目に記号を振る
- 社内で使える Azure OpenAI の画面(Microsoft Foundry のプレイグラウンド)に、第7章の指示と記録を貼る
- 出てきた下書きを、実際に掲載した説明文と並べる
- 付属品・型番・動作の記述が、記録と合っているかを手で照らす
20点は必ずやってください。 連携を作る前に、いまの記録が下書きの材料として足りているかを確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 実際の説明文と同じくらい具体的な下書きが出た | 連携と照合の仕組みに進む |
| 型番から仕様を推した、「動作良好」と書いた | 指示の書き方で直る。構成は有効 |
| 動作の記述が「動作確認済み」しか出ない | チェック表の項目を決めるのが先。 AIの問題ではない |
3行目が出たら、チェック表を見直す機会です。 自由記述の「動作OK」からは、何を確かめたかを書けません。品目ごとに項目を決めると、下書きの質より先に、確かめる手順が揃います。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 型番から容量や機能を推して書く | 指示で禁じ、記録に無い仕様は書かせない |
| 「動作良好」「完動品」が入る | 使えない言葉の一覧で照らし、確かめた項目を並べる書き方に固定する |
| 見本の文の付属品が混ざる | 「見本の内容は使わない」と明記し、照合で付属品を記録と比べる |
| 型番の表記の揺れで不一致が出すぎる | 全角・半角とハイフンを揃えてから照合する |
| 文字数が値札に収まらない | maxLength はスキーマで使えない。Functions で数えて作り直す |
| チェック表が自由記述で、動作の範囲が書けない | 品目ごとに項目を決め、良・不具合あり・未確認で入れる |
| 空欄が「確認した」と書かれる | 空欄があれば下書きを作らずに戻す |
| 売主の情報が入力に混ざる | 取り出す項目を決め、それ以外を渡さない |
| 担当者が下書きだけを直し、記録が古いまま | 記録のほうを直して作り直す運用にする |
| リコールの対象を売ってしまう | 値付けの段階でリコール情報サイトを確かめ、印が無ければ下書きを作らない |
上の2行が、この構成の失敗のほとんどです。 どちらも、生成AIが「商品説明らしい文」を書こうとして起きます。 記録に縛る指示と、使えない言葉の照合を、両方入れてあるかどうかで運用に乗るかが決まります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 買い取った品物の型番、製造年、状態、傷のメモ、動作確認の結果、採寸の値、販売の価格です。売主の本人確認の情報や連絡先は、取り出す項目から外します。
- 生成AIへ渡すのは品物の記録だけにする … 査定の記録にある売主の情報は、商品の説明に要りません。要らないものは、最初から渡しません
- 言い過ぎた表示に店が責任を負う … 消費者庁のページは、品質を実際よりも著しく優良であると示す表示を禁止し、誤って表示した場合も規制の対象になるとしています。下書きを記録に縛り、使えない言葉を照らし、確定は品物を見た担当者が行います
- リコールの確認を人の工程に置く … 型番がリコールの対象かどうかは、消費者庁のリコール情報サイトで人が確かめます。 生成AIに判断させません
- 処理の場所と履歴 … Global のデプロイでは、そのモデルが展開されているどの地域でも処理されうるとされています。社内の規程に合う種類を選び、履歴を残す必要が無いので Chat Completions で1回ずつ呼びます
- 記録と確定した文を残す … 返品や問い合わせのときに、どの記録をもとにどの文を載せたかを示せるようにします
- 価格を生成AIに決めさせない … 販売の価格は値付けの担当が決め、仕組みが値札に載せます。下書きに価格や値引きの記述を書かせません
誤りが起きた場合のリスクは、記録に無い長所や付属品が載ることと、店の言葉の基準と違う表現が載ることの2つです。 前者は根拠の記号と照合で、後者は言葉の一覧で防ぎます。どちらも、店頭と通販サイトに出る前に人が止められる位置に置きます。
10まず何から始めるか
1週目:チェック表と付属品の一覧を決める
冷蔵庫、洗濯機、電子レンジ、テレビ、ソファ、食器棚など、点数の多い品目から順に、動作確認の項目と付属品の一覧を決めます。 結果は「良・不具合あり・未確認」の3つで入れる形にします。
2週目:20点で試す
先月に売れた20点の記録を書き出し、プレイグラウンドで下書きを作らせます。型番から仕様を推していないか、「動作良好」と書いていないかを最優先で見ます。
3週目:言葉の一覧を作る
ランクごとに使ってよい言葉と使えない言葉を決めます。 これまで担当者が使ってきた言葉を集め、店長と通販サイトの掲載の担当で、どのランクに何を使うかを決めます。品目ごとの見本の文も1つずつ選びます。
4週目:拾うところから書き戻しまでをつなぐ
Azure Functions で「値札待ち」の品物を拾い、下書きを書き戻すところまで作ります。この時点では照合を入れず、根拠の記号が正しく付くかだけを見ます。
2か月目: 照合と文字数の確認を足し、1店舗で使い始めます。照合で不一致になった件数を毎週数えます。3か月目以降: 4店舗に広げ、1点8分が何分になったかを実測します。担当者が直す箇所が言い回しの好みだけになり、「書いてあった物が無い」という問い合わせが来なくなった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Chat Completions API と Responses API の両方で構造化出力が使え、それぞれ response_format・text.format でスキーマを定義すること。すべてのフィールドを必須にし additionalProperties: false を設定すること。文字列の minLength・maxLength・pattern・format が非対応であること。最大100個のオブジェクトのプロパティ、入れ子5段までであること | Microsoft Learn: Azure OpenAI で構造化出力を使用する方法 | 2026-10-27 |
| プロンプトと出力が他の顧客や OpenAI に提供されず、基盤のモデルの学習に使われないこと。Global・DataZone 以外は顧客が指定した地域の中で処理され、Global はモデルが展開されたどの地域でも処理されうること。Responses API がメッセージの履歴などを保存すること | Microsoft Learn: Data, privacy, and security for Foundry Models sold by Azure | 2026-10-27 |
| 景品表示法第5条第1号が、品質・規格その他の内容について実際のものよりも著しく優良であると示す表示を禁止していること。誤って表示した場合も規制の対象になること。中古自動車の走行距離の例 | 消費者庁: 優良誤認とは | 2026-10-27 |
| 所有している製品がリコールの対象になっていないかを、消費者庁のリコール情報サイトで定期的に確かめるよう勧めていること。対象と分かったらすぐに使用をやめ、メーカーなどに連絡するよう呼びかけていること | 国民生活センター: 見守り新鮮情報 第554号「事故を防ぐ!リコール情報を確認しましょう」 | 2026-10-27 |
どの言葉をどのランクに使うか、どの品物を売るかは、店の方針と店長の判断で決めてください。 本記事は上記の公式ページで確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1938)についてのご相談はこちらから。
