電子署名

このトピックは、 SG Systems Global 規制と運用に関する用語集。

2025年12月更新 • パート11 / 付録11 管理、承認、帰属 • QA、コンプライアンス、IT、運用

電子署名は、電子システム内で実行される法的効力を持つ承認および署名であり、署名イベントは特定の個人に一意に帰属し、特定の記録および意味（例：「レビュー済み」、「承認済み」、「実行済み」、「リリース済み」）に結び付けられます。規制対象となる製造および品質システムにおいて、電子署名は単なるチェックボックスや入力された名前ではありません。署名された記録が監査および調査において信頼性があり、弁護可能であることを保証するために、身元、意図、および記録との関連性を証明する必要のある管理されたイベントです。そのため、電子署名は、21 CFR Part 11、EU Annex 11、データインテグリティ、および誰が、何に、いつ、どのような署名をしたかを記録する帰属可能な監査証跡と密接に関連しています。

電子署名が重要なのは、電子記録をコンプライアンス基準を満たす証拠に変換するからです。署名が脆弱な場合（共有アカウント、意味の曖昧さ、署名者の不在、署名後に編集可能な記録など）、たとえ基盤となるプロセスが優れていても、システムの正当性を証明することは困難になります。強力な電子署名は、ペーパーレス運用、リリースサイクルの短縮、ワークフローの制御、バッチ実行（eBMR）、逸脱、是正措置・予防措置（CAPA）、文書管理、トレーニング、サプライヤー／品質に関する意思決定における信頼性の高い説明責任を実現します。目標はシンプルです。電子記録は、署名済みの紙の記録と同等、あるいはそれ以上の信頼性を備えている必要があります。なぜなら、証拠にはタイムスタンプが付与され、追跡可能だからです。

「電子署名は、本人であること、意図があること、そして署名された正確な記録への壊れることのないリンクを証明する場合にのみ価値があります。」

1) 電子署名が実際に証明するもの

準拠した電子署名は、次の 3 つのことを証明する必要があります。

• アイデンティティ： 署名者は一意に識別され（共有資格情報なし）、認証されます。
• 意図： 署名者は署名する意図があり、署名の意味（確認済み/承認済み/実行済み/リリース済み）を理解していました。
• レコードバインディング: 署名は署名時に特定の記録にリンクされ、分離したり誤用したりすることはできません。

これらの要素が揃っていれば、電子署名は手書き署名よりも強力になります。なぜなら、タイムスタンプが付与され、帰属が明確で、システムコンテキスト（役割、ワークフローステップ、レコードバージョン）にリンクされているからです。これらの要素が欠けていると、「電子署名」は単なるUIアーティファクトとなり、証拠価値は低くなります。

2) 電子署名と電子記録

電子記録とは、バッチ記録、逸脱、CAPA、試験結果、管理文書、研修修了など、データそのものです。電子署名は、これらの記録に適用される承認または証明のアクションです。この2つは連携して機能する必要があります。管理署名のない記録は、リリースに不完全な可能性があります。管理記録のない署名は意味がありません。

そのため、Part 11はしばしば「電子記録と電子署名」と要約されます。記録（整合性、保持、監査証跡）と署名（同一性、意図、拘束力）の両方を管理する必要があります。どちらか一方が弱ければ、コンプライアンス体制は崩壊します。

3) 規制対象業務において電子署名が存在する理由

電子署名が存在するのは、規制対象となる製造が文書化された意思決定に基づいているためです。承認は、何が許可されるかを定義します。具体的には、どのバッチステップが実行されたか、どの逸脱が許容されるか、どのCAPAが完了するか、どの仕様が有効か、どのロットがリリースされるかなどです。署名がなければ、意思決定は曖昧になります。署名があれば、意思決定は帰属可能となり、弁護が可能になります。

電子署名はペーパーレス化を実現し、業務プロセスの摩擦を軽減します。フォームを印刷・スキャンする代わりに、組織はアクションの時点で署名を取得し、記録や監査証跡に即座にリンクさせることができます。適切に実施すれば、転記ミスが減り、アクションから文書化までの時間差が短縮されるため、コンプライアンスと効率性の両方が向上します。

4) 署名の意味：「確認済み」は「承認済み」と同じではない

署名の意味は、最も見落とされがちな要件の一つです。署名には明確な意図が必要です。一般的な署名の意図には、以下のようなものがあります。

• 実行: 「私はこの手順/アクションを実行しました。」
• 検証済み： 「この結果/ステップが要件を満たしていることを確認しました。」
• 審査： 「私は記録を確認しましたが、許容範囲内であると判断しました。」
• 承認済み： 「この記録/決定の使用を承認します。」
• 発売日： 「このロット/バッチ/文書を次の状態にリリースします。」

システムは意味を明確かつ一貫したものにする必要があります。すべてが単に「署名」されているだけでは、署名者が何を証明したのかが不明瞭となり、署名は脆弱です。強力なシステムは、署名の意味をメタデータとして記録し、記録と監査証跡に明確に示します。

5) 認証制御：アイデンティティを防御可能にする

アイデンティティは基盤です。認証が脆弱であれば、どんなに強力な署名プログラムも機能しなくなります。防御可能なプログラムには、少なくとも以下の要件が必要です。

• 固有のユーザー アカウント: 共有ログインや汎用「オペレーター」アカウントはありません。
• 強力な認証: パスワード標準、適切な場合の MFA、およびリセットの制御。
• 制御されたプロビジョニング: 支配 アクセスプロビジョニング およびデプロビジョニング。
• ロールベースの権限: 承認されたロールのみが署名でき、許可されたアクションのみ（RBAC).

多くのシステムでは、バッチリリースや逸脱承認といった影響の大きい署名に対して、「署名時の再認証」（例：パスワードの再入力や本人確認）を要求しています。目的は、ログイン時だけでなく、署名時にも意図と本人確認を明確にすることです。

6) 記録のバインディングと署名後の変更管理

署名は、署名時の記録状態に紐付けられる必要があります。根本的な問題は「署名後の編集」です。承認後に記録が変更され、追跡可能性が確保されない場合、承認は無意味になります。防御可能なアプローチには、通常、以下が含まれます。

• ロッキング： 署名されると、重要なレコード フィールドはロックされるか、リビジョン管理されるようになります。
• リビジョン管理: 署名後の変更には、新しい承認（ 文書管理 (NAIST) と 変更管理).
• 監査証跡の可視性: 署名後のすべての変更は、誰が何をなぜ変更したかを含めて記録され、表示されます。
• 署名無効化ロジック: 特定の変更により、以前の署名が自動的に無効になり、再署名が必要になります。

バインディングには添付ファイルの制御も含まれます。レコードが添付ファイル（レポート、PDF、画像）を参照している場合、署名は単一のフィールドだけでなく、レコードパッケージ全体に適用する必要があります。

7) 電子署名が使用される場所（一般的な使用例）

電子署名は、意思決定の帰属と防御が求められるあらゆる場面で使用されます。一般的な使用例には以下のようなものがあります。

• バッチ実行: ステップ完了、工程内チェック、ラインクリアランス確認、最終バッチ承認など 電子骨髄バンク.
• 保持/解放: 配置と解放 検疫/ ロットおよびバッチのステータス。
• 逸脱と調査: 逸脱の承認、調査の結論、有効性の確認。
• キャパ: CAPA 承認、アクション完了のサインオフ、およびクローズ。
• 変更管理： 変更要求の承認、実装の承認、実装後のレビュー。
• 文書管理: SOP 承認、有効日承認、廃止承認。
• トレーニング： トレーニング完了の証明と能力の確認。
• サプライヤーと品質の決定: MRB 処分およびサプライヤー是正措置の承認。

いずれの場合も、署名は正しい意味を反映する必要があり、権限のないユーザーがリスクの高い決定に署名できないように、役割によって制約される必要があります。

8) 署名イベントの監査証跡の期待

署名イベントは追跡可能でなければなりません。電子署名の監査証跡は、通常、以下の情報を記録し、記録します。

• 署名者のID: ユーザー ID および、該当する場合は印刷された名前。
• タイムスタンプ： 署名の日付/時刻 (タイムゾーンの一貫性を含む)。
• 意味： レビュー/承認/実行/リリース。
• レコード参照: どのレコードとどのバージョン/リビジョンが署名されたか。
• 認証方法： 影響の大きい手順の署名時に再認証が行われたかどうか。

監査人は、署名の失敗や上書きにも注意を払います。ログイン試行の失敗、署名のキャンセル、パスワードのリセット、そして帰属を危うくする可能性のあるあらゆる管理者のアクションなどです。そのため、署名システムは制御されたアクセスプロビジョニングと連携させ、異常なパターンがないか監視する必要があります。

9) 一般的な障害モード（電子署名が弱くなる仕組み）

電子署名プログラムは、予測可能な方法で失敗する傾向があります。

• 共有アカウント: 帰属を破壊し、署名を防御不可能にします。
• 曖昧な意味: 明確な意図なく「署名」された。
• 署名後に編集可能な記録: 制御された改訂なしに変更できる場合、承認は無意味になります。
• 過度に広範な署名権： 影響の大きいステップを承認できるユーザーが多すぎると、職務の分離が弱まります。
• 弱いプロビジョニング: ロールクリープと古いアクセスにより、不正な署名機能が発生する可能性があります。
• 不十分な監査証跡レビュー: 署名イベントは存在しますが監視されず、疑わしいパターンは検出されません。

解決策はガバナンスと設計です。強力な ID 制御、明確な署名の意図、レコードのロック/改訂ルールの適用、品質システムに合わせたロールベースの権限などです。

10) 実践的な青写真：防御可能な電子署名の実装

実際の実装ブループリントは次のようになります。

• 1) 署名ポイントを定義する: 署名が必要なワークフローをリストします (バッチ ステップ、リリース、逸脱、CAPA、変更管理、ドキュメント)。
• 2) 署名の意味を定義する: レビュー/承認/実行/リリースされ、システムがそれらを記録することを確認します。
• 3) 役割を定義する: 署名権限を役割にマッピングし、職務の分離を実施します。
• 4) アイデンティティ制御を実施する: 固有のアカウント、強力な認証、制御されたプロビジョニング。
• 5) 署名をレコードにバインドする: 署名されたレコードをロックまたはリビジョン管理し、添付ファイルとコンテキストを保持します。
• 6) 監査証跡をキャプチャする: 署名イベントはログに記録され、確認可能であり、必要な期間保持されます。
• 7) 監視とレビュー: 定期的なアクセスレビューと、署名の異常に関する監査証跡の監視。

このブループリントは、電子署名を単なる「チェックボックス機能」ではなく、コンプライアンス強化の手段へと転換します。署名を自然な形で使いやすくし、誤用されにくいものにすることが目標です。

11) V5との関連性 SG Systems Global

管理された実行と承認。V5プラットフォームでは、電子署名により、MESステップの承認から検査​​対応のeBMRへの変換、WMSの保留と解除、QMSの逸脱、CAPA、MRB、変更管理の承認など、モジュール全体にわたる管理された実行がサポートされます。RBACと管理されたプロビジョニングにより、権限のある役割のみが特定の決定に署名できます。

監査可能性。署名イベントは、帰属情報、意味、タイムスタンプとともに記録され、監査証跡を強化し、パート11/附属書11に準拠した証拠を裏付けます。レコードはロックまたは改訂管理できるため、署名は正しいレコードの状態に紐づけられたままになります。

結論として、 V5は電子署名を用いて説明責任を徹底し、データの完全性を保護することで、承認を紙を使わずに、法的にも監査にも対応できる証拠へと変換します。

12) よくある質問

Q1. 電子署名は法的に有効ですか?
多くの規制対象の状況では、ID、意図、およびレコードのリンクに対する適切な制御が実装され、適用される規制と組織のポリシーに準拠している場合は、はい、可能です。

Q2. 電子署名ではパスワードの再入力が必要ですか?
多くの場合、影響の大きい署名に使用されます。一部のシステムでは、署名の意図を明確にするために、署名時に再認証が必要になります。具体的なアプローチは、リスクモデルと規制要件に適合する必要があります。

Q3. 署名されたレコードは後から変更できますか?
追跡可能性がなければ変更は不可能です。通常、署名済みの記録はロックされるか、変更があった場合は新たな改訂と再承認が必要となり、変更内容と理由を示す完全な監査証跡が残ります。

Q4. 電子署名を最も早く破るものは何ですか?
共有アカウント、あいまいな署名の意味、職務の分離のない広範な署名権限、制御された改訂なしで署名後にレコードを編集する機能。

Q5. 電子署名は最初にどこで使用すべきですか?
価値の高い管理ポイントから始めましょう。バッチステップの完了とリリース、逸脱/CAPAの承認、変更管理の承認、管理文書の承認などです。これらは、監査や調査で最も頼りにされる署名です。

Q6. 署名の監査証跡には何を記録する必要がありますか?
誰が、いつ、どの記録／バージョンに署名したか、署名の意味、そして（該当する場合）どのように認証が行われたか。これらの記録は保存され、検索可能である必要があります。

関連レディング
• コア要件: 21 CFRパート11 | 附属11 | データの整合性 | 監査証跡
• アクセス制御: 役割ベースのアクセス | アクセスプロビジョニング | ユーザーアクセス管理
• ワークフローコンテキスト: 電子骨髄バンク | MES | V5 QMS | 変更管理