- プロセスコントロール（構造設備）
- ラボ
- ITアプリケーション
- インフラストラクチャ
.png)
上記4 種類のシステムは、それぞれバリデーションの実施 方法が異なる。
しかしながら、どのカテゴリにも精通した専門家はほとんどいないのが現状である。
構造設備のバリデーション
構造設備とは、原薬工場における反応槽や発酵槽、製剤工場における造粒機、打錠機、凍結乾燥機、秤量機、高圧蒸気滅菌器、コーティング機、PTP分包機などである。
構造設備の特徴は、その品質が直感的に把握できることにある。
すなわちプロセスバリデーションを実施し、実際に生産された製品の品質を確認することによって検証ができるのである。
多くの構造設備はカテゴリ3（使用目的が限定され、そのためのプログラムがハードウェアの提供業者によって汎用機能として固定され、パラメーターを設定することによって機能が実現されるシステム）である。
また構造設備では、ハードウェアをPLC、ファームウェアなどの比較的小さなプログラムで制御していることが多い。
したがって、ほとんどの場合、供給者にIQ、OQ （IOQ）を実施させることになる。
ただし、複雑またはユーザが変更したPLC は、カテゴリ5に分類されるが、カテゴリ3 と5 の境界は曖昧である。
昨今は、SCADA やDCS のように、ITアプリケーションにより中央で集中管理されている構造設備も利用されている。
一般に構造設備では、適格性検証（Qualification：DQ、IQ、OQ、PQ）を行う。
一般に１つの構造設備は、1 つの機能しかもたない。
例えば、造粒機は造粒する機能、打錠機は打錠する機能である。
つまり1システム=1機能=1プロセスとなる。
したがって、そのような構造設備では、機能仕様書は作成しない。（というよりも作成できない。）
厚労省のコンピュータかシステム適正管理ガイドラインでも、機能仕様書に関して詳細に記載がない所以である。
筆者はこれまで多くのサプライヤと仕事をしてきたが、機能仕様書の書き方を知らない業者がほとんどであった。
一般に機能仕様書は、IT アプリケーションのような比較的複雑な機能を持つシステムに関して作成する。
QC ラボのバリデーション
読者は、パソコンを購入した場合に、バリデーションを実施するだろうか。
おそらくメーカの品質保証を信じて、バリデーションは実施していないであろう。
分析機器も同じで、ほとんどの場合、出来合いのもの（カテゴリ3）であり、CSV（IQ、OQ） などは不要である。
ただし、品質試験の記録は、出荷判定に大きな影響を持ち、電子記録・電子署名（ER/ES）に関する信頼性保証が大切である。
その場合、まだまだほとんどの分析機器には、パスワードがかからないため、QC ラボの施錠管理や入退室管理が重要である。
厚労省のコンピュータかシステム適正管理ガイドラインは、構造設備中心に記載されているため、QC ラボ（分析機器、Excel）等では以下のような対応が必要となる。
・ 定期点検、自己点検 → 「校正」で代用する
・ 分析機器ではIQ、OQ は実施しない
・ IQ：設置の確認、バージョン・製造番号等の記録
・ PQ：単純なシステムに関しては校正で代用することも可
一方で、多くの場合、MS-Excel 等のスプレットシートを使用して、試験成績書等を作成していることを見受ける。
MS-Excel は、安価で購入できるが、試験結果、試験成績書、出荷判定書等を作成するのであれば、リスクの高いデータを扱うことになり、バリデーションは重要である。
MS-Excel 等のバリデーション手順を検討しておかなければならない。
ただし、MS-Excel をワープロのように使用（タイプ入力のみで、関数を使用せず、計算を行わない場合）するのであれば、バリデーションは不要である。
IT アプリケーションのバリデーション
IT アプリケーションは、例えば、ERP、MES、LIMS、EDMSなどである。いわゆるソフトウェアである。
ITアプリケーションでは、製品を生産するのではなく、電子記録（データ）を作成し、管理する。
では、電子記録の信頼性をどうやって保証すれば良いのであろうか。
電子記録の信頼性を保証（検証）することは、構造設備の品質保証に比べて難易度がはるかに高い。
ITアプリケーションではテストを繰り返すことになる。
つまり、単体テスト、連結テスト（インテグレーションテスト）、システムテスト、ユーザ受入れテストなどである。
テストは、十分なテストデータを準備し、仮説検証型（ブラックボックステスト）により実施する。
すなわち予期される結果との比較を行うことによって実施する。
この作業は大変に時間がかかり、困難かつ不完全な活動である。
従って効率的、効果的であるよう、早期計画が必須となる。
ソフトウェアのテストは、自ずと限界がある。
かなりシンプルなプログラムを除けば、ソフトウェアは徹底的にテストされることはない。
そもそも、あらゆる入力データを用いてソフトウェアをテストすることは不可能であり、またプログラム実行時のあらゆる条件分岐をテストすることも不可能である。
あるソフトウェアを徹底的にテストする方法論は存在しない。
全機能のテストは、全プログラムがテストされたことを意味するのではない。
またエラーを発見しなかったテストを、ソフトウェアにエラーが存在しないと結論付けてもいけない。
テストは表面的なものである可能性があるからである。
どれだけテストを実施しても、バグが残ってしまうのがITアプリケーションの特徴である。
ITアプリケーション（ソフトウェア）のテストで、IQ、OQ、PQを実施している企業がいまだに見受けられるが、それらは間違いである。IQ、OQ、PQなどのQualification（適格性評価）は、構造設備（つまりGMPハード）に対して実施するのである。
インフラストラクチャのバリデーション
インフラストラクチャは、自動倉庫、製造用水給水システム、空調システム（HVACシステム）、マテハンなどが相当する。
インフラストラクチャのバリデーションも直感的に実施することができる。 つまり、比較的容易に実施できる。
このように、4つのGMPシステムの違いを理解しておかなければ、CSVの実施方法が大きく異なり、CSV SOPの内容も異なることになる。
Comment