dfmea-design

設計FMEA（DFMEA）— AIAG-VDA 2019

目標

機能、インターフェース、故障モードを分析して設計リスクを特定し、軽減します。これにより、製造へのリリース前に設計上の弱点を解消し、その結果をDVP、PFMEA、コントロールプランに直接反映します。

必須実施チェックリスト

• DFMEAの範囲を定義済み：境界図が完成し、境界の内側と外側を特定済み
• 製品階層をマッピング済み：システム → サブシステム → コンポーネント → インターフェース（ステップ2）
• すべてのインターフェースを特定済み — 内部（コンポーネント間）、外部（環境）、ユーザー／組み立て
• すべての機能を動詞＋名詞＋測定可能な規格で定義済み（ステップ3）
• 各機能について、DVPで測定可能な検証方法を確認済み
• 各機能について、故障の連鎖を完了済み：影響 → モード → 原因（ステップ4）
• すべての故障原因を工学的解析（FEA、計算）または試験の証拠で検証済み — 仮定に基づいていない
• S/O/Dの評価を解析、試験データ、または設計履歴に基づいて正当化済み
• すべてのH-AP項目について、アクション、担当者、目標日を定義済み
• 製造へのリリース前に、DFMEA → DVP、PFMEA、図面の連携を検証済み

---

使用するタイミング

• 新製品開発（APQPフェーズ2 — 製品設計・開発に組み込む）
• 設計変更または設計変更要求（ECR）
• 設計に根本原因があることが判明した市場故障の調査
• 定期設計レビュー
• 製造への引き継ぎ前（DFMEAがPFMEAを導きます）

PFMEAとの主な違い： DFMEAでは設計意図と設計の堅牢性を分析します。PFMEAでは製造プロセスを分析します。DFMEAが先に行われます — DFMEAの故障影響と重大度評価がPFMEAの情報源になります。

前提条件

• 製品要求事項／仕様書（設計図面、顧客仕様書）
• システムブロック図または製品構成図
• インターフェースマトリックス（システムレベルの分析の場合）
• チーム：設計エンジニア、システムエンジニア、品質エンジニア、信頼性担当者（可能な場合）

DFMEAにおけるAIAG-VDA 2019の7ステップアプローチ

---

ステップ1 — 計画と準備

範囲を定義します：

• 分析対象： コンポーネント、サブシステム、またはシステム
• 顧客： 次の階層の組立先は誰ですか？ エンドユーザーは誰ですか？
• 境界図： DFMEAの範囲の内側と外側に何があるか
• インターフェースマトリックス： このコンポーネントと相互作用するものは何か（機械、電気、熱、化学）？

---

ステップ2 — 構造分析（設計階層）

製品階層をマッピングします：

System (e.g., Steering Column)
└── Subsystem (e.g., Tilt Mechanism)
    └── Component (e.g., Pivot Pin)
        └── Interface (e.g., Pin-to-Bracket contact)

インターフェースマトリックス： 各コンポーネントについて、以下を特定します：

• 他のコンポーネントとのインターフェース（内部）
• 環境とのインターフェース（外部）：熱、振動、腐食、電磁気
• ユーザーまたは組み立てプロセスとのインターフェース

設計故障の大半はインターフェースで発生します。各インターフェースは、単に共有するコンポーネントだけでなく、それ自体が潜在的な故障箇所として分析されなければなりません。実際には、DFMEAの工数の少なくとも50%をインターフェースと相互作用に充てる必要があります。コンポーネントだけを分析すると、最も一般的な市場故障モードを見落とします。

---

ステップ3 — 機能分析

構造内の各要素について、設計機能を定義します：

形式： 動詞＋名詞＋測定可能な規格

例：

• コンポーネントの機能：「永久変形することなく、50 Nm ± 5 Nmのトルクを伝達する」
• インターフェースの機能：「-40°Cから+120°Cまでの範囲で、2.5 barの圧力におけるシール性を維持する」
• システムの機能：「< 50msの遅延でステアリング角度のフィードバックを提供する」

図面から特殊特性を特定します — これらはステップ5でS = 9または10になります。

試験可能性のルール： すべての機能は測定可能かつ検証可能でなければなりません — DVPに試験または解析の方法が存在する必要があります。検証方法のない機能には、ステップ5で信頼できるD評価を付けることができません。

---

ステップ 4 — 故障分析

DFMEA の故障連鎖：故障影響 → 故障モード → 故障原因

故障影響（FE）：

• エンドユーザーへの影響：安全上の危険、主要機能の喪失、性能の低下
• 車両／システムへの影響：隣接部品の損傷、二次故障
• 製造への影響（部品が仕様を満たさない場合）：組み立て不能、手直し

故障モード（FM）： この部品は、設計上の機能をどのように果たせなくなりますか？

• 破断、摩耗、腐食、変形、信号喪失、漏れ、寸法ドリフト、電気的短絡／断線

故障原因（FC）： どの設計パラメーターまたは設計判断が故障モードを引き起こしますか？

• 材料強度不足（材質の選定違い、不適切な熱処理）
• 不適切な形状（応力集中、肉厚不足）
• 熱膨張の不整合
• 使用環境に対する防食性能の不足
• 公差の積み上がりによる干渉
• 組み立てのばらつきを考慮していないインターフェース設計

故障原因の検証： 故障原因は、工学解析（FEA、構造計算、熱シミュレーション）または試験のエビデンスを用いて検証する必要があります。「おそらく」「可能性が高い」「かもしれない」といった未検証の仮定は、最終的な故障原因として認められません。特定した故障モードとその原因の両方を裏付けるために、CAE（FEA、シミュレーション）、試験データ、フィールド返却データを使用してください。市場投入後の故障を受けた DFMEA の更新では、FC は 8D またはフィールド調査で検証された根本原因と一致している必要があります。

---

ステップ 5 — リスク分析

PFMEA と同じ S/O/D 評価および AP テーブルを使用します（テーブルについては action-priority-ap と pfmea-process を参照してください）。

DFMEA 固有の主な注意事項：

**DFMEA における発生度（O）**では、以下を考慮します。

• 設計の成熟度（新規設計の場合は O が高くなります）
• 類似設計の履歴（類似設計で同じ故障が発生している場合は O が高くなります）
• 予防管理：設計レビュー、CAE／FEA、DVP 試験

**DFMEA における検出度（D）**では、以下を考慮します。

• 設計検証試験（DVP）
• 工学解析（FEA、シミュレーション）
• チェックリストを用いた設計レビュー
• 試作試験

D = 10 は、この故障モードに対する設計検証がないことを意味します。これは新機能ではよくあることであり、DVP の策定につながります。

評価の根拠： すべての S/O/D 評価は、解析、試験データ、または設計履歴を用いて根拠を示す必要があります。根拠が文書化されていない評価は、OEM 監査に耐えられません。類似部品の設計履歴がある場合は、明示的に参照してください。データがない場合は、O と D を暫定評価として記載し、確認に使用する DVP 項目を明記してください。

---

ステップ 6 — 最適化

DFMEA の H-AP 項目に対するアクションは、通常、以下のいずれかに該当します。

1. 設計変更： 形状、材料、公差、またはコーティングを変更する
2. 設計検証の追加： 設計が要求を満たすことを確認する DVP 試験項目を追加する
3. 予防策の追加： 設計ガイドライン、DFM／DFA ルール、規格の参照を追加する
4. 検出の改善： DVP または設計レビューのチェックリストに検査要件を追加する

DFMEA → DVP の連携： 検出管理（D 評価の改善）にはすべて、設計検証計画（DVP）の対応する項目が必要です。「試験を実施する」ことで D を改善する場合、その試験は DVP に記載されていなければなりません。

アクションの追跡管理： すべてのアクションは、試験結果、シミュレーション出力、更新した解析など、客観的なエビデンスをもって完了まで追跡管理する必要があります。検証エビデンスなしに「完了」とされたアクションは認められません。目標日を過ぎても未完了の H-AP 項目は、設計レビュー責任者またはプログラムマネージャーにエスカレーションし、改定日と遅延理由を文書化する必要があります。

---

ステップ 7 — 結果の文書化

他の APQP 文書に反映する DFMEA の成果：

• DFMEA で特定された特殊特性 → コントロールプランおよび PFMEA に反映
• 検出管理 → DVP 項目
• インターフェースの故障モード → PFMEA の構造分析への入力
• 確認済みの材料／形状要件 → 発行済み図面

DFMEA → PFMEA の引き継ぎ

DFMEA と PFMEA は連携しています。

DFMEA	→	PFMEA
設計故障の影響（エンドユーザーへの影響）	→	PFMEA の重大度評価
重要特性	→	PFMEA の工程ステップにおける SC のフラグ付け
インターフェースの故障モード	→	組立ステップにおける PFMEA の故障モード
設計意図（機能）	→	工程ステップの機能要件

DFMEA の必須レビューイベント（APQP / IATF 16949 §8.3）

トリガー	必要な対応
新製品開発	APQP フェーズ 2 で DFMEA を開始します。設計凍結の前に着手してください。設計凍結後に開始した DFMEA には、是正効果がありません。
エンジニアリング変更要求（ECR）	変更の影響を受けるすべての機能、故障モード、インターフェースについて、変更のリリース前に DFMEA をレビューして更新します。
設計マイルストーン／設計レビュー	未解決の H-AP 項目、アクション、改訂後の評価を含め、DFMEA の状況を提示します。各ゲートで DFMEA を最新の状態にしておく必要があります。
設計が根本原因と確認された市場故障	8D／市場調査で検証された根本原因に合わせて、FC、評価、アクションを更新します。故障モードを含めるよう DVP を更新します。

プログラムのライフサイクルを通じて更新されない DFMEA は、設計品質保証の欠落であり、生きた文書ではありません。

よくある間違い

• 設計凍結後に DFMEA を開始する — 変更できない場合、DFMEA に価値はありません
• コンポーネントのみを分析し、インターフェースを分析しない — 設計故障の大半はインターフェース故障です
• DVP テストを追加せずに D を改善する — 実際のテストを行わずに検出の評価を得ています
• DFMEA チームと PFMEA チームが連携しない — 重大度評価と重要特性を共有する必要があります

出力形式

各利用の開始時に、ユーザーに次のように尋ねます。

"出力はどの形式で受け取りますか？ A — 構造化された Markdown（書式付きの表とセクション、そのままコピーできます） B — プレーンな表（Excel または Word 向けの簡略化された構成） C — 説明形式のレポート（正式な文書やメール向けの流れるような文章）

デフォルト：A。"

選択された形式に合わせて、すべての出力セクションを調整します。プラットフォームまたはセッションのコンテキストですでに形式の希望が定義されている場合は、この質問を省略します。

参考ファイル

• インターフェースマトリックス作成ガイド

変更履歴

バージョン	日付	作成者	変更内容
1.0	2026-06-01	@RBraga01	初回リリース
1.1	2026-06-03	@RBraga01	インターフェースマトリックスの統合と DFMEA から PFMEA への引き継ぎワークフローを追加