脆弱性診断の指摘の修正を依頼する前に｜優先順位・依頼範囲・再診断の合格条件の決め方

脆弱性診断の指摘の修正を依頼する前に、①報告書の危険度の順ではなく「外から触れるか・ログインの前か後か・個人情報や他人のデータに届くか」で並べ直す、②指摘の種類ごとに直す場所と頼む範囲を分ける、③再診断で何をもって「直った」とするかを修正前に決める、の3つを済ませてください。この3つが決まっていれば、元の開発会社に頼む場合も別の会社に頼む場合も、見積の範囲がぶれにくくなります。

この記事は、取引先の要請や監査で自社のWebサービス・業務システム・会員サイトの脆弱性診断を受け、報告書に「高」「中」の指摘が並んでいるのに、作った開発会社が動かない（契約が切れている・返事が遅い・見積が出ない）事業責任者・情シス担当の方に向けたものです。

なお、当社（AI革命株式会社）は脆弱性診断・ペネトレーションテスト・再診断は行いません。診断と再診断は専門の診断会社に依頼してください。当社が受けるのは、報告書と該当コードの調査、修正（コード・設定・ライブラリの更新）、修正内容の記録と再診断への引継ぎです。他社が作ったシステムでも、言語やフレームワークを問わず対応できます。

この進め方が合う場合・合わない場合

報告書を受け取ったからといって、外部の開発会社に頼むのが正解とは限りません。先に、自社の状況がどれに当たるかを確かめてください。

報告書の指摘を「外から触れるか・ログイン前後・届く情報」で並べ直す

出典: FIRST CVSS 公式

報告書の「高・中・低」は、主に技術的な深刻度です。脆弱性の深刻度の国際的な基準であるCVSS（v4.0、FIRST）は、基本の評価に加えて、実際に悪用されているか（Threat）や自社の環境（Environmental）で補うことを強く推奨しています（CVSS v4.0 仕様、2026-10-14確認）。つまり、報告書の危険度には「その画面に誰が触れるか」「漏れたら何が困るか」という自社の事情は入っていません。

そこで、指摘ごとに次の3点を書き足して並べ直します。

• 外から触れるか: インターネットから誰でも開けるか。社内ネットワークやVPNからしか開けないか
• ログインの前か後か: ログインしなくても試せるか。ログインが要るなら、そのアカウントは誰でも作れるか
• 何に届くか: 個人情報、他の顧客のデータ、決済・注文、管理機能のどれに届くか

架空の報告書3項目での並べ直し（説明用・架空データ）

以下は架空の会員サイトの報告書から3項目を取り出した例です。実在の案件・報告書ではありません。

この例では、報告書では「中」のBを1番目にしています。誰でも会員登録できるので実質的に外から試せ、手順も簡単で、他人の個人情報に届くからです。Aは届く範囲が最も広いので放置はできませんが、触れる人が限られるため2番目にしています。

ただし、条件が変われば順番も変わります。管理画面がインターネットから開ける作りなら、Aが1番目です。並べ直しは「報告書を無視する」作業ではなく、自社の事情を足して判断する作業です。

ライブラリなどの部品に既知の脆弱性（CVE番号つき）が指摘されている場合は、米国CISAの「実際に悪用が確認された脆弱性」の一覧（KEVカタログ、2026-10-14確認）に載っているかも確かめてください。載っていれば順番を上げる材料になります。

指摘の種類で、直す場所と頼む範囲が変わる

出典: IPA（情報処理推進機構） 公式サイト

「指摘を直す」と一口に言っても、設定を1行変えれば済むものから、業務のルールを決め直さないと直せないものまであります。見積の幅が大きく変わるのはこの違いのためです。分類はOWASP Top 10:2025（Webアプリの代表的な脆弱性の分類、公式、2026-10-14確認）に合わせています。

表の中で、発注者がいちばん気をつけたいのは認証・権限の指摘です。たとえば「店舗のスタッフは自店舗の会員だけを見られる」「本部は全店舗を見られる」といったルールが決まっていないと、開発会社はどこまで制限すればよいか分かりません。この決定は開発会社ではなく、事業責任者の仕事です。

報告書に載った画面だけ直しても終わらない

診断は、決められた範囲の画面やリクエストを調べた結果です。同じ書き方のプログラムが診断していない画面にもあれば、そこにも同じ問題が残ります。修正を頼むときは「指摘箇所の修正」に加えて「同じ作りの箇所を探して直す」を範囲に入れるかどうかを決めてください。入れない場合は、残る可能性があることを記録に残します。

WAFを入れただけで「直った」としない

IPA『安全なウェブサイトの作り方』（改訂第7版 第4刷、2021年3月31日公開。IPA、2026-10-14確認）は、対策を、脆弱性の原因そのものをなくす「根本的解決」と、攻撃による影響を減らす「保険的対策」に分けて示しています。WAF（不正な通信を手前で止める仕組み）は、プログラムの原因そのものをなくすものではありません。プログラムの修正に時間がかかる間の備えとして使い、修正の代わりにはしないでください。同資料には脆弱性ごとの問題のあるソースコードと修正例、チェックリスト（Excel版あり）が載っています。2021年の資料ではあるものの、修正方針を開発会社とすり合わせるときの共通の参照先として使えます。

元の開発会社に頼むか、別の会社に頼むか

元の会社が対応できるなら、システムを一番よく知っているのはその会社です。ただ、返事が来ない・見積が出ないまま時間が過ぎるなら、別の会社に頼む準備を並行して進めます。どちらに頼むにしても、次の項目を先に確認してください。

元の会社から修正の見積が出た場合は、追加開発の見積の確認方法が参考になります。別の会社へ移す場合の引継ぎの進め方は開発会社を変えるときの引継ぎ、会社の選び方はシステム改修会社の選び方で詳しく書いています。

再診断の合格条件を、修正の前に決める

修正が終わってから「どうなれば合格か」を考えると、診断会社・開発会社・自社の間で話がかみ合わなくなります。修正を頼む時点で、次の表を埋めておくのがおすすめです。

再診断の条件は診断会社ごとに違います。公開されている例では、cloudpackは危険度Medium以上の脆弱性を対象に、1案件につき1回の再診断を無償としています（リモート診断の場合。オンサイト診断は別見積。cloudpack 脆弱性診断、2026-10-14確認）。セキュアスカイプラスは自社の記事で、Webアプリケーション診断の再診断は危険度Medium以上が対象で、診断完了から3か月以内の1回を無償としていると説明しています（同社コラム、2026-10-14確認）。自社の契約にどう書かれているかを必ず確かめてください。

再診断は前回指摘した箇所だけを見る契約もあります。その場合、修正で新しく入った問題や、同じ作りを探して直した箇所は再診断の対象外です。そこを誰がどう確かめるか（修正側のテスト記録で示すのか、再診断の範囲を広げるのか）も、この時点で決めておきます。

直さない指摘を残すときの記録

すべての指摘を今すぐ直せるとは限りません。直さない、または後回しにすると決めた指摘は、理由を自社で記録しておきます。報告書は診断した時点の記録で、診断会社は後から記載の変更や指摘の削除に応じないことがあるためです（セキュアスカイプラスのコラムは、内容の変更や脆弱性の削除の要請には応じられないと説明しています）。取引先から「この指摘はどうなったか」と聞かれたとき、記録があれば説明できます。

「危険度が低いから直さない」だけでは理由になりません。直さないことで何が残るか、いつ見直すかを書いておくことが大切です。

自社でAIを使って進められる部分、会社に頼んだ方がよい部分

出典: GitHub Docs 公式

報告書の読み解きや下調べは、ChatGPTやClaudeなどの生成AIを使えば自社でもかなり進められます。ただし、報告書には攻撃の再現手順が書かれているので、外部のAIサービスに入れる前に、社内の利用ルールと、入力内容が学習に使われない設定かを確認してください。

Dependabotは、修正を含む最も小さい版への更新の提案を自動で作れますが、提案どおりに更新して問題が無いかは別に確かめる必要があります（GitHub Docs、2026-10-14確認）。自社に開発の担当者がいれば、修正の一部を社内でAIを使って進め、残りを外部に頼む分け方もできます。

修正を頼むときの費用の考え方

脆弱性の修正費用の相場は、公開されている一次情報が見つからなかったため、この記事では示しません。指摘の種類と件数、同じ作りの箇所をどこまで探すか、ソースコードや環境がそろっているかで大きく変わるためです。

費用は、診断と修正で分けて考えます。

当社の公開価格は既存システムの改修が100万円〜（税別）です。報告書と該当コードの調査、修正（プログラム・設定・部品の更新）、修正後の確認、修正一覧の作成と再診断への引継ぎを、指摘の内容に合わせて範囲に含めます。クラウドの利用料、外部サービスやライセンスの費用は実費で別にかかります。診断会社に払う診断・再診断の費用は含みません。

まず状況を知りたい場合は「調査のみ」も受けられます。調査のみ・調査と修正のどちらでも、作業に入る前に範囲と金額を示し、合意してから進めます。指摘が多く、作り直しの方が合理的に見える場合は、その判断も含めてお伝えします。

報告書の指摘の件数と危険度の内訳、対象システムの種類が分かれば、依頼範囲の候補と費用の目安をお返しできます。報告書の指摘を見て修正範囲を相談する

相談前に揃えておくもの・送らないもの

初回相談は無料・30分（オンライン）です。修正の範囲が決まっていなくても大丈夫です。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。

事前にあると話が早いもの

• 対象システムの種類（会員サイト、業務システム、ECなど）と、主に使う人
• 指摘の件数と危険度の内訳（例: 高2件・中5件・低8件）と、指摘の種類のおおまかな分け方
• 元の開発会社との関係（保守契約の有無、連絡がつくか）
• ソースコードの有無と置き場所、サーバー・クラウドの管理者権限を自社が持っているか
• 再診断の期限や、取引先への回答期限

初回の問い合わせフォームに送らないもの

• 報告書の本文（攻撃の再現手順が書かれているため）
• 管理画面・サーバーのID・パスワードなどの認証情報
• 実際の顧客データ

報告書の中身や認証情報の受け渡しが必要になるのは、依頼の範囲が決まってからです。そのときも、渡す範囲と期間を決めてから進めます。

よくある質問

危険度が「低」や「情報」の指摘も直す必要がありますか？

必ずしも全部を同時に直す必要はありません。ただし「低」でも、他の指摘と組み合わさると被害が大きくなることがあります。直さないと決めた指摘は、理由・代わりの対策・見直しの期限を記録し、取引先に聞かれたら説明できる状態にしておいてください。

元の開発会社に無償で直してもらえますか？

開発時の契約書の、契約不適合責任や保守の条項によります。期間や対象は契約ごとに決められているため、まず契約書を確認し、必要なら法務担当や弁護士に相談してください。無償の対象外でも、元の会社に有償で頼む方が早い場合もあります。

再診断は、修正した開発会社にお願いできますか？

当社は診断・再診断を行いません。再診断は、最初に診断した会社に頼むと、報告書と同じ手順で確かめられます。無償の再診断が契約に含まれていることもあります。当社は、再診断に必要な修正一覧を作って引き継ぎます。

ソースコードが手元に無い場合はどうすればよいですか？

まず元の開発会社、サーバー、GitHub等のリポジトリにあるかを確かめます。サーバー上のプログラムしか無い場合でも、それが最新か、改修してよい権利があるかを確認したうえで調査できることがあります。権利関係が不明なまま他社に渡すのは避けてください。

修正のためにサービスを止める必要はありますか？

プログラムや設定の修正は、検証用の環境で直して確かめてから本番に反映すれば、長時間止めずに済むことがあります。データベースの構造を変える修正や、部品の大きな版の更新では、短い停止が必要になる場合があります。止める必要があるかは、調査の段階で確かめてお伝えします。

報告書をChatGPTなどのAIに読ませてもよいですか？

報告書には攻撃の再現手順や内部の構成が書かれています。外部のAIサービスに入れる前に、社内の利用ルールと、入力内容が学習に使われない設定かを確認してください。対象のURLや固有の情報を伏せてから使う方法もあります。

報告書の「高・中」が並んだまま、誰に何を頼めばよいか決まらない場合は、指摘の件数と危険度の内訳、対象システムの種類だけお知らせください。初回相談（無料・30分・オンライン）で依頼範囲の候補と進め方を一緒に整理し、相談後に費用の目安を含む相談メモをお送りします。

報告書の指摘を見て修正範囲を相談する