システム保守契約とは？契約形態・SLA・契約書の必須項目・費用相場をわかりやすく解説【2026年版】
システムは導入して終わりではありません。稼働し続ける限り、障害対応・不具合修正・環境変更への追随といった保守が必要になり、その取り決めを定めるのが「システム保守契約」です。ところが、いざ契約を結ぶ・見直す段になると、「どの契約形態を選べばよいのか」「契約書に何を書けば後で揉めないのか」「SLAはどう決めればいいのか」で手が止まる担当者は少なくありません。
本記事では、システム保守契約の基礎から、契約形態の選び方、契約書に必ず盛り込むべき項目、SLA（サービス品質保証）の決め方、費用相場までを、保守を請け負う側の視点で解説します。読み終えるころには、自社にとって過不足のない保守契約を、トラブルなく結べる状態になっているはずです。
目次
想定読者
本記事は、次のような方を想定しています。
- はじめてシステム保守契約を結ぶ、または既存契約を見直したい情シス・総務担当者
- 現在の保守契約が「何にいくら払っているのか」不透明で、妥当性を確かめたい方
- 保守ベンダーからの契約書案を受け取ったが、そのまま押印してよいか不安な方
- 障害時の対応範囲や責任の所在を、契約で明確にしておきたい製造業の担当者
システム保守契約とは
システム保守契約とは、稼働中のシステムを正常な状態に保つための作業（障害対応・不具合修正・問い合わせ対応・軽微な改修・環境変更への追随など）を、どの範囲で・どの品質で・いくらで提供するかを取り決める契約です。多くは月額または年額の継続契約として結ばれます。
混同されやすいのが「運用」との違いです。ざっくり分けると、運用は「システムを動かし続けるための日常業務」（監視・バックアップ・ジョブ実行など）、保守は「壊れた・壊れそうなものを直す業務」（障害復旧・修正・パッチ適用）を指します。実務では両者を1つの契約にまとめることも多いため、契約時には「自社が必要としているのは運用か、保守か、両方か」を先に整理しておくと、見積もりの粒度が揃います。
保守契約が必要になる理由は、大きく3つあります。第一に、障害は必ず起きること。ハードウェアの経年劣化、OSやミドルウェアの脆弱性、連携先の仕様変更など、稼働後も不具合の火種は絶えません。第二に、対応を都度発注（スポット）にすると、いざというとき動いてもらえない・割高になること。契約があれば優先的に、あらかじめ決めた条件で対応してもらえます。第三に、責任の所在を明確にできること。「どこまでがベンダーの対応で、どこからが別料金か」を契約で定めておけば、障害時の「言った言わない」を防げます。
システム保守契約の主な契約形態
システム保守契約は、いくつかの軸で形態が分かれます。それぞれ費用と安心感のバランスが異なるため、自社のシステムの重要度に合わせて選びます。
まず、発注の形による違いです。
| 形態 | 内容 | 費用感 | 向いているケース |
|---|---|---|---|
| 年間保守契約（月額・年額） | 一定の対応範囲を継続的にカバー | 中〜高（固定費） | 業務に不可欠で、止まると困るシステム |
| スポット契約（都度発注） | 障害・依頼が発生するたびに個別に発注 | 低（変動費）だが割高になりやすい | 停止しても業務影響が小さい／利用頻度の低いシステム |
次に、対応方法による違いです。
| 形態 | 内容 | 特徴 |
|---|---|---|
| リモート保守 | 遠隔から監視・調査・復旧を行う | 費用を抑えやすく、初動が速い |
| オンサイト保守 | 技術者が現地に出向いて対応 | ハードウェア障害や現地作業に強いが費用は高め |
さらに、契約の法的性質としては、成果物の完成を約束する「請負」ではなく、善良な管理者の注意をもって業務を遂行する「準委任」で結ばれるのが一般的です。保守は「必ず直る」ことを保証する性質のものではないため、準委任が実態に合っています。ただし、特定の改修や移行など成果が明確な作業は、保守契約とは別に請負や個別契約で切り出すことも多く、「継続的な保守（準委任）」と「個別の作業（請負・別料金）」の線引きを契約時に確認しておくことが重要です。
多くの企業にとって現実的なのは、重要システムは年間保守契約＋リモート主体（必要時オンサイト）という組み合わせです。まずは自社システムを「止まると業務が止まるもの」「多少止まっても許容できるもの」に仕分け、前者に手厚い契約を寄せると、費用対効果の高い保守体制になります。
保守契約書に必ず盛り込むべき8項目
契約後のトラブルは、そのほとんどが「契約書に書いていなかったこと」で起こります。以下の8項目は、システム保守契約書に必ず明記すべき要素です。契約書案を受け取ったら、この観点で抜け漏れをチェックしてください。
| 項目 | 確認すべき内容 |
|---|---|
| 対応範囲（スコープ） | どのシステム・機器・ソフトウェアが対象か。対象外は何か |
| 対応の種類 | 障害対応・不具合修正・問い合わせ・軽微改修のどこまでを含むか |
| 対応時間・受付時間 | 平日日中のみか、24時間365日か。受付窓口と連絡手段 |
| SLA（サービスレベル） | 応答時間・復旧目標時間・稼働率などの品質基準（次章で詳述） |
| 料金と追加費用 | 月額に含まれる範囲と、別料金になる作業・その単価 |
| 再委託・体制 | 作業を外部に再委託する場合の可否と責任の所在 |
| 免責事項 | ベンダーが責任を負わない範囲（天災・利用者の過失・対象外機器など） |
| 契約期間・更新・解約 | 契約期間、自動更新の有無、解約予告期間、データ・資料の返還 |
とくに見落とされやすいのが、「解約時の取り決め」です。保守を別のベンダーに切り替える際、運用手順書・監視設定・アカウント権限の一覧が返還される契約になっていないと、引き継ぎが難航します。契約を結ぶ時点で「終わり方」まで決めておくのが、後悔しない保守契約のコツです。
SLA（サービス品質保証）の決め方
SLA（Service Level Agreement）は、保守の「品質」を数値で約束する取り決めです。SLAが曖昧だと、障害時に「すぐ対応してくれると思っていた」というすれ違いが起きます。逆に、過剰なSLAを求めると費用が跳ね上がります。次の3つの観点で、自社の業務影響に見合った水準を設定してください。
まず応答時間（レスポンスタイム）です。障害の連絡から一次回答までの時間で、「受付後30分以内に一次連絡」などと定めます。次に復旧目標時間（RTO：Recovery Time Objective）です。障害発生から復旧までの目標時間で、業務が止まって許容できる時間から逆算します。あわせて、どこまでのデータ復旧を目指すかを示すRPO（Recovery Point Objective）も、バックアップの取得間隔と合わせて確認します。最後に稼働率です。「月間99.9%」のように定め、未達時の対応（報告・料金減額など）まで決めておくと実効性が高まります。
水準の目安を、システムの重要度別に整理すると次のようになります。自社のシステムがどの行に当てはまるかを起点に考えると、過不足のないSLAを設定しやすくなります。
| 重要度 | 対応時間帯 | 一次応答の目安 | 復旧目標（RTO） | 稼働率の目安 |
|---|---|---|---|---|
| 高（止まると即業務停止） | 24時間365日・有人 | 30分以内 | 数時間以内 | 99.9%以上 |
| 中（数時間の停止は許容） | 平日日中＋夜間は通知 | 当日中 | 1営業日以内 | 99.5%前後 |
| 低（翌営業日対応で可） | 平日日中のみ | 翌営業日 | 数営業日 | 定めない場合も |
SLAで最も費用を動かすのは対応時間帯です。24時間365日の有人対応は、ベンダーが交代要員を確保し続ける体制であり、その人件費が月額に反映されます。「念のため24時間」と決める前に、深夜や休日に本当に即時復旧が必要な業務はどれかを整理しましょう。夜間はバッチ処理のみで、翌朝の復旧で業務影響がないのであれば、平日日中の対応で十分なケースもあります。重要度の異なるシステムを1つの契約で束ねる場合は、システムごとにSLAを分けて定義しておくと、不要な費用を避けられます。
システムの〇〇についてお困りでしたら、c3index にお気軽にご相談ください。
システム保守契約の費用相場
保守費用は、開発費の年間15〜20%が一つの目安とされます。たとえば1,000万円で開発したシステムなら、年間150万〜200万円程度が目安です。ただしこれはあくまで基準で、実際の金額はシステムの規模、対応時間帯、SLAの水準、オンサイトの有無によって大きく変わります。
費用を左右する主な変数は、①対応時間帯（平日日中か24時間365日か）、②対応の深さ（監視・通知のみか、復旧作業まで手を動かすか）、③対象システムの規模と複雑さ、④SLAで約束する稼働率・復旧時間、の4つです。見積もりを比較するときは、月額の総額だけでなく「月額に含まれる作業」と「別料金になる作業の単価」をセットで確認してください。初期費用が安く見えても、改修単価が高いと総額で逆転することは珍しくありません。
とくに注意したいのが、月額に含まれる範囲の線引きです。一般に、障害の一次対応・問い合わせ対応・軽微な設定変更・定期報告は月額に含まれることが多い一方、機能追加やバージョンアップ、大規模なデータ移行、対象外機器の対応は別料金（都度見積もり）になるのが通例です。契約前に「どこまでが月額の範囲で、どこからが別料金か」を具体的な作業例で確認しておくと、稼働後に想定外の請求が積み上がるのを防げます。安さだけで選ばず、対応範囲・SLA・追加料金の単価を含めた総額で比較することが、結果的にコストを抑える近道です。
保守契約を結ぶ・見直すときの進め方と注意点
はじめて契約を結ぶ場合も、既存契約を見直す場合も、進め方は共通しています。次の手順で進めると、抜け漏れのない契約になります。
- 現状の棚卸し：対象システム・構成・過去の障害履歴・現在の対応体制を整理する
- 必要な対応範囲とSLAの決定：業務影響から逆算し、対応時間帯・復旧目標を決める
- 複数社への相見積もり：同じ条件（範囲・SLA）を渡して比較し、金額差の理由を確認する
- 契約書の精査：前述の8項目、とくに追加料金・免責・解約条件を確認する
- 契約・引き継ぎ：既存ベンダーからの切り替え時は、手順書・設定・権限の返還を確認する
見直しのタイミングとして多いのは、保守費用が業務実態に合わなくなったときです。「ほとんど障害が起きないのに手厚い契約のまま」あるいは逆に「重要度が上がったのに対応時間が薄いまま」というミスマッチは、定期的な棚卸しで是正できます。また、システムを実際に開発・運用しているベンダーであれば、障害時の原因切り分けが速く、保守契約の内容も実態に即したものになります。
よくある質問
Q. システム保守契約は必ず結ばなければいけませんか？
A. 法的な義務はありません。ただし、業務に不可欠なシステムを都度発注（スポット）で運用すると、障害時にすぐ対応してもらえない、割高になる、優先度が下がるといったリスクがあります。停止が業務に直結するシステムは、年間保守契約で対応条件をあらかじめ固めておくのが安全です。
Q. 保守契約と運用契約は分けるべきですか？
A. 実務では1つの契約にまとめることが多く、必ずしも分ける必要はありません。重要なのは、監視・バックアップなどの運用業務と、障害復旧・修正などの保守業務のそれぞれが、契約の対応範囲に含まれているかを明確にすることです。範囲さえ明確なら、1本の契約でも問題ありません。
Q. 開発を依頼した会社以外に、保守だけを依頼できますか？
A. 可能なケースがほとんどですが、事前に現状調査（アセスメント）が必要になります。構成図や設定情報が残っていない環境では、調査に別途費用と期間がかかります。将来的に保守先を選び直せるよう、構成情報がドキュメントとコードで残されているかを、開発時点から確認しておくとスムーズです。
Q. SLAの稼働率はどのくらいに設定すればよいですか？
A. 業務影響から逆算します。止まると即座に売上や生産に直結するシステムは99.9%以上、多少の停止を許容できるシステムは99.5%程度が一つの目安です。稼働率を上げるほど冗長構成や有人対応が必要になり費用も上がるため、「本当に必要な水準」を見極めることが費用の適正化につながります。
Q. 保守契約を今のベンダーから切り替えても大丈夫ですか？
A. 引き継ぎの計画を立てれば問題ありません。鍵になるのは、現行ベンダーから運用手順書・監視設定・アカウント権限の一覧を受け取れるかどうかです。切り替え先が決まったら、並行期間を設けて情報を移し、切り替え後の初動対応まで確認しておくと、トラブルなく移行できます。
まとめ
システム保守契約のポイントを整理します。
- 保守契約は「対応範囲・品質・費用」を取り決める継続契約。まず自社に必要なのが運用か保守か両方かを整理する
- 契約形態は「年間保守かスポットか」「リモートかオンサイトか」を、システムの重要度に合わせて選ぶ
- 契約書には8項目（対応範囲・種類・時間・SLA・料金・再委託・免責・契約/解約条件）を必ず明記する
- SLAは応答時間・復旧目標時間・稼働率を、業務影響に見合った水準で設定する。過剰なSLAは費用を押し上げる
- 費用は開発費の年間15〜20%が目安。月額に含まれる範囲と別料金の単価をセットで比較する
- 「終わり方（解約・引き継ぎ）」まで契約時に決めておくことが、後悔しない保守契約のコツ
保守契約は、いざ障害が起きてからでは条件を整えられません。稼働中のシステムを守るためにも、対応範囲とSLAを明確にした契約を、実態に合った形で結んでおくことをおすすめします。
c3index に相談する
c3index は、製造業の基幹システムをはじめとするシステムの開発・運用・保守を一貫して手がけるシステム会社です。「今の保守契約が妥当か見てほしい」「他社が開発したシステムの保守を引き受けてほしい」「対応範囲やSLAの決め方から相談したい」といった段階からのご相談を承っています。現在のシステムと運用体制をうかがったうえで、過不足のない保守契約のかたちをご提案します。
