システムの保守契約とは？内容とSLAの見方を発注者向けにやさしく解説

システムを作った後は、多くの場合「保守契約」を結んで使い続けます。ところが契約書を見ても、専門用語が並んでいて「何をどこまでやってくれる契約なのか」が読み取りにくいものです。この記事では、費用の相場ではなく保守契約の中身そのものに絞って、契約書に何が書かれ、発注者としてどこを確認すればよいかを整理します。保守と運用の違い、含まれる範囲と含まれない範囲、SLA（サービス品質保証）のやさしい見方、契約タイプの違い、よくあるトラブルと確認チェック項目まで、順を追って解説します。

※本記事は保守契約の一般的な読み方の解説です。制度・契約条件の記述は一般論であり、実際の契約は会社ごと・案件ごとに内容が変わります。重要な契約は契約書の原文と、必要に応じて専門家の確認をお願いします。

なお、保守にいくらかかるかという費用の相場は保守・運用費用の相場の記事で、契約書全体の確認手順は契約書チェックの記事で扱っています。この記事は「保守契約という個別の契約に何が書かれ、どこを見るか」に集中します。

保守契約とは｜「保守」と「運用」の違い

保守契約とは、納品後のシステムを安定して使い続けるために、開発会社が継続的にサポートすることを取り決めた契約です。作って納品したら関係が終わるのではなく、その後の不具合対応や更新をどう続けるかを約束するものと考えると分かりやすいでしょう。

よく混同されるのが「保守」と「運用」です。厳密な定義は会社によって異なりますが、ざっくり分けると次のようになります。

区分	ねらい	主な作業の例
保守	システムそのものを直す・整える	不具合修正、軽微な改修、セキュリティ更新、OS・ライブラリ対応
運用	システムを動かし続ける	稼働監視、バックアップ、問い合わせ対応、定期レポート

現実の契約書では、この2つをまとめて「保守運用」「保守・サポート」と呼ぶことがほとんどです。大切なのは言葉の分類ではなく、「実際にどの作業をやってくれるのか」が具体的に書かれているかです。「保守一式」とだけ書かれている契約は、範囲があいまいなサインだと考えてください。

なぜ保守契約が必要になるのかというと、システムは作って終わりではなく、周囲の環境が絶えず変化していくからです。スマートフォンのOSは年に何度も更新され、ブラウザの仕様も変わり、利用しているライブラリには新しい脆弱性が見つかります。これらは発注側の都合とは関係なくやってくるため、放置していると「昨日まで動いていたのに突然ログインできなくなった」といった事態が起こり得ます。保守契約は、こうした変化に継続的に追随するための備えでもあります。

保守契約に含まれる範囲・含まれない範囲

保守契約で最もトラブルになりやすいのが「範囲」です。どこまでが月額料金の中に含まれ、どこからが別料金なのか——この線引きが不明確だと、後から想定外の請求が来たり、逆に「それは契約外です」と対応を断られたりします。

一般的に保守契約に含まれることが多い作業は、次のようなものです。

• 障害対応：システムが停止・エラーになったときの原因調査と復旧
• 軽微な改修：文言の修正、項目の追加など、短時間で終わる小さな変更
• OS・セキュリティ更新：iOS/Android やブラウザの仕様変更への追随、脆弱性パッチの適用
• 監視：稼働状況やエラー、容量の見張り（プランにより含まれない場合もある）
• 問い合わせ対応：使い方や不具合の相談窓口

一方、次のような作業は含まれないことが多く、別見積り・別料金になりがちです。ここを事前に知っておくと、認識のずれを防げます。

よくある誤解	実際の扱い
新しい機能の追加も保守でやってくれる	多くは保守の範囲外。開発として別料金
デザインの大幅変更も無料対応	軽微な範囲を超えると別料金
データの大量移行・集計作業	通常は保守外の作業
発注側の操作ミスによるデータ復旧	範囲・回数に制限があることが多い
サーバー費用・ドメイン更新料	保守料金とは別に実費がかかるのが一般的

ポイントは、「含まれる範囲」だけでなく**「含まれない範囲」まで契約書や別紙に書かれているか**を確認することです。含まれないことが明記されていれば、いざというときに「言った・言わない」でもめずに済みます。

SLA（サービス品質保証）の見方

SLA（Service Level Agreement＝サービス品質保証）は、保守の品質を数値で約束する取り決めです。「頑張って対応します」といった曖昧な言葉ではなく、「何時間以内に」「どれくらいの水準で」対応するかを具体的な数値で示すものだと考えてください。発注者にとっては、SLAを読めば「このシステムがどれくらい手厚く守られるのか」が分かります。

主なSLAの項目は次の3つです。

項目	意味	見るときのポイント
対応時間	連絡してから対応を始めるまでの時間	「受付は平日9〜18時」など、対象時間帯も確認
復旧目標	障害発生から復旧までの目標時間	「目標」か「保証」かで意味が大きく変わる
稼働率	一定期間でシステムが正常稼働している割合	99%と99.9%では停止許容時間が大違い

とくに稼働率は数字のわずかな差が大きな違いになります。目安として、次のように停止が許される時間が変わります。

• 稼働率99%：月あたり約7時間程度まで停止し得る
• 稼働率99.9%：月あたり約43分程度まで
• 稼働率99.99%：月あたり約4分程度まで

数字が高いほど手厚く見えますが、その分だけ体制もコストも必要になり、月額料金は上がります。また「復旧目標」は努力目標であって保証ではないことが多く、達成できなくても返金などの措置がないケースもあります。SLAを読むときは、数値そのものだけでなく「目標なのか保証なのか」「守られなかったときにどうなるのか」まで確認しましょう。

あわせて確認したいのが、その数値が「いつの時間帯」に適用されるかです。たとえば「1時間以内に対応」と書かれていても、受付が平日9〜18時に限られていれば、金曜の夜に障害が起きても対応は月曜の朝からになります。24時間365日の対応を求めるほど料金は大きく上がるため、自社の業務時間や、システムが実際に使われる時間帯に合わせて必要な水準を見極めることが大切です。数値の高さを競うのではなく、自社にとって本当に必要な時間帯と水準はどこかという視点で読むと、過剰な契約を避けられます。

保守契約の3タイプ｜スポット／月額／SLA付き

保守の契約形態は、大きく3つに分けられます。業務がどれくらい「止められないか」に応じて選ぶのが基本です。

タイプ	料金の考え方	向いているケース
スポット保守	問題が起きたときに都度対応・都度請求	止まっても困らない、更新頻度が低いシステム
月額保守	毎月定額で一定範囲をカバー	使い続ける前提で、ある程度の安心がほしい
SLA付き保守	月額＋対応時間・復旧目標などを数値で保証	止まると業務や売上に直結する重要システム

スポット保守は普段の費用を抑えられますが、いざというときに「すぐ対応してもらえるとは限らない」「その都度見積りになる」という不確実さがあります。月額保守は毎月の費用が読め、一定範囲の対応が含まれるので安心感があります。SLA付き保守は最も手厚い代わりに料金も高くなります。

「とにかく手厚い契約が良い」というわけではありません。社内でしか使わず多少止まっても困らないシステムに高額なSLAを付けるのは過剰です。逆に、予約や決済など止まると即座に売上や信用に響くシステムなら、SLA付きを検討する価値があります。自社にとっての「止まったときの困り具合」を基準に選びましょう。

シーン別に目安を挙げると、次のような整理になります。社内の勤怠管理や在庫管理のような業務が数時間止まっても代替手段でしのげるシステムなら、月額保守で十分なことが多いでしょう。飲食店の予約やネットショップの決済のように止まった瞬間に取りこぼしが発生するシステムは、対応時間を約束したSLA付きが安心です。一方、公開したての小規模なツールや、使う人が限られる社内向けの試験的なシステムであれば、まずはスポット保守で様子を見て、利用が定着してから月額へ切り替えるという段階的な選び方もあります。

保守契約でよくあるトラブル

保守契約をめぐるトラブルは、いくつかの典型パターンに集約されます。あらかじめ知っておくと、契約前に防ぎやすくなります。

• 範囲外の追加請求：「これも保守でやってくれると思っていた」作業が別料金だった。範囲の線引きが契約書に明記されていないことが原因
• 対応が遅い・後回しにされる：SLAがなく対応時間の約束がないため、連絡しても数日返事が来ない
• 軽微改修の解釈のずれ：「軽微」の基準があいまいで、どこまで無償か会社と認識が食い違う
• 保守を断ると強気になる：他社に頼めない状態（ソースコードがない等）で、料金や対応の主導権を握られる
• サーバー費用が別で想定外：保守料金にサーバー・ドメイン費が含まれず、毎月別に請求される

これらの多くは、「範囲」と「SLA」と「金額に含まれるもの」を契約前に文書で固めておけば防げるトラブルです。とくに5つ目のように、成果物（ソースコード）の権利が発注側にないと、保守の主導権を相手に握られやすくなります。逆に言えば、契約前のわずかな確認の手間を惜しまないことが、運用が始まってからの余計な出費や交渉のストレスを大きく減らすことにつながります。

例：あるお店が予約システムの保守を月額で契約したケースを考えてみます。契約書に「軽微な改修を含む」とだけ書かれていたため、メニュー追加のたびに「これは軽微を超える」と追加請求され、当初想定の倍近い費用になってしまった——というのは、範囲の定義があいまいなときに起こりがちな失敗です。「軽微改修＝月◯時間まで」のように、数量で線引きしておくと防げます。

契約前に確認すべきチェック項目

保守契約を結ぶ前に、最低限これだけは確認しておきたい項目をチェックリストにまとめます。契約書の原文や別紙と照らし合わせながら、一つずつ確認してください。

#	確認項目	見るポイント
1	含まれる作業の範囲	障害対応・改修・更新・監視などが具体的に書かれているか
2	含まれない作業	別料金になる作業（機能追加・大量作業等）が明記されているか
3	対応時間	受付の曜日・時間帯、緊急時の連絡手段
4	復旧目標・稼働率	「目標」か「保証」か、守られないときの扱い
5	月額料金と実費	サーバー・ドメイン等の実費が別かどうか
6	軽微改修の基準	「軽微」の範囲を時間・回数など数量で定義しているか
7	解約条件	解約予告の期間、違約金の有無
8	引き継ぎ・ソースコード	他社へ移る際のデータ・コードの引き渡し条件

このうち特に重要なのが、1・2の「範囲」と、8の「引き継ぎ」です。範囲があいまいだと日々の追加請求に、引き継ぎ条件が不利だと将来の乗り換え不能につながります。契約書に書かれていない項目があれば、口頭で済ませず別紙や覚書として文書に残してもらうことをおすすめします。

解約・引き継ぎ・ソースコードの扱い

保守契約は「一度結んだら一生そこに頼み続ける」ものではありません。だからこそ、契約前にやめるときのことまで見ておくことが大切です。確認したいのは次の3点です。

• 解約条件：解約は何か月前に伝える必要があるか、違約金や最低契約期間があるか
• 引き継ぎ：他社へ移る際に、データや設計資料、サーバーの管理権限を渡してもらえるか
• ソースコードの帰属：成果物の権利が発注側にあるか、開発会社に残るか

ここで鍵になるのがソースコードの権利です。ソースコードが手元にない、あるいは著作権が開発会社に残ったままだと、他社への乗り換えも自社での改修もできず、事実上その会社に依存し続けることになります。これはベンダーロックインの記事で詳しく扱っている、発注者が陥りやすい状態です。

保守契約そのものが悪いわけではありません。問題になるのは、「保守を解約したら何も引き継げない」設計になっているケースです。契約前に「成果物の権利は発注側に帰属する」「解約時にはデータと必要資料を引き渡す」と書かれているかを確認しておけば、いざというときに主導権を保てます。

一律料金と保守の考え方

保守契約が読みにくくなる根っこには、「開発費そのものが最後まで見えない」という問題があります。開発費が「やってみないと分からない」状態だと、そこに連動する保守費や範囲の交渉も見通しづらくなります。だからこそ、開発費の総額を先に固定できると、保守も含めた費用と範囲の計画が立てやすくなります。

D-oneApp では、開発費は一律100万円（プロは200万円）で総額を固定し、追加費用なし・着手前に総額確定を前提にしています。そのうえで、保守は任意の月額オプション（スタンダード月1万円／プロ月2万円）としています。過剰な保守を押し付けるのではなく、必要な範囲だけを金額の見えた状態で続けられる形です。

• 開発費は一律で固定：作った後の保守も含め、費用の全体像が読める
• 保守は任意：止められなさに応じて必要な分だけを月額で
• 成果物の権利はお客様に：解約しても引き継げるので、ロックインを避けられる

保守に毎月いくらかかるかの目安は保守・運用費用の相場の記事、サーバー代など毎月かかる費用の全体像はランニングコストの記事もあわせてご覧ください。

まとめ

保守契約で確認すべきは、費用の金額そのものよりも**「範囲」と「SLA」と「引き継ぎ」**です。含まれる作業と含まれない作業の線引きが明記されているか、対応時間・復旧目標・稼働率がどう約束されているか、解約時にソースコードやデータを引き継げるか——この3点を契約前に文書で固めておけば、範囲外請求や対応の遅れ、乗り換え不能といったトラブルの多くは防げます。契約タイプはスポット／月額／SLA付きから、システムがどれくらい止められないかに応じて選びましょう。保守も含めた契約や費用の全体像を相談したい方は、無料相談でお気軽にご相談ください。