Home / 根本原因分析（RCA）― 問題が発生する仕組みを解明し、再発を防ぐ

根本原因分析（RCA）― 問題が発生する仕組みを解明し、再発を防ぐ

根本原因分析（Root Cause Analysis：RCA）は、不良、故障、事故、業務上のトラブルなどについて、表面的な現象や直接的な原因だけでなく、その問題が発生する背景にある要因や仕組みを調べ、再発防止につなげるための方法です。

例えば、製造工程で不良品が発生したとします。不良品を取り除き、正常な製品に交換すれば、当面の問題は解消できます。しかし、不良が発生した原因を取り除かなければ、同じ問題が再び起きる可能性があります。

作業者の操作ミスが原因と判断された場合も同様です。なぜ誤操作が起きたのか、装置や作業手順に問題はなかったのか、誤操作を防止する仕組みはなかったのか、といった点を調べる必要があります。

RCAは、こうした問題を体系的に調査するために、5 Whys、特性要因図、故障の論理的な分析、業務プロセスの調査、統計解析など、複数の方法を組み合わせて利用します。

ただし、「根本原因」という言葉から、すべての問題には一つの究極的な原因があると考えるのは適切ではありません。実際の問題には、複数の要因が関係し、それらが特定の条件で重なったときに発生するものもあります。

RCAの目的は、何が悪かったかを説明することだけではありません。問題が再発する可能性を減らすために、どの条件や仕組みを変更すべきかを明らかにすることです。

根本原因とは何か

根本原因（Root Cause）という言葉は、一般に、問題の発生につながった原因のうち、対処することで同じ問題の再発を防止できる可能性がある、基礎的な要因を意味します。

例えば、製造装置が過熱して停止したとします。

装置が停止した直接の理由は、温度が安全限界を超え、保護機構が作動したことかもしれません。

しかし、温度が上昇した理由を調べると、冷却水の流量が不足していたことが判明したとします。

さらに調べると、冷却配管のフィルターが詰まっていたことがわかりました。

ここまでの調査によって、フィルターを清掃すれば装置を復旧できるかもしれません。

しかし、フィルターの目詰まりが適切な時期に発見されなかった理由は、まだ明らかになっていません。

例えば、保全計画にフィルターの点検項目が含まれていなかったのかもしれません。流量低下を検出するセンサーが設置されていなかった可能性もあります。

これらの要因まで検討すれば、フィルターの清掃だけでなく、点検方法や監視機構を改善する必要性が見えてきます。

このように、問題には異なる水準の原因があります。

原因の水準例主な対応
発生した現象装置が過熱して停止した安全確保、運転停止、復旧
直接的な原因冷却水の流量不足流量の回復
背景にある原因フィルターの目詰まり清掃、交換、目詰まり対策
管理・設計上の要因点検対象からの漏れ、監視機構の不足保全計画や設備設計の改善

ただし、原因の水準をどこまで遡れば根本原因と呼べるのかについて、すべての分野に共通する一意の基準が存在するわけではありません。

さらに原因を辿れば、保全予算、設備導入時の設計判断、組織体制などへ分析を広げることもできます。

現実には、無制限に原因を追究するのではなく、問題の重要性、利用できる証拠、対策の実行可能性などを考慮しながら、再発防止に有効な要因を特定する必要があります。

根本原因は必ず一つなのか

「根本原因」という言葉は、問題を引き起こした唯一の原因が存在するという印象を与えます。

しかし、複雑な事故や不良は、複数の要因が組み合わされて発生する場合があります。

例えば、製造ラインで異なる部品を組み付けてしまう問題について、次のような条件が重なったとします。

  • 部品Aと部品Bの外観が似ている。
  • 部品を保管する容器の表示がわかりにくい。
  • 部品を識別するスキャナーが停止していた。
  • スキャナー停止中でも作業を継続できる仕組みになっていた。
  • 最終検査では部品番号を確認していなかった。

この場合、作業者が部品を間違えたことは直接的な出来事ですが、それだけで問題全体を説明することはできません。

部品の識別が難しい環境、識別装置の停止、確認工程の不足などが組み合わされて、不良品が出荷される条件が成立しています。

また、部品の誤組付けが発生した理由と、不良が出荷まで発見されなかった理由は区別できます。

前者は不良の発生に関係する要因であり、後者は不良を検出・阻止する仕組みが十分に機能しなかった問題です。

このような場合、特定の一人や一つの工程だけに原因を帰着させるよりも、問題を発生させた条件と、問題の拡大を防げなかった条件の両方を調べる必要があります。

安全工学では、複数の防護層に弱点が存在し、それらが重なることで事故につながるという考え方があります。いわゆるスイスチーズモデルも、こうした複数の防護層の関係を説明するために使われます。

RCAでは、直線的な原因の連鎖だけでなく、複数の要因の組み合わせや相互作用を考慮することが重要です。

RCAは5 Whysや特性要因図とどう違うのか

RCAは、個別の図式化技法ではなく、原因の調査から対策の立案・評価までを含む広い活動です。

5 Whysや特性要因図は、その中で利用できる方法です。

方法主な目的RCAでの役割
5 Whys「なぜ」を繰り返して背景要因を考える原因の連鎖を掘り下げる
特性要因図考えられる原因をカテゴリーごとに整理する原因候補を幅広く列挙する
パレート図問題の件数や影響を項目別に比較する調査する対象の優先順位を考える
変化点分析（Change Analysis）正常時と異常時の違いを調べる問題発生に関係する変化を探す
バリア分析（Barrier Analysis）防止・検出の仕組みが機能したか調べる問題を防げなかった理由を調べる
故障の木解析（FTA）故障に至る事象の論理的な組み合わせを調べる複数の原因条件の関係を分析する
統計解析・実験計画法要因と結果の関係を数値的に評価する原因仮説を検討・検証する

それぞれ得意とする役割が異なるため、問題の性質に応じて使い分けます。

例えば、比較的単純な問題では、5 Whysと実際の記録の確認だけで十分かもしれません。

一方、安全性に重大な影響を与える事故や、複数の設備・組織が関係する問題では、時系列の再構成、複数要因の分析、専門的な技術調査などが必要になる場合があります。

すべてのRCAで、すべての手法を利用する必要はありません。

RCAの進め方

RCAの進め方にはさまざまな形式がありますが、一般的には、問題の定義、事実の収集、原因仮説の形成、原因の検討、対策の実施、効果確認という活動が含まれます。

1. 問題を明確に定義する

最初に、実際に何が起きたのかを明らかにします。

例えば、「製造品質が悪い」という表現では、具体的に何を調べるべきかがわかりません。

「特定の製品について、直近1か月の組立工程で部品の誤組付けが12件発生した」というように、対象、場所、期間、発生した事象を具体的に記述します。

この段階では、原因についての推測を問題の定義に含めないことが重要です。

例えば、「作業者の不注意によって誤組付けが発生した」と最初から定義すると、原因を十分に調べる前に結論を決めてしまうことになります。

問題の記述では、観察された事実と、その事実に対する解釈を区別します。

2. 発生状況と証拠を収集する

次に、問題が発生した状況を詳しく調べます。

製造工程であれば、作業記録、設備ログ、測定値、製造条件、保全履歴、製品の現物、作業者への聞き取りなどが考えられます。

事故の場合には、発生前後の状況、作業手順、安全装置の状態、関係者の行動などを調べる必要があります。

この段階で重要なのは、原因を決めつけずに、利用できる証拠を収集することです。

関係者の説明が一致しない場合にも、一方を直ちに誤りと判断するのではなく、記録や観察結果などと照合して検討します。

また、問題発生後に現場の状態が変化する可能性があるため、安全を確保したうえで、必要な記録や証拠を適切に保全することも重要です。

3. 問題が発生した経過を再構成する

問題がいつ、どのような順番で発生したかを整理します。

例えば、設備の故障について、次のような時系列が確認されたとします。

正常運転 → 流量の低下 → 温度の上昇 → 警報の発生 → 装置停止

この時系列は、問題がどのように進行したかを理解するために役立ちます。

ただし、出来事が時間的に連続していることだけで、因果関係が成立するわけではありません。

流量が低下した原因は何か、警報が出た時点で運転を停止できなかった理由は何か、といった点について、別途検討する必要があります。

4. 原因候補を幅広く考える

観察された事実をもとに、考えられる原因を列挙します。

5 Whysによって原因の連鎖を掘り下げることもできますし、特性要因図によって設備、材料、作業方法、環境などの観点から候補を整理することもできます。

この段階では、最初に思いついた説明に固執しないことが重要です。

例えば、装置が停止した原因として、冷却装置の不具合だけでなく、異常な負荷、温度センサーの故障、制御プログラムの問題なども考えられます。

原因候補を列挙することと、それが実際の原因であると確認することは異なります。

5. 原因仮説を検証する

考えられた原因候補について、証拠との対応を確認します。

例えば、冷却水の流量不足が原因であるという仮説であれば、問題発生時に流量が低下していたかを調べます。

また、同じ運転負荷で正常に動作している装置と比較することも考えられます。

必要に応じて、追加測定、部品の調査、シミュレーション、実験などを行います。

ただし、安全上の問題がある場合には、故障や事故を実際に再発させて確認するべきではありません。代替的な試験や設計上の検証を利用する必要があります。

また、原因仮説を検討する際には、その仮説を支持する証拠だけでなく、反対の証拠や競合する説明についても検討します。

6. 再発防止策を設計・実施する

原因が特定された後には、再発防止策を検討します。

例えば、フィルターの目詰まりが問題であれば、定期交換、差圧や流量の監視、装置の設計変更などが考えられます。

重要なのは、問題が発生したときの対処方法だけでなく、同じ条件が再び生じても重大な問題につながらない仕組みを作ることです。

対策には、実施担当者、期限、実施条件、評価する指標などを設定する必要があります。

7. 対策の効果を確認する

対策を実施した後には、実際に問題の発生頻度や影響が減少したかを調べます。

例えば、不良率が低下した場合でも、生産量や製造条件が大きく変化していれば、改善策の効果と断定できないかもしれません。

また、問題が一度も再発していないことだけで、対策が十分に機能しているとは限りません。まれにしか発生しない事故や故障では、短期間に再発が見られないことは十分な効果の証拠にならない場合があります。

そのため、最終的な不良率や事故件数だけでなく、監視装置の稼働率、点検の実施状況、安全機構の作動確認など、対策が機能していることを示す指標も利用できます。

RCAは、原因を記載した報告書を作成した時点で完了するのではなく、対策が実施され、その有効性が確認されるところまでを含めて考えるべきです。

実践例 ― 誤った部品を組み付けた製品が出荷された

次の例は、RCAの進め方を理解するための仮想事例です。

ある製造工場で、製品に誤った部品が組み付けられ、そのまま出荷されるという問題が発生しました。

調査の結果、次の事実が確認されたとします。

確認された事実内容
発生した問題部品Aを使用すべき製品に部品Bが組み付けられた
部品の特徴AとBは形状・寸法が非常によく似ている
通常の識別方法組付け前にバーコードを読み取る
発生時の設備状態バーコードスキャナーが故障していた
発生時の作業方法スキャナー停止中は目視確認によって作業を継続していた
最終検査部品番号の照合は行われていなかった

原因の整理

この問題について、「作業者が部品を取り違えた」という説明は、直接的な出来事を示しています。

しかし、再発防止を考えるためには、さらに詳しい分析が必要です。

まず、部品AとBを間違えやすい状態にあったことが重要です。

次に、通常は誤組付けを防止するためのバーコード確認が、故障によって利用できなくなっていました。

さらに、バーコード確認が行われなくても製造工程を継続できたことが、誤組付けの発生につながった可能性があります。

そして、最終検査で部品番号を確認しなかったため、不良品が出荷されました。

この問題では、誤組付けが発生した原因と、それを検出できなかった原因を区別できます。

原因仮説と検証方法

原因仮説検討する証拠
部品の外観が似ていたため取り違えやすかった容器や部品の識別表示、過去の取り違え記録
スキャナー停止が誤組付けの可能性を高めた設備ログ、停止時刻と不良発生時刻の対応
故障時の代替作業手順が不十分だった作業標準書、故障時の対応記録、作業者への聞き取り
最終検査で誤組付けを検出できなかった検査項目、検査記録、検査工程の実態

こうして整理した段階では、まだ仮説にすぎないものも含まれています。実際の記録や追加調査によって確認する必要があります。

再発防止策

例えば、次のような対策が考えられます。

対策期待される効果
スキャナー故障時には組付け工程を開始できない仕組みにするバーコード確認なしでの組付けを防ぐ
部品容器の形状や識別方法を変更する部品の取り違えを起こりにくくする
最終検査で部品番号を確認する誤組付け品の流出を防ぐ
故障時の対応手順と復旧条件を見直す例外運用によるリスクを低減する

これらの対策についても、実際の効果や副作用を検討する必要があります。

例えば、スキャナーが故障すると生産ラインが停止する設計は、誤組付け防止には有効かもしれませんが、生産効率との調整が必要です。

また、最終検査を追加する場合には、検査の信頼性や処理時間への影響も考慮します。

問題の重要性や安全性を踏まえて、複数の対策を組み合わせることが考えられます。

「作業者のミス」で分析を終わらせない

RCAでは、個人の操作ミスや判断ミスを原因として特定する場合があります。

しかし、「作業者が注意しなかった」という説明だけで調査を終えると、再発防止につながらないことがあります。

例えば、作業者が手順を守らなかった場合、次のような問いを考えられます。

作業手順は明確だったのでしょうか。必要な情報が作業時点で確認できる状態だったのでしょうか。手順に従うことが現実的に可能だったのでしょうか。作業量や時間的な制約によって、例外的な対応が常態化していなかったでしょうか。

また、作業者が間違えても、不良品や事故につながらない仕組みを設計できなかったかという観点も重要です。

これは、人間が誤りを犯す可能性を前提として、システム側に防止・検出機能を設けるという考え方です。

ただし、すべての個人的な行動を組織や設備の問題だけに帰着させるべきだという意味ではありません。意図的な違反行為など、個人の責任を検討する必要がある場合もあります。

重要なのは、責任の判断と、再発防止のための原因調査を混同しないことです。

作業者を処分したとしても、同じ条件が残っていれば、別の作業者が同じ誤りを犯す可能性があります。

有効な再発防止策とは何か

原因を特定した後に重要になるのが、対策の実効性です。

例えば、事故や不良が発生した後に、「作業者へ注意を徹底する」「教育を実施する」「マニュアルを改訂する」という対策が採用されることがあります。

これらの対策が不要というわけではありません。しかし、同じ作業を続ける中で、作業者の注意力や記憶に依存する状態が残れば、再び問題が発生する可能性があります。

安全分野では、対策の強さを階層的に整理する考え方があります。

対策の例特徴
危険な作業や故障要因そのものを取り除く問題を生み出す条件をなくす
インターロックや誤操作防止機構を設ける人間の判断だけに依存せず問題を防ぐ
作業工程や設備の設計を変更する問題が起きにくい仕組みにする
自動検査や警報を設ける問題を検出し、影響を抑える
チェックリストや確認手順を追加する人間の確認作業によってリスクを下げる
注意喚起や教育を行う作業者の理解や行動の改善を図る

一般に、危険や誤操作の可能性を構造的に減らす対策は、注意喚起だけに依存する対策よりも持続的な効果を期待しやすい場合があります。

ただし、どの対策が適切かは、問題の性質、技術的な制約、費用、導入による副作用などによって異なります。

RCA² ― 原因分析だけでなく行動を重視する

医療安全の分野では、従来のRCAが原因の報告で終わり、十分な改善につながらないという問題が指摘されてきました。

そこで米国のNational Patient Safety Foundationは、2015年にRCA²（Root Cause Analyses and Actions）という考え方を提唱しました。

RCA²では、原因の特定だけでなく、実効性のある改善策の実施や、その効果の評価までを重視します。

この考え方は医療安全だけに限定されるものではなく、製造、品質管理、業務改善などでも参考になります。

重要なのは、原因を詳しく説明すること自体ではなく、同じ種類の問題が再び発生する可能性を実際に減らすことです。

RCAとFMEA・FTA・CAPAの関係

品質管理や信頼性工学には、RCAと関連する複数の方法があります。

特にFMEA、FTA、CAPAは、それぞれの役割を区別すると理解しやすくなります。

FMEA ― 起きる前に故障や不良の可能性を調べる

FMEA（Failure Mode and Effects Analysis：故障モード影響解析）は、製品や工程について、どのような故障や不良が発生しうるかを事前に検討する方法です。

RCAは、一般に、すでに発生した問題について原因を調べるために利用されます。

一方、FMEAは、まだ発生していない問題も含めて、潜在的な故障モードとその影響を検討します。

ただし、両者は独立した活動ではありません。

実際にRCAによって新しい故障原因が確認された場合、その知識をFMEAへ反映し、類似の製品や工程についてもリスクを再検討できます。

FTA ― 故障に至る論理的な条件を分析する

FTA（Fault Tree Analysis：故障の木解析）は、特定の望ましくない事象について、それが発生するために必要な条件や要因の組み合わせを、論理的な木構造で分析する方法です。

例えば、装置が停止する条件として、冷却系の故障、電源の異常、制御装置の故障などを考えます。

さらに、「AまたはBが起きれば停止する」というOR条件や、「AとBが同時に起きた場合に停止する」というAND条件を用いて、故障の構造を表現できます。

このような論理的な関係は、単純な5 Whysだけでは表現しにくい場合があります。

FTAは、すでに発生した事故や故障の解析に加えて、設計段階のリスク分析にも利用できます。

CAPA ― 是正処置と予防処置を管理する

CAPA（Corrective and Preventive Action：是正処置・予防処置）は、発生した不適合への対応と、問題の再発や潜在的な問題の発生を防ぐための処置を管理する仕組みです。

RCAによって原因を調べ、その結果に基づいて是正処置を立案し、実施と効果確認を行うという関係になります。

RCAが原因の解明に重点を置くのに対し、CAPAは対策の計画、実施、記録、効果確認などを含む管理活動です。

定性分析と定量分析の統合

RCAでは、定性的な観察と定量的な分析を組み合わせることが重要です。

例えば、故障の原因を調べる際に、作業者へのインタビューや現場観察によって、設備の使われ方や例外的な運用を把握できます。

一方、装置の温度、圧力、流量、稼働時間などのデータを分析することで、問題が発生したときの条件を数量的に比較できます。

統計的な相関が見つかった場合にも、因果関係を確認するには追加調査が必要になることがあります。

例えば、温度上昇と装置故障に相関が見られたとしても、温度上昇が故障の原因なのか、故障によって温度が上昇したのか、別の条件が両方に影響しているのかは、相関だけでは判断できません。

このような場合には、装置の動作原理や故障の発生順序を調べ、必要に応じて実験やシミュレーションを行うことになります。

RCAは、定性的な原因仮説を数量的な証拠によって検討するための活動でもあります。

また、定量的な分析から予想外の関係が見つかった場合には、それを説明するために新しい仮説を考えることもできます。

定性的な原因探索から定量的な検証へ進むだけでなく、定量的な結果によって原因の捉え方を修正するという往復が重要です。

根本原因分析はどのような問題に適しているか

RCAは、特定の問題が発生した理由を調べ、再発防止を図る場合に適しています。

例えば、製造不良、設備故障、労働災害、医療事故、情報システムの障害、業務上の重大なミスなどが代表的な対象です。

一方、まだ発生していない問題について将来のリスクを検討する場合には、FMEAなどの予防的な手法が適していることがあります。

また、「新しい事業を作りたい」「新しい研究テーマを発見したい」といった課題では、そもそも何を実現するべきかが決まっていない場合があります。

こうした課題をすべて「現在の成果が不足している根本原因を探す問題」として扱うと、既存の組織や技術の範囲に分析が限定される可能性があります。

新しい方向性を探索するには、原因分析だけでなく、問題構造化、概念探索、類推、アイデア生成などが必要になる場合があります。

RCAは、すべての問題解決に適用するべき万能の手法ではありません。

根本原因分析の限界

RCAには多くの利点がありますが、注意すべき限界もあります。

第一に、原因を過去へ遡るほど、因果関係の検証が難しくなる場合があります。

例えば、設備の故障を保全計画の不足によって説明できたとしても、なぜ保全計画が不十分だったのかをさらに遡ると、予算、組織体制、経営方針など、多くの要因が関係している可能性があります。

第二に、問題は一つの原因から直線的に発生するとは限りません。複数の要因の相互作用や、時間とともに変化する条件が重要な場合があります。

第三に、事故や故障が発生した後には、結果を知っているために、その結果につながった経緯を必要以上に予測可能だったと考えてしまう傾向があります。これは後知恵バイアス（Hindsight Bias）に関係します。

第四に、原因候補を列挙しただけで、それらが実際に原因だったことを確認したつもりになる危険があります。

第五に、分析によって適切な原因が発見されたとしても、対策が実施されなかったり、十分な効果を持たなかったりすれば、問題は再発する可能性があります。

このため、RCAの品質を、原因分析報告書の詳しさや図の完成度だけで評価することは適切ではありません。

AIによる根本原因分析の支援

LLMや機械学習は、RCAに関係する複数の作業を支援できます。

例えば、故障報告書、品質記録、保全履歴、作業日報などを収集し、発生した事象や条件を整理できます。

また、5 Whysや特性要因図の作成を支援し、複数の原因候補を考えることもできます。

異なる事故や故障の記録から類似する状況を探し、過去に採用された対策を参照することも考えられます。

さらに、時系列データやセンサーデータについて統計的な分析や異常検知を行い、発生条件を詳しく調べることもできます。

ただし、LLMが提示した原因の説明は、必ずしも実際の原因を表しているわけではありません。

例えば、装置の故障報告に「温度上昇」と記載されている場合、AIは一般的な知識から「冷却装置の不具合」という説明を生成するかもしれません。

しかし、実際には温度センサーの誤作動や、別の機械的な問題が関係している可能性もあります。

そのため、AIを利用する場合には、次の情報を区別することが重要です。

  • 実際に観察・測定された事実
  • 人間が報告した状況や認識
  • AIが提案した原因候補
  • 原因仮説を支持・否定する証拠
  • 検証された原因と未検証の仮説
  • 対策の内容と、実施後に確認された効果

これらを対応づけて記録できれば、単にもっともらしい原因を説明するだけでなく、証拠に基づいて調査を進めるための支援が可能になります。

また、AIによる分析では、最初の説明に固執せず、別の仮説や検討されていない条件を探索できることが重要です。

ThinkNaviでの位置づけ

ThinkNaviでは、根本原因分析を、5 Whysや特性要因図などの個別手法を組み合わせる総合的な問題解決方法として位置づけます。

問題の状況が明確でない場合には、問題構造化によって調査対象や問題の定義を整理できます。

原因候補を幅広く考える場合には特性要因図、原因の連鎖を掘り下げる場合には5 Whys、複数の条件の論理的な組み合わせを調べる場合にはFTAなどを利用できます。

また、原因仮説を数量的に検討する場合には、統計解析や実験計画法を利用できます。

ThinkNavi Freeでは、発生した問題、観察された事実、原因候補、検証結果、対策などを手入力で記録し、関連する手法を組み合わせて分析できるワークフローが考えられます。

LLMを利用する場合には、原因候補の提案、競合仮説の比較、証拠の整理、検証方法の提案、対策案の検討などを支援する方向が考えられます。これらは今後の機能開発の候補であり、現在提供されているすべての機能を示すものではありません。

根本原因分析では、問題が発生した理由を一つのわかりやすい説明にまとめることが、必ずしも最良の結果ではありません。

問題の発生には、複数の要因や条件が関係している場合があります。また、すべての原因を取り除くことができなくても、防止・検出・影響軽減の仕組みを改善することで、再発リスクを下げられる場合があります。

RCAで重要なのは、唯一の「真の原因」を発見したと主張することではありません。問題が発生した仕組みを証拠によって理解し、どこを変えれば同じ問題が起こりにくくなるのかを明らかにすることです。

関連ページ

参考文献・関連資料