FMEAをAIエージェントで効率化する方法【製造業・品質管理】|過去の不具合データを生かす進め方
- FMEAが重いのは、書く量が多い・評価が人によってぶれる・過去のFMEAや不具合を引けない・見直されないの4つが重なるからです。
- AIに任せられるのは、議事録や過去の記録から候補を出す下書きと、過去と照らした記載漏れの指摘です。影響の重さの評価と対策の決定は人が持ちます。
- AIの候補の質は、材料になる不具合データの「項目」と「言葉」がそろっているかで決まります。海外工場を含め、先にここを整えます。
- ここで紹介するのは、カトルセが商談で提案している進め方です。導入の実績ではありません。始めるなら、製品ファミリー1つと過去の記録数十件で、人の作ったFMEAと比べるところからです。
「FMEAをAIで何とかできないか」。2026年の秋、製造業の品質・設計の方から、こうしたご相談を続けていただきました。FMEAは製品の弱点を前もって洗い出す大事な表ですが、書くのに時間がかかり、担当者によって中身が変わり、過去の分が次の製品に生かされにくい、という声が共通しています。
この記事では、FMEAづくりのどこにAIを使い、どこを人が決めるのかを工程ごとに分け、材料になる不具合データの整え方と、AIエージェントの組み方、小さな始め方を説明します。FMEAという言葉になじみのない方は、先に2章の基本の説明からお読みください。不具合報告書づくりや過去事例の検索の全体像は製造業のAI活用事例2026に、図面やデザインレビューの議事録の検索は図面検索・検図のAI化にまとめています。ここではFMEAとその材料に絞ります。
1. 現場で聞く「FMEAが重い」の中身
カトルセが2026年の夏から秋にお会いした製造業の企業で聞いた声を、業種と規模だけにして並べます。
| 業種・規模 | 聞いた悩み |
|---|---|
| 上場の製造業 | FMEAのAIエージェント支援を最優先にしたい。ねらいは属人化の解消、作成時間の短縮、精度の向上。海外工場を含めた不具合データの整備も課題になっている。 |
| 精密部品メーカーの開発部門 | 設計審査で話した内容を、議事録から決まった帳票に落としたい。量産前の品質計画(APQP)の帳票づくりに数百時間かかるのがいちばん大変。「ここがまだ足りない」という判定までAIにしてほしい。過去のFMEAや図面はプロジェクトごとに保管している。 |
| 産業用電気機器メーカー(300〜499名) | 不具合報告書をAIに読み込ませて、新人でもベテランに近い判断ができる仕組みにしたい。 |
| 電気機器・制御盤の製造 | 検査データはあるが、原因分析と再発防止に生かしきれていない。 |
| 金属製品メーカー | 少人数の品質管理で、品質関係の書類と不具合実績のとりまとめに手間がかかる。顧客監査や認証の更新対応も重なる。 |
共通点は3つです。
- 書く量が多く、人に依存している。FMEAも関連の帳票も、詳しい人が時間をかけて書くしかありません。
- 過去のFMEAや不具合が「ある」のに引けない。プロジェクトごと、拠点ごとに保管され、似た部品の分を探すだけで時間がかかります。
- 記録の書き方がばらばら。拠点・人・年代によって項目も言葉も違い、集めても比べられません。
2. FMEAを知らない方へ:起きる前に「壊れ方」を洗い出す表
FMEA(故障モード影響解析)は、部品や工程ごとに「機能 → 故障モード(どう壊れるか)→ 影響 → 原因 → 今の対策 → 評価 → 追加の対策」を並べる表です。製品ができる前に「どこが、どう壊れうるか、壊れたら何が起きるか」を洗い出し、重いものから手を打つために使います。
身近な例で、自転車のブレーキワイヤーを1行書くと次のようになります。
| 項目 | 自転車のブレーキワイヤーの例 |
|---|---|
| 機能 | ブレーキレバーの力をブレーキに伝える |
| 故障モード | ワイヤーが切れる |
| 影響 | 止まれない |
| 原因 | サビ、摩耗 |
| 今の対策 | 定期点検 |
| 評価 | 影響が重い。起きる可能性もある → 優先して手を打つ |
| 追加の対策 | サビにくい素材に変える、点検の間隔を短くする |
実際の製品では、これが部品や工程の数だけ、1つの部品にも故障モードの数だけ並びます。FMEAには大きく2種類あります。
- 設計FMEA:製品の設計そのもの(部品・構造・材料)に潜む壊れ方を洗い出します。
- 工程FMEA:作る工程(加工・組立・検査)で起きうる不良を洗い出します。
作り方には自動車業界の手引きや国際規格があり、評価の付け方や様式は、自社や顧客が指定するものに従うのが一般的です。この記事では、特定の手引きの手順には立ち入らず、どの様式でも共通する「表を書く作業」へのAIの使い方を扱います。
品質管理の中でのFMEAの位置
品質管理の道具は、使う時期で大きく2つに分かれます。FMEAは起きる前に予測する道具で、なぜなぜ分析や是正処置の報告は起きた後に原因を追う道具です。そして、起きた後に書いた不具合の記録こそが、次の製品のFMEAで「この部品は前にこう壊れた」と気づくための材料になります。FMEAのAI化で不具合データの整備が欠かせないのは、このつながりがあるからです。
| 道具 | いつ使うか | 何をするか |
|---|---|---|
| FMEA | 起きる前(設計・工程を決める段階) | 壊れ方を予測し、重いものから対策を決める |
| なぜなぜ分析 | 起きた後 | 1つの不具合について「なぜ」を重ねて根本の原因を掘り下げる |
| 不適合報告・是正処置報告 | 起きた後 | 何が起きたか、どう処置し、再発をどう防ぐかを記録する |
3. 結論:AIは「候補を出す・照らす・指摘する」、人は「評価して決める」
FMEAづくりを工程に分けると、AIに任せやすい所と、人が持つべき所がはっきりします。

| 工程 | AIに任せること | 人が持つこと |
|---|---|---|
| 構造の分解 | 仕様書や部品表から、部品・工程の一覧の下書きを作る | 分け方の粒度を決める |
| 機能の書き出し | 仕様書・議事録から、部品ごとの機能の候補を書く | 抜けや言い過ぎを直す |
| 故障モード・原因の候補出し | 議事録・過去のFMEA・不具合記録から候補を挙げ、根拠の記録を添える | 採るか捨てるかを決める |
| 過去の不具合との照合 | 似た部品・似た現象の記録を探し、表に無い候補を指摘する | 本当に同じ壊れ方かを判断する |
| 評価 | 似た故障に違う評価が付いていないか、ぶれを指摘する | 評価を付けて確定する |
| 対策の決定 | 過去に効いた対策の例を示す | 対策と担当・期限を決める |
| 見直し | 新しい不具合が出たとき、関係するFMEAの行を探して知らせる | 表を直すかを決める |
AIが苦手なことも押さえておきます。社内に記録の無い壊れ方を当てること、評価の最終判断、根拠の無い断定です。AIはもっともらしい故障モードを書き足すことがあります。そこで、指示の原則を「話されていない・記録に無いことは書かず【要確認】と書く」「候補には根拠の記録を必ず添える」の2つにします。根拠の無い候補は、人が確かめるまで表に入れません。
4. 先に整える:不具合データの「項目」と「言葉」をそろえる
AIが過去と照らして候補を出せるかどうかは、材料の不具合記録しだいです。報告書が文章のまま、項目も言葉も人によって違うと、AIは似た不具合を見つけられません。次の4つの手順で、FMEAに使える形にします。

- 必須の項目を決める:製品、部品、工程、現象、原因、対策、発生した拠点、日付。最初は多くしすぎず、FMEAの列と対応する項目を優先します。
- 1件1行に分ける:報告書の文章から、AIで上の項目を抜き出して表にします。1通の報告書に2つの現象が書かれていれば2行にします。抜き出せない項目は空欄のままにし、AIに推測で埋めさせません。
- 言葉をそろえる:同じ現象の呼び方の辞書を作ります。たとえば「割れ」「クラック」「ヒビ」を1つにまとめる、といった対応です。AIには表記ゆれの候補を挙げさせ、辞書として確定するのは人です。
- 様式の違いを対応表で吸収する:拠点や年代で様式が違うときは、元の様式を無理に作り直さず、「この様式のこの欄は、共通の項目のこれ」という対応表を作ります。
カトルセは商談で、過去のデータを「集める → 整える → 検索できる形にする → 使う」の4段階で進めることをお勧めしています。いきなり「使う」から始めると、AIの答えが外れたときに、AIの問題なのかデータの問題なのかが分からなくなるからです。検索の精度そのものの改善は、RAGの精度が上がらない理由で詳しく扱っています。
ベテランの頭の中にしかない「この部品はこう壊れやすい」という知識も、故障モードや原因の候補として使えます。聞き取りと録音の進め方は技能伝承をAIで進める方法をご覧ください。
5. 海外工場の記録をそろえるときの注意
海外工場を含めると、現地語・英語・日本語が混ざった記録をそろえることになります。一般的な進め方として、次の点に気をつけます。
- 原文は消さない:翻訳で置き換えず、原文を残したまま、日本語(または英語)の要約と共通の項目を付け足します。後で「元は何と書いてあったか」に戻れるようにするためです。
- 用語集を先に作る:専門用語は訳し方がぶれます。部品名・現象名の対訳を先に決め、AIへの指示に渡します。
- 数え方の違いを前提にする:拠点ごとに、何を1件と数えるか、どう分類するかが違うことがあります。4章の対応表で吸収します。
- 現地の担当者に確かめてもらう:AIが付けた要約と項目は、現地の担当者が確認してから共通の表に入れます。
海外拠点のデータを社外のAIサービスに入れてよいかは、社内規程や契約によります。先に確認してください。規程の作り方は生成AIの社内規定の作り方にまとめています。
6. AIエージェントの組み方:下書き係・照合係・点検係
カトルセが商談で提案しているのは、AIに3つの役を分けて持たせる組み方です。議事録から部品・機能・故障モード・原因・対策を抜き出して様式に下書きし、過去のFMEAや不具合記録と照らして、記載漏れを指摘します。
- 下書き係:設計審査(デザインレビュー)の議事録や仕様書から、自社の様式に沿って、部品・機能・故障モード・原因・対策の候補を書きます。
- 照合係:過去のFMEAと不具合記録から、似た部品・似た現象を探し、どの記録が根拠かを添えて候補を足します。
- 点検係:空欄、評価のぶれ(似た故障に違う評価が付いている)、対策の書き漏れを指摘します。
ここでは「AIエージェント」と呼んでいますが、AIが最初から最後まで自動で仕上げるものではありません。各段の間で人が中身を確かめ、承認してから次に進む半自動の流れです。FMEAは製品の安全や品質の判断そのものなので、この形が現実的だと考えています。なお、これは提案している進め方で、構築して効果を測った実績ではありません。
指示文の例を2つ示します。自社の様式の列名に合わせて書き換えてください。
【下書き係への指示の例】
あなたは設計FMEAの下書き担当です。
添付の設計審査の議事録と仕様書から、次の列で表を作ってください。
列:部品/機能/故障モード/影響/原因/今の対策
・議事録や仕様書に書かれていないことは推測で埋めず、【要確認】と書く
・各行に、根拠になった発言や記載をそのまま引用して添える
・評価の列は空欄のままにする(評価は人が付ける)
【照合係・点検係への指示の例】
添付の「FMEAの下書き」と「過去の不具合記録(1件1行の表)」を照らしてください。
1. 下書きの部品と似た部品・似た現象の不具合記録を探し、
下書きに無い故障モード・原因があれば、記録の番号を添えて候補として挙げる
2. 空欄の行、似た故障モードなのに対策の書き方が大きく違う行を指摘する
3. 根拠の記録が見つからないものは候補に入れない
出力は「指摘」と「根拠の記録」の2列の表にする
7. Copilot・SharePointしか使えない会社での始め方
お会いした企業では、会社の標準のAIがMicrosoft 365 Copilotで、過去のFMEAや資料がSharePointやExcelに保管されている、というケースが目立ちました。ClaudeやChatGPTを使うには情報システム部門の許可が要る、という会社も少なくありません。
その場合は、段階を分けると進めやすくなります。
- いま使えるAIで、手作業で試す:過去のFMEAを1つ渡して要約させる、議事録から故障モードの候補を挙げさせる、不具合報告書から項目を抜き出させる。担当者が1件ずつ試し、どこまで使えるかを確かめます。
- 限界を書き留める:大量の記録との照合、様式への書き込み、評価のぶれの検出など、手作業では回らない所が見えてきます。
- そこで初めて仕組みを検討する:手作業で効果と限界が分かってから、照合や点検を自動で回す仕組みを考えます。
Copilotで成果が出やすい業務の選び方はCopilot無料版でできる業務10選に、部署ごとにAIツールが分かれてしまったときの片付け方は生成AIツールが部署ごとにバラバラにまとめています。
8. 始め方:製品ファミリー1つ・過去の記録数十件から
最初から全製品を対象にすると、データの整備だけで止まります。次の順で、小さく比べるところから始めます。
- 対象を製品ファミリー1つに絞る:部品や壊れ方が似ている製品群に絞ると、過去の記録が照合に生きやすくなります。
- 過去のFMEAと不具合記録を数十件集める:4章の手順で項目と言葉をそろえます。
- 人の作ったFMEAとAIの下書きを並べる:すでに人が作ったFMEAがある製品で、同じ材料からAIに下書きさせ、「人が見落としていた候補」と「AIの的外れ」を数えます。
- 作成時間と件数を測っておく:いまFMEAや関連帳票の作成に何時間かかり、年に何件作っているか。これが分かっていないと、効果を比べられず、仕組みに投資するかの判断ができません。
- AIの評価は「正しいか」より「人が見て役に立つ候補が出たか」で見ます。
- 的外れの候補が多いときは、AIより先に不具合データの項目と言葉を疑います。
- 評価の列はAIに埋めさせず、人の評価のぶれを点検係に指摘させる使い方から始めます。
9. 機密の扱いと、カトルセが手伝える範囲
不具合データとFMEAは、製品の弱点の一覧そのものです。社内でも機密度の高い情報なので、AIに入れる前に扱いを決めます。
- 社外に出さない構成:クラウドに出せない場合は、社内で動かすローカルLLMという選択肢があります。構成と費用の目安はローカルLLMのオンプレ構成と費用にまとめています。
- 社内の利用ルール:どの情報を、どのAIに、どこまで入れてよいかを先に決めます(生成AIの社内規定の作り方)。
カトルセがお手伝いできるのは、次の3つです。
- 研修:品質・設計の担当者が、自分でAIを使えるようにします。設計職向けの生成AI×設計実務研修では「過去の不具合事例から設計チェック項目を作る」演習を、品質・製造向けの生成AI×現場管理実務研修では「不適合報告・是正処置報告の下書き」の演習を行います。FMEAそのものを作る演習はカリキュラムに含まれていませんが、FMEAの材料になる不具合記録をAIで扱う基本はここで身につきます。職種別AI研修シリーズ(全9講座・各11時間)。受講料は全講座共通で1名あたり36万円(税抜)。ライブ形式(対面/オンライン同時双方向)のため人材開発支援助成金の活用をご検討いただけます。支給の可否は都道府県労働局の審査で決まります。申請手続きは社会保険労務士の独占業務のため、必要な場合は提携社労士をご紹介します。
- 進め方の伴走:対象の絞り方、データの整え方、比べ方の設計をAI顧問として一緒に進めます。
- 仕組みづくり:照合や点検を自動で回す仕組みが必要になった段階で、生成AI開発としてご相談ください。
よくある質問
FMEAの評価をAIに付けさせてもよいですか?
候補と根拠を示すところまではAIに任せ、評価の確定は人が行うことをお勧めします。評価は製品の安全や品質の判断そのもので、根拠を説明できる人が責任を持つ必要があります。AIには、似た故障に違う評価が付いていないかを指摘させる使い方が向いています。
過去のFMEAがExcelでばらばらです。そのままでも使えますか?
そのままでも要約や候補出しには使えますが、照合の精度は上がりません。まず製品ファミリー1つ分だけ、項目と言葉をそろえた1件1行の表にしてください。様式の違いは、元のファイルを作り直さず、共通の項目との対応表で吸収できます。
海外工場の不具合記録が英語や現地語です。
原文を残したまま、日本語(または英語)の要約と共通の項目をAIで付け足す方法があります。先に部品名・現象名の用語集を作ってAIに渡し、付けた要約は現地の担当者に確かめてもらいます。社外のAIサービスに入れてよいかは、社内規程と契約を先に確認してください。
AIが社内に記録の無い故障を見落としませんか?
見落とします。AIが根拠を持てるのは、渡した議事録や過去の記録に書かれていることだけです。だからこそFMEAは人が書き、AIはその抜けを過去の記録から指摘する役に置きます。記録に無い壊れ方を考えるのは、これまでどおり設計審査の場での人の議論です。
自動車業界の手引きなど、決まった様式に合わせられますか?
自社や顧客が指定する様式の列と書き方をAIに渡せば、その形で下書きさせることはできます。ただし、手引きの解釈や評価の付け方の判断は人が持ちます。様式に合わせたかどうかの最終確認も、手引きに詳しい担当者が行ってください。
まとめ ── AIは候補と指摘まで。先にデータをそろえ、1製品ファミリーから比べる
- FMEAのAI化は「候補を出す・照らす・指摘する」まで。評価と対策の決定は人が持ちます。
- 候補の質は不具合データで決まります。項目と言葉をそろえ、1件1行の表にしてから使います。海外工場の記録は原文を残して要約と項目を足します。
- 下書き係・照合係・点検係の3役に分け、各段で人が確かめます。根拠の記録が無い候補は表に入れません。
- 製品ファミリー1つ・過去の記録数十件から。人の作ったFMEAと比べ、作成時間と件数を測っておきます。
自社の不具合記録をどこから整えればよいか、いまのAI活用の段階を知りたい方は、まず生成AI活用レベル診断(無料)をお試しください。具体的なご相談はお問い合わせからどうぞ。
※ 本記事は2026年10月25日時点の情報にもとづいています。FMEAの説明は一般的な内容で、特定の手引きや規格の手順・評価の基準を示すものではありません。実際の作成は、自社や顧客が指定する手引き・様式に従ってください(自動車業界の手引きや国際規格の公式ページは、2026年10月25日に確認を試みましたが閲覧できなかったため、名称・版などは記載していません)。商談で伺った声は、企業が特定されないよう業種と規模だけにしています。紹介した進め方はカトルセが商談で提案している内容で、導入の実績や効果を示すものではありません。本記事に登場する製品名・サービス名は、それぞれの提供元の商標または登録商標です。
