TL;DR

「対策方針: 早期にパッチ適用を推奨」では現場は動かない。「5/22 14:00 までに山田が本番サーバ A の Apache を 2.4.62 にアップデート」と書いた瞬間に作業が走る
現場向け報告の 3 要素: タスク (動詞) / 担当者 (個人名) / 期限 (日時)
表形式でまとめれば作業着手率はほぼ 100%

対象読者

セキュリティコンサルタント 1-3 年目
脆弱性対応依頼書・インシデント指示書を書く方
「結局誰が、いつまでに、何を?」と問い返された経験がある方

なぜ「対策方針」では動かないのか

セキュリティ担当が「対策方針」を書いた時点で、頭の中には次の情報が揃っている。

どのサーバが対象か
誰が作業するか
いつまでにやるべきか
どうやって作業するか

しかし報告書には「対策方針」しか出ない。受け取った現場は次のロスを生む。

「どのサーバ?」→ 1 日ロス
「うちじゃなくて隣のチームでは?」→ 2 日ロス
「いつまで?」→ 1 週間ロス
「どう作業?」→ 半日ロス

報告書が「自分の頭の中の情報」を出し切っていないだけ。

Before/After 比較表

#	場面	Before (方針のみ)	After (タスク化)
1	週次脆弱性対応	「早期にパッチ適用を推奨」	「5/22 14:00 までに山田が web-prod-01 の Apache を 2.4.62 に yum update。完了報告は Slack #infra」
2	インシデント初動	「不審な通信を検知。詳細調査を行う」	「田中: 端末 PC-042 をネット切断、14:30 完了報告。鈴木: 過去 7 日通信ログ抽出、17:00。高橋: 上長報告書、明日 10:00」
3	月次セキュリティ	「アカウント棚卸を実施」	「6/5 佐藤が退職者リスト入手、6/10 山田が AD 無効化、6/15 鈴木が完了報告書作成」

After 共通: 誰が・いつまでに・何を が全部埋まっている。

現場向け報告の 3 要素

要素 1: タスク (動詞形・1 アクション)

NG  「対応する」「実施する」「確認する」
OK  「アップデートする」「切断する」「無効化する」

「対応」は範囲が広すぎて作業が始まらない。「アップデートする」なら yum update を打てば終わる。

要素 2: 担当者 (実名・1 人)

NG  「情シス部門で対応」「セキュリティチーム」
OK  「山田が対応」

部署名だと「誰の手に渡るか」が決まらない。実名なら朝礼で確認できる。

要素 3: 期限 (日付 + 時刻)

NG  「速やかに」「至急」「来週中に」
OK  「5/22 (金) 14:00 まで」

時刻まで書くことで、他業務との競合を見える化できる。

実例: Apache 脆弱性対応依頼

Before (対策方針)

件名: Apache HTTP Server の脆弱性対応依頼

JPCERT より深刻度高の脆弱性 (CVE-2026-XXXX、CVSS 9.1) が公開されました。
当社の本番環境に該当があり、悪用された場合 RCE の可能性があります。
つきましては早期にパッチ適用を推奨いたします。

現場: 「どのサーバ?」「うちのチーム?」「いつまで?」「手順は?」 → 3 日経過しても着手なし。

After (タスク + 担当者 + 期限)

件名: 【要対応・5/22 14:00 まで】Apache 脆弱性 対応依頼 (CVE-2026-XXXX)

【対応概要】 本番サーバ 3 台の Apache を 2.4.62 にアップデート

【タスク・担当者・期限】
| # | タスク                                            | 担当 | 期限      | 完了報告先  |
|---|---------------------------------------------------|------|-----------|-------------|
| 1 | web-prod-01 の Apache を 2.4.62 に yum update     | 山田 | 5/22 14:00| Slack #infra|
| 2 | web-prod-02 の Apache を 2.4.62 に yum update     | 田中 | 5/22 16:00| Slack #infra|
| 3 | web-prod-03 の Apache を 2.4.62 に yum update     | 鈴木 | 5/23 10:00| Slack #infra|
| 4 | 3 台の動作確認 (HTTP 200 応答)                    | 佐藤 | 5/23 11:00| 本依頼に返信|

【作業手順】 別紙 1 (社内 Wiki: /security/CVE-2026-XXXX-apache-update)
【ロールバック手順】 別紙 2
【作業窓口】 ゆうき (内線 1234)

現場: 「了解、5/22 14:00 までやります」 → 13:30 に完了報告。

タスク化 4 チェックリスト

#	チェック項目	NG → OK
1	動詞で書かれているか	「対応」 → 「アップデート」
2	担当者が個人名 1 人か	「情シス」 → 「山田」
3	期限が日付 + 時刻か	「速やかに」 → 「5/22 14:00」
4	完了報告先が明示か	(なし) → 「Slack #infra」

4 つ揃った報告書は現場で作業着手率がほぼ 100%。

「分からないから止まる」を防ぐ事前確認依頼

報告書を初めて受ける現場では Apache バージョンや該当サーバが分からないことが多い。本依頼の前に事前確認依頼を出す。

件名: 【事前確認・5/20 まで】本番サーバの Apache バージョンご確認依頼

下記 3 台の Apache バージョンを 5/20 12:00 までに本依頼に返信でご回答ください。
  - web-prod-01 / web-prod-02 / web-prod-03
確認コマンド: httpd -v
担当: 各サーバ管理者 (山田 / 田中 / 鈴木)

事前確認で情報を得たら本番の対応依頼書を発出。

担当者が今日からできる 3 アクション

次の脆弱性対応依頼を「タスク + 担当者 + 期限」表で書く
「速やかに」を全て日時に置換する (過去 1 ヶ月分を grep)
完了報告先を必ず明示する (Slack / メール / 対面のいずれか)

まとめ

現場向け報告の肝は「タスク化」。動詞で書く、個人名で書く、日時で書く、完了報告先を書く。この 4 つで作業着手率はほぼ 100%。

シリーズ最終回 (#5) は監査対応報告: 監査人を納得させる Before/After。

関連記事

📌 無料テンプレ提供: 「タスク + 担当者 + 期限」表テンプレ、事前確認依頼の雛形、完了報告先一覧フォーマットを PDF 配布。note メンバーシップで 初月無料。

📣 法人向け: 脆弱性対応依頼書・インシデント指示書のタスク化改善ワークショップ → intect-i.jp

タグ: #Security #セキュリティ #報告書 #BeforeAfter #現場担当 #脆弱性対応 #タスク化