ソフトウェア保守とは？種類・作業内容・保守費用・契約のポイント

はじめに

ソフトウェア保守とは、リリース後のシステムを安全に使い続けるために、不具合修正、環境変化への対応、機能改善、予防的な点検を行う活動です。ソフトウエア保守と表記されることもありますが、検索している人の多くは「何をどこまで依頼すべきか」「保守費用はいくら見込むべきか」「運用やサポートと何が違うのか」を知りたいはずです。

新機能開発の予算は確保していても、バグ修正、セキュリティ対応、監視、クラウド費、問い合わせ対応、ドキュメント更新まで見込めていない会社は少なくありません。保守費用を削りすぎると障害対応が遅れ、ユーザー離脱や情報漏えいのリスクが高まります。一方で、必要以上に高い保守契約を結ぶと、使っていない監視ツールや過剰な待機体制に費用を払い続けることになります。

大切なのは、システムの重要度に合わせて、どこに固定費をかけ、どこを自動化し、どこを都度対応にするかを分けることです。この記事では、ソフトウェア保守の意味、種類、作業範囲、運用・サポートとの違い、費用相場、SLA、障害対応、更新管理、保守会社・契約形態の選び方を整理します。開発後の体制を見直したい方は、自社の契約範囲と照らし合わせながら確認してください。

ソフトウェア保守とは？意味と必要性

ソフトウェア保守は、完成したシステムを業務や技術環境に合わせて維持・改善する取り組みです。利用者増、OSやブラウザの更新、外部APIの仕様変更、セキュリティ脆弱性など、リリース後のシステムには必ず変化が起きます。

保守で守るものは、プログラムの正常動作だけではありません。業務継続、顧客データ、売上機会、社内担当者の引き継ぎやすさも対象です。ソフトウェアの保守費用は、今月の障害対応費ではなく、半年後・1年後も安全に変更できる状態を維持するための予算です。

ソフトウェア保守の種類と定義

ソフトウェア保守は、目的によって種類を分けると見積もりや契約範囲を整理しやすくなります。ISO/IEC/IEEE 14764:2022 は、ソフトウェア保守プロセスと保守種類の定義を扱う国際規格です。

種類	目的	具体例
是正保守	発生した不具合を直す	バグ修正、障害復旧、エラー原因調査
適応保守	外部環境の変化に合わせる	OS、ブラウザ、API、クラウド仕様変更への対応
完全化保守	利用価値を高める	画面改善、性能改善、軽微な機能追加
予防保守	将来の障害を防ぐ	依存ライブラリ更新、ログ点検、脆弱性対応

この4分類を使うと、曖昧な「保守一式」を避けやすくなります。

運用・サポート・保守の違い

保守費用を正しく見積もるには、運用・サポート・保守を分けて考える必要があります。混同したまま契約すると、障害時に「それは保守に含まれるのか」「追加費用なのか」で揉めやすくなります。

区分	主な役割	例
運用	正常時にシステムを動かし続ける	バックアップ確認、監視アラート確認、アカウント管理、定期処理
サポート	利用者や管理者を支援する	操作方法の問い合わせ、権限変更依頼、簡単な調査
保守	修正・改善・環境変化へ対応する	不具合修正、セキュリティパッチ、API変更対応、性能改善

IPA「情報システム・モデル取引・契約書（第二版）」 は、情報システム開発や保守運用の契約を整理する参考資料として公開されています。実務では一体で委託する場合もありますが、作業項目ごとに責任者、対応時間、費用区分を分けておくことが重要です。

利用者対応と技術的な保守の役割分担を具体化する例として、恋活アプリ 保守運用も参考にしてください。

保守に含まれる作業内容

保守に含まれる作業は、単なるバグ修正に限られません。主な内訳は、障害対応、セキュリティ更新、監視、クラウド運用、リポジトリ管理、軽微な改修、ドキュメント整備、定例報告です。

項目	内容	費用が増える要因
障害対応	エラー調査、復旧、原因分析	24時間対応、顧客影響が大きい
セキュリティ	脆弱性対応、依存ライブラリ更新	個人情報、決済、外部公開
監視	死活監視、ログ、APM、通知	サーバー数、トラフィック量
クラウド運用	AWS等の利用料、サポート契約	高可用性、複数環境
軽微な改修	UI調整、CSV変更、項目追加	仕様変更が多い
ドキュメント	手順書、仕様書、引き継ぎ	担当者交代が多い

社内用ツールと顧客向け本番サービスでは、必要な監視や対応速度が違います。対象システムの重要度を決め、必要な作業だけを契約に入れることが現実的です。

SLA・障害対応・更新管理の設計

SLAは、サービスレベル合意のことです。保守契約では、対応時間、初動返信、復旧目標、稼働率、報告方法などを決めるために使います。SLAは「頑張って早く対応します」という曖昧な約束を、発注者と保守会社が確認できる基準に変えるものです。

設計項目	決める内容	注意点
対応時間	平日営業時間、夜間休日、24時間365日	厳しくするほど待機費が上がります
初動目標	受付から一次回答までの時間	復旧完了時間と分けて決めます
復旧目標	暫定復旧、恒久対応、再発防止報告	障害レベルごとに分けます
優先度	重大障害、通常障害、軽微な不具合	売上・顧客影響で分類します
更新管理	パッチ適用、リリース手順、検証環境	本番反映前の確認手順が必要です

障害対応では、すべてを最優先にしないことが重要です。決済停止や顧客向け画面の停止は緊急対応にし、軽微な文言修正は月次対応にまとめます。更新管理では、OS、ミドルウェア、ライブラリ、外部API、ノーコード基盤の仕様変更を定期的に確認します。

保守費用の種類と相場

一般的な目安として、ソフトウェア保守費用は初期開発費の10〜20%を年額で見込むことが多いです。初期開発費が300万円なら、年30万〜60万円、月2.5万〜5万円が最低ラインの目安になります。ただし、24時間対応、決済、個人情報、外部API連携がある場合は、月10万〜50万円以上になることもあります。

料金体系は、月額固定、時間精算、チケット制、スポット対応に分かれます。小規模な業務システムでは、月額固定の基本保守に、改修作業だけ時間精算を組み合わせる方法が現実的です。

より詳しい費用内訳は、システム開発 保守費用 相場と内訳｜ノーコード開発で総コストを抑える方法でも解説しています。

公式料金で見る運用ツール費

保守契約を見積もる時は、人件費だけでなく、運用ツール費も確認します。リポジトリ、監視、エラー管理、クラウドサポートは、保守品質に直結する固定費です。

ツール	公式料金の要点	保守での役割
GitHub	GitHub Pricing でFree $0、Team $4/user/month、Enterprise $21/user/monthから（2026-09-01確認）	ソースコード、レビュー、CI/CD、権限管理
Sentry	Sentry Pricing でDeveloper $0、Team $26/mo、Business $80/mo（2026-09-01確認）	エラー監視、ログ、トレース、アラート
Datadog	Datadog Pricing でInfrastructure Pro $15/host/month、Enterprise $23/host/month、APM Pro $35/host/month（年払い、2026-09-01確認）	インフラ監視、APM、ログ、メトリクス
AWS Support	AWS Support Pricing でBusiness Support+は$29/month per accountまたはAWS利用額割合の大きい方、Enterprise Supportは$5k/monthから（2026-09-01確認）	クラウド障害時の技術支援

小規模なWebアプリなら、GitHub Team、Sentry Team、最低限のクラウド監視で十分な場合があります。高トラフィックのサービスでは、DatadogやAWS Supportの費用も見込みます。

保守費用を抑えるポイント

保守費用を抑える最も効果的な方法は、リリース前から保守しやすく作ることです。コードレビュー、テスト、自動デプロイ、ログ設計を整えておけば、障害調査の時間を短縮できます。

次に、優先度を明確にします。障害、セキュリティ、売上影響、法令対応を最優先にし、UI改善や便利機能は月次でまとめると、費用対効果を管理しやすくなります。

💡 ポイント: 保守費用を下げるには、重要な部分にだけ強い監視を置き、軽微な改修はまとめて判断することが重要です。

保守会社・契約形態の選び方

保守会社を選ぶときは、金額だけで比較しないことが重要です。開発元、第三者保守、自社内製、スポット依頼には、それぞれ向き不向きがあります。

選択肢	向いているケース	注意点
開発元に継続依頼	仕様理解が深く、リリース直後の不具合対応が多い	費用が固定化しやすい
第三者保守	開発元の対応が遅い、費用を見直したい	引き継ぎ資料とソース管理が必要
自社内製	社内に技術者がいて、頻繁に改善したい	採用・教育・属人化対策が必要
スポット依頼	重要度が低く、障害頻度が少ない	即応義務がなく、緊急時に高額化しやすい

契約形態は、継続的な調査・対応を依頼する準委任、特定の修正完了を依頼する請負、必要時だけ依頼するスポット対応に分けて考えます。

契約前には、保守対象、対応時間、初動目標、月の作業上限、機能追加の扱い、再委託、秘密保持、契約更新・解約条件を確認してください。保守範囲と除外項目を契約前に書面化することが、追加費用トラブルを防ぐ最短ルートです。

将来的な拡張を見越した保守体制

保守体制は、開発が終わってから急いで決めるものではありません。要件定義の段階で、変更頻度が高い画面、権限管理、外部サービス連携、障害時の判断者を決めておくと、保守費用を見積もりやすくなります。

開発前から保守運用までの流れを整理したい場合は、【完全ガイド】ソフトウェア開発の流れとは？要件定義から保守運用まで徹底解説！も参考になります。

社内業務アプリや申請管理、予約管理、顧客管理のような定型業務では、Bubbleやkintoneなどのノーコード基盤を使うことで、画面修正や項目追加を低コストで行いやすくなります。ただし、大量アクセスや特殊な外部API連携がある場合は、コード開発と組み合わせる判断が必要です。

保守費用を正しく評価してビジネスを加速

保守費用は、単に削るほど良いものではありません。削るべきなのは、使っていない監視、過剰な待機体制、曖昧な月額固定費です。残すべきなのは、セキュリティ更新、バックアップ確認、障害時の初動、仕様変更に耐える設計です。

ノーコード総合研究所では、既存システムの保守コスト見直しや、Bubble/kintoneを使った業務システム化に対応しています。システム全体を作り直す前に、保守負荷が高い部分を切り分けることが大切です。

まとめ

ソフトウェア保守は、リリース後のシステムを安定して使い続けるための修正・改善・予防活動です。保守には、是正保守、適応保守、完全化保守、予防保守があり、運用やサポートとは役割が異なります。契約前にこの違いを整理しておくと、作業範囲と費用の認識違いを減らせます。

保守費用は、バグ修正だけでなく、監視、セキュリティ、クラウド運用、リポジトリ管理、軽微な改修、ドキュメント整備まで含めて考えます。初期開発費の10〜20%を年額で見る方法は目安になりますが、システムの重要度、SLA、扱うデータ、外部公開の有無によって必要な金額は大きく変わります。

見積もり前には、対応時間、初動目標、月の改修上限、監視対象、クラウド費、問い合わせ窓口を確認してください。この6点が曖昧なまま契約すると、障害時に「どこまで保守に含まれるか」で揉めやすくなります。月額を下げたい場合でも、セキュリティ更新とバックアップ確認だけは削らない方が安全です。

既存システムの保守費が高い場合は、保守範囲を分解し、必要なSLAだけを残し、変更が多い業務画面をノーコード化する方法も検討できます。費用、安定性、将来の変更しやすさを同時に見ることで、保守を単なる固定費ではなく事業継続の仕組みに変えられます。ノーコード総合研究所では、現実的な保守体制づくりを支援します。