活用ガイド
医療機器の開発文書の不足を見つけにくい。コード根拠付きの要求・設計・SOUPの下書きとギャップレポートを作ります。担当者と専門家が漏れや未確定項目を確認します。
医療機器ソフトウェアの文書準備では、コードで確認できる事実と担当者の判断を分け、下書きと補完一覧を作ります。
こんな問題があるとき
実装が進んでも、要求・設計・外部ソフトウェア一覧にはコードとの繰り返し照合が必要です。参照の切れや製品・安全情報の不足があると、何から補完すべきか分かりにくくなります。
Specifyで解決する
- GitHubリポジトリと必要な文書スキルを接続し、コードにない製品情報を入力します。
- Specifyで要求・アーキテクチャ・SOUPの下書きを作り、コード根拠と文書間の参照を確認します。
- ギャップレポートで漏れと未確定項目を集め、担当者が補完します。提出前の規制・安全判断は専門家がレビューします。
どのような結果を得られますか？
| 必要な作業 | 作成する文書 | レビューする成果物 |
|---|---|---|
| 実装された機能と構造の文書化 | 要求仕様書 · アーキテクチャ設計書 | 要求ID、アーキテクチャ項目、根拠ファイルのパスを含むドラフト |
| 外部ソフトウェア構成要素の整理 | SOUPリスト | 識別情報、バージョン・使用箇所の根拠、追加確認事項 |
| 文書セットの不足箇所の確認 | 文書セット ギャップレポート | 必須節の欠落、未確定値、[GAP]、参照先のないIDをまとめたレポート |
先に確認する表記
| 表記 | 意味 |
|---|---|
| REQ-… / ARCH-… | 要求事項とアーキテクチャ項目のIDです。参照先が実在し、内容が一致しているか確認します。 |
| [unconfirmed] | ドラフトの提案値で、担当者がまだ確定していない状態です。承認済みの事実として扱わないでください。 |
| [GAP] | 根拠や入力が不足しており、確認・補完が必要な箇所です。この表示だけで規制適合性を判定するものではありません。 |
| SOUP | 出所や開発履歴が十分に分からないソフトウェア項目を確認する際の表記です。版と使用箇所を特定しても、安全影響の評価が完了したことにはなりません。 |
この例で使用するプロジェクト
MedRelay Demoは、合成機器パケットの入力検証、順序チェック、メモリ保持、CSVエクスポートを実装した小さな文書化用の例です。画面は、このコードを接続して実際のアプリで実行した結果です。実際の患者データや顧客プロジェクトは使用していません。
サンプルコードをダウンロードし、自分のGitHubリポジトリに配置すると、同じ流れを試せます。実際の医療機器や認証取得事例ではありません。安全クラスやリスク受容基準などは意図的に未確定のままにしています。
生成文書は提出前に規制・品質の専門家によるレビューが必要なドラフトです。コードで確認した実装の事実は、承認済みの要求事項や試験実施の証拠を代替しません。対象市場、意図する使用、安全クラス、適用規格と版は担当者が確認してください。
始める前に
- 文書化するGitHubリポジトリとブランチを連携します。最初はレビュー範囲が明確なリポジトリを選びます。
- ドキュメントプロジェクトを作成できる編集権限とプランを確認します。最新の利用条件は料金ページを参照してください。
- 製品の目的、ユーザー、使用環境、コードの範囲など、コードだけでは確定できない情報を用意します。
- 規格ライブラリの利用可否を確認します。規格検索を利用できない場合や条項が見つからない場合は、根拠不足として残してレビューします。
設定 → AIエージェント → プラグインでmedical-device-docsを探し、含まれるスキルを確認してインストールします。このパックには、認証プロファイルの収集、開発文書の作成、ギャップレビューを行う10種類のスキルが含まれます。
活用例1. 要求仕様書・設計書のドラフトを作成する
製品情報を先に確認する
まずプロジェクトを作成でリポジトリとブランチを選び、文書の種類として認証プロファイル インテークを選択して生成します。certification-profile-intakeはリポジトリを読み、認証プロファイルの候補値を作成します。製品名、意図する使用、システム境界などには、コードの根拠または未確認の理由が記載されます。
[unconfirmed]は、まだ人が確定していないことを表します。担当者が確認した項目だけを[confirmed]に変更します。安全クラスやリスク受容基準が未決定なら、未確定のままにします。後続の文書では、確定したプロファイルの値だけを事実として扱います。
文書の種類と範囲を選ぶ
同じプロジェクトに文書を追加
サイドバーのプロジェクト一覧で、対象プロジェクトの文書追加ボタンを押します。連携済みのリポジトリとブランチをそのまま使用します。以前の進行状況が開いた場合は閉じるを押して文書選択に戻ります。
要求仕様書とアーキテクチャを選択
ドキュメントで以前の選択を解除し、SW要求仕様書 (IEC 62304)とSWアーキテクチャ設計書 (IEC 62304)を選択します。この例では、活用例2のSOUPリスト (IEC 62304)も選択しています。実行手順を見るで作成範囲を確認してください。
確認した認証プロファイルを指定
選択した文書の設定で各文書を展開し、認証プロファイルノードIDに同じプロファイルを指定します。プロファイル文書を開いたときのアドレス末尾の
node-…がノードIDです。プロファイルや確定値がない場合、関連情報を推測で埋めず、未確定項目として残します。選択内容を確認して生成
文書の種類と入力値を確認し、ドキュメント3種を作成を押します。要求仕様書とSOUPが先に開始され、同じバッチの要求仕様書の実行終了後にアーキテクチャが開始されます。生成後に文書を開いて結果を確認します。
結果で確認すること
要求仕様書のREQ-001、アーキテクチャ設計書のARCH-001などのIDをたどり、説明が実装と一致するか確認します。根拠ファイルのパスは、内容を再確認する出発点です。
| 確認項目 | 担当者が行うこと |
|---|---|
| 機能・インターフェースの説明 | コードと比較し、要求の不足や実装との相違を記録 |
| 要求と設計の対応 | 参照IDが実在し、内容も一致するか確認 |
| 規格の引用 | 規格・版・条項がレビュー範囲に適合するか確認 |
[GAP]と未確定値 | 製品・開発・規制・品質担当者の中から補完する担当を決定 |
| 検証に関する記述 | 計画と実施結果を区別し、試験記録を別途確認 |
活用例2. SOUPレビュー資料を整理する
外部ライブラリやソフトウェア構成要素を整理するには、SOUPリストスキルsw-soup-listを使います。リポジトリの依存関係マニフェストとlockファイルを根拠に、識別情報のドラフトを作成します。
名称、正確なバージョン、ライセンス、使用箇所を元のファイルと照合してください。ライセンスや既知の異常に関する評価資料が確認できない場合は、未確認であることを残します。
依存関係一覧だけではSOUPレビューは完了しません。直接・推移的依存関係の対象範囲、各構成要素のSOUP該当性、既知の異常の評価、製品安全への影響は担当者が確認します。実施していない脆弱性点検やリスク評価を完了済みとして記録しないでください。
活用例3. 文書セットの不足項目を確認する
文書の生成がすべて完了したら、同じプロジェクトで文書追加を開きます。以前の選択を解除し、SW文書セット ギャップレポートだけを選択します。同じ認証プロファイルノードIDを指定し、ドキュメント1種を作成を押します。pack-gap-reviewは他の文書を読んでレポートを作成し、点検対象の文書自体は変更しません。
この実行では、REQ-011の未対応、REQ-020の部分対応、SOUP項目のARCH参照がレビュー対象として記録されました。要求仕様書・設計書・SOUP・認証プロファイルを実際に読んで点検しています。タイトル検索で確認できなかった他の文書は、存在しないと断定せず未判定として残しています。
| レポートの指摘 | 次の作業 |
|---|---|
| 必須節の欠落・空の本文 | 該当部分を記述し、根拠を補完 |
| 規格条項の参照不足 | 適用範囲と検索結果を確認し、引用または根拠不足の理由を補完 |
| 参照先のない要求・設計ID | 実際の項目に接続するか、廃止記録を確認 |
| 未確定情報を確定事実として記述 | プロファイルと照合して修正し、担当者がレビュー |
残っている[GAP] | 必要な情報・証拠・判断を揃えて再レビュー |
このレポートは、文書パックのチェックリストに基づく補完作業の一覧として使います。不足なしという表示だけで、規制要求への全面的な適合や提出準備の完了が証明されるわけではありません。
コードを変更した後は
医療機器文書パックの開発文書8種類とギャップレポートは全体書き換え方式です。リポジトリの変更を自動反映を有効にすると、選択したブランチの変更に応じて既存の管理文書が更新されます。影響箇所だけを変更する差分更新とは異なり、文書全体を書き換えるため、人が補完した内容と併せて結果を確認してください。この例の初回生成では自動更新を無効にしています。
再生成の前後で、確定した製品情報、既存の項目ID、人が補完した根拠とレビュー記録が一貫しているか確認します。認証プロファイルのインテークは別の差分更新方式で、確定値を勝手に変更せず、再確認が必要な内容を残します。
自分のプロジェクトで始める
最初はリポジトリ1つ → 認証プロファイルの確認 → 要求仕様書・設計書のドラフト → ギャップレビューの順で進めます。最初のレビューで必要な資料と担当者を確認し、SOUP・リスク管理・使用適合性の文書へ広げてください。