なぜソフトウェアカテゴリー分類が必要なのか
ソフトウェアカテゴリー分類（GAMPカテゴリ分類）は、CSV／CSAの現場で最初に行う作業でありながら、その目的が正しく理解されないまま「儀式」として運用されている例が少なくない。カテゴリ分類は文書の体裁を整えるための作業ではなく、どのシステムに、どの程度の検証努力を投じるかを合理的に決めるための道具である。GAMP 5 は2022年7月に Second Edition が刊行され、FDA は2025年9月24日にコンピュータソフトウェアアシュアランス（CSA）の最終ガイダンスを連邦官報で告示した。日本ではQMS省令の経過措置が2024年3月25日に終了し、現在は全面適用の段階にある。本稿では、2026年8月時点の規制環境を前提に、カテゴリ分類の目的・各カテゴリの定義・クラウドやAI/MLへの適用・CSAとの関係を整理する。
なぜソフトウェアカテゴリー分類が必要なのか
企業が使用するソフトウェアは、表計算ソフトから製造実行システム、SaaS型の品質管理システムまで多岐にわたる。これらをすべて同一の基準で検証すれば、低リスクのシステムに過剰なコストを投じる一方、真に重要なシステムへの検証努力が薄まるという逆転が起きる。カテゴリ分類の目的は、この逆転を防ぐことにある。
- 検証の程度を決める：供給者が既に実施した作業をどこまで信頼できるかを見極め、自社で追加すべき検証の範囲を決定する。
- リスクベースの出発点とする：カテゴリはリスク評価の結論ではなく入口である。同じカテゴリ4でも、製品品質・患者安全・データインテグリティへの影響度によって検証の深さは変わる。
- 説明責任を果たす：査察・監査の場で「なぜこの程度の検証で十分と判断したのか」を論理的に説明する根拠を残す。
ここで重要なのは、カテゴリは「システム」ではなく「ソフトウェアの構成要素」に対して付与されるという点である。この原則を外すと、実際のシステム構成と分類が乖離し、分類作業そのものが形骸化する。
GAMPカテゴリの構成（GAMP 5 Second Edition）
GAMP 5（Good Automated Manufacturing Practice 5）は ISPE が刊行するガイドであり、現行版は2022年7月刊行の Second Edition である。ソフトウェアカテゴリ分類は初版から一貫して GAMP 5 の中核概念として位置づけられており、Second Edition でもその枠組みは維持されている。
現在使用されるカテゴリはカテゴリ1・3・4・5の4区分である。かつて存在した「カテゴリ2（ファームウェア）」は、ファームウェアが独立した区分として扱えるほど単純ではなくなったことを背景に、GAMP 5 の初版（2008年2月刊行）の時点で既に廃止されている。2026年現在も「カテゴリ2」を用いた手順書が散見されるが、これは改訂漏れであり、社内SOPの見直し対象である。
カテゴリ一覧と検証の程度
| カテゴリ | 区分の名称 | 代表的な例 | 検証・アシュアランスの程度 |
|---|---|---|---|
| 1 | インフラストラクチャソフトウェア | OS、データベースエンジン、ミドルウェア、ウイルス対策ソフト、仮想化基盤、ネットワーク機器のソフトウェア | 製品そのものを検証するのではなく、バージョンの記録・適格性評価（インストール／構成の確認）とインフラ管理プロセスで担保する。上位アプリケーションの検証を通じて間接的に確認される。 |
| 2 | —（廃止） | — | GAMP 5 初版の時点で廃止済み。旧版の手順書を使用している場合は改訂が必要。 |
| 3 | 構成設定を行わない製品（非構成製品） | 市販パッケージをそのまま使用する場合。PDFビューア、標準的な計測機器付属ソフト、設定変更せず使用する統計ソフト | 意図する用途に対する要求仕様と、実使用条件下での動作確認が中心。供給者の実績と製品の成熟度を踏まえ、テスト量は限定的でよい。 |
| 4 | 構成設定を行う製品（構成製品） | ERP、LIMS、MES、電子文書管理システム、SaaS型QMS。標準機能の範囲で自社向けにパラメータ設定を行うもの | 供給者評価に加え、自社が行った構成設定の妥当性と、その設定条件下でのビジネスプロセスの動作を確認する。標準機能そのものの網羅テストは通常不要。 |
| 5 | カスタムアプリケーション | 自社開発システム、ERPへのアドオン開発、業務用マクロ・スクリプト、システム間連携のカスタムインタフェース | 要求仕様から設計・実装・テストまでライフサイクル全体を管理する。設計レビュー、トレーサビリティ、単体／結合／システム／受入テストなど最も厚い検証を要する。 |
なお、カテゴリ番号は「重要度の順位」ではない。カテゴリ1のインフラであっても、そこにデータインテグリティ上の弱点（監査証跡の欠落、時刻同期の不備、特権アカウントの共有など）があれば、リスクはカテゴリ5のアプリケーション以上になり得る。
カテゴリ別の記録・文書の目安
| カテゴリ | 典型的に残すべき記録・文書 |
|---|---|
| 1 | 構成管理台帳（製品名・バージョン・パッチ適用状況）、インフラ適格性評価記録、バックアップ／復旧手順、アクセス権管理記録 |
| 3 | 要求仕様（意図する用途）、供給者情報、インストール記録、実使用条件での動作確認記録、変更管理記録 |
| 4 | 要求仕様、供給者アセスメント記録、構成設定仕様書と設定根拠、構成条件下でのテスト記録、運用手順書、変更管理記録、権限マトリクス |
| 5 | 上記に加え、機能仕様・設計仕様、トレーサビリティマトリクス、ソースコード管理記録、コードレビュー記録、各段階のテスト仕様書と結果、リリース判定記録、教育訓練記録 |
単一のカテゴリに収まらないシステムをどう扱うか
現代のシステムは、単一のカテゴリに分類できないことがむしろ通常である。ERPを例に取れば、同一システムの中に3つのカテゴリが同居する。
| 構成要素 | カテゴリ | 検証の重点 |
|---|---|---|
| 稼働基盤（OS・DB・仮想化基盤） | 1 | バージョン管理と適格性評価。インフラ管理プロセスで担保する |
| 標準の会計・在庫・標準帳票機能 | 3 | 意図する用途での動作確認。供給者テストの結果を活用する |
| 組織構造・承認ワークフロー・勘定科目体系の設定 | 4 | 設定値の妥当性と設定根拠、設定条件下でのプロセス動作 |
| 独自帳票、他システムとの自動連携、業界固有処理 | 5 | ライフサイクル全体の管理。設計レビューとテストの網羅性 |
この「機能単位の分類」により、変更が生じた際の影響範囲が明確になる。たとえばカテゴリ3として運用していた標準機能にマクロを追加すれば、その部分はカテゴリ5となり、必要な検証と文書が変わる。逆に、長年カスタム開発で維持してきた機能が供給者の標準機能に置き換われば、カテゴリは下がり、検証負荷を減らせる。カテゴリ分類は一度決めたら終わりではなく、変更管理プロセスの中で継続的に見直すものである。
カテゴリ分類を含むCSVの実務では、規制知識・IT知識・プロジェクト管理能力を横断的に求められる。必要なスキルセットについてはCSV実施に必要なスキルを参照されたい。
CSAへの移行でカテゴリ分類の位置づけはどう変わったか
FDAは、製造および品質マネジメントシステムに使用するソフトウェアに関するコンピュータソフトウェアアシュアランス（CSA）の最終ガイダンスを、2025年9月24日に連邦官報で告示した（Docket No. FDA-2022-D-0795）。ドラフトは2022年9月13日に公表されていたもので、約3年を経ての最終化である。
CSAが置き換えるもの・置き換えないもの
この点は誤解が極めて多い。実務上の影響が大きいため、正確に押さえておく必要がある。
- CSAが置き換えるのは、General Principles of Software Validation（GPSV）の第6節のみである。GPSVそのものが廃止されたわけではなく、第6節以外の記述は引き続き有効である。
- CSAは 21 CFR Part 11 を置き換えない。 電子記録・電子署名に関する要求は Part 11 として現行有効であり、CSAを採用したからといって監査証跡やアクセス管理の要求が緩和されるわけではない。Part 11 の適用範囲に関する運用は、2003年9月に告示された Scope and Application ガイダンスの考え方が引き続き参照される。
- ガイダンスは法的拘束力を持たない（nonbinding recommendations）。CSAは「こうしなければならない」という新たな規制要求ではなく、既存の規制要求を効率的に満たすための考え方を示したものである。
カテゴリ分類とクリティカルシンキングの関係
CSAの中核にあるのはクリティカルシンキング、すなわち「そのソフトウェア機能が失敗したとき、何が起こるのか」を起点に検証努力を配分する考え方である。ここでカテゴリ分類が不要になるわけではない。むしろ両者は次のように役割分担する。
| 観点 | GAMPカテゴリ分類 | CSAのクリティカルシンキング |
|---|---|---|
| 問いの内容 | そのソフトウェアはどのように作られ、誰がどこまで検証済みか | その機能が失敗したとき、製品品質や患者安全にどう影響するか |
| 判断の軸 | 供給元・構成の自由度・カスタマイズの有無（供給者側の成熟度） | 意図する用途と工程リスク（自社の使い方） |
| 導く結論 | どの範囲を自社で確認する必要があるか（検証の範囲） | スクリプト化テストか非スクリプト化テストか、記録をどこまで残すか（検証の手法と厚み） |
| 単独運用した場合の弊害 | カテゴリ番号だけで検証量が機械的に決まり、低リスク機能への過剰検証と高リスク機能への過小検証が同時に起こる | 供給者が何を検証済みかの評価が抜け、既に担保されている部分を重複して確認する |
つまり、カテゴリ分類は「供給者の作り込みをどこまで信頼できるか」を、クリティカルシンキングは「失敗したら何が起こるか」を評価する。この2軸を掛け合わせて初めて、検証努力の配分が合理的に決まる。カテゴリ4だから一律にこのテスト、といった運用は、CSAの考え方とは相容れない。
クラウド／SaaS・AI/MLをどう分類するか
従来のオンプレミス前提のカテゴリ定義では判断に迷う技術が増えている。基本原則は変わらない――提供形態ではなく、ソフトウェアがどう作られ、自社がどこまで手を加えるかで判断する。
| 提供形態・技術 | 分類の考え方 | 実務上の留意点 |
|---|---|---|
| IaaS（クラウド基盤） | 基盤部分はカテゴリ1に相当する。稼働環境として管理対象に含める | 物理的な適格性評価は事業者側にあるため、契約と供給者アセスメントで担保する。責任分界点を文書化しておく |
| SaaS（標準機能のみ利用） | 実質的にカテゴリ3に近い。設定項目が業務に影響する範囲で判断する | 自社の管理下にないバージョンアップが継続的に発生する。リリースノートの受領と影響評価を定常業務として設計する |
| SaaS（構成設定を伴う品質・文書管理システム等） | カテゴリ4。設定内容と設定根拠が検証の主対象となる | マルチテナント環境における監査証跡・データ分離・退去時のデータ返還を、契約段階で確認する |
| SaaS上のカスタム拡張・ローコード開発 | 拡張部分はカテゴリ5として扱う | 「ノーコードだから検証不要」は成立しない。作成物が業務ロジックである以上、仕様・テスト・変更管理が必要 |
| AI/ML（学習済みモデルを組み込んだ機能） | 組み込み形態に応じてカテゴリ4または5。学習データとモデルは構成要素として管理対象に含める | 入力が同じでも出力が変動し得る点が従来ソフトと決定的に異なる。受入基準・性能監視・再学習時の変更管理を設計する必要がある |
| 生成AI（外部サービスの利用） | カテゴリ分類だけでは扱いきれない。用途と出力の使われ方に基づくリスク評価が主となる | 出力を規制対象の判断や記録に用いる場合、人によるレビューと承認の記録が不可欠。出力の再現性が保証されない前提で運用設計する |
日本の規制におけるカテゴリ分類の扱い
コンピュータ化システム適正管理ガイドライン
日本では、平成22年10月21日付 薬食監麻発第1021011号「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」（平成24年4月1日適用）が、カテゴリ分類を実務上の枠組みとして取り込んでいる。
同ガイドラインは2010年の発出以降、本文の改正は行われていない。したがって、そこで参照されているカテゴリの枠組みと、現行の GAMP 5 Second Edition の考え方との間で運用上の整合をとる作業は、各社の責任で行う必要がある。手順書上は同ガイドラインの別紙2に沿った分類を維持しつつ、リスク評価と検証手法の設計にCSAの考え方を反映させる、という二層構造が現実的な落としどころとなる。
ER/ES指針との関係
電子記録・電子署名については、平成17年4月1日付 薬食発第0401022号「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」（ER/ES指針）が、廃止・改正されることなく現在も有効である。カテゴリ分類の結果がどうであれ、電磁的記録を扱うシステムであればER/ES指針の要求を満たす必要がある点は変わらない。詳細はER/ES指針の解説を参照されたい。
医療機器分野の状況
医療機器・体外診断用医薬品については、令和3年厚生労働省令第60号による改正QMS省令（令和3年3月26日公布・施行、ISO 13485:2016との整合が趣旨）の経過措置が2024年（令和6年）3月25日に終了し、現在は全面適用の段階にある。「2024年3月26日までに対応を」といった期限訴求はすでに意味を失っており、現在の論点は施行後の運用が実際に機能しているかである。
整合先である ISO 13485 の現行版は 2016年版（第3版）である。2025年10月31日の定期見直しにおいて「確認（Confirmed）」とされており、改訂作業は進行していない。したがって「ISO 13485の次期版に備える」といった前提で計画を立てる必要はない。
米国では 21 CFR Part 820 が Quality Management System Regulation（QMSR）へ全面改正され、2026年2月2日に施行された。§820.7 で ISO 13485:2016 が参照取り込み（incorporation by reference）されたことにより、設計管理の根拠条文は旧 §820.30 から ISO 13485 箇条7.3 へ移っている。プロセスバリデーションおよびソフトウェアバリデーションの要求も同規格の枠組みで読むことになるため、社内手順書における参照条文の見直しが必要である。
2026年時点での実務上の要点
カテゴリ2はGAMP 5初版の時点で廃止されている。現行の社内SOPやカテゴリ判定シートに残っていれば、直ちに改訂対象である。あわせて参照文献の記載を GAMP 5 Second Edition（2022年7月刊行）へ更新する。
システム全体に単一のカテゴリを付与する運用は、実態と乖離する。基盤・標準機能・設定・カスタム開発を分けて分類し、機能一覧とカテゴリの対応表を維持する。この表は変更管理の影響評価にそのまま使える。
カテゴリは検証範囲の出発点であり、検証の厚みはリスク評価で決める。CSAのクリティカルシンキングと組み合わせ、高リスク機能に資源を集中させる。カテゴリ番号から機械的にテスト件数を導く運用は、過剰検証と過小検証を同時に生む。
CSAが置き換えるのはGPSVの第6節のみであり、21 CFR Part 11 は置き換えない。また法的拘束力を持つ規制ではない。CSAを根拠に監査証跡やアクセス管理を省略する運用は成立しない。
SaaSは自社の管理下にないタイミングで更新される。導入時の検証だけでなく、リリースノートの受領・影響評価・必要に応じた再検証を定常プロセスとして手順に組み込む。供給者との責任分界点は契約段階で文書化する。
学習データとモデルを構成要素として管理対象に含め、受入基準・性能監視・再学習時の変更管理を設計する。生成AIの出力を規制対象の判断や記録に用いる場合は、人によるレビューと承認の記録を必ず残す。
QMS省令は経過措置終了済み（2024年3月25日）で全面適用、ISO 13485 の現行版は 2016年版、米国 Part 820 は QMSR として2026年2月2日施行済み。CSV関連の社内文書が古い前提のまま運用されていないか、この機会に確認したい。
ソフトウェアカテゴリー分類が必要なのは、文書を揃えるためではなく、限られた検証資源をリスクに見合って配分するためである。GAMP 5 Second Edition の枠組み（カテゴリ1・3・4・5）で「供給者の作り込みをどこまで信頼できるか」を判断し、CSAのクリティカルシンキングで「失敗したら何が起こるか」を評価する。この2軸を組み合わせることで、はじめて過剰管理と過小管理の両方を避けられる。クラウドやAI/MLといった新しい技術も、提供形態に惑わされず「どう作られ、自社がどこまで手を加えるか」という原則に立ち返れば分類できる。カテゴリ分類は一度きりの作業ではなく、変更管理の中で継続的に見直し続ける生きた枠組みとして運用すべきものである。
- 医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドラインについて（平成22年10月21日 薬食監麻発第1021011号、平成24年4月1日適用）／厚生労働省 https://www.mhlw.go.jp/web/t_doc?dataId=00tb6573&dataType=1&pageNo=1
- 医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について（平成17年4月1日 薬食発第0401022号、ER/ES指針）／厚生労働省
- 医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令の一部を改正する省令の施行等について（令和3年3月26日 薬生発0326第10号）／厚生労働省 https://www.mhlw.go.jp/web/t_doc?dataId=00tc5787&dataType=1&pageNo=1
- Medical Devices; Quality System Regulation Amendments（89 FR 7496、2024年2月2日公布、Docket FDA-2021-N-0507）／Federal Register https://www.federalregister.gov/documents/2024/02/02/2024-01709/medical-devices-quality-system-regulation-amendments
- 21 CFR Part 820（Quality Management System Regulation）／eCFR https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
- Computer Software Assurance（CSA）最終ガイダンス（連邦官報告示 2025年9月24日、Docket No. FDA-2022-D-0795）／U.S. Food and Drug Administration https://www.fda.gov/regulatory-information/search-fda-guidance-documents
- ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes（第3版、2025年10月31日の定期見直しで Confirmed）／ISO https://www.iso.org/standard/59752.html
- GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition（2022年7月）／ISPE ※有償刊行物
