システムの運用を外部ベンダーに委託していると、こんな経験はないでしょうか。「この対応は保守の範囲外になります。改修（エンハンス）扱いで別途費用をいただきます」——そう告げられたとき、「なぜ保守の範囲外なのか」「保守と改修、エンハンスはどう違うのか」を即座に判断できる担当者は多くありません。
「保守」「改修」「エンハンスメント（エンハンス）」は、いずれもシステムリリース後の対応を指す言葉ですが、目的・費用・契約形態が大きく異なります。この区分が曖昧なまま発注を続けると、「保守契約に含まれると思っていた作業が都度追加請求される」という状況が生まれ、コストの読みにくさにつながります。
この記事では、3つの概念の定義を整理した上で、比較表と判断フローを使って「自分の依頼はどれに該当するか」を自己判断できるようにお伝えします。保守・改修・エンハンスの違いを理解することで、ベンダーとの認識合わせや契約交渉もスムーズになります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
保守・改修・エンハンスとは—3つの概念を整理する
まず、それぞれの言葉の意味から確認しましょう。
システム保守とは（現状を維持・安定させる業務）
システム保守とは、稼働中のシステムが正常に動き続けるよう維持・管理する業務です。主な目的は「現状を維持すること」であり、具体的には次のような作業が含まれます。
- バグ・障害の修正（不具合が発生した際の原因調査と対応）
- セキュリティパッチの適用（脆弱性対策のためのアップデート）
- サーバーやミドルウェアのバージョンアップ（環境変化への適応）
- 定期的な死活監視・バックアップ
ポイントは、保守の対象は「すでに決まっている仕様の範囲内での維持」という点です。法改正への対応やOS終了対応など、外部環境の変化に合わせた調整も「適応保守」として保守の範囲に含まれることがありますが、これが改修・エンハンスと混在しやすい境界線になります。
システム改修とは（仕様変更・不具合修正への対応）
システム改修とは、現在稼働しているシステムに対して、仕様変更や機能の修正・調整を加える作業です。「壊れた部分を直す」というより、「現状の仕様と異なる状態に変更する」という意味合いが強くなります。
改修が発生する主なケースは次のとおりです。
- 業務プロセスの変更に伴う画面・ロジックの変更
- 法改正・制度変更に対応するための機能変更
- 当初の仕様では対応できない要件への対処
- UI・UXの見直し（操作性の改善）
保守との違いは「仕様が変わるかどうか」です。既存の仕様・ロジックを変えない範囲での対応は保守、変更を伴う場合は改修に分類されます。
エンハンスとは（機能追加・性能向上・拡張）
エンハンスメント（エンハンス）とは、既存のシステムに新しい機能を追加したり、パフォーマンスを向上させたりする開発作業です。「より良くする」「拡張する」ことが目的であり、改修とは異なる積極的な意図があります。
エンハンスの代表的な内容は次のとおりです。
- 新しい業務機能の追加（例：販売管理システムへの予算管理機能の追加）
- 外部サービス・APIとの連携追加（例：チャットツールとの通知連携）
- パフォーマンス改善・処理速度の向上
- セキュリティ強化（現状より高い水準に引き上げる）
エンハンスは「現状をベースに上乗せする開発」のため、新規システム開発よりコストを抑えられる一方、既存システムへの影響調査・テストが必要になります。詳しくはエンハンス開発とは？意味・メリット・新規開発との違いをわかりやすく解説をご覧ください。
保守・改修・エンハンスの違いを比較表で整理
3つの概念を5つの軸で比較します。自分の依頼がどの区分に該当するか確認する際の参照表としてご活用ください。
5軸の比較表
比較軸 | 保守 | 改修 | エンハンス |
|---|---|---|---|
主な目的 | 現状維持・安定稼働の継続 | 仕様変更・修正・調整 | 機能追加・拡張・性能向上 |
対象作業の例 | バグ修正、監視、パッチ適用 | 画面変更、ロジック修正、法改正対応 | 新機能開発、API連携追加、UI刷新 |
費用感 | 月額定額制が多い（開発費の5〜20%/年が目安） | スポット費用（規模により50〜800万円程度） | 開発費用に準じる（機能規模によって変動） |
契約形態 | 保守契約（定額・月額）が主流 | スポット契約または保守契約外の追加発注 | 個別の開発契約が一般的 |
依頼タイミング | 継続的・定常的（月次・随時） | 課題・問題の発生時 / 制度変更のタイミング | 事業上の必要が生じたとき |
「保守の範囲内」と「範囲外（改修・エンハンス）」の境界線
保守と改修・エンハンスの境界は、ひとことで言えば「仕様が変わるかどうか」です。
- 仕様書どおりに動いていない → 保守の範囲内（バグ修正）
- 仕様自体を変更する → 改修・エンハンスの範囲
ただし現実には、「これは仕様通りか、仕様変更か」の判断がベンダーによって異なるケースがあります。この曖昧さをなくすには、保守契約の締結時に「保守の範囲内とみなす作業の定義」を契約書に明記することが有効です。詳しくはシステム保守契約の種類と内容｜準委任・請負の選び方と記載すべき条項も参考にしてください。
保守契約の範囲外になりやすい典型的なケース
「保守だと思っていたのに追加費用が発生した」というトラブルが起きやすいケースを整理します。
法改正への対応は保守か改修か
法改正・制度変更による対応（消費税率の変更・電子帳簿保存法対応・マイナンバー関連など）は、「適応保守」として保守契約に含めているベンダーと、仕様変更が発生するため改修費用として別途請求するベンダーに分かれます。
判断の分かれ目は、対応のためにプログラムのロジックを変更するかどうかです。パラメータ変更や設定値の修正で済む場合は保守として扱われることが多いですが、税率計算ロジックや帳票フォーマットを書き換える必要がある場合は改修扱いになることがほとんどです。
画面デザインの変更はどちらか
「文言を変えたい」「ボタンの位置を調整したい」といった軽微な変更は、多くのケースで保守の範囲内として対応されます。ただし、レイアウトの大幅変更・フローの変更・入力項目の追加・削除が伴う場合は、仕様変更に該当するため改修・エンハンスの扱いになります。
新機能追加・外部サービス連携はどちらか
新しい機能の追加や、SlackやkintoneなどのSaaS・外部APIとの連携追加は、エンハンスに分類されます。既存の仕様書には存在しない機能を「上乗せ」するため、保守契約の対象外となるのが一般的です。
費用の目安は機能の規模次第ですが、外部API連携の追加であれば小規模で50〜200万円、業務機能の追加であれば300〜800万円程度が改修・エンハンスの費用相場として参考になります（システム改修費用の相場は？より参照）。
境界が曖昧な場合の対処法
「これは保守か改修か判断が難しい」と感じた場合の実践的な対処法を3点挙げます。
- 契約書で「保守対象作業の定義」を確認する: 保守契約書に「作業範囲の例示」が記載されていれば、それをベースに判断できます。記載がない場合は再交渉の余地があります
- ベンダーに「なぜ範囲外か」の説明を求める: 保守範囲外と判断した根拠（仕様変更が発生するか・工数がどの程度か）を確認します
- 次回の契約更新時に定義を明記する: 「保守の範囲内とみなす小規模改修の上限工数（例：月5時間以内）」を契約書に追記することで、毎回の判断を省力化できます
「保守・改修・エンハンスのどれを依頼するか」判断フロー
依頼内容を決める前に、以下のフローで区分を確認してください。
判断フロー（4ステップ）
ステップ1: 既存の動作に問題が発生しているか？
- はい → ステップ2へ
- いいえ → ステップ3へ
ステップ2: 仕様書どおりに動いていないか（バグ）？
- はい → 保守（バグ修正）
- いいえ（仕様どおりだが現状の仕様が問題） → 改修
ステップ3: 現在存在しない新しい機能・連携を追加したいか？
- はい → エンハンス
- いいえ → ステップ4へ
ステップ4: 既存の機能の動作や画面を変更したいか？
- はい（軽微な調整） → 保守または改修（変更の規模で判断）
- はい（仕様の変更を伴う） → 改修
- いいえ → 保守（定常的なメンテナンス）
判断フローの使い方と注意点
このフローはあくまで「最初の見当をつける」ための目安です。実際には、ベンダーとの契約内容・作業規模・技術的な複雑性によって判断が変わることがあります。
フローで「改修」または「エンハンス」と判断した場合は、発注前にベンダーへ「この作業の規模感と費用の目安」を確認することをおすすめします。判断が難しい場合やトラブルを避けたい場合は、保守と改修・エンハンスをまとめて相談できる開発会社にパートナーを変えることも一つの選択肢です。
保守・改修・エンハンスを一括で依頼できるTechBandとは
秋霜堂株式会社の TechBand は、「社内にシステム開発部門ができたような体制を提供する」サービスです。保守・改修・エンハンスを区分ごとに別のベンダーへ発注するのではなく、一つの窓口でシステムのライフサイクル全体を相談できる点が特長です。
「この作業が保守なのかエンハンスなのか、まず相談したい」という段階から対応しており、発注前の整理や優先順位の判断もサポートします。実際の開発実績については事例ブログもご参照ください。
まとめ
保守・改修・エンハンスの違いを整理すると、次のように整理できます。
- 保守: 現状維持が目的。仕様を変えない範囲での安定稼働維持（バグ修正・監視・パッチ適用）
- 改修: 仕様変更が目的。既存機能の変更・調整（画面変更・法改正対応・仕様修正）
- エンハンス: 機能追加・拡張が目的。現状にない新しい機能・連携の追加
「これは保守の範囲内か」と迷ったときは、「仕様が変わるかどうか」「新しい機能を追加するかどうか」の2点を確認するのが最初のステップです。
また、保守契約の範囲外になりやすいケース（法改正対応のロジック変更・外部API連携追加など）を事前に把握しておくことで、追加費用の発生を見越した予算計画が立てやすくなります。
保守・改修・エンハンスそれぞれの詳細については、以下の記事も参考にしてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
