FMEA（Failure Mode and Effects Analysis、故障モード影響解析）は、製品や工程が「どう壊れうるか」を部品・工程ごとに書き出し、その影響の重さと起こりやすさ、見つけやすさから対策の順番を決める手法です。この記事では、国際規格IEC 60812:2018の定義を起点に、設計向けのDFMEAと工程向けのPFMEAの違い、7ステップのやり方と記入例、RPNの計算と限界、自動車業界で広がるAP（処置優先度）を整理します。後半では、FTAやなぜなぜ分析との使い分けと、Excelの帳票が形骸化する原因、品質管理システムで管理する判断まで扱います。
まとめ：FMEAは故障を事前に潰す手法、評価はRPNからAPへ移りつつある
FMEAは、不具合が起きる前に「どの部品・工程が、どう故障し、何が起きるか」を表にして、対策の優先順位を決めるボトムアップの分析です。設計段階で使うのがDFMEA、製造工程で使うのがPFMEAで、自動車部品のサプライヤーでは顧客から提出を求められる場面が多くあります。
評価は、重大度・発生度・検出度を1〜10で採点して掛け合わせるRPNが長く使われてきました。ただしRPNは同じ点数でも危険度が違う組み合わせが生まれるため、AIAGとVDAの統一ハンドブックは重大度を最優先するAP（High／Medium／Low）を導入しています。
実務で先に押さえるのは2点です。一つは、重大度9〜10の項目はRPNの大小にかかわらず対策を検討すること。もう一つは、市場不具合や工程内不良が出たら発生度と検出度を書き直し、帳票を生きた状態に保つことです。後者が回らない組織では、FMEAは監査のための書類に変わります。
FMEAとは何か、故障モード影響解析の定義とIEC 60812の位置づけ
FMEAは、米軍が1949年に定めた手順書MIL-P-1629に起源を持つとされ、その後は航空宇宙・自動車・医療機器へと広がりました。現在の国際的な拠り所はIECの規格です。
IEC 60812:2018が定める対象範囲とFMECAとの関係
IEC 60812:2018（第3版・2018年8月発行・165ページ）は、FMEAとFMECAを計画し、実施し、文書化し、維持する方法を定めた規格です。適用対象はハードウェアだけでなく、ソフトウェア、人の作業を含む工程、それらのインターフェースまで含みます。第3版では、RPNの別の算出方法と、致命度マトリクスによる評価が追加されました。
FMECAは、影響の重大度を含めて致命度を順位付けする場合の呼び名です。日本ではこの規格に対応するJISとして、JIS C 5750-4-3:2021が発行されています。取引先から「FMEA」と「FMECA」のどちらを求められているかは、採点の仕組みが違うため最初に確認します。
故障モード・故障の影響・故障の原因を帳票の別々の列に分けて書く理由
FMEAの表で最も混同されやすいのが、故障モードと影響と原因の3列です。例えばブレーキホースなら、故障モードは「亀裂による液漏れ」、影響は「制動力の低下」、原因は「曲げ半径不足による応力集中」と書き分けます。
ここが混ざると、対策が「制動力を上げる」のような結果への手当てになり、原因側の設計変更につながりません。故障モードは部品や工程が機能を果たせない状態、影響はお客様や次工程が受ける結果、原因はその状態を生む仕組み、と書き手全員で定義をそろえてから表を埋めます。
DFMEAとPFMEAの違い、設計段階と工程段階で対象と担当が変わる理由
FMEAには対象の違いでいくつかの種類があります。AIAG & VDA FMEAハンドブックは、Design FMEA、Process FMEA、監視とシステム応答を扱う補足のFMEA-MSRの3つを対象にしています。
DFMEAは図面と仕様、PFMEAは工程フローと作業標準を対象にする
| 観点 | DFMEA（設計FMEA） | PFMEA（工程FMEA） |
|---|---|---|
| 分析の対象 | 部品・材料・寸法・仕様 | 工程フロー・設備・作業手順 |
| 主な担当 | 設計・開発部門 | 生産技術・製造・品質部門 |
| 実施の時期 | 試作前の設計段階 | 量産準備から工程変更のたび |
| 主な成果物 | 設計変更・評価試験計画 | コントロールプラン・作業標準 |
両者は独立した書類ではありません。DFMEAで重大度が高いと判定した特性は、PFMEAで「その特性を作り込む工程」として引き継がれ、検査方法と頻度がコントロールプランに落ちます。この受け渡しが切れると、設計が警告した特性を工程側が通常品質として扱う事故が起きます。
ソフトウェアやサービス工程にFMEAを広げるときの採点と検出の注意点
IEC 60812はソフトウェアも適用対象に含めており、システム開発でも機能ごとに「入力が欠ける」「処理が二重に走る」といった故障モードを洗い出す使い方ができます。ただし、ソフトウェアには部品の摩耗のような確率的な故障が少なく、発生度の採点根拠が弱くなりがちです。
システム開発では、FMEAを設計レビューの観点表として使い、検出はテスト設計に結びつける形が現実的です。工程別のレビューとテストの管理は、システム開発の品質管理を工程別レビューとメトリクスで整理した記事で扱っています。
FMEAのやり方7ステップと記入例、ワークシートの列と書く順番
AIAG & VDAのハンドブック（2019年発行）は、それまで各社でばらばらだった手順を7つのステップに統一しました。
計画から文書化までの7ステップと、各ステップで整理する情報と成果物
- 計画と準備：対象範囲・期限・チーム・前回のFMEAを決める
- 構造分析：システム・部品（または工程・作業要素）を階層に分解する
- 機能分析：各要素の機能と要求値を書く
- 故障分析：故障モード・影響・原因の連鎖を結ぶ
- リスク分析：現行の予防策・検出策を書き、重大度・発生度・検出度を採点する
- 改善策の決定：優先度の高い項目に処置・担当・期限を割り当てる
- 結果の文書化：結論を関係者と顧客へ報告し、記録を残す
旧来の手順との大きな違いは、ステップ2と3で構造と機能を先に固める点にあります。いきなり故障モードを思いつく順に書くと抜けが出るため、構造ツリーから順に機能を当て、その機能が果たせない状態として故障モードを導きます。
PFMEAの記入例、はんだ付け工程で原因と対策の列を1行ずつ埋める手順
基板のはんだ付け工程を例に、1行分を埋めると次のようになります。
| 列 | 記入内容 |
|---|---|
| 工程・機能 | リフローではんだ接合を形成する |
| 故障モード | はんだ未溶融による接合不良 |
| 影響（重大度S） | 出荷後の導通不良・製品停止（S=8） |
| 原因（発生度O） | 炉内温度プロファイルのずれ（O=4） |
| 現行の検出策（検出度D） | 外観検査の抜き取り（D=6） |
| 処置 | 炉温の連続監視とX線検査の追加 |
処置を実施したら、同じ行でSODを採点し直し、処置前後の差を残します。採点し直さない帳票は、対策が効いたのかを後から誰も説明できません。
RPNの計算方法と限界、AIAG & VDAのAP（処置優先度）へ移る理由
FMEAの評価で必ず出てくるのがRPN（Risk Priority Number、リスク優先数）です。計算は単純ですが、点数の読み方に落とし穴があります。
RPNは重大度×発生度×検出度、1〜1000の値で故障のリスクを比べる
RPNは、重大度（Severity）・発生度（Occurrence）・検出度（Detection）をそれぞれ1〜10で採点し、掛け合わせた値です。最小は1、最大は1000になります。先ほどのはんだ付けの例では、8×4×6で192です。
多くの社内基準は「RPN100以上は対策必須」のような閾値を置いています。ただ、この閾値に規格上の根拠はありません。採点表の定義が部署ごとに違えば、同じ故障でも点数が変わるため、採点基準表を全社で1つにそろえることが閾値より先です。
同じRPNでも危険度が違う問題と、重大度を重く見るAPの判定の考え方
RPNの弱点は、掛け算が重みを消してしまう点です。S=9・O=2・D=2のRPNは36、S=3・O=4・D=3も36になります。前者は人命や法規に関わる故障がまれに起きる状態で、後者は軽微な不具合がときどき起きる状態です。同点として並べると、対策の順番を誤ります。
AIAG & VDAのハンドブックが導入したAPは、重大度を最も重く、次に発生度、最後に検出度という順で重みを付け、組み合わせごとにHigh・Medium・Lowを割り当てる表です。Highは予防策か検出策を改善する処置を講じるか、現状で十分な理由を示す必要があり、Mediumは処置を検討して見送るなら理由を残します。自動車の取引で新ハンドブックへの準拠を求められたら、RPNの閾値運用からAPの判定表へ切り替える必要があります。
FTA・DRBFM・なぜなぜ分析との違いと、問題の段階に応じた使い分け
品質の分析手法は似た目的を持つものが多く、取り違えると工数ばかりかかります。使い分けの軸は「起きる前か後か」と「下から積むか上から掘るか」の2つです。
FMEAは部品から結果へ、FTAは結果から原因へ向かう分析手法の違い
| 手法 | 向き | 主な使いどころ |
|---|---|---|
| FMEA | 部品・工程から影響へ（ボトムアップ） | 新規設計・新工程の網羅的な洗い出し |
| FTA | 望ましくない事象から原因へ（トップダウン） | 重大事故1件の発生経路と確率の分析 |
| DRBFM | 変更点から影響へ | 既存設計の一部変更時の心配点の洗い出し |
| なぜなぜ分析 | 発生した不具合から真因へ | 起きた問題の再発防止 |
FMEAとFTAは対立する手法ではありません。FMEAで重大度10と判定した影響を頂上事象にしてFTAで経路を掘る、という組み合わせが典型です。変更が小さい流用設計なら、全項目をFMEAで洗い直すより、変更点に絞るDRBFMのほうが工数を抑えられます。
すでに起きた不具合の原因分析はなぜなぜ分析と特性要因図に渡す
FMEAは未然防止の道具なので、すでに起きた不具合の真因を探す場面には向きません。市場不具合や工程内不良が出たら、特性要因図で4M・5Mの要因を広げる手順や、なぜなぜ分析で真因まで掘り下げる手順で原因を特定します。
そこで分かった原因は、FMEAの該当行に戻して発生度と検出度を書き直します。事後の分析と事前の分析をこの往復でつなげるかどうかが、FMEAが書類で終わるか、設計の知見として残るかの分かれ目です。
FMEAが形骸化する失敗パターンと、Excel管理から品質管理システムへ移す判断
FMEAの失敗の多くは手法ではなく運用で起きます。特にExcelの帳票で管理している現場では、同じ型の問題が繰り返し見られます。
類似品のコピーで作った帳票が更新されず、監査用の書類になる失敗
最も多いのは、類似品のFMEAをコピーして品番だけ書き換える運用です。発生度と検出度は元の製品の値のまま残り、新しい材料や設備の故障モードは追加されません。もう一つは、不具合が出ても帳票が更新されない状態です。品質保証部門の不適合記録とFMEAが別のファイルにあり、誰も突き合わせていません。
形骸化の兆候を見分ける手掛かりは、単純な数字です。過去1年の工程内不良・市場不具合の件数に対し、FMEAの改訂件数が極端に少なければ、帳票は現場から切り離されています。検査記録と不適合管理の回し方は、製造業の受入・工程内・出荷検査と不適合管理を整理した記事が参考になります。
Excelの帳票から品質管理システムへ移す条件と導入を見送る場面
システム化を検討してよいのは、次のどれかに当てはまる場合です。製品・工程のFMEAが数十本を超え、共通部品の故障モードを横断して探す必要がある。DFMEAの特殊特性をPFMEAとコントロールプランへ自動で引き継ぎたい。不適合記録から該当するFMEAの行へたどれる状態を、顧客監査で示す必要がある。
逆に、FMEAが年に数本で、担当者が2〜3名に限られる工場では、システム化は過剰です。採点基準表の統一と、改訂履歴のシートを足したExcel運用で十分に回ります。導入を決める場合も、費用と効果を大きく左右するのは、FMEA単体のツールにするか、検査記録や不適合管理と同じ基盤に載せるかという選択です。製品タイプごとの違いは品質管理システムの製品タイプ別比較で整理しています。既存の生産管理と工程・ロット情報をつなげたい場合は、生産管理システム開発の一部として、FMEAと不適合記録を同じデータで扱う設計を相談できます。
FMEAについてよくある質問、RPNの基準値やソフトウェアへの適用まで
FMEAを初めて担当する方から寄せられやすい質問をまとめます。
FMEAとFMECAは何が違いますか？
FMECAは、FMEAに致命度（Criticality）の評価を加えた分析です。IEC 60812:2018では、少なくとも影響の重大度を含めて致命度を順位付けする場合にFMECAと呼ぶと定義しています。実務上は、RPNやAPで優先度を付ける自動車業界のFMEAも、致命度マトリクスで評価する航空宇宙・防衛のFMECAも、表の基本構造は同じです。違いは採点の方法にあるため、顧客の指定する様式と評価基準を最初に確認してください。
RPNはいくつ以上なら対策が必要ですか？
規格で決まった基準値はありません。社内基準として100や120を閾値にする例はありますが、同じRPNでも重大度の高い組み合わせと低い組み合わせが混ざるため、閾値だけで判断すると危険です。少なくとも重大度9〜10の項目はRPNにかかわらず対策を検討する、というルールを併せて置きます。自動車業界でAIAG & VDAのハンドブックに準拠する場合は、RPNではなくAPのHigh・Medium・Lowで判定します。
FMEAはいつ、誰が作成するものですか？
DFMEAは設計の構想がまとまり、試作図面を出す前に設計部門が中心となって作成します。PFMEAは工程フローが決まった量産準備の段階で、生産技術・製造・品質の担当者が集まって作成します。どちらも1人で書くと視点が偏るため、設計・製造・品質・購買など異なる部門から4〜6名程度のチームで行うのが一般的です。作成後も設計変更や工程変更、不具合の発生のたびに改訂します。
FMEAはソフトウェア開発にも使えますか？
使えます。IEC 60812:2018はソフトウェアも適用対象に含めています。機能や処理単位を構造として分解し、「入力の欠落」「タイムアウト」「二重登録」などを故障モードとして洗い出す使い方です。ただしソフトウェアは発生度の根拠となる故障率データが乏しいため、採点よりも、洗い出した故障モードをテストケースとレビュー観点に落とすことに重心を置くほうが成果につながります。
医療機器や自動車以外の業界でもFMEAは使われますか？
使われています。医療機器では、リスクマネジメントの国際規格ISO 14971:2019に沿ったリスク分析の手段の一つとして、FMEAが広く用いられています。ほかにも食品工場の工程管理、物流センターの作業設計、ITサービスの障害対策など、工程と故障を分解できる対象であれば適用が可能です。業界の規格や顧客が様式を指定していない場合は、IEC 60812の手順を土台に社内の採点基準を定めるのが無難です。
関連記事
- 品質管理と品質保証の違いとは？QCとQAの役割分担・QC7つ道具・システム化の判断まで解説：FMEAを含む品質保証の仕組み全体の中での位置づけ
- 品質管理システムとは？機能・種類と選び方、パッケージ導入か自社開発かの判断まで解説：FMEAや不適合記録を管理するシステムの機能と選び方
- 品質管理システムを中小企業が入れるには：検査記録から始める段階導入と費用・補助金2026：小規模な工場でFMEAを含む品質記録を段階的にシステム化する進め方
