受託開発の保守費用をどう説明する？範囲・金額・契約の決め方

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

一方で、依頼する側から見ると「もう納品されたのに、なぜ毎月費用がかかるのか」と感じることがあります。
ここを曖昧にしたまま「月額いくらです」と出すと、あとでかなり揉めます。

この記事では、受託開発で保守費用を説明するときの考え方を、範囲、金額、契約、説明文の作り方に分けて整理します。
法的な最終判断は契約内容や業種によって変わるため、実際の契約書は弁護士や法務担当と確認してください。ここでは、制作会社、フリーランス、開発会社がクライアントへ説明するときの実務上の整理に寄せます。

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

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

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

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

保守と追加開発を分ける

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

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

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

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

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

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

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

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

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

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

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

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

金額をどう考えるか

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

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

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

金額説明の言い方

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

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

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

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

契約で決めるべき項目

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

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

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

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

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

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

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

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

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

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

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

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

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

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

保守プランの作り方

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

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

見積書に入れる文言例

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

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

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

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

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

よくある誤解

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

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

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

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

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

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

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

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

まとめ

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

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

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

参考情報

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