BE Health Ventures
投資・臨床戦略担当 副総経理　沈信緯 

 

AI SaMD（AI搭載医療機器ソフトウェア）が承認取得および IEC 62304 への適合を達成する上で、最もボトルネックとなりやすいのはモデルの精度不足ではありません。むしろ、AI特有の非決定性を、本来は決定論的ソフトウェアを前提として設計されたライフサイクルフレームワークに無理に当てはめようとする点にあります。その結果、形式上は整っているように見えても実質的には保守不可能なドキュメント群を生み出し、開発そのものを停滞させてしまうケースが多く見受けられます。 

実装可能かつ実効性のあるアプローチは一つに集約されます。すなわち、AIの非決定性を有するモジュールを決定論的なシステムフレームワーク内に内包し、最小限でありながら完全性を担保した設計管理（Design Control）およびトレーサビリティ（Traceability）の構造を構築することです。これにより、規制当局がリスクを適切に評価可能となると同時に、開発チームとしてもコストおよび開発スピードをコントロール可能な状態を維持することができます。 

 

一、AIの位置づけを明確にする ― 例外ではなく、Software Itemとして定義する
IEC 62304 は、AIを用いたからといってルールが変わるわけではありません。本規格が一貫して重視しているのは、「ソフトウェア安全クラス分類（Class A／B／C）」および「ライフサイクルプロセス」の2点です。したがって、ドキュメントの冒頭において、AIモジュールをIEC 62304の文脈に適切に位置づける必要があります。一般的に、AIモジュールはソフトウェア項目（Software Item）またはソフトウェアモジュールとして扱われます。これはすなわち、当該モジュールも他のソフトウェアと同様に、安全分類、設計管理（Design Control）、バージョン管理およびアップデート管理の対象となることを意味します。 

この位置づけは単なる形式論ではなく、審査における論理構造そのものに関わる重要なポイントです。AIをSoftware Itemとして定義することで、審査者に対してはニューラルネットワークの内部構造を詳細に説明するのではなく、「高リスクなブラックボックスモジュールをいかにシステム全体の統制下に置き、検証可能性（Verifiability）、トレーサビリティ（Traceability）、およびロールバック可能性（Rollbackability）を担保しているか」を示すことになります。 

さらに実務的な観点では、安全クラスの過小評価は重大なリスクを伴います。一度分類を誤ると、その後のドキュメント構成や検証・試験戦略全体に対して強い疑義が呈される可能性があります。特に診断または治療意思決定に関与するAIの場合、実務上はClass BまたはClass Cに分類されるケースが一般的です。安全クラス分類は単なる規制上の選択肢ではなく、必要となるエビデンスのコスト構造、上市までのタイムライン、さらには審査過程における質疑の深度を直接的に規定する重要な要素です。 

 

二、設計管理（Design Control）のMVP ― 最短経路でDHFの骨格を構築する 

IEC 62304 における設計管理とは、実務的にはソフトウェア開発プロセスとリスクコントロールを一体の流れとして結びつけることを意味します。この最小構造は、そのままDHF（Design History File：設計履歴ファイル）の原型に対応します。ここで求められるのは、膨大なドキュメントの集合ではなく、審査において一貫して追跡可能な「通るべき経路」を構築することです。そして、その各ステップが必ずエビデンスへと接続されている必要があります。最短経路は以下に集約されます：SRS → SAD → SDS → 実装 → V&V。 

実装にあたっては、審査者にとって理解しやすい3つの設計アクションを確実に押さえることが重要です。審査者が評価するのはドキュメントの分量ではなく、不確実性が工学的に制御可能な形へと収束されているかどうかです。 

第一のアクション：SRSにおいてAI要件を「検証可能なシステム挙動」として定義する 

システム要求仕様書（SRS）では、「AIが病変を検出する」といった抽象的な記述に留めてはいけません。AIの不確実性を、システムとして制御可能なルールへと変換する必要があります。例えば、「AIモジュールの出力には必ず信頼度（confidence score）を付与すること」「当該信頼度が事前に定義された閾値を満たした場合にのみ、システムはその結果を採用すること」「閾値を下回る場合には、システムはフェイルセーフとして低機能モードへ移行する、もしくは人によるレビューを要求すること」といった形で明確に規定します。 

ここで重要なのは、閾値が0.8か0.75かといった数値そのものではなく、リスクコントロールが検証可能かつ試験可能なシステム挙動として記述されているかどうかです。このステップの本質は、モデル性能に内在する不確実性を、システム挙動としての確実性へと変換する点にあります。これにより、審査当局はリスクコントロールを設計の一部として理解できるようになり、リスクを単にモデルに委ねるのではなく、設計として統合されていることが明確になります。 

 

第二のアクション：SADにおいてAIをブラックボックスサービスとして抽象化し、インターフェース定義を厳格に行う 

ソフトウェアアーキテクチャ設計（SAD）レイヤーでは、モデル内部の構造を詳細に開示する必要はありませんが、AIを統制可能なサービスモジュールとして定義することが不可欠です。少なくとも以下の境界条件を明確にし、検証可能かつテスト可能な形で定義する必要があります。 

• 第一に、入力仕様の定義です。入力データの形式および許容範囲、画像や信号の仕様、欠損値の取り扱い、例外ケースを含めて明確に規定します。 

• 第二に、前処理の定義です。どの処理が固定ルールとして実装されるのか、どの処理がモデル出力に影響を与えるのかを区別して明示します。 

• 第三に、出力仕様の定義です。出力は必ず構造化データとして定義し、分類結果、位置情報、信頼度（confidence）、アラートフラグなどの必須フィールドを明確にします。 

• 第四に、インターフェース仕様の定義です。APIシグネチャ、バージョン管理、後方互換性、ならびにロールバック戦略を含めて規定します。 

• 第五に、エラーハンドリングおよびタイムアウト処理です。障害発生時または遅延時において、システムがどのような状態へ遷移するかを定義します。 

• 第六に、信頼度閾値のシステムへの組み込み方法です。低信頼度時の処理フロー、UI上の表示、ログ記録および監査トレイルの設計を明確にします。 

審査者が確認するポイントは、ブラックボックスであるAIの境界条件が適切に制御されているかどうかです。仮にモデルが完全に説明可能でない場合であっても、工学的に定義された境界条件により、システムが異常時においても制御可能な状態を維持できることが重要です。すなわち、リスクコントロールをモデル内部に委ねるのではなく、システム設計として担保していることを明確に示す必要があります。 

 

第三のアクション：SDSは逐次的な説明ではなく、「規範化」による統制を行う 

最小実行可能なソフトウェア詳細設計（SDS）において重要なのは、AIモジュールを「監査可能なエンジニアリング成果物」として定義することです。ニューラルネットワークの内部構造を逐一説明する必要はありません。むしろ、「当該モデルがどのように定義され、どのように構築され、どのように再現（再実行）可能であるか」を説明できる、再現性およびトレーサビリティのある制御ポイントを確立することが求められます。 

そのため、SDSでは少なくとも以下の要素を記述し、かつ一貫したバージョン管理のもとで紐づける必要があります。 

• 第一に、モデルアーキテクチャの種類および制約条件です。分類・検出・セグメンテーションのいずれに該当するのか、前処理および後処理パイプラインの有無を含めて明確にします。 

• 第二に、入力・出力フォーマットおよび前処理／後処理の規定です。正規化、クロッピング、ノイズ除去、特徴量抽出など、固定ルールとして実装される処理を明示します。 

• 第三に、学習データの出所およびアノテーション品質管理です。アノテーション基準、アノテーターの資格要件、相互評価（inter-rater agreement）、およびデータ除外基準を含めて定義します。 

• 第四に、データ分割戦略です。少なくともtrain／validation／testの分割方針を明確にし、外部データや多施設データの位置づけおよび使用方法を説明します。 

• 第五に、トレーニングプロセスのフレームワーク設計です。主要なハイパーパラメータのバージョン管理、乱数シードの固定、トレーニング環境および依存ライブラリのトレーサビリティを確保します。 

ここで行っているのは学術論文の記述ではなく、エンジニアリングガバナンスの構築です。すべての再実行において、「この結果は同一のエンジニアリング条件下で再現可能であり、かつ監査可能か」という問いに対して明確に答えられる状態を担保することが求められます。 

 

三、バージョン管理および変更管理 ― Retrainingをソフトウェア更新として扱うことで、合規性は一気に担保される 

AI SaMDにおいて最も頻出する課題は、モデルの更新サイクルは高速である一方、バージョンのトレーサビリティが確保されていない点です。IEC 62304 に基づく実務的な解決策は極めて明確です。すなわち、すべてのトレーニングおよび再トレーニング（Retraining）を「ソフトウェア更新」として扱い、更新計画およびロールバック戦略を必ず定義することです。 

また、バージョン命名は単なる「v1.2」といった内部ラベルに留めるべきではありません。モデルバージョンは、使用したトレーニングデータセットのバージョン、およびハイパーパラメータのバージョンと厳密に紐づけて管理する必要があります。これにより、任意の時点において以下の問いに即座に回答可能となります：「現在市場に提供されているモデルはどのバージョンか」「どのデータセットで学習されたか」「どのハイパーパラメータが使用されたか」「前バージョンとの差分は何か」。 

この領域は一見すると単なるエンジニアリング管理の問題に見えますが、実際にはグローバル規制対応における共通言語でもあります。FDA が重視するのは、市販バージョンと変更後バージョンの差異を明確に説明できるか、そしてリスクコントロールが引き続き有効であるかという点です。一方、欧州のMDR などの市場では、変更管理がQMS（品質マネジメントシステム）に組み込まれているか、さらに監査時にバージョンとエビデンスの連鎖を一貫して提示できるかが重視されます。 

加えて、企業統治および投資家の視点においても、この領域は極めて重要です。投資後の監査やM&Aにおけるデューデリジェンスにおいて頻繁に確認されるポイントであり、最終的には「当該企業のエビデンスが信頼に足るかどうか」を左右する中核要素となります。 

 

四、V&V（検証・妥当性確認）の最小実装 ― 非AIは単体テスト、AIはエンドツーエンドと性能エビデンスで担保する 

多くのチームは検証および妥当性確認（V&V）を過度に複雑に設計しがちですが、その結果、自ら維持できない状態に陥るケースが見受けられます。最小実行可能なアプローチは、むしろ審査者の思考に近く、V&Vを三層構造として整理することで、エビデンスの連鎖をシンプルかつ可読性の高い形で構築することが可能です。 

• 第一層：非AIモジュールは標準的な単体テスト（Unit Test）を適用します。データパイプライン、インターフェース、ルールロジック、UI表示、例外処理について、各更新後に自動的に検証される仕組みを確立します。 

• 第二層：AIモジュールはエンドツーエンドテストおよび性能評価試験を実施します。これらは申請時に規定した臨床用途（Intended Use）と整合させる必要があり、性能指標は必ずリスクコントロール要件と紐づけて定義します。 

• 第三層：システムレベルでは統合試験およびシステム検証を実施します。インターフェース仕様、境界条件、フェイルセーフとしての降格動作（degradation）、および人によるレビュー介入フローが適切にトリガーされるかを確認し、さらに臨床データまたはシミュレーションデータ上で、感度（sensitivity）、特異度（specificity）などの主要性能指標が維持されていることを検証します。 

ここで重要なのは、テストの量ではなく、AIの不確実性を「測定可能な性能指標」と「検証可能なシステム挙動」に落とし込めているかどうかです。SRSにおいて信頼度閾値および降格モードを定義した場合、V&Vでは少なくとも以下の2点を証明する必要があります。すなわち、高信頼度領域においては性能が規定値を満たしていること、低信頼度領域においてはレビュー要求または降格動作が確実に発動すること、さらに統合インターフェースが境界条件下でも破綻しないことです。 

審査者が確認したいのは、リスクが主張によってではなく、制御構造によって管理されているかどうかです。すなわち、リスクコントロールが設計および検証プロセスの中に一貫して組み込まれていることを示すことが求められます。 

五、Traceability MatrixのMVP ― 巨大なクロス表ではなく、監査可能な「エビデンスチェーン」を構築する 

Traceabilityの最小可行定義は非常にシンプルです。すなわち、「リスクからエビデンスまで一貫して辿れる一本の線を構築できること」です。網羅的で巨大なクロスリファレンステーブルを維持する必要はありません。重要なのは、各リスクが少なくとも1つの要求事項、設計項目、テストケース、およびエビデンス文書に確実に紐づいていることです。 

実務上は、Traceabilityの主表（マスターテーブル）を単一の信頼できる情報源（Single Source of Truth）として管理することを強く推奨します。主表には最小限、以下の項目を明確に定義し、全ドキュメントで一貫した命名規則を適用する必要があります。 

• 第一に、Risk ID：ISO 14971 に基づくリスク項目との対応付け 

• 第二に、Requirement ID：SRSにおけるシステム要求との対応付け 

• 第三に、Design Item ID：SADまたはSDSにおける設計項目との対応付け 

• 第四に、Test Case ID：V&Vにおけるテストケースとの対応付け 

• 第五に、Evidence Location：試験報告書や関連ファイルの保存場所（アクセス可能かつ監査追跡可能であること） 

実践的な制御ロジックは、一本のストーリーとして接続することで明確になります。例えば「希少病変の見逃しリスク」を対象とする場合、まずリスク項目R-001を定義します。次に要求仕様としてSR-001を設定し、「AI出力に信頼度を付与し、閾値未満の場合には必ず人的レビューを要求する」ことを規定します。設計段階ではD-AI-001として、AI出力とシステムによるレビュー促進ロジックを実装します。テスト段階ではTC-001を用い、外部の希少病変データセットに基づき、高信頼度領域における感度が規定値を満たすこと、ならびに低信頼度サンプルが適切にレビュー対象としてフラグ付けされることを検証します。最後に、AI_Test_Report_v1.0.pdfなどの試験報告書をエビデンスとして主表に紐づけます。 

このように一本のトレーサビリティラインが確立されていれば、それ自体が最小構成でありながら、十分に監査可能なコントロール構造として機能します。 

 

六、維持可能なアーキテクチャ設計 ― 「主表＋3分表」とAI特有の2つの制御ポイント 

見落とされがちなポイントの一つが、将来的な保守コストです。実務的に成熟した最小構成では、1つの主表（マスターテーブル）に加えて3つの分表を組み合わせることで、更新コストを抑制しつつ、トレーサビリティを明確に維持します。 

• 第一の分表：リスク → 要求（Risk to Requirement）
  　すべてのリスクが確実に要求事項へと展開されていることを担保します。 

• 第二の分表：要求 → 設計（Requirement to Design）
  　すべての要求が設計上の実装ポイントへと追跡可能であることを保証します。 

• 第三の分表：要求 → テスト（Requirement to Test）
  　すべての要求に対して対応するテストケースおよびエビデンスが存在することを担保します。 

運用ツールはExcelでもALMツール（例：Jira）でも構いませんが、重要なのはツールではなく運用ルール（SOP）です。特に明確に定義すべきは、「AIモデルの追加または変更が発生した場合には、必ずトレーサビリティの起点および関連リンクを同時に更新する」という点です。これを徹底しなければ、次回の監査や上市後の変更管理において、ドキュメント体系は容易に分断されてしまいます。 

さらに、AI SaMDにおいてはほぼ確実に問われる2つの論点が存在します。これらについては最小限の拡張で事前に対応し、Traceabilityチェーンに自然に組み込むことが重要です。 

第一の論点は「ブラックボックス性と説明可能性（Explainability）」です。完全な可説明性を保証する必要はありませんが、合理的な説明手法および適用シナリオを提示できることが求められます。代表的な症例に対する可視化結果や説明出力を、設計および検証エビデンスとして組み込むことが有効です。実務的には、SDSにおいて説明可能性の手法および出力形式を定義し、Traceabilityに「Explainability Method」項目を追加して、関連ドキュメントやレポートへリンクさせる形が推奨されます。 

第二の論点は「データドリフトおよびモデル劣化（Model Degradation）」です。データモニタリングおよび性能劣化の検知ロジックをSRSに明記し、それを監視モジュール設計および市販後監視（Post-market Surveillance）計画へと接続する必要があります。これにより、リスクが上市前だけでなく製品ライフサイクル全体にわたって管理されるべきものであることを示すことができます。Traceabilityには「Drift Monitoring」または「Post-market Monitoring」といった項目を追加し、該当する設計および計画文書へリンクさせることが有効です。 

これら2つの制御ポイントは単なる付加機能ではなく、審査者に対して「AI特有のリスクがライフサイクル全体にわたり存在することを理解し、それをエンジニアリングガバナンスによって統制できている」ことを示すための重要な要素です。 

 

結語：VCの視点 

バイオ・ヘルスケア領域のベンチャーキャピタルにおけるデューデリジェンスの観点では、チームが IEC 62304 を実務レベルで適切に実装できるかどうかは、単なるコンプライアンス対応コストではなく、「希少な競争優位性」として評価されます。その理由は極めて現実的です。デジタルヘルスおよびバイオテック領域において、迅速に市場投入を実現し、かつ長期的に存続できるチームは、必ずしもモデルアーキテクチャの説明に長けたチームではなく、むしろエンジニアリングガバナンスを確実に実装できるチームであるケースが大半です。 

AIをSoftware Itemとして明確に定義できているか、不確実性を検証可能なシステム挙動へと変換できているか、Retrainingをトレーサブルなソフトウェア更新として安定的に管理できているか、さらに最小限のTraceabilityによってリスクからエビデンスまでの連鎖を確実に構築できているか。これらはいずれも、開発スケジュールの予測可能性、臨床および規制エビデンスの積み上げの確実性、さらには将来的なM&Aやエグジット時のデューデリジェンスにおいて、「この優れた結果がどのモデルバージョンから得られたものか」を即座に説明できるかどうかを直接的に左右します。 

投資家の視点から見れば、この最小可行アーキテクチャによって得られる価値は、単なるドキュメント整備ではありません。それは「確実性」です。すなわち、規制リスクおよび開発・デリバリーリスクを、管理可能なエンジニアリングリスクへと収束させる能力であり、その結果として時間および資本の消費曲線を高い精度でコントロール可能にするものです。これこそが、AI SaMDの企業価値（バリュエーション）を持続的に支える根本的なロジックと言えます。 

 

詳細については、Joseph.Shen@behealthventures.com までお問い合わせください。