No.108AIを利用した自社開発システムのCSVについて

CSV投稿者: とくさん2026年9月11日 18:19

AIの進歩により、ちょっとしたシステムであればベンダーに開発を依頼しなくとも構築可能になってきているかと思います。ローンチ後のメンテナンスや保守などの話もあるかと思いますが（こちらもAIで対応可能かと思われますが）、適正ガイドラインに従って開発等を自社で行う場合に気を付けなければならないことはどんなことでしょうか？例えば供給者監査やアセスメントなどはどのように実施すればよいのでしょうか？ AIがすべてコードを書いた場合のコードレビューはどのように実施すればよいのでしょうか？プログラムテストで代用可能なのでしょうか？

公式回答株式会社イーコンプライアンス2026年9月11日 18:28

AIを利用した自社開発システムのCSVについて

株式会社イーコンプライアンス

結論（要点）

AIがコードを書いても、規制上の要求は軽くなりません。 自社で作り込んだシステム（カスタム開発）は、CSVの世界で最も検証負荷が大きい類型に当たります。「小規模だから軽く済む」ではなく「小規模だが、設計仕様書もコードレビューも必要」が出発点です。
供給者は「自社」になります。 供給者監査は外部への監査ではなく、自社の開発プロセス・力量・記録管理を評価する内部アセスメントとして実施します。外部ベンダーの品質保証文書に依拠して検証を軽減する、という手は使えません。
生成AIサービス（ChatGPT、Claude、Copilot 等）は、一般的な解釈としては「供給者」ではなく「開発ツール」として管理するのが妥当と考えます。ただしAIが本番稼働時に推論・判断を行う設計であれば、まったく別問題として戦略を設計し直す必要があります。
コードレビューはプログラムテストで代替できません。 目的が異なります（机上での静的確認 vs. 動かしての動的確認）。とくにAI生成コードは「テストは通るのに、仕様に無い挙動やセキュリティ欠陥を抱えている」形になりやすく、テストだけでは検出できません。
実務上の最大のリスクは技術面よりも属人化・ブラックボックス化です。「査察官に『このシステムの監査証跡はどう実装されていますか』と聞かれ、社内の誰も答えられない」状態が、最も突かれる弱点になります。

0. まず「今回の質問に直結する最小セット」

規制文書を最初から大量に並べると混乱しますので、優先度順に整理します。

日本国内でGxP記録を扱うシステムなら、まずこの3つ

優先	文書	本件での意味
①	「医薬品等の製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」（平成24年4月1日薬食監麻発0401第2号）	開発計画、要求仕様、システムアセスメント、機能仕様・設計仕様、プログラム作成及びプログラムテスト、システムテスト、検証業務、運用管理業務（変更管理・自己点検等）——自社開発でも成果物と記録の要求は同じで、そのすべてを自社で作成・維持する義務を負います
②	「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」（ER/ES指針。平成17年4月1日薬食発第0401022号）	真正性・見読性・保存性、監査証跡、アクセス管理。AIはこれらを「自発的に」実装しません。要求仕様に書かなければ確実に抜けます
③	GMP省令（平成16年厚生労働省令第179号）／医療機器等の場合はQMS省令（平成16年厚生労働省令第169号）	品質システム、文書・記録の管理、バリデーション。責任主体は製造販売業者・製造業者です

米国向けの製品・データがある場合に追加されるもの

文書	補足
21 CFR Part 11（Electronic Records; Electronic Signatures）§11.10、§11.30 等	21 CFR Part 11（eCFR）
21 CFR Part 820（医療機器）。2024年2月2日公表の最終規則により QMSR（Quality Management System Regulation）へ改正され、発効日は2026年2月2日。それまでが移行期間です	21 CFR Part 820（eCFR） QMSRは ISO 13485:2016 を取り込む構成のため、日本のQMS省令とのギャップ比較も ISO 13485 を軸に行うと整理しやすくなります
FDA ガイダンス「Computer Software Assurance for Production and Quality Management System Software」	リスクベースでテスト労力を配分する考え方（後述第5章）

参考として押さえておくとよいもの

ISO 13485:2016（医療機器QMS）4.1.6（QMSで使用するコンピュータソフトウェアの適用に関するバリデーション）、7.5.6（製造・サービス提供工程の妥当性確認）
ICH Q9(R1)「品質リスクマネジメント」 — 後述のリスクベース判断の枠組みとして参照できます
GAMP 5 Second Edition（ISPE、2022年） — 業界ベストプラクティス（法令ではありません）

※ 上記のうち、日本の通知・省令および ICH／ISO の各文書については、本文そのもののURLに確信が持てないため、本回答ではあえてリンクを付けず、文書名・発出番号・条項番号のみを記載しています（当社は、推測したURLや発行機関のトップページへのリンクは掲載しない方針です）。原文は各発行機関の公式サイトでご確認ください。

※ 外部レビューでは「eCFRへのリンクを削除すべき」「IMDRF文書のURLを追加すべき」というご指摘をいただきましたが、当社の出典方針では eCFR（ecfr.gov）は米国連邦規則集の一次情報源として掲載可、一方 IMDRF は当社の掲載対象一次情報源に含めていないため、この2点についてはご指摘を反映していません。この点をあらかじめ明記いたします。

1. 前提の整理：自社開発は「最も重い」ケース

1-1. 「カテゴリ」とは何か（用語の説明）

CSVの実務では、GAMP 5（ISPE発行の業界ガイドライン）のアプリケーション分類（カテゴリ）がよく使われます。ざっくり言うと次のような整理です。

カテゴリ3（設定せずに使う市販ソフト） … 供給者のテスト実績にある程度依拠できる
カテゴリ4（設定して使う市販ソフト） … 設定内容（コンフィグレーション）を中心に検証
カテゴリ5（カスタム開発） … 自社向けに書かれたコードなので依拠できる他社の実績がなく、設計仕様書の作成・ソースコードレビュー・単体テストまで自前で行う

AIに書かせたコードも、「AI製」という新しいカテゴリにはなりません。

自社（またはAI）が書いたアプリケーション・スクリプト → カテゴリ5相当
ローコード／ノーコード基盤やRPA上に構築 → 基盤はカテゴリ4相当、その上の設定・スクリプト部分はカテゴリ5相当として切り分けて評価

※ 重要な注意：「カテゴリ5」は日本のコンピュータ化システム適正管理ガイドラインの正式用語ではありません。 同ガイドラインは「カテゴリごとの検証範囲」を明示的に定義していません。GAMP 5 では Category 5（カスタムアプリケーション）は他カテゴリより検証負荷が高いとされ、国内のCSV実務でも一般に同様の解釈が取られている、という位置づけです。したがって本回答でも「規制がそう規定している」ではなく「業界の一般的解釈として重く見るべき」という趣旨でお読みください。

1-2. データインテグリティとの関係（表現の正確さについて）

GMP省令・QMS省令には「データインテグリティ」という用語自体は明示されていません。ただし両省令は記録の正確性・完全性・保存性の確保を求めており、その責任は製造販売業者・製造業者が負います。したがって「AIに書かせたから、記録の信頼性の責任が軽くなる」ということはありません。

2. 供給者監査・供給者アセスメントはどう実施するか

2-1. そもそも何のためのアセスメントか

供給者アセスメントには、大きく次の2つの目的があります。

供給者の品質保証能力に依拠してよいかを判断し、依拠できる範囲で自社の検証を軽減する
供給者の品質システム全般（開発プロセス、変更管理、不具合対応、セキュリティ、継続的な供給能力）が適格であることを確認する

自社開発では、①で依拠できる外部の品質保証が存在しません。 したがって、

検証軽減の根拠が使えない → 設計仕様書・ソースコードレビュー・プログラムテストまで自社で実施し、記録を残す
代わりに評価すべきは → 「自社の開発体制が、供給者として合格水準にあるか」（＝②を自社に向けて行う）

という置き換えになります。

2-2. 「内部供給者アセスメント」という考え方

これは、本来は外部ベンダー向けに行う供給者アセスメントを、供給者＝自社に置き換えて適用したものです（当社が実務上使っている呼び方で、規制用語ではありません）。

実施のしかたの目安：

評価者：品質保証部門、または当該開発に関与していない第三者
記録の置き場所：システムアセスメント記録（または供給者アセスメント記録）の添付資料
タイミング：開発着手前に初回実施し、以後は定期レビュー・自己点検の対象に含める

2-3. 内部供給者アセスメントのチェック項目（例）

区分	確認項目	記録の例
開発プロセス	コンピュータ化システム開発に関する手順書（SDLC）が制定されているか	社内SOP
力量	開発担当者・レビュー担当者の力量（言語、DB、セキュリティ、GxP）と教育訓練記録	力量評価表、教育記録
独立性	開発者と検証者・最終承認者の役割が分離されているか	役割分担表、承認フロー
構成管理	ソースコードのバージョン管理（Git等）、ビルド手順、リリース物の同定	リポジトリ、リリース記録
環境分離	開発／テスト／本番環境が分離されているか	構成図
変更管理	リリース後の修正が変更管理手順を通るか（AIで直す場合も同じ）	変更管理記録
テスト	テスト計画・仕様・実施記録・エビデンスの様式が定義されているか	テスト手順書
セキュリティ	アクセス権の付与・削除、特権ID管理、監査証跡の保護	セキュリティSOP
AI利用ルール	使用可能なAIサービス、入力してよい情報の範囲、記録の残し方	AI利用規程
自己点検	コンピュータ化システムの自己点検の対象に含まれているか	自己点検計画・記録

独立性についての補足：開発者と検証者・承認者を分けることが望ましいのは間違いありませんが、規制文書が「1人開発を禁止」と明文で定めているわけではありません。小規模組織では役割の兼務が避けられない場合もあります。その場合でも、少なくとも品質部門または当該開発に関与していない第三者が検証・承認に関与する形を確保し、なぜその体制で妥当なのかをリスク評価記録に残してください。

3. 生成AIサービス自体の扱い

3-1. 「開発時にだけ使う」場合

この場合、そのAIサービスは規制対象システムの構成要素ではないため、供給者監査の対象とはせず、「開発ツールの管理」として扱うのが一般的な解釈として妥当と考えます。

※ ただし、この分類（供給者ではなく開発ツール）を明文で規定した法令・通知は、現時点では存在しません。コンピュータ化システム適正管理ガイドラインにもAI固有の供給者分類の規定はありません。当社の見解としての整理である点をご承知ください。

押さえるべき管理項目：

利用するサービス名・モデル名・バージョン（記録に残す）
入力データの取り扱い（患者データ・製造データ・未公開仕様を入力しない／学習利用のオプトアウト設定）
利用規約上の生成物の権利・ライセンス、および出力に混入し得るOSSライセンス（GPL等）の確認
社内AI利用ポリシー（どの用途に使ってよく、どこは人間が必須か）

3-2. 「本番稼働時にAIが動作する」場合

例：AIが逸脱内容を分類する、記録を要約して保存する、判定結果を出す——といった設計です。これはまったく別問題です。

Part 11 や EU GMP Annex 11、ER/ES指針は、いずれも従来型の（同じ入力に同じ出力が返る）ソフトウェアを念頭に策定されており、確率的に出力が変わるAIへの適用には解釈・運用上の課題が伴います。

※ これらの規制が「決定論的システムのみを対象とする」と明記しているわけではありません。「AIは規制の想定外だから自由」という意味ではなく、適合性の立証方法を自社で設計・正当化する必要があるという意味です。

当社が現時点で妥当と考えるアプローチ（確立した公式解釈ではありません）：

AIの役割を意思決定支援（ドラフト生成）に限定し、正式記録は従来型システムで管理する
AI出力は「ドラフト」扱いとし、人間によるレビューと最終承認を経て記録化する
監査証跡に「AI生成 → 人間の修正 → 最終承認」の全ステップを残す
代表的なデータセットによる性能評価（精度・再現率等。100%保証ではない旨を文書に明記）
運用開始後の継続的モニタリング（性能劣化の早期検出）

なお、AIが医療機器の機能そのもの（診断・治療判断の支援等）に関わる場合は、CSVの枠ではなく医療機器プログラムとしての規制（薬機法上の該当性判断、QMS省令、ソフトウェアライフサイクル）の検討が先に必要です。国際的にも SaMD（Software as a Medical Device）やAI/ML搭載機器の枠組みが議論されていますので、該当しそうな場合は早い段階で規制該当性の確認をお勧めします。

4. AIが全コードを書いた場合のコードレビュー

4-1. 結論：プログラムテストでの代用は不可

適正管理ガイドラインの開発業務では、設計仕様に関する文書の作成とプログラムの作成及びプログラムテストが別項目として要求されています。ソースコードレビュー（設計仕様との整合性確認）とテストは、目的の異なる別の検証行為です。

建築にたとえると：

コードレビュー ＝図面と使われている部材を机の上で突き合わせて確認する作業。「図面に無い配管が通っていないか」「規格外の材料が混ざっていないか」が分かります。
プログラムテスト ＝実際に電気を通し、水を流して動かしてみる作業。ただし試した箇所しか分かりません。

	ソースコードレビュー（静的）	プログラムテスト（動的）
目的	設計仕様どおりに書かれているか、余計な実装が無いか	期待どおりに動作するか
検出できるもの	隠しコード・デバッグコード、ハードコードされたID／パスワード、エラー処理の欠落、規約違反、保守性の問題、ライセンス問題、監査証跡の実装漏れ	機能不具合、境界値、異常系の挙動
検出できないもの	実行時の相互作用、性能	「テストケースに書かなかったこと」すべて

テストは「テストした条件で合格した」ことしか示せません。AI生成コードのリスクは、まさにこの「テストしていない部分」に集中します。

4-2. AI生成コード特有のリスク（レビュー観点）

以下は規制文書に列挙された要求ではなく、当社の実務経験および一般に指摘されている傾向です。

ハルシネーション — 存在しない関数・引数・ライブラリの使用、実在しないパッケージ名（サプライチェーン攻撃の入口にもなり得ます）
コメントと実装の不一致 — もっともらしいコメントが付いているのに、処理内容が違う
規制要件の欠落 — 監査証跡、変更前後の値の保持、削除禁止、タイムスタンプ、権限分離は、要求仕様に明記しない限りほぼ実装されません（ER/ES指針・Part 11 の核心部分）
セキュリティ — SQLインジェクション、認証の甘い実装、平文パスワード、古い暗号方式
依存ライブラリ — 既知脆弱性、ライセンス条項、保守終了
過剰実装 — 頼んでいない機能・エンドポイントが付いてくる（＝仕様外機能＝検証対象外の穴）
再現性の欠如 — 同じ指示でも別のコードが出るため、「なぜこの実装なのか」の設計根拠が残らない
仕様の循環 — AI生成コードから仕様書を逆生成すると、仕様がコードを追認するだけになり検証の意味が失われます。必ず「仕様 → コード」の順序を守ってください。

4-3. 実務的なレビューの進め方

① レビュー体制

AIに書かせた人 ≠ レビューする人（独立性）
レビュー者はそのコードの挙動を自分の言葉で説明できることを合格条件にする → 説明できないコードは「レビュー未完了」として差し戻す。ここが最も重要な歯止めです

② レビュー可能な粒度に分割

全体アーキテクチャ・データモデル・権限設計は人間が設計仕様書として作成
AIには「関数／画面／バッチ」単位の小さな実装を任せ、1回のレビュー量を人間が読める範囲に抑える

③ レビューチェックリストを規程化（例）

設計仕様との一対一対応（トレーサビリティ）
仕様外の機能・コード・外部通信が無いこと
入力バリデーション、例外処理、ログ出力
監査証跡・電子署名・権限制御の実装
ハードコードされた接続情報・アカウントが無いこと
コーディング規約、命名、可読性（＝将来の保守性）
依存ライブラリの一覧・バージョン・ライセンス・既知脆弱性

④ 機械的手段は「補助」として活用（人間の承認は必須）

静的解析（リンター）、SAST（セキュリティ静的解析）、依存関係脆弱性スキャン、コードカバレッジ
別のAIによるクロスレビューは指摘候補の抽出として有用ですが、AI同士のレビューは独立性の証明にはなりません

⑤ 記録（査察で提示するもの）

対象ソースの同定（ファイル名、バージョン／コミットID、ハッシュ）
レビュー観点（チェックリスト）、指摘事項、修正内容、再レビュー結果
レビュー者・承認者の署名と日付
AI使用記録：使用モデル名・バージョン、実施日、主要なプロンプト（または要旨）、生成物、人間が加えた修正

5. どこまで軽減できるか（リスクベースの考え方）

FDA ガイダンス「Computer Software Assurance for Production and Quality Management System Software」では、高プロセスリスク（患者安全・製品品質に直結）の機能にはスクリプト化テストを集中させ、それ以外は非スクリプト化テスト（探索的・シナリオベース）で労力を軽減する整理が示されています。

※ 同ガイダンスは2022年9月にドラフトが公表され、その後最終版が発出されています。最新の版・表現は必ず FDA の公表原文でご確認ください（当社としては版の詳細について断定を避けます）。

※ リスク評価の枠組み自体は、ICH Q9(R1)「品質リスクマネジメント」の考え方と整合的に組み立てると説明しやすくなります。

これを踏まえた現実的な設計：

リスク	テスト	コードレビュー
高（患者安全・製品品質・GxP記録の完全性に影響。計算・判定・記録保存・権限制御）	スクリプト化テスト（正常系＋異常系＋境界値）＋エビデンス保存	原則全行レビュー。第三者レビュー＋静的解析
中	シナリオベーステスト	変更箇所＋その周辺、静的解析併用
低（画面レイアウト、参照専用の表示等）	探索的テスト、使用時確認	観点を絞ったレビュー（省略する場合はリスク評価書で根拠を文書化し、品質部門が承認）

「リスクが低いからレビューをゼロにする」ことは可能ですが、無条件ではありません。 その判断根拠（機能の低リスク性、出力を人間が全件確認する運用、静的解析の実施、カバレッジ等）をリスクアセスメント記録に残し、品質部門が承認することが前提です。

つまり「テストで代用してよいか」は、規制が認める／認めないという二択ではなく、その軽減を自社が科学的に正当化し、文書化できるかの問題だとご理解ください。

6. 見落としやすい「ローンチ後」の論点

ご質問にあるとおり、保守もAIで対応できそうに見えます。しかしここが最大の落とし穴です。

属人化とブラックボックス化
- 「AIに聞けば直る」は、その担当者がAIを使いこなせる限りの話です。異動・退職後に誰も触れないシステムがGxP記録を保持している状態は、重大な指摘対象になり得ます。
- 具体的なイメージ：査察官から「この記録の変更履歴はどこに、どの形式で保存されていますか」「削除できない仕組みはどう実装されていますか」と問われ、社内の誰も答えられない——これが最悪のシナリオです。
- 対策：設計仕様書・データモデル図・運用手順書を人間が読める形で維持し、引継ぎ可能性を定期レビュー項目に含める。
ソースコードと成果物の自社保有・構成管理
- リポジトリ、ビルド手順、リリース物、環境設定を自社資産として管理・バックアップする。
変更管理を必ず通す
- AIで5分で直せるからこそ、無記録の修正（＝未承認変更）が起きます。影響評価 → 承認 → テスト → 記録の手順を例外なく適用し、緊急変更の手順も定めておく。
AIサービス側の変更リスク
- モデル更新・仕様変更・サービス終了により、同じ手法で保守できなくなる可能性があります。開発時の環境・モデルを記録し、代替手段を想定しておく。
定期レビューと自己点検
- 適正管理ガイドラインの運用管理業務（自己点検、セキュリティ管理、バックアップ・リストア等）の対象に、自社開発システムを確実に含める。
セキュリティ保守
- 依存ライブラリ・OSのパッチ適用、脆弱性情報の監視。自社開発は「誰も面倒を見ない」状態になりやすい領域です。

7. 最低限そろえるべき成果物（自社開発＝カスタム開発の目安）

フェーズ	成果物	補足
計画	バリデーション計画書／開発計画書、リスクアセスメント、システムアセスメント（分類・内部供給者アセスメント）	「自社開発である」ことのリスクを明記
要求	要求仕様書（URS） ※ 監査証跡・アクセス制御・データ保存要件を必ず記載	ここに書かないとAIは作りません
設計	機能仕様書、設計仕様書（アーキテクチャ、データモデル、権限設計）	人間が作成
実装	ソースコード、構成管理記録、AI使用記録、コードレビュー記録	レビュー記録は必須
テスト	プログラムテスト（単体）、システムテスト（結合）、IQ／OQ／PQ、トレーサビリティマトリクス	高リスク機能はスクリプト化
報告	バリデーション報告書、リリース承認
運用	SOP、教育訓練記録、セキュリティ管理、バックアップ／リストア、変更管理、逸脱管理、定期レビュー、自己点検	保守の持続性を確認
廃棄	廃棄計画・記録（データ移行・保存期間）

8. 当社からの実務的な推奨

1件目は「低リスク・非GxP」領域で試す。 開発体制とレビュー手順を回して成熟させてから、GxP対象システムへ拡大してください。
AI利用規程を先に作る。 「どのAIを、どの目的に使い、何を記録し、どこを人間が承認するか」を明文化しないまま開発を始めると、後付けの文書整備がきわめて困難になります。
委託でも自社開発でも、規制責任の所在は変わりません。 外部ベンダーに委託しても責任は委託元（製造販売業者・製造業者）が負い、自社開発に切り替えても同じです。「AIが書いた」は免責理由になりません。査察対応としては、①AI利用ポリシー、②技術文書（仕様・設計・レビュー・テスト記録）、③リスク評価と軽減策の3点を整備しておくことをお勧めします。

注記

※ 本回答は、当社が把握している規制・ガイドラインおよび実務経験に基づく一般的な考え方の整理であり、個別案件の適合性を保証するものではありません。実施に際しては、貴社の製品区分・対象当局・システムの用途に応じたご判断が必要です。

※ 生成AIに関する規制当局の考え方は現在も形成途上です。本回答中の「AIを用いた開発・運用の管理方法」は確立した公式解釈ではなく、当社として現時点で妥当と考えるアプローチであり、断定を避けて記載しています。

※ 「カテゴリ5」「内部供給者アセスメント」は、それぞれ GAMP 5（ISPE発行の業界ガイドライン）の用語、および当社の実務上の呼称であり、日本の法令・通知の正式用語ではありません。

※ 各文書の章・項の呼称は整理上の表現です。正確な条項番号は必ず原文（通知本文・省令本文）でご確認ください。

※ 日本の通知・省令、ICH、ISO の各文書については、本文そのもののURLに確信が持てないため、本回答ではリンクを付さず文書名・発出番号のみを記載しています。

個別のシステム（用途、GxP区分、リスクレベル）が決まっていれば、内部供給者アセスメント様式、AI使用記録様式、コードレビューチェックリストの具体案までご提示できます。差し支えない範囲で対象システムの概要をお知らせください。