ECサイトに載せる商品画像を掲載の前に点検し、背景・サイズ・写り込み・登録したカラーとの食い違いを拾って、撮り直しの依頼を作る

処理の起点を決める

受け取り用のフォルダに画像が追加されたことを起点にします。 撮影の側は1日の終わりにまとめて置くことが多いので、翌朝には全部の点検が終わっている状態を目指します。

ファイル名の決まりを最初に守ってもらいます。 SKUのコード_画像の種類_連番.jpg（例：TS1024-NV_main_01.jpg）のように、SKUと画像の種類（main：第1商品画像、sku：SKUの画像、detail：細部）がファイル名から分かる形にします。決まりに合わないファイル名は、点検に進めずに撮影の側へ戻します。ファイル名からSKUが決まらないと、色見本を引けないからです。

処理の済んだ画像は、結果ごとのフォルダへ移します。 pass は掲載の待ち、retake は撮り直しの待ち、needs_human は確認の待ちです。受け取り用のフォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、承認済みの色見本の画像です。 色見本は、商品の企画の段階で承認した色の生地や現物を、決まった照明で撮った画像です。これが無いと、カラーの判定は「ネイビーに見えるか」という名前の話になり、照明の違いで揺れます。

画像の規則は、モールと自社サイトで別の行にします。 楽天市場の第1商品画像とSKUの画像には、テキストの占有率20％以下、枠線なし、背景は単色の白か写真の背景、という基本のルールがあり、正方形で700×700ピクセル以上が推奨されています。自社サイトの決まりはこれと違うことがあるので、載せる先ごとに判定を分けます。

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

サイズの判定は、取得した数値の比較だけで済みます。 第1商品画像なら「幅と高さが同じ」「どちらも700ピクセル以上」のように、規則の表の値と比べるだけです。 生成AIには渡しません。

色見本は Files API に一度アップロードし、商品マスタに置いた場所を記録しておきます。 同じ色の商品画像を点検するたびに色見本を送り直す必要がなくなり、リクエストの大きさも商品画像の分だけで済みます。

回転の情報が0でない画像は、先に人へ回します。 撮影の機材によっては、画像の向きの情報だけが回転していて、表示の仕方で縦横が入れ替わることがあります。Gemini に渡す前に向きをそろえないと、縦長の画像を横長として判定します。

AIへ渡す前に整形する

1. ファイル名の確認 … 決まりに合わなければ撮影の側へ戻します
2. 形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF のいずれかであることを確かめます
3. 重複の検知 … 同じチェックサムの画像がすでにあれば、二重に点検しません
4. サイズと比の判定 … 規則の表の値と比べ、size_ok を付けます
5. 向きの確認 … 回転の情報が0でなければ needs_human にします
6. 大きさの確認 … 画像と指示を合わせて20MBを超えるものは、縮小した点検用の画像を作るか、Files API で渡します
7. 色見本の確認 … そのSKUの色見本が商品マスタに無ければ、色の判定だけを no_reference にします

4番目で size_ok が false の画像も、5番目以降に進めます。 サイズが足りない画像は撮り直しになりますが、同じ撮り直しで背景や写り込みも直してもらうために、全部の項目を一度に見ます。撮り直しを2回頼むことを避けます。

AIに処理させる

させるのは、画像から数値にできない6つの項目を判定し、根拠を短い文で書くことです。

右端の列の unsure が、この構成でいちばん大事な逃げ道です。 迷った画像を ok に寄せると見逃しになり、ng に寄せると撮影の側への空振りの依頼になります。迷ったものは人へ回すと決めておけば、AIはどちらにも寄せずに済みます。

文字の量は、目安の値として受け取ります。 20％のような上限の判定には、Gemini の物の検出で文字の領域の囲みの座標（0〜1000に正規化された値）を返させる方法もありますが、囲みの面積は文字の要素の占有の数え方と一致するとは限りません。 上限に近い画像は人へ回します。

3行目は、とくに守らせます。 画像と色見本が違うとき、誤っているのは画像のほうか、SKUへの割り当てのほうかのどちらかで、商品マスタの色を画像に合わせて変えることはありません。

指示内容を固定する

あなたはEC事業者の商品登録の担当で、掲載の前の商品画像を点検しています。
1枚目が点検する商品画像、2枚目が承認済みの色見本です。
画像に見えることだけで判定してください。推測で埋めないでください。

【点検する項目】
1. background ..... 背景が単色の白か、写真の背景か。影・グラデーション・グレーがかり・床の継ぎ目
2. intrusion ...... 手、ハンガー、値札・タグ、別の商品、撮影の機材、ほこり・糸くず の写り込み
3. text ........... 画像の中の文字の要素の有無と、画像全体に対するおよその割合
4. border ......... 画像の4辺を囲う線、L字の線、帯
5. color_match .... 商品の色が、2枚目の色見本と同じ色に見えるか
6. product_framing  商品が切れていないか、ピント、商品が小さすぎないか

【status の選び方】
- ok ...... 問題が見えない
- ng ...... 問題が見える。どこに何が見えるかを finding に書く
- unsure .. 画像だけでは決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 画像のサイズや縦横の比は判定しないでください。
- color_match は、色の名前ではなく、2枚目の色見本と比べて判定してください。
  登録されたカラーの名前「{color_name}」は参考です。名前に合わせて判定を寄せないでください。
- 照明や影で色が決められないときは unsure にしてください。
- finding には、画像のどこに（右下、商品の左袖、背景の上端など）何が見えるかを書いてください。
- 掲載してよいか、規約に合うかの結論は書かないでください。
- 撮影の側への依頼の文は、ng の項目について、直す場所と直し方を1文ずつで書いてください。

【SKU】{sku_code}　【商品名】{product_name}　【画像の種類】{image_type}
【この載せる先の決まり】{rules}

「名前に合わせて判定を寄せない」を明記しないと、名前のほうを答えます。 「ネイビー」と渡すと、黒に近い画像でも「ネイビーに見えます」と書きがちです。比べる相手を、名前ではなく色見本の画像に固定します。

finding に場所を書かせるのは、撮り直しの依頼の質のためです。 「写り込みがあります」ではなく「右下にタグが写っています」と書けば、撮影の側は聞き返さずに直せます。

出力形式を固定する

応答をJSONに指定し、スキーマを渡して、次の形で受け取ります。

{
  "file_name": "TS1024-NV_main_01.jpg",
  "sku": "TS1024-NV",
  "image_type": "main",
  "checks": [
    { "item": "background", "status": "ng",
      "finding": "背景の下側に床との継ぎ目の影が見える" },
    { "item": "color_match", "status": "unsure",
      "finding": "色見本より暗く見えるが、照明の差か色の違いか決められない" }
  ],
  "retake_note": "背景の下側の影が出ないよう、床との継ぎ目を外して撮影してください。"
}

checks には6項目を並べ、item は background／intrusion／text／border／color_match／product_framing です。

1つ目の理由は、status を列挙の値に限れることです。 Gemini の構造化出力は JSON Schema の一部に対応し、enum で ok／ng／unsure に限れます。 ただし公式でも、構文として正しいJSONでも、値が正しいとは限らないので、アプリの側で値を確かめるようにとされています。受け取った後、6項目がそろっているか、ng に finding があるかを確かめます。

2つ目は、AIの判定と掲載の判断を分けられることです。 ワークフローは次の規則で結果を決めます。

ng と unsure が混ざる画像は needs_human にします。 撮り直しを頼む前に、unsure の項目も人が見て、一度の依頼で全部を直してもらうためです。

システムへ連携する

撮り直しの依頼は、撮影の側ごとに1日1通にまとめます。 画像1枚ごとに送ると、撮影の側は依頼の山に埋もれます。ファイル名と retake_note を並べた一覧にし、担当者が確かめてから送ります。

件名：【撮り直しのお願い】10月6日受け取り分（スタジオA）4件

| ファイル名 | 直す項目 | 直す場所と直し方 |
|:--|:--|:--|
| TS1024-NV_main_01.jpg | 背景 | 下側の床との継ぎ目の影が出ないよう撮影してください |
| TS1024-NV_sku_01.jpg | 写り込み | 右袖の内側に値札のタグが見えます。外して撮影してください |
| BG0310-BE_main_01.jpg | サイズ | 正方形・700×700ピクセル以上でお願いします（届いたもの：1200×900） |
| BG0310-BE_detail_02.jpg | 商品の写り | 持ち手の上端が切れています。全体が入るよう撮影してください |

撮り直した画像は、同じファイル名で受け取り用のフォルダに置いてください。

サイズの行だけは、届いた画像の実際の幅と高さを添えます。 数値はファイルの情報から取ったものなので、撮影の側が書き出しの設定を直すときの手がかりになります。依頼の文の型は差し込みで作り、表の行の中身だけがAIの retake_note です。

人が確認する

人が開くのは retake と needs_human の画像だけです。 pass の画像は、掲載の待ちのフォルダのサムネイルの一覧で流し見ます。

1. needs_human を先に見る … とくに color_match が unsure のものは、現物か色見本の生地と見比べます
2. retake の根拠を確かめる … finding の場所を画像で見て、本当に直す必要があるかを決めます
3. 依頼の一覧を送る … retake_note を直す必要があれば直し、撮影の側へ送ります
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

1番目で現物を見るのは、色の判定だけは画像の中で決着がつかないことがあるからです。 画像と色見本が違って見えるとき、撮影の照明の問題か、割り当ての誤りかは、現物を見ないと分かりません。

撮り直して届いた画像は、前回の理由と並べて見ます。 点検の記録から前回の finding を引き、前回の理由が直っているかを最初に確かめます。 直っていないまま別の項目で pass になった画像を、見落とさないためです。

例外に対処する

上から2行目が最初の月に多く出ます。 色見本の画像がそろっていない商品は多く、ここが埋まるまでは色の判定が人に回り続けます。 新商品の企画の段階で色見本を撮る流れを決めておくと、この行は減っていきます。

記録を残す

• 画像のファイル名、置かれた日時、撮影の側、チェックサム
• 幅・高さ・回転と、size_ok の判定
• 生成AIの判定の結果（JSONの全文）と、使った色見本の画像
• 規則で決めた結果と、そのときの画像の規則の表の版
• 人が判定を覆した記録（項目と変えた向き）
• 撮影の側ごとの撮り直しの件数と理由

最後の行は、撮影の側との打ち合わせの材料になります。 同じ理由の撮り直しが同じ撮影の側に続くなら、撮影の手順の見直しを頼むほうが、1枚ずつ戻すより早く終わります。