保守契約を結んでいる開発会社に脆弱性（＝ソフトウェアの弱点）の修正を相談したところ、「保守の範囲外です」と言われ、数十万円の見積もりが届いた。高いのか安いのか、そもそも払うべきなのかが分からず、手が止まってしまう方は少なくありません。
「保守の範囲外と言われた脆弱性の修正に、数十万円の見積もりが出た。妥当かどうか判断する材料がない」
先に結論をお伝えします。金額そのものの相場を当てようとするより、「見積もりの中身を分解して、何に何時間かかるのかを説明してもらう」ほうが、確実に妥当性を判断できます。 脆弱性の修正は、部品を1つ入れ替えるだけで済むものから、周辺の機能の作り直しまで必要なものまで幅が広く、同じ「脆弱性対応」でも金額が大きく変わるためです。
この記事では、見積もりを受け取ったときに発注者が確認する5つの見方、よくある失敗、そのまま使える質問例を整理します。金額の妥当性を断定するものではなく、あくまで判断の材料を揃えるための一般的な考え方です。契約の解釈など個別の判断は、弁護士など専門家にご相談ください。
脆弱性の修正が「保守の範囲外」で高額になりやすい3つの理由
開発会社が不誠実だと決めつける前に、金額が大きくなる構造を知っておきましょう。
理由1：修正の中身が「バージョンを上げるだけ」とは限らない
脆弱性の修正は、多くの場合、使っている部品（ライブラリ・フレームワーク・OSなど）のバージョンアップ（＝新しい版に入れ替えること）で行います。ただし、古い版から大きく飛ぶと、自社のプログラムの書き方が新しい版に合わなくなり、書き換えが必要になることがあります。この場合、修正作業というより「改修」に近い工数になります。
理由2：直したあとの確認（テスト）が作業の大部分を占めることがある
部品を入れ替えると、関係のない機能が動かなくなる可能性があります。そのため、今まで動いていた機能が変わらず動くかを確かめるテストが必要です。システムの規模が大きいほど、この確認の工数が増え、見積もりの大きな割合を占めます。
理由3：保守契約が「障害の復旧」中心で、予防的な修正が想定されていない
保守が「止まったら直す」「問い合わせに答える」といった内容で作られていると、まだ何も起きていない段階の修正は範囲外として扱われがちです。これは契約の書き方の問題で、どちらかが悪いという話ではありません。契約の範囲の考え方は、次の記事でも整理しています。
見積もりが妥当かを判断する5つの見方
ここからが本題です。見積もりを受け取ったら、次の5つを順に確認してください。責める口調ではなく、「内容を理解したいので教えてください」という姿勢で聞くと、情報が出やすくなります。
1. 作業が「調査」「修正」「テスト」「反映」「報告」に分かれているか
「脆弱性対応一式 ◯◯万円」のように1行にまとまっている見積もりは、妥当性を判断できません。まず、作業ごとに分けて書いてもらいましょう。分けるだけで、どこに工数が集中しているかが見えます。
| 作業 | 確認したいこと |
|---|---|
| 調査 | 何を調べるのか。すでに調査済みで、費用が重複していないか |
| 修正 | どの部品を、どの版まで上げるのか |
| テスト | どの範囲の機能を、どう確認するのか |
| 反映 | 本番環境への反映の手順と、夜間・休日の作業の有無 |
| 報告 | 報告書の作成が含まれるか |
2. 工数（人日・人月）と単価が書かれているか
金額だけでなく、「何人が、何日かけるか」と「1人1日あたりの単価」が分かれば、見積もりの組み立てが確認できます。単価が、今の保守契約や過去の見積もりと大きく違う場合は、理由を聞いてみましょう。人月・人日（＝1人が1か月・1日働いたときの作業量の単位）は、見積もりでよく使われる言い方です。
3. 修正の「必要性」と「緊急度」を説明してもらう
すべての脆弱性を、すぐに高額な費用をかけて直す必要があるとは限りません。その脆弱性が自社のシステムで実際に悪用されうる条件なのか、影響の大きさ（情報が漏れる・止まるなど）と、悪用される可能性の高さを、開発会社に説明してもらいます。判断に迷うときの考え方は、こちらの記事も参考にしてください。
4. 代替案（段階的な対応）がないか確認する
一度に全部直すと高額でも、次のように段階を分けられることがあります。
- まず緊急度の高い部分だけ直し、残りは次の定期保守に回す
- すぐに直せない間は、設定の変更や通信の制限などで悪用しにくくする一時的な対策を入れる
- 使っていない機能は、直すのではなく停止・削除する
こうした代替案が見積もりに入っているか、聞いてみる価値があります。ただし、一時的な対策で「これで絶対安全」とは言えない点は、開発会社と共有しておいてください。
5. 第三者の目で比べる材料を持つ
数十万円規模の見積もりなら、別の会社に内容を見てもらう（セカンドオピニオン）のも選択肢です。相見積もりを取るというより、「この見積もりの作業内容は一般的か」を確認する目的です。その際は、現行システムを知らない会社が見積もるには調査の工数が追加で必要になる点も考慮してください。また、IPA（情報処理推進機構）の「中小企業の情報セキュリティ対策ガイドライン」には、ソフトウェアを最新の状態に保つことなど、中小企業が段階的に取り組む対策の考え方が示されています。自社が何を優先すべきかを整理する材料になります。
📰 出典：IPA「中小企業の情報セキュリティ対策ガイドライン」（執筆時点：2026年11月。第4.0版が2026年3月に公開）
やりがちな失敗
- 金額の大きさだけで「ぼったくりだ」と判断する：修正の中身が改修に近い場合、高額になるのは自然です。内訳を見る前に決めつけないことが大切です。
- 高いからと、修正を先送りして放置する：内容次第では、被害が起きたときの対応費用のほうが大きくなるおそれがあります。段階的な対応を相談しましょう。
- 口頭だけで合意して進める：後から「範囲に含まれていたはず」「いや別だった」と揉めます。やり取りはメールなど文書に残してください。
- 次回のための契約の見直しをしない：今回の件を、更新時に「脆弱性対応の範囲」を決め直すきっかけにしましょう。
発注者がやること チェックリスト
- ☐ 見積もりが「調査・修正・テスト・反映・報告」に分かれているか確認した
- ☐ 工数（人日・人月）と単価が書かれているか確認した
- ☐ 脆弱性の影響の大きさと、緊急度の説明を受けた
- ☐ 段階的な対応や、一時的な対策の案があるか聞いた
- ☐ 内容によっては、第三者に見積もりの作業内容を確認してもらうか検討した
- ☐ やり取りと合意を、メールなど文書に残した
- ☐ 今後の保守契約で、脆弱性対応の範囲を決め直す予定を立てた
開発会社への質問例
そのまま打ち合わせで使える質問です。
- 「見積もりを、調査・修正・テスト・反映・報告に分けて、それぞれの工数を教えていただけますか」
- 「今回の修正は、部品のバージョンを上げるだけで済みますか。それとも、プログラムの書き換えも必要ですか。必要な場合、その理由を教えてください」
- 「この脆弱性は、うちのシステムでどのような条件のときに悪用されうるのか、影響の大きさと緊急度を教えてください」
- 「緊急度の高い部分だけ先に対応して、残りを後に回す進め方は可能でしょうか。その場合、見積もりはどう変わりますか」
- 「今後同じような修正が出たときに備えて、保守契約でどこまでを月額に含められるか、更新時に相談させていただけますか」
まとめ
「保守の範囲外」と言われた脆弱性の修正に数十万円の見積もりが出たときは、金額の高い・安いを即断せず、作業と工数を分けてもらい、必要性・緊急度・代替案を確認することが、妥当性を判断する近道です。開発会社と対立するのではなく、一緒に内容を理解する姿勢で進めると、納得感のある結論に近づけます。
契約上の範囲の解釈や、費用負担をめぐる個別の判断は、弁護士など専門家にご相談ください。
あわせて読みたい関連記事
