最終更新日：2026年6月22日
システムを開発したら、その後は保守契約を結んで運用していくのが一般的です。ところが、この保守契約ほど「毎月払っているのに、何をしてもらっているのかよく分からない」と言われる契約も珍しくありません。システムが問題なく動いているあいだは保守の働きが目に見えないため、中身を確かめないまま結び続けている発注者は少なくないのです。
結論から言うと、保守契約で本当に大事なのは月額の金額そのものではありません。「どこまでが保守の範囲なのか」「障害が起きたとき誰がいつ動くのか」「いざ別の会社に移したくなったとき、移せるのか」――この3点が契約で明確になっているかどうかです。この記事では、保守契約とは何を約束する契約なのか、種類・SLA・料金体系を整理したうえで、契約書で必ず確認すべき点を発注者の視点で解説します。
システムの保守契約とは何か
システムの保守契約とは、ひとことで言えば「稼働しているシステムを止めずに使い続けるために、障害対応・改修・更新などの作業を継続的に引き受けてもらう契約」です。家やクルマと同じで、システムも作って終わりではなく、使い続けるかぎり手入れが要ります。その手入れを、開発した会社や保守を引き受ける会社と取り決めるのが保守契約です。
なお、「運用」と「保守」は厳密には別の概念で、保守がそもそもなぜ必要なのかも含めて、別の記事で整理しています。言葉の定義や保守の必要性から押さえたい方は、運用保守とは何かを解説した記事をあわせてご覧ください。ここでは、その保守をどういう契約で取り決めるかに絞って話を進めます。
保守契約のやっかいなところは、システムが順調に動いているあいだは「何もしてくれていない」ように見えてしまうことです。しかし保守契約の本質は、いざ障害が起きたときのための保険にあります。問題は、その保険が「何に対する保険なのか」が契約で曖昧なままになっているケースが多いことです。
保守契約の種類──準委任型と請負型、そしてSLA
保守契約は、契約の形態によって性格が変わります。発注者として最低限知っておきたいのが、準委任型と請負型の違い、そしてSLAという考え方です。
準委任型は、「対応するという役務（仕事そのもの）」に対価を払う契約です。多くの保守契約はこちらにあたります。障害対応や監視といった継続的な作業は、あらかじめ完成形を決められる性質のものではないため、「最善を尽くして対応する」という準委任型がなじみます。一方の請負型は、「特定の成果物を完成させること」に責任を負う契約です。たとえば「この機能を改修して納品する」といった、ゴールがはっきりしている個別の作業では請負型が使われます。
どちらが優れているという話ではありません。継続的な運用保守は準委任型が一般的で、まとまった改修だけを切り出すなら請負型、というように作業の性質に応じて使い分けるのが実態です。大事なのは、自分が結ぼうとしている契約がどちらの性格で、相手が何に責任を負っているのかを理解しておくことです。
そしてもうひとつ重要なのがSLA（サービスレベル合意）です。SLAとは、「障害の連絡を受けてから何時間以内に着手するか」「どの時間帯に対応するか」「どの程度の稼働率を保つか」といったサービスの水準を数値で取り決めたものです。SLAがある契約では「いつまでに、どこまで動いてくれるのか」がはっきりします。逆にSLAがまったく定められていない保守契約は、いざというときの対応速度が相手任せになりがちです。
保守契約の料金体系
保守契約の料金には、大きく分けて次のような形があります。
- 月額固定型：毎月一定額を払い、決められた範囲の保守を受ける。費用が読みやすい。
- 従量型（スポット・チケット制）：対応が発生したぶんだけ支払う。対応が少ない月は安く済むが、トラブルが続くと読みにくい。
- 組み合わせ型：基本の監視・軽微な対応は月額固定、大きな改修は別途見積もり、という形。
ここで注意したいのは、保守の料金は「世間の相場」で決まるのではなく、契約の中身で決まるということです。具体的には、対応範囲の広さ・SLAの水準・システムの規模・技術的な複雑さによって、同じ「保守」でも金額は大きく変わります。月額だけを並べて「A社よりB社のほうが安い」と比較しても、対応範囲やSLAが違えば、そもそも比べているものが違うのです。安い保守契約は、多くの場合いざというときの対応範囲が狭いだけ、ということも珍しくありません。
なお、開発が終わったあとにかかるのは保守費用だけではありません。サーバー代やライセンス費用なども含めた運用後のコスト全体については、システム開発後のランニングコストを整理した記事で詳しく解説しています。
保守契約書で必ず確認すべき5つの点
保守契約書（ソフトウェア保守契約書）を交わすとき、発注者として最低限ここだけは確認しておきたい、という点があります。次の5つです。
とりわけ注意したいのが、1つ目の「対応範囲」と5つ目の「解約・移管の条件」です。対応範囲が書かれていない契約は、「それは保守の範囲外なので別料金です」と後から言われる火種になります。どこまでが月額に含まれ、どこからが追加開発なのか――この線引きが文書になっているかを必ず確認してください。
そして見落とされがちなのが、解約・移管の条件です。辞めるときの条件が書かれていない契約は、いざ別の会社に切り替えたいときに揉めます。ソースコードや最新のドキュメントを渡してもらえるのか、移管にあたって何が必要なのかが取り決められていないと、「やめたくてもやめられない」状態――いわゆるベンダーロックインに陥ります。契約を結ぶときにこそ、辞めるときのことを確認しておくべきです。
保守契約で起きがちなトラブルと、その回避
保守契約をめぐるトラブルは、多くが契約時の取り決めの曖昧さに起因します。よくあるのは次のようなケースです。
- 対応範囲が曖昧で揉める：「直してくれると思っていた不具合が、追加料金だと言われた」
- 相手側で属人化している：「担当者しか分からず、その人が辞めたら保守が止まった」
- 連絡が取れない・急に値上げされた：「保守はしてもらっているが、対応が遅く相談もしづらい」
これらを避けるには、契約前に対応範囲とSLAを文書で握っておくこと、そして相手がチームで保守できる体制かを確認することが効きます。すでに「保守を断られた」「今の保守体制に不安がある」という段階なら、自社で抱えるか外注するかの判断軸を整理した運用保守は自社か外注かの記事と、他社開発システムでも引き継げる条件をまとめた「保守を断られた」ときに読む記事もあわせてご覧ください。
アクシアの保守契約・運用保守
アクシアは、システム開発を下請けに出さず自社のエンジニアで一貫して行う体制で、運用保守そのものを15年以上手がけてきました。運用保守は必ず2名以上のチームで対応し、担当者が休んだり入れ替わったりしても保守が止まらないようにしています。「その人がいないと何もできない」という属人化を、私たちの側で作らないやり方です。
契約面でも、対応範囲・対応時間・解約や移管の条件をあらかじめ明確にすることを大切にしています。発注者が「何を約束してもらっているのか分からない」まま払い続ける状態を作らないためです。さらに、他社が開発したシステムの引き継ぎ（保守移管）も得意分野で、ソースコードやドキュメントが揃っていなくても、エンジニアが実際にシステムを解析して保守体制を組みます。近年はシステムの解析にAIも活用し、対応できる言語の幅と調査のスピードはさらに広がりました。実際に、保守移管サービスでは他社開発システムの引き継ぎを30社以上手がけています。
保守契約は、金額だけで選ぶものではありません。対応範囲・SLA・解約条件まで含めて、「いざというときに本当に頼れるか」で判断してください。今の保守に不安がある、契約の中身を見直したいという場合は、まずはお気軽にご相談ください。