なぜ設計履歴ファイル(DHF)が必要なのか

医療機器の開発現場では「設計履歴ファイル（Design History File：DHF）」という言葉が長らく使われてきた。ところが 2026年2月2日に施行された QMSR（Quality Management System Regulation）によって、DHF という用語は 21 CFR Part 820 の条文から姿を消した。では DHF はもう不要になったのか。答えは明確に「否」である。用語は消えたが、要求は残った。本稿では、DHF がなぜ不可欠なのかという実務的な意義を、QSR 時代・QMSR 以後・QMS省令・欧州 MDR の4つの制度を突き合わせながら整理し、あわせて元記事に欠けていた「いつまで保管するのか」という論点を補う。

1. 設計履歴ファイル（DHF）とは何だったのか

1-1. QSR における定義と要求

DHF は、米国 FDA の医療機器品質システム規則（QSR：Quality System Regulation、21 CFR Part 820）に置かれていた記録類型である。2026年2月1日まで有効だった条文では、定義と要求が次のように書かれていた。

ここで押さえておきたいのは、DHF が「新たに作る文書」ではなく「集める仕組み」だったという点である。条文は「contain or reference（含むか、または参照する）」と書いている。つまり設計仕様書や試験報告書を物理的に一箇所に綴じ込む必要はなく、どこに何があるかを辿れる索引として機能していればよい。この「含むか参照するか」という構造は、後述する ISO 13485 の設計・開発ファイルにもそのまま引き継がれている。

1-2. QSR の設計管理は、随所で「DHF に記録せよ」と命じていた

旧 §820.30 は (a) 総則から (j) DHF まで10の項からなり、そのうち3つの項が明示的に「DHF に文書化する」ことを求めていた。

設計管理プロセスそのもの（設計開発計画、インプット、アウトプット、照査、検証、バリデーション、移管、変更）の全体像については、姉妹記事「設計管理と設計開発の違いとは」で扱っている。本稿はその結果として残る記録の束――DHF／設計・開発ファイルそのものに焦点を絞る。

2. QMSR 施行で何が変わったのか――DHF という用語は条文から消えた

2-1. まず2つの日付を区別する

QMSR をめぐる記述で最も多い混乱が、公布日と施行日の取り違えである。

2-2. 新しい Part 820 に §820.30 は存在しない

QMSR は Part 820 の構造そのものを組み替えた。最終規則の前文（Comment 15 への回答）は、Subpart C 〜 Subpart O を削除・留保（removed and reserved）したと述べている。現行の Part 820 に残っている条は次のとおりである。

すなわち、§820.30 も §820.180 も §820.181 も §820.184 も、現行の 21 CFR Part 820 には存在しない。現行条文の全文を検索しても「design history」という語は一度も出てこない。「21 CFR 820.30(j) において DHF が要求されている」という説明は、2026年2月2日をもって現在形では成立しなくなったのである。

2-3. 前文 Comment 31――FDA は DMR・DHF・DHR をまとめて廃止した

これは推測ではない。最終規則の前文（89 FR 7507〜7508）の Comment 31 に対する FDA の回答が、正面からこの点を扱っている。

あわせて FDA は、DHR に相当する内容は ISO 13485 の 7.5.1 における医療機器記録／バッチ記録に、DMR に相当する内容は 4.2.3 の医療機器ファイル（Medical Device File：MDF）に、それぞれ移ると説明している。設計段階から出てくる最終的な設計アウトプットが MDF の出発点になる、という関係も同じ回答の中で述べられている。

2-4. 社内文書を「設計・開発ファイル」に改称する義務はあるか

結論から言えば、QMSR は事業者に社内文書の改称を命じていない。現行 §820.1 から §820.45 までのどこにも、記録や手順書の名称を規定する条文はない。前文 Comment 31 の回答も、FDA が規則本文から用語を削除したと述べているだけであり、事業者側の文書名には言及していない。同じ回答の末尾で FDA は、各組織が自らの要求事項に即した QMS を実装することになると述べており、名称よりも記録が要求を満たしているかが問われるという立て付けになっている。

ただし実務上は、次の点を織り込んでおくのが安全である。

1. 査察官が使う用語は変わったFDA の査察運用文書である Compliance Program 7382.850（2026年2月2日実施）では、Design and Development という QMS Area の中に「Design and Development Files」というエレメントが置かれている。「DHF」というエレメント名は存在しない。査察官の質問は新しい用語で来る。
2. 対応関係を説明できるようにしておく社内で「DHF」の名称を継続して使うのであれば、品質マニュアルや手順書のどこかで「本手順書における DHF は、ISO 13485 7.3.10 にいう設計・開発ファイルを指す」と明示的に紐づけておく。これは改称よりはるかに軽い作業で、査察時の説明コストを大きく下げる。
3. 改称するなら中途半端にしない手順書だけ改称して様式・記録の表題・システムのフォルダ名が旧称のまま、という状態が最も混乱を招く。改称する場合は文書体系全体を一巡させる前提で計画する。

QMSR と ISO 13485:2016 の条項レベルの差分については「ISO13485:2016とQMSRとの差異」で詳述している（第6節が DMR・DHF・DHR の用語廃止を扱う）。査察手法そのものの変化については「FDA医療機器査察の新時代――QSITからの転換」を参照されたい。

3. 【対応表】DHF に相当するものは、4つの制度でどう呼ばれるか

ここが本稿の要である。同じ実体を指すのに、制度ごとに名前も条番号も異なる。名前を追いかけるのではなく、記録の中身で対応づけるのが正しい読み方である。

QMS省令 第36条の2 の条文

旧 QSR の DHF が「機器の型式ごと」であったのに対し、QMS省令 第36条の2 は「製品又は類似製品グループごと」と単位を定めている点に注意したい。ISO 13485 7.3.10 も同様に類似製品グループ単位を許容する立て付けであり、この点は旧 QSR より運用しやすい。なお、設計開発を「非適用」としている製造販売業者の扱いについては「適用除外と非適用の違い」を参照されたい。

欧州 MDR――Article 10(4) と Annex II

元記事は「Article 10(4) および Annex II・III で要求される技術文書」と書いていた。この条番号は原文で確認したところ正しい。Annex II（技術文書）の第3節「DESIGN AND MANUFACTURING INFORMATION」は、その (a) で「当該機器に適用された設計段階を理解できるようにする情報」を求めており、まさに DHF が担ってきた機能に対応する。Annex III は市販後調査（PMS）に関する技術文書である。

さらに実務上見落とされやすいのが Annex II 第1.2節「Reference to previous and similar generations of the device」である。ここでは、製造業者が製造した従前の世代の機器の概要を技術文書に含めることが求められている。MDR は、過去のリビジョンの情報を保持していることを制度として前提にしているのである。

4. 「時間軸で変化する製品」という現実

製品開発の現場では、同一品目であっても複数の異なるリビジョンが市場に共存することが一般的である。次は説明のための架空の例である。

これらはすべて同じ製品名で市場に流通しているが、内部的には設計が異なっている。性能向上のための部品変更、コスト削減のための材料変更、規制対応のための仕様変更、供給停止部品の代替品への切替えなど、さまざまな理由で設計は進化していく。

この「共存」こそが、設計履歴ファイルが必要とされる根本理由である。もし製品が一度きりの設計で永久に変わらないのであれば、最新版の設計文書だけを持っていれば足りる。実際にはそうならないから、どの個体がどのリビジョンで、そのリビジョンの設計はどうだったのかを後から辿れる仕組みが要る。

5. なぜ過去の設計情報が必要なのか

5-1. 苦情対応における原因究明

顧客から製品の不具合に関する苦情が寄せられた場合、その製品がいつ製造されたどのリビジョンなのかを特定し、当時の設計情報を参照する必要がある。

例えば、3年前に出荷されたバージョン2.0の製品に不具合が発生した場合、現在のバージョン3.0の設計文書を見ても原因は究明できない。バージョン2.0当時の回路図、部品リスト、製造手順書などが必要である。もし過去の設計情報が保管されていなければ、原因究明は極めて困難になり、適切な対策も立てられない。

制度側もこれを前提にしている。QMSR の §820.35(a)（苦情の記録）は、ISO 13485 8.2.2 に上乗せする形で、調査対象となる苦情について機器の名称、苦情の受領日、UDI／UPC その他の機器識別、苦情申立者の氏名・住所・電話番号、苦情の内容と詳細、実施した修正または是正処置、申立者への回答を記録することを求めている。UDI が記録項目として明示されているのは、まさに「どの個体か」を特定させるためである。日本では QMS省令 第55条の2（苦情処理）が対応する。

5-2. 修理・メンテナンス（サービス）の実施

製品が修理のために返品された際も、同様の課題が生じる。修理担当者は、その製品がどのリビジョンで製造されたかを確認し、該当する設計文書や部品情報を参照しなければならない。

最新版の部品で修理しようとしても、互換性がない場合や、逆に性能を損なう場合がある。当時の設計情報があってこそ、適切な修理が可能になる。

QMSR の §820.35(b)（サービス活動の記録）は、ISO 13485 7.5.4 を遵守するうえで、サービスを行った機器の名称、UDI／UPC その他の機器識別、サービス実施日、サービスを実施した個人、実施したサービスの内容、試験および検査のデータを最低限記録することを求めている。ここでも UDI が明示されている。

5-3. ソフトウェアにおける特有の課題

ソフトウェアを含む製品では、設計・開発ファイルの重要性はさらに高まる。ソフトウェアは物理的な製品と比べてリビジョンの変更頻度が高く、バグ修正や機能追加により頻繁にバージョンアップが行われるためである。

例えば、ある医療機器のソフトウェアで重大なバグが発見されたとする。このバグが現在のバージョン3.5だけでなく、過去のバージョン3.0から3.4にも存在する可能性がある。しかし、当時のソースコードが保管されていなければ、次のような問題が発生する。

1. バグの影響範囲が特定できないどのバージョンからバグが存在するのか、どの顧客が影響を受けるのかが分からない。影響範囲が確定できなければ、市販後の安全対策（回収の要否判断、顧客への通知範囲）を決められない。
2. パッチ適用が不可能になる各バージョンのソースコードがなければ、そのバージョンに対するバグフィックスやセキュリティパッチを作成できない。現在のコードに修正を加えても、過去のバージョンを使用している顧客には対応できない。「最新版にアップデートしてください」で済まない機器――院内ネットワークでの検証が必要な機器、組込みで現地アップデート手段のない機器――では、これは致命的になる。
3. 検証作業の再現性がない当時どのようなテストを行い、どのような条件で検証したのかが不明では、修正後の妥当性確認も適切に行えない。テストコード・テストデータ・実行環境の情報まで含めて設計・開発ファイルから辿れる必要がある。

6. 何を保管するのか

各リビジョンごとに、少なくとも次のような設計管理上の記録を、設計・開発ファイルの中に含めるか、そこから参照できる形で体系的に保管する必要がある。

QMS省令 第36条の2 が「設計開発において参照した資料」まで記録簿の対象に含めている点は見落とされやすい。適用した規格の版、参照した文献、他社品の調査結果なども、設計判断の根拠として辿れる状態にしておく必要がある。

7. いつまで保管するのか――保存期間という論点

「何を保管するか」は論じられても、「いつまで保管するか」は抜け落ちがちである。しかし前節までで見たとおり、市場に複数リビジョンが共存する以上、保存期間の設計を誤れば、まだ使われている製品の設計情報を捨ててしまうことになる。

7-1. 4つの制度の保存期間要求

7-2. 「最も古いリビジョンの耐用期間」が効いてくる

ここで第4節の「時間軸で変化する製品」と結びつく。保存期間の起算点と長さはリビジョンごとに異なる。

• 旧 QSR も ISO 13485 も、保存期間を機器の寿命（耐用期間）に紐づけている。したがってまだ市場で稼働している最も古いリビジョンの耐用期間が終わるまで、そのリビジョンの設計記録を捨てられない。
• QMS省令 第68条は「作成の日から」を起算点とし、有効期間＋1年との比較で長い方を採る構造になっている。長期使用される特定保守管理医療機器では15年が下限となる。
• MDR Article 10(8) は「最後の機器が上市された後」を起算点とする。製造・上市を続けている限り起算点が動き続けるため、実際の保持年数は10年（埋込み型は15年）を大きく上回ることがある。

制度ごとに起算点が違う（出荷日／作成日／最後の上市日）ことが、複数地域に製品を出している製造販売業者にとって最大の実務課題になる。最も長くなる要求に合わせて一本化するのが定石である。複数地域の要求を一度の監査で束ねる仕組みについては「MDSAPとは何か」も参考になる。

8. 電子的に保持する場合に何が起きるか

8-1. 「保存した」と「読める」は別のことである

設計・開発ファイルの保存期間は10年、15年、場合によってはそれ以上に及ぶ。この時間スケールでは、電子的に保存したという事実だけでは記録の可読性を保証しない。媒体の劣化、読取装置の陳腐化、ファイル形式の互換性喪失、電子署名の検証基盤の失効――いずれも15年という単位では現実に起こり得る。

この論点は「電子記録の長期保存が困難な理由」で詳しく扱っている。設計・開発ファイルはまさにこの困難に最も長くさらされる記録であり、保存戦略を設計段階で決めておく必要がある。

8-2. バージョン管理システムの活用と、その留保

特にソフトウェア開発においては、バージョン管理システム（Git、Subversion など）の活用が事実上不可欠である。各コミットに適切なタグを付け、リリースごとにブランチを管理することで、任意の時点のソースコードを確実に復元できる体制を整える。ハードウェアにおいても、図面管理システムや PLM（製品ライフサイクル管理）システムを活用し、各リビジョンの設計情報を確実に保管することが求められる。

8-3. 完全性と検索性は法令上の要求である

QMS省令 第9条第2項は、記録の識別、保管、セキュリティ確保（漏えい・滅失・毀損の防止その他の安全管理）、完全性の確保（記録が正確であり、作成された時点から不適切な改変がない状態を保つこと）、検索、保管期間、廃棄についての所要の管理方法に関する手順を文書化することを求めている。さらに第9条第4項は、記録を「読みやすく容易に内容を把握することができ、かつ、検索することができるようにしなければならない」と定めている。

検索できることは、努力目標ではなく条文上の要求である。欧州 MDR も同様で、Annex II の冒頭は技術文書を「明確に、体系的に、容易に検索可能で（readily searchable）、曖昧さのない形で」提示することを求めている。

9. アクセスと検索性をどう確保するか

保管した情報は、必要な時に迅速にアクセスできなければ意味がない。製造番号・ロット番号・UDI から該当するリビジョンを特定し、関連する設計文書を検索できる仕組みを構築することが重要である。実装にあたっての要点を整理する。

1. 個体からリビジョンへの対応表を持つ製造記録（DHR 相当／医療機器記録）と設計・開発ファイルを、リビジョン識別子で結線する。UDI-DI はモデルやバージョンの識別に用いられるため、これを鍵にできる設計にしておくと後が楽になる。
2. 索引そのものを文書として管理するISO 13485 7.3.10 も QMS省令 第36条の2 も、記録の実体をどこに置くかは問うていない。問われるのは「含むかまたは参照する」索引が維持されているかである。索引そのものを版管理対象の品質管理監督文書として扱う。
3. 参照先が消えない仕組みにする索引がファイルサーバのパスやチケットの URL を指しているだけだと、システム移行やフォルダ再編で一斉にリンク切れを起こす。文書番号など、格納場所に依存しない識別子で参照する。
4. 「取り出せること」を定期的に試す保存してあることと、査察の場で短時間のうちに提示できることは別である。内部監査の際に、過去リビジョンの記録を実際に取り出す演習を組み込む。
5. 廃棄も手順化する保管期限を過ぎた記録の廃棄も第9条第2項の管理対象である。期限が来たから捨てるのではなく、当該リビジョンが市場から退いたかを確認したうえで判断する。

10. 査察・監査でどう見られるか

10-1. FDA――6つの QMS Areas の1つが Design and Development

FDA は 2026年2月2日をもって QSIT（Quality System Inspection Technique）の運用を終了し、コンプライアンスプログラム CP 7382.850「Inspection of Medical Device Manufacturers」に基づくリスクベース査察へ移行した。CP は QMSR の要求事項を 6つの QMS Areas と 4つの OAFRs（Other Applicable FDA Requirements）に整理しており、Design and Development はその QMS Area の1つである。

そして Design and Development エリアのエレメントの1つが「Design and Development Files」である。つまり設計・開発ファイルは、査察の単位として明示的に位置づけられている。「DHF」というエレメント名はもはや存在しない。査察手法の詳細は「FDA医療機器査察の新時代――QSITからの転換」で扱っている。

10-2. 施行前に作られた記録はどう扱われるのか

設計・開発ファイルは性質上、QMSR 施行日（2026年2月2日）より前に作成された記録を大量に含む。これらが査察でどう扱われるのかは、実務上きわめて重要な論点である。この点については「なぜ事後法が適用されたのか――QMSR施行前記録の査察」で詳しく論じている。

10-3. 動画で学ぶ

11. まとめ

設計履歴ファイルは、製品のライフサイクル全体を通じて、品質保証と顧客安全を支える基盤である。市場には異なるリビジョンの製品が共存し続けるという現実を踏まえれば、過去の設計情報を確実に保管し、必要な時に参照できる体制を整えることは、製造業者としての基本的な責任といえる。

特にソフトウェアの頻繁なアップデートが当たり前となった現代においては、その重要性はさらに増している。バグフィックスやセキュリティパッチの適用、原因究明、トレーサビリティの確保――これらすべてが、適切な設計・開発ファイルの管理によって初めて実現可能になる。

設計・開発ファイルの整備は、一見すると地味で手間のかかる作業かもしれない。しかし、それは将来の問題を未然に防ぎ、顧客の信頼を守るための投資である。今日の丁寧な記録が、明日のトラブルから組織を救う――その認識を持って取り組むことが求められる。

そして2026年以降は、これに用語の移行という論点が加わった。条文から「DHF」が消えたことを「不要になった」と読み違えれば、記録体系そのものを緩めてしまいかねない。消えたのは名前であって、要求ではない。