【連載】ドキュメントは敵か味方か？規制産業の「文書主義」の正体（第4回）

ソフトウェア開発の現場で、ドキュメントはしばしば嫌われ者です。その象徴としてよく引用されるのが、2001年のアジャイルソフトウェア開発宣言にある「包括的なドキュメントよりも動くソフトウェアを」という一節です。

しかし宣言には、見落とされがちな但し書きが続きます。「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」。つまり、包括的なドキュメントに価値が無いとは一言も言っていません。優先順位の話をしているだけです。

医療機器業界も、この二項対立に長く向き合ってきました。AAMI TIR45（Guidance on the use of agile practices in the development of medical device software：2012年発行、2023年改訂）は、アジャイル開発の実践を IEC 62304（Medical device software - Software life cycle processes）、ISO 13485（Medical devices — Quality management systems — Requirements for regulatory purposes）、ISO 14971（Medical devices — Application of risk management to medical devices）、21 CFR Part 820.30 （FDA　Design controls.）の要求とどう対応づけるかを整理したガイダンスです。業界が議論してきたのは「アジャイルか文書か」ではなく、「アジャイルで開発しながら、必要な文書をどう作るか」でした。

では、その「必要な文書」とは何なのでしょうか。

規制適合の世界には、ひとつの原則があります。評価されるのは「実施したこと」ではなく、「実施したと第三者が確認できること」です。厳しく聞こえますが、外から確かめられる形になっていない活動は、存在しなかったのと同じ扱いになる、というだけの話です。

ここで重要なのが、ISO 13485:2016 が「文書（document）」と「記録（record）」を明確に区別していることです。

文書とは、これから何をするかを定めた規範です。方針、手順書、開発計画、仕様書がこれにあたります。4.2.4（文書の管理）は、文書が発行前に適切性をレビューされ承認されること、最新版が使用の場で入手できることを要求しています。

記録とは、実際に何が起きたかを示す証拠です。テスト記録、レビュー記録、承認記録がこれにあたります。4.2.5（記録の管理）は、記録が読みやすく、識別可能で、検索可能な状態に保たれること、そして保管期間を定めることを要求しています。（図表1）

IEC 62304 の 5.1 ソフトウェア開発計画は、前者の典型です。開発を始める前に、何を、どの順序で、どのような判定基準で行うかを宣言します。「後からつじつまを合わせるための文書」ではなく、「これから何をするかの約束」ための文書です。この時間の向きを取り違えると、全ての文書が後追いの事務作業になってしまいます。

ドキュメントを味方にする最短の方法は、読み手が何を確認しに来るのかを知ることです。監査は粗探しではありません。限られた時間の中でサンプリングを行い、「品質マネジメントシステムが機能している」という仮説を検証する作業です。

監査者が確認したいことは、突き詰めれば三つです。

第一に、決めてあるか。計画や手順が存在し、承認され、最新の状態にあるか。

第二に、決めたとおりにやったか。記録が計画や手順と一致しているか。

第三に、その結果は妥当と言えるか。判断の根拠が示されているか。

経験のある監査者ほど、最初に開発計画書と変更履歴、そして逸脱の扱いを見ます。第一の問いと第二の問いのズレが最も表れやすい場所だからです。ここで誤解されがちなのですが、計画から逸脱したこと自体は、通常それほど重い問題になりません。逸脱が記録されず、影響も評価されていないことが問題になるのです。

前回の「主張・論拠・証拠」の構造に重ねると、第一の問いが論拠の枠組み、第二の問いが証拠、第三の問いが証拠と主張を結ぶ推論にあたります。監査者も審査官も、文書の分厚さではなく、この三つがつながっているかを見ています。

この視点を持つと、ドキュメントは「読者」を想定して書けるようになります。誰が、何を確認するために、どの順番で読むのか。それを意識するだけで、書き方は変わります。どこに何が書かれているかが分かる構成にする。結論だけでなく、そう判断した根拠を書く。関連文書への参照を明示する。変更した時は、変更内容ではなく変更理由を残す。逆に読者を想定しない文書は、「網羅的だが、何も確認できない」ものになりがちです。

文書主義が本当に有害になる場面は、実際にあります。典型的なのは次の三つです。

一つ目は、監査のためだけに書かれた文書です。実務では別のやり方をしているのに、手順書だけが規格の文言をなぞって存在している。監査で最も重い指摘は「文書がない」ことではなく、「文書と実態が違う」ことです。前者は不備ですが、後者は品質マネジメントシステムが機能していない証拠とみなされます。

二つ目は、更新されない設計書です。実装と食い違った設計書は、開発者から信用されなくなり、参照されなくなり、その結果さらに更新されなくなります。この負の循環に入った文書は、維持コストを払い続けるだけの負債です。

三つ目は、全てを同じ深さで書こうとすることです。これは規格の意図ではありません。IEC 62304 は、医療機器ソフトウェアの障害が患者や操作者に与える危害の重大さに応じて定められるソフトウェア安全クラス（A：なし／B：軽微／C：重大）に応じて要求される作業と成果物を変えています。クラス A ではソフトウェアアーキテクチャ設計（5.3）や詳細設計（5.4）は要求されません。クラス B ではアーキテクチャをソフトウェアユニットに分割するところまで（5.4.1）が求められ、ユニットごとの詳細設計（5.4.2）とインターフェースの詳細設計（5.4.3）はクラス C にのみ要求されます。どのクラスにどの箇条が適用されるかは、附属書 A の表 A.1（Summary of requirements by software safety class）に整理されています。（図表2）

つまり規格は、「全てを書け」とは言っていません。リスクの大きさに応じて文書の深さを変えよ、と言っています。これは第2回で述べたリスクベースのテスト戦略とまったく同じ原理です。文書量を一律に増やすことは、規格適合ですらないのです。

ここまで規制と監査の話をしてきましたが、規制対応は結果であって、目的ではありません。よく設計されたドキュメントは、まず開発する側の役に立ちます。

第一に、組織の記憶になります。担当者が異動しても退職しても、「なぜこの設計にしたのか」が残ります。設計の意図が残っていないコードは、次に触る人にとってブラックボックスです。医療機器は10年、20年と使われ続けることも珍しくないからこそ、書いた本人がいなくなる前提で残しておく必要があります。

第二に、変更の判断が速くなります。要求とアーキテクチャとテストの対応が追える状態なら、変更の影響範囲を推測ではなく根拠で判断できます。トレーサビリティを「事務作業」だと思っている組織ほど、変更のたびに全体を再テストする羽目になります。

第三に、不具合発生時の初動が変わります。市販後に問題が発生した時、どこまでが想定内でどこからが想定外だったのかを切り分けられるかどうかで、対応の速度と精度がまったく違います。第1回で取り上げた Therac-25 の事例で深刻だったのは、バグそのものよりも、設計の前提と根拠が検証可能な形で残っていなかったことでした。

第四に、外部への説明材料になります。とくに SaMD（Software as a Medical Device）のスタートアップにとって、設計・開発の記録は、投資家、提携先、買収候補に対して「この製品はきちんと作られている」ことを示す唯一の材料となります。第1回で「ドキュメントは規制対応ではなく参入チケットだ」と書いたのは、この意味です。

規制側の枠組みも、この「残すこと」の目的に沿って整理が進んでいます。米国では、2024年2月2日に公布された QMSR（Quality Management System Regulation）が2026年2月2日に施行され、21 CFR Part 820 は ISO 13485:2016 を引用する形に再編されました。従来の設計履歴ファイル（DHF）、機器基準書（DMR）、機器履歴記録（DHR）といった用語は QMSR の条文には現れず、ISO 13485 の医療機器ファイル（4.2.3）や設計・開発ファイル（7.3.10）の枠組みに整理されています。呼び名は変わっても、求められていることは変わりません。設計の意思決定を、後から追える形で残すことです。

ここ数年で最も大きく変わったのは、文書を「書く」コストです。

要求仕様のドラフト作成、要求からテスト仕様への展開、トレーサビリティの対応づけ、レビュー記録の整理、規格の条項と自社文書とのギャップ分析。こうした作業は、生成AIの助けを借りて飛躍的に効率化できるようになりました。文書間の矛盾や欠落を洗い出す作業に至っては、人間より速く網羅的なことすらあります。「文書作成に時間を取られて開発が進まない」という長年の言い訳は、もはや通用しなくなりつつあります。

ただし、効率化されたのは「書く」作業であって、「残す」必要性ではありません。むしろ生成AIを使うほどに、工程の区切りで記録を確定させる意味は大きくなります。

理由は単純です。AIは開発の全工程を記憶していないからです。人間のチームであれば、半年前になぜその設計にしたのかを覚えている人が一人はいます。AIにあるのは、その時に渡された文脈だけです。前の工程で何を決めたかが文書として残っていなければ、次の工程のAIはそれを知らないまま作業を始めます。要求の背景を知らないままアーキテクチャを提案し、既知の不具合を知らないまま同じ設計を繰り返す。人の引き継ぎで起きる様々な問題が、より速く、より大量に起こります。

だからこそ、工程の区切りごとに、その工程のインプットとアウトプットを文書として確定させ、次工程の入力にする必要があります。IEC 62304 のソフトウェア開発プロセス（5.1〜5.8）が、計画、要求仕様、アーキテクチャ設計、詳細設計、ユニット実装・検証、結合試験、システム試験と段階を分け、それぞれに成果物を定めているのは、この「前工程の出力が次工程の入力になる」という構造を担保するためです。アジャイルの代表的なフレームワークであるSCRUMで開発するなら、その区切りはスプリントの終わりになります。AAMI TIR45 が反復の中で文書を段階的に成熟させる考え方を扱っているのも、文書化を後回しにするためではなく、区切りごとに整合を取るためです。

残すべきものは、AI時代でも変わりません。開発計画、要求仕様書、アーキテクチャ設計書、テスト計画、テストエビデンス、不具合レポート。ソフトウェア工学が長く必要としてきた成果物であり、規格がライフサイクルプロセスの中で求めてきたものです。これらが欠ければ、次の工程――人間であれAIであれ――の入力が欠落し、同じ問題を繰り返すことになります。

変わったのは、人間が担う部分です。ドキュメントを作る作業そのものは、AIに任せられるようになりました。任せられないことが二つあります。一つ目は、その文書が何のためにあり、誰が何を確認するために読むのかを定義してAIに伝えることです。二つ目は、出てきたものが自分たちの設計を正しく表しているかを見極めることです。この二つができる組織にとって、文書作成は初めて本当に効率的な作業になります。

人間に残る責任は、さらに三つあります。

第一に、内容の妥当性を判断する責任です。生成AIは「もっともらしい文書」を大量に作ります。規制文書において最も危険な失敗は、文書がないことではなく、根拠のない文書が整った体裁で存在することです。前節で述べた「文書と実態の乖離」を、これまでにない速度で生み出せてしまう点は自覚しておく必要があります。

第二に、レビューと承認です。ISO 13485 の 4.2.4 は、文書が発行前に適切性をレビューされ、承認されることを要求しています。誰がいつ何を作成し、誰が責任を持って承認したのか。この責任の所在は、人にしか置けません。生成AIが作ったものは、どこまでいってもドラフトです。

第三に、記録の完全性です。記録は改変されないことに価値があります。生成物を記録として扱うのであれば、その出どころと根拠が追える状態でなければなりません。

そして、文書の形そのものも変わりつつあります。2022年12月に FD&C 法（連邦食品・医薬品・化粧品法）へ追加された 524B 条は、サイバーデバイスの市販前申請にあたって SBOM（ソフトウェア部品表）の提出を求めています。SBOMは人間が読む読み物ではなく、機械可読なデータです。FDA の電子提出テンプレート eSTAR（electronic Submission Template And Resource）も同じ方向を向いています。IEC 81001-5-1（ヘルスソフトウェア及びヘルスITシステムの安全，有効性及びセキュリティ―第5-1部：セキュリティ―製品ライフサイクルにおけるアクティビティ）が求めるセキュリティのライフサイクル記録も、継続的に更新されるデータとして扱うほうが実態に合います。文書は「文章の束」から「構造化されたデータ」へ移りつつあり、生成AIはその移行を後押しします。（図表3）

ドキュメントが敵になるのは、それを「誰かに見せるため」に書いたときです。味方になるのは、「誰かが確認できるため」に書いた時です。

規制産業の文書主義は、文書を作ること自体を目的にしているわけではありません。人が入れ替わり、技術が変わり、製品が長期間使われ続ける前提の中で、「なぜそれで安全と言えるのか」を後から誰でも確認できるようにしておく。そのための仕組みです。監査者も、審査官も、そして数年後のあなた自身も、その読者です。（図表4）

生成AIによって、書くコストは下がりました。残っているのは、何を残すべきかを決める仕事と、それが正しいと判断する仕事です。それは、この連載が繰り返してきた問いと同じものです。

あなたは今、なんのためにそのドキュメントを書いていますか？

次回予告

第5回は「QAが開発の最後に置かれると、なぜ失敗するのか」をテーマに取り上げます。工程の最後にQAを置く体制がなぜ破綻するのか、医療機器開発における設計管理とQAの位置づけから解説します。

参考文献・規格

21 CFR Part 820 Quality Management System Regulation（2024年2月2日公布／2026年2月2日施行）
ISO 13485:2016 「医療機器―品質マネジメントシステム―規制目的のための要求事項」 4.2.3／4.2.4／4.2.5／7.3.10
IEC 62304:2006/AMD1:2015 「医療機器ソフトウェア―ソフトウェアライフサイクルプロセス」 5.1／5.3／5.4／附属書A（表A.1）
ISO 14971:2019 「医療機器―リスクマネジメントの医療機器への適用」
IEC 81001-5-1:2021 「ヘルスソフトウェア及びヘルスITシステムの安全、有効性及びセキュリティ―第5-1部：セキュリティ―アクティビティライフサイクル」
連邦食品・医薬品・化粧品法（FD&C法）第524B条 Ensuring Cybersecurity of Medical Devices（2022年12月追加）
FDA "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions"（2025年6月）
AAMI TIR45:2023 "Guidance on the use of agile practices in the development of medical device software"
アジャイルソフトウェア開発宣言（2001年）

参考サイト

ポータルサイト：https://www.medicalsoftwareconsulting.com/
規格解説動画：https://www.youtube.com/@MedicalSoftwareConsulting
医療機器ソフトウェア 規制・規格 知識データベース：https://watch.medicalsoftwareconsulting.com/