朝9時、得意先からクレームの電話。品管リーダーがまずやるのは、ベテランの田中さんを呼ぶこと。「あー、これ3年前にも似たのあったな」と記憶を頼りにファイルを探す。見つからない。Excelで検索してもヒットしない。結局、ゼロから調べ直す──。
この光景に心当たりがある工場は多いはずです。私も製造業の現場で品質クレーム対応に生成AIを入れる取り組みをしましたが、最初に詰まったのはAIの性能ではなく、まったく別のところでした。
その顛末と、現場で固まった役割分担の線引きを書きます。
Q01品質クレームの過去事例検索は、AIでできますか？
できます。生成AIには「意味で検索する」力があり、「ベアリングの焼き付き」と入力すれば「軸受けの過熱損傷」と書かれた報告書も引っかかります。キーワード一致では超えられなかった用語のゆれ、担当者ごとの書き方の違い、フォーマットのバラつきの壁を越えられます。
クレーム対応が属人化している工場に共通するのは、「情報がない」のではなく 「情報はあるのに使えない」 という構造です。不具合報告書はちゃんと書いている。ファイルも保管してある。でも「前に同じことがあったか」を調べる手段がない。Excelで「ベアリング」と検索しても、「軸受け」と書いてあればヒットしません。
そしてベテランの頭の中にだけ「あのときはこうだった」がある。それが異動や引退で消える。これはベテランのせいでも品管の怠慢でもなく、過去のデータが「検索できる形」で存在していない仕組みの問題です。
Q02AIを入れる前に、つまずくポイントはありますか？
あります。AIの性能より先に、データの壁に当たります。ある工場で過去の不具合報告書を分析したら、原因欄が「原因不明」「その他」「調査中」のまま放置された報告書が想像以上に多かった。フォーマットもWord・Excel・手書きスキャンPDF・メール本文と散在し、粒度も構成もバラバラでした。
生成AIの意味検索を知ったとき、正直「クレーム対応の救世主になるのでは」と思いました。でも実際に報告書の中身を見て分かったのは、AIの問題ではなくデータの問題だったということです。
ただ、ここで「じゃあまずデータを全部整えてからだ」と身構える必要はありません。実はこのデータの壁こそ、生成AIが崩してくれるところです。
Q03バラバラな報告書は、フォーマットを統一してから読ませる必要がありますか？
不要です。生成AIはWord・Excel・PDF・メール文面といったバラバラな形式の報告書を読んで、「何が起きたか（現象）」「なぜ起きたか（原因）」「どう対処したか（対策）」を抽出できます。人がフォーマットを揃え直さなくても、AIが読んで構造化します。過去の報告書を書き直す手間は要りません。
ただし、実務で気づいたコツが2つあります。
- 段階的に抽出させる：一度に「現象・原因・対策・再発防止策・製品名・工程」を全部抽出させると精度がガタッと落ちる。①現象→②原因→③対策と分けて処理させると精度がかなり上がる
- 抜き取り検査の発想で出力をチェックする：数百件の一括処理で全件チェックは非現実的。「抽出結果が極端に短い」「原因が不明のまま」「製品名が存在しない値」といった明らかな異常だけ自動検出し、残りはランダムに抜き取り確認する
品質管理の責任者なら「抜き取り検査」の考え方は日常そのものだと思います。AIの出力も、同じ発想で管理できます。
Q04原因の推定まで、AIに任せていいですか？
任せてはいけません。「似た事例を探して並べる」のがAIの仕事、「これが原因だ」と判断するのは人の仕事です。AIは過去の類似事例からもっともらしい回答を組み立てるだけで、今回の個別事情を見ていません。この線引きが導入成功の分かれ目です。
ある工場で「AIが過去事例から原因を自動推定する機能」を試したことがあります。AIは過去データをもとに「金型の摩耗が原因」と回答した。しかし実際に調べると、原因は材料ロットの不良でした。品質クレームでは、誤った原因判断が得意先との信頼関係に直結します。
暴走リスクの抑え方は驚くほどシンプルで、AIへの指示に 「情報が足りない場合は『判断できません』と回答してください」 とひと言入れるだけ。これで誤答が大幅に減ります。品質の世界で「わからない」と言えることは、間違った答えを出すよりずっとマシです。
Q05AIを入れると、クレーム対応の何が変わりますか？
まず初動のスピードです。ベテランの記憶頼みで半日かかっていた類似事例の調査が、AIが過去事例を提示する数分に変わります。さらに、新しいクレームが来るたびにナレッジが蓄積される好循環が生まれ、ベテランの頭の中の「あれと同じだよ」がシステムとして残り続けます。
でも私が現場で見ていて一番大きいと思うのは、もっと手前の変化です。AIに読ませるために報告書の中身を見直すプロセスそのものが、品質改善の仕組みになる。「原因不明」のまま放置されていた報告書に向き合うことは、報告書の運用を見直すことと同じです。
AIを入れるつもりで始めたことが、品質改善の本丸に手をつけることになる。狙っていたわけではないのですが、複数の工場で同じことが起きました。
よくある質問（FAQ）
- Q. 何から始めればいいですか？
- A. 過去の不具合報告書を10件だけ集めて、原因欄を見ることからです。「原因不明」「その他」がどのくらいあるか。そこがAI活用の入り口であり、品質改善の入り口でもあります。
- Q. 「原因不明」のまま閉じた報告書は、資産になりませんか？
- A. 現状のままでは検索しても答えが出ない「高くつく」資産です。ただしAI導入を機に原因欄の運用を見直せば、以後の報告書は蓄積するほど効くナレッジに変わります。
- Q. ベテランが引退する前にやるべきことはありますか？
- A. 過去の報告書をAIで検索できる形にしておくことです。「あのときはこうだった」という記憶がシステムに残る形になっていれば、異動や引退で調査ノウハウがゼロに戻る事態を防げます。
- Q. 報告書の量が数百件ありますが、全件を人がチェックするのですか？
- A. 不要です。明らかな異常（抽出結果が極端に短い、原因が不明のまま、製品名が存在しない値）だけ自動検出し、残りは抜き取り確認で十分です。品質管理の抜き取り検査と同じ発想で運用できます。
AUTHOR
黛 政隆（まゆずみ まさたか）
株式会社GembaShift 代表取締役CEO
エンジニア歴20年、PM経験50件超。生成AIの導入を、現場に入って一緒に組む仕事をしています。 この記事の内容は、著者自身が実際に手を動かして業務で検証した実体験に基づいています。