出荷前の荷姿写真から荷札の不備と積付け不良を見つける

処理の起点を決める

出荷写真フォルダにファイルが作成されたことを起点にします。Power Automate の SharePoint コネクタには「ファイルが作成されたとき」トリガーが標準で用意されています。

1件の出荷につき複数枚を撮るため、1枚目が届いた瞬間に判定を始めない設計にします。撮影アプリ側で「撮影完了」を押したときにまとめてアップロードするか、フォルダに完了を示す目印のファイルを最後に置き、それをトリガーにします。1枚ずつ判定すると、まだ撮っていない面について「取扱表示が見当たらない」と誤って指摘します。

入力データを集める

最後の「判定基準の文書」が、この構成のいちばんの仕込みです。 ベテランの頭の中にある決まりを、AIに渡せる文章にする作業がここに当たります。実装よりもこの整理に時間がかかります。

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

写真： 撮影アプリからクラウドの保管先へ保存します。Power Apps を使う場合、標準のカメラコントロールで撮った画像は最大解像度が640×480ピクセルに制限されます。荷札の文字を読むにはこの解像度では足りないため、フル解像度が扱える「画像の追加」コントロールを使います。 ここは実装前に必ず確認してください。

出荷指示・マスタ： WMSまたは基幹システムのAPIから出荷番号で引きます。APIがない場合は、当日分の出荷指示を朝に一括でエクスポートし、ワークフローから参照できる場所に置く方式でも足ります。リアルタイム連携は必須ではありません。

判定基準： 品目マスタと得意先マスタから機械的に引ける条件（必要な取扱表示、最大積み段数）と、文章でしか書けない条件（「ラップは天面まで巻く」など）に分けます。前者はプログラムで条件を組み立て、後者はプロンプトに載せます。

AIへ渡す前に整形する

1. 撮影枚数と向きの確認 … 決められた枚数が揃っているかを先に数えます。足りなければ判定に入らず、撮り直しを促します。AIに「写っていないもの」を判断させると誤ります
2. 画像の縮小 … 生成AIに渡す画像は、大きすぎると自動的に縮小されます。Claude では画像を28×28ピクセルの区画に分けて数える方式で、標準の解像度帯では長辺1568ピクセル・1568トークンが上限、高解像度に対応するモデルでは長辺2576ピクセル・4784トークンが上限です。送る前に自分で縮小しておくほうが、仕上がりが読めます
3. 荷札部分の切り出し … 荷札の寄り写真は、全体写真とは別に撮ります。全体写真を縮小すると文字が読めなくなるためです
4. 明るさの確認 … 倉庫は照明の当たり方に差が出ます。極端に暗い写真は、判定に入る前にはじいて撮り直しにします
5. 人の写り込みの扱い … 作業者が写り込んだ写真は、人が入らない角度で撮り直すルールにします

AIに処理させる

OCRと生成AIで役割を分けます。

OCR（Azure AI Vision の Read）にさせること： 荷札の文字の読み取り。出荷番号、届け先名、住所、品番。ここは生成AIにさせません。文字の読み取りは専用の機能のほうが正確で、費用も安く済みます。読み取った文字列と出荷指示データの突き合わせは、AIではなくプログラムで行います。文字列が一致するかどうかの判定をAIに任せる理由はありません。

生成AI（Claude API の画像入力）にさせること：

数量はAIに数えさせません。 画像から個数を数える処理は、対象が多いと正確とは限らないことが公開資料に明記されています。梱包数はWMSの出荷指示データを正とし、AIには見た目の印象を返させるにとどめ、これだけで出荷を止める判断には使いません。

人物の特定もさせません。 誰が作業したかを写真から判定する使い方はしません。作業者の記録は、端末のログイン情報から取ります。

指示内容を固定する

あなたは出荷検品を支援する担当者です。
出荷前に撮影した荷姿の写真を見て、下の【判定項目】について
問題があるかどうかを判定してください。

【厳守事項】
- 写真から読み取れないことは判定しないでください。
  角度・明るさ・隠れなどで見えない項目は "unknown" とし、
  reason に「何が見えないか」を書いてください。
- 箱の個数を数えないでください。梱包数は別途システムから照合します。
- 写真に人が写っている場合、その人については何も記述しないでください。
- 「たぶん貼られている」で ok を返さないでください。
  ラベルの文字または図柄が実際に見えている場合だけ ok にしてください。
- 出荷を止めるかどうかの判断はしないでください。
  判定結果と根拠だけを返してください。

【この出荷の条件】
出荷番号: {shipment_no}
届け先: {customer_name}
必要な取扱表示: {required_labels}
最大積み段数: {max_stack}
この得意先の荷姿ルール: {customer_rule}

【自社の出荷基準（抜粋）】
{shipping_standard}

【判定項目】
1. 必要な取扱表示がすべて貼られているか
2. 取扱表示の向きが正しいか（天地無用が横向きになっていないか）
3. 荷札が剥がれ・折れ・重なりなく貼られているか
4. 積付けが崩れていないか
5. パレットからのはみ出しがないか
6. ラップが指定どおり巻かれているか
7. 外装に潰れ・濡れ・穴がないか

【写真】
Image 1: 正面
Image 2: 側面
Image 3: 上面
Image 4: 荷札の寄り

「読み取れないことは判定しない」「たぶんで ok を返さない」の2行が重要です。 生成AIは、低品質な写真や傾いた写真で誤った解釈をすることがあると公開資料に明記されています。見えないものを「たぶん大丈夫」と返されると、この仕組みは信用できなくなります。判定が unknown に倒れるほうが、誤った ok より安全です。

「出荷を止める判断はしない」も入れます。止めるかどうかは人が決めます。

出力形式を固定する

{
  "shipment_no": "",
  "photo_count": 0,
  "checks": [
    {
      "item": "required_label | label_direction | waybill | stacking | overhang | wrap | damage",
      "result": "ok | ng | unknown",
      "confidence": "high | medium | low",
      "image_ref": "Image 1",
      "reason": ""
    }
  ],
  "overall": "pass | review",
  "notes": ""
}

構造化した形で返させる理由は、後段が人ではなく仕組みだからです。判定結果を端末の画面に色分けして出し、ng の件数でアラートを出し、あとから「どの項目が何件 ng だったか」を集計します。文章で返させると、この3つがどれもできません。

Claude API には、返す形をJSONスキーマで指定して守らせる構造化出力の機能があります。overall に想定外の値が入って後段が止まる、といった事故を防げます。

overall は pass と review の2値にとどめ、出荷停止を意味する値は作りません。止めるのは人の判断だからです。

システムへ連携する

判定結果の戻し先は3か所です。

1番目の即時表示がこの構成の肝です。 判定に30秒かかったり、結果がメールで後から届いたりすると、担当者は待たずに積んでしまいます。撮影から判定表示までを10秒以内に収める設計にしてください。収まらない場合は、判定項目を減らします。

WMSへの書き戻しは、APIがあればAPI、なければ日次のCSV取込でも足ります。この部分は利用環境に応じた個別確認が必要です。

人が確認する

指摘があった荷物だけを人が確認します。全件確認には戻しません。

理由は、この構成が置き換えているのが「見落とし」だからです。全件を人が見直すなら、導入前と工数が変わりません。ただし、無条件に自動で通すわけでもありません。次の3つは必ず人に回します。

• ng がひとつでもある
• unknown が2つ以上ある（写真の撮り方に問題がある可能性が高い）
• 荷札のOCR結果と出荷指示データが一致しない（届け先違いは最も損害が大きい）

3番目はAIの判定ではなく、文字列の突き合わせです。ここは自動で止めてよい種類の判定なので、一致しない場合は端末に大きく警告を出します。

出荷そのものを機械的に止める仕組みは作りません。倉庫の締め切り時刻に、システムが出荷を止めると現場が回らなくなります。 警告を出し、担当者が確認して進めるか直すかを決める形にします。

例外に対処する

最後から2番目の「止めない」は、この構成の設計思想です。 AIが応答しないときに出荷が止まる仕組みは、倉庫では使われなくなります。

記録を残す

• 荷姿写真（出荷番号に紐づけて保管。保管期間は自社のクレーム対応期間に合わせる）
• OCRの読み取り結果（生の状態）
• AIの判定結果（判定項目の全件と確信度）
• 撮影者、撮影日時、確認者、確認日時
• 人が「実際は問題なかった」と判断して通した記録

最後の項目が改善の材料になります。はみ出しで ng が出るが人が毎回通している、という状況が見えれば、判定基準の書き方が現場の運用と合っていないと分かります。

判定結果は、クレーム対応の証跡にもなります。「出荷時点でこの荷姿だった」と写真と判定記録で示せるため、輸送中の損傷か出荷時の不備かを切り分けられます。