保守契約の更新で脆弱性対応をどう書き足す？契約書に入れたい6つの項目と開発会社への質問例

保守契約の更新時期が近づき、「そういえば、脆弱性（＝システムの弱点）への対応は今の契約でどこまで含まれているのだろう」と気になった方は多いはずです。契約書を開いても「システムの保守」としか書かれておらず、何をどう書き足せばいいのか分からない、というのはよくある状況です。

先に結論をお伝えします。契約書に法律用語を並べる必要はなく、「誰が」「何を」「いつまでに」「いくらで」やるかを、6つの項目に分けて決めておけば十分に実用的です。更新は、範囲をあいまいなままにしない絶好のタイミングです。

この記事では、保守契約の更新で脆弱性対応について書き足したい項目を、そのまま使えるチェックリストと開発会社への質問例とあわせて解説します。なお、契約の法的な有効性や条文の表現は、個別の事情で変わります。最終的な文言は弁護士などの専門家に確認してください。

保守契約の更新で、脆弱性対応があいまいになりやすい理由

まず、なぜ今の契約書では分かりにくいのかを押さえておきましょう。理由が分かると、何を書き足すべきかが見えてきます。

• 「保守」という言葉が指す範囲が会社ごとに違う：障害が起きたときの復旧だけを指す場合もあれば、定期的な更新作業まで含む場合もあります
• 脆弱性は、契約した後から見つかる：システムを作った時点では存在が知られていなかった弱点が、後から公表されることがあります。そのため、契約書に最初から想定して書かれていないことが多いのです
• 対応が「作業」なのか「改修」なのか線引きが難しい：部品のバージョンを上げるだけで済む場合もあれば、プログラムの修正が必要な場合もあり、後者は保守の範囲外として別見積もりになることがあります

どれも開発会社が不誠実という話ではなく、契約を結ぶ時点では見えないことが多い、という構造的な事情です。だからこそ、更新のタイミングで「見つかったときの決めごと」を先に書いておく価値があります。

脆弱性対応の費用の考え方については、次の記事も参考になります。

契約書に書き足したい6つの項目

1. 対象範囲：どのシステム・どの部品が対象か

「システム全体」とだけ書かれていると、サーバーのOS、WordPressなどのCMS（＝サイトを管理する仕組み）、プラグイン、外部から使っているライブラリ（＝部品）のどこまでが対象なのか分かりません。対象の一覧（製品名とバージョン）を別紙にして、契約書から参照する形にすると、更新のたびに見直しやすくなります。

2. 情報の受け渡し：脆弱性の情報を誰が見つけ、誰に知らせるか

脆弱性の情報は、JVN（＝日本国内の脆弱性情報を集めたサイト）などで公表されます。それを開発会社が定期的に確認して発注者に知らせるのか、発注者側から問い合わせるのかを決めておきます。「知らせる」と書く場合は、頻度（例：月1回の報告）と連絡手段も一緒に書きます。

3. 対応の期限：深刻度ごとの目安の時間

すべての脆弱性を同じ速さで直すのは現実的ではありません。そこで、深刻度（重大・高・中・低など）に応じて、「確認の連絡は何営業日以内」「対策の実施は何日以内を目標」のように目安を決めます。深刻度は、CVSS（＝脆弱性の深刻さを0〜10の点数で示す世界共通の指標）の点数を目安にする方法が一般的です。目標であって保証ではない書き方にするか、保証にするかで費用が変わるため、開発会社と相談します。

4. 費用の線引き：保守料金に含むもの、別見積もりになるもの

もっともトラブルになりやすい項目です。次のように、作業の種類ごとに、月額の保守料金に含むか、別見積もりかを表にして書いておくと、後で揉めにくくなります。

作業の種類	例	書き方の例
調査	自社のシステムが対象か確認する	月額に含む／1件あたり◯時間まで含む
軽微な更新	部品のバージョンを上げるだけ	月額に含む／別見積もり
改修を伴う対応	プログラムの修正、動作確認が必要	事前に見積もりを提示し、承認後に着手
緊急対応	休日・夜間の対応	割増の有無と、その条件

5. 緊急時のルール：連絡先・承認の方法・休日対応

深刻な脆弱性が見つかったときは、見積もりの承認を待っている間にも状況が進みます。緊急時の連絡先（担当者2名以上が望ましい）、メールなどでの簡易な承認の方法、休日・夜間に対応するかどうかを決めておきます。「何かあったら誰に電話すればよいか」が分かるだけでも、いざという時の慌て方が大きく変わります。

6. 実施の記録：何をいつ直したかを残す

対応した内容を報告書や作業履歴として発注者に渡すと書いておきます。次の見直しの材料になるだけでなく、担当者が替わったときや開発会社を変えるときの引き継ぎ資料にもなります。

更新の話し合いの進め方

書き足したい内容が決まったら、次の順番で進めると無理がありません。

1. 今の契約書で「脆弱性」「セキュリティ」「更新」という言葉が出てくる箇所を探す：何も書かれていなければ「未定義」だと分かります
2. 過去1年間に実際にあった対応を、開発会社に一覧にしてもらう：実績があると、現実的な範囲や頻度が決めやすくなります
3. 6項目のうち、今回の更新で決める項目に優先順位をつける：全部を一度に決めなくても、まず「対象範囲」「費用の線引き」「緊急時の連絡先」だけでも十分です
4. 開発会社に案を作ってもらい、社内で確認する：開発会社が作った案のほうが、実際の運用と合いやすくなります
5. 法務担当や弁護士に、文言のチェックを依頼する：個別の契約の有効性や責任の範囲は、専門家の判断が必要です

やりがちな失敗

• 「脆弱性対応も含む」とだけ書く：どこまで含むのかが分からず、実際の場面で解釈が分かれます
• 対応の期限を保証として書いたが、費用に反映されていない：開発会社の体制が追いつかず、守られない契約になります
• 口頭の約束で済ませる：担当者が替わると、約束が引き継がれません
• 自社の対象システムを把握していない：対象の一覧が古いままだと、更新後も「見ていなかった部品」が残ります

公的な参考資料

中小企業向けのセキュリティ対策については、IPA（情報処理推進機構）が公開している「中小企業の情報セキュリティ対策ガイドライン」があります。執筆時点（2026年11月）では第4.0版（2026年3月公開）が最新で、基本方針や規程のサンプル、自社診断のシートなどが付録として用意されています。

📰 出典：IPA「中小企業の情報セキュリティ対策ガイドライン」

また、システム開発の契約の全体像を知りたい場合は、IPAの「情報システム・モデル取引・契約書（第二版）」が参考になります。保守運用の細かな条項はシステムごとに異なるため、そのまま転用せず、自社の状況に合わせて専門家と確認してください。

📰 出典：IPA「情報システム・モデル取引・契約書」

発注者がやること チェックリスト

• ☐ 今の契約書で、脆弱性やセキュリティについて書かれた箇所を探した
• ☐ 保守の対象となるシステム・部品の一覧（製品名とバージョン）を開発会社からもらった
• ☐ 脆弱性の情報を「誰が見つけて、誰に知らせるか」を決めた
• ☐ 深刻度ごとの対応期限の目安を決めた（保証か目標かも確認した）
• ☐ 保守料金に含まれる作業と、別見積もりになる作業を表にした
• ☐ 緊急時の連絡先と、簡易な承認方法を決めた
• ☐ 対応の記録（報告書）を受け取る約束にした
• ☐ 最終的な文言を専門家に確認してもらう予定を入れた

開発会社への質問例

そのまま打ち合わせで使える一文を挙げます。

• 「現在の保守料金には、脆弱性の情報の確認と、当社のシステムが対象かの調査は含まれていますか」
• 「脆弱性が見つかった場合、部品の更新だけで済む対応と、プログラムの修正が必要な対応は、どこで線引きされますか」
• 「深刻度が高い脆弱性について、連絡と対策の実施までの目安の時間はどのくらいですか」
• 「休日や夜間に緊急の対応が必要になった場合、割増の費用や対応できない時間帯はありますか」
• 「過去1年間に行った脆弱性の対応を、日付と内容の一覧でいただけますか」

まとめ

保守契約の更新で脆弱性対応を書き足すときは、次の6つを決めておけば十分に実用的です。

1. 対象範囲（システム・部品の一覧）
2. 情報の受け渡し（誰が見つけ、誰に知らせるか）
3. 対応の期限（深刻度ごとの目安）
4. 費用の線引き（含むものと別見積もり）
5. 緊急時のルール（連絡先・承認・休日対応）
6. 実施の記録（報告書）

すべてを一度に完璧にする必要はありません。まずは「対象範囲」「費用の線引き」「緊急時の連絡先」の3つから始めて、次の更新で少しずつ足していく進め方でも問題ありません。なお、本記事は一般的な考え方の紹介であり、個別の契約内容の判断は弁護士などの専門家にご確認ください。

脆弱性の修正を先送りしたときの費用と責任の考え方も、あわせて確認しておくと安心です。

あわせて読みたい関連記事