【ITニュース解説】A stack of SOPs won't stop a retrained model from shifting your risk file overnight

AIモデル、特に医療機器として機能するソフトウェア（SaMD）が私たちの生活に浸透するにつれ、その安全性と信頼性をどのように確保するかが重要な課題となっている。本稿では、AIモデルが持つ学習能力と、それが従来の品質管理システム（QMS）やリスク管理の枠組みにどのような課題を突きつけるかについて解説する。

医療機器ソフトウェアは、多くの場合、機械学習モデルを含んでいる。これらのモデルは、新しいデータが与えられると「再学習（retrain）」し、その振る舞いを変化させる特性を持つ。例えば、ある医療画像から病変を検出するAIモデルが、新たな患者データで再学習することで、以前とは異なる方法で判断を下すようになる可能性がある。このようなモデルの変化が、予期せぬリスクを生み出すことが懸念されている。

ある品質管理会議での出来事がこの問題の核心を突いている。もしSaMDが静かに再学習した場合、既存のリスク管理ファイル（システムが持つ潜在的な危険性とその対策をまとめた文書だと理解してほしい）は、この変化を捉えられているのだろうか。当時の議論では、既存の「市販後監視計画」がこの変化に対応しているという意見も出たが、実際にはその計画では不十分であったと筆者は指摘している。

筆者が指摘する根本的な問題は、**「リスクファイルはスナップショットであり、モデルは常に動いている」**という点にある。従来の品質管理システム（QMS：製品やサービスの品質を維持・向上させるための品質管理システム）は、一度決定された設計やリスク評価が比較的安定していることを前提として構築されてきた。しかし、学習するAIモデルは、再学習のたびに内部的な動作や性能が変わりうる。モデルの重み（判断基準）、学習に用いたデータの分布、特定の利用者グループにおけるエラーの傾向など、多岐にわたる要素が、エンジニアによる明示的な設計変更（Engineering Change Order、略してECO）を伴わずに変化することがある。これらの変化は、従来の「設計変更」の定義には当てはまらないため、正式な変更管理プロセスを経ずにシステムに適用されてしまうことが問題なのである。

このようなモデルの再学習による内部的な変化は、表面上は問題なく見えても、特定の条件下で新たなリスクや既存のリスクの増大を引き起こす可能性がある。例えば、ある特定の年齢層や疾患を持つ患者群（サブグループ）に対するモデルの診断精度が、再学習によって静かに低下してしまうケースや、モデルが運用中に学習したデータから、これまで想定していなかった新たな故障モード（システムの予期せぬ挙動や誤動作）を学習してしまうケースなどが考えられる。また、モデルの推論処理を行うソフトウェアの基盤（inference stack）の依存関係が更新された際に、数値計算の精度が変わることで、予測結果に微妙な差異が生じ、それが診断に影響を与える可能性もある。これらの変化は、システムのログデータには記録されるかもしれないが、従来の文書ベースの品質管理システムでは、自動的にリスク管理ファイルに反映されることはない。筆者はこれを「QMSはPDFを読んでいるが、リスクはJSONの中にある」と表現し、品質管理システムが公式な文書ばかりを追っている間に、システム内部の動的なデータの中にリスクの兆候が潜んでいる状況を指摘している。

国際的な標準規格や規制も、この問題の重要性を認識している。医療機器のリスクマネジメントに関する国際規格であるISO 14971:2019は、リスクマネジメントファイルを常に最新の状態に保つことを求めている。また、医療機器ソフトウェアのライフサイクルプロセスに関するIEC 62304も、ソフトウェアが変更された際にはリスクを再評価することを要求している。さらに、欧州連合で制定が進むEU AI Act（AI規制法案）は、高リスクとされるAIシステムに対し、データセットの変化や市販後の継続的な監視、重大なインシデントの報告義務など、より厳格な要件を課している。

米国食品医薬品局（FDA）が提唱するPredetermined Change Control Plan（PCCP：予め定められた変更管理計画）は、AIモデルの動的な変化に対応するための具体的なアプローチとして注目される。PCCPでは、どのような入力データが変化したときに、どのような条件でモデルを再評価するか、そしてモデルがどのような範囲内で動作すべきかを事前にプロトコルとして明確に定める。このプロトコルに沿って変更が行われる限りは、新たな承認申請が不要となるため、開発と運用の柔軟性が高まる。しかし、このプロトコルがなければ、モデルの再学習のたびに新たな申請が必要となる可能性があり、これは開発者にとって大きな負担となる。標準や規制は、本質的に「システムに加えられた変更と、それがもたらすリスクを継続的に関連付けて管理すること」を求めているのである。

このような状況に対し、筆者はいくつかの具体的な改善策を試みている。第一に、リスク管理ファイルが会議の決定からではなく、システムの稼働状況を示すデータ（テレメトリー：遠隔測定データ）から直接トリガーされる仕組みを構築することである。例えば、サブグループの性能が設定された閾値を超えて変動した場合、自動的にリスク管理のワークフローが起動される。これにより、人間が気づかないうちに発生するリスクの兆候を早期に検知し、対応を開始できる。

第二に、真に機能するPCCPを策定し、それを厳守することである。これには、モデルの再学習を引き起こすトリガー、再学習後のモデルを検証するための基準（バリデーションゲート）、そして問題が発生した場合に前の安定したバージョンに戻すための条件（ロールバック条件）を明確に定めることが含まれる。この約束事がなければ、本番環境でモデルの再学習を行うべきではないと筆者は考えている。

第三に、市販後の運用データ（Post-Market Surveillance: PMS）を、単なる報告書ではなく、設計の入力情報として直接活用する仕組みを構築することである。PMS計画書には、どのデータ信号がどのリスクコントロール（リスクを軽減するための対策）にフィードバックされるかを具体的に記述すべきである。これにより、製品が実際に市場でどのように機能しているかという貴重な情報が、次期製品の設計や既存製品の改善に直接活かされ、リスク管理のサイクルがより強固になる。

これらの取り組みは、特別なツールを導入することなく実現可能であると筆者は述べている。必要なのは、文書管理システムがリスク管理システムそのものではなく、あくまで「決定の記録」に過ぎないという事実を認識することである。真のリスク管理システムは、リスクを検知し、適切な判断を下し、その過程を記録する一連のプロセス全体を指す。そして、その中で最も見過ごされがちなのが「検知」の部分なのである。

しかし、これらの解決策を実践する上で、筆者自身もまだ課題に直面している。それは、「誰がリスク検知のトリガーを所有するのか」という問題である。システムの監視はデータサイエンスチームが行い、アラートは彼らのキューに入る。一方で、品質管理システムのワークフローは品質管理チームが担当する。このチーム間の引き継ぎ（ハンドオフ）の過程で、再学習によって引き起こされた変化がすり抜けてしまう可能性がある。システムエンジニアにとって、この課題は重要である。再学習イベントが品質管理システムにどのように確実に引き継がれ、そしてその引き継ぎが、机上の手続き論ではなく、日々の運用の中で実際に機能するためにはどうすればよいのか、この問いに答えることが、今後の安全なAIシステムの開発と運用において不可欠である。