過去の不具合記録を生成AIで探せるようにすると、どこで見つからないのか？——似た事例が引けない5つの書き方と、検索に載せる前にそろえる項目【2026年版】

製造DX編集部

2026年10月26日公開

この記事の要点

過去の不具合記録を生成AIで探せるようにしても、似た事例が出てこない原因の多くは、AIの性能ではなく記録の書き方にあります。
現象と原因と対策が1つの欄に混ざっている、品番や工程の書き方が人ごとに違う、対策をどこまで適用したかが書かれていない——この種の書き方が、検索で引けない記録を作ります。
検索に載せる前にそろえるのは、現象・発生条件・対象・原因・対策と適用範囲の5項目です。全件を直す必要はなく、再発の多い製品系列から始めます。
候補を探して要約する作業は生成AIに任せられますが、どの事例が今回と同じかを決める判断は人に残します。

この記事が支援する判断：品質保証や設計・生産技術の担当者が、過去の不具合報告書やトラブル記録を生成AIで検索できるようにしようと考えたときに、いまの記録のままで使えるか、どの項目を先にそろえるか、どこまでをAIに任せるかを決める場面を支援します。

新しい不具合が起きたとき、「前にも似たことがあったはずだ」と感じても、過去の報告書をすぐに見つけられないことがあります。そこで記録を生成AIに読み込ませて検索しようとすると、期待した事例が出てこない、あるいは関係のない事例が並ぶという結果になりがちです。結論から言えば、検索の精度を決めるのは記録の項目と書き方で、AIを替えても記録が同じなら結果はあまり変わりません。本稿では、似た事例が引けなくなる書き方と、検索に載せる前にそろえる項目を整理します。

過去の不具合記録は、なぜ生成AIで探しても見つからないのか？

不具合報告書は、その不具合を社内や客先に報告し、対策を承認してもらうために書かれます。あとで別の担当者が、別の製品の不具合と突き合わせて探すことは、書く時点ではあまり想定されていません。そのため、報告書ごとに書き方が違い、同じ現象が別の言葉で書かれ、原因と対策が1つの文章に入っています。

生成AIの検索は、記録のどこを見ているのか？

生成AIを使った検索は、質問と意味の近い文章を記録から取り出して答えを組み立てます。記録の中で「どの工程で」「どの条件で」「何が起きたか」が分かれていないと、質問とたまたま言葉が近い記録が選ばれ、条件が同じ記録は選ばれません。製造業の中小企業104社への調査をもとに不具合管理の支援システムを設計した2026年の論文も、現状を次のようにまとめています。

practical failure management in many SMEs remains reactive, media-discontinuous, and weakly connected to reusable knowledge.
Turgut Refik Caglar “Design and Implementation of a Knowledge-Based Assistance System for Smart Failure Management in Manufacturing SMEs Using Large Language Models”（AHFE Open Access, Industrial and Systems Engineering, 2026）

訳すと「多くの中小企業の実際の不具合管理は、起きてから対応する形で、媒体が途切れ、再利用できる知識とのつながりが弱いままである」という指摘です。記録が紙・Excel・メールに分かれ、つながっていない状態では、どの検索の仕組みを入れても拾える範囲が限られます。

似た事例が引けなくなる5つの書き方とは？

検索で引けない記録には、共通する書き方があります。表1は、よく見られる5つの書き方と、検索で何が起きるか、どう直すかを並べたものです。

書き方	検索で起きること	直し方
①現象・原因・対策を1つの欄に書く	原因の言葉で質問しても、現象の言葉が多い記録が選ばれる	欄を分け、1欄1つの内容にする
②品番・工程・設備の書き方が人ごとに違う	同じ設備の記録が別物として扱われ、取りこぼす	マスタの正式名称か番号で書く
③現象を社内の呼び方だけで書く	別の部署の呼び方で質問すると引けない	現象の分類を決め、呼び方は別欄に残す
④発生条件（材料ロット・段取り後・季節など）を書かない	条件の違う記録まで「似た事例」として並ぶ	4M（人・機械・材料・方法）のどれが変わったかを書く
⑤対策をどこまで適用したかを書かない	対策済みかどうか分からず、同じ調査をやり直す	適用した工程・品番と、適用しなかった理由を書く

表1：似た事例が引けなくなる5つの書き方と直し方（編集部作成）

①と②は、記録を書く人を変えなくても、様式とマスタを決めれば直せます。③と④は、現場で何を「同じ不具合」と見なすかを決める必要があるため、品質保証と製造で分類の定義を合わせてから進めます。⑤は、対策会議の結論を記録に戻す手順がないと、いつまでも空欄のまま残ります。

検索に載せる前に、どの項目をそろえるのか？

そろえる項目は、図1の5つです。いま自由記述の1欄に入っている内容を、この5項目に分けて持ち直すと、「同じ工程で、同じ条件のときに、同じ現象が出た記録」を条件で絞り込めるようになります。

図1：自由記述の不具合記録を、検索に載る5つの項目に分けて持ち直す（編集部作成）

表の形にすれば、そのまま検索に使えるのか？

表の形の記録をそのまま生成AIに渡せばよいわけでもありません。FMEA（故障モード影響解析）のデータを知識グラフにして検索に使う方法を提案した論文は、出発点の課題を「its effectiveness is often limited by the reasoning capabilities of the FMEA tools, which are usually tabular structured」と書いています（出典：Bahr ほか、arXiv:2406.18114）。表に入っているだけでは項目どうしの関係をたどれないため、同論文はまずデータの標準化と項目の定義（スキーマ）を示し、そのうえで検索の仕組みを組んでいます。

帳票の作りそのものが読み違いを起こす点は、Excel帳票を生成AIに読ませる記事でも出発点に置いています。

結論から言えば、製造業の帳票は印刷して人が読むために作られており、コンピュータが読むためのデータの形をしていないからです。
Excel帳票を生成AIに読ませると何がずれるのか？——読み違いを招く7つの作りと、渡す前に直す範囲・渡してはいけないブックの条件【2026年版】

生成AIに任せてよい作業と、人が決める作業はどこで分かれるのか？

過去の事例を探す作業は、探す・読む・当てはめる・決めるの4つに分けられます。表2のように、前の2つは生成AIに任せやすく、後ろの2つは人が受け持ちます。

作業	担当	判断の目安
候補の記録を探して並べる	生成AI	①〜③の項目がそろっていれば、条件で絞った候補を出せる
候補の記録を要約し、違いを並べる	生成AI	原文へのリンクを必ず付け、人が元の記録を確かめられるようにする
今回の不具合と同じ事例かを決める	人	発生条件と対象が一致するかを、現物と工程で確かめる
過去の対策を流用するか、新しく決めるかを決める	人	過去の対策の効果と、適用しなかった範囲の理由を読んで決める

表2：過去の不具合を探す作業の分け方と、生成AIと人の担当（編集部作成）

原因の欄に「推定」と「確定」が混ざっている記録は、要約の段階で推定が事実のように書き換わることがあります。原因の欄は、確定した原因と推定の段階の原因を分けて書くと、要約の誤りを人が見つけやすくなります。

生成AIでの検索がまだ早い、向かない条件とは？

次の4つのいずれかに当てはまる場合は、検索の仕組みを先に入れても期待した結果は出ません。記録の側を整えるか、別の方法で探すほうが早く進みます。

過去の記録が紙や写真のままで、文字として残っていない——先に読み取りと文字起こしの工数を見積もる必要があります。
何を「同じ不具合」と見なすかが、部署ごとに違う——分類の定義を合わせないと、検索結果の当否を誰も判断できません。
記録の件数が少なく、担当者が全件を覚えている——一覧表と人の記憶で探すほうが早く、仕組みの費用に見合いません。
対策会議の結論を記録に戻す手順がない——検索できても「その後どうなったか」が分からず、同じ調査を繰り返します。

同じ不具合を別の工程で繰り返さないための水平展開も、記録の持ち方が出発点です。是正処置の水平展開を扱った記事は、止まる原因の1つを次のように挙げています。

情報：不具合が4M・工程・部品といった属性で構造化されておらず、類似工程を機械的に引き当てられない。
是正処置が同じ不具合を繰り返す構造——品質保証の「水平展開」が形骸化する理由とAIで補える範囲

いまのExcelの様式のまま、検索できる形にするには？

不具合報告書や是正処置票は、多くの工場でExcelの様式として長く使われています。様式を一から作り直すと、書く人の負担が増え、過去の記録との対応も切れます。進め方は、まず再発の多い製品系列を1つ選び、直近の記録を図1の5項目に分けて持ち直し、その範囲で検索を試すことです。そこで引けなかった記録を見れば、様式のどの欄を分けるべきかが分かります。

SPESILLは、仕様書・FMEA・是正処置・見積書などの製造業のExcel帳票を、様式を残したまま構造化し、生成AIでの検索や起案に使えるようにする基盤です。AIが出した候補や下書きは、人が確認して仕上げる前提で使います。様式を変えずに過去の記録を持ち直したい場合の選択肢の1つになります。

よくある質問（FAQ）

過去の不具合報告書を、そのままChatGPTに読み込ませてもよいですか？

少ない件数を要約させる用途なら使えますが、似た事例を探す用途では、現象・原因・対策が1欄に混ざった記録や、品番の書き方がばらばらの記録は引けません。社外のサービスに渡す場合は、客先名や図面番号などの機密情報の扱いを社内の規程で確かめてから使ってください。

過去の記録を全部、5つの項目に直す必要がありますか？

全件を直す必要はありません。再発の多い製品系列か、客先への影響が大きい不具合から始め、直近の記録を5項目に分けて持ち直します。そこで検索を試し、引けなかった記録の書き方を見て、様式のどの欄を分けるかを決めると、手戻りが少なくなります。

生成AIが出した「似た事例」は、そのまま対策に使えますか？

そのままは使えません。生成AIが出すのは候補で、今回と発生条件や対象が同じかは、人が現物と工程で確かめます。過去の対策を流用する場合も、その対策の効果と、適用しなかった範囲の理由を元の記録で読んでから決めてください。

まとめ

過去の不具合記録を生成AIで探せるようにしても似た事例が出てこない原因は、多くの場合、記録の書き方にあります。現象・原因・対策が1欄に混ざる、品番や工程の書き方が人ごとに違う、現象を社内の呼び方だけで書く、発生条件を書かない、対策の適用範囲を書かない——この5つを直し、現象・発生条件・対象・原因・対策と適用範囲の5項目をそろえます。候補を探して要約する作業は生成AIに任せ、同じ事例かどうかと対策をどうするかは人が決めます。全件を直す前に、再発の多い製品系列1つで試してください。

次に読みたい関連記事

出典・参考

Turgut Refik Caglar “Design and Implementation of a Knowledge-Based Assistance System for Smart Failure Management in Manufacturing SMEs Using Large Language Models”（AHFE Open Access, Industrial and Systems Engineering, 2026。DOI: 10.54941/ahfe1007784。論文ページ。2026年10月22日に要旨を確認）
Bahr ほか “Knowledge graph enhanced retrieval-augmented generation for failure mode and effects analysis”（arXiv:2406.18114、v3 2025年3月28日。2026年10月22日に要旨を確認）

過去の不具合報告書や是正処置票を、いまの様式のまま検索や起案に使える形にする方法は、SPESILLの紹介ページで説明しています。SPESILLで製造業の帳票を生成AIで使える形にする