製薬AIで一番危ないのは何か——未承認変更と影響評価設計（ADIC実用シリーズ 製薬編⑦）

製薬AIのリスクを語るとき、モデルの精度やデータ品質が話題になることが多い。しかし実務担当者が実際に直面する最大のリスクは別のところにある。未承認変更だ。

未承認変更とは、変更管理プロセスを経ずにモデルが変更されること、あるいは変更として認識されないままモデルの動作が変化することだ。意図的なものから、無意識に行われるものまでさまざまある。しかしどちらにしても、QA内部監査や査察対応の場面では「変更管理がされていたか」という論点化につながりやすい。

これはAI固有の問題ではないが、AIが関与することで問題が見えにくくなる。人手で計算される統計解析なら、変更は文書の差し替えとして痕跡が残ることが多い。しかしAIモデルの「再学習」「パラメータ調整」「バージョン切り替え」は、技術的には記録なく行える。この点が製薬AIにおける最大の変更管理上のリスクだ。

【対象成果物】この記事が扱う記録単位

本記事で扱うのは、変更管理に関する以下の成果物セットだ。

変更要求記録：変更の種類（バグ修正・性能改善・適用範囲拡張）、変更理由、変更前後の仕様差分

影響評価記録：変更が影響した判断件数、影響した症例・バッチ・解析件数の推計

差分記録：変更前後のモデルを同一テストデータで実行した出力差分の定量評価

この3点が、CSV変更管理の文脈で「変更が適切に管理されていた」ことを照合しやすくする。

本質的な問題：変更の三分類と影響評価

CSV（コンピュータ化システムバリデーション）の変更管理の文脈でAIモデルの変更を捉えると、三種類の変更を区別する必要がある。

バグ修正は、モデルの計算に誤りがあり修正する変更だ。この変更は、修正前の判断が誤った条件で行われた可能性を示唆する。影響評価未実施のままバグ修正として処理された場合、後から「あの時期の判断はどの条件で行われたか」という論点が発生しやすい。影響を受けたロット、症例、解析件数まで追えることが重要になる。

性能改善は、精度を向上させるためのモデル更新だ。変更前後で判断結果が変わった事例がある場合、変更前の判断の正当性の説明が難しくなりうる。変更がいつ行われ、変更後のモデルが試験・解析のどの段階から使われたかの記録が必要だ。

適用範囲拡張は、新たなデータや集団に対応するためのモデル拡張だ。拡張後のモデルが既存データに対して異なる動作をする可能性があり、既存の判断との整合性確認が必要だ。この確認が記録として残っていないと、変更管理の論点化につながりやすい。

なぜ変更管理の既存手順では対応しにくいのか

GMPのチェンジコントロールフォームは「変更内容」「変更理由」「影響評価」「テスト計画」の記載欄を持つ。しかしAIモデルの場合、「変更内容」に「重みを再学習した」と記載しても、その変更が実際の出力にどう影響するかは記載欄では表現しにくい。

さらに問題なのは、再学習による実質変更だ。コードは変わらなくてもモデルの重みが変わった場合、コードの変更管理はされているが、モデルの動作変化が変更として記録されていないことがある。重みの変化が出力の変化を引き起こしているにもかかわらず、変更管理プロセスを通らないケースは、実務上発生しやすい。

また、バグ修正名目の判定変更も問題だ。「バグ修正」として変更管理された変更が、事実上、判定結果を変えていた場合、その変更が実質的な性能改善変更に当たるかどうかの区別が曖昧になる。この区別がロジカルに行われ、記録に残る設計がなければ、後から「影響評価未実施変更だった」という論点が発生しやすい。

ADICで変更管理を設計する

ADICは規制判断そのものを代替するものではない。ADICは、変更の定義・評価・承認・記録の全プロセスを、AIモデルの特性に合わせて照合しやすい形で固定する実装基盤である。

変更の定義では、モデルのハッシュ変化、重みの変化量、出力分布の変化量を自動計測し、変更の種類（バグ修正・性能改善・適用範囲拡張）と規模を分類する。この分類に基づいて、それぞれに必要な変更管理手順に誘導される。停止トリガーとして、ロック期間中変更の検出、変更管理未承認状態の検出が設定される。

変更前後の比較評価では、標準的なテストデータセットを使って更新前後のモデルを比較し、出力差分の統計量を自動算出する。症例単位差分、バッチ単位差分、エンドポイント単位差分、アラート件数差分の形で差分評価が行われる。この差分が事前定義した許容範囲内であれば変更承認の条件を満たし、範囲外であれば再バリデーション要求として変更管理委員会に提出される。

変更の有無だけでなく、変更がどの判断件数に影響したかまで追えることが重要になる。ロールバック手順と、旧版再現性の確保も変更管理設計の一部として含まれる。

製薬実務での具体的な使いどころ

変更管理でADICが機能する場面は、定期的なモデル更新が行われる長期運用と、申請後の継続使用だ。

長期試験では、試験期間が数年に及ぶ場合、AIシステムのメンテナンスが複数回行われる。メンテナンスのたびに変更管理記録が追加されることで、試験全体のモデル変更履歴が時系列で照合可能になる。内部監査では変更履歴の完全性と影響範囲特定が論点になりやすい。ADICの変更ログにより、この照合を行いやすくする。

複数施設試験では、各施設で異なるバージョンのAIが稼働していた場合、施設間のデータ比較が難しくなる。ADICは施設ごとのモデルバージョンを中央管理し、施設別設定差分を停止トリガーとして設定することで、全施設での同一バージョン使用を確認しやすくする。

AI開発ベンダーとの契約では、変更管理の要件をADICのフレームワークに基づいて仕様書に記載することで、ベンダーが行うモデル更新の変更内容・理由・影響評価を、変更要求記録として提出する仕組みを契約に組み込みやすくなる。

まとめ

AIモデルの変更は避けられない。問題は変更そのものではなく、変更の種類を正確に分類し、影響評価を記録として残し、過去の判断への遡及影響を特定できる状態を維持することだ。

バグ修正・性能改善・適用範囲拡張の三種類を区別し、それぞれに適切な変更管理手順を適用すること。更新前後の出力差分を定量評価すること。影響を受けた判断件数を記録すること——この三つがADICの変更管理設計の核心だ。

変更を記録することは、正当な変更を守ることでもある。ADICの変更管理設計は、改善を阻止するためではなく、改善を照合可能な形で行うための仕組みだ。

── GhostDrift Research より ──

GhostDrift Researchは、AIの「改善」が変更管理上の論点を生みやすいことを問題視している。変更管理の設計は、改善を阻止するためではなく、改善を安全に行うための仕組みだ。ADICはその仕組みを製薬AI固有の要件として実装している。