▶ 今回のシミュレーター: FMEA RPN リスク優先度 シミュレーター （ブラウザで動作・登録不要）
「RPNが100超えたら危険」という都市伝説
「RPNが100を超えたら対策必須」。これを聞いたこと、ありませんか？
実は、そんなルールはどこにもありません。
AIAG（Automotive Industry Action Group）のFMEAハンドブックにも、ISO 26262の機能安全規格にも、「RPNのしきい値は◯◯」なんて絶対基準は書かれていないんです。
むしろ、S（深刻度）が10の「警告なしで人命に関わる故障」は、RPNがたとえ30でも最優先で対策すべき。一方、S=3でD=10（まったく検知できないけど大した影響じゃない）のRPN=300は、コスト対効果で対策を見送ることもある。
数字の大小より、中身を読め ── これがFMEAの本質です。
でも、じゃあどうやって「中身を読む」のか？ その答えが、今回のシミュレーターが提供する3つの視点にあります。
ざっくり本質 ── 「壊れ方の3つの顔」を見える化する
FMEAでやっていることは、実はすごくシンプルです。
製品や工程の「壊れ方（故障モード）」に対して、3つの質問をするだけ。
- それが起きたら、どれだけヤバイか？（深刻度 S）
- どれくらいの頻度で起きるか？（発生頻度 O）
- 起きても気づけるか？（検知性 D）
この3つをそれぞれ1〜10で評価して、掛け算した値がRPN（リスク優先度）です。
「RPNはリスクの『総合点』ではなく、『3つの角度から見た立体地図』なんです」
数式で理解する
FMEAの根幹は、たった1つの式です。
RPN = S \times O \times D
ただし、各パラメータは以下の意味を持ちます。
- S（Severity：深刻度）：1〜10の整数。顧客や法規への影響度。10は「警告なしで安全上の危険」、1は「影響なし」。
- O（Occurrence：発生頻度）：1〜10の整数。故障が発生する確率や頻度。10は「ほぼ毎回発生」、1は「極めて稀」。
- D（Detection：検知性）：1〜10の整数。検知の難しさ。10は「検知できない」、1は「確実に検知できる」。
重要なのは、Dは「検知のしやすさ」ではなく「検知の難しさ」だということ。 ここを間違えると、RPNの解釈がガラリと変わってしまいます。
RPNの取りうる範囲は：
1 \leq RPN \leq 1000
なぜなら最小は $1 \times 1 \times 1 = 1$、最大は $10 \times 10 \times 10 = 1000$ だからです。
コードで実装する ★最重要★
さて、ここからが本番です。上記の計算ロジックを、実際に動くJavaScriptコードで再現してみましょう。
このコードは、シミュレーターの核となる機能 ── S, O, Dの入力からRPNを計算し、しきい値フィルタ、パレート図のデータ生成、対策前後比較まで ── をカバーしています。
/**
* FMEA RPN シミュレーター コアエンジン
* AIAG FMEA第5版に準拠
*/
class FMEACalculator {
constructor() {
this.failureModes = [];
}
/**
* 故障モードを追加
* @param {string} name - 故障モード名
* @param {number} S - 深刻度 (1-10)
* @param {number} O - 発生頻度 (1-10)
* @param {number} D - 検知性 (1-10)
* @param {object} countermeasure - 対策後評価（任意）
*/
addFailureMode(name, S, O, D, countermeasure = null) {
// 入力値のバリデーション
if (![S, O, D].every(v => Number.isInteger(v) && v >= 1 && v <= 10)) {
throw new Error('S, O, D は 1〜10 の整数で指定してください');
}
const mode = {
name,
S, O, D,
RPN: S * O * D,
// 対策後評価があれば計算
after: countermeasure ? {
S: countermeasure.S || S,
O: countermeasure.O || O,
D: countermeasure.D || D,
RPN: (countermeasure.S || S) * (countermeasure.O || O) * (countermeasure.D || D)
} : null
};
this.failureModes.push(mode);
return mode;
}
/**
* しきい値フィルタリング
* @param {number} threshold - RPNしきい値
* @returns {Array} フィルタリングされた故障モード一覧
*/
filterByThreshold(threshold) {
return this.failureModes.filter(m => m.RPN >= threshold);
}
/**
* パレート図用データ生成（累積RPN割合計算）
* @returns {Array} RPN降順にソートされたデータ
*/
getParetoData() {
// RPN降順にソート
const sorted = [...this.failureModes].sort((a, b) => b.RPN - a.RPN);
const totalRPN = sorted.reduce((sum, m) => sum + m.RPN, 0);
let cumulative = 0;
return sorted.map(m => {
cumulative += m.RPN;
return {
name: m.name,
RPN: m.RPN,
cumulativeRatio: (cumulative / totalRPN) * 100 // 累積割合(%)
};
});
}
/**
* リスクマトリックス用データ
* @returns {Array} {S, O, RPN, name} の配列
*/
getRiskMatrixData() {
return this.failureModes.map(m => ({
name: m.name,
S: m.S,
O: m.O,
RPN: m.RPN
}));
}
/**
* 対策前後比較
* @returns {Array} 対策前後のRPN比較データ
*/
getComparisonData() {
return this.failureModes
.filter(m => m.after !== null)
.map(m => ({
name: m.name,
beforeRPN: m.RPN,
afterRPN: m.after.RPN,
reduction: m.RPN - m.after.RPN,
reductionRate: ((m.RPN - m.after.RPN) / m.RPN * 100).toFixed(1)
}));
}
}
// ===== 使用例 =====
const fmea = new FMEACalculator();
// 自動車のブレーキシステム故障モードを想定
fmea.addFailureMode(
'制動力低下（パッド摩耗）',
8, // S: ブレーキ効かない → 重大
4, // O: 年間数件報告あり
3, // D: 定期点検で発見可能
{ O: 2, D: 1 } // 対策後：高性能パッド + 摩耗センサー
);
fmea.addFailureMode(
'ブレーキフルード漏れ',
9, // S: ほぼ事故に直結
2, // O: 稀（過去3年で1件）
6, // D: 漏れに気づきにくい
{ D: 3 } // 対策後：漏れ検知センサー追加
);
fmea.addFailureMode(
'ABSモジュール故障',
7, // S: 制動距離増加
3, // O: 過去1年で1件
5, // D: 警告灯で気づく
{ O: 1, D: 2 } // 対策後：信頼性向上 + 自己診断機能
);
// 結果の確認
console.log('=== 全故障モード ===');
fmea.failureModes.forEach(m => {
console.log(`${m.name}: RPN=${m.RPN} (S=${m.S}, O=${m.O}, D=${m.D})`);
});
console.log('\n=== RPN 100以上フィルタ ===');
fmea.filterByThreshold(100).forEach(m => {
console.log(`${m.name}: RPN=${m.RPN}`);
});
console.log('\n=== パレートデータ ===');
fmea.getParetoData().forEach(d => {
console.log(`${d.name}: RPN=${d.RPN}, 累積割合=${d.cumulativeRatio.toFixed(1)}%`);
});
console.log('\n=== 対策前後比較 ===');
fmea.getComparisonData().forEach(d => {
console.log(`${d.name}: ${d.beforeRPN} → ${d.afterRPN} (削減率${d.reductionRate}%)`);
});
このコードのポイント：
- バリデーション：S, O, Dが1〜10の整数であることを確認
- 対策後評価：対策によって変化したパラメータだけ上書き可能（Oだけ下げる、Dだけ下げるなど）
- パレートデータ：累積RPN割合を自動計算 → 「上位20%の故障モード」を特定可能
- リスクマトリックス：SとOの2軸でプロットするためのデータ生成
数値例で確かめる
実際に、ある電子機器の「電源ユニット過熱」という故障モードを評価してみましょう。
評価値：
- S（深刻度）：7（機器停止、データ損失の可能性）
- O（発生頻度）：4（年に数回の報告あり）
- D（検知性）：6（温度センサーはあるが、異常に気づくまで時間がかかる）
計算：
RPN = 7 \times 4 \times 6 = 168
このRPN=168、一見すると「まあまあ高い」ですが、ここで先ほどのコードを実行してみます。
const fmea2 = new FMEACalculator();
fmea2.addFailureMode('電源ユニット過熱', 7, 4, 6);
console.log(fmea2.failureModes[0].RPN); // 168
ここで重要なのは：S=7（深刻度が高い）にもかかわらず、D=6（検知が難しい）ためにRPNが高くなっています。つまり、「対策すべきは発生頻度Oを下げるか、検知性Dを上げる（Dの値を下げる）か」という判断が必要になります。
対策として、過熱防止回路を追加（Oを2に低減） かつ 温度監視をリアルタイム化（Dを2に改善） した場合：
fmea2.addFailureMode('電源ユニット過熱（対策後）', 7, 2, 2);
console.log(fmea2.failureModes[1].RPN); // 28
RPNが168 → 28に低減。削減率83.3% です。
シミュレーターで遊ぶ
実際のシミュレーターで、いくつか実験してみましょう。
実験1：「RPNが同じでも中身が違う」を体感
- ケースA：S=5, O=5, D=5 → RPN=125
- ケースB：S=9, O=3, D=5 → RPN=135
RPNはほぼ同じ（125 vs 135）ですが、リスクマトリックスで見ると、ケースBはS=9（「警告なしで危険」に近い）と高リスク領域にプロットされます。
何が起きるか：シミュレーターのリスクマトリックス上で、ケースBは右上（高S・高O）に表示され、視覚的に「優先度が高い」ことがわかります。RPNの数字だけ見ていると見落とすポイントです。
実験2：しきい値フィルタで「見るべきもの」を絞る
10個の故障モードを登録し、RPNしきい値を100に設定してみましょう。
何が起きるか：パレート図が自動更新され、RPN 100以上の故障モードだけが強調表示されます。累積RPN割合が80%に達するまでの主要モードが一目でわかります。
実験3：対策前後比較で「効果の可視化」
先ほどの「電源ユニット過熱」で、対策前後のRPNを比較してみます。
何が起きるか：対策前RPN=168、対策後RPN=28が横並びで表示され、差が「140」、削減率「83.3%」と数値化されます。これで「対策の効果」を客観的に示せます。
現場でハマるポイント
1. 「検知性D」の解釈を間違える
最も多いミスです。Dは**「検知の難しさ」**。つまり：
- D=1：「確実に検知できる」← 良い状態
- D=10：「まったく検知できない」← 悪い状態
「検査がしっかりしてるからD=10」と入力すると、RPNが跳ね上がります。逆です。検査がしっかりしているならD=1です。
2. 「主観評価のバラつき」を放置する
あるエンジニアは「年に1回くらい」をO=4と評価し、別のエンジニアはO=3と評価する。これではチーム内で一貫性が保てません。
対策：社内で評価基準を具体化する。例えば：
- O=3：「過去3年間で1件の報告あり」
- O=4：「過去1年間で1件の報告あり」
のように、客観的なデータ（故障報告書、CAE解析結果の確率など）に基づいて評価しましょう。
3. 「RPNが下がったからOK」と早合点する
対策後にRPNが下がったからといって、それで終わりではありません。
確認すべきこと：
- 対策によって新たな故障モードが生まれていないか（トレードオフの確認）
- S（深刻度）が変わっていないか（対策によってSが上がるケースもある）
- 対策の実効性は担保されているか（机上の空論になっていないか）
まとめ
- RPNは「絶対的なしきい値」ではなく「相対的な優先順位付けの道具」 ── 数字の大小より、S（深刻度）が高いものを最優先に
- 3つの視点（パレート図・リスクマトリックス・対策前後比較）を組み合わせて判断 ── 一つの指標に頼らない
- 評価基準はチームで統一し、客観データに基づく ── 主観のバラつきが最大のリスク
今回紹介したコードは、実際のシミュレーターのコアロジックを再現しています。ぜひブラウザ上で動かしながら、S, O, Dの値を変えて「数字のマジック」を体感してみてください。
▶ FMEA RPN リスク優先度 シミュレーター — ブラウザで即動作、登録不要
NovaSolverでは700以上の工学シミュレーターを無料公開中 👉 一覧はこちら