端末チェックとは何か
21 CFR Part 11 の §11.10（クローズドシステムの管理）には、「端末チェック」（device (e.g., terminal) checks）という要求事項が置かれている。しかしこの言葉は文脈によって異なる意味で用いられており、現場において混乱を招くことも少なくない。本稿では、まず条文を原文で確認したうえで、端末チェックが実務上持つ2つの意味――すなわち「正しい端末からのデータ送信確認」と「出荷判定可能なパソコンの限定」――を整理し、それぞれがどの規制要求に接続するのかを明らかにする。
ただし、本稿で扱う「意味2（出荷判定可能なパソコンの限定）」は、§11.10(h) の文言から直接導かれるものではなく、日本のCSV／ER-ES実務のなかで定着してきた用法であると解される。こちらは規制上、主として §11.10(d)（システムアクセスの権限者への限定）および §11.10(g)（権限チェック）に接続するものと整理するのが妥当である。以下、両者を区別して論じる。
まず条文を原文で確認する
21 CFR §11.10「Controls for closed systems」の (h) 号は、次のとおりである。
（訳）(h) 適宜、データ入力または操作指示の発信源（source）が妥当であるかを判定するために、端末装置等のチェック（device (e.g., terminal) checks）を用いること。
――21 CFR §11.10(h)（eCFR 現行版）
よくある誤訳に注意
- “the validity of the source of data input or operational instruction” は、「データ入力または操作指示の発信源の妥当性」である。「データ入力や操作の指示の根拠となっている事項の有効性」といった訳が流通することがあるが、原文の source は「情報源＝どこから来たか」を指しており、「根拠」ではない。
- この誤訳を採ると、端末チェックが「入力値の妥当性チェック（レンジチェック等）」と混同されやすくなる。入力値の妥当性は §11.10(a) のバリデーションや (f) の operational system checks の領域であり、(h) の主眼は「どの装置から来たデータか」にある。
端末チェックの2つの意味
意味1：正しい端末からのデータ送信確認
1つ目の意味における端末チェックとは、承認された端末からのみデータがシステムに送信されていることを確認する仕組みを指す。これは §11.10(h) の直接的な射程である。
たとえば、製造現場の試験機器から品質管理システムへデータが自動転送される場面を考えてみよう。もし悪意ある第三者や、承認されていない端末からのデータ送信を許してしまえば、記録の真正性は根本から揺らいでしまう。端末チェックは、こうしたリスクに対する防御策として機能する。
具体的な実装方法としては、以下のようなものが挙げられる。
- IPアドレスによる認証
- MACアドレスによる端末識別
- デジタル証明書を用いた端末認証
- 専用のVLAN（仮想LAN）による通信経路の限定
これらの技術を組み合わせることで、「誰が」「どの端末から」データを送信したかを明確に記録することが可能となる。これはALCOA+原則における「Attributable（帰属性）」の確保にも直結する重要な要素である。
意味2：出荷判定可能なパソコンの限定
2つ目の意味における端末チェックとは、製品の出荷判定という重要な意思決定行為を行える端末を、特定のパソコンに限定する仕組みである。
医薬品や医療機器の出荷判定は、品質保証責任者が最終的な製品品質を確認し、市場への出荷可否を決定する重要なプロセスである。この判定行為が、どの端末からでも実施可能な状態は望ましくない。物理的なアクセス制御と論理的なアクセス制御を組み合わせることで、より強固なセキュリティが実現されるからである。
実装例としては、次のような方式が考えられる。
- 品質保証部門の特定の部屋に設置された専用端末のみで操作可能とする
- 出荷判定機能へのアクセスを、事前登録された端末からのみ許可する
- 端末の物理的な施錠と、ユーザー認証を組み合わせる
2つの意味の比較
| 観点 | 意味1：データ送信確認 | 意味2：出荷判定端末の限定 |
|---|---|---|
| 主な目的 | データの真正性確保 | 重要業務の実施権限の限定 |
| 対象となる行為 | システムへのデータ入力・転送 | 出荷可否の意思決定 |
| 主な実装層 | ネットワーク層・アプリケーション層 | 物理層・アクセス制御層 |
| 関連する原則 | データインテグリティ | 職務分掌・アクセス管理 |
| 直接の規制根拠 | §11.10(h)（device checks） | §11.10(d)・§11.10(g)（日本の実務用法と解される） |
両者は独立した概念ではなく、多層防御の考え方の下で相互補完的に機能するものである。
規制要求との関係
FDA 21 CFR Part 11
米国FDAが定める電子記録・電子署名に関する規則である 21 CFR Part 11 は、§11.10「Controls for closed systems」において、端末チェックに関連する複数の要求事項を定めている。
| 条項 | 原文の要旨 | 端末チェックとの関係 |
|---|---|---|
| §11.10(a) | 正確性、信頼性、一貫した意図された性能、および無効または改変された記録を識別する能力を確保するためのシステムのバリデーション | 端末チェック機能そのものが「意図どおり動作すること」を検証する根拠。CSVの対象となる |
| §11.10(d) | システムへのアクセスを権限のある個人に限定すること | 意味2（出荷判定端末の限定）の基礎 |
| §11.10(e) | セキュアかつコンピュータ生成のタイムスタンプ付き監査証跡。記録の変更は先行記録を不明瞭にしてはならない | 「どの端末から」の情報を含む操作履歴を残す仕組み |
| §11.10(f) | 適宜、許容された手順・事象の順序を強制するための operational system checks | 入力値・手順の妥当性を扱う。端末チェックとは別領域 |
| §11.10(g) | 権限チェック（authority checks）。権限者のみがシステム使用、電子署名、入出力装置へのアクセス、記録の変更、当該操作の実施を行えること | 役割ベースの承認制御。装置レベルのアクセス制御も明示的に含む |
| §11.10(h) | 適宜、データ入力または操作指示の発信源の妥当性を判定するための端末チェック（device (e.g., terminal) checks） | 意味1の直接的な規制根拠 |
なお、§11.30（オープンシステムの管理）は、オープンシステムについて §11.10 に定める手続・管理を適宜適用したうえで、記録の真正性・完全性・機密性を確保するために、文書の暗号化や適切なデジタル署名標準の使用といった追加の措置を求めている。インターネット等を経由する構成では、端末チェックに加えて暗号化等の措置を検討する必要がある。
厚生労働省 ER/ES指針
日本においては、厚生労働省が2005年（平成17年4月1日）に発出した「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」（薬食発第0401022号）、通称「ER/ES指針」が、電子記録・電子署名の要件を定めている。
同指針は、真正性・見読性・保存性の3要件（近年では「完全性」を加えた4要件で整理されることもある）を満たすためのコントロールを求めており、端末チェックはそのうち真正性を担保する実装手段の一つとして位置づけられる。ただし、ER/ES指針の条文に「端末チェック」という語が置かれているわけではない点には留意が必要である。
PIC/S GMP ガイド Annex 11 / EU GMP Annex 11
PIC/S（医薬品査察協定・医薬品査察共同スキーム）のGMPガイド Annex 11「Computerised Systems」（EU GMP Annex 11 と整合）も、コンピュータ化システムのアクセス管理について規定している。第12項（Security）は、権限のない者によるシステムへのアクセスを防止するための物理的および／または論理的な管理を求めており、端末チェックはこの要求を具体化する手段の一つと位置づけられる。
また、PIC/S PI 041-1（2021年7月1日発効）の9.5項「System security for computerised systems」は、ユーザーアクセス管理について「個々のログインIDとパスワードを、電子システムにアクセスし使用する必要のある全職員に対して設定・付与すべきである」「共有のログイン資格情報では、当該行為を実施した個人への追跡が不可能となる。この理由により、たとえ費用節減のためであっても共有パスワードは禁止されるべきである」と明記している。端末レベルの管理は、この利用者レベルの管理を代替するものではなく、上乗せするものである。
データインテグリティとの関係
端末チェックは、データインテグリティの基本原則であるALCOA+との関係でも重要な意味を持つ。直接関連の深い原則は次のとおりである。
| ALCOA+の原則 | 端末チェックが果たす役割 |
|---|---|
| Attributable（帰属性） | 誰が、どの端末からデータを生成・変更したかを明確にする |
| Contemporaneous（同時性） | 承認された端末からの記録であることを担保し、記録時点の正統性を保証する |
| Original（原本性） | データの発信源を明確にすることで、原本の特定を容易にする |
| Accurate（正確性） | 承認されていない端末からの改変リスクを排除する |
なお、ALCOA+には他に Legible（判読性）、Complete（完全性）、Consistent（一貫性）、Enduring（永続性）、Available（可用性）が含まれるが、これらは記録そのものの可読性や保存性に関する原則であり、端末チェックとの直接的な対応関係は限定的である。端末チェックは、上記4原則を技術的に下支えする基盤的なコントロールである。（ALCOA+の全体像についてはデータインテグリティ保証の3要素を、原本の特定については紙と電子、どちらが原本かを参照されたい。）
▲【動画】医療機器企業向けeQMSアプリケーション「AI Compliance」（株式会社イーコンプライアンス）
実務における端末チェックの実装
技術的対策
端末チェックを実装する際の技術的対策は、多層防御の考え方に基づくことが望ましい。単一の認証方式に依存するのではなく、複数の手段を組み合わせることで、セキュリティの堅牢性が向上する。たとえば、IPアドレス制限、デジタル証明書認証、ユーザー認証を組み合わせた多段階の認証体系を構築することで、一つの認証が突破されても他の層で防御できる構造となる。
運用的対策
技術的対策だけでは不十分である。運用面でのルール整備と徹底が同様に重要となる。具体的には次のような対策が考えられる。
- 端末の登録・抹消プロセスの明文化
- 定期的な登録端末の棚卸し
- 退職者・異動者に伴う権限見直しの徹底
- 端末の物理的な管理（施錠、設置場所の限定）
技術と運用の両輪が揃って初めて、端末チェックは実効性を発揮する。
バリデーションにおける留意点
コンピュータ化システムバリデーション（CSV）を実施する際には、端末チェック機能が要求仕様どおりに動作することを検証する必要がある。これは §11.10(a) が求めるバリデーションの一部である。
- IQ（据付時適格性確認）端末チェック機能に関連する設定情報（登録端末リスト、ネットワーク設定、サーバ設定等）が、要求仕様どおりに導入されていることを確認する。
- OQ（運転時適格性確認）登録されていない端末からのアクセスが確実に拒否されること、登録端末からは正常にアクセスできることなど、機能要件を網羅的に検証するテストケースを設定する。「拒否されるべきものが拒否される」という否定側のテストを忘れないことが肝要である。
- PQ（性能適格性確認）実運用に近い条件下での動作を検証する。同時アクセス数、VPN経由の接続、障害時のフェイルセーフ挙動などを含める。
これらの検証結果は、バリデーション文書として適切に記録・保管することが求められる。
導入のポイント
リスクベースアプローチの採用
すべてのシステムに対して一律に厳格な端末チェックを実装することは、運用負荷の観点から現実的ではない。§11.10(h) の条文自体が “as appropriate（適宜）” という限定を置いている点に注意されたい。システムが扱うデータの重要性、規制上の位置づけ、業務への影響度などを総合的に評価し、リスクに応じた管理レベルを設定することが重要である。
ICH Q9（品質リスクマネジメント）の考え方を応用し、リスクの大きさに応じて端末チェックの厳格さを段階的に設定する手法が有効である。GxP対象データを扱うシステムには厳格な端末チェックを、そうでないシステムには相応のレベルの管理を適用するといった区分が考えられる。PIC/S PI 041-1 の5.4項（データの重要度）・5.5項（データリスク）の考え方も参照されたい。
ユーザビリティとセキュリティのバランス
過度に厳格な端末チェックは、業務効率を低下させる原因ともなる。正当な利用者が必要な業務を円滑に遂行できることと、不正アクセスを防止することのバランスを取ることが求められる。
実務では、利用者の行動パターンを分析し、業務実態に即した設計を行うことが重要である。たとえば、出張先や在宅勤務の可能性がある業務については、VPN経由でのアクセスを許可する設計とするなど、現実的な運用を想定した仕組みづくりが求められる。運用に無理があると、利用者は必ず抜け道を作る。それが新たなDI不適合の温床となることは、データインテグリティを脅かす事象の8割とはで述べたとおりである。
継続的な見直し
脅威の態様は時代とともに変化する。当初設計した端末チェックの仕組みも、定期的に見直し、必要に応じて強化していくことが重要である。近年ではゼロトラストセキュリティの考え方が普及しつつあり、「社内ネットワーク内だから安全」という前提自体を見直す動きがある。こうした動向も踏まえ、端末チェックの仕組みを進化させていく姿勢が求められる。
関連記事
- 電子署名の3つの明示事項――§11.50 が求めるもの
- なぜ2人以上の共謀が必要とされたのか――§11.200(a)(3) の背景
- なぜ電子記録は適正にバリデートされれば紙より信頼性が高いのか
- メタデータとは何か――「どの端末から」という情報もメタデータである
- 紙と電子、どちらが原本か
- データインテグリティ保証の3要素
- データインテグリティを脅かす事象の8割とは
- なぜデータインテグリティが重要なのか
- 改ざんの真の定義／過失も故意も、改ざんと同等に重い
- 意図した変更とは
まとめ――3つのポイント
- 「端末チェック」は Part 11 の規制用語である21 CFR §11.10(h) の “device (e.g., terminal) checks” がその出典であり、目的は「データ入力または操作指示の発信源の妥当性を判定すること」にある。「入力値の妥当性チェック」と混同してはならない。
- 実務上の2つの用法を区別する「意味1：正しい端末からのデータ送信確認」は §11.10(h) の直接の射程である。一方「意味2：出荷判定可能なパソコンの限定」は、日本のCSV／ER-ES実務で定着した用法と解され、規制上は §11.10(d)・§11.10(g) に接続すると整理するのが妥当である。
- “as appropriate” ――リスクに応じた設計を条文自体が「適宜」という限定を置いている。ICH Q9 の考え方を応用し、扱うデータの重要度に応じて管理レベルを段階化すること。そして IQ／OQ／PQ を通じ、とくに「拒否されるべきアクセスが拒否される」ことを検証すること。
技術の進化とともに、端末チェックの手法も高度化していくであろう。しかし、その本質は一貫している。すなわち、「信頼できるデータを、信頼できる担当者が、信頼できる環境で扱う」という、医薬品・医療機器の品質保証の根本原則を、電子化された業務環境において具現化することである。実務者には、自社のシステムが扱うデータの重要性を正しく評価し、リスクに応じた適切な端末チェックを実装していく姿勢が求められる。用語の持つ2つの意味を正しく理解し、それぞれの文脈で適切に対応できることが、これからの品質保証担当者に求められる基本的な素養の一つといえるであろう。
参考・出典（一次情報源）
- eCFR「21 CFR §11.10 Controls for closed systems」――(a)(d)(e)(f)(g)(h) 各号
- eCFR「21 CFR Part 11 – Electronic Records; Electronic Signatures」（§11.30 オープンシステムの管理を含む）
- FDA「Part 11, Electronic Records; Electronic Signatures — Scope and Application」（2003年8月）
- FDA「Data Integrity and Compliance With Drug CGMP: Questions and Answers」（最終版、2018年12月）
- PIC/S「PI 041-1 Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments」（2021年7月1日発効、PDF）――5.4〜5.5項、9.5項
- PIC/S「PIC/S Publications」（PE 009 GMP Guide, Annex 11 Computerised Systems を含む）
- European Commission「EudraLex Volume 4, Annex 11: Computerised Systems」（現行版、PDF）／改訂案に係るパブリックコンサルテーション
- 厚生労働省「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」（平成17年4月1日 薬食発第0401022号、いわゆるER/ES指針）
- 厚生労働省「医薬品及び医薬部外品の製造管理及び品質管理の基準に関する省令の一部改正について」（令和3年4月28日 薬生監麻発0428第2号）
- PMDA「データインテグリティについての期待値」（第3回ラウンドテーブル資料、令和6年2月16日、PDF）※同資料は演者の個人的見解であり、PMDAの公式見解ではない旨が明記されている
