ハイリスク／ノンハイリスクの2分法
コンピュータ化システムのバリデーション（CSV）や、近年FDAが推進するコンピュータソフトウェアアシュアランス（CSA）の世界では「そのソフトウェアにどれだけの労力をかけて検証すべきか」を決める出発点がリスク評価である。
検証の厳しさをリスクに見合った大きさに調整する、いわゆる「リスクベースアプローチ」の根幹をなす考え方だ。
ここで注目したいのが、FDAのCSAガイダンスにおけるリスクの分け方である。FDAは、プロセスリスクが本来は高リスクから低リスクまで連続的に広がる「スペクトラム（連続体）」であることを認めつつ、本ガイダンスでは実務上の判断軸を「ハイリスク（high process risk）」か「ハイリスクではない（not high process risk）」かという2区分で提示している。
本稿では、なぜこの2分法が用いられるのか、そして実務でどう使い分ければよいのかを、初心者にも分かるように解説する。
なお、本ガイダンスの対象範囲は、医療機器の製造または品質マネジメントシステムで用いるコンピュータ／自動データ処理システムである。
医療機器そのものであるソフトウェア（SaMD）や、医療機器に組み込まれるソフトウェアの設計開発に関する検証（V&V）は対象外である点に注意したい。
なぜ「2分法」なのか
リスクを細かく「高・中・低」と段階分けする方法は、一見すると丁寧で合理的に思える。しかし実務に落とし込むと「中リスク」の扱いが厄介な問題を生みやすい。
あるシステムの機能が「高でも低でもなく、中くらい」と判定されたとき、では具体的にどの程度の検証を行えばよいのか、明確な基準を引きにくいからだ。
「高」に寄せれば過剰な労力がかかり、「低」に寄せれば検証不足のリスクが残るーーこれは実務上しばしば指摘される悩みである。
そこでFDAは、本ガイダンス上の実務的な整理として、プロセスリスクを「ハイリスク（high process risk）」と「ハイリスクではない（not high process risk）」の2区分で提示している。
具体的には、ハイリスクに該当する機能には医療機器リスクに見合った保証活動を、ハイリスクではない機能にはプロセスリスクに見合った保証活動を選択する、という整理である。
ここで重要なのは、製造業者が内部的に「moderate（中等度）」「intermediate（中間）」「low（低）」といった独自の区分を持つこと自体は、FDAによって否定されていない点だ。
ただし、そうした区分に該当するものは、本ガイダンス上は「ハイリスクではない（not high process risk）」の枠組みで扱われる。
判断すべきは結局のところ「ハイリスクか、そうでないか」に集約されるのである。
なお「ノンハイリスク」という言葉は「低リスク」あるいは「リスクなし」と誤解されやすい。あくまで「ハイプロセスリスクではない（not high process risk）」という意味であり、検証が不要という意味ではない点に注意したい。
用語解説：プロセスリスクと医療機器リスク
ここで2つの重要な用語を区別しておきたい。
プロセスリスク（process risk）とは、製造工程や品質システムそのものを損なう可能性を指す。
一方、医療機器リスク（medical device risk）とは、医療機器が患者またはユーザーに危害を及ぼす可能性を指す。
そしてFDAが定義する「ハイプロセスリスク」とは、ソフトウェアが意図したとおりに機能しなかった場合に、安全性を損なう恐れのある品質問題につながりうる状態、すなわち医療機器リスクの増大につながりうる状態を指す。
平たく言えば「そのソフトが誤動作したら、巡り巡って患者の安全が脅かされかねないか」という問いに「はい」と答えられるものが、ハイリスクなのである。
なお、ここでの危害の評価は「合理的に予見可能（reasonably foreseeable）」かどうかという観点で行われる。
FDAは、発生可能性が高い（likely）失敗だけでなく、ライフサイクルを通じて合理的に予見可能な失敗を考慮するとしており、たとえば発生可能性は必ずしも高くないものの予見はできる「停電」を例に挙げている。
発生確率を細かく数値化する確率論的なアプローチとは、視点が異なる点が特徴である。
具体例で理解する2分法
抽象的な定義だけでは分かりにくいので、具体例で見てみよう。
ハイリスクに該当するソフトウェアの例
製造記録（バッチレコード）を管理・計算するソフトウェア
品質試験の結果を取得・判定するソフトウェア
製品の出荷可否を判定するソフトウェア
これらは、追加の人手確認が限定的または存在しない場合、誤動作により不良品の見逃しや誤った判定につながり、患者の安全を脅かしうる。
たとえばバッチレコードの計算に誤りがあれば、規格外の製品がそのまま流通しかねない。
だからこそ厳格な検証が求められる。逆に言えば、製品やプロセスの受入可否を測定・判定する機能であっても、十分に独立した人手による確認が併存している場合には、ハイリスクの評価が変わりうる。
ハイリスクに該当しないソフトウェアの例
教育訓練記録を管理するソフトウェア（学習管理システム＝LMS）
一般的な文書管理（ドキュメント管理）のソフトウェア
CAPA（是正・予防措置）のルーティング、苦情ログ、変更管理、手順管理など
これらは品質システムの運用に役立つものの、その失敗が直接患者の安全を損なうとは考えにくい。
したがって、ハイリスク機能と同等の保証活動が常に必要になるわけではなく、プロセスリスクに見合った保証活動を選択すればよい。
ただし注意が必要なのは、文書・手順を管理するソフトウェアであっても、ラベリングや安全上重要な手順を生成・管理する機能については高リスク化しうるという点である。
同じ「文書管理」でも、扱う対象によって判定が変わる可能性がある。
このように、ハイリスクでない機能については、スクリプト化された厳密なテストではなく、シナリオテスト、エラー推測、探索的テストといった非スクリプト型（unscripted）の手法を、リスクに見合った形で柔軟に組み合わせて用いることが認められている。
労力を本当に必要な箇所に集中させる、という思想がここに表れている。
注意点：システム単位ではなく「機能単位」で見る
最後に、実務上きわめて重要な落とし穴を指摘しておきたい。
従来の設備管理（製造ラインの装置や空調設備など、ハードウェア寄りの設備）では、設備単位でまとめてリスクを一括評価することもある。
設備ごとにリスクの性質がそろっていれば「この装置はハイリスク」と一括りにしやすいからだ。
ところが、相手がアプリケーションソフトウェアとなると話は変わる。
FDAも、ソフトウェアは複数のフィーチャー（feature）・機能（function）・操作（operation）から構成され、意図した用途やリスクが異なる場合にはそれぞれを個別に評価することを推奨している。
つまり、1つのシステムの中に、リスクの異なる機能が混在していることが多いのである。
たとえば、ある業務システムが「出荷判定（ハイリスク）」と「教育訓練記録の管理（ノンハイリスク）」の両方の機能を併せ持っている、というケースは珍しくない。
このような場合、システム全体を一律に「ハイリスク」あるいは「ノンハイリスク」と判定してしまうのは適切ではない。
システム単位ではなく、機能・操作単位でハイリスクかどうかを見極め、それぞれに見合った検証を割り当てる必要がある。
2分法はあくまで「機能ごとの判定」に適用するものだ、と理解しておくことが肝要である。
まとめ
FDAがプロセスリスクを「ハイリスクか否か」の2分法で提示するのは、リスクが連続的なスペクトラムであることを認めつつ、判断の軸を「患者の安全に関わるか」という一点に絞り込むためである。製造記録・品質試験・出荷判定に関わるソフトウェアは原則ハイリスクとして厳格に、教育訓練や一般的な文書管理のソフトウェアは「ハイリスクではない」ものとして柔軟に検証する。ただし、独立した人手確認の有無や、扱う文書がラベリング・安全上重要な手順かどうかによって判定は変わりうる。そして何よりも、システム単位ではなく機能単位でリスクを見極めることが、この2分法を正しく運用する鍵となる。
シンプルな枠組みであるからこそ、その背後にある「リスクに見合った労力配分」という思想を理解して使いこなしたい。
出典
FDA, Computer Software Assurance for Production and Quality Management System Software（現行ガイダンス。2026年2月3日発行版が2025年9月24日発行版を置き換え）
FDA, Computer Software Assurance for Production and Quality Management System Software（本文PDF）
（参考：履歴）Federal Register, Computer Software Assurance…; Availability（2025年9月24日発行版）
