設計管理と設計開発の違いとは

医療機器業界で働く方であれば「設計管理」という言葉を一度は耳にしたことがあるだろう。しかし、この「設計管理」と「設計開発」の違いを明確に説明できる人は意外と少ない。結論を先に述べれば、規制されているのは「設計開発」ではなく「設計管理」である。どのような回路を組むか、どのようなアルゴリズムを選ぶかは企業の専門性に委ねられているが、それをどう計画し、どう検証し、どう記録するかは法的要求事項として定められている。本稿では、この2つの概念の違いを、21 CFR Part 820（QMSR）・ISO 13485:2016・QMS省令の条文に対応づけながら、初心者にも分かりやすく解説していく。

「設計開発」と「設計管理」――似て非なる2つの概念

まず、2つの言葉が指しているものを一覧で並べてみる。この対比が、本稿の問いに対する直接の回答である。

設計開発とは何か

設計開発とは、製品の仕様を決定し、それを実現するための技術的な活動そのものを指す。具体的には以下のような活動が含まれる。

• 製品の機能仕様の決定
• 回路図や機械図面の作成
• ソフトウェアのプログラミング
• 試作品の製作
• 性能試験の実施

これらは、エンジニアとしての専門的な知識と経験に基づいて行われる創造的な活動である。どのような設計手法を用いるか、どのような図面の書き方をするかといった技術的な選択は、基本的に各企業のプロフェッショナルな判断に委ねられている。

なお、FDAの産業界向け教育資料（CDRH Learn）は、設計開発を「ある対象に対する要求事項を、その対象に対するより詳細な要求事項へと変換する一連のプロセス」と説明し、これはISO 9000:2015の定義に拠るとしている。「設計」「開発」「設計開発」の3語は、しばしば同義に使われる。

設計管理とは何か

一方、設計管理は、設計開発のプロセスを適切に管理・記録し、品質を保証するための体系的な仕組みである。設計開発という「活動」に対して、設計管理は「プロセスの管理方法」と言える。

重要なのは、医療機器規制において厳格に規制されているのは、この「設計管理」の方であるという点だ。設計開発の技術的な内容そのものは規制対象ではないが、それをどのように管理するかは法的要求事項として定められている。

なぜ設計管理が法的要求になったのか――「44%」という数字の出どころ

設計管理が米国で法的要求事項になった経緯は、明確な数字で裏付けられている。

FDAは1990年5月22日付の連邦官報（55 FR 21108）で、1983年10月から1989年9月までの6年間に発生した医療機器回収を分析した報告書「Device Recalls: A Study of Quality Problems」の公表を告知した。1996年10月7日に公布された品質システム規則（QSR）最終規則の前文（61 FR 52602）は、その結論を次のように記している。

この分析結果を受け、1990年の医療機器安全法（Safe Medical Devices Act of 1990）がFDAに対し、医療機器のcGMP要求事項に設計管理を追加する権限を与えた。そして1997年6月1日、設計管理を含む品質システム規則（QS Regulation）が施行された。設計管理は、こうして「思想」ではなく「実測データに基づく制度」として導入されたのである。

設計管理を定める規制は、いま、どうなっているか

ここは元記事から最も大きく書き換えた部分である。従来「ISO 13485やFDAの21 CFR Part 820では」と並列で語られてきた両者の関係は、2026年2月2日をもって根本的に変わった。

QMSR――Part 820 は ISO 13485:2016 を「引用組み込み」している

FDAは2024年2月2日、医療機器品質システム規則改正最終規則（89 FR 7496）を公布した。この規則により21 CFR Part 820はQuality Management System Regulation（QMSR）へと改称され、2026年2月2日に施行された。

QMSRの構造は次のとおりである。

• §820.7（Incorporation by reference）――ISO 13485:2016 および ISO 9000:2015 の第3章（用語及び定義）を引用組み込み（incorporation by reference）する。
• §820.10(a)――製造業者は、ISO 13485の適用される要求事項に適合する品質マネジメントシステムを文書化しなければならない。
• §820.10(c)――クラスII・クラスIII、および所定のクラスIの機器の製造業者は、ISO 13485の「7.3 設計開発」およびその細分箇条の要求事項に適合しなければならない。

そして重要なのは、旧QSRの設計管理条文であった §820.30（Design controls）は、条文そのものが消滅したという点である。現行のPart 820を確認すると、Subpart B の該当箇所は次のようになっている。

適用対象――すべての機器に設計管理が要求されるわけではない

設計管理（ISO 13485 7.3）の適用範囲は、§820.10(c) に列挙されている。旧§820.30(a) の範囲がそのまま引き継がれた。

なお、ISO 13485 自体は原則としてすべての機器に 7.3 の適用を求めるが、FDAは最終規則前文で「ISO 13485 の箇条1 は、規制当局が設計開発要求事項からの除外を設け得ることを認め、製造業者に対して除外の正当化を文書化するよう求めている。§820.10(c) はこれと整合している」と説明している。適用除外と非適用の区別については 適用除外と非適用の違い を参照されたい。

日本――QMS省令 第30条〜第36条の2

日本では、医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令（平成16年厚生労働省令第169号、いわゆるQMS省令）が設計管理を定めている。2021年3月26日公布の改正により ISO 13485:2016 との整合が図られ、第30条から第36条の2までの9か条が設計開発の章を構成している。

QMS省令 第30条第1項は、次のように定める。

この一文が、設計管理の出発点である。「良い設計をせよ」ではなく「設計開発のための手順を文書化せよ」と書かれている点に、設計管理という制度の性格が凝縮されている。

用語の整理――「設計履歴ファイル」と「設計開発ファイル（DHF）」は同じものか

ここは実務で最も混乱が生じている箇所である。「設計開発ファイル（DHF）」という併記は、厳密には新旧の用語を混ぜてしまっている。整理すると次のようになる。

この整理はFDA自身が明示している。最終規則前文のComment 31（DMR・DHF・DHRという用語がISO 13485に存在しないが、これらの用語は本規則に残るのかという質問）に対し、FDAは次のように回答している。

つまりDHFという「用語」は廃止されたが、そこに保管すべき内容は 7.3.10 の設計開発ファイルへ引き継がれている。実務上ファイルを作り直す必要はないが、手順書や品質マニュアルの中で「DHF」という語をFDA要求の根拠として引いている場合は、参照先を ISO 13485 7.3.10 へ改める必要がある。この点はすでに ISO13485:2016とQMSRとの差異 および FDA医療機器査察の新時代 で詳しく扱っている。

規制が求める設計管理のステップ――9つか、10か

設計管理は一般に「9つのステップ」として紹介されることが多い。これは旧QSR §820.30 の (b)〜(j) の9項に対応しており、決して誤りではない。ただし現行の ISO 13485:2016 では 7.3.1 から 7.3.10 までの10項で構成されている。9項の説明は、冒頭の「7.3.1 一般（手順を文書化すること）」が落ちているのである。

そして「設計管理のための手順を文書化する」という 7.3.1 こそ、設計管理の起点である。QMS省令が第30条第1項でまず手順の文書化を命じているのと同じ構造だ。したがって本稿では10のステップとして整理する。

【対応表】ISO 13485:2016 7.3 × QMS省令 × 旧QSR § 820.30 × 主な成果物

各ステップの実務ポイント

1. 一般――手順の文書化（7.3.1／第30条第1項）

設計開発のための手順を文書化する。これが出発点である。手順書がなければ、以降のすべての活動は「たまたまそうした」に過ぎず、体系的な管理とは認められない。

2. 設計開発計画（7.3.2／第30条第2項〜第4項）

プロジェクトの開始時に、設計開発をどのように進めるかの計画を文書化する。この計画書は、単なる形式的な文書ではなく、実際の活動の指針となる重要なものである。QMS省令 第30条第4項は、計画の策定において次の6つを文書化するよう求めている。

1. 設計開発の段階どの段階に区切って進めるか。
2. 各段階における適切な照査どの段階でデザインレビューを行うか。
3. 各段階における適切な検証、バリデーション及び設計移管業務条文は同項第3号のかっこ書きで設計移管業務を「設計開発からの工程出力情報について、あらかじめ、実際の製造に見合うものであるかどうかについて検証した上で、製造工程に係る仕様とする業務」と定義している。
4. 設計開発に係る部門又は構成員の責任及び権限誰が何を決めるのか。
5. 工程入力情報から工程出力情報への追跡可能性を確保する方法いわゆるトレーサビリティマトリクスを指す。
6. 設計開発に必要な資源人・設備・予算。

また第30条第3項は、計画書を文書化し保管するとともに、変更の必要が生じた場合には設計開発の進行に応じて更新しなければならないと定めている。この「更新義務」が後述の「計画と実際の乖離」の論点に直結する。

3. 設計インプット（7.3.3／第31条）

顧客要求、法規制要求、安全性要求など、設計に必要な入力情報を明確に定義し、文書化する。QMS省令 第31条第1項は、明確にすべき入力情報として、意図した用途に応じた機能・性能・使用性・安全性に係る製品要求事項、法令の規定等に基づく要求事項、リスクマネジメントに係る工程出力情報、従前の類似設計から得られた適用可能な要求事項、その他必須の要求事項を挙げる。そのうえで第2項でこれらの妥当性を照査し承認すること、第3項で要求事項が漏れなく、不明確ではなく、かつ、互いに相反することがないようにすることを求めている。

FDAの教育資料は「携帯可能（Portable）」という要求を例に挙げている。重量要求を掘り下げた結果「3 lb ± 1 kg」という単位が食い違った矛盾する要求が見つかり、これを「3 lb ± 1 lb」に是正した、という例である。「互いに相反することがないように」とは、こうした地味な作業を指す。

4. 設計アウトプット（7.3.4／第32条）

設計インプットに基づいて作成された図面、仕様書、手順書などの設計成果物を指す。QMS省令 第32条第1項は、工程出力情報が、①入力情報に係る要求事項に適合すること、②購買・製造・サービス提供のために適切な情報を提供するものであること、③出荷可否判定基準を含むか、または参照できるものであること、④製品の安全かつ適正な使用又は操作に不可欠な当該製品の特性を規定していること、の4点に適合させるよう求める。さらに第3項で次の段階に進む前の承認を、第4項で記録の作成・保管を義務づけている。

5. デザインレビュー（7.3.5／第33条）

設計開発の各段階で、計画通りに進んでいるか、要求事項を満たしているかを体系的に評価する。QMS省令 第33条第2項は、参加者として「当該設計開発段階に関連する部門の代表者」および「当該設計開発に係る専門家」を求め、第3項で結果および所要の措置の記録（対象設計・参加者・実施日を含む）の作成・保管を求めている。

6. 設計検証（7.3.6／第34条）

設計アウトプットが設計インプットの要求事項を満たしているかを確認する活動である。QMS省令 第34条第2項は、検証計画に方法（統計学的方法を用いる場合は検体の数の設定の根拠を含む）および判定基準を含めて文書化することを求める。第3項は、他の機械器具等と一体的に使用または操作される医療機器等については、その一体的な状態を維持したまま検証を実施することを求めている。

7. 設計バリデーション（7.3.7／第35条）

製品が実際の使用環境において意図した用途を満たすことを確認する活動である。QMS省令 第35条は9項からなる長い条文で、実務上とくに重要なのは次の各項である。

• 第3項――製品を代表するものについてバリデーションを実施すること。
• 第4項――初回の製造に係る一群の医療機器等およびロット（これらと同等のものを含む）から代表製品を選択し、その選択の根拠の記録を作成・保管すること。
• 第5項――薬機法第23条の2の5第3項等に該当する医療機器等については、臨床試験等の資料の収集・作成をバリデーションの一部として実施すること。
• 第8項――製品の出荷を行うに当たり、あらかじめバリデーションを完了すること。ただし使用時の組立てまたは設置の後でなければバリデーションを行えない場合は、製品受領者への受渡しまでに行うこと。

8. 設計移管（7.3.8／第35条の2）

設計部門から製造部門へ、製品を作るための情報を適切に引き継ぐプロセスである。QMS省令 第35条の2 第1項は、手順に次の2点を含めるよう求めている。

• 製造工程に係る仕様を確定する前に、設計開発からの工程出力情報が実際の製造に見合うものであるかを適切に検証していることを確認すること。
• その製造工程を出ることによって適合製品を適切に製造できることを確認すること。

そして第2項で、設計移管業務を行った場合の結果および結論の記録・保管を求めている。設計移管は「図面を渡す」ことではなく、「その図面どおりに量産できることを確かめる」工程である。

9. 設計変更管理（7.3.9／第36条）

設計変更が発生した際の承認プロセスや影響評価を管理する。QMS省令 第36条は、第2項で変更が機能・性能・安全性・使用性および法令の規定等の適合性に及ぼす影響の有無および程度を検証すること、第4項で変更の実施前にあらかじめ照査・検証・バリデーション・承認を行うこと（バリデーションを実施しないことに合理的な理由があるときを除く）を求める。さらに第5項は、照査の範囲に構成部品等、工程内の製品、既に引き渡された製品、リスクマネジメントに係る工程入出力情報、製品実現に係る工程への影響評価を含めるよう明記している。

10. 設計開発ファイル（7.3.10／第36条の2）

設計開発の全記録を体系的に保管する。QMS省令 第36条の2 は次のとおりである。

「製品又は類似製品グループごと」という単位の指定に注意されたい。1製品1ファイルに固定する必要はないが、逆に全製品を1つのファイルにまとめることも想定されていない。

「設計検証」と「設計バリデーション」の違い

設計管理のなかで最も取り違えの多い2語である。定義そのものは単純であるにもかかわらず、実務では検証で済ませてバリデーションを省いたり、逆にバリデーションと称して仕様との照合を行っていたりする例が後を絶たない。

計画と実際の乖離――柔軟性と規律のバランス

設計開発計画書の重要なポイントの1つは、計画と実際の活動が一致していなければならないという点である。プロジェクトを進める中で、当初の計画通りに進まないことは珍しくない。技術的な課題が発見されたり、市場要求が変化したりすることもある。

このような場合、重要なのは計画書を改訂することである。計画と実態が乖離したまま進めることは、規制上の問題となる。逆に言えば、適切に計画を更新し続ければ、柔軟にプロジェクトを進めることができる。QMS省令 第30条第3項が「設計開発計画を変更する必要がある場合には、設計開発の進行に応じ更新しなければならない」と定めているのは、まさにこの趣旨である。

たとえば――これは説明のための架空の例だが――当初3回を予定していたデザインレビューを、技術的な課題が見つかったために5回に増やす必要が生じたとする。この場合、計画書を改訂して5回に変更し、その変更を承認・記録することで、規制要求を満たしながら適切な開発を進めることができる。逆に、計画書には3回と書いたまま実際には5回開催した（あるいは2回しか開催しなかった）という状態が、最も避けるべき姿である。問われているのは回数の多寡ではなく、計画と実態の一致である。

設計開発ファイル（旧DHF）が持つ実務的価値

設計開発ファイル（ISO 13485 7.3.10／QMS省令 第36条の2「設計開発に係る記録簿」）は、製品の設計に関するすべての記録を保管したものである。これには以下のような情報が含まれる。

• 設計開発計画書とその改訂履歴
• 設計インプット・アウトプットの文書
• デザインレビューの議事録
• 検証・バリデーションの報告書
• 設計変更の記録
• 設計開発において参照した資料に係る記録

その存在は、単なる規制対応以上の実務的価値を持っている。製品が市場で故障した場合、その原因究明には設計開発ファイルが不可欠である。過去の設計変更履歴を辿ることで、どの時点からその問題が存在していた可能性があるか、どのロット番号の製品が影響を受けるかを特定できる。

たとえば、ある部品の仕様を3年前に変更していたとする。その変更履歴が設計開発ファイルに記録されていれば、現在発生している不具合がその変更に起因する可能性を速やかに検証できる。影響を受ける製品の範囲も正確に特定できるため、必要最小限の回収や修正で済む。

実践的な導入アプローチ

1. ステップ1：現状の把握まず、自社の設計開発プロセスを可視化することから始める。どのような活動が行われているか、どのような文書が作成されているかを棚卸しする。ここで重要なのは、手順書に書かれている姿ではなく、実際に行われている姿を書き出すことである。
2. ステップ2：ギャップ分析現状のプロセスと規制要求事項を比較し、不足している要素を特定する。本稿の対応表を、ISO 13485 7.3.1〜7.3.10 の10行のチェックリストとして使うとよい。各行について「手順書があるか」「記録が残っているか」「両者が一致しているか」の3点を確認する。
3. ステップ3：段階的な導入すべてを一度に完璧にしようとせず、重要度の高い要素から段階的に導入していく。たとえば、まず設計開発計画書とデザインレビューの仕組みを確立し、次に検証・バリデーションのプロセスを整備するといった具合である。
4. ステップ4：継続的な改善設計管理の仕組みは、一度構築すれば終わりではない。実際に運用する中で見えてくる課題を継続的に改善していくことが重要である。マネジメントレビューを形骸化させずに運用できるかが分かれ目になる。この点は マネジメントレビューのインテグリティ を参照されたい。

デジタル化とAI――規制側の現在地

設計開発ファイルの電子化

従来、設計開発ファイルは紙の文書として管理されることが多かったが、文書管理システムやPLM（Product Lifecycle Management）システムを活用する例が増えている。電子化により、設計変更の履歴管理や文書の検索性が向上し得る。

AIと設計開発――「近づいている」ではなく、すでに規制の議題である

元記事は「AIやエージェント型システムが設計開発に参画する時代が近づいている」としていたが、規制側の現在地を確認すると、AIはすでに医療機器規制の具体的な議題になっている。確認できた一次情報は次のとおりである。

したがって、AIが設計開発に関与する場合に問われるのは「AIを使ってよいか」ではなく、「AIが生成した設計案を、誰が、どの根拠で、どう照査し、どう検証・バリデーションしたか」を記録として示せるかである。設計管理の枠組み自体は変わらず、むしろその厳格な適用が要求される。

技術の進化とともに、設計開発の手法は今後も変わっていくだろう。しかし、それをどのように管理し、品質を保証するかという設計管理の本質的な重要性は変わらない。むしろ、AIなどの新技術が導入される中で、その重要性はさらに高まっていくと考えられる。設計管理を単なる規制対応の負担と捉えるのではなく、製品品質の向上と効率的な開発を実現するための有効なツールとして活用することが肝要である。適切な設計管理の仕組みは、故障対応の迅速化、開発プロセスの可視化、組織的な知識の蓄積など、多くの実務的価値をもたらす。