【連載】リスクマネジメントは机上の空論か？現場で起きる誤解――「ハザード」「危険状態」「危害」を区別できないとき、リスク分析は書類作成に変わる（第6回）

リスクマネジメントが机上の空論に見えるとき、現場ではたいてい、次のどれかが起きています。

一つ目は、申請の直前にまとめて書類が作られる場合です。開発がほぼ終わった段階で、薬事の担当者から「リスクマネジメントファイルをそろえてください」と依頼が来る。そこで初めて、過去の製品の表を開き、書き換えが始まります。

二つ目は、前の製品の表がそのまま引き継がれる場合です。機能は増えているのに行は増えず、過去に「受容できる」とされた行が、疑われることなく残ります。

三つ目は、表が完成しても、設計が何も変わらない場合です。分析で見つかった問題は設計レビューで議論されず、取扱説明書に注意書きが一行加わって終わります。

三つに共通するのは、リスクについての判断が、設計についての判断より後ろに置かれていることです。表は、判断の結果を記録するための道具のはずです。その道具が、判断そのものを置き換えてしまっているのです。

ISO 14971:2019 （Medical devices — Application of risk management to medical devices）の 4.1 は、製造業者に、リスクマネジメントのプロセスを確立し、実施し、文書化し、維持することを求めています。第4回で、規制が求めているのは文書そのものではなく「確認できること」だと述べました。リスクマネジメントでも同じで、求められているのはプロセスであり、書類は、そのプロセスが実施されたことの記録にすぎません。

では、書類が判断を置き換えてしまう入り口は、どこにあるのか。多くの場合、それは用語の取り違えにあります。

プロジェクトマネージャが「リスク」と聞いて、真っ先に思い浮かべるのは、納期の遅れや予算の超過でしょう。国際規格 ISO 31000 （Risk management — Guidelines）も、リスクを「目的に対する不確かさの影響」と定義しており、好ましい影響（予想外の収益や新しい機会）も含みます。

一方、ISO 14971 のリスクは、「危害の発生確率とその危害の重大さとの組合せ」です。しかも、適用範囲（箇条1）は、「ビジネス上のリスクマネジメントには適用しない」と、はっきり書いています。

この違いは、他の業界から医療機器に参入する組織ほど、見落としやすいものです。プロジェクトのリスク登録簿の延長でリスク分析表を作ると、「リリースの遅延」「要員の不足」といった項目が並びます。どれも現実の課題ですが、患者や使用者に何が起きるのかは、どこにも書かれていません。

第2回で述べたとおり、安全とは「受容できないリスクがないこと」です。その「リスク」の単位は、患者や使用者に起きる危害であり、納期やコストのリスクは別の表で扱うべきものです。

ISO 14971 は、リスクを、ある連鎖として捉えています。まず、主な用語を、定義のとおりに確認しておきます。

• 危害（Harm）：人への傷害若しくは健康被害、又は財産若しくは環境への損害（3.3）
• ハザード（Hazard）：危害の潜在的な源（3.4）。機械安全の分野では「危険源」とも呼ばれます
• 危険状態（Hazardous Situation）：人、財産又は環境が、一つ以上のハザードにさらされている状況（3.5）

定義だけでは違いが見えにくいので、附属書Cの図C.1が示す考え方を、電子ポットで説明します。（図表1(a)）

電子ポットのハザードは、中に入っている熱湯、つまり熱エネルギーです。ここで押さえておきたいのは、ハザードは「出来事」ではなく「危害のみなもと」だということです。熱湯があるだけでは、誰も傷つきません。

次に、コードに引っかかってフタが開き、お湯がこぼれたとします。規格は、ハザードから危険状態に至る経路を「一連の事象」と呼びます。こぼれたお湯に人がさらされている状況が、危険状態です。

危険状態になっただけでは、まだ危害ではありません。気づいて避けられるかもしれない。こぼれたお湯に触れ、やけどを負って、初めて危害になります。

規格は、一連の事象によって危険状態が生じる確率を P1、危険状態が危害に至る確率を P2 とおき、危害の発生確率は、この二つの組合せで考えます。リスクは、その確率と、危害の重大さの組合せです。

この連鎖は、ポットに限った話ではありません。ISO/TR 24971:2020 （Medical devices — Guidance on the application of ISO 14971）の表F.1が示す、輸液ポンプのサイバーセキュリティに関連するリスクの例を見てみましょう（図表1(b)）。表F.1では、データの完全性・可用性・機密性の喪失がハザードとして整理されています。データそのものが人を傷つけるわけではありませんが、そこから危害に至る連鎖の出発点になるからです。ここでは「データの完全性の喪失」がハザードです。使われていないネットワークポートが開放されているという脆弱性が悪用され、不正アクセスによって投与量が変更される。これが一連の事象です。ハザードではなく、一連の事象の側に脆弱性が置かれている点に注目してください。その結果、意図したとおりに投与されない、誤った投与量設定という危険状態になり、健康状態の悪化や死亡という危害に至ります。

図表1(b)：セキュリティに関連するリスクの例（ISO/TR 24971:2020 表F.1）より第1行を抜粋

リスク分析表の各列は、この連鎖に対応しています。四つの項目を過不足なく埋められるかどうかが、適切な分析ができるかどうかの分かれ目です。

用語の関係が分かると、現場でよく見かける取り違えの構造が見えてきます。

誤解①　ハザードの欄に「ソフトウェアのバグ」と書く

規格の定義に沿って整理すると、ソフトウェアのバグは「危害の潜在的な源」というより、危険状態に至る一連の事象の中に現れる原因です。ここにバグと書くと、分析は故障モードの列挙で止まりがちです。「バグがある」ことと「患者に何が起きるか」の間には、危険状態と危害という二つの中間項があるからです。

FMEA（Failure Mode and Effects Analysis：故障モード影響解析）の経験が豊富な方ほど、この罠に入りやすいかもしれません。設計FMEAの「故障モード」は、リスク分析では「危険状態」または「一連の事象」におおむね相当します。そして「故障の影響」は、システムへの影響ではなく、人が受ける傷害や健康被害、つまり危害まで書く必要があります。（図表2）
FMEAの表をそのまま流用して「システムが停止する」で止めると、それはリスク分析になりません。

図表2：設計FMEAの項目と、ISO 14971 のリスク分析の用語の対応

なお、何をハザードと呼ぶかには、組織によって幅があります。大切なのは、組織の中で定義をそろえ、一貫して使うことです。

誤解②　危害を「機器への影響」で書く、あるいは中間項を飛ばす

「システムが停止する」「画面が固まる」。これらは機器の挙動であり、危害ではありません。危害は、人への傷害や健康被害（および財産・環境への損害）です。

重大さは、機器の挙動ではなく、危害の程度で決まります。同じ「停止」でも、生命維持に関わる機器なのか、代替手段のある補助的な機器なのかで、患者に起きることはまったく違います。同じ機器の挙動でも、「意図する使用（Intended Use）」が違えば、リスクは別物になります。

中間項を飛ばす問題もあります。「故障したら死亡」と一足飛びに書くと、手を打てる場所が見えなくなります。リスクコントロールは、一連の事象の途中で（P1）を下げるのか、危険状態から危害に至る経路（P2）や重大さを下げるのかで、性質が変わります。中間項を書いていない表は、対策を検討する材料になりません。

誤解③　ソフトウェアは確率が出せないから、評価を諦める

ソフトウェアの不具合は、部品の故障のようにランダムに起きるのではなく、特定の条件で系統的に現れます（Systematic Failure）。第2回で見たとおり、発生確率の推定は難しいと言えます。ここから、二つの極端な運用が生まれます。

一つは、IEC 62304 （Medical device software — Software life cycle processes）の取り決めを、リスク評価にまで持ち込むことです。同規格の 4.3 は、ソフトウェア安全クラスを決めるときに、ソフトウェア故障の確率を 1（100%）と仮定します。これは、ソフトウェアが故障する確率の議論を省いて、重大さに基づいてクラスを決めるための仮定です。評価でも常に最悪値を置くと、保守的ではありますが、ソフトウェア起因の行が全て同じ位置に並び、対策の優先順位を判断する材料が失われてしまいます。

もう一つは、根拠なく「まれ」と置いて、受容可能にしてしまうことです。これは机上の空論そのものです。

ISO 14971 の 5.5 は、危害の発生確率が推定できない危険状態については、起こり得る結果を列挙し、リスク評価とリスクコントロールに用いることを求めています。重大さに着目して判断する道が、規格に用意されているのです。実務上も、P1 が見積もれなくても、P2 は、使用環境や臨床の状況、他の監視手段の有無から議論できる場合があります。確率が出せないことは、評価を放棄する理由になりません。

誤解④　受容基準を結果の後で決める。ベネフィットを免罪符にする

リスク評価は、リスクマネジメント計画に定めた、リスクの受容可能性の判断基準に照らして行います（ISO 14971 4.4、箇条6）。基準が先で、評価が後です。ところが現場では、分析結果を表に載せてから、「このあたりまでは緑にしよう」と色分けを決めてしまう場合があります。基準が判断を導くのではなく、判断が基準を作っている。これでは、評価をしたことになりません。

もう一つは、ベネフィット・リスク分析の使い方です。7.4 は、基準では受容できず、さらなるリスクコントロールも現実的でない残留リスクについて、「意図する使用」の医療上のベネフィットが、その残留リスクを上回るかを判断するためのものです。ベネフィットは、規格で「個人の健康に与える有益な影響若しくは望ましい結果、又は患者管理若しくは公衆衛生に与える有益な影響」と定義されています（3.2）。納期や売上は含まれません。「ここまで来たら設計は変えられない」という事情を、ベネフィットとして持ち出すことはできないのです。

誤解⑤　対策を入れれば終わり、リリースすれば終わり

リスクコントロール手段は、実施しただけでは終わりません。7.2 は、手段が実施されたことの検証に加えて、その有効性の検証を求めています。そして 7.5 は、その手段が新たなハザードや危険状態を生まないか、すでに評価したリスクが変わらないかを確認することを求めています。誤検出して正常な機能まで止めてしまう異常検出センサーのように、よかれと思って入れた対策が、新たなリスクを生む例は少なくありません。（図表3）

リスクマネジメントは、リリースした後でも終わりません。箇条10は、製造及び製造後の段階で、その医療機器に関連する情報を収集し、レビューする仕組みを求めています。不具合報告も脆弱性情報も、リスク分析表に戻ってくるループがあって初めて、第2回で見た「相対的な安全」が維持されます。五つの誤解と、関係する箇条を、図表4にまとめます。

机上の空論を、判断の道具に戻す三つの問い

五つの誤解は、用語の連鎖が書類の上でだけ閉じてしまっていることから起きます。自分たちの表が判断の道具として機能しているかどうかは、次の三つの問いで確かめられます。

第一に、表の一行を、一文で読めるかどうかです。「〜というハザードがあり、〜という事象が起きると、〜という危険状態になり、〜という危害に至る」。声に出して読めない行は、四つの項目のどれかが欠けています。

第二に、設計とつながっているかどうかです。リスク分析の結果が設計レビューで議論され、設計変更がリスク分析表の更新を引き起こしているか。前回見た設計レビューの場に、リスク分析表が載っているかを確かめてください。「小さな変更だから影響なし」と更新を飛ばすことが、最も危険です。

第三に、市販（リリース）後から戻ってくるかどうかです。不具合報告や脆弱性情報を受けて、表が更新された実績があるか。更新の記録が一件もない表は、リリースの日から止まっています。

この三つを回すには、誰が表を書くかも重要です。ISO 14971 の 4.3 は、リスクマネジメントのタスクを担う要員に、そのタスクに見合った知識と経験を求めています。一連の事象を書けるのは、設計を最もよく知る開発者です。リスク分析をQAだけの仕事にすると、設計の知識が表に入りません。開発が作り、QAがレビューして承認する、という分担が実務的です。（図表5）

リスクマネジメントは、書類ではなく判断である

リスクマネジメントが机上の空論になるのは、規格が現実離れしているからではありません。ハザード、危険状態、危害という連鎖を、現場の判断につなげる前に、書類の形に整えてしまうからです。

生成AIは、リスク分析表の行を短時間で大量に作れます。しかし、行が増えても、判断が増えるわけではありません。連鎖が一文で説明でき、設計が変わり、市販後の情報が戻ってくる。そこまで確かめる責任は、人間に残ります。

リスクマネジメントとは、文書をそろえることではなく、患者を守るための判断プロセスを、組織に根付かせることです。

あなたの組織のリスク分析表は、これまでに、設計を変えたことがありますか？

次回予告

第7回は「変更が怖くなる組織、変更を管理できる組織」をテーマに取り上げます。今回の最後に触れた「小さな変更だから影響なし」という判断は、なぜ最も危険なのか。変更のたびにリスクを再評価できる組織と、変更そのものを恐れるようになる組織を分けるものは何かを考察し、整理します。

参考文献・規格

ISO 14971:2019 「医療機器―リスクマネジメントの医療機器への適用」 1（適用範囲）／3.2／3.3／3.4／3.5／4.1／4.3／4.4／5.5／6／7.2／7.4／7.5／10／附属書C
ISO/TR 24971:2020 「医療機器―ISO 14971 適用の手引」 附属書F 表F.1
IEC 62304:2006/AMD1:2015 「医療機器ソフトウェア―ソフトウェアライフサイクルプロセス」 4.3
ISO 31000:2018 「リスクマネジメント―指針」
IEC 60812:2018 「故障モード及び影響解析（FMEA 及び FMECA）」

参考サイト

ポータルサイト：https://www.medicalsoftwareconsulting.com/
規格解説動画：https://www.youtube.com/@MedicalSoftwareConsulting
医療機器ソフトウェア 規制・規格 知識データベース：https://watch.medicalsoftwareconsulting.com/

過去回リンク

第1回：https://www.veriserve.co.jp/helloqualityworld/media/20260603001/
第2回：https://www.veriserve.co.jp/helloqualityworld/media/20260708001/
第3回：https://www.veriserve.co.jp/helloqualityworld/media/20260817001/
第4回：https://www.veriserve.co.jp/helloqualityworld/media/20260909001/
第5回：https://www.veriserve.co.jp/helloqualityworld/media/20261006001/