抗体医薬基礎知識・品質管理

URS(要求仕様書)とは?書き方と、後工程で効いてくる要件の立て方

URSそのシステムに何をさせたいかを定義する文書。Vモデルで検証項目をひもづける起点になる。(User Requirement Specification/要求仕様書)とは、装置やシステムを導入する側が「⁠何ができる必要があるのか⁠」を文書にしたものです。設備調達の起点であり、後に続く適格性評価(DQ/IQ/OQ/PQ)がすべてここに紐づきます。

#URS#要求仕様書#適格性評価#GMP
URS(要求仕様書)とは?書き方と、後工程で効いてくる要件の立て方

見落とされやすいのは、URSがメーカーの仕様書とは別物だという点です。仕様書は供給者が「この装置はこう作られている」と示す文書、URSは使う側が「こう使いたい」と示す文書です。前者を後者の代わりにすると、検証の基準が供給者側の都合になり、自分たちの製造に必要なことを確かめられなくなります。

この記事の要点
  • URSは「使う側が何を求めるか」の文書であり、供給者の仕様書とは役割が違います。
  • 要件は検証できる形——測れる、確かめられる書き方——で書くのが原則です。
  • リスクに基づいて要件に重みを付け、GMP要件と運用上の希望を区別しておくと後工程が回ります。

URSが起点になる理由

EU GMP Annex 15適格性評価とバリデーションを扱うEU GMPの附属書。継続的工程確認に相当する概念を含む。 は、適格性評価とバリデーション試験法が目的に合う性能を持つことを立証する妥当性確認。正確さ・精度などを評価する。の枠組みの中で、ユーザー要求仕様を出発点として位置づけています。要件が先にあり、それを満たす設計かを確認し(DQ)、据付・運転・性能を段階的に確かめていく——この流れの根が URS です。

そのため、URSに書かれていないことは原則として検証されません。逆に、URSに書いてあれば「それを満たしているか」を問える立場に立てます。

導入の交渉においても同じです。装置が納入された後で「これでは使えない」と言っても、要件として提示していなければ議論は難しくなります。⁠要求を先に文書化しておくこと自体が、実務上の備えになります。

検証できる形で書く

URSの品質は、ほとんど「書き方」で決まります。原則はひとつ——⁠その要件を満たしたかどうかを、後から確かめられる形で書くことです。

書き方検証できるか
曖昧「十分な精度で温度を制御できること」できない(十分とは何か)
検証可能「設定温度に対する制御偏差を、規定した範囲内に維持できること」できる(測って判定できる)
曖昧「操作しやすいこと」できない
検証可能無菌操作外部から微生物を入れずに工程を進める操作。最終滅菌できない細胞治療では全工程で無菌性を維持する。を行う姿勢のまま、操作部に手が届くこと」できる(実地で確認できる)

数値を入れられる要件は数値で書きます。ただし、⁠根拠のない数値を置かないことも同じくらい重要です。「なんとなく厳しめに」書いた要件は、達成できないときに緩和の手続きが必要になり、あるいは不要に高価な仕様を招きます。製品の品質要件や工程の設計から遡って、その数値の理由を説明できる状態にしておきます。

POINT

URSの一行ごとに「これはどうやって確かめるか」を自問すると、書きすぎと書き足りなさの両方が見えてきます。確かめる方法が思いつかない要件は、たいてい表現の問題です。

GMP要件と運用要件を分けておく

URSに書かれる要件は、性質の違うものが混ざります。

  • GMP医薬品を一定の品質で安全に造るために守るべき製造・品質管理の基準(適正製造規範)です。詳しく →要件⁠:製品品質・患者安全に直結する。逸脱承認された手順や規格から外れた事象。GMPでは発見したら記録し、製品品質への影響を評価してロットの可否を判断します。詳しく →すれば製品に影響する
  • 規制・法令要件⁠:データインテグリティ記録が正確で完全・改ざんされていないことを保証する考え方で、ALCOA+などの原則で健全性を管理します。詳しく →、電子記録、安全法規など
  • 運用要件⁠:作業のしやすさ、段取り時間、保守のしやすさ
  • 希望⁠:あれば嬉しいが、なくても製造は成立する

これらを区別せずに並べると、後の検証で優先順位が付かなくなります。⁠どの要件がGMPに関わるかを明示しておけば、リスクマネジメント(ICH Q9)の考え方に沿って検証の深さを配分できます。品質に直結する要件は厳密に、そうでない要件は簡便に——この配分が適格性評価製造装置やユーティリティが意図どおりに据え付けられ、動き、性能を出せることを文書で裏づける活動。の作業量を現実的な範囲に収めます。

コンピュータ化システムを含む場合は、GAMP の考え方に沿ってCSV/コンピュータ化システムバリデーションの範囲も併せて整理しておきます。ソフトウェアの要件は、装置の機械的な要件とは別立てで書いたほうが追跡しやすくなります。

何を書き落としやすいか

実務でURSに漏れやすいのは、装置の主機能ではなく周辺の条件です。

  • ユーティリティ水・空調・ガスなど、製造を直接支える設備の総称。適格性評価や汚染管理の対象になる。⁠:必要な電源・圧縮空気・注射用水の質と量、排気の条件
  • 設置環境⁠:設置面積、搬入経路、天井高さ、清浄度区分との整合
  • 洗浄と保守⁠:分解の可否、洗浄バリデーションで必要となるサンプリング箇所へのアクセス
  • 材質⁠:製品接触部の材質と、抽出物・浸出物の情報が供給者から得られるか
  • データ⁠:記録の出力形式、監査証跡いつ誰が何をしたかを記録し、改ざんや削除ができないようにした操作履歴。記録の信頼性を支える。、外部システムとの接続
  • 能力の幅⁠:将来の増産や品目追加を想定した範囲

とくに洗浄と保守は、稼働してから効いてきます。分解できない構造、届かない場所——導入後に判明すると、運用の負担として恒久的に残ります。

URSから先はどうつながるか

URSを確定させると、以降の工程はこれを参照する形で進みます。

  1. DQ(設計時適格性評価)装置が届く前に、設計や仕様がURSの要求を満たすかを紙の上で確認する適格性評価の段階。:提示された設計がURSの要件を満たすかを、図面や仕様の段階で確認する
  2. IQ(据付時適格性評価)装置が仕様や図面どおりに正しく設置され、必要文書や校正がそろっているかを確認する段階。:設計どおりに据え付けられたかを確認する
  3. OQ(運転時適格性評価)装置が設計で意図した範囲で正しく動くか、制御やアラームなどを製品を使わず確認する段階。:規定した範囲で意図どおり動くかを確認する
  4. PQ(性能適格性評価実運用条件で意図した用途・狙いの性能を満たすかを確認する検証。ユーザ要求仕様に対応する。:実際の条件で、要求した性能が安定して出るかを確認する

この対応関係を表にしたものがトレーサビリティマトリクスURSの各要件がどの試験で確認されるかを対応づけ、検証の抜け漏れを防ぐ一覧表。です。URSの各要件が、どの段階のどの試験で確認されるかを一対一で追えるようにしておくと、査察や監査での説明が容易になります。要件が変わったときも、影響範囲をこの表から追えます。

その先にはプロセスバリデーションがあり、装置が満たすべき条件は工程の設計と噛み合っている必要があります。URSは装置単体の文書に見えますが、実質的には工程設計の一部として書かれるべきものです。

まとめ

URSは、装置やシステムを使う側が「何ができる必要があるのか」を示す文書であり、供給者の仕様書とは役割が異なります。適格性評価はURSに紐づいて設計されるため、ここに書かれていない要件は原則として検証されません。

書き方の原則は、⁠満たしたかどうかを後から確かめられる形にすることです。数値を入れられるものは入れ、ただし根拠のない数値は置かない。GMP要件・規制要件・運用要件・希望を区別しておけば、リスクに応じて検証の深さを配分できます。

漏れやすいのは主機能ではなく周辺条件——ユーティリティ、設置環境、洗浄と保守のしやすさ、データの取り扱い、能力の幅です。とくに洗浄と保守は導入後に恒久的な負担として残るため、要件段階で押さえる価値があります。

URSの各要件をDQ/IQ/OQ/PQのどの試験で確認するかを一対一で対応づけておくと、変更時の影響範囲も、監査での説明も追いやすくなります。

参考文献

Newsletter

この分野の新着を、メールで受け取る

こうした製造・分析・品質の解説記事と、装置・試薬の新製品ニュースを月数回お届けします。登録は無料で、いつでも解除できます。

登録によりプライバシーポリシーに同意したものとみなします。

次に読む

目次・関連閉じる
編集メモ:この記事はProglenth編集部が、抗体医薬に関する基礎的な情報を、はじめての方にも分かるように整理したものです。実際の製造方法・管理戦略・品質基準は、製品や企業、各国の規制によって異なります。本記事は一般的な解説であり、特定製品の推奨や規制・医療上の助言ではありません。実務で判断される際は、各極の薬局方・ガイドライン(ICH/GMP等)やメーカーの一次情報を必ずご確認ください。内容に誤りやご指摘があればお問い合わせからお知らせください。