FMEAとは？ハードウェアエンジニアのための実践ガイド

定義 — FMEAとは何か？

FMEAとは Failure Mode and Effects Analysis の略で、日本語では一般に 故障モード影響解析 と呼ばれます。

言葉は少しかたいですが、やっていることはシンプルです。製品や工程を見て、「何が壊れうるか」を考え、次に「壊れたら何が起きるか」を考え、最後に「そのリスクに対して何を打つべきか」を整理する手法です。

ハード設計をしている人なら、実は日常的にこの思考をしています。抵抗がオープンしたらどうなるか。コネクタが緩んだらどうなるか。センサがドリフトしたらADCはどんな値を返すか。FMEAは、そうした頭の中の設計勘を、チームでレビューできる形に落とし込むための方法です。

良いFMEAは、ただのExcel儀式ではありません。設計の弱点を早い段階であぶり出す、かなり実務的な会話のフレームです。

ここでいう「故障モード」は"どう壊れるか"で、「影響」は"その結果何が起きるか"です。そして「解析」は、リスクを評価し、既存対策を確認し、必要な追加対策を決める部分です。

現在の自動車業界を中心とした実務では、AIAG & VDA FMEA Handbook First Edition（2019年6月発行） が大きな基準になっており、従来の RPN中心の運用 から、7ステップ方式とAP（Action Priority）を重視する流れに移っています。

なぜFMEAがハードウェア設計で重要なのか

ハードウェアの不具合は、後で見つかるほど高くつきます。

ソフトウェアなら更新で救えることもありますが、回路定数のミス、熱設計の甘さ、故障経路の見落としは、試作や量産のやり直し、返品、現場不具合、場合によってはリコールにつながります。しかも厄介なのは、「今ここで少し面倒をかければ防げたはずの不具合」がかなり多いことです。

だからFMEAが効きます。試験で痛い目を見る前に、故障の筋道を先に洗い出す ためです。

これは車載だけの話ではありません。たとえば次のような製品でも同じです。

• IoT機器：電源変動やノイズの現場環境が厳しい
• 民生機器：コスト圧でマージンが削られやすい
• 産業機器：温度、振動、誤操作にさらされる
• 医療機器：安全性とリスク分析の結びつきが強い
• 航空宇宙・防衛：ミッションクリティカル性が高い

FMEAをやると、実務上かなり具体的なメリットがあります。

• システム境界やインターフェースが明確になる
• チーム内の"暗黙の前提"が見える化される
• ハード、ソフト、機構、生産の会話がつながる
• 対応優先度を整理しやすくなる
• 次の設計にも流用できる知見が残る

正直、FMEAは楽しい作業ではないです。でも、やらないことで後から払うコストの方がたいてい高い。そこが本質です。

FMEAの種類（DFMEA vs PFMEA）

FMEAには大きく分けて DFMEA と PFMEA があります。

DFMEA：Design FMEA

DFMEA は設計に対するFMEAです。製品アーキテクチャ、部品選定、インターフェース、許容差、環境ストレス、ロジック上の仮定などから、何が起きうるかを見ます。

例：

• サーミスタがオープンしてADC入力が飽和する
• 逆接保護が現実の誤配線条件に足りない
• デカップリング不足で負荷変動時にMCUがリセットする
• 筐体設計の甘さでコネクタ周辺に湿気が回り込む

つまり、モノを設計するときのFMEA です。

PFMEA：Process FMEA

PFMEA は工程に対するFMEAです。設計そのものではなく、実装、組立、検査、梱包、保守といった"作り方"に起因する失敗を見ます。

例：

• 実装工程で抵抗値違いが混入する
• はんだボイドで放熱信頼性が落ちる
• コネクタ締結トルクがばらつく
• 最終検査で断続不良を拾えない

つまり、モノを作るときのFMEA です。

どちらを先にやるべきか

スタートアップや小規模チームでは、まず DFMEAを優先 した方がいいことが多いです。設計が弱ければ、製造工程をいくら整えても根本は救えません。

ただし量産が見えてきたらPFMEAも重要です。"設計は良いのに工程で壊す"というのも、現場では普通に起きます。

具体的な作り方を知りたいなら、DFMEAの作り方：例つきステップバイステップガイド を読んでください。

FMEAを設計プロセスのいつ始めるべきか

答えはシンプルで、思っているより早く です。

多くのチームはFMEAを始めるのが遅すぎます。アーキテクチャがほぼ固まり、回路図も大体終わり、試作も終わってからFMEAを書く。これだと、FMEAは設計支援ではなく、単なる事後整理になります。

本来は逆です。

DFMEAは、システム境界、構成、部品戦略、インターフェース、設計前提をまだ変えられる段階で始めるのが理想です。AIAG & VDAの2019年版ハンドブックでも、計画、構造分析、機能分析、故障分析、リスク評価、最適化、結果整理という流れが整理されており、後追いではなく前倒しで使う前提が強いです。

実務上は、だいたい次のようなタイミング感です。

構想段階

対象範囲、システム境界、上位機能をざっくり決める

アーキテクチャ・回路設計段階

ここがDFMEAの本番です。構造も見えていて、まだ変更も効く

試作・評価段階

実測結果や故障知見をFMEAへ反映する

量産準備段階

設計判断の根拠や工程引き継ぎに使う

設計が固まってから始めると、FMEAは"検死報告書"になります。早く始めれば、"予防設計の道具"になります。

エンジニアがFMEAでやりがちな間違い

1. ただの書類仕事にしてしまう

一番ありがちな失敗です。

昔のテンプレートをコピーし、製品名だけ変えて、曖昧な言葉で埋める。見た目は整いますが、設計の意思決定に何も効きません。良いFMEAは、機能も故障モードも影響も対策も、ちゃんと具体的です。

2. 機能ではなく部品から書き始める

弱いFMEAは「R12オープン」と書きます。強いFMEAは「分圧機能が崩れてADC入力が飽和する」と書きます。

重要なのは、部品表ではなく機能とのつながりです。そこがないと、システムとしての意味が抜けます。

3. 古いRPNだけで判断する

従来は Severity × Occurrence × Detection = RPN で順位付けする運用が一般的でした。ただ、同じRPNでもリスクの意味がまるで違うことがあります。特に重大度が高い項目が、掛け算の中に埋もれやすいのが問題です。現在の自動車実務では、AP（Action Priority） によって優先度を判断する考え方が重視されています。

4. インターフェースを見ない

故障は部品の中だけで起こるわけではありません。

• センサ出力レンジとADC入力レンジ
• 電源シーケンス
• コネクタとハーネス
• ファームウェア前提とアナログ実態

こうした"境界面"で起きる不具合はとても多いです。部品単体だけ見ていると、そこを落とします。

5. 影響・原因・管理策をごちゃ混ぜにする

これは本当によくあります。

• 故障モード：サーミスタオープン
• 影響：高温誤警報
• 原因：はんだクラック、断線、接触不良
• 現在の管理策：ADC妥当性チェック、導通試験

この区別が曖昧になると、FMEA全体が急に読みにくくなります。

6. 評点の前提を揃えない

OccurrenceやDetectionの数字は、占いではありません。ラボ試作基準で考える人と、量産市場基準で考える人が同じ表に点を入れると、数字だけ揃って中身が揃いません。採点基準の共通認識が必要です。

7. 一度作って終わりにする

設計変更、評価結果、フィールド不具合が出たのに、FMEAを更新しない。それでは知見が蓄積しません。FMEAは"完成して終わる文書"ではなく、設計と一緒に育つべきものです。

現行の考え方や規格背景を整理したいなら、FMEA Standards: AIAG & VDA, IEC 60812, and Industry Requirements も合わせてどうぞ。

FAQ