入荷した貨物の破損と員数違いを写真で記録して、運送会社への申し立て資料を作る

処理の起点を決める

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

撮影から保存までは、スマートフォンのSharePointアプリでフォルダを開いて撮る運用にします。送り状番号のフォルダを先に作り、そこに撮るのが要点です。あとからファイル名で紐づけようとすると、必ず取り違えが起きます。

入力データを集める

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

荷札の読み取り： Azure AI Document Intelligence の read モデルにファイルを渡します。このモデルは印刷文字と手書き文字を行と単語として抽出し、単語ごとに位置（バウンディングポリゴン）と確信度を返します。画像の寸法は50×50ピクセルから10,000×10,000ピクセルの範囲で扱えます。

写真の判定： Claude API に画像を渡します。画像はbase64、URL、Files APIのfile_idのいずれでも渡せます。1リクエストに複数枚を含められるため、同じ納品の3枚をまとめて1回で見せます。 公式ドキュメントでは、画像はテキストより前に置くほうが結果がよいとされており、複数枚のときは「Image 1:」のような短いラベルを各画像の前に入れて、プロンプト側から呼べるようにします。

入荷予定： WMSのAPI、または日次でエクスポートした予定データを参照します。リアルタイム連携は必須ではありません。

AIへ渡す前に整形する

1. 画像の縮小 … スマートフォンの写真はそのままだと大きすぎます。Claude API では1リクエストに20枚を超える画像を含めると各画像の寸法上限が厳しくなるため、長辺2,000ピクセル以下に縮める運用にしておくと、枚数が増えても引っかかりません
2. 向きの補正 … 横持ちで撮った写真が回転していることがあります。Exifの向き情報に従って回転させます
3. 暗い写真の除外 … 倉庫の奥で撮ると真っ暗になります。明るさが一定以下の写真は撮り直しを促し、AIに渡しません
4. 同一納品のまとめ … 送り状番号のフォルダ単位で1回の処理にします。1枚ずつ処理すると、個口数のカウントができません

AIに処理させる

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

OCRにさせること： 荷札と送り状の文字の読み取り。送り状番号、仕入先名、個口数の数字。ここは生成AIにさせません。数字の読み取りは専用モデルのほうが安定します。

生成AIにさせること：

指示内容を固定する

あなたは入荷検品の記録を支援する担当者です。
同じ納品を撮った複数の写真を見て、外装の状態を記録してください。

【厳守事項】
- 写真に写っているものだけを書いてください。
  「おそらく内部も破損している」のような推測を書かないでください。
- 個口数は数えた数をそのまま返してください。
  重なって見えない箇所があるときは、count_confidence を low にし、
  note に「奥が見えない」と書いてください。
- 破損の有無を判断できない写真は、damage を "unknown" にしてください。
  「問題なし」と書かないでください。
- 荷札の文字は、OCRの読み取り結果をそのまま引き継いでください。
  写真から読み直して書き換えないでください。
- 人が写り込んでいても、人については何も書かないでください。

【OCRで読み取った荷札】
{ocr_result}

【WMSの入荷予定】
{expected_delivery}

【この仕入先の過去の異常記録（直近12か月）】
{past_incidents}

「写っているものだけを書く」の1行が重要です。 破損の写真を見せると、生成AIは内容物の状態まで推測して書きます。申し立て文にその推測が混ざると、事実と違う主張をすることになります。

出力形式を固定する

{
  "waybill_no": "",
  "supplier_name": "",
  "carrier": "",
  "expected_packages": 0,
  "counted_packages": 0,
  "count_confidence": "high | medium | low",
  "damage": "none | found | unknown",
  "damage_items": [
    {
      "part": "",
      "description": "",
      "photo_file": "",
      "severity": "low | medium | high"
    }
  ],
  "package_count_match": "matched | mismatched | unknown",
  "label_issue": "",
  "needs_review": [],
  "note": ""
}

個口数は文字列でなく数値で返させます。文字列にすると「6個」のように単位つきで返り、後段の突合で壊れます。

システムへ連携する

確定後、検品台帳に登録します。連携方法はWMSによって3通りあります。

まずは3つめで始めるのが現実的です。 写真と記録がつながるだけで、申し立ての根拠は揃います。WMSとの連携は効果を確かめてからで間に合います。

異常ありと確定したものは、運送会社の担当者へのメールを下書きします。自動送信はしません。 申し立ては取引先との交渉の入口なので、文面は必ず人が見てから出します。

人が確認する

全件、人が確定します。

理由は2つあります。ひとつは、破損の有無が支払いや返品につながる判断だからです。もうひとつは、写真に写らない異常（内部の破損、におい、温度）があるためです。AIは写真に写っているものしか見ていません。

確認を速くするための設計が重要です。

• 確認画面で、写真と判定結果を左右に並べて表示する
• count_confidence が low、damage が unknown のものを先頭に並べる
• 予定個口数と数えた個口数が一致したものは、その旨を大きく表示する
• 異常なしのものは、1タップで確定できるようにする

月900件のうち、異常は月40件前後です。860件を速く流せる作りにしないと、削減効果が出ません。

例外に対処する

記録を残す

• 入荷写真の原本（送り状番号のフォルダに、撮影日時のまま）
• OCRの抽出結果（生の状態）
• 生成AIの判定結果と count_confidence
• 確定した担当者と確定日時
• 人が修正した項目と、修正前後の値

最後の項目が精度の実測値になります。「個口数はそのまま通るが、破損の判定は4割が修正されている」と分かれば、どこを直すべきかが決まります。

写真の保存期間は、運送約款上の申し立て期間と、社内の品質記録の保存年限の長いほうに合わせます。