Media > AI活用ユースケース > 営業 > リユース店が買い取った家電・ブランド品・工具の写真から、商品名と型番の候補・付属品・状態の説明を作り、通販サイトへの出品の下書きにする

リユース店が買い取った家電・ブランド品・工具の写真から、商品名と型番の候補・付属品・状態の説明を作り、通販サイトへの出品の下書きにする

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

リユース店が買い取った家電・ブランド品・工具の写真から、商品名と型番の候補、写っている付属品、傷・汚れの場所と種類を拾い、通販サイトへの出品の下書きを作ります。出品担当は、型番を調べ、説明を書く代わりに、下書きを確かめて直します。

サマリー
生成AI
ChatGPT/Claude/Gemini
連携・自動化
Google Apps Script/Python
対象業界
EC/小売
対象部門
営業
対象業務
データ入力・転記/書類作成
主な課題
人手が足りない/書類作成に時間がかかる/確認ミスが多い
AIで行う処理
画像認識
主な効果
入力漏れ削減/品質標準化/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
180h/月
AI導入後
60h/月
想定削減
67%
年間削減
1,440h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 査定の担当が買取のときに写真を撮り、動作の確認の結果と買取の記録を在庫管理システムに入れる
  2. 出品の担当が、管理番号ごとに写真と記録を開く
  3. 本体のラベルや銘板の写真から型番を読み、メーカーの名前と型番で検索して商品名と発売の年を調べる
  4. 写真を見ながら、付属品(リモコン、取扱説明書、箱、充電器、替え刃 など)を書き出す
  5. 傷・汚れ・使用感を写真で探し、自社の状態の基準(S・A・B・C・ジャンク)に当てて状態を決める
  6. 出品の文の型に沿って、商品名・型番・付属品・状態・注意事項を書く
  7. 通販サイトの管理画面に入れて出品する
導入後(After)
  1. 人査定の担当が、決まった角度(正面・背面・ラベル・付属品を並べた写真・傷の寄り)で写真を撮り、動作の確認の結果を入れる
  2. 自動在庫管理システムで出品の準備に回った品物を、プログラムが1時間ごとに拾う
  3. 自動写真の枚数と角度のラベルがそろっているかを確かめ、写真を縮めて Gemini API に渡す
  4. 自動Gemini API が、商品名と型番の候補(ラベルから読んだか、見た目から推したか)、付属品、傷・汚れの場所と種類を JSON で返す
  5. 自動プログラムが、型番の候補を自社の過去の出品の記録と照らし、付属品の標準の一覧があれば差を出す
  6. 自動説明文の下書きと、出品の担当が確かめる事項の一覧を作る
  7. 人出品の担当が、確かめる事項の一覧から見て、型番・付属品・状態を確定し、下書きを直す
  8. 人通販サイトの管理画面に入れて出品する
各工程の詳しい説明を読む
  1. 査定の担当が買取のときに写真を撮り、動作の確認の結果と買取の記録を在庫管理システムに入れる
  2. 出品の担当が、管理番号ごとに写真と記録を開く
  3. 本体のラベルや銘板の写真から型番を読み、メーカーの名前と型番で検索して商品名と発売の年を調べる
  4. 写真を見ながら、付属品(リモコン、取扱説明書、箱、充電器、替え刃 など)を書き出す
  5. 傷・汚れ・使用感を写真で探し、自社の状態の基準(S・A・B・C・ジャンク)に当てて状態を決める
  6. 出品の文の型に沿って、商品名・型番・付属品・状態・注意事項を書く
  7. 通販サイトの管理画面に入れて出品する

(a)型番を調べるのに時間がかかる。 ラベルが小さい、かすれている、写真がぶれている、と読むだけで手間取ります。読めても、似た型番が多いメーカーでは、末尾の1文字で別の色・別の容量になります。

(b)付属品の書き漏れ。 写真に写っている替え刃や延長コードを書き忘れる一方、写っていない取扱説明書を「付属」と書いてしまうことがあります。購入者からの問い合わせで多いのは、付属品の食い違いです。

(c)状態の付け方が担当者ごとに違う。 同じ小傷でも、ある担当者はA、別の担当者はBを付けます。状態の基準は文章では決まっていますが、どの傷をどう読むかは人に任されています。

(d)出品が追いつかない。 1点12分でも、月900点では1人の担当の大半の時間になります。忙しい週ほど説明が短くなり、書き漏れが増えます。

  1. 【人】 査定の担当が、決まった角度(正面・背面・ラベル・付属品を並べた写真・傷の寄り)で写真を撮り、動作の確認の結果を入れる
  2. 【自動】 在庫管理システムで出品の準備に回った品物を、プログラムが1時間ごとに拾う
  3. 【自動】 写真の枚数と角度のラベルがそろっているかを確かめ、写真を縮めて Gemini API に渡す
  4. 【自動】 Gemini API が、商品名と型番の候補(ラベルから読んだか、見た目から推したか)、付属品、傷・汚れの場所と種類を JSON で返す
  5. 【自動】 プログラムが、型番の候補を自社の過去の出品の記録と照らし、付属品の標準の一覧があれば差を出す
  6. 【自動】 説明文の下書きと、出品の担当が確かめる事項の一覧を作る
  7. 【人】 出品の担当が、確かめる事項の一覧から見て、型番・付属品・状態を確定し、下書きを直す
  8. 【人】 通販サイトの管理画面に入れて出品する

7番目が、この設計の分かれ目です。出品の担当は、写真を最初から見直しません。 確かめる事項(見た目から推した型番、ラベルが読めなかった品物、状態の候補が分かれた傷)から見ていきます。ラベルから読めた型番で、過去の出品と一致したものは、写真で一度見て終わりにします。

状態の基準(S・A・B・C・ジャンク)は、AIには候補だけを出させます。 確定するのは出品の担当です。同じ傷の読み方を店でそろえるために、AIの候補と担当の確定が食い違ったものを毎週見直します(第7章)。

02今回想定するシステム構成

構成図
買取(査定の担当が決まった角度で写真を撮り、動作の確認の結果を入れる)
   ▼【トリガー】在庫管理システムで「出品の準備」に回った品物(1時間ごと)
Python のプログラム(社内のサーバー)
   ├── 写真の枚数と角度のラベルの確認、縮小
   ▼
Gemini API(画像の理解・構造化出力)── 品物ごとに1回
   │   商品名と型番の候補(label_read / inferred)とラベルの枠
   │   写っている付属品
   │   傷・汚れの場所と種類、写っていない面
   │   状態の候補と理由
   ▼
Python ── 過去の出品の記録との照合、付属品の標準の一覧との差
   ▼
説明文の下書き / 出品の担当が確かめる事項
   ▼
【人】出品の担当が確定し、通販サイトに出品
役割想定する製品代替候補
処理Gemini API(写真から型番の候補・付属品・傷を返し、説明文の下書きを作る)Claude API、OpenAI API
連携Python(在庫管理システムからの取得、写真の前処理、呼び出し、照合、下書きの書き戻し)Google Apps Script
台帳在庫管理システム(買取の記録、管理番号、出品の状態)-
出品先自社の通販サイト、通販モール-

新しく足すのは、Python のプログラムと Gemini API の契約、そして査定の担当が撮る写真の角度の決めごとです。 在庫管理システムも通販サイトもすでにあるものです。通販サイトへの自動の出品はしません。 下書きは在庫管理システムの「出品の下書き」の欄に書き戻し、出品は担当が行います。

写真を見る土台は、Gemini API の画像の理解です。 公式の案内では、画像の説明、画像についての質問への回答、分類、物の検出などに使えるとされています。対応する形式は PNG、JPEG、WEBP、HEIC、HEIF です。1つのリクエストに複数の画像を入れられるので、品物ごとに5〜8枚をまとめて渡します。画像を直接入れる場合は、リクエスト全体が20MBまでです。

ラベルの位置は枠で返させます。 物を検出させて枠を返させることができ、例では [ymin, xmin, ymax, xmax] の順で 0〜1000 に正規化されます。型番を読んだラベルの位置に枠があれば、出品の担当は写真のどこを見ればよいかがすぐ分かります。

出力は構造化出力で受けます。 response_format で mime_type を application/json にし、schema を入れて /v1beta/interactions に送ります。enum で値を決まった文字列に絞れます。値はアプリ側で検証するよう書かれています。

出品のページには、法律で決まった表示があります。 古物営業法では、古物商はインターネットで取引するとき、氏名又は名称、許可をした公安委員会の名称、許可証の番号を公衆の閲覧に供することとされています(規模が著しく小さい場合などを除く)。これは出品の文の型に固定で入れる項目で、AIには書かせません。

03どうやって実装するのか

Step1

処理の起点を決める

在庫管理システムで、品物が「出品の準備」の状態に回ったことを起点にします。 プログラムが1時間ごとにその状態の品物を拾い、まだ下書きの無いものだけを処理します。買取の直後には動かしません。 査定の担当が動作の確認の結果を入れ終える前に下書きを作ると、「動作の確認:未記入」のまま説明文ができます。

写真の撮り直しや、査定の記録の直しがあったときは、その品物だけを呼び直します。 呼び直すと、出品の担当が直した下書きを上書きしないよう、直した後の下書きは別の欄に残します。

Step2

入力データを集める

データ中身取得元
品物の写真正面、背面、ラベル・銘板の寄り、付属品を並べた写真、傷の寄り。ファイル名に角度のラベル写真の保管先
買取の記録管理番号、品目、メーカーの名前(査定の担当が分かれば)、買取の日在庫管理システム
動作の確認の結果通電、主な機能の動作、確認した日と担当、確認していない機能在庫管理システム
状態の基準S・A・B・C・ジャンクの定義と、品目ごとの傷の読み方の例自社で用意する文書
付属品の標準の一覧型番ごとの新品のときの付属品(自社で過去に作ったもの)自社で用意する一覧

質を決めるのは、写真の角度の決めごとです。 ラベルの寄りが無い写真の組では、型番はほとんど inferred になります。品目ごとに「ラベルはここ」の例の写真を査定の担当に渡し、撮る角度をそろえます。 炊飯器なら底、掃除機ならダストカップの裏、電動工具ならハンドルの側面です。

付属品の標準の一覧は、はじめは無くても動きます。 無いときは、写っている付属品を並べるだけにします。過去の出品で型番ごとの付属品が分かっているものから一覧にしていくと、「写っていない標準の付属品」が出せるようになります。

Step3

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

写真は、管理番号で写真の保管先から取ります。 角度のラベルで並べ、ラベルの寄りを先頭にします。動作の確認の結果と状態の基準は、在庫管理システムと社内の文書から取り、指示の文に入れます。

Gemini API へは、品物ごとに1回、写真をまとめて渡します。 1枚ずつ呼ぶと、正面の写真で推した商品名とラベルの写真で読んだ型番が別々に返り、つなぎ合わせる処理が要ります。まとめて渡せば、「ラベルの型番が正面の見た目と合うか」もAIに見させられます。

在庫管理システムに API が無い場合は、書き出したファイルで受けます。 1時間ごとに「出品の準備」の品物の一覧を書き出す設定にし、プログラムはその一覧を読みます。下書きの書き戻しも、取り込み用のファイルを作って在庫管理システムに読み込ませる形にします。 書き戻しの取り込みに失敗した品物は、次の回に同じ下書きを作り直さないよう、処理済みの印を残しておきます。

有料の利用枠で使います。 Gemini API の規約では、有料のサービスではプロンプトと応答(画像などのファイルを含む)が製品の改善に使われないとされています。

Step4

AIへ渡す前に整形する

  1. 枚数と角度の確認 … 決まった角度のラベルがそろっているかを見ます。ラベルの寄りが無い組は、AIに渡す前に「ラベルの写真なし」と印を付けます
  2. 形式と向き … PNG、JPEG、WEBP、HEIC、HEIF のどれかであることを確かめ、画像の向きの情報で回転しているだけのものは画素を回転させます。向きが合っていないと、返った枠がずれます
  3. 縮小 … 全体の写真は長い辺を1,600ピクセル程度に縮めます。ラベルの寄りは縮めすぎると文字がつぶれるので、大きめに残します
  4. 大きさの確認 … 画像を直接入れる場合は、リクエスト全体が20MBまでです。超えるときは縮め直します
  5. 動作の確認の結果の付け足し … 「確認した機能」と「確認していない機能」を分けて指示に入れます
  6. 人と個人の情報の映り込みの確認 … 査定の机の上の書類、売り主の手や顔が写っていれば、その写真は撮り直します

3番目を軽く見ないでください。 写真全体を同じ大きさに縮めると、銘板の小さな文字がつぶれ、読めたはずの型番が inferred になります。 ラベルの寄りの写真だけは縮め方を変えます。

Step5

AIに処理させる

させるのは、写真から商品名と型番の候補、写っている付属品、傷・汚れの場所と種類、状態の候補を返し、説明文の下書きを作ることだけです。

返すもの中身判断できないときの扱い
商品名と型番の候補メーカーの名前、商品名、型番、label_read か inferred か、ラベルの枠ラベルが読めなければ label_unreadable。推した型番は候補として最大3つ
付属品写っている付属品の名前と数何か分からない物は unknown_accessory として載せる
傷・汚れ場所(天面、側面、底面、持ち手 など)、種類(擦り傷、へこみ、割れ、変色、しみ、さび)、写真と枠汚れか傷か分からなければ unclear
写っていない面写真に無い面や、暗くて見えない範囲範囲がはっきりしなければ「写っていない面がある」
状態の候補状態の基準に照らした候補と理由候補が2つに分かれれば両方を返す
確かめる事項ラベルの型番と見た目が合わない、製造番号のラベルが剥がれている など迷えば載せる

右端の列の考え方は、迷ったら出品の担当に見せる側に倒すことです。 推した型番は候補として返し、状態が2つに分かれれば両方を返させます。候補が多いのは担当の数秒で済みますが、確かな値のように書かれた誤りは、購入者に届くまで誰も気づきません。

確かめる事項に「製造番号のラベルが剥がれている」を入れるのは、店の判断に回すためです。 古物営業法では、古物商は買い受けようとする古物に不正品の疑いがあると認めるときは、直ちに警察官に申告しなければならないとされています。疑いがあるかを決めるのは店で、AIは写っている事実を返すだけです。

させないこと理由
ブランド品の真贋の判断写真からは分からない。専門の担当が実物で見る
動作の可否の記載査定の担当の記録だけを根拠にする
状態の確定候補まで。出品の担当が基準で決める
写っていない付属品を「付属」と書く箱の中や引き出しの中は写っていない
販売価格・相場の記載価格は店が決める
不正品かどうかの判断疑いがあるかの判断と警察への申告は店が行う

4行目がいちばん起きやすい失敗です。 新品のときの付属品を知っている製品では、AIは「リモコン・取扱説明書付き」と書きたがります。写っていない付属品が説明文に入ると、購入者からの問い合わせと返品になります。

Step6

指示内容を固定する

あなたはリユース店の出品担当を手伝う係です。
買い取った1つの品物を、決まった角度から撮った写真が複数あります。
写真のファイル名には、角度のラベル(front/back/label/accessories/closeup)があります。

【品目】{買取の記録の品目}
【メーカー】{査定の担当が入れたメーカーの名前。無ければ空}
【動作の確認の結果】確認した機能:{一覧} 確認していない機能:{一覧}
【状態の基準】{S・A・B・C・ジャンクの定義と傷の読み方の例}

【やること】
1. label の写真のラベル・銘板から、メーカー、型番、製造の年を読み取る。
   読めたものは source を label_read とし、ラベルの枠を
   [ymin, xmin, ymax, xmax] の順で 0〜1000 に正規化して返す。
2. ラベルが無い・読めない場合は、label_unreadable とし、見た目から推した
   型番の候補を最大3つまで source を inferred として返す。
3. ラベルの型番と、正面の写真の見た目が合わないと思う場合は、確かめる事項に書く。
4. accessories の写真に写っている付属品を、名前と数で並べる。
5. 傷・汚れを、場所・種類・写真の角度・枠で並べる。
6. 写真に無い面と、暗くて見えない範囲を書く。
7. 状態の基準に照らして状態の候補を返し、理由を書く。2つに分かれれば両方を返す。
8. 説明文の下書きを、下の決まりで書く。

【説明文の決まり】
- 付属品は「写真に写っている付属品」として書く。
- 動作は、動作の確認の結果に書かれた機能だけを「確認済み」と書く。
  確認していない機能は「未確認」と書く。
- 傷は、場所と種類を書く。写っていない面については何も書かない。

【厳守事項】
- 写っていない付属品を「付属」「完備」と書かないでください。
- ラベルから読めない型番を、label_read として返さないでください。
  型番の末尾を補ったり、似た型番に直したりしないでください。
- ブランド品が本物かどうか、偽物の疑いについて書かないでください。
- 「動作良好」「目立つ傷なし」「美品」と書かないでください。
- 価格や相場について書かないでください。
- 写真に人や書類が写っていても、それについては何も書かないでください。

「型番の末尾を補わない」を明記しないと、似た型番に寄せます。 ラベルの末尾がかすれていると、AIは知っている型番の中から近いものを選んで埋めます。末尾の1文字で色や容量が変わる製品では、その埋めた1文字が返品の理由になります。

「美品」「目立つ傷なし」を禁じるのは、評価の言葉だからです。 状態は基準の候補として別の欄で返させ、説明文には場所と種類という事実だけを書かせます。

Step7

出力形式を固定する

品物ごとに、次の形の JSON で受け取ります。 source、kind、rank は enum で決まった文字列に絞ります。

{
  "item_id": "",
  "identification": {
    "maker": "",
    "product_name": "",
    "model_candidates": [
      { "model_no": "", "source": "label_read | inferred | label_unreadable", "label_box": [120, 300, 180, 620] }
    ],
    "year": ""
  },
  "accessories_seen": [ { "name": "リモコン", "count": 1 } ],
  "defects": [
    { "angle": "front", "location": "天面", "kind": "scratch | dent | crack | discoloration | stain | rust | unclear", "box_2d": [410, 220, 470, 380] }
  ],
  "not_visible": [ "底面" ],
  "rank_candidates": [ { "rank": "S | A | B | C | junk", "reason": "" } ],
  "check_points": [ "ラベルの型番と正面の色が合わない" ],
  "description_draft": ""
}

1つ目の理由は、source で型番の扱いを機械的に分けられることです。 プログラムは label_read の型番だけを過去の出品の記録と照らし、一致すれば「確認:写真で一度見る」、一致しなければ確かめる事項に回します。inferred の型番は、出品の文の型番の欄に入れず、候補として担当の画面に出すだけにします。

2つ目は、accessories_seen と付属品の標準の一覧で差が出せることです。 型番が確定した後に、標準の一覧から写っている付属品を引き、「写っていない標準の付属品」を担当に見せます。 欠品と書くか、付属品の写真を撮り直すかは担当が決めます。

3つ目は、rank_candidates を確定の欄と分けて残せることです。 AIの候補と担当の確定が食い違った品物を毎週集めると、どの傷の読み方が人によって揺れているかが分かり、状態の基準の例を足す材料になります。

response_format の schema には、次のように値を絞った形を入れます(抜粋)。

{
  "type": "object",
  "properties": {
    "identification": { "type": "object", "properties": {
      "model_candidates": { "type": "array", "maxItems": 3, "items": { "type": "object",
        "properties": {
          "model_no": { "type": "string" },
          "source": { "type": "string", "enum": ["label_read", "inferred", "label_unreadable"] },
          "label_box": { "type": "array", "items": { "type": "integer" }, "minItems": 4, "maxItems": 4 }
        },
        "required": ["model_no", "source"] } } } },
    "rank_candidates": { "type": "array", "maxItems": 2 },
    "description_draft": { "type": "string" }
  },
  "required": ["identification", "accessories_seen", "defects", "not_visible", "rank_candidates", "description_draft"]
}

maxItems で候補の数に上限を付けておくと、推した型番が10個並ぶような返り方を防げます。

Step8

システムへ連携する

つなぎ先方式内容
在庫管理システム既存の API か、書き出したファイル出品の準備の品物、買取の記録、動作の確認の結果を取る。下書きを書き戻す
写真の保管先ファイルの読み取り管理番号の写真を取る
Gemini APIAPI呼び出し(/v1beta/interactions)型番の候補、付属品、傷、状態の候補、説明文の下書き
過去の出品の記録在庫管理システムの検索型番の照合と、付属品の標準の一覧
通販サイト既存の管理画面出品の担当が確定した内容で出品する(この構成からは書き込まない)

通販サイトへは書き込みません。 下書きをそのまま出品する経路を作ると、推した型番や評価の言葉が、担当が見る前に購入者に届きます。 在庫管理システムへの書き戻しも「出品の下書き」の欄だけにし、買取の記録には触れません。

Step9

人が確認する

出品の担当は、確かめる事項のある品物から見ます。

  1. 型番を確定する … label_read は枠の位置のラベルを写真で一度見ます。inferred と label_unreadable は、実物のラベルを見に行くか、型番を空欄のまま出品します
  2. 付属品を確定する … 写っていない標準の付属品があれば、実物を見て、欠品と書くか撮り直します
  3. 状態を確定する … 候補と理由を読み、状態の基準で決めます
  4. 確かめる事項を店長に回す … 製造番号のラベルが剥がれている、ラベルの型番と見た目が合わない、といったものは店長が見ます
  5. 下書きを直して出品する … 直した内容は記録に残ります

1番目の「型番を空欄のまま出品する」を選べるようにしておきます。 推した型番を書いて間違えるより、「型番の表示なし」と書いて写真を見てもらうほうが、返品は少なくなります。

目標は、900点をならして1点4分です。 確かめる事項の無い品物は写真と下書きを一度見て1〜2分、事項のある品物は実物を見に行くので10分前後かかります。確かめる事項のある品物が3割を超える週は、写真の撮り方か状態の基準のどちらかが崩れています。 どの店舗の、どの品目で増えているかを見て、査定の担当に戻します。

Step10

例外に対処する

起きること対応
ラベルの寄りの写真が無いAIに渡す前に印を付け、型番は inferred として扱う。査定の担当に撮り直しを頼む
ラベルがかすれて読めないlabel_unreadable。実物を見るか、型番の表示なしで出品する
ラベルの型番と見た目が合わない確かめる事項として店長に回す
製造番号のラベルが剥がれている確かめる事項として店長に回す。不正品の疑いがあるかは店が判断する
何か分からない付属品が写っているunknown_accessory として載せ、担当が実物で確かめる
動作の確認の結果が未記入下書きを作らずに査定の担当に戻す
写真が20MBを超える縮め直して呼び直す
JSON の値が enum に無い下書きを作らずに担当に回す

上から3行目までが大半を占めます。 どれもAIの精度ではなく、写真の撮り方と、実物を見に行く手順の問題です。 撮る角度の決めごとを直すほうが、指示の文をいじるより効きます。

Step11

記録を残す

  • 管理番号ごとの写真の一覧と、Gemini API が返した JSON の全文
  • 指示に入れた動作の確認の結果と、そのときの状態の基準の版
  • 出品の担当が確定した型番・付属品・状態と、AIの候補との違い
  • 店長に回した確かめる事項と、その結果
  • 出品の後の、購入者からの問い合わせと返品の理由(型番・付属品・状態のどれか)

3つ目の「AIの候補との違い」が、状態の基準を直す材料です。 同じ傷でAとBに分かれる品目が分かれば、基準に例の写真を1枚足すだけで揺れが減ります。

04実装レベルの3段階

最小構成:品物ごとに写真を手で渡し、型番の候補と付属品と傷を出させる / 1点ごとの読み取り
半自動化:上記+在庫管理システムから1時間ごとに拾い、下書きと確かめる事項を書き戻す / 読み取りと下書きの作成
本格構成:上記+過去の出品の記録との照合と付属品の標準の一覧との差、通販モールごとの文の型での書き分け / 出品の準備の全体

最小構成では点数がさばけません。 900点には使えません。確かめるための段階です。 半自動化で、1点12分が4分になり、この段階が本記事の想定です。 型番の読み取り、付属品と傷の書き出し、下書きは自動になり、担当は確かめる事項から見て確定するだけです。本格構成では、照合と付属品の差が自動になり、確かめる事項がさらに絞られます。 ただし、付属品の標準の一覧を作る手間が先に要ります。 段階を飛ばさないでください。 半自動化を1か月回すと、label_unreadable の多い品目と、状態の候補が揺れる品目が分かります。そこを撮り方と基準の例で直してから、照合を足します。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
5 名
月間件数
900 件
1件あたり現在時間
12 分
1件あたり導入後時間
4 分
現在  900件 × 12分 ÷ 60 = 180 時間/月
導入後 900件 × 4分 ÷ 60 = 60 時間/月
月間削減時間
120h
削減率
67%
年間削減時間
1,440h
年間金額換算(時間単価2,500円)
360万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 店頭と出張で買い取った家電・ブランド品・工具を、自社の通販サイトや通販モールに出品しているリユース店。買取の件数が増えて出品の担当が型番を調べ、付属品と状態を書く作業が追いつかず、出品待ちの在庫が棚にたまっている場合。出品の文の書き方や状態の付け方が担当者ごとに違い、購入者からの「説明と違う」という問い合わせが出ている場合。買取のときに決まった角度で写真を撮る運用を作れる場合。
向いていない
  1. 一点ものの美術品・骨董品・高額な時計など、専門の鑑定士が一点ずつ説明を書く品物が中心の場合。写真を撮らずに出品している、または撮る角度が決まっていない場合。月の出品が数十点で、手で書いて足りる場合。なお、ブランド品の真贋、動作の可否、買取価格と販売価格、不正品の疑いがあるかの判断は、この構成では代替できません。

07最小構成で試す方法

  1. 先月出品した品物から30点を選ぶ(うち数点は、購入者から「説明と違う」と言われたものを入れる)
  2. その30点の写真を、品物ごとに Gemini API の有料の利用枠に渡す
  3. 「ラベルから読んだ型番と、見た目から推した型番を分けてください。写っている付属品だけを並べてください。傷の場所と種類を書いてください。写っていない物は書かないでください」と指示する
  4. 出てきた型番・付属品・傷を、当時の出品の文と購入者からの問い合わせと突き合わせる

30点は必ずやってください。 プログラムを組む前に、「自社の写真の撮り方で、ラベルが読めるのか」を確かめます。

出てきた内容判断
当時の出品の文と同じ型番と付属品が出た在庫管理システムとの連携に進む
写っていない付属品を書いた、型番の末尾を補った指示の書き方で直る。構成は有効
ほとんどの型番が label_unreadable になる写真の撮り方が先。 AIの問題ではない

3行目が出ることは珍しくありません。 失敗ではなく、型番を調べるのに時間がかかっていた理由が1つ分かったということです。

08実装時につまずきやすいポイント

問題対策
推した型番が出品の文に入るsource で分け、inferred は型番の欄に入れない
ラベルの末尾を似た型番で補う指示で禁じ、ラベルの枠を見て人が確かめる
写っていない付属品を「付属」と書く写っている付属品だけを並べさせる。 標準の一覧との差は型番の確定後に出す
「美品」「動作良好」と書く評価の言葉を禁じ、動作は査定の記録だけを根拠にする
ラベルの寄りを縮めすぎて読めないラベルの写真だけ縮め方を変える
状態の付け方が担当ごとに揺れるAIの候補と確定の違いを毎週見て、基準に例を足す
ブランド品の真贋を書く指示で禁じる。真贋は専門の担当が実物で見る
製造番号のラベルの剥がれを見落とす確かめる事項として店長に回す
古物営業法の表示が出品のページから抜ける文の型に固定で入れ、AIに書かせない

上の2行が、この構成の失敗のほとんどです。 どちらも「型番が書いてある」という同じ見た目から出発しています。ラベルから読んだ値かどうかを欄で分けてあるかどうかで、運用に乗るかが決まります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 品物の写真、買取の記録(管理番号、品目、買取の日)、動作の確認の結果です。売り主の住所・氏名・年齢などの本人の確認の記録は、Gemini API に渡しません。

  1. 売り主の情報を渡さない … 古物営業法では、古物商は取引の都度、取引の年月日、品目と数量、古物の特徴、相手方の住所・氏名・職業・年齢などを帳簿等に記録しなければならないとされています。出品の下書きに要るのは品目と特徴だけで、相手方の記録はプログラムの側で外してから扱います
  2. 写真に人と書類を写さない … 査定の机の上の書類や売り主の手が写った写真は撮り直します。写ってしまったものは、指示で書かせないようにしてあります
  3. 有料の利用枠で使う … 規約では、有料のサービスでは、プロンプトと応答(画像などのファイルを含む)が製品の改善に使われないとされています。一方で、禁止された使い方の検知などのために限られた期間記録されることも書かれています
  4. 真贋と不正品の疑いを AI に寄せない … 真贋は専門の担当が実物で見ます。不正品の疑いがあるかの判断と、警察官への申告は店が行います
  5. 出品のページの法定の表示を固定する … 氏名又は名称、許可をした公安委員会の名称、許可証の番号は文の型に固定で入れます
  6. 帳簿等とAIの記録を分けて持つ … 古物営業法では、帳簿等は最終の記載をした日から3年間、営業所に備え付けるなどして保存することとされています。AIの返した JSON や下書きは帳簿等ではありません。 帳簿等の「特徴」の欄は査定の担当が書いたものを正とし、AIの出力で書き換えないでください

誤りが起きた場合のリスクは、違う型番や写っていない付属品を書いて返品になることと、評価の言葉で状態を良く見せて問い合わせになることの2つです。 どちらも、写真から言えることだけを書かせる設計で防げます。

10まず何から始めるか

1週目:写真の角度の決めごとを作る

品目ごとに、正面・背面・ラベルの寄り・付属品を並べた写真・傷の寄りの撮り方と、ラベルの位置の例の写真を作り、査定の担当に渡します。出品の多い家電と電動工具から始めます。

2週目:30点で試す

先月の出品から30点を選び、写真を Gemini API に渡して型番・付属品・傷を出させます。「説明と違う」と言われた品物で、何が出ていたかを最優先で見ます。

3週目:状態の基準に例を足す

S・A・B・C の境目になる傷の写真の例を、品目ごとに数枚ずつ状態の基準に足します。AIに渡す基準も、担当が見る基準も同じものにします。

4週目:在庫管理システムから下書きまでをつなぐ

「出品の準備」の品物を1時間ごとに拾い、下書きと確かめる事項を書き戻すところまで作ります。この時点では状態の候補を出さず、型番と付属品と傷だけを見ます。

2か月目: 状態の候補を足し、AIの候補と担当の確定の違いを毎週集めます。3か月目以降: 過去の出品の記録との照合と付属品の標準の一覧を足し、1点12分が何分になったかを実測します。「説明と違う」という問い合わせの理由が型番・付属品・状態のどれかで数えられ、撮り方と基準が直るようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-15/最終更新:2026-10-15
確認した内容情報源確認日
画像の説明・質問への回答・分類・物の検出に使えること。対応する形式(PNG、JPEG、WEBP、HEIC、HEIF)。画像を直接入れる場合にリクエスト全体が20MBまでであること。1つのリクエストに複数の画像を入れられること。枠が [ymin, xmin, ymax, xmax] の順で 0〜1000 に正規化されること。画像のトークンの換算(384ピクセル以下は258トークン、それより大きいものは768×768の区画ごとに258トークン)Gemini API: Image understanding2026-10-15
構造化出力が response_format で mime_type を application/json にし、schema にスキーマを入れる形で /v1beta/interactions に送ること。enum、minItems、maxItems が使えること。値はアプリ側で検証するよう書かれていることGemini API: Structured output2026-10-15
有料のサービスではプロンプトと応答(画像などのファイルを含む)が製品の改善に使われないこと。禁止された使い方の検知などのために限られた期間記録されること。18歳以上であることが利用の条件であることGemini API Additional Terms of Service2026-10-15
インターネットで取引するときに氏名又は名称・許可をした公安委員会の名称・許可証の番号を公衆の閲覧に供すること(第12条第2項)。買い受けようとする古物に不正品の疑いがあると認めるときは直ちに警察官に申告すること(第15条第3項)。取引の都度、取引の年月日、品目及び数量、特徴、相手方の住所・氏名・職業・年齢などを帳簿等に記録すること(第16条)。帳簿等を最終の記載をした日から3年間保存すること(第18条)e-Gov 法令API: 古物営業法2026-10-15

出品のページの表示、不正品の疑いへの対応、帳簿の付け方は、管轄の警察署の案内と自社の手順に沿って決めてください。 本記事は公開の資料で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1607)についてのご相談はこちらから。

AI活用について相談する
目次