システムの保守契約で最も大切なのは、「何をしてくれる契約なのか」を作業の種類ごとに書き分けておくことです。障害が起きたときの対応、日々の問い合わせへの回答、軽微な修正、OSやライブラリの更新、監視、バックアップの確認。これらはどれも「保守」と呼ばれがちですが、手間もリスクもまったく違います。ひとまとめに「保守一式」としておくと、いざというときに「それは契約の範囲外です」「それくらいは保守でやってくれると思っていた」という食い違いが起き、対応が遅れたり、追加の費用をめぐって関係がこじれたりします。
この記事は、自社のシステムやサービスの保守契約をこれから結ぶ、あるいは今の契約内容に不安がある事業責任者・情報システム担当・経営者の方に向けたものです。保守契約に含めるべき項目、対応時間と対応の速さの決め方、費用の決め方の型、契約書や仕様書で確認すべき点、よくあるトラブルとその避け方を順に説明します。
なお、契約書の法的な書き方や、請負・準委任といった契約形態の法的な扱いは、最新の情報を弁護士などの専門家に確認してください。本記事では、発注側として「何を決めておくべきか」という実務の観点に絞って説明します。
保守契約とは：開発契約・運用契約との違い
保守契約は、システムが公開された後も、正しく動き続け、必要に応じて直していけるようにするための契約です。開発契約がシステムを「作る」ための契約であるのに対し、保守契約は作ったものを「維持する」ための契約だと言えます。
似た言葉に「運用」があります。会社や契約によって使い方は違いますが、一般に、運用はシステムを日々動かす作業（データの登録、アカウントの発行、定期的な処理の実行など）を指し、保守はシステムそのものを維持・修正する作業（不具合の修正、更新作業、障害の復旧など）を指すことが多いです。保守契約に運用の作業まで含めるのか、別の契約にするのかも、最初に決めておくべき点の一つです。
保守契約が曖昧になりやすいのは、開発契約に比べて「成果物」がはっきりしないからです。開発であれば、完成したシステムが成果物ですが、保守では「何も起きなかった月」も多く、何に対してお金を払っているのかが見えにくくなります。だからこそ、作業の種類と範囲を言葉にして残しておくことが重要です。
保守契約に含めるべき作業の種類
保守と呼ばれる作業は、大きく次の種類に分けられます。契約では、それぞれを含めるか、含める場合はどこまでかを明記します。
| 作業の種類 | 内容 | 決めておくこと |
|---|---|---|
| 障害対応 | システムが止まった、正しく動かないときの調査と復旧 | 受付時間、対応開始までの時間、復旧の目標、連絡方法 |
| 問い合わせ対応 | 操作方法や仕様に関する質問への回答 | 受付窓口、回答の目安時間、件数の上限 |
| 不具合の修正 | 本来の仕様どおりに動かない部分の修正 | 不具合の定義、修正の優先度、検証の方法 |
| 軽微な改修 | 文言の変更、項目の追加など小さな変更 | 「軽微」の基準、月あたりの作業時間の枠 |
| 更新作業 | OS、ミドルウェア、ライブラリ、証明書などの更新 | 対象の範囲、実施の頻度、検証の方法 |
| 監視 | サーバーやサービスの稼働状況の監視とアラート対応 | 監視の項目、通知先、夜間・休日の扱い |
| バックアップ | データの定期的な保存と、復元できるかの確認 | 取得の頻度、保管期間、復元テストの頻度 |
| 報告 | 作業内容や稼働状況の定期報告 | 報告の頻度、形式、定例会議の有無 |
| セキュリティ対応 | 脆弱性情報の確認と対応 | 情報収集の範囲、緊急時の対応方法 |
すべてを含める必要はありません。システムの重要度と予算に応じて、何を含め、何を含めないかを選びます。含めない作業については、必要になったときに別途見積もりで依頼する、と明記しておけば、後から揉めることはありません。
障害対応の範囲と対応時間の決め方
障害対応は、保守契約の中で最も揉めやすい部分です。次の点を具体的に決めておきます。
障害の重さの区分
すべての障害に同じ速さで対応する必要はありません。障害の重さを区分し、区分ごとに対応の速さを決めます。
| 区分 | 状態の例 | 対応の考え方 |
|---|---|---|
| 重大 | サービス全体が使えない、決済や受注ができない、データが失われるおそれ | 受付後すぐに対応を開始し、復旧を最優先する |
| 高 | 主要な機能の一部が使えないが、回避策がある | 当日中など、短い時間で対応を開始する |
| 中 | 一部の利用者や画面で不具合があるが、業務は続けられる | 翌営業日以降に対応を開始し、計画的に修正する |
| 低 | 表示の乱れなど、業務への影響が小さい | 次回の改修にあわせて修正する |
区分の判断を誰が行うのか（発注側か保守会社か）も決めておきます。発注側が「重大」と考えていても、保守会社が「中」と判断すると、対応の速さにずれが出ます。
受付時間と夜間・休日の扱い
障害の受付時間を、平日の日中だけにするのか、夜間や休日も含めるのかを決めます。夜間・休日も対応する契約は、待機する人の確保が必要になるため、費用は大きく変わります。サービスが夜間や休日にも使われるのか、止まったときにどのくらいの損失が出るのかを踏まえて判断します。夜間・休日は重大な障害だけを受け付ける、という中間の決め方もあります。
「対応開始」と「復旧」を分ける
「障害時は◯時間以内に対応」と書かれていても、それが「連絡に返事をする時間」なのか、「調査を始める時間」なのか、「復旧させる時間」なのかで意味がまったく違います。一般に、対応開始までの時間は約束しやすい一方、復旧までの時間は原因によって大きく変わるため、目標として扱うことが多いです。契約ではどの時点を指すのかを明記します。
稼働の目標の考え方は稼働率、障害時の連絡体制と手順はシステム障害時の対応フローで詳しく説明しています。
障害以外の保守作業の範囲の決め方
障害対応は「起きたときにどう動くか」の取り決めですが、保守契約の費用の多くは、障害が起きていない平常時の作業に使われます。平常時の作業は目に見えにくいため、範囲や頻度を決めておかないと、実施されていないことに気づけません。ここでは、範囲の線引きで揉めやすい改修と、予防のための作業に分けて説明します。
軽微な改修と「保守の範囲」の線引き
保守契約で次に揉めやすいのが、「どこまでが保守で、どこからが追加の開発か」という線引きです。
発注側から見ると、文言を少し変える、入力項目を一つ増やす、といった作業は「保守でやってもらえる範囲」に思えます。一方、保守会社から見ると、どんなに小さな変更でも、調査、修正、テスト、公開の作業が発生します。この認識のずれを防ぐには、次のような決め方が有効です。
- 作業時間の枠で決める：月あたり一定の作業時間までは保守の範囲で対応し、超えた分は別途見積もりにする。使わなかった時間を翌月に繰り越せるかも決めておく。
- 作業の種類で決める：文言・画像の差し替え、既存項目の選択肢の追加など、範囲内とする作業を例示する。
- 不具合と仕様変更を分ける：本来の仕様どおりに動かない「不具合」の修正は保守の範囲、仕様そのものを変える「仕様変更」は別途見積もり、と区別する。
不具合と仕様変更の区別は、元の仕様書がないと判断できません。開発時の仕様書や要件定義書が保守会社の手元にあり、最新の状態に保たれていることが前提になります。
予防のための作業：更新・監視・バックアップ
障害が起きていないときに行う予防的な作業も、契約で明確にしておきます。この部分を含めない契約にすると、何も起きない間は安く済みますが、問題が起きたときの影響が大きくなります。
更新作業
OSやミドルウェア、プログラムが使っているライブラリには、定期的に更新が出ます。セキュリティ上の問題の修正が含まれることも多く、放置すると、ある日突然サポートが終わったり、大きな作り直しが必要になったりします。更新作業を保守に含めるのか、含める場合は何をどの頻度で更新するのか、更新後の動作確認を誰がするのかを決めます。更新を放置するリスクはライブラリ更新を放置するリスクで詳しく扱っています。
監視
サービスが止まっていないか、応答が遅くなっていないか、ディスクの容量が足りなくなっていないかを監視し、異常があれば通知する仕組みです。監視の仕組みを誰が用意し、通知を誰が受け取り、受け取った後に誰が動くのかを決めます。通知を受け取るだけで対応は翌営業日、という契約も珍しくないため、通知と対応の関係を確認しておきます。
バックアップ
データのバックアップを取っているだけでは不十分です。実際に復元できるかを定期的に試していないと、いざというときに復元できないことがあります。取得の頻度、保管の期間、復元テストの頻度、復元にかかる時間の目安を決めておきます。どの時点まで戻せればよいか、どのくらいの時間で戻せればよいかという目標の考え方は、RPO・RTOの解説が参考になります。
費用の決め方の型
保守の費用の決め方には、いくつかの型があります。具体的な金額の相場ではなく、それぞれの型の特徴を整理します。
| 型 | 内容 | 向いている場面 | 注意点 |
|---|---|---|---|
| 定額型 | 毎月決まった金額で、決められた範囲の作業を行う | 作業量が安定しているシステム | 範囲を明確にしないと、どこまでが定額か揉める |
| 時間枠型 | 毎月一定の作業時間を確保し、その範囲で作業する | 軽微な改修が継続的に発生するシステム | 超過分の扱いと、繰り越しの可否を決める |
| 従量型 | 作業が発生した分だけ、作業時間に応じて支払う | 変更が少なく、障害もまれなシステム | 緊急時にすぐ対応してもらえる保証がない |
| 組み合わせ型 | 待機・監視・更新は定額、改修は時間枠や従量 | 多くのシステム | 内訳ごとに範囲を書き分ける |
実務では、障害対応の待機や監視、定期的な更新作業のように「何も起きなくても必要な部分」を定額にし、改修のように「量が変わる部分」を時間枠や従量にする組み合わせ型が使われることが多いです。費用の内訳と妥当性の見方は、システム保守費用の考え方でさらに詳しく説明しています。
保守契約を結ぶまでの手順
保守契約の内容は、次の順に整理すると漏れが少なくなります。
- システムの全体像を把握する：どのサーバーやクラウドで動いているか、どの外部サービスと連携しているか、誰が使っているかを一覧にします。
- 止まったときの影響を整理する：機能ごとに、止まったときに業務や売上、顧客にどんな影響が出るかを書き出し、重要度をつけます。
- 必要な作業の種類を選ぶ：前述の作業の種類から、含めるものと含めないものを選びます。
- 障害の区分と対応時間を決める：重要度に応じて、受付時間、対応開始までの時間、復旧の目標を決めます。
- 改修の範囲と時間枠を決める：軽微な改修の基準と、月あたりの作業時間の枠を決めます。
- 費用の型を決める：定額にする部分と、時間枠や従量にする部分を分けます。
- 連絡と報告の方法を決める：問い合わせの窓口、緊急時の連絡先、定期報告の頻度と形式を決めます。
- 契約書や仕様書に書き起こす：決めた内容を、契約書の本文か、別紙の保守仕様書として文書にします。契約形態や責任の範囲については、専門家に確認します。
- 定期的に見直す時期を決める：一年ごとなど、契約内容を見直す時期をあらかじめ決めておきます。
具体例：保守契約の範囲を見直した場面
ここでは架空の一般例として、会員向けの予約サイトを運営している会社を想定します。
この会社は、サイトを開発した会社とそのまま「保守一式」という契約を結んでいました。月額の費用は決まっていたものの、何が含まれているかは文書になっていませんでした。ある週末、予約が受け付けられない障害が起き、担当者が開発会社に連絡したところ、休日は対応していないため月曜日の対応になると言われました。さらに、復旧後に依頼した予約画面の文言修正は、保守の範囲外として別途見積もりになりました。
社内で話し合った結果、発注側も「一式」の中身を確かめていなかったことが問題だと分かりました。そこで、開発会社と協議して保守仕様書を作り直しました。予約や決済が止まる障害は「重大」とし、休日も受け付けて対応を始める。それ以外の障害は平日のみの対応にする。月あたり一定時間の改修枠を設け、文言変更などはその枠で対応する。ライブラリの更新は四半期ごとに行い、結果を報告する。バックアップの復元テストは年に一度行う。こうした内容を一つずつ書き出しました。
休日の待機を加えたことで月額の費用は見直しになりましたが、何に費用を払っているかが明確になり、社内での説明もしやすくなりました。また、改修枠の使い道を毎月の定例で決めるようになり、小さな改善が継続的に進むようになりました。
保守契約でよくあるトラブルと避け方
「一式」で契約して範囲が分からない：作業の種類ごとに、含めるもの・含めないものを書き出します。含めない作業は、別途見積もりで依頼できることを明記します。
対応時間の意味が食い違う：「対応」が返事なのか、調査開始なのか、復旧なのかを明記します。夜間・休日の扱いも必ず書きます。
不具合か仕様変更かで揉める：判断の基準となる仕様書を最新の状態に保ち、判断に迷うものは協議して決める手順を決めておきます。
更新作業が行われていない：更新作業を含める場合は、実施の頻度と報告の方法を決め、実施されたことを確認します。
担当者しか分からない状態になる：保守会社の担当者が一人に偏っていると、その人が不在のときに対応できません。体制と、設計資料や手順書の整備状況を確認します。
解約や乗り換えのときに困る：契約終了時に、ソースコード、設計資料、サーバーの管理権限、各種アカウントをどう引き渡すかを、契約の段階で決めておきます。
報告がなく、何をしているか分からない：定額の保守では、作業の中身が見えないと、費用の妥当性を判断できません。月に一度、対応した問い合わせや障害、実施した更新作業、使った改修時間をまとめた報告を受け取る取り決めにします。報告の内容は、契約の見直しや予算の検討の材料にもなります。
保守契約の確認チェックリスト
- 保守に含める作業の種類と、含めない作業が書き分けられている
- 障害の重さの区分と、区分ごとの対応の速さが決まっている
- 受付時間と、夜間・休日の扱いが明記されている
- 「対応開始」と「復旧」のどちらを約束しているかが明確である
- 軽微な改修の基準と、月あたりの作業時間の枠が決まっている
- 不具合と仕様変更を区別する基準となる仕様書がある
- 更新作業の対象と頻度、報告の方法が決まっている
- 監視の通知を誰が受け、誰が動くかが決まっている
- バックアップの取得と、復元テストの頻度が決まっている
- 問い合わせ窓口と緊急時の連絡先が明記されている
- 定期報告の頻度と形式が決まっている
- 契約終了時の資料・権限・アカウントの引き渡し方法が決まっている
- 契約内容を見直す時期が決まっている
よくある質問
Q. 開発した会社とそのまま保守契約を結ぶべきですか？
システムを最もよく知っているのは開発した会社なので、そのまま保守を依頼するのが自然な選択です。ただし、対応時間や体制が自社の求める水準に合っているかは、開発契約とは別に確認する必要があります。合わない場合は、保守を専門に引き受ける会社に依頼する選択肢もあります。
Q. 保守契約を結ばずに、必要なときだけ依頼することはできますか？
できますが、障害が起きたときにすぐ対応してもらえる保証はありません。また、更新作業などの予防的な作業が行われないため、問題が大きくなってから対処することになりがちです。利用者が少なく、止まっても影響が小さいシステムであれば、従量型の依頼でも成り立つことがあります。
Q. 保守仕様書は誰が作るものですか？
保守会社がひな形を用意することが多いですが、発注側も内容を確認し、自社の業務に照らして必要な項目を追加すべきです。特に、止まったときの影響や重要な機能の判断は、業務を知っている発注側にしかできません。
Q. 契約内容はどのくらいの頻度で見直すべきですか？
一年に一度は見直すのが目安です。利用者の増加、機能の追加、事業の重要度の変化に応じて、必要な対応時間や作業の範囲は変わります。大きな機能追加やサービスの拡大があったときは、その都度見直します。
Otsumuに相談できること
システムの規模が小さく、開発会社との関係が良好で、止まったときの影響も限られている場合は、この記事のチェックリストを使って今の契約内容を確認し、足りない項目を開発会社と協議して追記するだけで、十分に整えられることが多いです。外部に頼まずに自社で進められます。
一方で、今のシステムの構成や保守の状態を社内で誰も把握していない、保守会社の対応に不安があるが何を求めればよいか分からない、事業の拡大にあわせて保守の水準を見直したい、といった状況では、技術と事業の両方を理解した第三者に状態を確認してもらうほうが安全です。
Otsumuは自らも事業を手がける立場から、事業への影響を起点に必要な保守の範囲を整理し、現状の調査、保守仕様の設計、保守の引き受け、運用の改善までを一気通貫で支援しています。既存システムの保守のご相談は保守・運用で承っています。範囲に応じて個別にお見積もりします。
今の契約書や保守の内容が分かる資料をお持ちいただければ、確認すべき点を一緒に整理できます。まずは30分の無料相談をご利用ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01