LASSIC Media らしくメディア
システム保守契約書の雛形｜条項ごとの記入例と発注側の注意点
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム保守契約書は、共通の条項を基本契約に、業務ごとの中身を個別契約と業務仕様書に書き分けます。
- 雛形の条項では、対象外の作業、更新の申し出の期限、月額に含む作業の量を具体的な値で埋めます。
- 準委任か請負かを業務ごとに決め、受付の記録から測れるサービスレベルを書いておきます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
保守会社から契約書の案が届いたが、どこを確かめればよいのか分からない。そもそも自社で雛形を用意するべきなのか、迷っている——。初めてシステムの保守を外部に頼む担当者には、こうした悩みがつきものです。システム保守契約書は、稼働しているシステムの維持や修正を委託するときに、作業の範囲・期間・費用・責任を取り決める書類です。
雛形があれば、条項の抜けには気づきやすくなります。ただし万能ではなく、条項の枠を埋めただけでは、どの作業が月額に含まれるのか、止まったときに誰が動くのかまでは決まりません。本記事では、保守の契約を初めて担当する情報システムの担当者に向けて、システム保守契約書の構成、条項ごとの書き方の例と確認点、準委任と請負の違い、サービスレベルの書き方、そして外部に頼むときに確認しておきたい点を整理します。
システム保守契約書とは
システム保守契約書は、稼働しているシステムの維持や修正、問い合わせ対応などの業務を外部の会社に委託するときに結ぶ契約書です。IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書（第二版）」（以下、モデル契約）には、保守と運用の業務を委託するための基本契約のモデルが入っています。*1
モデル契約は、保守と運用の業務は多種多様で、すべての形を網羅した一律の雛形は作れないとしています。*1 そこで、どの業務にも共通する条項を基本契約にまとめ、個々の業務の中身は個別契約と、そこに添付する書類で決める形を採っています。
- 基本契約：どの業務にも共通する条項（再委託、秘密情報、損害賠償など）
- 個別契約：委託料や実施期間など、業務ごとの主な取引の条件
- 業務仕様書：作業の内容、実施体制、サービスレベル（達成を目指す水準）
- 受託条件明細：対象のシステム、役割分担など、発注する会社ごとに違う項目
つまり、雛形の条項を埋めるだけでは足りず、業務仕様書と受託条件明細までそろえて、はじめて保守の中身が決まります。
保守契約書の条項と書き方の例
モデル契約の保守運用の基本契約と、個別契約や業務仕様書のサンプルから、発注側が値を書き込む条項を抜き出すと次の表のようになります。*1 書き方の例の「〇〇」は、自社のシステム名や数値に置き換えて使います。条項の名前や並べ方は、相手の会社の契約書に合わせてかまいません。
| 条項 | 決めること | 書き方の例 | 発注側が確かめる点 |
|---|---|---|---|
| 目的と適用範囲 | 基本契約と個別契約の関係、どちらを優先するか | 「個別契約で本契約と異なる定めをした場合は、個別契約の定めを優先する。」 | 業務ごとの条件をどの書類に書くかが決まっているか |
| 契約形態 | 準委任か請負か | 「本件業務の契約形態は準委任とする。」 | 月額の保守と、まとまった改修で形を分けるか |
| 業務内容と対象 | 対象のシステム、作業の種類、対象外の作業 | 「対象は〇〇システムとし、問い合わせ対応、障害の調査、軽微な修正を行う。機能の追加は別途見積もる。」 | 対象外の作業と、その頼み方まで書いてあるか |
| 実施時間帯 | 受け付ける曜日と時間、休日の扱い | 「〇曜日から〇曜日（祝日を除く）の〇時から〇時までとする。」 | 夜間や休日に止まったとき、誰が動くか |
| 実施期間と更新 | 開始日、期間、自動更新、申し出の期限 | 「期間は〇年間とし、満了の〇か月前までに申し出がなければ、同じ条件で〇年間更新する。」 | 見直しや乗り換えを考える時期を逆算できるか |
| 委託料と支払 | 月額か作業ごとか、料金に含む作業の量 | 「委託料は月額〇〇万円とし、当月分を当月末日までに支払う。」 | 月額に含む作業の量と、超えたときの扱い |
| 再委託 | 再委託の可否、事前の承諾、通知の方法 | 「再委託するときは、事前に再委託先の名称と所在地を書面で通知し、承諾を得る。」 | 実際に作業する会社と人が分かるか |
| 発注側の協力 | 発注側の作業、業務の変更を伝える義務 | 「甲は、業務の変更が本件業務に影響しうる場合、想定される影響を事前に乙に通知する。」 | 社内の窓口と担当の作業を決めているか |
| 報告と会議 | 定例報告の周期、定期協議会、議事録 | 「乙は実施状況を〇か月ごとに報告し、議事録は会議の〇日以内に提出する。」 | 報告書にどの数字が載るか |
| 障害時の対応 | 緊急連絡体制、連絡の手順 | 「障害時の緊急連絡体制は、業務仕様書と運用手順書に定める。」 | 連絡網と手順書がそろっているか |
| サービスレベル | 測る項目、目標値、達成できなかったときの扱い | 「インシデントの受付から一次応答までの時間について目標値を定め、遵守率を報告する。」 | 受付の記録から測れる項目か |
| 資料とデータ | 渡す資料、終了後の返却や消去、蓄積された情報 | 「不要になった資料は返却し、または甲の指示に従って消去する。」 | 消去した証明を受け取れるか |
| 損害賠償 | 賠償の範囲、上限額、請求できる期間 | 「賠償の累計総額は、個別契約に定める〇〇の金額を限度とする。故意又は重大な過失による場合は除く。」 | 上限額が業務の重さに見合っているか |
表の中で抜けやすいのは、業務内容の行の「対象外の作業」です。保守の範囲に入っていると思っていた機能の追加が、実は別の見積もりだった、という食い違いはここで防げます。実施期間の行も見落とされがちです。モデル契約の例は、満了の一定期間前までに申し出がなければ同じ条件で更新する形なので、*1 申し出の期限を社内の予定表に入れておきます。
準委任と請負の違い
保守の業務は、内容によって準委任にも請負にもなります。モデル契約は、どちらにするかを個別契約で決めるとし、それぞれの場合の受託者の責任を書き分けています。*1 違いをまとめると次のとおりです。
| 項目 | 準委任 | 請負 |
|---|---|---|
| 受託者が負う義務 | 善良な管理者の注意をもって作業する。仕事の完成の義務は負わない | 仕事を完成させる |
| 結果に誤りがあったとき | 注意を怠った場合に、債務不履行の責任を負う | 誤りや業務仕様書との不一致を直し、損害を賠償する |
| 報酬の考え方 | 作業に対して払う。成果に対して払う形も選べる | 完成した仕事に対して払う |
| 保守で向いている業務 | 問い合わせ対応や障害の調査など、作業の中身を前もって決めきれない業務 | 対象と完成の姿を前もって決められる改修 |
民法には、準委任で受託者が別の会社に作業を任せるには、委任者の許諾か、やむを得ない事由が要るという定めがあります。*2 作業が途中で終わったときは、すでにした分の割合で報酬を請求できます。成果に対して報酬を払うと決めた場合は、成果の引き渡しと同時に払う形になります。*2 契約書の報酬の条項は、作業に払うのか、成果に払うのかが読み取れる書き方にしておきます。
サービスレベルの書き方
保守の質を数字で確かめたいときは、業務仕様書にサービスレベルを書きます。モデル契約のアプリケーション保守のサンプルは、次の3つの項目について目標値を定め、達成の状況を定例の報告書で示す形です。*1
- インシデント（異常や中断）の一次応答：受付から最初の連絡までの時間を守れた割合
- 質問への一次回答：受付から、回答か調査の状況と回答の予定日を示すまでの時間を守れた割合
- 改良の納期：改良の受付から、受け入れの承認を求めるまでの時間を守れた割合
どれも受付の記録から測れる項目です。モデル契約は、サービスレベルを入れるときの注意として、客観的に評価できるか、求める水準を達成できるか、時間に沿って見直せるか、測定と監視の費用が見合うかを挙げています。*1 達成できなかったときの扱い（協議、解約、ペナルティなど）と、報告の条件も契約書に書いておきます。項目の選び方は保守契約のSLA設計で扱っています。
外部に頼むときに確認しておきたい点
保守の契約書は、相手の会社が用意したものを使うことが多い書類です。条項を読む前に、委託する業務そのものを社内で整理しておくと、表の確認点に答えやすくなります。見積もりの前に、次の点を確かめておきます。
- 範囲：対象のシステムと作業、対象外の作業と、その頼み方
- 期間：実施期間、更新の申し出の期限、見直しの時期
- 体制：双方の窓口責任者、障害時の連絡網、再委託先
- 費用の決まり方：月額に含む作業の量と、超えたときの見積もり
- 引き継ぎ：設計書やソースコードの受け取り方と、終了時の資料の返却
モデル契約は、保守の段階でも発注側の参画が欠かせないとしています。*1 保守の会社を比べる段階の見方はシステム保守会社の選び方にまとめています。
まとめ：保守契約書で確かめたい3つの点
システム保守契約書を用意するうえで、確かめておきたい点は3つに整理できます。第一に、基本契約の条項だけでなく、業務仕様書と受託条件明細まで含めて、対象の作業と対象外の作業を書き分けること。第二に、実施期間と更新の申し出の期限、月額に含む作業の量を、具体的な値で埋めること。第三に、業務ごとに準委任か請負かを決め、受付の記録から測れるサービスレベルと、達成できなかったときの扱いを書いておくことです。この3点を踏まえておけば、「保守に入っていると思っていた作業が別料金だった」という事態を避けやすくなります。条項の書き方や業務の切り分けに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
保守会社が用意した契約書をそのまま使ってもよいですか
そのまま使う前に、本文の表の条項と照らして、抜けている条項や値が空いている箇所を確かめます。業務仕様書や料金表などの添付の書類まで読み、対象外の作業と更新の条件を確かめておきます。個別の契約の内容は、法務の担当者や弁護士などの専門家に確認してください。
開発を頼んだ会社とは別の会社に保守を頼めますか
頼めます。モデル契約の解説は、著作権を持たない発注側が別の会社に保守と運用を委託することは可能としています。*1 そのためにも、開発の契約の段階で、納入物にソースコードや設計書を含めておくことが大切です。
開発の契約不適合責任があれば保守契約は要りませんか
役割が違うため、分けて考えます。契約不適合責任は、納めたものが契約の内容に合わないときの責任です。モデル契約の解説は、契約不適合かどうかを問わずに対応してもらう保守契約を結ぶほうが、かえって経済的な局面もあるとしています。*1
システム保守の契約と体制づくりのご相談
保守の範囲と作業の一覧づくりから、サービスレベルの項目と測り方、障害時の連絡体制の取り決めまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：第二版（2025年4月8日更新）のうち「情報システム保守運用委託基本モデル契約書」（基本契約方式、第3条 個別契約、第7条 甲の協力、第9条 会議体、第10条 障害発生時の対応手順、第14条 本件業務に関する責任、第15条 資料等の提供及び返還、第20条 契約期間）、個別契約書と業務仕様書のサンプル（アプリケーション保守サービス）、開発モデル契約の第7条（再委託）と第53条（損害賠償）、保守・運用段階のSLAの留意点、請負と準委任の相違点の記述を参照（2026年10月確認）
- *2 参考：法務省「民法の一部を改正する法律（債権法改正）について」新旧対照条文（https://www.moj.go.jp/MINJI/minji06_001070000.html）。出典：民法第644条の2（復受任者の選任等）、第648条第3項（受任者の報酬）、第648条の2（成果等に対する報酬）を参照（2026年10月確認）
