CSVにおける成果物の種類と管理方法

CSV（Computerized System Validation）を実施する際に作成される文書を、成果物（Deliverable）と呼ぶ。成果物は種類ごとに目的が異なり、したがって作成単位・改訂の考え方・保管の方法も異なる。この違いを整理せずに一律のルールで管理すると、システムがバリデートされている状態を説明できなくなる。本記事では、CSV 成果物の種類と、それぞれをどう版管理し、どう保管するかを整理し、2026年8月時点で取るべき対応を示す。成果物が何を保証するためのものかという考え方は CSVにおける信頼性保証とは を参照されたい。

成果物の五つの種類

CSV 成果物は大別して「計画書」「仕様書」「報告書」「スクリプト」「ログ」の五種類がある。ISPE の GAMP 5 は、コンピュータ化システムのライフサイクルにわたって作成される多数の成果物の例を示している。現行版は Second Edition（2022年7月刊）であり、初版（2008年2月刊）のみを前提とした社内手順書やスライドが残っている場合は改訂が必要である。GAMP 5 は有償の刊行物であるため、本記事では逐語引用を行わず、実務上の考え方のみを述べる。

計画書に技術的事項を書かない

計画書には、誰がいつ何をするかを明確にする。すなわち CSV 実施組織および役割と責任である。またスケジュールを明らかにする。間違ってはならないのは、計画書にテクニカルな事項を記載しないということである。技術的事項は仕様書（Specification）に記載する。

多くのプロジェクトで計画どおりに進捗しないケースがあるが、その最大の理由はもともとの計画が不適切であることが多い。スケジュールは Feasible（実行可能）かつ Reasonable（合理的）でなければならない。実現不可能な計画は、逸脱を大量に生み、報告書の説明負担を増やすだけである。

報告書は計画書の写しであってはならない

そもそも、すべてのアクティビティが計画どおりに実施できたなどということはあり得ない。報告書で大切なのは、計画書のとおりに実施できず変更した事項、および逸脱した事項を記載することにある。特に逸脱事項は品質保証上の問題を含むため、正当化できる理由（Justification）を記載しなければならない。

版管理 ―― システム単位かプロジェクト単位か

成果物の管理でもっとも誤りが多いのが、改訂の単位である。ここを取り違えると、システムの現在の姿が一瞥できなくなる。

仕様書はシステム単位で改訂する

仕様書は、システムごとに1冊ずつ作成する。たとえば2010年度に EDMS（文書管理システム）の導入プロジェクトを実施し、その後2013年に機能追加のプロジェクトを、2015年には一部機能の変更と追加を実施したとする。

多くの場合、2010年度のプロジェクトでユーザ要求仕様書を作成し、2013年度には追加分のユーザ要求仕様書を、2015年度には変更・追加分のユーザ要求仕様書を作成していないだろうか。このように差分のみをプロジェクトごとのユーザ要求仕様書として作成したのでは、当該システムに対する最新のユーザ要件が一瞥できず、したがってそのシステムがバリデートできているかどうかが不明になってしまう。

本来は、2010年度にユーザ要求仕様書の Ver1.0 を作成し、2013年度にはそれを改訂した Ver2.0 を、2015年度にはさらに Ver3.0 を作成しなければならない。機能仕様書や設計仕様書も同様である。差分の機能仕様書や設計仕様書を作成してはならない。最新のシステムの機能がどうなっているかを、一瞥して分かるようにしておかなければならないのである。

計画書・報告書はプロジェクト単位で新規作成する

一方で、計画書や報告書といったマネジメント文書は、プロジェクトごとに作成しなければならない。2010年度のバリデーション計画書・報告書は当該プロジェクトの中で完結する。2013年度のプロジェクトでは、バリデーション計画書・報告書は当該プロジェクトのみの成果物として Ver1.0 を新規に作成する。けっして過去のバリデーション計画書やバリデーション報告書を改訂してはならない。過去のプロジェクトで何をどう判断したかという記録が失われるからである。

保存 ―― 最新版だけ残してよいもの、全版残すもの

計画書、報告書、仕様書等は、最新バージョンのみを綴じておけばよい。それに対して、テストスクリプトやテストログはすべてのバージョンを保存しておかなければならない。

理由は明快である。最新のテストログのみを綴じておくと、すべてのテストが合格している状態しか残らない。しかし規制当局のレビューでは、成功したテストを調査したいのではなく、エラーになったテストを参照し、それがどのように解決されたのかという経緯を調査したいのである。失敗の記録が残っていないバリデーションは、検証をした証拠がないのと同じである。なお、これらの成果物を承認し照査する側の役割については 品質保証（QA）とは を参照されたい。

電子成果物に適用される要求

CSV 成果物を電磁的記録として作成・保存する場合、次の要求が重なって適用される。

1. QMS省令第8条（品質管理監督文書の管理）文書の承認、配付、識別、劣化・紛失の防止、廃止文書の誤用防止を求めている。変更にあたっては、原則として最初に承認した部門またはあらかじめ指定した部門による照査と承認が必要である。
2. QMS省令第9条（記録の管理）記録の識別、保管、セキュリティ確保、完全性の確保、検索、保管期間、廃棄の管理方法を手順として文書化することを求めている。第2項は「完全性の確保」を「当該記録が正確であり、記録が作成された時点から不適切な改変がない状態を保つこと」と定義している。第4項は、記録が読みやすく容易に内容を把握でき、かつ検索できることを求めている。
3. ER/ES指針および 21 CFR Part 11厚生労働省の ER/ES指針（平成17年4月1日 薬食発第0401022号）は現在も有効であり、真正性・見読性・保存性を求めている。米国では 21 CFR Part 11 が現行有効であり、その適用範囲についての Scope and Application ガイダンス（2003年9月）も有効である。
4. コンピュータ化システム適正管理ガイドライン厚生労働省「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」（平成22年10月21日 薬食監麻発第1021011号、平成24年4月1日適用）は、開発・検証・運用・廃棄の各段階で作成すべき文書を整理している。

保管期間

成果物をいつまで保存するかは、根拠となる法令によって異なる。

なお QMS省令第67条ただし書きは、製品の製造または試験検査に用いた品質管理監督文書については、記録の保管期限（第68条）の期間にわたり当該文書が利用できるように保管すれば足りる旨を定めている。長期にわたる保管では、媒体の劣化やソフトウェアの陳腐化により「保存はしているが読めない」状態に陥りやすい。移行を行う場合は、移行前後の同一性を検証し、その記録を残すことである。

CSA は成果物の量を減らす免罪符ではない

FDA の CSA 最終ガイダンス（連邦官報告示 2025年9月24日、Docket FDA-2022-D-0795。ドラフトは2022年9月13日／87 FR 56059）は、リスクに応じて保証活動と記録の厚みを調整する考え方を示している。文書作成そのものが目的化していた実務に対する見直しの契機ではある。

しかしながら、次の点を取り違えてはならない。CSA は 21 CFR Part 11 を置き換えない。CSA が supersede するのは “General Principles of Software Validation” の Section 6 のみである（原文に “supersedes Section 6” と明記されている）。またガイダンスには法的拘束力がない（”not binding”）。電子記録・電子署名に関する要求、および日本の ER/ES指針・QMS省令・GMP省令が求める記録の管理は、いずれも従来どおり適用される。

CSA の考え方を成果物管理に翻訳すると、次のようになる。高リスク機能については従来どおり事前にスクリプト化されたテストと詳細な証跡が必要であり、低リスク機能については結論を支えるのに必要十分な記録に絞ってよい。判断の根拠となったリスク評価そのものを記録として残すことが、むしろ重要になる。CSA と CSV の関係の詳細は CSVにおける信頼性保証とは を参照されたい。