月次の脆弱性レビュー会議の回し方
（兼務でも破綻しない運営手順）

先に結論：月次レビュー会議で決めることは4つだけ

会議が長引く最大の原因は、「何でもかんでも会議の場に持ち込みすぎる」ことです。
月次レビュー会議では、最初から次の4つしか決めないと割り切ると、一気に回しやすくなります。

• どの案件を優先するか
• 各案件の結論をどう置くか
  （対応必須 / 要確認 / 対応不要など）
• 誰が、何を、いつまでにやるか
• 次回更新日と、証跡を何で残すか

CISA の SSVC（Stakeholder-Specific Vulnerability Categorization）でも、脆弱性対応は最終的に Track / Track* / Attend / Act のような「具体的な行動決定」へつなげるのが目的だとされています。
月次会議は、まさにこの“行動の決定”を行うための場です。cisa.gov

---

参加者は最小でよい

兼務体制で回している場合、会議メンバーを増やしすぎると「全員の予定が合う日がない」という理由で日程が組めず、逆に案件が止まります。

月次会議の最小構成は、次の3ロール（役割）で十分です。

必要に応じて、当該機能のQAや上流（OS/ミドルウェア）の連絡担当がスポットで入れば十分です。全員参加型の定例会にすると、かえって「誰がボールを持っているか」の責任がぼやけます。

---

会議前に準備すべきもの

月次レビュー会議は、会議中のファシリテーションよりも「事前準備」で勝敗の8割が決まります。
最低限、次の4つの資料を揃えておくと、会議時間をかなり短縮（30分程度に）できます。

CISAの handling procedures が求める tracking, prioritization, target timelines を、会議前に1枚のボード（台帳）へ集約したものが案件一覧だと考えると分かりやすいです。cisa.gov

---

進め方：月次レビュー会議の標準アジェンダ

アジェンダは複雑にする必要はありません。以下の4ステップ（順序）で進めるのが最も効果的です。

会議後に必ず残すべき証跡

会議の価値は、「決めたことを後から追えるか（監査で説明できるか）」で決まります。
議事録を長文でダラダラと書く必要はありません。最低限、以下の項目を残してください。

• 会議日
• 参加者
• 対象案件ID
• 決定事項
• 宿題（担当・期限）
• 次回更新日
• 証跡参照先

Word等で議事録を作るよりも、案件管理台帳（チケット）のコメント欄に決定事項を追記するだけの方が、案件と情報が紐付くため圧倒的に運用が強くなります。

そのまま使える：月次レビュー会議メモの型

案件台帳や社内チャットに記録を残す際、以下のテキストをそのままコピペして使えます。

※このテンプレがあるだけで、会議後のタスクの抜け漏れがかなり減ります。

よくあるNG例（会議が形骸化するパターン）

• NG1：新規案件を「全部」持ち込む
  事前にフィルタリングせず、件数が多すぎる状態で会議に持ち込むと、時間内に何も決まりません。「期限接近・新規・長期化」の3群に分けるのが先です。
• NG2：「調査中」がそのまま残る
  「次回更新日」と「担当者」が設定されていない“調査中”ステータスは、実質的には放置されているのと同じです。
• NG3：会議のための会議になる
  せっかく議論しても、決定事項や宿題が案件台帳（正本）へ反映されないと、翌月また同じ案件で同じ議論を繰り返すことになります。
• NG4：技術説明に時間を使いすぎる
  月次会議の目的は「脆弱性の技術的な仕組みを深く勉強すること」ではなく、「ビジネス上の優先順位と、誰が対応するかの宿題を決めること」です。

---

FAQ：レビュー会議の運用