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

はじめに

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

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

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

先に、システム保守費用を判断するときの要点をまとめます。

• システム保守費用は、障害対応・セキュリティ更新・監視・軽微な改修など、契約に含める作業の範囲で決まります。
• 費用の目安は初期開発費に対する年額の割合で見られることが多いですが、対応時間やSLAの水準で大きく変わります。
• IPAのモデル取引・契約書は、保守の作業範囲や責任分担を契約前に整理する参考資料になります。
• 見積もりの比較では、対応時間・初動目標・月の作業上限・除外項目をそろえて確認します。
• 契約後も稼働実績の報告を受け、使われていない作業や不足している体制を定期的に見直します。

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

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

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

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

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

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

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

規格の資料名と適用範囲はISO公式の書誌情報で確認できます（確認日：2026-10-09）。

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

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

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

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

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

IPA公式の第二版公開ページでは、受託開発と保守運用を扱うモデル契約書と、パッケージ・SaaS/ASPの活用と保守・運用を扱う追補版が公開されています。どちらも2025年4月8日に更新されています。契約範囲や役割を整理する際は、自社の委託内容に合う資料を参照してください（確認日：2026-10-09）。

保守に含まれる作業内容

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

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

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

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

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

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

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

保守費用の種類と相場

一般的な目安として、ソフトウェア保守費用は初期開発費に対する年額の割合で見込む方法がよく使われます。ただし、これは見積もりの出発点にすぎません。24時間対応、決済、個人情報、外部API連携がある場合は、監視や待機の体制が必要になり、割合だけで見た金額より高くなることがあります。個別システムの保守料金は、同じ作業範囲と対応条件による見積もりで確認してください。

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

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

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

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

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

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

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

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

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

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

保守費用が妥当かを稼働実績で点検する方法

保守費用の妥当性は、契約書の作業範囲と月ごとの稼働実績を突き合わせて点検します。保守会社から、問い合わせ件数、受付から初動までの時間、作業時間、改修件数を報告してもらいましょう。請求総額だけでは、どの作業をどれだけ利用したかが分かりません。

作業時間は障害対応・更新・改修に分け、月の作業上限と比べます。対応時間帯と初動目標が守られているかも、受付・着手の記録で確認します。実績の少ない区分は契約範囲の縮小を検討し、超過が続く区分は依頼の優先度や担当体制を見直します。ただし、障害が少なくても監視や待機が役立っている場合があるため、件数だけで必要性を判断しないことが大切です。

保守の稼働実績を点検するための確認項目

確認項目	保守会社に報告してもらう内容	見直しにつながる判断の例
問い合わせ対応	月ごとの件数と初動までの時間	初動が契約目標を超えていれば体制や優先度を協議する
作業時間	作業区分(障害・更新・改修)ごとの時間	上限に対して実績が少ない区分は契約範囲の縮小を検討する
障害対応	障害の件数、重大度、再発の有無	同じ障害の再発が続く場合は予防保守や改修を優先する
改修依頼	依頼件数、完了件数、持ち越し件数	持ち越しが続く場合は月次でまとめる運用や上限の見直しを検討する
更新管理	OS・ライブラリ・外部APIの更新対応の実施状況	未対応の更新が残る場合はセキュリティ上の優先度を確認する

点検は契約更新前など定期的に行い、報告の形式を毎回そろえます。作業区分や集計期間が変わると比較しにくいため、同じ項目で前回との違いを確認し、次の契約に残す作業と見直す作業を保守会社と合意しましょう。

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

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

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

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

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

保守会社を切り替えるときの引き継ぎ準備

保守会社を切り替える場合は、新しい会社が調査・復旧・更新を行える資料と権限を先に整理します。ソースコードの管理場所、仕様書、作業手順書、アカウントと権限の一覧、障害履歴をまとめ、資料の所在と管理責任者を確認してください。パスワードなどの認証情報は、安全な受け渡し方法を別途決めます。

新旧の保守会社が並行して対応する期間を設け、問い合わせ窓口の切り替え日を決めます。その間に、連絡先、監視通知、復旧手順、更新の承認経路を新しい担当者が確認できる状態にします。社内で担う窓口、依頼の優先度判断、作業の承認と、外部に任せる調査・改修・監視などの作業を分け、書面に残しましょう。

ソースコードや資料を引き渡せるかは、開発元との契約で決まります。成果物の引き渡し条件、第三者への開示条件、利用・改修に必要な権利やライセンスを、自社の契約書と照合してください。引き渡しが可能と確認できる前に、第三者保守への移行を確約しないことが大切です。

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

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

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

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

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

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

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

ソフトウェア保守費用のよくある質問

保守契約を結ばず、必要なときだけスポットで依頼してもよいですか？

重要度が低く、障害が少ないシステムなら選択肢になります。ただし、継続契約などで即応を約束していなければ、依頼先に緊急対応を求められるとは限りません。受付可能な時間、調査の着手時期、緊急時の費用を事前に確認しましょう。停止が事業に大きく影響する場合は、固定の保守体制も比較する必要があります。

開発会社とは別の会社に保守を依頼できますか？

第三者保守として依頼できる場合があります。ソースコードや引き継ぎ資料を別の会社に渡せるか、開発元との契約を確認してください。権限やライセンスの制約がある場合は、その条件も新しい保守会社と共有し、対応できる範囲を確かめます。

保守費用の見積もりが妥当かどうかはどう判断すればよいですか？

複数社から、同じ作業範囲・対応時間の条件で見積もりを取ります。初動目標、月の作業上限、除外項目もそろえれば、金額差の理由を確認しやすくなります。契約後は稼働実績の報告と契約内容を突き合わせ、利用が少ない作業や体制が足りない作業を定期的に点検しましょう。

ノーコードで作ったシステムにも保守は必要ですか？

必要です。ツールの仕様変更への追従、権限やデータの管理、障害時の対応は、ノーコードでも担当者と範囲を決めておく必要があります。基盤側が管理する作業と、自社または保守会社が担うアプリの確認・修正を分けて契約しましょう。

まとめ

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

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

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

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

https://nocoderi.co.jp/2025/04/06/system-development-support/

https://nocoderi.co.jp/2025/12/28/internal-system-development-design-guide/

https://nocoderi.co.jp/2026/06/12/kintone-pricing/