DFMEAの作り方：例つきステップバイステップガイド

DFMEA作成手順 — 構造分析から最適化までの8ステップ
DFMEA作成フロー：構造定義から最適化までの8ステップ

始める前に必要なもの

最初に大事なことを言うと、DFMEAはExcelを開いた瞬間には始まりません。

役に立つDFMEAは、まず設計の文脈が揃っていることが前提です。対象範囲も曖昧、機能も曖昧、インターフェースも曖昧なまま、いきなりSeverityやOccurrenceやDetectionの点数を入れ始めると、見た目だけ立派な表ができます。中身はかなり危ないです。

始める前に、最低でも次を用意したいです。

ハードウェアなら、設計者1人だけで閉じるより、システム観点を持つ人、テストや信頼性や製造を知る人が少しでも入ると精度が上がります。

今の主流に近い考え方としては、AIAG & VDA FMEA Handbook（2019）の7ステップがよく参照されます。車載でなくても、この流れはかなり使いやすいです。構造→機能→故障→リスク→改善という筋が通るからです。

FMEAそのものの基礎から整理したい場合は、先にFMEAとは？ハードウェアエンジニアのための実践ガイドを読むと入りやすいです。

Step 1 — 構造分析（スコープとシステム境界の定義）

最初のステップは、何を対象として解析するのかをはっきりさせること です。

ここ、意外と甘くなりがちです。「温度センサ回路をDFMEAします」と言いながら、ある人はサーミスタだけを見ていて、別の人はADC入力まで含めていて、さらに別の人はハーネスやコネクタまで含めている。これだと会話が噛み合いません。

構造分析では、対象をシステム、サブシステム、要素へと分解して関係を整理します。

温度センシング回路の例なら、こんな感じです。

この段階で大事なのは、全員が同じ対象を見ている状態を作ること です。

実務上のコツ：

ここが曖昧だと、次の機能分析も故障分析も全部ぼやけます。

Step 2 — 機能分析（各要素は何をするべきか？）

構造が見えたら、次は各要素が何をするべきかを定義します。

ここでも手を抜きやすいです。たとえば「サーミスタ」と書いてしまう。でもそれは部品名であって、機能ではありません。

機能は、動作や役割として書く のが基本です。

例：

機能分析がしっかりしていると、設計意図と故障ロジックがきれいにつながります。

この段階で、できれば要求も添えます：動作範囲、精度目標、応答時間、電源範囲、温度範囲、ノイズ耐性、フォールト時の期待挙動。

要求がないと、どこからが"失敗"か判断しづらいです。

Step 3 — 故障分析（何がおかしくなりうるか？）

ここで、いわゆる故障モードを洗い出します。

温度センサ回路の例なら、次のようなものが考えられます。

ただ、単に物理的な壊れ方を並べるだけでは弱いです。機能とのつながりまで書くのが大事です。

たとえば：

ここでの基本姿勢は、「その要素が本来の機能を果たさなくなったら、次に何が起きるか」を筋道で書くことです。

それが良いDFMEAの背骨になります。

Step 4 — 影響分析と重大度（S）

故障モードが見えたら、次は影響（Effect）を書きます。

影響は複数レベルで考えると整理しやすいです。

サーミスタオープンの例なら：

そのうえでSeverity（重大度）を決めます。

重大度は、起きたときにどれだけ深刻か であって、発生頻度ではありません。

例：

採点スケール自体は社内基準に依存しますが、原則は同じです。重大度は"結果"に対して付くものです。

「でもこの故障はめったに起きないからSeverityは低めで」これはダメです。起きにくさはOccurrenceの話です。

Step 5 — 原因分析と発生度（O）

次に、なぜその故障モードが起きるのか を考えます。

サーミスタオープンなら、原因候補はたとえば次です。

そのうえでOccurrence（発生度）を決めます。

発生度は、設計、環境、過去実績、部品品質などを踏まえて、その原因がどれくらい起きそうかを見ます。

例：

発生度は勘だけで決めない方がいいです。できれば次を使います：過去不具合、評価試験結果、故障物理の知見、使用環境、部品信頼性情報、製造成熟度。

データが薄いなら、「暫定評価」であることを明記した方が健全です。

Step 6 — 現在の管理策と検出度（D）

次に、今ある管理策 を洗い出します。

ここでいう管理策は、原因を防ぐもの、または故障をユーザ到達前に見つけるものです。

ハードDFMEAでは、たとえばこんなものがあります。

サーミスタオープンなら：

そしてDetection（検出度）を付けます。

検出度は、今ある管理策で、その問題をどれくらい確実に見つけられるか を示します。

例：

注意したいのは、"管理策っぽい希望"を管理策と呼ばないことです。「ベテランが見るから大丈夫」「たぶん試験で見つかる」は管理策ではありません。ちゃんとした手段とカバレッジが必要です。

Step 7 — アクション優先度（AP）とリスク評価

ここが、古いFMEA運用と新しい実務感覚が分かれるポイントです。

昔ながらのやり方では、S × O × D = RPN を計算し、その数字順に並べることが多かったです。でも、これには問題があります。同じRPNでも意味が全然違う組み合わせがあり、高Severityの問題が見えにくくなることがあります。

AIAG & VDA 2019では、こうした弱点を補うためにAP（Action Priority）が重視されます。つまり、「何点だったか」よりも、「この組み合わせなら対策を強く推奨すべきか」を見る考え方です。

実務上は、次の3段階で扱うことが多いです。

簡易例：

正確な判定は、組織で使うAP表に従うべきですが、本質は同じです。掛け算の見た目のきれいさに、設計判断を丸投げしないこと。

APの背景にある考え方や規格面を知りたいなら、FMEA規格：AIAG & VDA, IEC 60812, 業界要求事項を参照してください。

Step 8 — 最適化（対策と再評価）

DFMEAは、書いて終わりなら価値が半減します。設計を変えるために使ってこそ意味があります。

HighやMediumの項目に対して、Occurrenceを下げる、Detectionを上げる、あるいは故障経路そのものを潰すアクションを決めます。

サーミスタオープンの例なら：

そして、対策後に再評価します。

対策前：

対策後：

ここで大事なのは、Severityが変わらないのは普通だということです。故障したときの影響の重さは同じでも、起きにくくしたり、見つけやすくしたりできるわけです。

実践例：温度センサ回路のDFMEA

ここでは、次のシンプルな温度センシング回路を例にします：NTCサーミスタ → 分圧抵抗 → デカップリングコンデンサ → MCU ADC入力

回路の機能：この回路の目的は、温度を電圧に変換してADCへ入力し、MCUが要求精度内で温度を算出できるようにすることです。

Row 1 — サーミスタオープン

想定アクション：オープン故障専用の診断しきい値を追加、ストレス対策を強化、断線フォールト試験を実施

Row 2 — 分圧抵抗のドリフト

想定アクション：より良い温度係数・精度の抵抗に変更、キャリブレーションや妥当性チェックを追加、実装検証を強化

Row 3 — ADC入力へのノイズ混入

想定アクション：配線とGNDを見直す、RCフィルタ定数を最適化する、実負荷条件でノイズ評価を追加する

この例はシンプルですが、考え方はそのまま広げられます。バッテリ電圧監視、圧力センサ、電流検出、モータドライバ、電源監視などでも同じです。

そして正直に言うと、こういう Step 3〜7の繰り返し は、構造と機能がきちんと定義されていればツールでかなり効率化しやすい部分でもあります。

最初のたたき台を作りたいなら、FMEAテンプレートから始めるのもやりやすいです。

FAQ

Q: FMEAはどの手順で作ればいいですか？

A: 実務的には次の流れです。(1) 対象構造と境界を決める、(2) 機能を定義する、(3) 故障モードを洗い出す、(4) 影響を分析してSeverityを付ける、(5) 原因を分析してOccurrenceを付ける、(6) 現在の管理策を整理してDetectionを付ける、(7) APで優先度を判断する、(8) 対策して再評価する。

Q: DFMEAを始める前に必要なものは何ですか？

A: 少なくとも、スコープ、構造、機能、インターフェース、設計前提が必要です。

Q: RPNよりAPを使うべきですか？

A: 現在の自動車寄りの実務では、AP（Action Priority）が重視されます。RPNだけだと、重大な問題が数値上埋もれることがあるためです。

Q: 小さなハードウェアチームでもDFMEAはできますか？

A: できます。むしろ少人数チームほど、後戻りコストを減らすために有効です。重要なのは、大企業っぽい書類を作ることではなく、設計に効く粒度でやることです。

Q: DFMEAの練習に向いた題材は何ですか？

A: 温度センサ回路や電源監視回路のような、機能と故障経路が見えやすい回路が練習に向いています。

EXITON FMEAを試す — 30日間無料

KiCad回路図からAIAG & VDA準拠のDFMEAを生成。クレジットカード不要。

無料トライアルをダウンロード