製造現場から Microsoft Forms で上がる工程内の不良の報告を、不良の種類・工程・緊急度で分類し、品質管理と生産技術の担当に振り分ける

処理の起点を決める

フォームの回答が送信されたことを起点にします。 When a new response is submitted は回答の送信ごとに動くので、夜勤帯の報告も、上がったその場で振り分けられます。 1日数回の定時実行にはしません。まとめて処理すると、第3章の（b）がそのまま残ります。

フローは2本に分けます。 1本目は、報告を受けて分類し、台帳に書いてカードを出すフロー。2本目は、15分ごとに台帳を見て、緊急度 S・A の報告で「未受付」のまま決めた時間を過ぎたものを、もう一度知らせるフローです。1本目でカードの返事を待っているあいだは、そのフローが止まっているので、再通知の役は別のフローに持たせます。

同じ報告が二重に送られることがあります。 タブレットで送信を2回押したときです。台帳に、ライン・品番・ロット番号・発見時刻が同じ行が直近10分以内にあれば、新しい行を作らずに「重複の可能性」の印だけを付けます。 本当に別の不良が同じ時刻に2件出ることもあるので、消さずに印を付けて人が見ます。

入力データを集める

質を決めるのは、分類の定義表です。 「外観」「寸法」「異物」「組付け」「機能」「設備起因の疑い」「材料起因の疑い」の7区分ほどに絞り、それぞれに「含めないもの」を書きます。 「バリは外観。ただし寸法の公差を外れていると書かれていれば寸法」のような境目を、経験の長い担当者に書いてもらいます。これが第3章の（c）の目利きを、紙に移す作業です。

工程マスタには、現場での呼び方を入れます。 報告には「研削」とは書かれず「3番の研削盤」や「仕上げ」と書かれます。呼び方の一覧が無いと、AIが工程を当て推量で埋めます。

直近の報告は、連続しているかを見るために渡します。 同じライン・同じ品番で同じ種類の報告が続いていれば、1件ずつは軽微でも工程に何かが起きている兆しです。AIに件数を数えさせず、フローの側で台帳を引いて数を渡します。

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

Get items は Filter Query に OData の条件式を書けます。 「ラインが L2 で、品番が同じで、発見時刻が24時間以内」のように絞ってから件数を数えます。台帳を全件読んでからフローの中で絞ると、行が増えるにつれて遅くなります。 Top Count で取る件数の上限も決めておきます。

定義表と工程マスタは、毎回まるごとプロンプトに入れます。 7区分と工程の一覧なら短い表で済み、定義表を直せば翌回の分類から効くようにしておけます。プロンプトの文面に区分を書き込んでしまうと、区分を直すたびにプロンプトの保存し直しが要ります。

AIへ渡す前に整形する

1. 安全の語の照合 … 「けが」「指」「挟まれ」「発煙」「火花」「異臭」「漏れ」などの語の一覧と自由記述を照らし、当たればAIを通さずに最優先の連絡を出します。 語の一覧は安全衛生の担当と決めます
2. 空の報告の確認 … 自由記述が空か数文字しか無いものは、AIに渡さずに振り分けの担当者へ回します
3. 工程の呼び方の置き換え … 工程マスタの呼び方の一覧で、報告の工程欄を正式な工程名に置き換えます。置き換えられなかったものは原文のまま渡します
4. ロット番号の形の確認 … 品番ごとの決まった形（桁数・先頭の記号）に合わないものは「形が合わない」と印を付けます。AIに直させません
5. 直近の報告の件数 … 同じライン・品番・種類候補の直近24時間の件数を数え、プロンプトに渡します
6. 個人名の扱い … 報告者の氏名はプロンプトに渡さず、台帳にだけ残します

1番目をAIの前に置くのが、いちばん大事です。 安全に関わる報告は、AIの応答を待つ数十秒も惜しい報告です。語が当たれば先に知らせ、そのあとでAIに分類させます。 語の一覧から漏れた書き方は、AIの側で safety_mention として拾い、二重に網をかけます。

AIに処理させる

させるのは、報告文から決まった項目を写し出し、定義表に照らして不良の種類を1つ選び、その根拠の文を書き出すことです。

右端の列で、「書かれていない」を値として持たせます。 出荷済みかどうかが書かれていない報告で false を返すと、緊急度の規則が「出荷済みではない」と読みます。書かれていないことと、出荷済みでないことは違います。 not_stated なら、規則の側で「確認が要る」として一段上げられます。

1行目が、この構成の中心です。 AIに緊急度を聞くと、「少し気になる程度ですが、念のため」と書かれた報告を低く出します。ところが現場は、気になったときほど控えめに書きます。 事実だけを写させれば、言い回しに左右されません。

指示内容を固定する

あなたは製造工場の品質管理課で、工程内の不良の報告を受け付ける立場です。
報告文に書かれていることだけを使って、決まった項目を埋めてください。
推測で埋めないでください。

【不良の種類の選び方】
- 下の「分類の定義表」の区分から1つだけ選んでください。
- 定義表の「含めないもの」に当たる場合は、その区分を選ばないでください。
- どの区分にも当てはまらない、または迷う場合は unclassified にしてください。
  迷ったときに近そうな区分を選ばないでください。
- 選んだ根拠の文を、報告文からそのまま evidence に写してください。
  写せる文が無い場合は unclassified にしてください。

【発生工程の選び方】
- 下の「工程マスタ」の工程名から選んでください。
- 報告文に工程が書かれていなければ unknown にしてください。
  品番やラインから工程を推測しないでください。

【事実の写し出し】
- shipped_lot：出荷済み・客先へ納入済みと書かれていれば yes、
  出荷前・社内在庫と書かれていれば no、書かれていなければ not_stated。
- consecutive：連続している、何個も出ている、という記述があれば
  その文を写してください。無ければ not_stated。
- equipment_mention：異音・振動・停止・警報・油漏れなど、設備の状態に
  ついての記述を写してください。無ければ空にしてください。
- safety_mention：けが・挟まれ・発煙・火花・異臭など、人の安全や
  火災に関わる記述を写してください。無ければ空にしてください。

【厳守事項】
- 緊急度、急ぐべきかどうかは書かないでください。
- 原因の推定、処置の提案、出荷の可否は書かないでください。
- ロット番号・品番・数量は、報告のとおりに写してください。
  桁を補う、記号を直すことをしないでください。
- 書かれていないことを「無い」と書かないでください。
  書かれていない場合は not_stated です。
- Don't include JSON markdown in your answer.

【分類の定義表】{definitions}
【工程マスタ】{processes}
【報告】ライン：{line}／工程欄：{process_text}／品番：{part_no}
　　　　ロット番号：{lot_no}／数量：{qty}／発見時刻：{found_at}
　　　　状況：{situation}
【同じライン・品番の直近24時間の報告】{recent_summary}

「迷ったときに近そうな区分を選ばない」を明記しないと、いつもどこかの区分に入ります。 モデルは何か選ぶほうを好みます。新しい種類の不良ほど既存の区分に押し込まれ、台帳から見えなくなります。

「書かれていないことを『無い』と書かない」も同じ理由です。 出荷済みかどうかの欄が空のとき、何も言わなければ no で埋めます。not_stated という逃げ道を用意して、そこへ誘導します。

最後の英文の1行は、公式の案内に合わせたものです。 JSON が作れないというエラーが出るとき、この一文を足すよう案内されています。

出力形式を固定する

次の形のJSONで受け取ります。 AI Builder のプロンプトの出力を JSON にし、例を書き換えて Custom の形に固定します。

{
  "defect_type": "外観 | 寸法 | 異物 | 組付け | 機能 | 設備起因の疑い | 材料起因の疑い | unclassified",
  "process": "",
  "evidence": "",
  "facts": {
    "shipped_lot": "yes | no | not_stated",
    "consecutive": "",
    "equipment_mention": "",
    "safety_mention": ""
  },
  "lot_no_as_written": "",
  "qty_as_written": ""
}

JSON にする理由の1つ目は、緊急度を規則で決められることです。 facts の各項目を、フローの条件分岐でそのまま読めます。

2つ目は、Custom の形に固定しておけることです。 Auto detected のままだと、プロンプトを試すたびに形が検出し直されます。保存した形が実行時に使われ、入力が変わっても形は変わりません。 後段の条件分岐が、項目名の変化で壊れなくなります。

3つ目は、facts を後から読み直せることです。 緊急度の規則を変えたとき、過去の報告の facts に新しい規則を当て直せば、「新しい規則ならどれが S だったか」を数えられます。 AIに緊急度を書かせていたら、この見直しはできません。

システムへ連携する

カードには、報告の原文と、AIが写した evidence、緊急度とその理由になった条件を並べます。 ボタンは「受ける」「担当違い」の2つと、不良の種類を直す選択欄を置きます。担当が開いた画面だけで、受けるかどうかを決められるようにします。

チャネルの選び方に制約があります。 Teams の公式の説明では、プライベートチャネルへの投稿は現在できないとされています。振り分け先のチャネルは標準チャネルにします。また、カードを含むメッセージは約28KBが上限で、超えると失敗するとされているので、報告の原文が長いときは先頭を切って台帳へのリンクを付けます。

生産管理システムには書き込みません。 ロットの保留や出荷の停止は、品質管理課が生産管理システムの画面で行う判断です。この構成が出すのは、誰が受けるべきかの連絡までです。

人が確認する

人が見るのは、次の3つの場面です。

1. 振り分け先の担当がカードを開いたとき … 自分の持ち分かと、不良の種類が合っているかを見ます。違えば「担当違い」を押すか、種類を直します
2. 保留の報告 … unclassified か根拠の無いものは、振り分けの担当者が原文を読んで決めます
3. 担当違いと返された報告 … 振り分けの担当者が、正しい先へ回します。担当表のどこが違っていたかを記録します

品質管理課の受付が全件を見直すことはしません。 全件を見直す設計にすると、第10章の20.0時間に収まりません。その代わり、担当が直した種類と担当違いの件数を毎週数えます。 数が多い区分は、定義表の「含めないもの」が足りていません。

S の報告だけは、課長にも同時に届けます。 安全と出荷済みのロットに関わる報告は、担当1人の判断に任せない運用にします。

目標は、600件をならして1件2分です。 カードを開いて受けるだけの報告は1分もかかりませんが、保留と担当違いは原文を読み直すので数分かかります。2分を大きく超える月は、定義表か担当表が現場の実態とずれています。

例外に対処する

上の3行がいちばん大事です。 どれも「AIに決めさせない」ための行で、安全と、分類できない報告の扱いを、正常系と同じくらい丁寧に作ります。

記録を残す

• フォームの回答ID、報告の原文、受け取った時刻
• AIに渡した入力（定義表と工程マスタの版を含む）と、返ってきたJSONの全文
• 当てはめた緊急度と、どの条件に当たってその緊急度になったか
• 振り分け先と、カードを出した時刻、受けた時刻、受けた人
• 担当が直した不良の種類と、担当違いの記録
• 再通知の回数と時刻

2つ目で定義表の版を残すのは、区分を後から直すためです。 区分を直すと過去の分類の意味が変わり、どの版の定義で分けたかが残っていないと、月ごとの件数を比べられません。

5つ目が、定義表を育てる材料です。 担当が直した種類を区分ごとに数えると、どこの境目が曖昧かが分かります。経験の長い担当者の目利きを、少しずつ定義表に写していく記録です。