外部の脆弱性診断の報告書を受け取るたびに、指摘事項を重大度・対象システム・担当で整理した是正計画の下書きと、経営層向けの要約を作る

処理の起点を決める

受領用のフォルダ（Blob Storage のコンテナー）に報告書が保存されたことを起点にします。 報告書は診断会社からメールや受け渡し用のサイトで届くので、受け取った担当者が受領用のフォルダへ移します。移すときに、受付票（対象システム、診断会社、診断の種類、診断の期間）を同じ場所に置きます。

受付票を求めるのは、報告書の表紙だけでは対象が決まらないことがあるためです。同じ社名のサービスが複数あり、表紙には「○○サービス」としか書かれていないことがあります。受付票と表紙が食い違えば、処理を止めて担当者に戻します。

月末にまとめて処理しません。 報告書は届いた日に読み込み、是正の依頼をその週のうちに出します。重大度の高い指摘は、月末を待つあいだにも攻撃を受けうるからです。

入力データを集める

質を決めるのは、資産台帳と社内の基準の表です。 資産台帳にURLが登録されていないシステムは担当が付かず、基準の表が無ければ期限が付きません。どちらもAIの外側にあるもので、無ければこの構成は是正計画を作れません。

指摘一覧のファイルがあれば、件数の照合に使います。 報告書の本文から取り出した指摘の数と、一覧ファイルの行数が合っているかを見ます。合わなければ、本文の区切りか一覧ファイルのどちらかに漏れがあります。

データの取得方法を決める

資産台帳の照合は、URLとホスト名で行います。 報告書の対象は「https://〜/admin/」のようにパスまで書かれることが多いので、台帳にはホスト名とパスの先頭を登録しておき、長いほうから順に当てます。 名前で照合すると、似た名前のシステムに当たります。

前回との照合は、対象と指摘の種類の組で行います。 見出しの文言は診断会社ごとに違うので、AIに「指摘の種類」を社内の分類表から選ばせ、「同じシステム・同じパス・同じ種類」なら同じ指摘とみなします。 判定が割れるものは「要確認」として人に回します。

AIへ渡す前に整形する

1. 形式の確認 … PDFであることを確かめます。パスワードでロックされたPDFは、提出前にロックを解除する必要があります
2. ページ数とサイズの確認 … PDFは最大2,000ページ、有料（S0）レベルで500MBが上限です。報告書がこれを超えることはまずありませんが、付録の画面の写しが多いものはサイズを見ます
3. ヘッダーとフッターの除去 … 段落の役割が pageHeader と pageFooter のものを外します。「社外秘」「Page 12」が指摘の本文に混ざると、区切りを誤ります
4. 指摘ごとの区切り … 診断会社ごとの見出しの書式（「指摘ID」「No.」など）を設定ファイルに持ち、見出しの単位で切り出します
5. 攻撃の文字列の扱い … 再現の手順にある攻撃の文字列（入力した値や送った要求）は、AIに渡す前に置き換え、原本の位置だけを残します
6. 件数の照合 … 切り出した指摘の数を、指摘一覧の表の行数と比べます

5番目を軽く見ないでください。 再現の手順には、実際に攻撃が通った文字列がそのまま書かれています。要約にも依頼文にもその文字列は要りません。経営層向けの要約に攻撃の文字列が載ると、その資料自体が攻撃の手引きになります。

AIに処理させる

させるのは、2回に分けて3つです。 1回目は指摘ごとに項目をそろえること、2回目は是正の依頼文と経営層向けの要約を書くことです。

重大度を「原文のまま」と書いているのが、この表でいちばん大事なところです。 診断会社によって「緊急・高・中・低・情報」の5段階だったり、「High・Medium・Low・Info」の4段階だったりします。AIに社内の段階へ読み替えさせると、読み替えの誤りと付け直しの区別がつきません。 読み替えは、診断会社ごとの対応表でプログラムが行います。

CVSS の表記も、そのまま写させます。 CVSS v4.0 の仕様書では、点数を示すときに、どの評価の指標を使ったかを CVSS-B（基本）、CVSS-BT（基本と脅威）、CVSS-BE（基本と環境）、CVSS-BTE で書き分けるとされています。同じ「7.5」でも、基本の指標だけの点数と環境の指標を入れた点数では意味が違います。 報告書がどちらで書いているかを残さないと、比べてはいけない数字を並べることになります。

3行目がいちばん起きやすい失敗です。 要約を書かせるときに件数を渡さないと、AIは本文から数えて書きます。数え間違えた件数が、そのまま経営層の資料に載ります。

指示内容を固定する

あなたは情報システム部で、外部の脆弱性診断の報告書を整理する立場です。
渡す本文は、報告書から指摘を1件分だけ切り出したものです。
本文に書かれていることだけを使い、推測で埋めないでください。

【取り出す項目】
1. 指摘の見出し（報告書の文言のまま）
2. 対象のURL・ホスト（複数あればすべて）
3. 指摘の種類（下の分類表から1つ。当てはまらなければ other）
4. 重大度（報告書に書かれた段階を、文言を変えずにそのまま）
5. CVSS の表記（点数、ベクター、CVSS-B などの区分。書かれている分だけ）
6. 再現の要点（何をすると何が起きるか。2文以内）
7. 推奨される対策（報告書の推奨を、文言を変えずに箇条書き）

【厳守事項】
- 重大度を読み替えたり、付け直したりしないでください。
  「高」と書かれていれば「高」、「High」と書かれていれば「High」です。
- 本文に重大度が書かれていなければ、空にしてください。
  本文の内容から重大度を推し量って書かないでください。
- CVSS の点数だけがあってベクターや区分が無い場合は、点数だけを入れ、
  区分は空にしてください。
- 再現の要点に、攻撃に使った文字列・要求・認証情報を書かないでください。
  【置換済み】と書かれた箇所を復元しないでください。
- 推奨される対策を、自分の考えで補ったり言い換えたりしないでください。
- 是正の期限、優先度、リスクを受け入れてよいかは書かないでください。
- 本文が指摘ではない（総評、付録、目次など）と判断した場合は、
  is_finding を false にして、ほかの項目は空にしてください。
- evidence には、重大度と対象の根拠にした文をそのまま写してください。

【指摘の種類の分類表】{finding_types}
【診断会社】{vendor}
【本文】{finding_text}

「重大度を推し量って書かない」を明記しないと、空欄を埋めます。 総評の章に重大度がまとめて書かれていて、詳細のページには書かれていない報告書があります。何も言わなければ、本文の深刻そうな書きぶりから「高」と書きます。書かれていないことを示すのは空欄で、埋まった値ではありません。

2回目の指示では、集計した件数の表をそのまま渡し、「この表の数字以外の数を書かない」と指示します。 要約は「今月は○件の診断を受け、社内の優先度が最も高い指摘が○件、前回から残っている指摘が○件」という骨組みをプログラムが作り、AIにはその後ろの説明の文章だけを書かせます。

出力形式を固定する

1回目は次の形のJSONで受け取ります。

{
  "report_id": "",
  "finding_no": "",
  "is_finding": true,
  "title": "",
  "targets": [""],
  "finding_type": "",
  "vendor_severity": "",
  "cvss": { "score": "", "vector": "", "nomenclature": "" },
  "repro_summary": "",
  "recommendations": [""],
  "evidence": ""
}

これにプログラムが次の項目を足して、確定前の一覧の1行にします。

1つ目の理由は、診断会社の記述と社内の判断を別の列に置けることです。 vendor_severity は報告書のまま、normalized_severity と priority は社内の規則で決まります。経営層に「診断会社は中と言っているが、社内では最優先にした」と説明できるのは、列が分かれているからです。

2つ目は、照合と集計ができることです。 targets が配列で返るので資産台帳と照合でき、finding_type が分類表の値なので前回と照合できます。件数は確定した一覧から数えるので、要約の数字と一覧が一致します。

構造化出力のスキーマでは、すべての項目を必須にし、additionalProperties を false にします。項目を省略させず、空のときは空の文字列で返させるので、「書かれていなかった」と「取り出し忘れた」を同じ形で扱えます。

システムへ連携する

資産台帳には書き込みません。 照合できなかったURLがあっても、台帳に追加するのは台帳の管理者です。報告書に出てきたURLが台帳に無いということは、管理されていない公開の入口があるということで、それ自体を要約に載せます。

人が確認する

1. 件数の照合 … 確認画面に、報告書の指摘一覧の件数と、取り出した指摘の件数を並べます。合わなければ、原本の目次から抜けた指摘を探します
2. 重大度の照合 … vendor_severity を、報告書の指摘一覧の表と1件ずつ見比べます
3. 担当チームの確認 … 資産台帳で照合できなかった指摘に、担当チームを手で付けます
4. 期限の確認 … 基準の表で付いた期限を見て、変える場合は理由を書きます
5. 前回との照合の確認 … needs_check の指摘を、前回の記録と見比べて決めます
6. 要約の確認 … 数字の骨組みはそのままに、説明の文章を直します。上長の確認に回します

1番目と2番目を省かないでください。 この2つは、原本と一覧が一致しているかの確認です。AIが1件取りこぼしても、件数が合っていれば気づけません。件数で気づき、重大度で中身を確かめます。

4番目で期限を変えたときの理由は、必ず残します。 「社内からしか届かないので延ばす」は、リスクを受け入れる判断です。その判断が誰のものかを残しておかないと、次の診断で同じ指摘が出たときに説明できません。

例外に対処する

上から3行目が、いちばん大事な行です。 件数が合わないまま一覧を確定すると、取りこぼした指摘は誰にも依頼されません。 止めずに印を出すのは、残りの指摘の是正の依頼を遅らせないためです。

記録を残す

• 報告書の原本と受付票、受け取った日時
• レイアウト モデルの読み取り結果と、指摘ごとに区切った本文（攻撃の文字列は置き換えた後のもの）
• AIが返したJSONと、プログラムが足した項目（担当、期限、前回との照合）
• 人が直した箇所と理由（担当チーム、期限、前回との照合の判定）
• 確定した是正計画と、経営層向けの要約の確定版
• 指摘ごとの是正の状況（チケットの番号、完了日、再診断の結果）

4つ目の「人が直した理由」が、いちばん後から効きます。 期限を延ばした理由、担当を変えた理由が残っていれば、次の診断で同じ指摘が出たときに、それが受け入れたリスクなのか、是正の失敗なのかを区別できます。

最後の行は、前回との照合の材料になります。 是正が完了した指摘が次の診断で再び出たら reappeared とし、要約の最初に載せます。