GAMP5を考慮した医薬品製造に関わるコンピュータシステムの回顧的バリデーション手法の提案

全文

(1)Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. 1. はじめに. GAMP 5 を考慮した医薬品製造に関わるコンピュータシステムの回顧的バリデーション手法の提案. 本論文では，稼動中の医薬品製造に関わるソフトウェアが，医薬品を製造するために適切な機能と性能を有していることを，文書や電子データによる証拠を用いて立証する回顧的コンピュータ化システムバリデーションの実施方法について提案する．医薬品製造会社が製造した医薬品の品質が適切でなかったために，様々なトラブルが発生している．そのため，米国食品医薬品局，英国医薬品庁，日本国厚生労働省等の医薬品製造の監督機関は，医薬品製造会社に対して，「医薬品製造に関わるソフトウェア（Drag Manufacturing Software: DMSW）の機能と性能が適切であることを，設計や検証に関する文書や電子データによる証拠を用いて立証し，監督機関の認証を受けること」を義務付けた．これをコンピュータ化システムバリデーション（Computerized System Validation: CSV）と呼ぶ．CSV の実施方法については，国際医薬品エンジニアリング協会（International Society for Pharmaceutical Engineering: ISPE）の提唱する Good Automated Manufacturing Practice (GAMP5)1)が事実上の標準となっている．しかし，DMSW の中には諸事情により RCSV が未実施のままとなっているものも多く存在する．そのような DMSW を使用可能とするため，回顧的 CSV（Retrospective CSV: RCSV）が提案された．RCSV では，DMSW に関わる既存文書の収集と最低限の開発文書の作成，および運用記録の収集により，DMSW の機能と性能の適切さを立証する．しかし，実際に RCSV を実施すると，初めて RCSV を実施する場合（Initial RCSV: IRCSV）と RCSV 実施済みの DMSW を改造する場合（Maintenance RCSV:MRCSV）との間で，開発文書の十分生，整合性，網羅性に関する問題が発生した．本論文では，IRCSV と MRCSV の両方を考慮した RCSV の実施手順を提案し，DMSW のライフサイクル全体を考慮した一貫性のある RCSV を実施できるようにする．. 高橋正和† 本論文では， GAMP 5 を考慮した医薬品製造に関わるソフトウェア（DMSW）の回顧的コンピュータ化システムバリデーションを提案する． DMSW は医薬品の品質に多大な影響を与えるので，その機能と性能の妥当性を立証することが義務付けられている．特に，既に使用されている DMSW の妥当性を，既存の開発文書と運用記録を用いて，立証することを RCSV（Retrospective Computerized System Validation）と呼ぶ．GAMP5 には RCSV の実施方法の記述はないため，RCSV の実施が困難となっている．本論文では，GAMP5 に基づいた RCSV 手法を提案する．. A Proposal for Retrospective Computerized System Validation of GMP Related Computerized System Considering GAMP 5. 2. 回顧的コンピュータ化システムバリデーションの現状と問題点. Masakazu Takahashi†. 本章では，RCSV 対象 DMSW の特徴，実施方法，問題点を述べる． 2.1 回顧的コンピュータ化システムバリデーション対象ソフトウェアの特徴 Table １に，RCSV の対象となる DMSW の調査結果を示す．これらの用途は，データ管理，報告書作成，科学技術計算，設備制御，生産管理等であった．プログラミング言語は，BASIC や C 等の手続き型言語が使用されていた．DMSW の構造は，単純であった．アルゴリズムも，単純であった．そして，規模は構成するモジュールの単位では高々1000[LOC]程度であった．さらに，これらの DMSW は，GAMP5 では，医薬品の品質に与えるリスクが高いカテゴリ 5 のカスタム・アプリケーションに分類される．そのため，網羅的な CSV の実施が必要となる．. This paper proposes a GAMP 5(Good Automated Manufacturing Practice) based Retrospective Computerized System Validation (RCSV) method for Drug Manufacturing SoftWare (DMSW) that relates to drug production. Because DMSW affects big impact to quality of drugs, DMSW is required to prove adequacy of functions and performance. Especially, the work that explains adequacy for working DMSW based on existing documents and operational records is called RCSV. Because there is no description about RCSV procedure, this makes conducting RCSV difficult. In this paper, we proposed a RCSV method based on GAMP 5.. †. 1. 山梨大学大学院医学工学総合研究部 University of Yamanashi Graduate School of Medical and Engineering. ⓒ2009 Information Processing Society of Japan.

(2) Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. Development Language. Structure Algorithm Size[LOC]. Table 1 Variety of Target DMSW for RCSV Data Reporting Technical Facility Management Computing Control BASIC, BASIC, C BACIC, C, BASIC, C EXCEL FORTRAN, MACRO EXCEL MACRO Simple Simple Simple Simple Simple Simple Simple Sort of Complex 500-700 200-300 200-500 700-5000. Production Control COBOL. Simple Simple 5000-1000. 2.2 回顧的コンピュータ化システムバリデーションの流れ. Fig 1 RCSV Procedure 九番目に，上記の RCSV 活動項目の実施結果を示し，全ての結果が良好，または問題解決済みであることを確認し，RCSV 結果報告書としてまとめる．最後に，標準作業手順書に従って，DMSW を運用していく．しかし，Fig.1 では MRCSV については考慮されていない．. Fig.1 に一般的な RCSV 実施手順を示す2)．はじめに，RCSV の対象となる稼動中の DMSW を調査してシステム目録を作成する．二番目に，DMSW の GAMP カテゴリ分類を行う．三番目にギャップ分析，リスク評価，開発業者監査を並行して実施する．ギャップ分析では，存在する開発文書を調査して，不足しているものを明らかにする．リスク評価では，DMSW が医薬品製造に与えるリスクを評価して，RCSV の実施レベルを判断する．開発業者監査では，開発業者の品質管理体制が適切であることを確認する．四番目に，以上の調査結果をもとに DMSW 毎の RCSV 作業項目を決定し，RCSV 計画書としてまとめる．五番目に，ギャップ分析の結果をもとに，必要となる開発文書を収集し，不足があれば追加作成をする．六番目から八番目の作業では，DMSW の適切性を検証する．これらの作業では，据付時的確性診断（ Installation Qualification: IQ ），操作時的確性診断（ Operational Qualification: OQ），性能的確性診断（Performance Qualification: PQ），設計適格性診断（Design Qualification）を実施する．IQ では，適切な DMSW がコンピュータにインストールされていることを確認する．OQ では，設計書で記述された機能が，DMSW として実現されていることを確認する．そして，PQ ではユーザ要求仕様書（User Requirement Specification: URS）で記述された性能が，DMSW として実現されていることを確認する．DQ では，開発文書の設計情報と診断との間の追跡可能性について確認する．. 2.3 回顧的コンピュータ化システムバリデーション実施上の問題点医薬品製造会社は，医薬品の品質を向上させるために，定常的な設備・工程の見直しを行っており，それに伴って DMSW の改造が行われている．CSV では，計画段階から運用停止までのライフサイクル全体を通じて，DMSW が適切な機能と性能を有している状態であることを立証しなければならない．従って，IRCSV 実施後も，改造を行う度に MRCSV を実施しなければならない．しかし，GAMP には RCSV に関する明確な記述がないため，次の問題が発生している． (1) IRCSV 時の問題点開発文書を収集する際には，ギャップ分析を実施して，既存の開発文書の不足部分を明らかにして，不足文書を追加作成する．しかし，GAMP では RCSV の際に必要となる開発文書に関する記述がないため，問題(a)と(b)が生じている．. 問題(a) 必要となる開発文書の作成範囲が不明確である．問題(b) 開発文書に記述する項目とその説明の詳細さが不明確である．その結果，監督機関と医薬品製造会社で，準備すべき開発文書に関する解釈の差異 2. ⓒ2009 Information Processing Society of Japan.

(3) Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. オーバー・ヘッドが大きく実用的ではない．改造したソフトウェアに対する検証方法としては，改造対象の機能を独立化させることで改造が容易なソフトウェアを実現する方法9)，既存のソフトウェアを改造しやすい構造に変換する方法10) 等がある．しかし，これらはソフトウェアの構造自体が変化してしまうため，RCSV の前提と矛盾するため適用は難しい． CSV 実施方法には，高橋ら11)，12)の提案があるが，RCSV は考慮されていない．従って，円滑な RCSV を実施するための方法が望まれている．. が生じ，トラブルとなっている． (2) MRCSV 時の問題点 DMSW を改造する際には，改造に関する標準作業手順書に従って，開発文書の修正，ソフトウェアの追加・削除・修正，適切性確認のための検証を実施なければならない．しかし，GAMP には MRCSV の実施方法に関する具体的な記述が無いため，開発文書の作成と改造する機能の適切性の確認に関して以下の問題が生じている． (i) 開発文書の作成に関する問題 IRCSV の際に収集した開発文書は GAMP 等に則って作成されたものではない．そのため，問題(c)が生じている．問題(c). 4. GAMP5 を考慮した RCSV 手法の提案 4.1 節で問題(a)から(c)に対する解決策について提案する．次に，4.2 節で問題(d) に対する解決策について提案する．そして，4.3 節でこれらの解決策を統合し，かつ DMSW のライフサイクル全体を考慮した RCSV 実施手順について提案する． 4.1 RCSV のための開発文書とデータ・ベース問題(a)~(c)は，IRCSV の際に準備した開発文書と MRCSV の際に作成した開発文書で記述の様式が異なるため整合性を確保することが難しいことに起因している．以下に解決策を述べる．. IRCSV 実施時に作成した開発文書と MRCSV 時に作成した開発文書との間で整合性の確保と記述レベルの統一がなされていない．. このため，MRCSV を実施した DMSW に対して追加認証を受ける際，開発文書の機能説明の粒度が様々となり「開発文書の記述内容が不十分」との指摘を受ける． (ii) 増加する機能の適切性の確認に関する問題改造された部分の DMSW は，無改造部分の DMSW に影響を与えるので，影響を受けた範囲に対して追加検証を行い，適切性を立証する必要がある．しかし，その具体的な実施方法が規定されていない．そのため，問題(d)が生じている．問題(d). 解決策(a) 開発文書体系を規定する． IRCSV と MRCSV の両方の実施を考慮した場合，開発文書の体系は，GAMP で規定された文書体系と合致している必要がある．この観点から，提案案手法では，IRCSV の際にユーザ要求仕様書（User Requirement Specification: URS），機能設計仕様書（Functional Specification: FS），設計仕様書（Design Specification: DS），DMSW の構成管理表を作成する．そして，それらの開発文書の適切性を立証するための文書として PQ，OQ，IQ，DQ の計画書と報告書を作成したうえで，RCSV に関する計画書と結果報告書を作成する．さらに，MRCSV の際には，前記の文書の改定とモジュール・テストの計画書と結果報告書を作成する．. 改造部分に影響を受ける既存 DMSW の部分の同定と，その部分に対する網羅的な検証をすることが難しい．. その結果，監督機関から，MRCSV の際に十分な検証が行われていないとの指摘を受ける場合がある．. 3. 関連研究本章では，2.3 節で述べた問題の解決に関係する研究について述べる．開発文書の記述については Z 言語3)，VDM-SL4) 等の仕様記述言語がある．しかし，これらは高度な数学を用いるため利用者が制限され実用的でない．また，開発文書をパターンとして準備しておき，それを再利用して開発文書を作成する方法5),6)があるが，DMSW の種類は多様であるため，全パターンを準備することは実用的でない．仕様間とソフトウェアとの整合性の確認については，仕様記述言語を用いた方法7) があるが，高度な数学が要求されるので実用的ではない．ソフトウェアの改造に伴う影響範囲同定の手法には，プログラム形式化8) 等がある．プログラム形式化では，命令を正規表現形式で表し，改造の前後の正規表現を比較して構造の変化を同定する．しかし，正規表現を作成するための作業が多いため，. 解決策(b) 開発文書の雛型を作成して，記述項目と記述レベルを統一する．はじめに，雛型の記述項目について規定する．解決策(a)と同様の理由により，雛型の記述項目は GAMP 準拠とする．次に，各雛型の記述項目のレベルについて規定する．本論文で取り扱う DMSW はカテゴリ 5 であるため，IRCSV と MRCSV の整合性を確保しなければならないので，記述項目は GAMP に規定された項目とする．Table より，DMSW は単純な構造，単純なアルゴリズムであることが分かっているので，フロー・チャート，構造図，そしてそれらの処理内容の説明により，記述レベルを満たすことができる．提案手法では，これらを雛型に貼り付けて開発文書を作成する．三番目に，フロー・チャート，構造図，処理内容説明の作成手順を述べる．. 3. ⓒ2009 Information Processing Society of Japan.

(4) Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. Fig 2 Development Procedure of Flow Chart. Fig 3 Development Procedure of Structure Chart. フロー・チャートの作成手順はじめに，Fig 2 (a)に示す DMSW の命令をフロー・チャートの記号に置き換え，Fig 2 (b)に示す第 1 版のフロー・チャートを作成する．二番目に，第 1 版のフロー・チャート中に最小限の機能を表す命令のまとまりがあれば，それを下位モジュールとして識別し，Fig 2 (c)に示す第 2 版のフロー・チャートを作成する．三番目に，第 2 版のフロー・チャート中により上位の機能を表す命令，モジュールのまとまりがあれば，それを上位モジュールとして識別し，Fig 2 (d)に示す第 3 版のフロー・チャートを作成する．この作業を識別可能な上位の機能がなくなるまで繰り返す．この例の場合， Fig 2 (d)が最終版のフロー・チャートとなる．. の場合，名称は MONITORING PRESSURE IN VESSEL とした．その際，Fig 2 のフロー・チャートのモジュールは，構造図のモジュールとして，使用する．二番目に， Fig 3 (b)に示すように構造図の各モジュールに対して，処理内容の説明を作成する．三番目に，Fig 3 (c)に示すように構造図の構造と処理内容説明をもとに各モジュールを要求，外部機能，内部機能のいずれに対応するか識別する．四番目にフロー・チャート，構造図，そしてそれらの処理内容説明を用いて，開発文書を作成する手順について述べる．. z. z. URS の作成手順 FS の雛型に対して，要求に相当するモジュールの単位で，ID，バージョン，名称を記入し，さらに要求記述に処理内容説明と構造図の一部を埋め込む．そして，作成した URS を収集して全体の URS を作成する．Fig 4 に作成した URS の一例を示す．. z. 構造図と処理内容説明の作成手順はじめに，最終版のフロー・チャートを用いて Fig 3 (a)に示す構造図を作成する．便宜上，最上位モジュールを追加し，DMSW の特徴を示す名称を付与する．Fig 3 (a) 4. ⓒ2009 Information Processing Society of Japan.

(5) Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. z FS の作成手順 FS の雛型に対して，外部機能に相当するモジュールの単位で，ID，バージョン，名称を記入し，さらに機能記述に処理内容説明と構造図の一部を埋め込む．そして，作成した FS を収集して全体の FS を作成する．. (1) 改造の影響を受ける部分を同定する方法改造とは，プログラムに対して命令を追加・削除・修正する行為である．従って，追加・削除・修正された命令で計算されている変数に着目して，その影響を受ける部分を同定すれば良い．提案手法では，プログラム・スライシング13)を用いて，改造の影響を受ける部分を同定する．Fig 6 に，容器内の温度，圧力等を計算するプログラムと影響範囲を同定する手順を示す．このプログラムにおいて，190 行の変数 TEMP の計算式を改造した場合，TEMP に着目してプログラム・スライシングを行う．影響を受ける部分は{140,160,190,230,400,410}となる．. z. DS の作成手順 DS の雛型に対して，内部機能に相当するモジュールの単位で，ID，バージョン，名称を記入し，さらに設計記述に処理内容説明とフロー・チャートを埋め込む．そして，作成した DS を収集して全体の DS を作成する．. Fig 4 Sample of User Requirement Specification 解決策(c) 開発文書の記述内容をデータ・ベースで管理して整合性を確保する．設計情報を管理するデータ・ベースの構造は，解決策(a)と(b)に従うことが望ましい．また MRCSV を実施する際には，IQ，OQ，PQ，DQ の追加実施が必要となる．そして検証に関する情報も管理しなければならない．加えて DMSW の各種文書と DMSW の構成を管理する必要がある．Fig 5 に RCSV 用のデータ・ベースの構造を示す． 4.2 改造部分に対する影響範囲の同定と検証. 問題(d)は，DMSW を改造した際，その影響を受ける範囲の同定とその部分に対する網羅的な検証が困難であることに起因している．以下に解決策を述べる．解決策(d). Fig 5 RCSV Database Architecture. DMSW の改造行の変数に着目して，影響を受ける部分を同定し，それらの網羅的な検証を行う．. (2) 影響範囲の検証 GAMP ではテスト基準について明確に規定されていないため，提案手法では改造した DMSW を確認するため，限界値基準による検証行う14)．はじめに，影響を受ける範囲の同定結果に基づいて，プログラム構造を作成する．そして，条件分岐を考慮し. この解決策は，「改造の影響を受ける部分を同定する方法」と「同定した部分に網羅的なテストを行う方法」に分けて考えることができる．以下にその手順を述べる． 5. ⓒ2009 Information Processing Society of Japan.

(6) Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. て網羅的なテスト経路を設計する．Fig 6 の(c)にプログラム構造とテスト経路の一例を示す．プログラム構造は，影響を受ける命令を円，制御の流れを矢印で表す．この場合，経路は{140,160,190,240,400,410}と{140,160,240,400,410}の 2 つとなる．そして， 160 行の分岐条件として限界値を採用する．従って，テスト・データ{V,L}は{9.5,ANY} と{10.5,ANY}となる．検証終了後，IQ，OQ，PQ，DQ を再実施する．. Fig 6 Identification of Affected Range Using Program Slicing 4.3 RCSV の実施手順. Fig 7 Procedure of IRCSV. 本節では，解決策(a)から(d)を統合し，かつ，DMSW のライフサイクル全体を考慮した RCSV 実施を提案する．. z. MRCSV の実施手順 Fig 8 に提案する MRCSV の実施手順を示す．MRCSV では，はじめに「ソフトウェア構造の修正」を実施する．この工程の中では，改造の目的に合わせて構造図，フロー・チャート，処理内容説明を修正し，それらを用いて URS，FS，DS を修正する．次に，「ソフトウェ・アテストの実施」を行う．この工程では，改造の影響を受ける部分を同定し，プログラム構造図を作成し，テスト経路を設定して限界値基準に基づいたテストを実施する．以降の作業については IRCSV と同様である．. 解決策(e) 解決策(a)から(d)を連携させた RCSV 実施手順を規定する． IRCSV と MRCSV では，RCSV に関係する文書の有無により，実施手順が異なっている．以下に，それぞれの実施手順について述べる． z. IRCSV の実施手順 Fig 7 に提案する IRCSV の実施手順を示す．Fig 1 との差異は，「開発文書の確認と更新」作業の代わりに，「ソフトウェア構造の分析」を実施することである．この工程の中で，DMSW の構造図，フロー・チャート，処理内容説明を作成し，それらを用いて URS，FS，DS を作成する．並行して，それらの情報をデータ・ベースに登録して管理する．この作業により，IRCSV を実施した場合でも，GAMP に準拠した開発文書を準備することが可能となる．. この結果，IRCSV と MRCSV で実施手順は，ほぼ同様となり実施手順の違いによる煩わしさはなくなり，IRCSV と MRCSV との間での開発文書の不整合は発生しない．加えて，改造を行った部分の網羅的なテストも実施することができる．. 6. ⓒ2009 Information Processing Society of Japan.

(7) Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. (i) 「設計情報が漏れなく管理できること」に対する評価提案手法で使用するデータ・ベースのテーブルは，解決策(a)で定めた開発文書の単位となっており，各テーブルの属性は解決策(b)で定めた記述項目となっている．従って，データ・ベースで管理する設計情報はGAMPの要求を満足しており，必要な情報を管理することができる． (ii) 「IRCSVとMRCSVを通じて漏れなく設計情報を管理できること」に対する評価 IRCSVを実施した場合には，既存のDMSWから設計情報を逆生成し，それをデータ・ベースに格納する．従って，IRCSVの際，設計情報を漏れなく管理できる．MRCSVを実施した場合には，IRCSVの際にデータ・ベースに格納した設計情報をURS⇒FS⇒DS⇒DMSW Module の順番で修正し，データ・ベースを更新する．さらに，検証情報をModule Test⇒IQ⇒OQ⇒ PQの順番で修正し，データ・ベースを更新する．改造の際，上下位機能と入出力データに関する設計情報をキーとして，異なる階層間および同一階層内における設計情報を追跡をすることができる．従って，MRCSVの際，設計情報を漏れなく管理することができる．従って，漏れなく設計情報を管理することができる．以上の結果，「必要な設計情報が管理できること」，「IRCSVとMRCSVを通じて漏れなく設計情報を管理できること」が確認でき，問題(c)を解決することができる．. Fig 8 Procedure of MRCSV. 5. 提案手法の評価. (4) 解決策(d)の評価問題(d)は，「改造の影響を受けた部分を同定すること」と「改造の影響を受けた部分の網羅的なテストを行うこと」に分けて評価することができる．. 本章では，提案するRCSV手法を適用することで，現状のRCSVに関する問題点が解決できるか評価を行う．. (i) 「改造の影響を受けた部分を同定すること」に対する評価改造はソフトウェアに対する命令の追加，削除，修正の3種類に分類することができる．命令を追加した場合，追加した行で計算される変数に関してプログラム・スライシングを行うことで，影響を受ける部分を同定することができる．命令を削除した場合は，削除した行で計算されていた変数に関してプログラム・スライシングを行うことで，影響を受ける部分を同定することができる．修正とは，命令そのものではなく，定数や分岐条件等を修正することである．定数を変更した場合は，定数に関するプログラム・スライシングを，分岐条件を変更した場合は，分岐に用いた変数に関するプログラム・スライシングを行うことで，影響を受ける範囲を同定することができる．以上の結果，改造の影響を受ける範囲を同定することができる．. (1) 解決策(a)の評価問題(a)に対しては，解決策(a)でRCSVの開発文書体系を定めた．この体系は，GAMPで規定されたPCSV の開発文書体系と同様である．従って，GAMPで要求される開発文書は全て揃い，問題(a)を解決することができる． (2) 解決策(b)の評価問題(b)に対しては，解決策(b)で各開発文書の雛形を作成し，記述項目とその記述レベルを定めた．記述項目は，GAMPで規定された開発文書の記述項目と同様である．記述レベルについては，RCSV対象となるDMSWの特徴から，構造図とフロー・チャートを利用して記述するように規定した．これらは，GAMPの要求を満足している．さらに，稼働中のDMSWから構造図とフロー・チャートを逆生成する方法を規定した．従って，開発文書の必要な記述項目とその記述レベルは十分となり，問題(b)を解決することができる．. (ii) 「改造の影響を受けた部分の網羅的なテストを行うこと」に対する評価 (i)により，改造の影響を受けた部分は同定することができた．その部分を取り出して分析すれば，プログラム構造図が作成できる．そして，プログラム構造図の条件分岐を考慮したテスト経路を設計できる．さらに，その条件分岐に対して限界値基準に基づいたテスト・データを作成し，テストを行うことができる．これにより，改造の影響を受けた部分の網羅的なテストを行うことができる．. (3) 解決策(c)の評価問題(c)は，「必要な設計情報が管理できること」と「IRCSVとMRCSVを通じて漏れなく設計情報を管理できること」に分けて評価することができる．. 7. ⓒ2009 Information Processing Society of Japan.

(8) Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. 以上の結果，問題(d)を解決することができる． 7). (5) 解決策(e)の評価解決策(a)∼(d)は提案する解決策(e)のRCSV実施手順に組み込まれており，漏れなく実施することが可能である．さらに，DMSWのライフサイクル全体にわたる対応が可能となる．以上の評価の結果，RCSVに関する問題は，提案するRCSV手法により解決できることが確認できた．. 8). Satou, T. and Kishimoto Y., Program Code Analysis Focused on its Structure, WSEAS Transaction on Computers, Vol.2, Issue 1, pp24-29, 2003.. 9). 下村, 沖, 力石, 太田, 改造に伴う影響を除去するソフトウェア独立改造方式, 情報処理学会全国大会, 7M, pp6-7, 1994. Gallagher, K. B. and Lyle, J. R, Using Program Slicing in Software Maintenance, IEEE Transactions on Software Engineering, Vol.17, No.8, pp.751-761, 1991. 高橋, 津田, 医薬品製造設備における制御ソフトウェアの効率的コンピュータ・バリデーション, 情報処理学会論文誌, No.12, pp.2869-2879, 2004. 高橋, プログラマブル・ロジック・コントローラを用いた医薬品製造設備制御ソフトウェアの効率的なコンピュータ・バリデーションの一手法, 計測自動制御学会論文誌, Vol.42, No.8, 949-958, 2006. Weiser, M., Program Slicing, IEEE Transactions on Software Engineering, Vol.10, No.4, pp352-357, 1984. Myers, G. J. et al., The Art of Software Testing 2nd Edition, Jhon Wiley ¥& Sons Inc., 2004.Myers, G. J. et al., The Art of Software Testing 2nd Edition, Jhon Wiley ¥& Sons Inc., 2004.. 10) 11). 6. おわりに 12). 本論文では，GAMP5に基づいて，稼動中のDMSWが，医薬品の製造に適した機能と性能を有していることを立証するためのRCSV手法について提案した．提案手法により，医薬品製造会社で利用されているDMSWの適切性が立証できるようになり，さらに，そこで製造される医薬品の品質の適切性が立証できるようになった．今後は，カテゴリ5が以外のDMSWにもて起用可能なRCSV手法を提案するとともに，支援ツールの充実を図っていく．GAMP 5は2008年2月に発表されたばかりであり，現時点で，その適用の報告はまだなされていない．GAMP 5の適用に関する情報を収集して，その情報を提案案手法に反映させていく．そして，提案RCSV手法の適用を進めていく．併せて，作業の効率化を図っていく．. 謝辞. 義方法の提案, 信学技報, Vol.105, pp. 85-90, 2005. Satyananda, T., K., Lee, D. and Kang, S., Formal Verification of Consistency between Feature Model and Software Architecture in Software Product Line, Proc. of ICSEA2007, PP. N/A, 2007.. 13) 14). 本研究の一部は日本学術振興会科学研究費補助金基盤研究(c)，課題番号 21500439「医薬品製造に関わるソフトウェアの統合的なコンピュータ・バリデーション手法の研究」の助成による．. 参考文献 1) 2) 3) 4) 5). 6). GAMP forum: GAMP 5 A Risk-Based Approach to Compliant GxP Computerized Systems, International Society for Pharmaceutical Engineering, 2008. 萩原, 他, コンピュータバリデーション，FDA・厚生省 ER/ES 指針とその適用事例, 情報機構, 2006. Spivey, J. M., Understanding Z: A Specification Language and Its Formal Semantics, Cambridge Univ Press, 2008. Middelburg, C. A., Logic and Specification: Extending Vdm-Sl for Advanced Formal Specification, Chapman & Hall, 1993. Saida, R., et al.: Automatic Conversion from Specifications written in Japanese to Class Diagrams of UML, Technical Report of The Institute of Electronics, Information and Communication Engineers, Pattern Recognition and Media Understanding, , Vol.105, No.615, pp.159-164 (2005). 佐藤, 井上, 井上, 山村, 装置・NW 管理ドメインにおけるパターンを利用した OSS 要求定. 8. ⓒ2009 Information Processing Society of Japan.

(9) Vol.2009-SE-165 No.1 2009/7/2. 情報処理学会研究報告 IPSJ SIG Technical Report. 1) GAMP forum: GAMP 5 A Risk-Based Approach to Compliant GxP Computerized Systems, International Society for Pharmaceutical Engineering, 2008. 2)萩原, 他, コンピュータバリデーション，FDA・厚生省 ER/ES 指針とその適用事例, 情報機構, 2006. 3) Spivey, J. M., Understanding Z: A Specification Language and Its Formal Semantics, Cambridge Univ Press, 2008 4) Middelburg, C. A., Logic and Specification: Extending Vdm-Sl for Advanced Formal Specification, Chapman ¥& Hall, 1993. 5) Saida, R., et al.: Automatic Conversion from Specifications written in Japanese to Class Diagrams of UML, Technical Report of The Institute of Electronics, Information and Communication Engineers, Pattern Recognition and Media Understanding, , Vol.105, No.615, pp.159-164 (2005). 6)佐藤, 井上, 井上, 山村, 装置・NW 管理ドメインにおけるパターンを利用した OSS 要求定義方法の提案, 信学技報, Vol.105, pp. 85-90, 2005. 7) Satyananda, T., K., Lee, D. and Kang, S., Formal Verification of Consistency between Feature Model and Software Architecture in Software Product Line, Proc. of ICSEA2007, PP. N/A, 2007.. 8) Satou, T. and Kishimoto Y., Program Code Analysis Focused on its Structure, WSEAS Transaction on Computers, Vol.2, Issue 1, pp24-29, 2003. 9)下村, 沖, 力石, 太田, 改造に伴う影響を除去するソフトウェア独立改造方式, 情報処理学会全国大会, 7M, pp6-7, 1994. 10) Gallagher, K. B. and Lyle, J. R, Using Program Slicing in Software Maintenance, IEEE Transactions on Software Engineering, Vol.17, No.8, pp.751-761, 1991. 11)高橋, 津田, 医薬品製造設備における制御ソフトウェアの効率的コンピュータ・バリデーション, 情報処理学会論文誌, No.12, pp.2869-2879, 2004. 12)高橋, プログラマブル・ロジック・コントローラを用いた医薬品製造設備制御ソフトウェアの効率的なコンピュータ・バリデーションの一手法, 計測自動制御学会論文誌, Vol.42, No.8, 949-958, 2006 13) Weiser, M., Program Slicing, IEEE Transactions on Software Engineering, Vol.10, No.4, pp352-357, 1984. 14) Myers, G. J. et al., The Art of Software Testing 2nd Edition, Jhon Wiley ¥& Sons Inc., 2004.. 9. ⓒ2009 Information Processing Society of Japan.

(10)