「CSV対応してますか？」と製薬メーカーから最初に聞かれたとき、正直「CSVってスプレッドシートのことじゃないの？」と思った。
もちろん違う。
CSV（Computer System Validation）は、医療・製薬分野で使用するコンピュータシステムが「意図した目的に対して一貫して適切に機能すること」を文書で証明するプロセスだ。
言葉を知ってから理解するまでに、もう少し時間がかかった。
CSVとは何か
要するに「このシステムは設計通りに動いている、それを証明する書類がある」という状態を作ることだ。
根拠となる規制はFDA 21 CFR Part 11やEU GMP Annex 11、日本ではPMDAのガイドラインが代表的で、GxP（GMP・GCP・GLP）に準拠した環境での使用が求められるシステムに適用される。
治験データを扱うシステムを運用している以上、避けて通れない。
なぜエンジニアがCSVを知る必要があるか
「QAや規制担当の仕事では？」と思うかもしれない。でも実際には、仕様書の記述方法・ログの設計・変更管理の仕組みはエンジニアが作る。CSVの要件を知らずに設計すると、後から大幅な作り直しが発生する。
自分もそれを経験した。設計段階から考慮していれば、もっと早く対応できた部分があった。
バリデーション文書をどう作ったか
バリデーション文書を初めて整備したとき、ゼロから作ったわけではない。
本部長の知人から、既存のテンプレートを譲り受けた。それをうちの会社の実態に合わせて照らし合わせながら書き直した。「何が必要か」のフォーマットは借りて、中身を自分たちの運用に合わせた。
小さいチームでの規制対応は、こういう現実的なやり方で進めることが多い。誰かが作ったものを自分たちの文脈に合わせる。重要なのはフォーマットではなく、自分たちの実態が文書に反映されていることだ。
VP・TS・IQ/OQ/PQの実例
CSVの代表的なドキュメント構成：
バリデーション計画書（VP: Validation Plan）
「何を、どのようにバリデーションするか」の全体方針。対象システムの概要、リスク分類（GAMP5のカテゴリ）、実施スケジュール、関係者の役割などを含む。
テスト仕様書（TS: Test Specification）
各機能に対して「何を入力したら、何が出力されるべきか」を網羅的に定義する。UIのバリデーション、データ保存、権限制御、監査証跡の動作などをテストケースとして記述する。
IQ / OQ / PQ
- IQ（Installation Qualification）: システムが正しくインストール・設定されているか確認
- OQ（Operational Qualification）: 仕様通りに動作するか確認（機能テスト）
- PQ（Performance Qualification）: 実際の業務環境で意図した通りに機能するか確認
自社では、OQをCI-CDパイプラインの自動テストと対応づけ、テスト実行ログをバリデーション証跡として保管している。
開発フローへの組み込み方
リリース前チェックリストにCSV観点を入れるだけで変わる。
- 変更管理：変更の影響範囲をドキュメント化したか
- テスト証跡：テスト実行ログに日時・担当者・結果が残っているか
- 監査証跡：データの作成・変更・削除がログに記録されるか
- バックアップ・リストア確認：本番データのバックアップと復元テストを実施したか
ドキュメント整備で気をつけること
CSV文書は「何をしたか」だけでなく「なぜその判断をしたか」まで書くことが重要だ。監査では「この設計の根拠は？」と聞かれる。理由が追跡できない文書は、あっても意味がない。
また、作った後の維持が難しい。システムを変更したら文書も更新する運用フローを、SOPに明示的に組み込んでおく必要がある。実態と文書が乖離した瞬間に、文書は形骸化する。
設計上の注意点
- 監査証跡の設計は最初から: 後から追加しようとすると、スキーマ変更やパフォーマンス問題が出る
- 権限管理を細かく: 誰が何をできるか、ロールベースのアクセス制御を最初から設計する
- 変更管理フローをコードで強制: PRベースのレビューフローと変更管理ドキュメントを紐付ける仕組みを作ると追跡しやすい
「余計な手続き」ではない
CSVを「余計な手続き」と感じる時期があった。
でも今は「信頼できるシステムを作るための設計思想」だと理解している。証明できる状態を維持することは、インシデント対応でも引き継ぎでも機能する。規制のためだけじゃない。
最初はスプレッドシートのCSVと混同していたところから始まって、今はそこまで来た。
関連記事: