脆弱性対応の是正計画（CAPA）テンプレ
（OEM調査依頼で使える実務雛形）
OEM調査依頼や監査で「影響あり」となった後、必ず問われやすいのが 是正計画（CAPA：Corrective and Preventive Action） です。
「対策します」だけでは弱く、相手が見たいのは次の4点です。
- いま何を止血するか（暫定対策）
- なぜ起きたか（根本原因）
- どう直すか（恒久対策）
- どう再発を防ぐか（再発防止）
つまり、CAPAは単なる改善メモではなく、相手に “運用が回っている” ことを示す提出物です。
このページでは、そのまま使える 脆弱性対応の是正計画テンプレ と、書き方・運用のコツをまとめます。
まず整理：CAPAで最低限入れるべき項目
CAPAは細かくしすぎると運用が止まります。最小限、次の項目があれば実務では十分です。
- 案件ID
- 事象/CVE/依頼名
- 対象製品・対象版数
- 影響概要
- 暫定対策
- 根本原因
- 恒久対策
- 再発防止策
- 責任者
- 期限
- 検証方法
- 証跡ID/参照先
- 承認者
コピペで使える：脆弱性対応の是正計画（CAPA）テンプレ
使い方： このまま回答書や社内様式（チケットなど）へ貼り、【 】だけ埋めてください。
この記事のテンプレを、自社の製品構成や運用体制に合わせて調整したい方はご相談ください。
【無料】オンライン相談を予約する書き方のコツ（監査・照会を通すために）
1. 暫定対策と恒久対策を混ぜない
「設定で無効化した」ことと「根本修正した」ことは別です。前者は暫定対策、後者は恒久対策として分けて書きます。
2. 原因と対策を1対1で結ぶ
「原因が何で、その結果どの対策を打つのか」がつながっていないと、CAPAがただの“作文”になり、監査で突っ込まれます。
3. 期限は必ず「日付」で書く
「早急に」「速やかに」は監査で弱いです。YYYY-MM-DD で固定するとSLA運用として強くなります。
4. 証跡は添付できなくても参照できるようにする
証跡ID、文書名、保存場所が残っていれば、監査でも辿れます。「添付なし＝証跡なし」ではありません。
5. OTAが絡むなら配布方法も書く
修正版をどう届けるかは、再発防止の一部です。工場更新、現地更新、OTAなど、現実の運用方法を明記すると通りやすくなります。
よくあるNG例（CAPAが差し戻される原因）
- 原因が「調査不足」だけ
→ 何を直すべきか分からない（再発防止に繋がらない） - 暫定対策しか書かれていない
→ 恒久対策が無く、相手が不安になる - 責任者が無い
→ 誰が実行するか分からず止まる - 検証方法が無い
→ “やったつもり”で終わる - 次回更新日が無い
→ 調査中・対策中のまま放置に見える
Auto PSIRT Cloudに落とす時のポイント
このテンプレは、そのままシステムのワークフロー項目として使えます。
最低限、次をフィールド化すると運用しやすくなります。
- 案件ID
- 対象版数
- 暫定対策
- 根本原因
- 恒久対策
- 再発防止策
- 責任者
- 完了予定日
- 次回更新日
- 証跡ID
これが揃うと、回答書作成・進捗管理・監査対応が一本化しやすくなります。
FAQ：是正計画（CAPA）の書き方
OEMや監査の要求次第ですが、少なくとも「影響あり」となった案件では、暫定対策・恒久対策・再発防止の整理が求められやすいです。作っておくのが無難です。
大丈夫ですが、その場合でも「恒久対策の方針」と「次回更新日」を書いた方が通りやすくなります。いつ直るか分からない状態は相手を不安にさせます。
「暫定原因」と明記し、次回更新日を付けて運用してください。不確かなまま断定して後で覆る方が、監査や信頼関係において危険です。
回答書と是正計画、システムで一元管理しませんか？
Auto PSIRT Cloudなら、影響あり判定から暫定・恒久対策の入力、そしてOEM提出用フォーマットへの自動出力までを一気通貫でサポート。期限（SLA）もダッシュボードで管理できます。