# 医療機器ソフトウェアの開発文書自動化

> 医療機器の開発文書の不足を見つけにくい。コード根拠付きの要求・設計・SOUPの下書きとギャップレポートを作ります。担当者と専門家が漏れや未確定項目を確認します。

医療機器ソフトウェアの文書準備では、コードで確認できる事実と担当者の判断を分け、下書きと補完一覧を作ります。

## こんな問題があるとき

実装が進んでも、要求・設計・外部ソフトウェア一覧にはコードとの繰り返し照合が必要です。参照の切れや製品・安全情報の不足があると、何から補完すべきか分かりにくくなります。

## Specifyで解決する

1. GitHubリポジトリと必要な文書スキルを接続し、コードにない製品情報を入力します。
2. Specifyで要求・アーキテクチャ・SOUPの下書きを作り、コード根拠と文書間の参照を確認します。
3. ギャップレポートで漏れと未確定項目を集め、担当者が補完します。提出前の規制・安全判断は専門家がレビューします。

## どのような結果を得られますか？

| 必要な作業 | 作成する文書 | レビューする成果物 |
| --- | --- | --- |
| 実装された機能と構造の文書化 | 要求仕様書 · アーキテクチャ設計書 | 要求ID、アーキテクチャ項目、根拠ファイルのパスを含むドラフト |
| 外部ソフトウェア構成要素の整理 | SOUPリスト | 識別情報、バージョン・使用箇所の根拠、追加確認事項 |
| 文書セットの不足箇所の確認 | 文書セット ギャップレポート | 必須節の欠落、未確定値、`[GAP]`、参照先のないIDをまとめたレポート |



## 先に確認する表記

| 表記 | 意味 |
| --- | --- |
| REQ-… / ARCH-… | 要求事項とアーキテクチャ項目のIDです。参照先が実在し、内容が一致しているか確認します。 |
| [unconfirmed] | ドラフトの提案値で、担当者がまだ確定していない状態です。承認済みの事実として扱わないでください。 |
| [GAP] | 根拠や入力が不足しており、確認・補完が必要な箇所です。この表示だけで規制適合性を判定するものではありません。 |
| SOUP | 出所や開発履歴が十分に分からないソフトウェア項目を確認する際の表記です。版と使用箇所を特定しても、安全影響の評価が完了したことにはなりません。 |

<Screenshot name="medical-requirements" alt="実際に生成してレビューした要求仕様書。REQ-001入力検証とREQ-002順序検証にコードのパス、検証候補、未確定のリスク参照が表示されている" caption="サンプルコードが要求ID・根拠ファイル・検証候補に整理された実際の結果です。文書のタイトルと数値範囲の表記は読みやすく修正しています。" />

## この例で使用するプロジェクト

<strong>MedRelay Demo</strong>は、合成機器パケットの入力検証、順序チェック、メモリ保持、CSVエクスポートを実装した小さな文書化用の例です。画面は、このコードを接続して実際のアプリで実行した結果です。実際の患者データや顧客プロジェクトは使用していません。

<a href="/examples/ja/medrelay-demo.zip" download="medrelay-demo.zip">サンプルコードをダウンロード</a>し、自分のGitHubリポジトリに配置すると、同じ流れを試せます。実際の医療機器や認証取得事例ではありません。安全クラスやリスク受容基準などは意図的に未確定のままにしています。

<Warning>
  生成文書は<strong>提出前に規制・品質の専門家によるレビューが必要なドラフト</strong>です。コードで確認した実装の事実は、承認済みの要求事項や試験実施の証拠を代替しません。対象市場、意図する使用、安全クラス、適用規格と版は担当者が確認してください。
</Warning>

## 始める前に

- 文書化する[GitHubリポジトリとブランチ](/ja/guides/github)を連携します。最初はレビュー範囲が明確なリポジトリを選びます。
- [ドキュメントプロジェクト](/ja/guides/doc-projects)を作成できる編集権限とプランを確認します。最新の利用条件は[料金ページ](https://specify.app/pricing)を参照してください。
- 製品の目的、ユーザー、使用環境、コードの範囲など、コードだけでは確定できない情報を用意します。
- [規格ライブラリ](/ja/knowledge/standards)の利用可否を確認します。規格検索を利用できない場合や条項が見つからない場合は、根拠不足として残してレビューします。

<strong>設定 → AIエージェント → プラグイン</strong>で`medical-device-docs`を探し、含まれるスキルを確認してインストールします。このパックには、認証プロファイルの収集、開発文書の作成、ギャップレビューを行う10種類のスキルが含まれます。

<Screenshot name="medical-docs-pack" alt="医療機器文書パックの詳細画面。認証プロファイル、ギャップレビュー、アーキテクチャなどのスキルとインストールボタンが表示されている" caption="インストール前に、含まれるスキルと各スキルの提供言語を確認してください。" />

## 活用例1. 要求仕様書・設計書のドラフトを作成する

### 製品情報を先に確認する

まず<strong>プロジェクトを作成</strong>でリポジトリとブランチを選び、文書の種類として<strong>認証プロファイル インテーク</strong>を選択して生成します。`certification-profile-intake`はリポジトリを読み、<strong>認証プロファイル</strong>の候補値を作成します。製品名、意図する使用、システム境界などには、コードの根拠または未確認の理由が記載されます。

`[unconfirmed]`は、まだ人が確定していないことを表します。担当者が確認した項目だけを`[confirmed]`に変更します。安全クラスやリスク受容基準が未決定なら、未確定のままにします。後続の文書では、確定したプロファイルの値だけを事実として扱います。

<Screenshot name="medical-profile" alt="実際に生成されたMedRelay Demo認証プロファイル。製品名とバージョンにはファイルの根拠があり、製品情報には未確定の表示がある" caption="コードで確認できる情報と、人が決める情報を区別します。この例ではプロファイルの値を確定せず、未確定のまま後続文書を生成しています。" />

### 文書の種類と範囲を選ぶ

<Steps>
  <Step title="同じプロジェクトに文書を追加">
    サイドバーのプロジェクト一覧で、対象プロジェクトの文書追加ボタンを押します。連携済みのリポジトリとブランチをそのまま使用します。以前の進行状況が開いた場合は<strong>閉じる</strong>を押して文書選択に戻ります。
  </Step>
  <Step title="要求仕様書とアーキテクチャを選択">
    <strong>ドキュメント</strong>で以前の選択を解除し、<strong>SW要求仕様書 (IEC 62304)</strong>と<strong>SWアーキテクチャ設計書 (IEC 62304)</strong>を選択します。この例では、活用例2の<strong>SOUPリスト (IEC 62304)</strong>も選択しています。<strong>実行手順を見る</strong>で作成範囲を確認してください。
  </Step>
  <Step title="確認した認証プロファイルを指定">
    <strong>選択した文書の設定</strong>で各文書を展開し、<strong>認証プロファイルノードID</strong>に同じプロファイルを指定します。プロファイル文書を開いたときのアドレス末尾の<code>node-…</code>がノードIDです。プロファイルや確定値がない場合、関連情報を推測で埋めず、未確定項目として残します。
  </Step>
  <Step title="選択内容を確認して生成">
    文書の種類と入力値を確認し、<strong>ドキュメント3種を作成</strong>を押します。要求仕様書とSOUPが先に開始され、同じバッチの要求仕様書の実行終了後にアーキテクチャが開始されます。生成後に文書を開いて結果を確認します。
  </Step>
</Steps>

<Screenshot name="medical-generation-progress" alt="要求仕様書とSOUPリストが生成中で、アーキテクチャ設計書が先行文書を待っている実際の進行画面" caption="一括選択しても依存関係に沿って実行されます。文書ごとに進行状況とスレッドを確認できます。" />

### 結果で確認すること

要求仕様書の`REQ-001`、アーキテクチャ設計書の`ARCH-001`などのIDをたどり、説明が実装と一致するか確認します。根拠ファイルのパスは、内容を再確認する出発点です。

<Screenshot name="medical-architecture" alt="実際のアーキテクチャ文書の追跡表の一部。REQ要求がARCHソフトウェア項目と根拠ファイルに接続されている" caption="文書を個別に作って終わらず、REQ → ARCH → コードの根拠という対応を確認します。追跡表の一部です。" />

| 確認項目 | 担当者が行うこと |
| --- | --- |
| 機能・インターフェースの説明 | コードと比較し、要求の不足や実装との相違を記録 |
| 要求と設計の対応 | 参照IDが実在し、内容も一致するか確認 |
| 規格の引用 | 規格・版・条項がレビュー範囲に適合するか確認 |
| `[GAP]`と未確定値 | 製品・開発・規制・品質担当者の中から補完する担当を決定 |
| 検証に関する記述 | 計画と実施結果を区別し、試験記録を別途確認 |

## 活用例2. SOUPレビュー資料を整理する

外部ライブラリやソフトウェア構成要素を整理するには、<strong>SOUPリスト</strong>スキル`sw-soup-list`を使います。リポジトリの依存関係マニフェストとlockファイルを根拠に、識別情報のドラフトを作成します。

名称、正確なバージョン、ライセンス、使用箇所を元のファイルと照合してください。ライセンスや既知の異常に関する評価資料が確認できない場合は、未確認であることを残します。

<Screenshot name="medical-soup" alt="SOUP-001 zodにバージョン3.25.17、MITライセンス、入力検証での使用箇所が示され、安全影響とARCH参照がGAPとして残る実際の結果" caption="バージョンと使用箇所はコードから確認し、実施していない安全影響評価は未確定として残します。" />

<Note>
  依存関係一覧だけではSOUPレビューは完了しません。直接・推移的依存関係の対象範囲、各構成要素のSOUP該当性、既知の異常の評価、製品安全への影響は担当者が確認します。実施していない脆弱性点検やリスク評価を完了済みとして記録しないでください。
</Note>

## 活用例3. 文書セットの不足項目を確認する

文書の生成がすべて完了したら、同じプロジェクトで文書追加を開きます。以前の選択を解除し、<strong>SW文書セット ギャップレポート</strong>だけを選択します。同じ認証プロファイルノードIDを指定し、<strong>ドキュメント1種を作成</strong>を押します。`pack-gap-review`は他の文書を読んでレポートを作成し、点検対象の文書自体は変更しません。

<Screenshot name="medical-gap-review" alt="実際のギャップレポートの追跡性点検表の一部。REQ-011未対応、REQ-020部分対応、SOUPのARCH参照の確認事項が表示されている" caption="IDの存在と文書間の対応の十分性は別々に確認します。実際のレポートの一部で、読みやすくするためエディターで列幅を調整しています。" />

この実行では、<strong>REQ-011の未対応、REQ-020の部分対応、SOUP項目のARCH参照</strong>がレビュー対象として記録されました。要求仕様書・設計書・SOUP・認証プロファイルを実際に読んで点検しています。タイトル検索で確認できなかった他の文書は、存在しないと断定せず<strong>未判定</strong>として残しています。

| レポートの指摘 | 次の作業 |
| --- | --- |
| 必須節の欠落・空の本文 | 該当部分を記述し、根拠を補完 |
| 規格条項の参照不足 | 適用範囲と検索結果を確認し、引用または根拠不足の理由を補完 |
| 参照先のない要求・設計ID | 実際の項目に接続するか、廃止記録を確認 |
| 未確定情報を確定事実として記述 | プロファイルと照合して修正し、担当者がレビュー |
| 残っている`[GAP]` | 必要な情報・証拠・判断を揃えて再レビュー |

このレポートは、文書パックのチェックリストに基づく<strong>補完作業の一覧</strong>として使います。不足なしという表示だけで、規制要求への全面的な適合や提出準備の完了が証明されるわけではありません。

## コードを変更した後は

医療機器文書パックの開発文書8種類とギャップレポートは<strong>全体書き換え方式</strong>です。<strong>リポジトリの変更を自動反映</strong>を有効にすると、選択したブランチの変更に応じて既存の管理文書が更新されます。影響箇所だけを変更する差分更新とは異なり、文書全体を書き換えるため、人が補完した内容と併せて結果を確認してください。この例の初回生成では自動更新を無効にしています。

再生成の前後で、確定した製品情報、既存の項目ID、人が補完した根拠とレビュー記録が一貫しているか確認します。認証プロファイルのインテークは別の差分更新方式で、確定値を勝手に変更せず、再確認が必要な内容を残します。

## 自分のプロジェクトで始める

最初は<strong>リポジトリ1つ → 認証プロファイルの確認 → 要求仕様書・設計書のドラフト → ギャップレビュー</strong>の順で進めます。最初のレビューで必要な資料と担当者を確認し、SOUP・リスク管理・使用適合性の文書へ広げてください。

<CardGroup cols={2}>
  <Card icon="git" title="ドキュメントプロジェクトの作成" href="/ja/guides/doc-projects">リポジトリと文書スキルを選び、最初のドラフトを作成します。</Card>
  <Card icon="library" title="規格の根拠と文書パック" href="/ja/knowledge/standards">ライブラリの利用範囲と、その他の文書の種類を確認します。</Card>
</CardGroup>