提出前解析にADICはどう使えるのか——申請で説明負荷を下げるための証拠設計（ADIC実用シリーズ 製薬編②）

新薬申請のデータパッケージを準備する段階になったとき、統計担当者はある種の緊張に直面する。解析計画書に書いたことと、実際に動かした解析プログラムが本当に照合可能な形で残っているかという緊張だ。

申請後に審査担当者から「解析の再実行条件を確認したい」と言われたとき、同じ入力データに同じプログラムを流せば同じ結果が出るか。プログラムのバージョンは固定されているか。ライブラリの依存関係は記録されているか。これらに対応できない場合、追加照会や再解析要求につながりやすい。

AIが解析に使われるようになった今、この問題はさらに複雑になっている。機械学習モデルを解析に組み込む場合、モデルのバージョン、学習データの仕様、ハイパーパラメータの設定まで、固定すべき要素が格段に増える。

▶ADICはこちら

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

本記事で扱うのは、提出前解析に関する以下の成果物セットだ。

SAP対応表：SAPに記載された解析項目と、実装上の対応関係を照合可能な形で記録したもの

実行ログ：解析実行時のモデル版、乱数シード、依存ライブラリのバージョン、入力データのハッシュを含む実行条件の記録

環境仕様書：再実行に必要なOS、ライブラリ版、設定ファイルを外部検証者が再現できる形で記述した文書

この3点が揃っていることで、薬事審査での追加照会や、内部統計レビューでの再確認への対応が行いやすくなる。

本質的な問題：SAPとAI実装の間に生じるギャップ

統計解析計画書（SAP）は申請前に審査機関へ提出する。その時点でSAPに記載されていない解析を後から追加すること、あるいはSAPに記載された解析方法を変更することは、原則として認められない。

SAPとAI実装の間には、照合を困難にする問題が三つある。

第一に、機械学習モデルは「同じコード、同じデータ、同じ乱数シード」でなければ、同じ結果を再現しにくい場合がある。再現性を確保するには意識的な設計が必要だ。

第二に、解析の途中でモデルの調整が行われることがある。「精度が低かったので変更した」というケースでは、その変更がSAP上の変更に当たるかどうかの判断が難しくなる。SAP上の変更として正式に処理されないと、後から追加照会の対象になりやすい。

第三に、解析チームとAI開発チームが別組織であることが多く、「どのモデルのどのバージョンが最終解析に使われたか」の追跡が、組織間連携の不足で失われることがある。

提出前解析では、解析手順そのものよりも、実行時にどの版の実装がどの条件で動いたかの記録が後から追えることが重要になる。

SAPとの一致を照合するために必要な粒度

「SAPとAI実装が一致している」という確認を、薬事審査や統計レビュー担当者が行う場面を考えると、一致の確認対象は少なくとも以下の単位になる。

解析対象集団の定義（SAP記載の集団定義と実装上のフィルタ条件が対応しているか）、主要・副次評価項目の定義（評価指標の計算式がSAP記載と一致しているか）、欠測値の処理方法（SAPに記載された補完方法が実装で適用されているか）、前処理手順（標準化・変換処理がSAP記載と対応しているか）、乱数シード固定（再現性確保のためのシードが記録されているか）、モデル版と依存関係（実行に使ったモデルのバージョンとライブラリ一覧が記録されているか）、出力テーブルの定義（SAP記載の出力形式と実際の出力形式が対応しているか）、再実行条件（同一結果を再現するために必要な条件が仕様として文書化されているか）。

これらの単位が照合可能な形で残っていることが、審査担当者からの「再確認したい」という要求への対応を行いやすくする。

なぜ既存のバリデーション手順では対応しにくいのか

製薬企業のコンピュータ化システムバリデーション（CSV）のガイドラインは、ルールベースのシステムを前提として設計されている部分が多い。機械学習モデルは、入力データの分布が変わればモデルの挙動が変わる可能性があり、事前に網羅的な動作検証が難しい。

CSVでは「このボタンを押したらこの処理が行われる」という確定的な動作を検証する。AIは「この入力に対してこの範囲の出力が返る可能性がある」という確率的な性質を持つ。この違いを考慮せずにCSV手法をそのままAIに適用すると、バリデーション済みのはずのシステムが、申請段階で証拠不足として指摘を受けやすくなる。

ICH E9(R1)が推進するestimandフレームワークでは、試験の主要な構成要素の事前定義が強調されている。AIを使った解析でこの枠組みに対応するには、解析実施前にモデルの実装条件を固定し、実施後の変更を記録管理する仕組みが必要になる。

ADICが申請証拠の構造に加える要素

ADICは規制判断そのものを代替するものではない。ADICは、解析実行条件を照合しやすい形で固定し、審査・照会に対応しやすい証跡構造を整える実装基盤である。

具体的には、解析に使われたモデルをSAP提出前の段階でロックし、そのロック状態をハッシュ値と実行ログで記録する。解析実行時には、ロックされたモデルが使われていることを自動確認し、バージョン不一致が検出された場合や承認未完了の状態では解析を停止する。この停止条件があることで、SAPと実装の乖離を自動的に検出しやすくなる。

実行ログには、モデルのバージョン、入力データのハッシュ、乱数シード、依存ライブラリ一覧、実行時パラメータが自動的に記録される。これが審査担当者や内部統計レビュー担当者への照合資料として機能しやすくなる。

外部検証に必要な条件の固定という観点では、第三者検証に必要な入力仕様、モデル版、実行環境、パラメータ条件をまとめた環境仕様書をADICが自動生成する。これにより、同一条件での再実行可能性を高めやすくなる。ただし、データアクセス可否、匿名化・秘匿化の条件、実行環境差の問題については、別途運用設計が必要になる。

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

提出前解析でADICが機能する場面を三つ示す。

主要評価項目の解析では、試験の主要評価項目に機械学習を使った複合エンドポイントが含まれる場合、そのモデルの仕様はSAPに記載される。ADICはSAP記載の集団定義・評価指標・前処理手順と実装の対応を、ロック時点で記録し、解析実行時に照合する。薬事審査担当者から「SAPと実装の対応関係を示してほしい」という照会が来た場合、SAP対応表として取り出しやすくなる。

バイオマーカーに基づく部分集団解析では、事前定義された集団定義と実装の対応が照合可能な形で記録されていないと、探索的解析との区別が難しくなる。ADICはこの一致を、ロック時点と実行時の二段階で記録する。

安全性解析における有害事象の自動分類では、どのモデルのどの版がどの基準で分類を行ったかが記録として残っていないと、安全性データの説明が難しくなる。この分類ロジックの版管理と実行記録がなければ、安全性評価の照合が難しくなる。

まとめ

提出前解析にAIを使うことは可能であり、各国の審査機関も否定していない。しかし「解析にAIを使った」というだけでは、追加照会への対応が難しくなる。

必要なのは、SAP記載内容とAI実装の照合を可能にする構造、解析実行条件の固定と記録、第三者が再実行可能性を確認しやすい環境仕様の三点だ。

ADICはこの三点を、申請の証拠設計として開発段階から組み込む枠組みだ。パイロット解析の段階からADICを念頭に置いて設計することで、「申請用に証拠を揃え直す」という後処理の負荷を下げやすくなる。

── GhostDrift Research より ──

「解析の再実行条件が追えない」「SAPとの対応が説明しにくい」——これは製薬企業の統計担当者が実際に経験する問題だ。GhostDrift Researchは、この問題を「AI固有の技術的難しさ」ではなく、設計時点で対処しやすい証跡構造の問題として捉えている。