mcpField
W
write-standard-operating-procedure

write-standard-operating-procedure

github.com/pjt222ドキュメント4239 回インストール今日更新
リポジトリ

write-standard-operating-procedure について

write-standard-operating-procedureは、規制対象業務向けにGxP準拠の標準作業手順書(SOP)を作成するスキルです。文書管理、責任分担、具体的な手順、レビューと承認を含む監査可能な構成を整えます。

主な機能

  1. 01文書管理情報を設定
  2. 02目的・適用範囲・用語を定義
  3. 03役割と責任を割り当て
  4. 04段階的な手順を記述
  5. 05参照資料と改訂履歴を追加
  6. 06レビューと承認に回付

活用シーン

  1. 01バリデーション済みシステムのSOPを作成
  2. 02非公式な手順を正式文書化
  3. 03手順に関する監査指摘に対応
  4. 04変更管理に伴いSOPを更新

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/pjt222/agent-almanac --skill write-standard-operating-procedure

インストール後、Claude Code で/write-standard-operating-procedureを入力して読み込まれたか確認します。

詳細

標準作業手順書の作成

規制対象の活動について、明確で監査可能な手順を示す、GxP 準拠の標準作業手順書を作成します。

使用するタイミング

  • 新しいバリデーション済みシステムに運用手順が必要な場合
  • 既存の手順を正式な SOP 形式にする必要がある場合
  • 監査指摘で、手順の欠如または不備が指摘された場合
  • 変更管理によって SOP の更新が必要になった場合
  • 定期レビューで手順の内容が古くなっていることが判明した場合

入力

  • 必須:SOP の対象となるプロセスまたはシステム
  • 必須:規制上のコンテキスト(GMP、GLP、GCP、21 CFR Part 11、EU Annex 11)
  • 必須:対象読者(この SOP に従う役割)
  • 任意:既存の非公式な手順、作業指示書、またはトレーニング資料
  • 任意:この手順に関連する SOP
  • 任意:SOP の作成につながった監査指摘または規制当局の所見

手順

ステップ 1:文書管理メタデータを割り当てる
# Standard Operating Procedure
## Document ID: SOP-[DEPT]-[NNN]
## Title: [Descriptive Title of the Procedure]

| Field | Value |
|-------|-------|
| Document ID | SOP-[DEPT]-[NNN] |
| Version | 1.0 |
| Effective Date | [YYYY-MM-DD] |
| Review Date | [YYYY-MM-DD + review period] |
| Department | [Department name] |
| Author | [Name, Title] |
| Reviewer | [Name, Title] |
| Approver | [Name, Title] |
| Classification | [GxP-Critical / GxP-Supporting] |
| Supersedes | [Previous SOP ID or "N/A — New"] |

期待される結果: すべての SOP に、組織の文書番号付与規則に従った一意の ID が付与されていること。 失敗した場合: 番号付与規則が存在しない場合は、作業を進める前に規則を定めます:[TYPE]-[DEPT]-[3-digit sequential]。

ステップ 2:目的と適用範囲を記述する
### 1. Purpose
This SOP defines the procedure for [specific activity] to ensure [regulatory objective].

### 2. Scope
**In scope:**
- [System, process, or activity covered]
- [Applicable departments or roles]
- [Specific regulatory requirements addressed]

**Out of scope:**
- [Related activities covered by other SOPs — reference them]
- [Systems or departments not covered]

期待される結果: 目的が 1~2 文で記述されていること。適用範囲の境界が明確に定義されていること。 失敗した場合: 適用範囲が既存の SOP と重複する場合は、重複する部分について既存の SOP を参照するか、重複を解消するために両方の SOP を改訂します。

ステップ 3:用語と略語を定義する
### 3. Definitions and Abbreviations

| Term | Definition |
|------|-----------|
| ALCOA+ | Attributable, Legible, Contemporaneous, Original, Accurate + Complete, Consistent, Enduring, Available |
| CCB | Change Control Board |
| GxP | Good [Manufacturing/Laboratory/Clinical] Practice — umbrella for all regulated quality standards |
| SOP | Standard Operating Procedure |
| [Add terms specific to this SOP] | [Definition] |

期待される結果: SOP で使用するすべての略語と専門用語が定義されていること。 失敗した場合: 用語が曖昧である場合や、特定の分野に固有の場合は、正式な定義を確認するために、組織の用語集または関連する規制ガイダンスを参照します。

ステップ 4:責任を割り当てる
### 4. Responsibilities

| Role | Responsibilities |
|------|-----------------|
| System Owner | Ensure SOP compliance, approve changes, conduct periodic review |
| System Administrator | Execute daily operations per this SOP, report deviations |
| Quality Assurance | Review SOP for regulatory compliance, approve new versions |
| End Users | Follow procedures as written, report issues to system administrator |
| Training Coordinator | Ensure all affected personnel are trained before SOP effective date |

期待される結果: 手順セクションのすべての作業が、責任を負う役割に紐付けられていること。 失敗した場合: 手順のステップに役割が割り当てられていない場合は、責任の所在が不明です。SOP の承認前に担当者を割り当てます。

ステップ 5:手順セクションを記述する

ここが SOP の中核です。手順をステップごとに記述します。

### 5. Procedure

#### 5.1 [First Major Activity]
1. [Action verb] [specific instruction]. Reference: [form, system screen, tool].
2. [Action verb] [specific instruction].
   - If [condition], then [action].
   - If [alternative condition], then [alternative action].
3. [Action verb] [specific instruction].
4. Record the result in [form/system/log].

#### 5.2 [Second Major Activity]
1. [Action verb] [specific instruction].
2. Verify [specific criterion].
3. If verification fails, initiate [deviation procedure — reference SOP-XXX].

#### 5.3 Deviation Handling
1. If any step cannot be performed as written, STOP and document the deviation.
2. Notify [role] within [timeframe].
3. Complete Deviation Form [form reference].
4. Do not proceed until [role] provides disposition.

GxP SOP の作成ルール:

  • 各ステップを動作を表す動詞(確認する、記録する、入力する、承認する、通知する)で始めます
  • 訓練を受けた作業者が解釈に頼らずに実行できるだけの具体性を持たせます
  • 各分岐の明確な基準を含めて、判断ポイントを示します
  • 正確なフォーム名、システム画面、またはツール識別子を参照します
  • 承認または検証が完了するまで作業を停止する保留ポイントを含めます

期待される結果: 対象のプロセスに詳しくない訓練済みの担当者が、これらのステップに従って正しく作業できること。 失敗した場合: 対象分野の専門家が手順は曖昧だと指摘した場合は、詳細を追加するか、ステップをサブステップに分割します。SOP の曖昧さは、監査で繰り返し指摘される事項です。

ステップ 6:参考資料、添付資料、改訂履歴を追加する
### 6. References
| Document ID | Title |
|-------------|-------|
| SOP-QA-001 | Document Control |
| SOP-IT-015 | User Access Management |
| [Regulation reference] | [e.g., 21 CFR Part 11] |

### 7. Attachments
| Attachment | Description |
|-----------|-------------|
| Form-001 | [Form name and purpose] |
| Template-001 | [Template name and purpose] |

### 8. Revision History
| Version | Date | Author | Change Description |
|---------|------|--------|--------------------|
| 1.0 | [Date] | [Name] | Initial release |

期待される結果: 参照するすべての文書にユーザーがアクセスでき、改訂履歴がバージョン 1.0 から始まっていること。 失敗した場合: 参照する文書がまだ存在しない場合は、作成するか、参照を削除して、SOP のレビューで不足事項を記録します。

ステップ 7:レビューと承認に回付する
### Approval Signatures

| Role | Name | Signature | Date |
|------|------|-----------|------|
| Author | [Name] | | |
| Technical Reviewer | [Name] | | |
| QA Reviewer | [Name] | | |
| Approver (Department Head) | [Name] | | |

### Training Requirement
All personnel listed in Section 4 must complete training on this SOP before the effective date. Training must be documented in the training management system.

### Periodic Review
This SOP must be reviewed at least every [2 years / annually] or when triggered by:
- Change control affecting the covered process or system
- Audit finding related to the covered process
- Regulatory guidance update affecting the covered requirements

期待される結果: SOP が対象分野の専門家によるレビューを受け、品質部門の承認を得てから発効すること。 失敗した場合: 承認ワークフローが遅れている場合は、発効日を延期します。必要な承認が完了していない SOP は発効できません。

検証

  • 文書 ID が組織の採番規則に従っている
  • 目的が具体的かつ簡潔である(1~2 文)
  • 適用範囲と適用対象外の境界が明確に定義されている
  • すべての略語と専門用語が定義されている
  • 「責任」セクションの各役割が手順のステップに対応している
  • 手順の各ステップが動詞で始まり、解釈の余地なく実行できるほど具体的である
  • 判断が必要な箇所に、それぞれの分岐に対する明確な基準がある
  • 逸脱への対応が定義されている
  • 参照先の文書がすべて存在し、アクセスできる
  • 改訂履歴がバージョン 1.0 から漏れなく記録されている
  • 承認署名に作成者、レビュー担当者、承認者が含まれている
  • 定期レビューのスケジュールが定義されている

よくある落とし穴

  • 曖昧すぎる:「データ品質を確保する」は手順のステップではありません。「フォーム 001 の 15 個のフィールドがすべて入力され、付録 A に従った範囲内にあることを確認する」のように記述します。
  • 細かすぎる:想定されるあらゆるエラーのトラブルシューティングを含めると、SOP が読みにくくなります。複雑なトラブルシューティングについては、別の作業手順書を参照してください。
  • 逸脱への対応がない:手順書どおりに作業できない場合の対応を、すべての SOP で定義する必要があります。逸脱について何も記載しないと、逸脱が起こり得ないことを示唆してしまいます。
  • トレーニング前に発効する:すべてのユーザーがトレーニングを受ける前に発効する SOP は、直ちにコンプライアンス上の不備を生みます。
  • 参照されない SOP:一度もレビューされない SOP は古くなり、信頼性を失います。レビュー日を設定し、文書管理システムで記録してください。

関連スキル

  • design-compliance-architecture — SOP が必要なシステムとプロセスを特定します
  • manage-change-control — プロセスの変更時に SOP の更新を促します
  • design-training-program — 新規および更新された SOP について、ユーザーがトレーニングを受けられるようにします
  • conduct-gxp-audit — 監査で SOP の適切性と遵守状況を評価します
  • write-validation-documentation — SOP とバリデーション文書で承認ワークフローを共有します

コメント