医療AIの更新は、モデルの重みがまったく変わらなくてもワークフローを変えることがあります。画像デコーダー、較正ルール、キューを処理するサービス、ラベルの対応付けは、モデルに届くものや、その出力を受けて人が行うことを変え得ます。
したがってリリース時の問いは、新しいファイルがテストに合格するかだけではありません。提案された変更の後でも、稼働中のシステムを支えている根拠が引き続き適用できるか、という問いです。
本ガイドでは、その判断のためのエンジニアリング上の枠組みを提案します。変わる挙動を特定し、影響を受ける依存関係を追跡し、明確な基準版と候補版を比較し、利用を拡大する前に復旧を予行します。医療機器の分類、申請義務、臨床利用の準備状況を判定するものではありません。それらには、適切な専門性を持つ担当者による製品固有のレビューが必要です。
テストを選ぶ前に変更を定義する
再学習ジョブではなく、変更記録から始めます。問題、提案する修正、影響を受ける用途、更新を受け入れる理由となる結果を記述します。残る不確実性を受け入れる権限を持つレビュー担当者を明記します。
実装上の差分と、意図する挙動の差分を分けておきます。依存ライブラリの修正は出力の維持を目的とするかもしれません。閾値の改訂は、レビュー待ちキューに入る症例を意図的に変えます。新たなスキャナーへの対応は、サービスのコードがほぼ変わらなくても入力の境界を変えます。これらは同じ検証上の問いを持つ提案ではありません。
承認済みの基準版と候補版を、前処理、モデル、後処理、運用方針、実行環境、利用側との契約を含む完全なリリースとして記録します。何が変わるかとともに、何が変わらないかも示します。構成要素の識別子が同じであることは同一性の根拠になりますが、すべての挙動が影響を受けない証明ではありません。
モデルからAPIへの引き継ぎガイドでは、その完全なシステムを識別する方法を説明しています。変更管理は、パッチごとに引き継ぎチェックリストを作り直すのではなく、そのような二つのシステムの差分から始めます。
影響が及ぶ経路を追跡する
Sculleyらは、MLの保守リスクとして、相互の絡み合い、データ依存、未申告の利用側などを挙げています。[1] そこから私たちが導く実務上の示唆は、編集した構成要素のテスト群だけでなく、その構成要素から依存する判断までの経路を調べることです。
入力デコードを変更する仮想例を考えます。入力デコードは前処理に入力を渡し、前処理はモデル入力を供給し、モデルスコアは運用方針に渡され、運用方針がレビュー待ちキューへの振り分けを決めます。そのため、下流のコードが同じでも、デコードの変更には経路全体の確認が必要になり得ます。これは依存関係の例であり、特定の医療モデルが失敗するという根拠ではありません。
影響を受ける接続ごとに、失敗の仮説と、それを検討するための根拠を記述します。画像の向きが変わる可能性はあるか。欠損フィールドに既定値が入る可能性はあるか。スコア分布の変化が、変更していない閾値と相互作用する可能性はあるか。利用側が同じカテゴリを別の意味で解釈する可能性はあるか。
影響範囲は、何を確認する必要があるかについて理由を伴う主張です。変更したファイルの数ではありません。依存関係が不明なら範囲を広げ、関連する前提が明らかに変わっていない場合は、なぜ確認結果を再利用できるかを記録します。
影響を検証の問いに変える
有用な変更記録は、考えられる各失敗を、テスト、データセットまたは固定テストデータ、受入基準、責任を持つレビュー担当者につなぎます。候補版の結果を見る前に、その対応を記述することを勧めます。
出力の維持を目的とするデコーダーのパッチなら、対応入力のデコード内容と経路全体の出力が、根拠ある許容差の範囲内で維持されるかが問いになります。意図的な閾値変更なら、予測が同じであることは成功の証明になりません。提案した方針における振り分けの意図した変化、その誤り、レビュー負荷を調べる必要があります。
新しい入力元や対象集団に対しては、固定した結合テスト用データは代表性のある評価の代わりになりません。拡大する範囲に必要な根拠と、まだ検証していない前提を明示します。出力を受けて行動できる人や、出力が支える判断が変わるなら、通常の実装修正として扱わず、意図する用途の問題として上位の判断に回します。
あらゆる更新を受け入れ可能にする普遍的な割合を作り出してはいけません。受入基準では、該当する失敗の結果、測定とその不確実性、対象集団、次段階を承認できる人を説明します。未達の基準と不足する根拠を明示し、平均して良好なリリース要約にしてはいけません。
同じ症例でリリースを比較する
Breckらの本番準備状況の評価基準には、パイプライン全体の結合テスト、提供前のモデル確認、カナリアテスト、ロールバックが含まれます。[2] これらは一般的なMLエンジニアリングの実践であり、臨床検証の手順ではありません。以下の比較案は、そのシステムテストの視点を、範囲を限定したリリースレビューに応用したものです。
承認済みリリースと候補リリースには、同じ評価コホートを使います。各リリースが症例単位の出力を生成し、集計結果を解釈する前に同じ症例で比較します。この比較では、コホートの構成、参照ラベル、適格性ルール、評価指標の定義を固定し、避けられない差があれば特定します。
目的は、同じ症例で生じる変化と、評価集団を変えたために生じる差を区別することです。症例を対応させるだけでは、差が有益で、統計的に信頼でき、臨床的に意味があるとは言えません。変更が影響すると想定した失敗様式と関連するサブグループを、標本数、不確実性、限界とともに検討します。
候補版が対象集団を広げるなら、その新しい範囲の評価を別に明示して追加します。入れ替えたコホートの中に範囲拡大を隠し、同条件で改善したと説明してはいけません。裏付けのない入力元やサブグループには基準版の根拠を割り当てず、不足として見える状態にします。
独立した評価の境界を守る
開発へのフィードバックと、リリースの根拠を分けます。開発者は、パッチの調査に固定テストデータや開発用の検証データを使えます。修正案の選択に繰り返し使った評価セットは、その選択過程に対する独立した根拠ではなくなります。[4]
どの症例が実装判断に使われ、どれが受入基準の設定に使われ、どれが承認された評価のために確保されているかを記録します。データに適したグループ境界と時間境界を維持します。ファイル名が違うだけで、関連画像や反復観測を境界の両側に混在させてはいけません。
候補版には、互いの代替にならない複数の根拠が必要な場合があります。仕組みを確かめる単体・契約テスト、モデルと方針の組み合わせに対する代表性のある性能評価、配信と人の関わりに対するワークフロー評価です。各結果がどの問いに答えるかを示します。
許可され、適切に管理されている場合、サイレントモード評価は、通常の利用者にモデル出力を見せずに配信経路を調べられます。ただし、出力を表示することの便益を示すものでも、実運用での実験を許可するものでもありません。次段階も、それ自体のレビューと保護策の範囲内に保ちます。
実際に使えるロールバックを予行する
以前の承認済みリリースはロールバック候補であり、自動的な復旧保証ではありません。すでに存在しないインターフェース、スキーマ、認証情報、入力元に依存している可能性があります。復旧先全体を、実際に動かす環境に対して確認します。
復元前に、ロールバック先が現在も互換性を持つかを問います。互換性がある場合は、承認済みリリースを復元し、承認された手順に従って稼働中の識別情報を確認します。互換性がない場合は、影響を受ける出力を停止し、古い成果物を無理に稼働させず、定義済みの人によるレビューへの切替を使います。この分岐案は、代替経路が設計され、要員が配置され、承認されていることを前提とします。そうでなければ、復旧経路がないことが次段階への移行を妨げます。
管理された環境で切替を予行し、すでに処理中の作業を調べます。キュー内のジョブをどのリリースが担当するか、重複した処理をどう防ぐか、切替前の出力をどう帰属させるかを定義します。推論サービスだけでなく、受信側アプリケーションも検証します。
ソフトウェアを復元しても、すでに閲覧されたレポートや実行済みの行動は取り消せません。責任を持つチームが事後対応を検討できるよう、影響期間と出力の記録を、プライバシーに配慮した形で保存します。機微な内容を汎用の課題管理ツールにコピーするのではなく、インシデントの根拠を集める前に保存期間とアクセス規則を決めます。
判断を記録し変更を監視する
受入記録は、別の担当者が記憶に頼ってプロジェクトを再現しなくても、判断をたどれるものであるべきです。提案版と承認版の識別子、影響の理由、受入基準、テスト結果、未解決の限界、復旧の根拠、判断、責任者をまとめて保管します。
簡潔なリリースレビューでは、次を問えます。
- 意図する用途や入力境界の変更を含め、挙動の変化は明示されているか。
- 影響分析は編集ファイルだけでなく、依存する方針と利用側も含むか。
- 再利用する確認に理由があり、新しい確認は失敗の仮説に結び付いているか。
- 比較は同じ症例で行われ、拡大した範囲は別に評価されているか。
- 独立した評価は、開発中の繰り返しの選択から守られているか。
- ロールバック先は今も動作し、代替経路は使えるか。
- 切替後も影響を受けた出力と処理中の作業を特定できるか。
- 誰が変更を受け入れ、制限し、延期し、却下できるか。
この一覧を、重要な管理策の欠如を埋め合わせるスコアにしてはいけません。ほかの項目がそろっていても、復旧経路が未検証ならリリースを延期する必要があり得ます。
承認された展開後は、通常のサービス健全性に加え、変更固有の仮説も監視します。監視ガイドでは、兆候を担当者と対応経路につなぐ方法を扱っています。新しい根拠は、利用の制限、入力パイプラインの調査、別の管理された変更の開始を正当化する場合がありますが、自動的な再学習を意味しません。
ModAsteraが取り組むフルスタックのヘルステック、医療AI、規制対象ソフトウェアでは、このレビュー可能な判断のつながりが有用な成果物です。すべての更新を大規模にすることが目的ではありません。前提が誤っていた場合にも、根拠の範囲を適切な規模で明示し、復旧できるようにすることがエンジニアリングの狙いです。
References
[1] Sculley et al., Hidden Technical Debt in Machine Learning Systems (2015)
