不具合・トラブル報告書の作成支援と過去事例の検索

直近3年分の報告書から、発生日・工程・設備名・製品・現象（短い言葉）・現象分類・推定原因・是正内容・再発の有無・再発時の状況を抜き出し、1件1行の表にします。再発時の状況の列は、再発ありの行だけに記入し、それ以外は空欄のままにします。この列がないと、あとから「なぜ再発したか」をAIに聞いたときに、記録のない理由を書かせてしまいます。現象分類は最初に10種類程度を決めます。例えば「寸法不良」「溶接欠陥」「表面キズ」「部材違い」「工程飛ばし」などです。この分類列がないと、言葉の違う同じ不具合を拾えません。件数が多い場合は、まず不具合の多い1工程分から始めます。

現場のメモは短く、主語が抜けています。それをそのまま渡して構いません。重要なのは、書かれていない事実を補わせないことです。「メモにない事実を補わないでください」「不明な項目は未記入と書いてください」の2文を必ず入れます。

あなたは製造現場のトラブル報告書の作成を手伝います。
次のメモをもとに、下記の様式の各項目を埋めてください。

【様式】
発生日時／発生工程／設備名／対象製品・工番／現象／影響範囲／応急処置／推定原因（候補を3つまで）／再発防止の案／水平展開の候補

【ルール】
・メモに書かれていない事実を補わないでください。不明な項目は「未記入」と書いてください。
・現象の欄には、見えた事実だけを書いてください。原因の推測を混ぜないでください。
・推定原因は断定せず、「〜の可能性」という形で3つまで並べてください。1つに絞らないでください。
・最後に「報告書を完成させるために現場へ確認すべきこと」を箇条書きで挙げてください。

【メモ】
（ここに現場のメモ、または口述の書き起こしを貼り付け）

AIが挙げた確認事項を持って、その日のうちに現場へ戻ります。ここが報告書の質を決める工程です。時間が経つほど、材料ロットや設定値といった事実が失われます。確認して埋めた項目は、AIの出力ではなく人が書いた記述として扱い、報告書上で区別できるようにしておくと後の検証が楽になります。

現象の文言が違っても内容が近ければ拾わせる、ただし該当がなければ「該当なし」と答えさせる、の2点を指定します。無関係な事例を並べられると、確認の手間が増えて使われなくなります。

添付の過去トラブル一覧から、次の条件に近い事例を挙げてください。

【今回の条件】
発生工程：溶接／設備：半自動溶接機3号／現象：ビード表面にピットが多発／対象：SS400 t9 隅肉溶接

【出力】
各事例について次の順で1行ずつ書いてください。
発生日,工程,設備,現象,推定原因,是正内容,再発の有無,再発時の状況,今回との共通点

【ルール】
・現象の文言が違っても、内容が近ければ拾ってください。
・条件に近い事例がない場合は「該当なし」とだけ答えてください。無関係な事例を並べないでください。
・再発ありの事例は、一覧のP列（再発時の状況）に書かれている内容をそのまま引用してください。P列が空欄の場合は「再発理由の記録なし」と書いてください。理由を推測して書かないでください。

報告書の様式そのものを直します。現象欄と推定原因欄を明確に分け、推定原因欄には「〜の可能性」と書く決まりにします。さらに、真因が特定できた時点で「確定原因」欄へ書き移す運用にします。AIの下書きは推定原因欄までしか埋めない、というルールを品質保証部で明文化してください。これで、AIが書いた推測が確定原因として一人歩きするのを防げます。

報告書が完成したら、その内容を1行にして事例一覧へ追記します。追記が止まると、翌年から検索が機能しなくなります。品質保証部で月次の追記当番を決め、月初に前月分をまとめて反映してください。あわせて、現象分類が実態に合っているかを半年に1回見直します。分類に入らない事例が増えていたら、分類を足す時期です。