保守契約・システム保守契約書のチェックポイント｜対応範囲・SLA・追加費用

こんにちは。LegalAgent 代表弁護士の朝戸です。

システム保守契約書は、ソフトウェア開発契約書と比べると目立ちにくい契約です。しかし内容の詰めが甘いと、トラブルのしわ寄せは障害が起きた瞬間に現れます。保守対象や対応時間、追加費用の境界が曖昧なままだと、ユーザー側は「月額の中で当然やってもらえる」と考え、ベンダ側は「保守の範囲外です」と受け止める食い違いが生じやすいためです。

開発が終わった後のシステムでは、軽微な不具合対応やセキュリティパッチの適用、障害時の一次対応など、日々の維持管理が続きます。契約書の確認では、こうした業務がどこまで保守契約に含まれるのかを、障害発生の場面を想定しながら一つずつ見ていきます。

システムの保守範囲や追加費用の取り決めに関する契約審査を弁護士へ任せたい企業では、法務部がない場合でも継続して業務を依頼できる法務アウトソーシングを活用できます。

保守と運用の区分と契約類型の見きわめ

システム保守契約とは、稼働しているシステムについて、継続的な維持管理や障害対応、軽微な修正などを委託する契約です。対象は業務システムやWebサービスにとどまらず、SaaS連携やクラウド環境まで及ぶことが多くあります。契約類型としては準委任に近い契約が多く見られますが、契約書や業務の名称だけで直ちに判断できるものではありません。合意した業務の内容や完成義務の有無から実質的に判断します。

準委任契約の場合、ベンダは成果物の完成を約束する義務を負わずに、専門知識に基づき善良な管理者の注意をもって問い合わせや障害に対応し、システムを利用可能な状態に保つ業務を遂行します。これに対して、個別の機能改修や追加開発が含まれる部分は、仕事の完成義務を伴う請負に近い扱いにした方が実務に合う場面もあります。

あわせて、保守と運用の違いも整理しておきたい論点です。保守は不具合の調査や修正、パッチ適用などシステムを維持・修復する作業を指すことが多く、運用は日次バッチ処理やアカウント管理、稼働監視、バックアップの確認など日常的に動かし続ける業務を指すことがあります。この二つを契約書で分けて定めるか、一括して委託するかによって、費用の見積りや責任の所在が変わってきます。

対応範囲・SLA・費用の境界設計

保守契約を点検する際は、対応範囲、SLA（サービスレベル合意）、追加費用の三つの境界を突き合わせて確認します。次の表は、実務における具体的な設計例の一つです。すべての契約に当てはまる標準ではありませんが、役割分担を整理する目安になります。

論点	月額保守料に含める例	別料金となり得る例	契約書で決める事項
対応範囲	問い合わせ対応、既存機能の不具合調査、軽微な修正、定例報告	新機能開発、仕様変更、データ移行、他社製品の調査	対象システム、対象業務、除外業務、月間工数の上限
SLA	受付時間、障害区分、一次回答時間、復旧目標、定期メンテナンス	夜間休日の緊急対応、常時監視、現地対応	時間の起算点、除外時間、連絡経路、未達時の扱い
追加費用	契約内工数で行う作業、事前に合意した定例作業	上限超過、緊急対応、追加改修、オンサイト作業	見積り、単価、事前承認、作業着手、請求時期

この三つの要素は別々の条項に分かれていても、実際の現場では同時に連動します。たとえば夜間の障害調査が対応範囲に含まれていても、SLA上の開始時刻や追加費用の承認手順が決まっていなければ、復旧を急ぐほど費用の合意が後回しになります。

SLAの設計では、平日営業時間内だけの対応なのか、夜間休日の対応を含むのか、緊急連絡先はメールとチャットのどちらを優先するのかといった実務手順を確認します。すべての保守契約に細かなSLAを設ける必要はありませんが、事業に直結する重要システムほど、最低限の対応水準を数字で決めておくことで障害時の期待値がずれにくくなります。

稼働率や復旧目標を定める場合は、努力目標にとどまるのか達成義務なのかを明確にし、時間の起算点や定期メンテナンスなどの除外時間を詰めておきます。外部クラウドの障害についても、常に当然免責やSLA除外となるわけではないため、自社の管理範囲と責任の線引きを定めておくことが欠かせません。あわせて、目標未達時のサービスクレジットと損害賠償との関係も点検しておきます。

月額費用と別途費用の境界については、追加改修や仕様変更、夜間休日対応、オンサイト対応が一式に含まれるのかを確認します。上限工数を設定する場合は、超過時の単価や事前承認のフローを契約書に明記しておくと、請求時の揉め事を防ぎやすくなります。

障害対応の手順と本番環境の安全管理

障害対応の条項では、障害の定義、重大度の区分、報告方法、原因調査から復旧報告、再発防止策までの流れを定めます。原因がアプリケーションの不具合なのか、インフラの問題なのか、外部連携サービスの障害なのかが直ちに判別できない場合も少なくありません。調査範囲や第三者サービスとの連絡窓口を整理しておかないと、責任の押し付け合いにつながるおそれがあります。公開された脆弱性情報への影響調査やパッチ適用をどちらが担うのか、緊急対応費用が月額枠内かも定めておきます。

本番環境へのアクセスを伴う保守業務では、アクセスする情報や操作権限に応じた、具体的な安全管理の取り決めが求められます。アクセス権限の付与と削除の基準、アクセスログの取得と保管、再委託先の管理、インシデント発生時の報告期限などを個別の安全管理条項として定めておくことが有益です。

契約終了時の移行支援と当事者双方のリスク

保守契約は継続的な契約であるため、契約の更新や解約予告期間だけでなく、重大障害時の解除権や支払遅延時の業務停止権も確認します。さらに終了時におけるデータの返還、アカウントの返却、他社への引継ぎ支援まで見据えておく必要があります。保守に必要なソースコード、設定情報、インフラ構成図がベンダ側だけに保管されていると、契約終了時に他社へ移行しにくくなるおそれがあります。終了時の資料提供や移行支援は法律上の当然の無償義務ではないため、提供範囲や費用負担を契約書に明記しておくことが実務上の手当てになります。

ユーザー側における大きなリスクは、保守契約を結んでいる安心感がありながら、いざというときの不具合修正が別料金だったり夜間休日対応が含まれていなかったりして、必要な支援を受けられない事態です。契約終了時の移行支援や資料提供の条項も確認しておきます。

ベンダ側のリスクは、保守範囲が不明確なまま広がり、月額固定の枠内で新機能追加や仕様変更、他社サービスの不具合対応まで求められて工数が圧迫される点にあります。対象外の作業、別途見積りの条件、上限工数、緊急対応費用の扱いを定めておくことが防御線になります。システム停止によるユーザー側の逸失利益や信用毀損まで無制限に負う賠償条項は、保守料の対価と釣り合わない場合があるため、責任制限条項の点検も大切です。

重大な障害では、現場の技術対応だけでなく、顧客対応や経営判断も直ちに動き出します。契約書は、連絡体制や優先順位を明確にして初動の遅れを防ぐ前提になるものだと考えています。

生成AIは保守対象や対応時間、SLAなどの一般的な論点を洗い出す作業に役立ちます。しかし、対象システムが社内の一部の小規模ツールなのか、顧客向けサービスの基幹システムなのかといった背景までは、契約書の文章だけでは読み取れません。システムの重要度、利用者数、障害時に想定される損害規模を人間が補ってはじめて、実務に即した点検が可能になります。

よくある質問

システム保守契約とはどのような契約ですか？

稼働しているシステムについて、継続的な維持管理や障害対応、軽微な修正などを委託する契約です。契約類型としては成果物の完成義務を負わずに善管注意義務をもって業務を遂行する準委任に近い契約が多く見られます。ただし、個別の機能改修や追加開発が含まれる部分は請負に近い扱いに適する場合もあり、契約書の名称ではなく業務内容や完成義務の有無から実質的に判断されると考えられます。

保守契約書をレビューする際はどのような境界を確認すべきですか？

対応範囲、SLA、追加費用の三つの境界を突き合わせて確認すべきです。夜間の障害調査が対応範囲に含まれていても、開始時刻や追加費用の事前承認手順が決まっていないと、復旧を急ぐほど費用合意が後回しになるなど現場で同時に連動するためです。月額枠内の作業と別料金となる作業の線引きや、上限工数を超えた場合の単価、事前承認フローを契約書に明記することが大切になると解されています。

保守契約の終了時に他社へシステムを引き継ぐことは義務付けられていますか？

法律上の当然の義務として無償で義務付けられているわけではありません。契約終了時における資料提供や移行支援は当然の無償義務ではないため、契約書に定めていなければ対応が難しくなる恐れがあるためです。ソースコードや設定情報、インフラ構成図がベンダ側だけに保管されている事態に備え、引き継ぎ支援の提供範囲や費用負担をあらかじめ契約書に明記しておく必要があると考えられます。