不具合報告書をAIで書く・探す・つなぐ

第一に、記入者によって粒度が違います。ベテランは発生条件、ロット番号、設備名、直前の変更点まで書きますが、新人は「寸法NG」とだけ書くことがあります。第二に、同じ事象を別の言葉で表現するため、キーワード検索では過去事例が見つかりません。「バリ」「ばり」「エッジ残り」は同じ現象でも、検索では別物です。

第三に、報告書、是正処置の依頼、完了確認がそれぞれ別の帳票や別の担当者に分かれていて、再発防止策が実際に実施されたかを確認しにくいことです。監査では、記録が揃っていないことよりも、記録がつながっていないことの方が問題になります。

報告書の本文を意味で検索する仕組みを作ると、表現が違っても似た事例が見つかります。新しい報告書の下書きを書いた時点で、過去の類似事例とその真因、是正処置、効果確認の結果を一覧で示せます。「三年前に別ラインで同じ現象があり、治具の摩耗が原因だった」と分かれば、調査の出発点が変わります。

是正処置の追跡も、同じ検索基盤で行えます。期限を過ぎた是正処置、効果確認が未実施の案件、同じ設備で再発している案件を、週次で一覧にして品質保証の担当者に渡す運用です。判断や承認は人が行い、AIは漏れを拾う役割にとどめます。

過去二、三年分の報告書を取り込み、品質保証の担当者が実際に起きた不具合を十件ほど選び、AIが類似事例を引けるかを確認するところから始めます。引けなかった事例の原因が、記録の粒度なのか検索の仕組みなのかを切り分けることで、次の改善点が明確になります。

報告書の件数が少ない、または記録が紙のままで電子化されていない場合は、AIよりも先に電子化と書式の整備が必要です。また、原因分析そのもの(なぜなぜ分析、特性要因図の妥当性)をAIが保証することはできません。分析の質は、現場に出て確認する人の力に依存します。