工程や受入検査で出た不適合の報告を Power Automate で受け、不適合の種類と重大度を分けて担当と処置の期限を決め、似た過去の不適合を添える

処理の起点を決める

不適合報告の行が作られたことを起点にします。 When an item is created は新しい行ごとに動くので、夜勤帯に起票された報告も、その場で重大度と期限が付きます。 1日1回の定時実行にはしません。まとめて処理すると、受入で保留にした部品の処置が1日ずつ遅れます。

フローは3本に分けます。 1本目は、起票を受けて分類し、台帳を更新してカードを出すフロー。2本目は、毎朝8時に台帳を見て、処置の決定の期限が前日か当日なのに「処置の決定」が空の行を担当へ知らせるフロー。3本目は、毎月の初めに前月の重大度別・種類別・仕入先別の件数を品質管理課長へ送るフローです。1本目はカードの返事を待つあいだ止まっているので、催促の役は別のフローに持たせます。

「現象」「発見の段階」「品番」は必須の列にします。 空に近い行でフローが動くのを防ぐためです。

入力データを集める

質を決めるのは、影響の区分の定義表です。 「機能・組付け」と「外観のみ」の境目を、「相手部品と組み付く面か」「図面の重要寸法の記号が付いているか」のように、記述から判断できる言葉で書きます。経験の長い担当者の判断を言葉にする作業で、第3章の（a）のぶれは、ここで止めます。

「影響の確認待ち」の区分を必ず作ります。 現象は書かれているが、機能に影響するかがまだ分からない報告は少なくありません。この区分が無いと、AIはどちらかに寄せて選びます。確認待ちは重大度の表で一段上の扱いにし、確かめてから下げます。

過去の候補は、フローの側で数を絞ってから渡します。 品番が同じものと、仕入先が同じで種類が近そうなものを合わせて最大30件にします。それより多いときは発生日の新しいものから取ります。

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

Get items の Filter Query には OData の条件式を書けます。 「品番が同じ、または仕入先コードが同じ」かつ「発見日が24か月以内」かつ「自分自身の行ではない」で絞ります。台帳の全件を読んでからフローの中で絞ると、5年分の行で遅くなります。 Top Count で取る件数の上限も決めます。

写真はAIに渡しません。 添付の枚数だけを記録し、判定者がカードから開いて見ます。写真から傷の程度を推し量らせると、記述に無い事実が台帳に入ります。

過去の候補は、1件ごとに番号・発生日・種類・現象の先頭100文字・処置・是正の有無だけにして渡します。

AIへ渡す前に整形する

1. チェック欄の確認 … 「出荷済み」「客先で発見」「安全・法規に関わる」のどれかにチェックがあれば、AIを通さずに重大度Aとし、品質管理課長へ先に知らせます。 そのあとで分類は通常どおり行います
2. 空に近い報告の確認 … 現象が10文字未満なら、AIに渡さず起票者へ聞き返します
3. 品番と仕入先コードの形の確認 … 品番の桁と仕入先コードの形が決まりに合わないものは「形が合わない」と印を付け、AIに直させません
4. 発見の段階と仕入先の整合 … 受入の不適合で仕入先コードが空なら、起票者へ聞き返します。工程の不適合で仕入先コードがあれば「購入品起因の疑い」として残します
5. 過去の候補の絞り込みと要約 … 上の取得方法のとおり、最大30件にして短い表にします
6. 起票者名の扱い … 起票者の氏名はプロンプトに渡さず、台帳にだけ残します

1番目をAIの前に置くのは、この3つが重大度を決める事実そのものだからです。 AIの区分がどうであれ、重大度はAより下がりません。

AIに処理させる

させるのは、報告の記述を定義表に照らして種類と影響の区分を1つずつ選び、根拠の文を写すことと、過去の候補から似たものを選んで共通点を書くことです。

影響の区分の右端を pending_check にしているのが要です。 「端面にへこみ」とだけ書かれた報告で、組み付く面かどうかが書かれていなければ、機能とも外観とも決められません。決められないことを値として返させれば、重大度の表がそれを一段上で扱います。

4行目も大事です。 AIに「再発か」を聞くと、似た現象の記述があるだけで再発と書きます。再発の判定は「同じ品番か同じ仕入先で、同じ種類が12か月に2件以上」という数え方で決め、AIの共通点の記述は判定者が読む材料にとどめます。

指示内容を固定する

あなたは部品メーカーの品質管理課で、不適合報告を台帳に登録する立場です。
報告に書かれていることだけを使って、決まった項目を埋めてください。
推測で埋めないでください。

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

【影響の区分の選び方】
- 下の「影響の区分の定義表」から1つだけ選んでください。
- 機能・組付けに影響するか、外観だけかが報告から決められない場合は、
  pending_check を選んでください。どちらかに寄せないでください。
- 「重要寸法」「保安部品」「法規」などの語が報告にあれば、
  その文を critical_mention にそのまま写してください。

【根拠】
- 種類と影響の区分のそれぞれについて、選んだ根拠の文を報告から
  そのまま写してください。写せる文が無い場合は unclassified にしてください。

【似た過去の不適合】
- 下の「過去の不適合の候補」から、今回の報告と似ているものを最大3件選び、
  番号と共通点を書いてください。共通点は「同じ品番」「同じ仕入先」
  「同じ現象」「同じ工程」のように、候補に書かれている事実で書いてください。
- 似ているものが無ければ、空の配列にしてください。
  件数を埋めるために似ていないものを選ばないでください。
- 再発かどうか、是正が必要かどうかは書かないでください。

【厳守事項】
- 重大度、処置（特別採用・選別・返品・廃却）、原因の推定は書かないでください。
- 品番・ロット番号・数量は、報告のとおりに写してください。
  桁を補う、記号を直すことをしないでください。
- 候補に無い過去の不適合の番号を書かないでください。
- Don't include JSON markdown in your answer.

【種類の定義表】{type_definitions}
【影響の区分の定義表】{impact_definitions}
【報告】発見の段階：{stage}／品番：{part_no}／ロット番号：{lot_no}
　　　　仕入先コード：{supplier_code}／数量：{qty}／発見日：{found_on}
　　　　現象：{phenomenon}
　　　　調べたこと：{investigation}
【過去の不適合の候補】{candidates}

「迷ったときに近そうな区分を選ばない」と「どちらかに寄せない」を明記しないと、必ずどこかに入ります。 モデルは何か選ぶほうを好み、新しい現象ほど既存の区分に押し込まれて台帳から見えなくなります。

「件数を埋めるために似ていないものを選ばない」も同じ理由です。 最大3件と書くと、3件そろえようとして共通点の薄いものまで選びます。判定者は3件とも読むので、関係の無い1件が確認の時間を増やします。

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

出力形式を固定する

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

{
  "nc_type": "寸法 | 外観 | 材質 | 機能 | 員数 | 表示 | 梱包 | unclassified",
  "nc_type_evidence": "",
  "impact": "safety_legal | function_fit | appearance_only | pending_check",
  "impact_evidence": "",
  "critical_mention": "",
  "similar_cases": [
    { "nc_no": "", "common_points": "" }
  ],
  "part_no_as_written": "",
  "lot_no_as_written": "",
  "qty_as_written": ""
}

JSON にする理由の1つ目は、重大度を表で決められることです。 impact と発見の段階を、フローの条件分岐で表に当てはめます。

2つ目は、期限を規則で出せることです。 重大度ごとに「暫定処置」「処置の決定」「是正の要否の判断」の稼働日数を期限の規則に持たせ、稼働日カレンダーで数えて日付にします。期限が空のまま担当へ回ることが、なくなります。

3つ目は、similar_cases を照合できることです。 返ってきた nc_no が候補の番号に含まれるかを確かめ、含まれないものを捨てます。そのうえで、再発の条件（同じ品番か同じ仕入先で、同じ種類が12か月に2件以上）はフローが台帳の件数で判定し、 当たれば「是正の要否」を「要検討」にします。AIの共通点の記述は判断の材料で、判定ではありません。

システムへ連携する

カードには、報告の原文、AIが選んだ種類と影響の区分とその根拠の文、表から出た重大度とその理由、期限、似た過去の不適合の番号と共通点を並べます。 選択欄で種類・影響の区分・重大度を直せるようにし、ボタンは「確定」と「修正して確定」の2つです。過去の不適合の番号は台帳の行へのリンクにして、カードから開けるようにします。

チャネルとカードの大きさに制約があります。 Teams の公式の説明では、プライベートチャネルへの投稿は現在できないとされているので、判定者のチャネルは標準チャネルにします。カードを含むメッセージは約28KBが上限とされているので、報告の原文は先頭だけを載せ、台帳へのリンクを付けます。

生産管理システムと仕入先へは書き込みません。 受入の保留の解除やロットの止めは品質管理課が生産管理システムで行い、仕入先への処置の要求は購買課が出します。この構成が出すのは、誰がいつまでに決めるかまでです。

人が確認する

人が確かめるのは、次の3つの場面です。

1. 判定者がカードを開いたとき（全件） … 種類・影響の区分・重大度・期限を確かめ、違えば直して確定します。 似た過去の不適合は、番号のリンクから1件ずつ開いて確かめます
2. 重大度Aの先行連絡を受けた課長 … チェック欄に当たった報告を、分類の結果を待たずに見ます
3. 再発の条件に当たった報告 … 「是正の要否」が「要検討」になったものを、購買課と品質管理課で仕入先へ是正を求めるかを決めます

全件を確定するのは、誤った重大度Cのまま流れると期限が10稼働日先になり、重大な不適合が2週間放置されるからです。

判定者が直した記録を毎週数えます。 種類と影響の区分のどちらを、どこからどこへ直したかを集計すると、定義表のどの境目が言葉になっていないかが分かります。

目標は、180件をならして1件6分です。 カードを読んで確定するだけの報告は数分、似た過去の不適合を開いて読む報告や、区分を直す報告は10分ほどかかります。6分を大きく超える月は、定義表か重大度の表が現場の実態とずれています。

例外に対処する

記録を残す

• 起票された行の項目と、起票の時刻
• AIに渡した入力（定義表の版と、渡した候補の番号の一覧を含む）と、返ってきたJSONの全文
• 表から出た重大度と、どの条件でその重大度になったか（チェック欄・影響の区分・発見の段階・重要寸法の記述）
• 期限の計算に使った規則と稼働日カレンダーの版
• 判定者が直した項目と、直す前後の値
• 捨てた similar_cases の番号、再発の条件に当たったかどうか

2つ目で候補の番号の一覧を残すのは、「似た不適合が無い」と出たときに、探した範囲を後から確かめるためです。 候補に入っていなかったのか、入っていたのに選ばれなかったのかで、直す場所が違います。前者は Filter Query の条件、後者はプロンプトです。

5つ目は、定義表を育てる材料です。 判定者の修正を区分ごとに数え、多いところから定義表の「含めないもの」を足します。