保守契約に脆弱性対応は含まれる？緊急パッチで追加費用が出る場合の見分け方と、開発会社への質問

2025年3月29日2026年10月4日

「毎月保守費を払っているのだから、セキュリティの穴が見つかったときも直してもらえる」と思っていたのに、緊急の修正を頼んだら「それは別途お見積りです」と言われた。こうした行き違いは、保守契約を結んでいる発注者の間でよく起きます。

「保守契約に脆弱性対応が含まれているのか分からない。緊急のパッチ適用で追加費用を請求されるのか、不安です」

先に結論をお伝えします。「保守契約に脆弱性対応が含まれるか」は、契約書の「保守の範囲」にどう書いてあるかで決まり、名前が「保守」というだけでは決まりません。多くの場合、①ソフトウェアの更新を「見つけて知らせる」作業、②更新を「適用する」作業、③更新で画面や機能が壊れていないか「確認する」作業は、別々の項目として扱われます。契約を結んだ今のうちに、この3つがどこまで月額に入っているかを書面で確認しておけば、緊急時の揉め事はかなり防げます。

この記事では、脆弱性（＝システムやソフトウェアに見つかった、悪用されうる弱点）への対応が保守契約のどこに入りうるのかを整理し、発注者のチェックリストと開発会社への質問例をお渡しします。

なぜ「含まれているはず」が食い違うのか

「保守」という言葉が指す範囲は会社ごとに違う

発注者は「保守＝システムを安全に動かし続けてくれること」と受け取りがちです。一方、開発会社にとっての保守は「障害が起きたときの調査・復旧」「問い合わせ対応」など、契約書に列挙した作業を指していることがあります。同じ言葉でも、頭に描いている範囲がずれているのです。

保守・運用の契約については、経済産業省の研究会が「情報システム・モデル取引・契約書」を公表しています。受託開発に加えて保守運用も対象にしたモデルで、役割分担や範囲を契約であらかじめ明確にしておくことの重要性が整理されています。

📰 出典：経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第一版〉」

ここから言えるのは、「保守に何が含まれるか」は自然に決まるものではなく、契約で決めておくものだということです。

脆弱性対応は「作業の量」が読みにくい

脆弱性対応は、いつ・どれくらいの作業になるかが事前に分かりません。何も起きない月もあれば、重大な脆弱性が公表されて数日間バタバタする月もあります。そのため開発会社は、月額の定額に含めるのか、発生したら別料金にするのかを分けて設計することが多くなります。これは悪意ではなく、作業量が読めないものを定額にするリスクをどう分担するかという事情です。

脆弱性対応を3つの作業に分けて考える

月額に入っているかどうかを確認するとき、次の3つに分けて見ていくと整理しやすくなります（以下は一般的な分け方で、実際の区切りは会社・契約によって異なります）。

作業	中身	月額に含まれやすさの傾向
① 把握・通知	使っているソフトの脆弱性情報を見て、自社のシステムに関係があるか知らせる	含まれる場合と、別オプションの場合がある
② 適用	修正版への更新を本番環境へ反映する	軽微なもの（小さな更新）のみ含み、大きなものは別見積もりのことが多い
③ 確認	更新後に画面・機能・他システムとの連携が壊れていないか検証する	適用とセットか別項目かが分かれる

特に注意したいのは、修正の適用そのものは短時間でも、その後の動作確認に時間がかかる点です。更新によって他の機能が動かなくなることがあり、その確認・修正まで含めると工数が膨らみます。見積もりを見るときは「適用」と「確認」が別々に書かれているかを見てください。

追加費用になりやすいケース・なりにくいケース

契約の書き方次第ですが、一般的には次のような傾向があります。

追加費用になりにくい：契約で「セキュリティ更新の適用」「脆弱性情報の確認と通知」が保守項目として明記されている／軽微な更新で作業時間があらかじめ決めた範囲に収まる
追加費用になりやすい：契約の保守項目が「障害対応」「問い合わせ対応」のみ／フレームワークやOSの大きなバージョンアップが必要で、プログラムの改修を伴う／契約時の対象外とされている古いソフトの修正

「緊急だから追加費用」と言われた場合も、その金額が契約書のどの条項（単価・時間数・緊急対応の割増）に基づくのかを確認すれば、納得して支払える金額かどうかが判断しやすくなります。

揉めないために、契約時・更新時にやっておくこと

保守の範囲を3つの作業に分けて書面にする：把握・通知／適用／確認のそれぞれが月額内か別料金かを一覧にしてもらう。
緊急対応のルールを決める：緊急とは誰がどう判断するか、連絡の受付時間、休日夜間の対応、割増の有無を決めておく。
対象のソフトを一覧にする：OS・Webサーバー・データベース・フレームワーク・ライブラリなど、何が保守の対象かを書き出してもらう。対象外のものがあれば、それも書いてもらう。
上限と事前承認を決める：1回の追加費用が一定額を超える場合は、作業前に見積もりを出してもらい、承認してから進める。
更新時に見直す：契約の更新時期に「この1年で実際に対応した脆弱性と、かかった費用」を報告してもらい、範囲を見直す。

やりがちな失敗

契約書を読まずに「保守＝何でも対応」と思い込む：いざというときに範囲外と言われ、緊急の判断を迫られます。
緊急の連絡を口頭やチャットだけで済ませる：後から「依頼した」「聞いていない」の水掛け論になります。依頼内容と了承した費用は、メールなど記録に残る形にしましょう。
脆弱性のニュースを見たときに、自社に関係するか確認する窓口がない：誰が確認するかが決まっていないと、対応が遅れて被害の可能性が高まります。