保守契約書で最低限入れたい項目とは？対応時間・対象範囲・免責の決め方

Webサイトや小規模なWebシステムを納品したあと、かなり高い確率で出てくるのが「保守契約書には何を書けばいいですか？」という話です。
作る側からすると、サーバー更新、障害調査、軽微な修正、問い合わせ対応、バックアップ確認、外部サービス変更への追随など、納品後にも仕事は残ります。

一方で、依頼する側から見ると、何が対象範囲で、いつ対応してくれて、どこから追加費用で、どこまで責任を持つのかが見えにくいことがあります。
ここを曖昧にしたまま契約すると、あとでかなり揉めます。

この記事では、保守契約書で最低限入れたい項目を中心に、対応時間、対象範囲、追加費用、免責、SLAの置き方、そして別見積との線引きまで整理します。
法的な最終判断は契約内容や業種によって変わるため、実際の契約書は弁護士や法務担当と確認してください。ここでは、制作会社、フリーランス、開発会社がクライアントへ説明するときの実務上の整理に寄せます。

契約や外部サービス利用まで含めて見たい場合は、AIツール利用料はクライアントに請求できる？経費計上と見積書の考え方 や 生成AIにクライアント情報を入力してよい？機密情報・契約・ログ管理の実務判断 も近い論点です。

保守費用は何のための費用か

保守費用は、単に「何かあったら直します」という気持ちの料金ではありません。
実務では、次のような継続責任をどこまで引き受けるかを金額にしたものです。

つまり保守費用は、作業時間だけでなく「継続して見てくれる状態」「困ったときに連絡できる状態」「事故時に切り分けできる状態」を維持する費用でもあります。
ここを説明しないと、クライアントには「毎月の保険料みたいなもの？」とぼんやり伝わってしまいます。

まず結論：契約書には「いつ・どこまで・何を除くか」を最低限入れる

保守契約書で最低限入れたいのは、次の3本柱です。

1. いつ対応するか
   対応時間、休日夜間の有無、初動返信、優先度。
2. どこまで対応するか
   対象システム、対象範囲、月額内作業、追加費用条件。
3. 何を除くか
   免責、対象外、外部サービス障害、契約主体の違い、操作ミス時の扱い。

この3つが弱いと、保守契約書はあっても、実務では機能しません。
逆に、小規模案件でもここがそろっていればかなり揉めにくくなります。

まず結論：月額保守より重い変更は別見積にしやすい

最初にざっくり整理すると、次の考え方がかなり使いやすいです。

• 既存の仕組みを安全に使い続けるための確認、調査、軽微修正: 月額保守に入れやすい
• 構成、ページ数、機能、外部連携、作業量、責任範囲が増えるもの: 別見積にしやすい

特に、次のどれかに当てはまる作業は、別見積にした方が安全です。

1. 新しいページや機能を足す
2. 既存仕様や業務フローを変える
3. デザインや構成を大きく変える
4. 外部サービスやサーバー構成に手を入れる
5. 調査や確認ではなく、実装や移行が中心になる

この基準があると、何でも保守で見ます でも 全部追加費用です でもない、現実的な線引きがしやすくなります。

保守と追加開発を分ける

まず決めるべきなのは、保守と追加開発の境目です。

よくある失敗は、保守契約の中に「ちょっとした修正」を入れた結果、その「ちょっと」が無制限になることです。
ボタン文言の変更なら月額内、フォーム項目追加は別見積、外部サービス連携は別見積、というように例を出しておくと、あとで説明しやすくなります。

保守範囲に入れやすいもの

小さなWebシステムや業務アプリなら、保守範囲に入れやすいのは次のような作業です。

• 月数件までの問い合わせ対応
• 既存機能の不具合調査
• 軽微な文言修正、設定変更
• サーバー容量、ログ、バックアップの簡易確認
• SSL証明書、ドメイン、外部サービスの期限確認
• ライブラリやCMSの軽微な更新
• 障害時の一次切り分け
• 月次または四半期の簡単な状況報告

ここで大事なのは、「調査」と「修正」を分けて書くことです。
障害報告を受けて原因を調べるところまでは保守に含むが、大きな改修が必要な場合は別見積、という線引きはかなり現実的です。

たとえば、問い合わせフォームが送信できない場合でも、原因はさまざまです。
アプリの不具合、メールサーバーの制限、DNS設定、reCAPTCHAの仕様変更、外部SMTPの契約切れ、迷惑メール判定などがあり得ます。調査をして初めて、保守内で直せるのか、別作業なのかが分かります。

Webサイト保守で月額費用に含めやすい範囲

ここは、いわゆるWebサイト保守で一番聞かれやすい部分です。
コーポレートサイト、サービスサイト、採用サイト、問い合わせフォーム付きの中小規模サイトなら、月額保守に含めやすい範囲は次のようなものです。

Webサイト保守では、更新が少ないから何もしていないように見える ことがあります。
でも実際には、期限確認、送信確認、フォーム確認、バックアップ確認のような、事故が起きないように見る仕事が入っています。

特に問い合わせフォーム付きのサイトでは、サイトは表示されているのに、問い合わせメールだけ届かない という事故が普通にあります。
この種の確認は、納品後に地味ですが価値が出やすい保守です。
WordPress サイトの保守で最低限見るべきセキュリティ確認を先にそろえたい場合は、WordPress保守で最低限やるべきセキュリティ確認とは？更新・権限・バックアップの基本 もあわせて読むとつながりやすいです。 退職者、外注先、共用アカウントまで含めて WordPress の管理者アカウントをどう整理するかを先に見たい場合は、WordPress管理者アカウントの整理方法｜退職者・外注・共用アカウントの見直し もあわせて読むと実務で使いやすいです。 WordPress や小規模サイトで WAF を本当に入れるべきか、やりすぎになる境目まで見たい場合は、WAFとは？WordPressや小規模サイトで本当に必要かを整理 もあわせて読むと判断しやすいです。

Webサイト保守で別見積にしやすい範囲

逆に、Webサイト保守の月額に何でも入れると危ない作業もあります。

• 新しいページの追加
• デザインリニューアル
• 原稿作成やライティング
• SEO改善の継続提案や大規模リライト
• GA4 / Search Console の詳細分析レポート
• 大きなフォーム改修やCRM連携
• 会員機能、予約機能、決済機能の追加
• CMSのメジャー更新でテーマ改修まで必要な作業
• サーバー移転やドメイン移管
• 広告運用や記事制作の継続支援

ここを最初に曖昧にすると、クライアント側は「月額保守の中でサイト改善も見てくれる」と期待しやすくなります。
実際には、保守と改善は役割が違います。保守は安全に使い続けるためのもの、改善は成果を伸ばすためのもの、と分けた方が説明しやすいです。

別見積にしやすい作業一覧

どこまでが月額内ですか と聞かれたときは、次の一覧がかなり使いやすいです。

Webサイト保守の月額説明でよく使いやすい線引き

Webサイト保守では、次のように線引きするとかなり説明しやすいです。

この形にすると、毎月の維持管理 と 成果を伸ばすための追加支援 を分けやすくなります。

保守範囲から外しやすいもの

逆に、月額保守に何でも入れると危ない作業もあります。

• 新しい画面や機能の追加
• 業務フロー変更に伴う仕様変更
• デザインリニューアル
• 外部API、決済、基幹システム連携の追加
• 大量データ修正やデータ移行
• サーバー移転、クラウド構成変更
• セキュリティ事故後の本格調査
• 第三者診断、脆弱性診断、ペネトレーションテスト
• 休日夜間の緊急対応
• クライアント側の操作ミスによる大規模復旧

もちろん、これらを保守に含めてはいけないわけではありません。
ただし含めるなら、月額費用も責任も変わります。特に休日夜間対応や緊急待機は、実際に作業していない時間にも拘束が発生するため、通常の月額保守とは分けて説明した方がよいです。

セキュリティ面の全体像は、セキュリティ初心者が最初に覚える攻撃手法と防御の基本 ともつながります。
保守契約に「セキュリティ対応」と書く場合も、パッチ適用なのか、WAF設定なのか、診断なのか、事故対応なのかを分けないと範囲が広がりすぎます。

金額をどう考えるか

保守費用の金額は、単純な相場表だけで決めるより、次の要素から説明する方が納得されやすいです。

小規模案件であれば、月額数万円のライトな保守から始めることもあります。
ただし、月額が低い場合は「平日営業時間内の一次確認」「月数時間まで」「大きな改修は別見積」のように、できることを絞る必要があります。

逆に、売上に直結するEC、予約、会員、業務システム、社内の基幹処理に近いものでは、月額だけを安くしても意味がありません。
止まったときに誰が見るのか、何時間以内に反応するのか、復旧に必要な情報が揃っているのかを決めていないと、安い保守費用は安心につながりません。

金額説明の言い方

クライアントに説明するときは、「月額いくらです」だけでなく、何を守るための金額かを添えます。

納品後も、サーバー・外部サービス・ブラウザ・ライブラリ・業務内容は変化します。
保守費用は、既存システムを安全に使い続けるための問い合わせ対応、一次調査、軽微修正、バックアップや期限の確認、障害時の切り分けを行うための費用です。
新機能追加や大きな仕様変更は、保守とは別にお見積りします。

この説明に加えて、月額内で対応できる例と、別見積になる例を並べると伝わりやすくなります。

説明のコツは、「できません」と冷たく切るのではなく、「月額内で守る範囲」と「別見積で安全に進める範囲」を分けることです。
追加開発を保守内に無理に入れると、開発者側は赤字になり、クライアント側も優先順位や品質が曖昧になります。

保守契約書で最低限入れたい項目

保守契約では、最低限次の項目を決めておくと揉めにくくなります。

• 対象システム、対象サーバー、対象ドメイン
• 対応範囲と除外範囲
• 対応時間、休日夜間対応の有無
• 連絡手段、緊急連絡先
• 初動返信時間、復旧目標、優先度
• 月額内の作業時間、問い合わせ件数
• 未使用時間の繰越可否
• 追加費用になる条件
• バックアップ、ログ、監視の責任分担
• 外部サービス、クラウド、SaaSの契約主体
• 再委託の有無
• 秘密保持、個人情報、セキュリティ要件
• 契約期間、更新、解約、引き継ぎ資料

特に外しにくい3項目

1. 対応時間

平日営業時間内のみか 休日夜間も見るのか が曖昧だと、障害時に一番揉めやすいです。
小規模案件なら、まずは 平日10時〜18時受付 / 1営業日以内に一次返信 のように現実的な表現で十分です。

2. 対象範囲

アプリだけか、サーバー、DNS、メール、外部API、ドメインまで含むかで、保守負荷はかなり変わります。
サイト保守一式 のような書き方は広く見えすぎるので、対象システムと対象外を短くても明記した方が安全です。

3. 免責

保守契約では、何でも直す契約ではない ことを言葉にしておく必要があります。
たとえば次のようなものは、免責や別途協議として整理しやすいです。

• 外部クラウドやSaaSの障害
• ドメイン失効や契約切れ
• クライアント側操作ミスやアカウント管理不備
• 事前共有のない環境変更
• 保守対象外機能への影響

ここを書かないと、制御できない原因まで 保守契約しているのに と受け取られやすくなります。

IPAの「情報システム・モデル取引・契約書（第二版）」でも、受託開発や保守運用を含むモデル契約書が公開されており、ユーザ企業とITベンダが共通理解のもとで対話を深めることが期待されています。
実案件では、そのまま使うのではなく、自社の契約書や案件規模に合わせて、保守範囲、責任分担、セキュリティ、プロジェクト管理の観点を確認する材料として見るとよいです。

秘密情報や外部委託の扱いがある案件では、秘密保持契約や再委託条項も確認します。
保守では本番データ、障害ログ、顧客情報、管理画面の権限に触れることがあるため、開発時より情報管理が重くなる場面もあります。

SLAはどこまで入れるべきか

SLAは、サービスレベルに関する合意です。
保守契約でよく出るのは、初動返信時間、対応時間帯、稼働率、障害優先度、復旧目標、報告方法などです。

ただし、小規模な受託開発でいきなり厳密なSLAを約束すると危険です。
たとえば「24時間365日対応」「1時間以内復旧」のような文言は、待機体制、監視、冗長構成、権限、費用が揃っていないと現実的ではありません。

小規模案件では、まず次のような表現から始める方が安全です。

• 平日10時から18時まで受付
• 障害報告は原則1営業日以内に一次返信
• 重大障害は可能な範囲で優先対応
• 原因調査後、保守内対応か別見積かを判断
• 外部サービス障害、クライアント側操作、契約切れは対象外または別途協議

大事なのは、「復旧を保証します」と簡単に書かないことです。
アプリ側の不具合なら直せても、クラウド障害、決済代行の障害、メール配送制限、ドメイン契約切れ、クライアント側の操作ミスなど、開発者だけでは制御できない原因もあります。

保守費用を安く見せすぎると起きること

保守費用を安く見せると契約は取りやすく見えます。
ただし、範囲を曖昧にしたまま安くすると、あとで次のような問題が起きます。

• いつでも無料で相談できると思われる
• 追加開発が保守内だと思われる
• 夜間休日も対応してもらえると思われる
• サーバー、DNS、メール、外部APIまで全部見ていると思われる
• 障害時に「保守契約しているのに」と不満が出る
• 開発者側が疲弊し、通常開発の品質も落ちる

免責をどう書くと角が立ちにくいか

免責 という言葉は強く見えますが、実務では必要です。
ただし、全部を突き放すように書くより、受注側で制御できる範囲 / できない範囲 を分けて書く方が伝わりやすいです。

たとえば、次のような書き方です。

外部クラウド、ドメイン管理会社、メール配信サービス等の第三者サービス起因の障害については、原因調査および連携支援は行いますが、当該サービス自体の復旧保証は対象外とします。

お客様側で実施された設定変更、アカウント管理不備、契約失効、素材未提供に起因する遅延や不具合については、必要に応じて別途対応を協議します。

この形なら、丸投げ感を減らしながら、責任範囲を明確にできます。

保守は、信頼関係を作るための継続契約です。
だからこそ、最初に安く広く見せるより、狭くても明確な範囲から始め、必要に応じて上位プランや追加契約にする方が長続きします。

保守プランの作り方

説明しやすいのは、段階を分ける方法です。

この分け方にすると、クライアントは「高いか安いか」ではなく、「自社に必要な安心のレベルはどこか」で選びやすくなります。

見積書に入れる文言例

見積書や提案書には、短くても次のような文言を入れておくと説明しやすくなります。

月額保守には、既存機能の利用に関する問い合わせ対応、障害時の一次切り分け、軽微な設定変更、バックアップ・期限等の確認を含みます。
新機能追加、仕様変更、外部サービス仕様変更に伴う大規模改修、休日夜間対応、セキュリティ事故調査、データ移行は別途お見積りとなります。

もう少し柔らかく説明するなら、次のような形です。

保守費用は、納品後にシステムを安全に使い続けるための継続対応費です。
「壊れたときだけ直す費用」ではなく、日常の問い合わせ、軽微な調整、障害時の切り分け、期限やバックアップ確認を含めた運用のための費用として設定しています。

この文言は、契約書そのものではなく説明の土台です。
実際には、見積書、注文書、業務委託契約、保守契約書、個別契約、利用規約のどこで定義するかを決めて、矛盾が出ないようにします。

よくある誤解

納品後の不具合修正は全部無料？

契約不適合や納品直後の不具合対応と、継続的な保守は分けて考えます。
納品物が合意した仕様を満たしていない場合の対応と、運用後に発生する環境変化、外部サービス変更、追加要望への対応は同じではありません。

保守契約があれば何でもすぐ直る？

直るとは限りません。
原因調査、影響範囲、権限、外部サービス、バックアップ状態によって対応は変わります。復旧時間を約束するなら、それに見合う監視、冗長化、作業体制、費用が必要です。

月額保守に作業時間の上限は不要？

上限なしは危険です。
月額内の作業時間や問い合わせ件数を決めないと、軽微な依頼が積み上がり、通常開発や他案件に影響します。未使用時間を繰り越すかどうかも決めておくとよいです。

サーバー代や外部サービス代も保守費に含める？

含めてもよいですが、分けて見せた方が誤解は少ないです。
サーバー代、ドメイン、メール、決済、SaaS、AIツールなどは、誰が契約者で、誰が支払い、解約時にどう引き継ぐかを決めます。クライアント名義にした方が安全なものもあります。

まとめ

受託開発の保守費用は、「作った後もよろしくお願いします」という曖昧な月額ではなく、納品後のシステムを安全に使い続けるための継続対応費として説明すると伝わりやすくなります。

ポイントは、保守、運用、追加開発、改善提案を分けることです。
月額内に含める作業、別見積になる作業、対応時間、初動、月内作業量、外部サービスの責任分担を決めておけば、クライアントも判断しやすくなります。

保守費用は、安く見せることより、期待値を合わせることが大事です。
狭くても明確な範囲から始め、システムの重要度や停止時の影響に合わせて、標準保守、運用保守、個別SLAへ広げる方が、開発者側にもクライアント側にも健全です。

参考情報

• IPA: 情報システム・モデル取引・契約書（第二版）
• IPA: 「情報システム・モデル取引・契約書」からの見直しのポイント