MENU
coevo

coevoは「ものづくり」「テクノロジー」を中心とした技術や産業のトピックスをわかりやすくお伝えするメディアです。

FTA(故障の木解析)とは?FMEAとの違いやツリー図の作成方法、進め方

  • シェア

製造業や研究開発の現場では、製品やシステムの高度化に伴い、不具合や事故の原因が複雑化している。単一のミスではなく、複数の条件や要因が重なって重大なトラブルへ発展するケースも多く、原因を体系的に分析する手法が重要となっている。

そこで活用されているのがFTA(故障の木解析)である。FTA(故障の木解析)とは、トップ事象から原因を論理的に分解し、潜在的なリスクや因果関係を構造的に整理できる分析手法であり、高い信頼性が求められる分野で発展してきたフレームワークだ。

近年は品質向上や設計段階でのリスク管理を目的に、製造業や研究開発の現場でもFTAの活用が広がっている。本記事では、このFTAの基本的な考え方から、FMEAとの違い、ツリー図の構成要素、実践的な進め方までを体系的に解説する。

FTA(故障の木解析)とは?

FTAとはFault Tree Analysisの略称であり、複雑なシステムにおいて発生してはならない重大な失敗や望ましくない事象の原因を体系的に分析する手法である。日本語では「故障の木解析」と呼ばれる。

まず分析の出発点として、事故やシステム停止などの望ましくない事象をトップ事象として定義し、その事象に至る原因を段階的に分解しながらツリー状に整理していく点が特徴である。解析ではツリー図を用い、各要因の関係性をANDやORなどの論理記号で表現することで、複数の要因がどのように組み合わさって問題を引き起こすのかを構造的に理解できる。

この手法の起源は1960年代にベル研究所のH.A.ワトソンによって提案されたものであり、1965年にはボーイング社がミサイル制御システムの安全性評価に応用したことで実用的な解析手法として確立された。

その後、航空宇宙や原子力といった高い安全性が求められる分野で広く採用され、現在では製造業やシステム開発など多様な領域でリスク分析の手法として活用されている。

FTA(故障の木解析)とFMEA(故障モード影響解析)の違い

FTAとFMEAはいずれも製品やシステムの信頼性や安全性を高めるためのリスク分析手法であるが、分析の出発点とアプローチが大きく異なる。

項目FTA
(故障の木解析)
FMEA
(故障モード影響解析)
考え方起きてほしくない事象から原因をさかのぼって分析する起こりうる故障モードを洗い出して影響を評価する
分析の向きトップダウン(結果 → 原因)ボトムアップ(原因 → 影響)
主な目的重大事故や不具合の原因特定不具合の未然防止
向いている場面特定の重大トラブルや事故の要因分析設計段階・工程設計段階でのリスク洗い出し
特徴因果関係を論理的に深掘りしやすい網羅的にリスクを確認しやすい

FTAはトップダウン型の分析手法であり、まず重大な事故やシステム停止など望ましくない事象をトップ事象として設定し、その事象が発生する原因を段階的にさかのぼりながら分解していく。ツリー図で因果関係を整理することで、複数の要因がどのように組み合わさって問題を引き起こすのかを明確にできる。

一方、FMEAはボトムアップ型の分析手法であり、製品やシステムを構成する部品や機能ごとに発生し得る故障モードを洗い出し、それがシステム全体に与える影響を評価していく。つまりFTAは特定の重大事象の原因構造を深く分析するのに適しており、FMEAは潜在的な故障を網羅的に抽出してリスクを管理する目的で活用される。

FTAと特性要因図(フィッシュボーン図)の違い

FTAと特性要因図(フィッシュボーン図)はいずれも問題の原因を分析するための手法であるが、目的と分析の進め方に明確な違いがある。

FTAは重大な事故やシステム停止などの望ましくない結果を起点とし、その事象に至る原因を論理的に分解していく分析手法だが、特性要因図は、特定の結果に対して考えられる原因を網羅的に洗い出すことを目的とした整理手法である。

図の形状が魚の骨に似ていることからフィッシュボーン図とも呼ばれ、人、機械、方法、材料などのカテゴリーごとに原因候補を書き出して整理していく。この手法は厳密な論理構造を表現するものではなく、問題構造がまだ明確でない段階や、ブレインストーミングによって原因の可能性を幅広く探りたい場面に適している。

FTAの構成要素とツリー図で用いられる記号

FTAのツリー図は、大きく「事象」と「ゲート」の組み合わせで構成される。ここでは、FTAで用いられる代表的な記号をいくつか紹介したい。

事象の記号

事象の記号は、トップ事象から原因となる基本事象へと論理的に分解・展開するための視覚的ブロックのことを指す。

記号名称概要
トップ事象分析の基点となる問題および事象
中間事象トップ事象から派生する事象および原因
基本事象これ以上展開・分解する必要のない最も基礎的な事象
外部事象外部環境や特定の条件下で発生する事象
否展開事象分析の範囲外である場合や、詳細な情報が不足している事象
条件付き事象特定の論理ゲートが成立するための条件を示す補助的な事象

ゲートの記号

ゲート記号とは、構成要素の因果関係を表現する記号をいう。基本事象や中間事象がどのように組み合わさって上位の事象を発生させるかを記述する役割を担う。

記号名称概要
ANDゲート複数の入力事象がすべて発生した場合にのみ上位事象が発生することを示す記号
ORゲート入力事象のいずれか一つが発生すれば上位事象が成立することを示す記号
XOR(排他的OR)ゲート複数の入力事象のうち「いずれか一つだけ」が発生した場合に上位事象が成立することを示す記号
※FTAの実務ではあまり使用されない
優先ゲート入力事象が特定の順序で発生した場合にのみ上位事象が成立することを示す記号
制約ANDゲート特定の条件が満たされた場合にのみ上位事象が発生することを表す記号

FTAを行う目的・メリット

FTAを行う目的やメリットは、主に以下の4点が挙げられる。

因果関係を体系化できる

FTAを活用する1つ目のメリットは、複雑な問題の因果関係を体系的に整理できる点にある。

現代の製品開発や事業運営では、技術的要因、運用条件、外部環境など複数の要素が相互に影響し合いながら問題が発生することが多い。そのため、単にリスクを列挙するだけでは、どの要因がどのような条件で重大な事象につながるのかを正確に把握することは難しい。

FTAでは、望ましくない事象を起点として原因を段階的に分解し、各要因の関係性を論理的に整理することで、問題の構造を明確にすることができる。加えて、ツリー図によって因果関係を可視化することで、複数の条件がどのように組み合わさると問題が発生するのかを直感的に理解できるようになる。

また、構造化された分析結果は、関係者の間で共通の理解を形成するうえでも有効であり、複雑な課題に対して組織全体で同じ視点を持って議論できる基盤となる。

ボトルネックとなる要因を特定できる

FTAを活用する2つ目のメリットは、重大な問題を引き起こすボトルネックとなる要因を明確に特定できる点にある。

FTAではツリー図の中でANDゲートやORゲートといった論理ゲートを用いて原因同士の関係を表現するため、単独の要因で重大事象につながるのか、それとも複数の条件が同時に成立したときに初めて発生するのかを区別できる。この分析によって、問題発生に大きく影響する要因や弱点となる部分を見つけ出すことが可能となる。

例えば研究開発の段階では、設計構造やシステム構成の中に潜む弱点を早期に発見できるため、開発の後工程で問題が顕在化するリスクを低減できる。また新規事業の領域でも、運用体制や外部環境など複数の条件が関係するリスクの中から、事業継続に大きく影響する要因を把握できる。

いずれも段階でも、重要度の高い要因を特定できることで、限られた資源を効果的に集中させる判断が可能だ。

定量的にリスクを評価できる

FTAを活用する3つ目のメリットは、リスクを定量的に評価できる点にある。研究開発や新規事業の分野では、未知の要因や潜在的な故障原因が多く存在するため、経験や勘だけに依存した判断ではリスクを正確に把握することが難しい場合がある。

それに対し、FTAでは重大事象に至る原因を基本事象と呼ばれる最小単位まで分解し、それぞれの発生確率を設定することで、システム全体としてのリスクを数値として評価することが可能だ。

また、論理ゲートによって要因同士の関係を表現し、その構造に基づいて確率計算を行うことで、どの程度の確率で重大事象が発生する可能性があるのかを分析できる。これにより、感覚的な判断ではなく、データや数値に基づいた客観的な安全評価を行うことができるようになる。

数値化された結果は意思決定の根拠としても活用しやすく、リスク管理の精度を高めることにもつながる。

未然に不具合を防ぐことができる

FTAを活用する最後のメリットは、重大な不具合や事故を事前に予測し、未然に防止できる点にある。

製品開発や新規事業の分野では、過去の実績やトラブル事例が十分に存在しない場合も多く、経験だけに依存した判断では潜在的なリスクを見落としてしまう可能性があり、結果、設計や運用の段階で問題が潜んだまま進行し、後工程や市場投入後に重大なトラブルとして表面化することも少なくない。

その点、FTAではシステム構造や設計思想を出発点として、望ましくない事象につながる原因を論理的に分解しながら検討していくため、過去のデータが少ない状況であっても、構造的な視点から潜在的なリスクを洗い出すことができる。

開発や設計の初期段階で問題の芽を早期に把握し、対策を講じることが可能となり、結果として重大な不具合や事故の発生を未然に防ぐ体制を構築できる。

FTAの実践的なやり方・手順について

続いて、FTAの実践的なやり方や手順について解説したい。

トップ事象の定義

FTAにおける最初のステップは、分析の起点となるトップ事象を明確に定義することである。

トップ事象は、発生してはならない重大な結果や望ましくない状態を指し、生産停止、重大事故、品質不良によるサービス停止などが典型的な例である。なお、曖昧な定義では分析範囲が不明確になり、原因の検討が的外れになる可能性があるため、この段階では、事象の内容をできるだけ具体的に定義することが重要だ。

また、現実のトラブルは人、設備、運用など複数の要因が重なって発生することが多いため、分析対象には機器の故障やシステム不具合といった技術的要因だけでなく、操作ミスや手順の誤り、確認不足などのヒューマンエラーも含めて考える必要がある。

要因(中間事象)の抽出と展開

次のステップは、トップ事象を引き起こす直接的な原因を洗い出し、それらをツリー状に整理していく要因の抽出と展開である。

まず、問題の発生につながる可能性のある要因をどのような条件や事象が重なることで重大な結果が生じるのかを複数の観点から考える。次に、それぞれの要因同士の関係性を論理ゲートによって接続し、因果関係を明確にしていく。

代表的な論理関係としては、複数の要因のうちいずれか一つが発生すれば問題につながる場合に用いるORゲートや、複数の条件が同時に成立した場合にのみ問題が発生する場合に用いるANDゲートがある。ここで論理関係を適切に用いることで、事象がどのような条件の組み合わせで発生するのかを整理できる。

ただし、ORゲートを過度に使用するとツリー構造が複雑化し、分析の焦点がぼやける可能性があるため、原因の関係性を十分に検討したうえで適切に配置することが重要だ。

基本事象(原因の末端)までの分解

そして、抽出した要因をさらに掘り下げ、問題の発生につながる原因を最小単位まで細分化していくステップにつながる。

FTAの分析では、これ以上分解できない段階、あるいは部品の故障や操作ミスなど実際に対策を講じることが可能なレベルに到達するまで継続することが重要だ。例えば、設備トラブルという要因をさらに分解し、特定の部品の破損やメンテナンス不足といった具体的な原因にまで整理することで、実務的な改善策を検討できるようになる。

この段階で重要なのは、原因を抽象的な概念で終わらせず、現場で確認可能な具体的事象まで掘り下げることである。原因が明確になり、対策を実施できるレベルに到達した時点でツリーの展開が終了となる。

発生確率の割り当て(定量評価)

続いて、ツリーの末端に位置する基本事象ごとに、どの程度の確率でその事象が発生するのかを数値として設定するプロセスに移る。

評価の際には、過去の故障データ、試験結果、信頼性試験の記録、部品メーカーのカタログ値など、客観的な情報をもとに確率を見積もることが重要だ。経験や感覚だけに頼るのではなく、実績データを活用することで、分析の精度を高めることができる。

そして、ツリー図で用いられている論理ゲートの関係に従い、それぞれの事象の発生確率を計算していく。例えば、複数の条件が同時に成立した場合に発生する関係と、いずれか一つの条件で発生する関係では計算方法が異なる。

ゲートの種類論理の考え方計算式(2事象の場合)計算例備考
ORゲートいずれか一方が起きれば発生P(A ∪ B) = P(A) + P(B) - P(A)P(B)0.1 + 0.2 - (0.1×0.2) = 0.28和集合
ANDゲート両方が同時に起きたら発生P(A ∩ B) = P(A)P(B)0.1 × 0.2 = 0.02積集合
排他的ORゲートどちらか「片方だけ」で発生P(A xor B) = P(A)(1-P(B)) + P(B)(1-P(A))0.1×0.8 + 0.2×0.9 = 0.26積集合を除いた和集合
優先AND両方起きる、かつ「順番」が一致P = P(A)P(B)×順序確率0.1 × 0.2 × 0.5 = 0.01特定の順序条件を満たした積集合
制約/条件付き事象が起き、かつ「条件」が成立P = P(A)×P(C)0.1 × 0.5 = 0.05事象と条件の積集合

(※1) 発生順番が「A→B」と「B→A」の2通りで、確率が等しい(0.5)と仮定した場合。

(※2) 条件(例:夜間である確率など)を 0.5 と仮定した場合。

このような論理関係に基づいて確率を積み上げることで、最終的に重大なトップ事象がどの程度の確率で発生する可能性があるのかを定量的に把握できるようになる。これにより、リスクの大きさを客観的に評価することが可能だ。

評価と対策の実行

最後に、作成したツリー全体を確認し、重大事象の発生につながるリスクを低減するための具体的な対策を検討・実施していくステップとなる。

ツリー図は作成して終わりではなく、その内容が実際のシステムや業務の状況と整合しているかを丁寧に検証することが重要だ。そのためには、現場の担当者や技術者、専門家など複数の視点からレビューを行い、論理構造に矛盾がないかを確認する必要がある。

また、検証の際には、設備や部品の故障といった物理的要因だけでなく、操作ミスなどのヒューマンエラーや外部環境の影響が適切に含まれているか、原因が具体的なレベルまで整理されているかなどを確認することも重要である。

対策は理想的にはすべて実施するのが望ましいが、限られたリソースを考慮し、影響度や重要度が高い項目から優先的に進めることが現実的だろう。

FTAを実施するうえで押さえておきたい注意点

FTAは万能なフレームワークではなく、適切に論理展開をしないと期待した効果は得られない。最後に、FTAの運用でよく陥りがちなポイントを紹介する。

トップ事象を具体的にかつ明確に定義する

FTA分析における1つ目に注意すべきことは、トップ事象を具体的かつ明確に定義することである。FTAはトップダウン型の分析手法であり、トップ事象を起点として原因を段階的に分解していくため、最初の定義が曖昧であったり抽象的すぎたりすると、分析の方向性が定まらず、ツリー図の枝が無秩序に広がってしまう。

例えば単にシステム障害と設定するのではなく、特定の設備が停止する、製品が安全基準を満たさないといったように、発生状況や影響範囲が明確になるレベルまで具体化することが望ましい。

解析範囲と目的を明確にする

FTA分析における2つ目に注意すべきことは、解析範囲と目的を事前に明確にしておくことだ。解析の対象範囲を限定せずに分析を進めてしまうと、ツリー図の分解が際限なく広がり、構造が過度に複雑になってしまう。

結果、原因の整理や優先順位付けが難しくなり、実務に活用できる結論を導き出せなくなる可能性がある。また、分析対象を広げすぎることで問題が過剰に存在するように見えてしまい、かえって意思決定を混乱させる恐れもある。

例えば、特定の設備や工程、特定の運用シナリオなど、どの範囲を対象として分析するのかをあらかじめ定めておくことで、ツリーの構造を適切な規模に保つことができる。なお、分析の目的を共有し、チーム内での認識のずれを防ぎ、必要な原因の洗い出しに集中することも効果的だ。

同階層の事象の粒度を揃える

FTA分析における3つ目に注意すべきことは、同じ階層に配置する事象の粒度を揃えることである。ツリー図の中で、ある事象の原因を分解する際に、抽象度の高い要因と具体的な要因が同じ階層に混在してしまうと、構造が不均衡になり分析の精度が低下する。

例えば、設備故障のような大きな概念と、特定部品の摩耗といった詳細な原因が同列に並ぶと、本来検討すべき重要な要因が見落とされたり、特定の領域だけ過度に細かく分析されたりする恐れがある。

このような状態では、ツリー全体の論理構造が不明確になり、後の確率計算やリスク評価にも影響を及ぼすため、結果として、実際よりもリスクが低く見積もられてしまう可能性もある。

論理関係の混同を避ける

FTA分析における4つ目に注意すべきこととして、ツリー図で用いる論理関係を正しく理解し、混同を避けることも重要だ。FTAでは、複数の要因がどのような条件で事象を引き起こすのかを表現するために、ANDゲートやORゲートといった論理記号を用いる。

これらの論理関係を誤って設定してしまうと、事故や故障の発生確率が実態と異なる形で算出され、分析結果の信頼性が大きく損なわれてしまう。また、原因同士の関係性を誤解したまま分析を進めると、本来注目すべき共通原因を見落とす可能性がある。

結果、問題の本質とは異なる表面的な対策にリソースが費やされてしまい、十分な安全対策やリスク低減につながらないリスクにもつながる。

定期的にアップデートする

最後に、作成したツリー図を定期的に見直し、最新の状況に合わせて更新することにも注意しなければならない。製品設計や製造プロセス、運用方法、外部環境などは時間の経過とともに変化するため、過去に作成した分析内容がそのまま現在のリスク構造を正確に反映しているとは限らない。

FTAは一度作成して終わりではなく、新たに判明した故障事例や運用データ、設備の変更、設計改良などの情報を反映しながら継続的に更新していく必要がある。もし古いツリー図のまま運用を続けてしまうと、新たに発生した原因を見落としたり、すでに対策済みで影響が低減されたリスクを過大に評価したりする可能性がある。

まとめ

新規事業や研究開発などの分野では、どの安全対策にリソースを投じるべきかを判断する指針として、FTAが果たす役割は極めて大きい。

一見すると緻密な作業と多大な労力を要する手法ではあるが、論理ゲートを積み上げ、事象間の因果関係を厳密に定義していくプロセスそのものが、チーム全体のシステム理解を深化させる。この過程で得られる知見は、個人の経験に依存しない「組織知」へと昇華され、結果として組織全体の設計・開発における信頼性向上に直結するのだ。

ただし、FTAはあくまで「思考の補助線」に過ぎない。その真価を発揮させるには、導入の目的と運用の質が問われる。解析の前提となる事象の抽出が不十分であったり、形式的な作業に終始したりすれば、真のリスクを見落とすばかりか表面的な事象の対処にリソースを浪費する結果を招きかねない。

FTAを単なるチェックリストとしてではなく、本質的なリスクを射抜く戦略的な検証プロセスとして位置づけることこそが、確かな安全と革新を両立させるカギとなるだろう。

関連する記事をみる

PAGE TOP