システム保守契約書レビューの基本｜定義・チェックリスト・立場別リスク
こんにちは!Legal Agent 代表弁護士の朝戸です。
システム保守契約書は、ソフトウェア開発契約書と比べると目立ちにくい契約書かもしれません。しかし企業の現場では、保守契約の設計が甘いことで、障害対応、問い合わせ対応、追加改修、セキュリティ対応、データ復旧、責任範囲をめぐる問題が起きることがあります
開発が終わった後のシステムは、作って終わりではありません。日々の運用、軽微な不具合対応、法令改正や外部サービス仕様変更への対応、クラウド環境の更新、セキュリティパッチ、障害時の一次対応、バックアップ、アカウント管理など、多くの業務が続きます。これらをどこまで保守契約に含めるのかを曖昧にすると、ユーザー側は「当然やってもらえる」と考え、ベンダ側は「保守範囲外です」と考えることになりやすいです
この記事では、システム保守契約書の定義、レビューが重要になる理由、チェックリスト、ユーザー側・ベンダ側のリスク、AIレビューを使う際の注意点を整理します
この記事で分かること
この記事では、システム保守契約書レビューの基本について、基本的な意味、レビューで問題になりやすい条項、立場ごとの注意点、AIで確認するときに人が見落としてはいけない点を整理します。最初に全体像をつかみ、その後にチェックリストで実務上の確認順序を追える構成にしています
最初に確認するポイント
- どの取引、手続、社内運用でこの論点が問題になるのか
- 自社が相手方に何を求め、相手方から何を求められているのか
- 契約書、発注書、規約、社内承認、実際の運用が同じ前提になっているか
- 条項だけでなく、証拠として残る資料や連絡経路まで整理されているか
- AIの指摘をそのまま採用せず、事業上の優先順位とリスク許容度に照らして判断できるか
システム保守契約書とは何か
システム保守契約書とは、既に開発・導入されたシステムについて、継続的な維持管理、障害対応、問い合わせ対応、軽微な修正、バージョンアップ支援、運用支援などを委託する契約書です。対象は、業務システム、Webサービス、SaaS連携、ECサイト、社内ツール、基幹システム、データ連携基盤、クラウド環境など多岐にわたります
保守契約には、準委任的な性質が強いものが多いです。ベンダは、一定の成果物完成を約束するというより、専門的知識に基づいて問い合わせや障害に対応し、システムを利用可能な状態に保つための業務を行います。ただし、個別の改修や追加機能開発が含まれる場合、その部分は請負的に扱う必要があることもあります
保守と運用の違いも整理が必要です。保守は、不具合修正、パッチ適用、障害調査、軽微な改修など、システムを維持するための作業を指すことが多いです。運用は、日次・月次処理、アカウント管理、監視、バックアップ確認、問い合わせ受付、データ登録など、日常的にシステムを動かす業務を含むことがあります。契約書上、保守と運用を分けるのか、まとめて扱うのかを明確にする必要があります
また、システム保守契約では、SLA、つまりサービスレベル合意が重要になることがあります。問い合わせ受付時間、初動対応時間、復旧目標時間、稼働率、障害区分、緊急対応、休日夜間対応の有無などを定めるものです。すべての保守契約に詳細なSLAが必要とは限りませんが、事業上重要なシステムでは、最低限の対応水準を定めておくことが望ましい場面があります
システム保守契約書のレビューでは、単に「保守します」と書かれているかを見るだけでは足りません。何を保守対象とし、何を対象外とし、どの時間帯に、どの水準で、どの費用範囲で対応するのかを確認することが重要です
レビューが重要になる理由
システム保守契約書が重要なのは、障害が起きたときに初めて契約内容が問題になることが多いからです。平常時には大きな問題がなくても、システム停止、データ消失、セキュリティ事故、外部API変更、クラウド障害、アクセス集中が起きたときに、「誰がどこまで対応するのか」が問われます
ユーザー側から見ると、保守契約を結んでいる以上、システムに問題が起きればベンダが対応してくれると考えがちです。しかし、契約書上は問い合わせ対応だけで、不具合修正や復旧作業は別途見積りになっている場合があります。夜間休日対応が含まれていないこともあります。重要システムでこの認識差があると、障害時に深刻な混乱が生じます
ベンダ側から見ると、保守契約の範囲が曖昧なままだと、月額保守料の範囲内で無制限の作業を求められるリスクがあります。新機能追加、仕様変更、データ修正、利用者教育、マニュアル作成、他社サービスの不具合対応まで求められると、保守契約として想定した工数を大きく超える可能性があります
また、システム保守では、原因がどこにあるか分かりにくい問題が多くあります。アプリケーションの不具合なのか、インフラの問題なのか、ユーザーの操作ミスなのか、外部サービスの障害なのか、ネットワークの問題なのかがすぐには判別できないことがあります。契約書で調査範囲、切り分け、第三者サービスとの関係を整理しておかないと、責任の押し付け合いになりやすいです
さらに、セキュリティ対応の重要性も高まっています。脆弱性情報が公開されたとき、誰が影響調査を行うのか、パッチ適用を行うのか、緊急対応費用は月額保守料に含まれるのか、事故時の報告期限はどうするのかを決めておく必要があります。保守契約は、日常業務だけでなく緊急時の体制を定める契約でもあります
保守契約書は、開発契約の付属書のように扱われることがありますが、実際にはシステムの安全な運用を支える重要な契約書です。開発完了時に急いで締結するのではなく、運用開始後に起きることを想像して設計する必要があります
システム保守契約書レビューの基本チェックリスト
最初に、保守対象を確認します。対象システム、対象機能、対象環境、本番環境、検証環境、クラウドサービス、データベース、外部API、連携システム、OS、ミドルウェア、ネットワーク機器が保守対象に含まれるのかを見ます。対象外を明確にしておくことも重要です
次に、保守業務の範囲を確認します。問い合わせ対応、不具合調査、軽微な修正、障害復旧、パッチ適用、バージョンアップ、監視、バックアップ、データ復旧、アカウント管理、月次報告、定例会が含まれるかを見ます。「保守業務一式」とだけ書かれている場合、実務上の認識差が生じやすいです
対応時間と対応方法も重要です。平日営業時間内だけなのか、夜間休日対応があるのか、緊急時の連絡先はどこか、メール、チャット、電話、チケットシステムのどれで受け付けるのかを確認します。初動対応時間、復旧目標、回答期限を定める場合は、ベンダが現実的に守れる水準かも確認する必要があります
SLAを設ける場合には、稼働率、計測方法、除外時間、メンテナンス時間、障害区分、サービスクレジット、損害賠償との関係を見ます。ユーザー側では、SLAが単なる努力目標になっていないかを確認します。ベンダ側では、外部クラウドやユーザー側環境に起因する障害まで自社のSLA違反にならないようにする必要があります
費用条項では、月額保守料に含まれる作業と、別途費用になる作業を分けます。追加改修、仕様変更、データ修正、大規模障害対応、夜間休日対応、オンサイト対応、第三者サービス対応、ライセンス費用、クラウド費用が含まれるかを確認します。上限工数を定める場合は、超過時の単価と承認手続も必要です
障害対応条項では、障害の定義、重大度、報告方法、原因調査、暫定対応、恒久対応、復旧報告、再発防止策を確認します。障害発生時のユーザー側の協力義務、ログ提供、環境アクセス、第三者サービスへの問い合わせ協力も定めることがあります
セキュリティ・個人情報では、アクセス権限、秘密保持、個人情報の取扱い、管理者権限、ログ管理、脆弱性対応、事故時の報告、データ削除、再委託先管理を確認します。保守業務では本番環境にアクセスすることがあるため、通常の業務委託契約よりも具体的な管理条項が必要になる場合があります
契約期間・解除・引継ぎも見ます。保守契約は継続契約であるため、更新、解約予告期間、重大障害時の解除、支払遅延時の停止、終了時のデータ返還、アカウント返却、ドキュメント引渡し、他社への引継ぎ支援を確認します
ユーザー側・ベンダ側で変わるリスク
ユーザー側のリスクは、保守契約を結んでいるのに、必要な対応が契約範囲外になっていることです。問い合わせ対応だけが含まれ、不具合修正は別途費用、夜間休日対応なし、外部サービス障害の切り分けなし、バックアップ確認なしという契約では、重要システムを守るには不足する可能性があります
ユーザー側では、ベンダロックインにも注意が必要です。保守に必要なドキュメント、ソースコード、設定情報、アカウント、インフラ構成図がベンダ側にしかない場合、契約終了後に別ベンダへ移行できないことがあります。契約書では、終了時の引継ぎ、資料提供、移行支援、データ返還を確認する必要があります
ベンダ側のリスクは、保守範囲が広すぎることです。月額固定の保守料で、追加開発、仕様変更、ユーザー教育、データ移行、他社サービス調査まで求められると、採算が合わなくなる可能性があります。ベンダ側では、保守対象外、別途見積り事項、上限工数、緊急対応費用を明確にすることが重要です
ベンダ側では、SLAや損害賠償の責任も慎重に見る必要があります。システム停止によるユーザー側の逸失利益、顧客対応費用、信用毀損まで無制限に責任を負う条項は、保守料とのバランスを欠く可能性があります。故意又は重過失、情報漏えい、知的財産侵害などの例外をどう扱うかは、取引の重要性に応じて調整します
双方に共通するリスクは、障害時のコミュニケーションです。契約書に連絡体制や優先順位がないと、現場が誰に連絡すべきか分からず、初動が遅れる可能性があります。重大障害では、技術対応だけでなく、ユーザー企業の顧客対応、社内報告、経営判断も必要になります。契約書は、その前提となる役割分担を明確にするものであるべきです
システム保守契約は、平常時よりも緊急時に価値が出る契約です。契約書レビューでは、障害が起きた日の動きを具体的に想像しながら、対応範囲、連絡体制、費用、責任を確認することが重要だと考えています
AIでシステム保守契約書レビューを行う際の注意点
生成AIは、システム保守契約書の論点整理に向いています。保守対象、対応時間、SLA、障害対応、費用、セキュリティ、個人情報、再委託、責任制限、契約終了時の引継ぎなど、典型的なチェックポイントを抽出しやすいためです
一方で、AIが契約書だけを読んでも、対象システムの重要度や実際の運用体制までは分かりません。社内業務の一部を支える小規模ツールなのか、顧客向けサービスの基幹システムなのか、24時間稼働が必要なのか、障害時にどの程度の損害が出るのかによって、必要な保守水準は変わります
AIにレビューさせる場合は、対象システムの概要、利用者数、業務上の重要性、対応時間の希望、障害時の影響、月額保守料、ベンダの体制、クラウドや外部サービスの利用状況、個人情報の有無を入力する必要があります。これらがないと、AIは一般的な保守契約のチェックリストを返すだけになりやすいです
また、AIが強いSLAや広い責任条項を提案した場合でも、それが費用や体制に見合うかを確認する必要があります。低額の月額保守契約で、24時間365日の即時復旧や無制限の損害賠償を求めると、交渉上受け入れられにくい可能性があります。逆に、重要システムであるにもかかわらず、ベンダ側の標準条項をそのまま受け入れると、障害時の対応が不足する可能性があります
システム保守契約書のレビューでは、AIを使って論点を早く洗い出し、弁護士又は法務担当者がシステムの重要性と実務運用に照らして調整する流れが有効だと考えています。特に、技術部門、事業部、法務が同じ前提で保守範囲を確認するためのたたき台として使いやすいです
LegalAgentの関連サービス
LegalAgentでは、システム保守契約書について、保守対象、SLA、障害対応、追加費用、セキュリティ、責任制限、契約終了時の引継ぎまで含めてレビューしています。開発契約から保守契約へ移る場面や、既存ベンダとの契約見直しでも、事業部と法務が同じ前提で判断できる形に整理することを重視しています