James Whitfield

QAチームがバックログに埋もれていたため、CAPAトリアージ用のAIアシスタントをプロトタイプしました。アイデアは明白に感じられました。モデルに入ってくる不適合や苦情を読ませ、考えられる根本原因カテゴリを提案させ、技術ファイルから関連文書を提示させ、人間が編集できる修正処置のドラフトを生成させるというものです。サンドボックス環境ではスクリーニングが高速化しましたが、厄介な疑問が突きつけられました。規制当局（または社内監査人）が受け入れられるよう、これをどうバリデートすればよいのか？

21 CFR 820およびISO 13485の下で業務を行う場合、CAPAが未検証の賭けの場ではないことは既にご存知でしょう。21 CFR 820.100は文書化された手順と有効性の検証を求め、ISO 13485は管理された是正・予防プロセスを要求します。しかし、これらの規格は人間のプロセスと古典的なソフトウェアバリデーション向けに書かれています。AIは「検証」と「証拠」の形を変えます。

以下はプロトタイプ作成を通じて得た学びと、実験から管理された支援的導入に移行するために用いた実践的なバリデーションパターンです。

核心の問題：確率論的なモデルで何が「バリデート」されるのか？

従来のソフトウェアバリデーションは「入力X → 期待される決定論的出力Y」です。LLMでは出力は確率的で文脈に依存し、モデル更新によって変化する可能性があります。つまり、モデルを常に同じ修正計画を生成するブラックボックスのSOPのように扱うことはできません。しかし、モデルを「管理された支援」——人間によるレビューとトレーサビリティの対象となる提案の源泉——として扱うことは可能です。ただし、そのように扱う場合でもバリデーション成果物は必要です。

プロトタイプの内容（理論ではなく実践）

  • QMSから過去のCAPAおよび不適合報告の非識別化サンプルを取り込みました（PHIおよびサプライヤー機密情報を削除しました）。
  • 管理文書（設計履歴、リスク評価、過去のCAPA）の埋め込みインデックスを構築し、アシスタントが文脈を提示できるようにしました。
  • 「シャドウモード」パイプラインを作成しました。AIは提案を生成しましたが、それに基づくアクションは行わず、提案を記録して元の人間の結果と比較しました。
  • 整合性を測定しました。AIの根本原因カテゴリは人間のカテゴリと一致したか？上位3件の参照文書の中に人間が実際に使用した文書が含まれていたか？

その結果は予想通りでした。有益なヒット、もっともらしいが誤った根拠、そして存在しない引用を自信たっぷりに挙げる幻覚もありました。

当社にとって理にかなったバリデーションパターン

「モデルをバリデート」するつもりはありませんでした（脆すぎる）。管理された支援プロセスをバリデートし、規制当局が期待する証拠を生成したかったのです。以下の内容を定義・反復し、すべてを変更管理下に置きました。

  1. 範囲と境界の定義

    • アシスタントが扱えるCAPAの種類はどれか？（例：管理的なトリアージのみ。製造保留の判断は不可）
    • 許可されるデータ：PHIや規制対象のサプライヤーIPをパブリックLLMに送信しない。

  2. ゴールデンテストコーパスの作成

    • 人間が受け入れた根本原因、使用した参照文書、最終的な是正処置を含む非識別化済みの過去事例。
    • エッジケースや曖昧な入力を含める。

  3. 受容基準（測定可能）

    • 例となる指標：根本原因のトップ1一致率、人間が使用した正しい文書が上位5件の参照内に存在する割合、100件の提案あたりの幻覚引用発生率。
    • リスクに基づいて合格/不合格の閾値を定義する（製品の処分に影響を与える可能性があるものはより厳しく審査）。

  4. 継続的監視とドリフト検知

    • モデルバージョン、プロンプトテンプレート、埋め込みインデックスのバージョンを記録する。
    • 定期的にゴールデンコーパスおよび新規のライブ決定監査に対して再テストを実施する。
    • パフォーマンスが低下した場合は変更管理を開始し、再バリデートを行う。

  5. ヒューマンインザループの制御

    • アシスタントの出力は明確な出所（モデルバージョン、タイムスタンプ、プロンプト）とともにCAPAレコードのドラフトとして保存される。
    • 指名された人間のレビューアが、アクションを実行する前に必ず承認・編集・署名しなければならない。

  6. 文書化とトレーサビリティ

    • アシスタント利用のためのSOP、バリデーション計画、テストレポート、定期レビュー記録。
    • 提案から最終的なCAPA内容への監査可能なトレースを維持する。

エンジニア向けの実装メモ

  • プロンプト、テストスイート、評価コードをソース管理対象のアーティファクトとして扱う。プロンプトを変更したりモデルをアップグレードした際には、ゴールデンコーパスのテストを実行する小さなCIジョブを使用しました。
  • 埋め込みインデックスをスナップショットし、アシスタントが各CAPAレコードで使用したバージョンを保存する。これによりアシスタントが文書を提示した「理由」を保持できます。
  • 外部LLMへの呼び出しの前にPHIやサプライヤー秘密情報を編集またはトークン化する。機密データを送信する必要がある場合は、DPAおよびSOC2管理下のエンタープライズ／プライベートホスト型モデルを優先する。
  • すべてを追記専用監査ストアに記録する（各ドラフト提案がCAPAの履歴の一部となるよう、webhook経由でQMSにログを書き込みました）。
  • 役割を定義する：AI提案を承認できる者、閲覧のみ可能な者、モデルプロンプト／ポリシーを編集できる者。

監査人および認証機関が突っ込んでくるポイント

私の経験では、レビューアが重視するのは以下の点です。

  • アシスタントが監督なしにCAPAの結果を変更しないという証拠。
  • モデルバージョニングと意思決定経路を示す再現可能な記録。
  • データ保護管理（特に臨床的苦情の場合）。
  • アシスタントを使用できる場合とバイパスしなければならない場合に関する明確なSOP。

これらの成果物を提示できない場合、質問が出ることを想定し、ゴールデンコーパスのテスト結果と再バリデーション計画を提示する準備をしておく必要があります。

最後に

AIはトリアージ時間を大幅に短縮し、大規模な技術ファイルから関連する証拠を提示することができます。しかし、バリデーションに関する議論は一度限りのチェックボックスではなく、継続的なプログラムです。テストコーパス、監視、変更管理、そして人間による監督が必要です。最終的に、私たちは管理業務を削減する範囲でAIを受け入れ、製品の処分を直接変更する可能性がある領域では人間の署名なしに使用しないことにしました。

このコミュニティから学びたいこと：社内監査人や認証機関に対して「AI支援CAPAワークフローが十分にバリデートされている」と納得させるために使用した具体的なテストケースや指標のリストをお持ちでしょうか？もしあれば、監査で有効だったテストケースや受容基準の種類を共有していただけますか？