製造現場で見つけた不良品を写真で見分けて、不良区分と発生工程の記録にする

処理の起点を決める

SharePointの不良記録ライブラリにファイルが作成されたことを起点にします。Power Automate の SharePoint コネクタには「ファイルの作成時 (プロパティのみ)」トリガーがあります。

なお、同じコネクタには「フォルダーにファイルが作成されたとき」というトリガーもありますが、こちらは非推奨とされており、推奨される代替は「ファイルの作成時 (プロパティのみ)」です。 新しく作る場合は非推奨のほうを選ばないでください。

トリガーの動き方にも注意が要ります。Power Automate は、設定したライブラリの変更を定期的にチェックする作りです。多くの場合は変更から数分以内に動きますが、続けて撮影されたときに、1回の実行で複数の変更をまとめて拾うことがあります。 1回の実行で1枚だけを処理する前提で作ると、取りこぼします。

入力データを集める

不良区分の定義に「見本写真」を添えることが、この構成の成否を分けます。 「打痕」という語だけを渡しても、自社が何を打痕と呼んでいるかは伝わりません。各区分について3〜5枚の見本写真を用意し、判定のときに一緒に渡します。

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

写真： タブレットの標準のカメラで撮り、SharePointのライブラリへ保存します。専用アプリを作らなくても、共有のショートカットで足ります。

画像の受け渡し： Claude の画像入力では、base64で埋め込む、URLで参照する、Files APIにアップロードして file_id で参照する、の3つの方法があります。見本写真のように繰り返し使う画像は、Files APIにアップロードして file_id で参照するほうが、毎回base64を送るより軽くなります。

工程の通過実績： ロット番号から生産管理システムのAPIまたは日次エクスポートを参照します。リアルタイムである必要はありません。

過去の不良記録： 「品番Aの打痕は、過去60件中48件が研磨工程で発生している」という集計表を月1回作り、これを候補の根拠にします。

AIへ渡す前に整形する

1. 画像の枚数と向きの確認 … 2枚そろっているか、真っ暗・真っ白でないかを見ます。撮り直しが必要なら、その場でタブレットに表示します
2. 画像サイズの調整 … 撮ったままの写真は大きすぎます。Claude の画像入力では、1枚あたり10MB（base64）が上限で、最大寸法は8000×8000 pxです。 これを超えないよう、送る前に縮小します
3. 枚数の管理 … 1リクエストに含める画像は、見本写真を含めて20枚以下に抑えます。20枚を超えると1枚あたりの寸法制限が厳しくなるため、すべての画像を2000px以下にするか、20枚以下に収める必要があります
4. 圧縮の程度 … JPEGで強く圧縮すると、細かい傷が消えます。圧縮の設定を決めたら、実際に送った画像を目で見て確かめてください
5. 品番とロットの妥当性確認 … バーコードの読み取り誤りを検出します。存在しない品番なら、その場でやり直させます

AIに処理させる

AIと従来の処理で役割を分けます。

従来の処理にさせること： 品番・ロットからの工程の引き当て、過去実績の集計、記録票の組み立て。

AIにさせること：

AIに不良の個数を数えさせません。 Claude は画像内の物体のおおよその数を答えられますが、特に小さい物体が多数ある場合、常に正確とは限りません。 個数は作業者が入力します。

発生工程の特定もAIにさせません。 AIが出すのは「不良部がどこにあるか」という観察です。そこから工程を推定するのは、過去実績の集計と工程の順番を使った従来の処理が行います。

指示内容を固定する

あなたは製造業の品質管理を支援する立場です。
不良品の写真を見て、社内の不良区分のどれに当たるかの候補を挙げてください。

【厳守事項】
- 不良かどうかの判定はしないでください。すでに人が不良と判断したものです。
  区分の候補を出すことだけが役割です。
- 候補は最大3つまで、確からしい順に挙げてください。
  1つに断定しないでください。
- 不良の個数を数えないでください。個数は作業者が入力します。
- 見本写真にない区分を新しく作らないでください。
  どれにも当てはまらない場合は "unclassified" を返し、
  その理由を reason に書いてください。
- 位置は、製品のどの部分かを言葉で書いてください
  （例：左上のフランジ部の縁）。座標は書かないでください。
- ピントが合っていない、不良部が写っていない場合は
  retake_needed を true にし、何を撮り直すべきかを書いてください。
- 見えていないことを推測で書かないでください
  （裏面の状態、内部の状態など）。

Image 1: 全体像
Image 2: 不良部の近接

【社内の不良区分と見本写真】
{defect_classes_with_samples}

【この品番の情報】
{product_info}

画像を先に、テキストを後に置いてください。 画像を先に置く形が、この用途では扱いやすくなります。

「座標を書かせない」のは意図的です。 Claude の座標や位置の出力は近似であり、そのまま使うものではありません。言葉での位置なら、作業者が読んで確かめられます。

出力形式を固定する

{
  "candidates": [
    {
      "defect_class": "",
      "confidence": "high | medium | low",
      "reason": ""
    }
  ],
  "location_description": "",
  "observation": "",
  "retake_needed": false,
  "retake_reason": "",
  "unclassified": false
}

記録票は、後段の処理がこれと品番・ロット・数量を組み合わせて作ります。

{
  "product_no": "",
  "lot_no": "",
  "defect_class": "",
  "quantity": 0,
  "suspected_process": [
    { "process": "", "basis": "past_record | position | order", "count": 0 }
  ],
  "photo_urls": [],
  "recorded_by": "",
  "recorded_at": ""
}

suspected_process に basis（根拠）を持たせます。「過去60件中48件がこの工程」という根拠が見えれば、作業者が納得して選べます。 根拠のない候補は選ばれません。

システムへ連携する

生産管理システムへの登録は、作業者が候補を選んだ後に行います。 AIの候補をそのまま登録する構成にしません。品質記録は、後から対策の根拠になるものです。誤った区分が自動で積み上がると、集計そのものが信用できなくなります。

写真は品番・ロットで検索できる形で保管します。 ファイル名に「日付_品番_ロット_連番」を入れるか、ライブラリの列にメタデータとして持たせます。これをしないと、後から見返せません。

人が確認する

全件、作業者が区分を選びます。

理由は2つあります。1つは、品質記録が対策の根拠になるためです。誤った区分が積み上がると、対策の方向を誤ります。もう1つは、現場の人が自分で選んだ記録のほうが、後から参照されるためです。

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

• 候補を3つだけ、大きなボタンで表示する
• 候補にない場合の「一覧から選ぶ」を1タップで開けるようにする
• retake_needed が true なら、区分の選択より先に撮り直しを促す
• 発生工程の候補に、根拠（過去実績の件数）を添える
• 選んだ後、確認画面を挟まずに登録を完了させる

確認画面を挟まないことが重要です。 現場の操作は1回でも少ないほうがよく、選択そのものが確認になっています。

例外に対処する

記録を残す

• 撮影した写真（全体像と近接）を、品番・ロットで検索できる形で
• AIが出した候補と confidence、reason
• 作業者が選んだ区分と、AIの第1候補と一致したかどうか
• 発生工程の候補と、その根拠
• 撮り直しになった件数と理由

3つ目が精度の実測値になります。「第1候補がそのまま選ばれた割合」が7割を超えていれば、候補出しは役に立っています。 3割を切るようなら、見本写真か区分の定義を見直す合図です。

なお、Claude の画像アップロードは一時的なもので、APIリクエストの処理が終わると自動的に削除され、リクエストの期間を超えて保存されることはありません。写真の保管は自社側で行う必要があります。