システムの保守契約とは？範囲・費用相場と見直すべきサイン

Webサービスやスマホアプリの保守契約は、月額料金だけでは判断できません。障害時にどこまで対応するのか、誰が権限を持つのか、追加費用はいつ発生するのかが曖昧だと、更新時や保守先の変更時に運用が止まるおそれがあります。

この記事では、保守契約の範囲、SLA、費用の比較方法、見直しのサイン、移管時の受入条件を整理します。月額ではなく、対応条件・年間総額・引継ぎ条件で保守契約を判断できるようになります。

保守契約は、対応範囲、年間総額、権限・資料を含む継続性を分けて確認すると比較しやすくなります。

01Section保守契約とは何か｜保守・運用・追加開発の境界を決める

保守契約とは、稼働中のシステムを安定して利用し続けるために、不具合対応、更新、監視、復旧などの作業と役割分担を定める取り決めです。契約に含める範囲は、サービスの利用時間帯、停止時の影響、外部連携の数、自社の運用体制によって変わります。

経済産業省の情報システム・モデル取引・契約書〈第一版〉（受託開発・保守運用）は、保守・運用の委託において、対象業務や役割分担を個別の契約・仕様で整理する際の確認先です。月額契約であっても、すべての依頼が無制限に含まれるわけではありません。

保守は「不具合修正」だけを指すものではない

保守には、不具合の調査・修正だけでなく、依存ソフトウェアの更新、障害後の再発防止、バックアップ状況の確認などが含まれることがあります。一方で、アカウント発行や定型登録などの日常作業は運用、新しい機能や連携の追加は追加開発として、別の費目・契約となることがあります。

クラウドを利用している場合も、アプリケーション、データ、アクセス権限、設定を誰が管理するかは確認が必要です。AWSの責任共有モデルでも、利用するサービスに応じてクラウド事業者と利用者の責任範囲が異なることが示されています。利用中のサービスでは、実際の契約名義と組織管理者権限をあわせて確認してください。

責任分界は作業・権限・承認を分けて確認する

「誰が対応するか」だけでなく、「誰が管理者権限を持つか」「誰が費用と本番反映を承認するか」を分けて記録することが重要です。特にクラウド、DNS、SSL/TLS証明書、アプリストア、外部SaaSは、作業担当と契約名義が一致しない場合があります。

02Section保守範囲とSLAはどう決めるか

保守範囲は「障害対応あり」「監視あり」といった作業名だけで比べると不十分です。本番・検証などの対象環境、受付時間、優先度、月間工数、超過時の単価や承認方法までそろえて、初めて契約内容を比較できます。

先に押さえたい用語

SLAで確認する受付・優先度・初動・報告

SLAは、サービス品質や障害時の対応水準を合意するための取り決めです。優先度別の初動時間や復旧時間に一律の正解はありません。売上・顧客対応への影響、営業時間、代替手段、自社で一次対応できるかを基に決めます。

IPAの製品利用者向けガイドでは、脆弱性対処を含む委託において、対応プロセスやSLAなどの合意を契約書・仕様書へ明記する考え方が示されています。これは具体的な時間値や料金を定める資料ではなく、合意内容を文書化する際の参考として使えます。

軽微改修は工数・対象機能・超過条件で決める

軽微改修を定額保守に含める場合は、「月間の工数枠」「対象となる機能」「未消化枠の扱い」「超過時の単価と承認者」を明記します。新機能、画面の大幅変更、外部連携の追加、要件定義を伴う変更は、通常の保守とは別に見積もるほうが境界を管理しやすくなります。

03Section保守費用は月額ではなく年間総額で比較する

保守費は月額だけでなく、追加改修や緊急対応、外部サービス、終了時支援を分けて年間総額で比較します。

保守費用は、定額の月額保守料だけでは把握できません。追加改修、夜間休日の緊急対応、クラウドやライセンスの利用料、終了時の引継ぎ支援までを分けて予算化する必要があります。

年間総額は、次の式で整理できます。

年間総額 ＝ 月額保守料 × 12 ＋ 追加改修費 ＋ 緊急・超過対応費 ＋ クラウド・ライセンス・外部サービス費 ＋ 移管・終了支援費

公開ベンチマークは背景情報にとどめる

JUASのソフトウェアメトリックス調査2020発表資料の図表H2-80「保守費用分析」および図表H3-1「開発費と保守費の関係」には、自己開発システムについて、初期開発費用に対する保守費用の年平均が7.8%と掲載されています。稼働後の追加開発費用は年平均12.0%として別に整理されています。

使い方としては、たとえば初期開発費用が1,000万円のシステムに年平均7.8%を当てはめると年間約78万円（月換算で約6.5万円）という試算になり、受け取った見積もりが桁として大きく外れていないかを確かめる背景情報として利用できます。あくまで過去集計に基づく概算であり、適正価格を示すものではありません。

対応時間、監視、オンコール、環境数、クラウド・ライセンス、追加改修、移管支援の含有条件は、個別契約ごとに異なります。Webサービス・スマホアプリに限定し、これらの条件まで統一した最新月額レンジは公開情報だけでは比較が難しいため、同一条件の見積もりと実績工数を優先してください。

同一条件で相見積もりを取る

料金体系の比較方法は、システム開発・保守の料金体系を比較するポイントも参考になります。相見積もりでは、各社へ以下の5区分を同じ記入欄で提示し、対象外・別途見積・実費の条件も確認します。

04Section保守契約を見直すべきサインと選択肢

まず運用継続に関わる権限・復元・連絡体制を確認し、その後に問題の原因に応じた選択肢を比較します。

見直しの出発点は「月額が高い」という印象ではなく、障害対応、資産管理、契約範囲、実績工数に問題があるかの確認です。個人データを扱う委託では、委託先の安全管理措置、再委託、取扱状況を確認する観点も必要です。詳細は個人情報保護委員会のガイドラインで確認してください。

すぐに是正を確認したいサイン

次の状態は、更新時の値下げ交渉より前に、責任分界と運用継続性を確認したいサインです。

• バックアップの対象、保存先、復元手順、直近の復元確認を説明できない
• クラウド、DNS、証明書、ソース管理、ストアの主要管理者権限を自社が把握していない
• 重大障害時の連絡先、判断者、エスカレーション経路が不明である
• 脆弱性対応の担当者、影響調査、更新判断の期限が決まっていない

更新時に再設計したいサイン

一方で、契約更新に合わせて条件を見直しやすいのは、実績と契約条件のずれです。

• 同種障害が再発し、原因分析や再発防止の実施状況が不明である
• 月額内工数が継続的に余る、または不足して追加請求が続く
• 範囲外請求が頻発し、不具合修正と仕様変更の境界が曖昧である
• 構成図、手順書、既知課題、権限一覧が不足し、説明が担当者に依存している

問題の原因から次の選択肢を決める

保守先への依存が強く、権限や資料を自社で管理できない場合は、単なる料金交渉ではなく依存リスクの整理が必要です。ベンダーロックインとは？発生するリスクと回避策を参照し、資産・権限・代替体制を分けて確認してください。

段階的刷新を比較する場合は、保守費だけで結論を出さず、将来の移行要件や運用リスクも含めて検討します。システムリプレースとは？進め方と失敗を防ぐポイントもあわせて確認すると、刷新の準備事項を整理しやすくなります。

05Section解約・移管で確認すべきこと｜受入完了をどう判定するか

移管は解約条項だけでなく、権限、環境再現、監視、復元、既知課題を新体制で扱えるかで受入条件を確認します。

保守先の変更可否は、解約条項だけでは決まりません。ソースコード、設計資料、クラウドやDNSの権限、監視、バックアップ、既知課題を新しい体制で扱えるかが重要です。

解約通知前に確認する契約・権利・権限

まず、契約期間、自動更新、通知期限、中途解約、終了後の支援、データ返却・削除、成果物の扱いを確認します。そのうえで、ソース管理、クラウド、DNS、SSL/TLS、監視、アプリストア、外部SaaSの契約名義と組織管理者を棚卸しします。

スマホアプリでは、アプリ本体に加えて、署名鍵、課金、認証、分析、通知などの周辺サービスも確認対象です。Appleのアプリ移管条件とGoogle Playのアプリ移管手順を、移管申請時点の公式情報として確認してください。ストアの条件やアカウント要件は変更される可能性があります。

切替前に受入完了とする条件

バックアップは、保存されているだけでは復旧可能性を示しません。AWS Backupを利用する場合は、AWS Backupの復元テストに関する公式説明を確認し、対象データ、権限、手順、試験記録を整理します。他の製品を利用している場合も、利用中サービスの仕様と運用手順で復元可能性を確認してください。

Go／条件付きGo／No-Goを判断する

Goと判断しやすいのは、契約上の引継ぎ条件、主要権限、コード、検証環境への反映、監視、復元、既知課題が確認済みの場合です。一部の資料や権限が不足していても、補完担当・期限・代替策が合意されていれば条件付きGoとして切替計画を検討できます。

発注者が主要権限を取得できない、コードを再現できない、復元できない状態ではNo-Goです。重大な未解決課題が不明な場合も、解約通知を急がず、資産整理、権限是正、再交渉、段階的刷新を優先します。移管の期間や費用は、通知期限、資料の状態、受入調査、並行運用の要否に左右されるため、一律の目安ではなく個別計画で確認します。

06Section保守契約書と付属文書で確認する項目

保守契約では、契約書本文だけを見ても判断できません。保守仕様書、SLA、運用設計書、見積書、個別発注書、変更依頼書の内容と優先関係を照合し、実際の運用と矛盾していないかを確認します。

システム開発・保守契約で確認すべきチェックポイントも参照し、文書間の矛盾を早めに見つけてください。モデル契約などの公開資料を参照する場合も、個別契約の結論を代替するものではなく、対象範囲や文書間の関係を確認するための資料として扱います。

品質・費用・情報管理・終了時の確認観点

法務・情報セキュリティ・購買へ相談する論点

法務には成果物・データの扱い、秘密保持、責任制限、終了条件などを確認します。情報セキュリティや個人情報保護の担当には、アクセス権限、再委託、個人データの取扱い、事故時の連絡を相談します。購買や経理には、超過精算、契約更新、解約通知、終了時支援の費用条件を確認します。

これらは契約上の有効性を一律に判断するためではなく、実務上の曖昧さを残さないための確認です。

07Sectionまとめ｜月額ではなく対応条件と継続性で保守契約を判断する

保守契約の判断は、料金だけでなく、障害対応と運用継続を確保できるかで行います。更新・見直し・移管の前に、次の順で確認してください。

1. 1管理者権限、バックアップ復元、重大障害の連絡経路、脆弱性対応の不明点を解消する。
2. 2対象範囲、対応時間、工数、超過条件、別費目をそろえ、年間総額で比較する。
3. 3問題の原因に応じて、継続、範囲・SLA変更、再見積もり、移管、段階的刷新を選ぶ。

保守契約は、契約更新時だけでなく、サービスの利用実態や体制が変わった時点で見直す価値があります。契約文書、費用明細、資産・権限、運用実績をそろえたうえで判断を進めると、価格と継続性の両面を比較しやすくなります。

保守契約の見直しや移管を進める際の相談先を探す

保守範囲、対応条件、年間総額、権限・資料の引継ぎ条件を整理したうえで、Webアプリ・SaaS開発の支援先を比較できます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発の支援先を探す