システム保守契約書レビューの基本｜定義・チェックリスト・立場別リスク
こんにちは。LegalAgent 代表弁護士の朝戸です。
システム保守契約書は、ソフトウェア開発契約書と比べると目立ちにくい契約です。しかし内容の詰めが甘いと、そのしわ寄せは障害が起きた瞬間に現れます。保守対象、対応時間、追加費用の境界が曖昧なままだと、ユーザー側は「当然やってもらえる」と考え、ベンダ側は「保守範囲外です」と考える場面が生まれやすいためです。
開発が終わった後のシステムには、軽微な不具合対応やセキュリティパッチ、障害時の一次対応など、日々の業務が続きます。契約書レビューでは、こうした業務がどこまで保守契約に含まれるのかを、障害が起きた日を思い浮かべながら一つずつ確認していきます。
保守と運用の境界、請負と準委任の境界
システム保守契約とは、既に稼働しているシステムについて、継続的な維持管理や障害対応、軽微な修正などを委託する契約です。対象は業務システムやWebサービスに限らず、SaaS連携やクラウド環境まで及ぶことが多く、契約類型としては準委任的な性質が強い場合がほとんどです。ベンダは成果物の完成を約束するのではなく、専門知識に基づいて問い合わせや障害に対応し、システムを利用可能な状態に保つ業務を行います。個別の改修や追加機能開発が含まれる部分は、請負に近い扱いにした方が実務に合うこともあります。
保守と運用の違いも、契約書を読む前に整理しておきたい点です。保守は不具合修正やパッチ適用、障害調査など、システムを維持するための作業を指すことが多く、運用は日次処理やアカウント管理、監視、バックアップ確認など、システムを日常的に動かす業務を指すことがあります。この二つを契約書で分けて扱うのか、まとめて扱うのかによって、費用の考え方も責任の所在も変わってきます。
対応時間とSLAは、現実に守れる水準か
システム保守契約では、SLA、つまりサービスレベル合意の設計が対応時間の実効性を左右します。問い合わせ受付時間や復旧目標時間、稼働率などを定めるものですが、すべての保守契約に詳細なSLAが要るわけではありません。事業上重要なシステムほど、最低限の対応水準を数字で決めておいた方が、障害時の期待値がずれにくくなります。
レビューで見るべきは、平日営業時間内だけの対応なのか、夜間休日対応があるのか、緊急連絡先はメールとチャットのどちらが優先されるのかという運用の細部です。稼働率や復旧目標を定める場合は、除外時間やメンテナンス時間の扱い、サービスクレジットと損害賠償の関係まで見ておくと、ユーザー側は努力目標だけの条項になっていないかを、ベンダ側は外部クラウドの障害まで自社のSLA違反として扱われないかを、それぞれ点検できます。
費用の境界線と、障害発生時の流れ
月額保守料に含まれる作業と、別途費用になる作業の境界は、保守契約でもっとも揉めやすい論点です。追加改修や仕様変更、夜間休日対応、オンサイト対応などが一式に含まれるのか、超過分にどのような単価と承認手続が適用されるのかを、契約書の文言と運用イメージの両方から確認します。上限工数を定める場合は、超過時の単価と承認フローもセットで見ておきます。
障害対応の条項では、障害の定義と重大度の区分、報告方法、原因調査から復旧報告、再発防止策までの流れを見ます。原因がアプリケーションの不具合なのか、インフラの問題なのか、外部サービスの障害なのかがすぐには判別できない場合も多いため、調査範囲や第三者サービスとの関係を契約書側で整理しておかないと、責任の押し付け合いになりやすくなります。脆弱性情報が公開されたときに誰が影響調査とパッチ適用を担うのか、緊急対応費用が月額保守料の枠内かどうかも、あわせて決めておきたい事項です。
セキュリティと引継ぎ、終了後を見据えた条項
本番環境へのアクセスを伴う保守業務では、通常の業務委託契約よりも具体的な管理条項が求められる場合があります。アクセス権限の付与や削除、ログ管理などを、セキュリティ条項として個別に見ておくべき理由です。再委託先の管理や事故発生時の報告期限も、本番環境に触れる保守業務では見落とせません。
保守契約は継続契約であるため、更新や解約予告期間だけでなく、重大障害時の解除、支払遅延時の停止、終了時のデータ返還やアカウント返却、他社への引継ぎ支援まで確認します。保守に必要なソースコードや設定情報、インフラ構成図がベンダ側にしか残っていない場合、契約が終わったときに別ベンダへ移行できなくなります。終了時の資料提供と移行支援を契約書に明記しておくことが、ベンダロックインを避ける実務上の手当てになります。
ユーザー側とベンダ側、見え方が変わるリスク
ユーザー側の最大のリスクは、保守契約を結んでいるのに、実際に必要な対応が契約範囲外になっていることです。問い合わせ対応だけが含まれ、不具合修正は別途費用、夜間休日対応なしという契約では、重要システムを守るには物足りません。ベンダロックインへの備えとして、契約終了時の引継ぎと資料提供の条項も見ておくべきです。
ベンダ側のリスクは、保守範囲が広がりすぎることです。月額固定の保守料で、新機能追加や仕様変更、他社サービスの不具合対応まで求められると、想定した工数を大きく超えるおそれがあります。保守対象外の作業、別途見積り事項、上限工数、緊急対応費用の扱いを明確にしておくことが、ベンダ側の防御線になります。SLAや損害賠償の責任も慎重に見る必要があり、システム停止によるユーザー側の逸失利益や信用毀損まで無制限に負う条項は、保守料とのバランスを欠くことがあります。
双方に共通するのは、障害時のコミュニケーション設計です。連絡体制や優先順位が契約書に書かれていないと、現場は誰に連絡すべきか分からず、初動が遅れます。重大障害では技術対応だけでなく、ユーザー企業側の顧客対応や経営判断も動き出すため、契約書はその前提となる役割分担を明確にするものであるべきだと考えています。
生成AIは、保守対象や対応時間、SLAといった典型的な論点を洗い出す作業には向いています。一方で、対象システムが社内の一部業務を支える小規模ツールなのか、顧客向けサービスの基幹システムなのかまでは、契約書だけを読んでも分かりません。対象システムの重要度や利用者数、障害時に想定される損害を人が補ってはじめて、AIが返す一般的なチェックリストが実務で使える水準になります。