開発会社から「保守・運用 月額〇〇万円」と書かれた契約書や見積もりを受け取って、サインしてよいものか手が止まっていませんか。金額は書かれているものの、その中に何が含まれていて、障害対応や機能追加が別料金なのかが読み取れない——そんな状態で契約判断を任されている方は少なくありません。
「保守」と「運用」という言葉の違いを調べても、たいていは「保守は問題対応、運用は日々の維持」といった定義の説明で終わってしまいます。しかし発注担当者が本当に知りたいのは、言葉の意味そのものではなく「その金額に何が含まれ、何が追加費用になるのか」という費用と責任の線引きのはずです。
特にやっかいなのが、契約書に「保守・運用」とまとめて書かれているケースです。この一括表記こそが、稼働後の「それは保守の範囲外です」という追加請求トラブルの入口になります。何が定額内で何が別料金かが曖昧なまま契約してしまうと、想定外のコストが後から積み上がっていきます。
本記事では、保守と運用の違いを発注者目線で簡潔に整理したうえで、見積もりの金額を読み解くための費用体系の4類型、追加費用が発生しやすいグレーゾーン作業、契約書で注意すべき曖昧表記、そして発注前にベンダーへ確認すべき6つの項目を解説します。読み終えたとき、自社の契約のどこを見て、何を確認すれば「想定外の追加請求」を契約前に防げるのかが分かるようになります。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
保守と運用の違いとは｜「保守・運用」をまとめて契約する前に
まず押さえておきたいのは、保守と運用は本来別の作業を指すという点です。ここでは定義を網羅的に並べるのではなく、費用と責任の線引きにつながる範囲で簡潔に整理します。保守と運用それぞれの業務内容を業務一覧レベルで詳しく知りたい場合は別の解説記事に譲り、本記事は「契約・費用の判断」に的を絞ります。
運用とは（稼働を維持する日常業務）
運用とは、システムが日々問題なく動き続けるように維持する定常的な業務を指します。具体的には、サーバーやネットワークの稼働監視、定期的なバックアップ、ログの確認、ユーザーアカウントの登録・削除、ディスク容量やリソースの管理などが含まれます。
運用業務の特徴は、作業内容と発生頻度がある程度決まっていて予測しやすいことです。「毎日この監視をする」「月次でこの処理をする」と作業量が見通せるため、後ほど解説する費用体系のなかでも月額固定の定額に乗りやすい性質を持っています。
保守とは（不具合修正・改善・将来への備え）
保守とは、システムに発生した不具合の修正や、変化する環境への対応、将来に向けた改善といった「何かが起きたとき・変えるとき」の業務を指します。プログラムのバグ修正、障害発生時の復旧対応、OSやミドルウェアのアップデートへの追従、軽微な機能の改修などが該当します。
保守業務の特徴は、いつ・どれだけ発生するかが事前に読みにくいことです。障害は予告なく起きますし、機能改修の規模もその都度変わります。この「予測しにくさ」が、保守の一部が定額に収まりきらず別料金になりやすい根本的な理由になります。
なぜ「保守・運用」の一括表記が費用トラブルの入口になるのか
ここまでで分かるとおり、運用は予測しやすく定額向き、保守は予測しにくく一部が別料金になりやすいという、性質の異なる作業です。にもかかわらず契約書では「保守・運用」とひとまとめにされ、「月額〇〇万円」とだけ書かれていることが珍しくありません。
このとき問題になるのが、定額の金額に「どこまでの保守が含まれているのか」が明示されていないケースです。たとえば「軽微な改修は含むが、画面追加などの機能追加は別見積もり」「障害対応は含むが、原因が利用者側にある場合は有償」といった境界が契約書に書かれていないと、稼働後に「それは保守範囲外です」と追加請求される余地が生まれます。
つまり、保守と運用の区分を理解することは、言葉の暗記ではなく「定額に含まれる作業」と「別料金になる作業」の境界を見極めることに直結します。次の章からは、この境界を読み解くための具体的な視点を順に見ていきます。
保守と運用の費用体系の違い｜定額・従量・障害対応単価を見分ける
見積もりや契約書に並ぶ金額は、すべて同じ性質のものではありません。「どの費用体系で課金されるのか」という型を知っておくと、見積もりの各行が何を意味しているのかを読み解けるようになります。ここでは代表的な4つの費用体系を整理します。
4つの費用体系（月額固定／従量・実費／障害対応単価／スポット改修）
保守運用の費用は、おおむね次の4つの体系に分けて考えると整理しやすくなります。
- 月額固定（定額）: 毎月決まった金額で、あらかじめ定義された範囲の作業を行う体系です。日常的な監視・バックアップなどの運用業務や、一定範囲の保守が含まれます。発注者にとっては予算が読みやすい一方、「定額に何が含まれるか」が曖昧だとトラブルになります。
- 従量・実費: 実際に発生した作業量に応じて課金される体系です。作業時間（人月・人日）や利用したインフラの実費などが該当します。使った分だけ支払うため公平ですが、見積もり段階では総額が読みにくくなります。
- 障害対応単価: 障害が発生した際の対応に対して、時間帯や緊急度に応じた単価で課金される体系です。特に深夜・休日や緊急対応は割増単価が設定されることが多く、定額に含まれているのか別料金なのかを必ず確認すべき項目です。
- スポット改修費: 機能追加や画面追加など、その都度見積もりを取って実施する改修の費用です。「保守の範囲を超えた変更」はこの体系で扱われることが多く、月額には含まれないのが一般的です。
実際の見積もりでは、これらが組み合わさっています。たとえば「月額固定の運用保守費＋障害の緊急対応は時間外単価＋機能追加は都度スポット見積もり」といった構成です。各項目がどの体系なのかを意識して読むと、金額の意味が立体的に見えてきます。
運用が定額に乗りやすく、保守の一部が別料金になりやすい理由
なぜこのような体系の違いが生まれるのかは、先ほどの「予測しやすさ」で説明できます。運用業務は作業量が見通せるため、ベンダーも定額に組み込みやすく、月額固定で提供されるのが一般的です。
一方、保守業務のうち障害対応や機能改修は、発生のタイミングも規模も読みにくいため、すべてを定額に含めるとベンダー側がリスクを抱えることになります。その結果、「軽微な範囲までは定額に含むが、それを超える分は従量・スポット」という線引きが設けられます。この線引きの位置こそが、後ほど解説するグレーゾーンの正体です。
保守費用の目安（初期費用の数%〜20%）と相場の確認方法
費用体系とは別に、保守運用費の総額の目安も知っておくと見積もりの妥当性を判断しやすくなります。一般的に、年間の保守費用は初期開発費の15〜20%が目安とされています（システム幹事「システム開発の保守費用相場」）。たとえば1,000万円で開発したシステムなら、年間150万〜200万円程度が一つの目安になります。
ただし、この比率はあくまで概算であり、システムの複雑さ・障害対応の手厚さ・SLAの水準によって上下します。相場の詳細な内訳や規模別・業界別の目安、妥当性のチェック方法については、システム保守費用の相場と算出方法【妥当性の判断基準】で詳しく解説しています。本記事ではこの先、相場そのものではなく「その金額の内訳で、何が定額内で何が別料金か」という区分の見極めに焦点を当てます。
追加費用が発生しやすいグレーゾーン作業リスト
ここからが本記事の核心です。「定額に含まれていると思っていたら、別料金だった」というトラブルは、特定の作業に集中して発生します。これらをあらかじめカタログとして知っておけば、自社の契約に当てはめて「この作業はどちらに転ぶか」を契約前に確認できます。
バージョンアップ・環境変化への追従はどちらの範囲か
OS・ミドルウェア・ライブラリのバージョンアップ対応は、グレーゾーンの代表格です。セキュリティ更新のために必要な作業ですが、「動いているシステムを新しい環境に合わせて修正する」ため作業量が読みにくく、定額に含むベンダーと別見積もりにするベンダーが分かれます。
同様に、外部サービスのAPI仕様変更や、決済・認証など連携先の変更への追従も、外部要因による作業として別料金になりやすい項目です。契約では「定期的なセキュリティパッチ適用は含むが、メジャーバージョンアップは別見積もり」のように、どこまでが定額かを明記してもらうことが重要です。
軽微な改修・機能追加の線引き（保守か別見積もりか）
「ちょっとした文言修正」「ボタンの追加」といった軽微な改修は、最も認識のズレが起きやすい領域です。発注者側は「軽微だから保守に含まれるはず」と考えがちですが、ベンダー側は「仕様変更＝改修＝別料金」と捉えていることがあります。
この線引きを曖昧にしたままだと、依頼のたびに「これは有償です」と言われ、想定外の費用が積み上がります。対策としては、「月◯時間までの軽微改修は定額に含む」といった工数枠を設定するか、改修の判断基準（既存機能の修正は含む／新規機能の追加は別）を契約で定義しておくことが有効です。
障害の原因切り分けとデータ復旧の費用負担
障害が起きたとき、その原因がベンダー起因（プログラムのバグ等）なのか、利用者起因（誤操作・想定外の使い方）なのか、あるいは外部環境起因なのかによって、費用負担が変わるのが一般的です。
ここで問題になるのが「原因が不明な障害」です。原因を切り分ける調査自体に工数がかかり、調査の結果ベンダー起因でなかった場合に「調査費用は誰が負担するのか」が契約に書かれていないと揉めます。また、誤操作によるデータ破損からの復旧（リカバリ）も、バックアップの取得は運用に含まれていても、復旧作業そのものは別料金とされることがあります。「原因不明時の調査費用の扱い」「データ復旧作業の費用負担」は、契約前に必ず確認したいポイントです。
対応時間帯・SLAによって変わる費用（時間外・緊急対応）
同じ障害対応でも、平日日中の対応と深夜・休日の緊急対応では費用が大きく変わります。月額に含まれる障害対応が「平日9〜18時のみ」で、それ以外は時間外単価という契約は珍しくありません。
ここで関わってくるのが、サービス品質を取り決めるSLA（Service Level Agreement）です。たとえば稼働率を月99%と定めた場合、30日換算で月あたり約7.2時間の停止までが許容範囲という計算になります（NTTドコモビジネス「SLA・SLOの正しい理解」）。応答時間（連絡からの一次返答までの時間）や復旧目標時間をどう設定するかによって、必要な対応体制とコストが変わります。手厚いSLAは安心ですが、その分コストも上がるため、自社のシステムにとって必要十分な水準を見極めることが大切です。
契約書でありがちな曖昧表記とチェックポイント
グレーゾーン作業を知ったら、次はそれが契約書のどの記載に現れるのかを押さえます。発注者目線で「この書き方は危ない」というポイントを翻訳して解説します。法律家向けの専門的な条項解説ではなく、見積もり判断にそのまま使える粒度で見ていきます。
「一式」「保守・運用」の包括表記に潜むリスク
契約書や見積書で「保守・運用一式 月額〇〇万円」とだけ書かれている場合は要注意です。「一式」という言葉は便利な反面、何が含まれて何が含まれないのかを意図的・結果的に曖昧にします。
この表記のままサインすると、稼働後に追加対応を依頼するたびに「それは一式の範囲外です」と言われる余地を残します。対策は、「一式」の中身を作業項目レベルで一覧化してもらうことです。後述する責任分担表（作業項目ごとに定額／別料金を整理した表）を添付してもらえば、包括表記のリスクを大きく減らせます。
作業範囲（スコープ）と有償条件が明記されているか
良い契約書には、対象となる作業の範囲（スコープ）と、有償となる条件が明記されています。たとえば「無償対応は瑕疵（納品物の不具合）に起因するものに限り、利用者起因の障害対応・仕様変更は有償とする」といった記載です。
逆に、有償・無償の境界がどこにも書かれていない契約書は、トラブルの温床です。「どういう場合に追加費用が発生するのか」が一文でも明記されているかを確認し、書かれていなければ追記を依頼しましょう。境界が文書化されているだけで、稼働後の認識のズレは大幅に減ります。
SLA（対応時間・応答時間・稼働率）の確認
SLAに関する記載があるか、ある場合はその水準が自社の業務に合っているかを確認します。チェックすべき主な項目は、稼働率（どのくらいの停止まで許容されるか）、応答時間（連絡してから一次対応までの時間）、復旧目標時間（障害発生から復旧までの目標）、そして対応時間帯（平日日中のみか、24時間365日か）です（NECフィールディング「SLAとは？」）。
注意したいのは、SLAが手厚いほど良いわけではないという点です。24時間365日の即時対応を求めれば当然コストは上がります。自社のシステムが止まったときの業務影響の大きさに照らして、過剰でも不足でもない水準を選ぶことが、適正な費用につながります。
発注前に確認すべき6つの条件｜ベンダー質問チェックリスト
ここまでの内容を、契約・見積もり段階でベンダーに確認すべき6つの項目に集約します。次の打ち合わせにそのまま持ち込めるよう、各項目に「確認の聞き方」の例を添えました。これを使えば、グレーゾーンを契約前に一つずつ潰していけます。
含まれる作業・除外作業を一覧で出してもらう
最初に確認すべきは、月額に含まれる作業と、含まれない（別料金になる）作業の一覧です。
- 確認項目1: 月額に含まれる作業の範囲
- 聞き方の例:「月額費用に含まれる作業を一覧でいただけますか。あわせて、含まれない作業（別料金になる作業）も明示してください」
- 確認項目2: 軽微改修の工数枠の有無
- 聞き方の例:「軽微な改修は月◯時間まで定額に含む、といった枠はありますか。枠を超えた場合の単価も教えてください」
障害対応・改修・バージョンアップの費用負担を確認する
次に、グレーゾーンになりやすい3つの作業について、費用負担を確認します。
- 確認項目3: 障害対応の範囲・時間帯・原因不明時の費用負担
- 聞き方の例:「障害対応は何時から何時まで含まれますか。原因が不明・利用者起因だった場合、調査や対応の費用はどうなりますか」
- 確認項目4: バージョンアップ・環境変化対応の扱い
- 聞き方の例:「OSやミドルウェアのバージョンアップ、外部APIの仕様変更への対応は、定額に含まれますか。それとも別見積もりですか」
SLAと契約終了時の引き継ぎを確認する
最後に、サービス水準と、契約を終える際の条件を確認します。
- 確認項目5: SLA（応答／復旧時間・稼働率・ペナルティ）
- 聞き方の例:「稼働率・応答時間・復旧目標時間はどの水準ですか。基準を満たせなかった場合の取り決め（ペナルティ）はありますか」
- 確認項目6: 契約終了時の引き継ぎ・データ返却
- 聞き方の例:「契約を終了する場合、ソースコードや設計書、データの引き継ぎはどう行われますか。引き継ぎに別途費用はかかりますか」
この6項目を確認するだけで、稼働後に「想定外だった」と言われる主要なポイントはほぼ押さえられます。逆に、これらに明確に答えられないベンダーは、契約後の運用でも認識のズレが起きやすいと考えられます。
保守・運用範囲を契約書に明記する進め方
確認した内容は、口頭の合意で終わらせず契約書・SLA・作業範囲記述書（SOW）に落とし込んでこそ意味を持ちます。最後に、発注者から依頼すべき具体的なアクションを整理します。
作業項目×定額/別料金の対応表を契約に添付する
最も効果的なのが、作業項目ごとに「定額に含む／別料金」を整理した責任分担表を作成し、契約書に添付してもらうことです。横軸に「定額／従量／スポット」、縦軸に「監視・バックアップ・障害対応・軽微改修・機能追加・バージョンアップ」などの作業項目を置いた表をイメージしてください。
この一枚があれば、稼働後に作業を依頼するたびに「これはどちらか」を表で確認できます。包括表記の曖昧さを構造的に解消する、最もシンプルで効果の高い手段です。
有償条件・SLAを数値で明記してもらう
「有償となるのはどういう場合か」という条件は、できるだけ具体的に文書化してもらいます。「利用者起因の障害対応は有償」「機能追加は都度見積もり」といった条件を一文ずつ明記するだけで、後の認識のズレが大きく減ります。
SLAについても、稼働率・応答時間・復旧目標時間・対応時間帯を数値で明記してもらいましょう。「迅速に対応します」といった定性的な表現ではなく、「一次応答は連絡から◯時間以内」のように測定可能な形にしておくことが、いざというときの拠り所になります。
同条件で複数見積もりを比較する
複数のベンダーから見積もりを取る場合は、同じ条件・同じ作業範囲で出してもらうことが鉄則です。一方が「障害対応込み」、もう一方が「障害対応別」のまま総額だけを比べても、正しい比較にはなりません。
ここまでに整理した責任分担表や確認6項目を共通の前提として各社に渡し、同じ土俵で見積もってもらえば、金額の差が「対応範囲の差」なのか「単価の差」なのかが見えてきます。これが、見積もりの妥当性を自分で判断できる状態への近道です。
まとめ｜区分の理解が「想定外の追加請求」を防ぐ
保守と運用の違いは、単なる言葉の定義の問題ではありません。発注者にとって本当に重要なのは、「定額に含まれる作業」と「別料金になる作業」という費用と責任の線引きを見極めることです。本記事の要点を振り返ります。
- 運用は予測しやすく定額に乗りやすい一方、保守の一部（障害対応・機能改修・バージョンアップ）は予測しにくく別料金になりやすい。
- 見積もりは「月額固定／従量・実費／障害対応単価／スポット改修」の4つの費用体系で読み解ける。
- 追加費用が発生しやすいグレーゾーン作業（バージョンアップ・軽微改修・原因不明の障害・時間外対応）を知り、契約前に扱いを確認する。
- 契約書の「一式」「保守・運用」といった包括表記は、作業項目ごとの責任分担表で具体化してもらう。
- 発注前にベンダーへ確認すべき6項目（含む作業／障害対応／改修／バージョンアップ／SLA／引き継ぎ）をチェックリストとして打ち合わせに持ち込む。
これらを実践すれば、稼働後に「それは範囲外です」と追加請求されるリスクを、契約前に大きく減らせます。グレーゾーンは、契約段階で文書化して予防するのが最も確実です。
なお、保守費用そのものの相場や妥当性の判断軸についてさらに詳しく知りたい場合は、システム保守費用の相場と算出方法【妥当性の判断基準】をあわせてご覧ください。本記事で整理した「区分と体系の見極め」と、相場の知識を組み合わせれば、自社の保守・運用契約を自信を持って判断できるようになります。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
