脆弱性診断を依頼すると、診断会社から「脆弱性診断報告書」が納品されます。数十ページにわたって検出された脆弱性が並び、それぞれに「高」「Critical」といった危険度のラベルやCVSSスコアが付いています。しかし、セキュリティの専門家ではない担当者にとっては、どの脆弱性から対処すればよいのか、本当にすべて直す必要があるのか、社内にどう説明すればよいのかが分かりにくいものです。
本記事では、脆弱性診断報告書に何が書かれているのか、標準的な章立てと1件ごとの記載項目を実際の公開サンプルに沿って解説します。あわせて、CVSSや危険度の読み方、影響と悪用可能性をふまえた「直す順番」の決め方、報告書を受け取ったあとの再診断までの流れ、そして良い報告書を見分けるポイントまで整理します。受け取った報告書を自分で読みこなし、対応の優先順位を自分の言葉で説明できる状態を目指します。
目次
一括ダウンロードする
脆弱性診断報告書とは何のために受け取る成果物か
脆弱性診断報告書とは、WebアプリケーションやサーバーなどのIT資産を診断会社が検査し、見つかった弱点（脆弱性）と、その危険度・対策方法をまとめた成果物です。脆弱性診断を発注すると、診断の実施後にこの報告書が納品されます。まず押さえておきたいのは、報告書は「検出された脆弱性の一覧」であると同時に「どこから手を付けるかを判断するための材料」でもある、という点です。
報告書は多くの場合、全体像を示す「総合評価」から始まり、検出された脆弱性を一覧で示し、1件ごとの詳細（どんな脆弱性か・どう悪用されるか・どう直すか）へと続きます。まずこの大きな流れを頭に入れておくと、ページ数が多くても迷わず読み進められます。
脆弱性診断報告書の標準的な構成（章立て）
ここからは、脆弱性診断報告書の標準的な章立てを見ていきます。「経営層が全体像を掴むための総合評価」と「技術者が修正に使う指摘事項の詳細」という二部構成は、脆弱性診断報告書に広く採られている基本的な骨格です。ただし章の名称や区切り方、どこまで詳しく書くかは診断会社ごとに異なります。
以下は、公開されているWebアプリケーション診断の報告書サンプル（デジサート・ジャパンの公開サンプル）の目次をもとに整理した、代表的な章立ての一例です。
| 章 | 1. はじめに | 2. セキュリティ診断実施概要 | 3. 総合評価 | 4. 診断対象URL一覧 | 5. 指摘事項一覧 | 6. 診断結果詳細 | 7. お問い合わせ・再診断 | 8-9. 付録（APPENDIX） |
|---|---|---|---|---|---|---|---|---|
| 記載される主な内容 | 診断の目的、本報告書の取り扱い、セキュリティ対策の運用についての前提説明 | 診断の対象・期間・手法などの実施条件 | 全体の評価・総評と、リスクレベル・危険度・攻撃難易度の判定基準、診断項目の概要 | 実際に診断したURL（画面・機能）の一覧 | 検出された脆弱性を一覧表にまとめたもの（危険度の全体像を掴む） | 1件ごとの脆弱性の詳細（種類・内容・結果・対応案・再現例・発生箇所） | 問い合わせ先と、修正後の再診断についての案内 | 診断項目の詳細な説明や参考文献 |
総合評価（エグゼクティブサマリー）の読み方
総合評価は、報告書の冒頭に置かれる「経営層向けのサマリー」にあたる部分です。システム全体のリスクがどの程度か、どのような種類の脆弱性がいくつ見つかったかが要約されており、技術的な詳細を読まなくても全体像を把握できるようになっています。
まずこの総合評価に目を通し、「全体として危険な状態なのか」「深刻な脆弱性がどれくらいあるのか」を掴みます。その上で、指摘事項一覧で個々の脆弱性の危険度を確認し、詳細へと読み進める順序が効率的です。総合評価は社内の上司や経営層に状況を共有する際にもそのまま使えるため、最初に読み込んでおくと説明の土台になります。
1件の脆弱性ごとに記載される項目と記載例
報告書の中心は、検出された脆弱性を1件ずつ詳しく説明する「診断結果詳細」です。ここでは1件の脆弱性について、下表のような項目が記載されます。各項目が何を意味するのかを知っておくと、報告書のどこを見れば「何が危ないのか」「どう直せばよいのか」が分かるかを判断できます。
| 記載項目 | リスクレベル | 脆弱性種類 | 診断内容 | 診断結果 | 対応案 | 再現例 | 発生箇所 | 備考 |
|---|---|---|---|---|---|---|---|---|
| 意味・読み方 | その脆弱性の総合的な危険度。危険度と攻撃難易度から判定される（後述） | クロスサイト・スクリプティングなど、脆弱性の分類名 | どのような検査を行ったか（入力した文字列や操作の内容） | 検査の結果と、その脆弱性によって起こりうる被害（＝影響） | 脆弱性を解消するための具体的な対策方法 | 脆弱性を再現した際の画面や手順（修正後の確認にも使える） | 脆弱性が見つかったURL（画面・機能） | 特記事項があれば記載される補足 |
記載例（1件分のサンプル）
実際の報告書では、1件の脆弱性が次のような形で記載されます。以下は公開サンプルに含まれるクロスサイト・スクリプティング（入力した文字列が意図せずスクリプトとして動作してしまう脆弱性）の例です。各項目が埋まることで、「何が・どこで・なぜ危険で・どう直すか」が1件単位で読み取れるようになっています。
| 項目 | リスクレベル | 脆弱性種類 | 診断結果 | 対応案 | 発生箇所 |
|---|---|---|---|---|---|
| 記載内容 | 高（危険度：高／攻撃難易度：中） | クロスサイト・スクリプティング | 入力項目に特定の文字列を入れると、エスケープされずにスクリプトが動作する。攻撃者に正規利用者のセッションIDを奪取され、なりすましの危険性がある | 入力された文字列の特殊文字のチェックを厳密に行い、エスケープ処理を行うよう設定する | 該当する入力画面のURL |
危険度の読み方（CVSSとリスクレベル）
報告書で各脆弱性に付いている「危険度」は、多くの場合CVSS（共通脆弱性評価システム）というスコアか、診断会社独自のリスクレベルで示されます。ここでは両者の読み方を整理します。まずCVSSは、脆弱性の深刻さを0.0〜10.0の数値で表す国際的な指標で、スコアに応じて深刻度が次のように区分されます。
| 深刻度 | 緊急（Critical） | 重要（High） | 警告（Medium） | 注意（Low） | なし（None） |
|---|---|---|---|---|---|
| CVSS基本値 | 9.0〜10.0 | 7.0〜8.9 | 4.0〜6.9 | 0.1〜3.9 | 0 |
出典・参考資料（1件）
一方、診断会社によっては独自のリスクレベルを用いることもあります。たとえば公開サンプルでは、脆弱性の「危険度（高・中・低）」と「攻撃難易度（易・中・難）」の組み合わせから、リスクレベルを「緊急・高・中・低」の4段階で判定しています。攻撃が容易で被害が大きいものほど、高いリスクレベルになる仕組みです。
報告書に独自のリスクレベルが使われている場合は、その判定基準が「総合評価」の章に説明されているので、あわせて確認しておきましょう。
直す順番（対応優先度）の決め方
結論から言うと、検出された脆弱性は必ずしも一度にすべてを直す必要はなく、危険度と自社への影響が大きいものから順に対応していくのが基本です。ただし危険度の低いものも「直さなくてよい」わけではなく、リスクを把握したうえで計画的に対応します。
進め方としては、まず危険度（CVSSやリスクレベル）から対応の目安をつかみ、そのうえで影響の中身や自社での悪用されやすさを加味して順番を調整します。「全部直さなければならないのか」「どこから手を付けるべきか」で悩んだときの、基本の軸になります。
指摘された項目が多くて優先順位づけに迷うという課題は、脆弱性を継続的に検査するサービスの現場でも共通して聞かれます。
こうした「どれから手を付けるか分からない」状態を避けるには、まず危険度から対応の目安を持つことが出発点になります。
CVSSと対応優先度の早見表
危険度から対応の優先度をつかむための、おおまかな目安は次のとおりです。報告書が診断会社独自のリスクレベル（緊急・高・中・低）で示されている場合は、「高」がCVSSの重要（High）に、「中」が警告（Medium）におおむね対応すると考えると読み替えやすくなります。対応までの期間はあくまで一般的な目安であり、自社のサービスの性質やセキュリティポリシーに応じて基準を定めるのが実務的です。
| 深刻度 | 緊急（Critical） | 重要（High） | 警告（Medium） | 注意（Low） |
|---|---|---|---|---|
| 対応の緊急度（目安） | 最優先 | 高い | 中程度 | 低い |
| 対応時期の目安 | 発見後すぐ〜数日以内を目標に対応 | 1週間〜数週間を目安に修正計画を立てる | 1か月程度を目安に通常の改修サイクルで解消 | リスクを把握し、次回の改修・更新時などに対応 |
※対応時期は決まった規格値ではなく、一般的な運用例をもとにした目安です。実際の基準は自社のポリシーで定めます。CVSSの深刻度区分はIPA「共通脆弱性評価システムCVSS v3概説」に基づきます。
「影響」欄を自社視点でどう読むか
危険度のスコアだけで機械的に順番を決めると、判断を誤ることがあります。同じ「High」でも、外部に公開された決済画面の脆弱性と、社内からしかアクセスできない管理画面の脆弱性とでは、自社にとっての危険度は変わるためです。そこで役立つのが、報告書の「診断結果（影響）」欄の読み方です。
影響欄には、どんな攻撃者が・誰に・何をできてしまうのかが書かれています。ここが「情報漏えいのおそれがあります」のように曖昧な表現で終わっている場合は、自社にとって本当に危険なのかを診断会社に確認することが望まれます。
逆に「正規利用者のセッションIDを奪取され、なりすましが可能」のように具体的であれば、自社のどの画面・どのデータが狙われるのかをイメージしやすくなります。
影響の具体性と、自社システムでその脆弱性がどれだけ悪用されやすいかを合わせて見ることで、スコアだけでは見えない優先順位が判断できます。
直す順番を社内（上司・開発チーム）に説明・合意する
対応の順番は、担当者一人で抱えるものではなく、上司や開発チームと合意して進めるものです。その際、報告書の二部構成がそのまま説明の型になります。経営層や上司には総合評価をもとに「全体としてどの程度のリスクがあり、優先度の高い脆弱性がいくつあるか」を伝え、開発チームには指摘事項詳細の発生箇所・対応案をもとに「どの画面を・どう直すか」を共有します。
たとえば経営層や上司には、「今回の診断で至急対応すべき脆弱性が◯件見つかり、うち△件は今週中に、残りは今月中に修正する計画です」のように、件数と対応時期に絞って伝えると判断してもらいやすくなります。技術的な詳細は指摘事項一覧や詳細のページを添えれば十分です。
このように読む相手に応じて使う章を分けると、「なぜこの順番で直すのか」の根拠を報告書の該当箇所で示しながら合意を取りやすくなります。
一括ダウンロードする
報告書を受け取ったあとの流れ（対策から再診断まで）
報告書は受け取って終わりではなく、指摘された脆弱性を直し、直ったことを確認するまでが一連の流れです。ここでは、対策後の再診断と報告会の活用、そして報告書の種類について整理します。
対策後の再診断（修正確認診断）
指摘された脆弱性を修正したら、その修正が正しく効いているかを確認する「再診断（修正確認診断）」を行います。多くの診断会社が、本診断で検出した脆弱性を対象に再診断のメニューを用意しており、修正前後の検出項目を比較できる形で結果を示します。再診断の回数がプランに含まれているか、追加費用になるかは契約内容によって異なるため、発注時に確認しておくと安心です。
報告会の活用
診断会社によっては、報告書の内容を診断担当者が直接説明する「報告会」を実施しています。報告書だけでは判断しづらい点や、対応の優先順位について疑問があれば、報告会で直接確認できます。社内の開発チームや関係部署を交えて実施すると、対応方針の合意形成が円滑になります。
報告書の種類の違い
報告書には、用途に応じていくつかの種類が用意されていることがあります。検出した脆弱性の概要と対策を早く把握するための簡易な報告書、全ての脆弱性を図や検出根拠とともに詳しく説明する正式な報告書、再診断の結果をまとめた修正確認の報告書などです。どの報告書が納品されるか、どこまで詳しく書かれるかは診断プランによって変わるため、自社に必要な詳しさの報告書が含まれるプランかを確認しておきます。
良い脆弱性診断報告書の見分け方
これから脆弱性診断を発注する場合、どんな報告書が納品されるかは診断会社選びの重要な判断材料です。対応を進めやすい報告書に共通する条件を、チェック観点として整理します。
- 経営層向けの総合評価と、技術者向けの詳細が分かれているか：全体像を把握する層と、実際に修正する層の両方が使える二部構成になっているか。
- 1件ごとに影響と対応案まで書かれているか：脆弱性の指摘だけでなく、「何が起きるか（影響）」と「どう直すか（対応案）」が具体的に書かれているか。
- 再現手順・発生箇所が示されているか：開発チームが同じ現象を再現して修正・確認できるだけの情報があるか。
- 危険度の判定基準が明示されているか：CVSSか独自のリスクレベルか、その判定根拠が報告書内で説明されているか。
- 修正後の再診断の結果まで報告書に残るか：直したあとに効果を確認する再診断（修正確認診断）があり、その結果が報告書として残るか。
これらの観点は、報告書サンプルを事前に確認したり、診断会社に問い合わせたりすることで判断できます。発注前にサンプルを見せてもらえるかどうかも、報告書の品質を推し量る一つの手がかりになります。
脆弱性診断・検出した脆弱性への対応を相談できるサービス
ここからは、報告書の作成を依頼できる脆弱性診断サービスと、報告書で指摘された脆弱性の対応状況を管理するのに役立つサービスを紹介します。「これから診断を依頼して報告書を受け取りたい」「検出された脆弱性を継続的に管理したい」という場合の選択肢として参考にしてください。
| サービス名 | CoWorker 脆弱性診断サービス | Aikido Security |
|---|---|---|
| 提供形態 | 受託型の脆弱性診断 （AI「Red Agent」＋専門家による診断） | SaaS（自動スキャンツール） を自社で継続利用 |
| 主な診断対象 | ソースコード・Webアプリ・API （静的／動的診断・ペネトレーションテスト） | ソースコード・依存ライブラリ・ クラウド設定・稼働中のWebアプリ |
| 報告書・レポート | 検出した脆弱性と対策をまとめた報告書をPDFで納品 | 管理画面で対応状況を管理し PDF・CSVでレポート出力 |
| 再診断・継続チェック | 上位プランに再診断を含む （Standard1回／Professional2回） | 継続的に自動で再スキャン |
| 料金の目安 | ソースコードAI診断15万円〜 （2026年10月時点） | 月額5万円台〜 （年間契約の参考価格） |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
1. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker株式会社が提供する、自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた脆弱性診断サービスです。
Webアプリケーション・API・ソースコードを対象に、ソースコードを解析する静的診断、稼働中のシステムに実際にアクセスして検査する動的診断、攻撃を想定したペネトレーションテスト（実際に攻撃を試みて、どこまで侵入・悪用できるかを検証するテスト）までをメニューとして用意しています。
AIが脆弱性の候補を洗い出し、専門家が最終的に内容を確認してレポートを作成する流れのため、報告書そのものの作成を依頼したい場合に適しています。上位のプランでは、修正後の再診断が1〜2回含まれており、指摘された脆弱性を直したあとの確認まで一貫して任せられます。料金はソースコードを解析する静的診断が15万円から用意されています（2026年10月時点）。
2. Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・稼働中のWebアプリケーションを1つの管理画面で継続的に検査できるツール（SaaS）です。日本では株式会社AndGoが日本語での窓口を務めています。人が診断して報告書を納品する受託型とは異なり、自社で日常的に脆弱性をチェックし、対応状況を管理していくための仕組みです。
検出した脆弱性のアラートを1画面に集約し、対応すべきものを絞り込めるため、「指摘が多すぎてどれから手を付けるか分からない」という状態を避けやすくなります。修正案を自動で作成してプルリクエストまで用意する機能や、PDF・CSVでのレポート出力もあり、報告書で指摘された脆弱性を継続的に管理したい場合の選択肢になります。無料で試せるプランが用意されているため、導入前に操作感を確認できます。
ここで取り上げたのは一例です。診断方法や費用相場、報告書に含まれる内容を含めて脆弱性診断サービス全体を比較し、自社に合う依頼先を選びたい場合は、以下の記事で選び方まで詳しく解説しています。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
まとめ
脆弱性診断報告書は、「総合評価で全体像を掴む→指摘事項一覧で危険度を確認する→1件ごとの詳細で影響と対策を読む」という順で読み進めると、専門家でなくても対応の判断ができます。直す順番は、CVSSや危険度の目安を出発点にしつつ、影響の具体性と自社での悪用されやすさを加味して決めるのがポイントです。
報告書を受け取ったあとは、修正と再診断までを一連の流れとして計画し、報告会も活用しながら社内で対応方針を合意していきます。これから診断を依頼する場合は、前述の「良い報告書の見分け方」の観点で、どんな報告書が納品されるかも確認してください。
自社に合う脆弱性診断サービスを探すなら、複数サービスの資料をまとめて請求して、診断の範囲や報告書の形式を比べてみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. 脆弱性診断報告書とは何ですか？
A. 脆弱性診断報告書とは、診断会社がWebアプリケーションやサーバーなどのIT資産を検査し、見つかった脆弱性と、その危険度・対策方法をまとめた成果物です。
脆弱性診断を発注すると、診断の実施後にこの報告書が納品されます。検出された脆弱性の一覧であると同時に、どこから手を付けるかを判断するための材料でもあり、多くは経営層向けの「総合評価」と、技術者向けの「指摘事項詳細」の二部で構成されます。
Q. 脆弱性診断報告書に載っている脆弱性は、すべて直さないといけませんか？
A. 脆弱性診断報告書の脆弱性は、必ずしも一度にすべてを直す必要はなく、危険度と自社への影響が大きいものから順に対応していくのが基本です。
危険度（CVSSやリスクレベル）が高いものを優先し、影響の具体性や自社システムでの悪用されやすさを加味して順番を決めるのが基本です。危険度の低いものは、リスクを把握したうえで次回の改修時などに計画的に対応すれば問題ないケースが多いものの、「対応しなくてよい」という意味ではない点には注意が必要です。
Q. 脆弱性診断報告書で脆弱性が検出されなかった場合、システムは安全だと考えてよいですか？
A. 脆弱性診断報告書で脆弱性が検出されなくても、それは「診断した範囲・時点で問題が見つからなかった」という意味であり、システムが将来にわたって完全に安全であることを保証するものではありません。
診断の対象外だった画面・機能や、診断後に追加・変更した箇所には、別のリスクが残っている可能性があります。また新しい脆弱性は日々見つかるため、一度の診断で終わりにせず定期的に確認し続けることが重要です。報告書には「診断対象URL一覧」があるので、どこまでを検査した結果なのかを必ず確認しておきましょう。
Q. 脆弱性診断報告書の内容が専門的で理解できない場合はどうすればよいですか？
A. 脆弱性診断報告書が理解しづらい場合は、診断会社の報告会を活用して、不明な点を診断担当者に直接確認するのが確実です。
多くの報告書には用語を解説した付録（APPENDIX）が付いており、まずそこで脆弱性種類やCVSSの意味を確認できます。それでも判断に迷う影響や優先順位は、報告会や問い合わせ窓口で質問できます。自社に技術者がいない場合は、検出後の修正対応まで相談できる診断会社を選ぶと、報告書を読みこなす負担を抑えられます。
Q. 脆弱性診断を依頼してから報告書が届くまでどのくらいかかりますか？
A. 脆弱性診断報告書が届くまでの期間は診断の範囲や手法によって幅がありますが、一般的なWebサイトで、打ち合わせから診断・報告までおおむね3週間程度が一つの目安です。
診断対象のページ数や機能が多いほど期間は長くなり、人の手による手動診断を含む場合はさらに時間がかかる傾向があります。急ぎの案件に対応できるプランを用意している診断会社もあるため、サービスの公開スケジュールが決まっているときは、発注時に納品時期を相談しておくと安心です。
Q. 脆弱性診断報告書で指摘された脆弱性は、修正後に再診断を受ける必要がありますか？費用はかかりますか？
A. 脆弱性診断の再診断は義務ではありませんが、修正が正しく効いているかを確認するために受けることが推奨され、再診断がプランに含まれるか追加費用になるかは契約内容によって異なります。
多くの診断会社が、本診断で検出した脆弱性を対象にした再診断（修正確認診断）を用意しており、修正前後の検出項目を比較できる形で結果を示します。再診断の回数が料金に含まれているプランもあれば、別料金のこともあるため、発注時に確認しておくと安心です。
Q. 脆弱性診断（報告書）はどのくらいの頻度で受けるべきですか？
A. 脆弱性診断は、システムに大きな変更があったタイミングに加え、最低でも年1回、推奨は3〜6か月ごとの定期的な実施が目安とされます。
新しい脆弱性は日々見つかり、機能追加や改修によって新たな弱点が生まれることもあるため、一度の診断で終わりにせず継続的に受けることが重要です。具体的な頻度は、自社サービスの重要度や扱うデータの機密性、セキュリティポリシーに応じて決めるのが実務的です。
Q. 脆弱性診断報告書を取引先の監査やセキュリティチェックシートの対応で提出できますか？
A. 脆弱性診断報告書は、取引先のセキュリティ評価や監査への対応として、自社のセキュリティ対策状況を示す資料として提出されることがあります。
ただし報告書には、検出された脆弱性の内容や発生箇所など機密性の高い情報が含まれます。そのまま全文を提出するのではなく、総合評価（サマリー）部分の提示にとどめる、提出範囲を診断会社に相談するといった配慮が安全です。報告書の取り扱い条件が契約で定められている場合もあるため、提出前に確認が必要です。
Q. 脆弱性が記載された脆弱性診断報告書は、どのように保管・管理すればよいですか？
A. 脆弱性診断報告書は、未修正の脆弱性の在りかを示す機密情報として、アクセスできる人を限定し、厳重に保管する必要があります。
報告書が外部に漏れると、攻撃者に自社システムの弱点と発生箇所を教えることになりかねません。報告書の冒頭には取り扱い上の注意が記載されていることが多いので、その指示に従い、共有する範囲を修正対応に必要な関係者に絞って管理することが重要です。
脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、脆弱性診断・セキュリティ診断サービスの最新資料を無料で一括請求できます。診断の範囲や報告書の形式、再診断の対応などを比べながら、自社に合う依頼先を検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
