システム保守とは？運用との違い・費用相場・契約形態を発注者視点で解説

システム保守とは、開発して稼働を始めたシステムを、障害の修正や環境変化への対応を通じて安定して使い続けられる状態に保つ仕事です。日々の稼働を見守るシステム運用と混同されがちですが、両者は担う役割が異なります。この記事では、システム保守と運用の違い、JIS X 0161が定める4つの保守タイプ、初期開発費に対する比率で見る費用相場と見積もりの根拠、準委任と請負の契約形態とSLAの決め方を、発注する側の視点で整理します。そのうえで、開発元・第三者保守・自社内製のどれに任せるかの判断軸と、外注で失敗しやすい典型パターンまで具体的に示すのがこの記事のねらいです。

まとめ：システム保守の全体像と、運用の違い・費用・委託先の判断軸

システム保守は、リリース後のシステムに手を入れて不具合を直し、法制度やOSの変化に追随させ、使い勝手を改善する作業の総称です。障害が起きていないかを監視し日々の稼働を維持するシステム運用とは役割が分かれ、運用が「動かし続ける」のに対し、保守は「直して変えて追随させる」ところを受け持ちます。ソフトウェアの保守はJIS X 0161で是正・予防・適応・完全化の4つに整理され、この分類で自社に必要な作業の範囲を切り分けられます。

費用は、初期開発費に対する年間の比率で見ると相場観をつかみやすくなります。一般には年5〜15%程度が目安とされ、24時間365日の対応やSLAで復旧時間を短く縛るほど上振れする傾向です。契約は準委任と請負のどちらを選ぶかで責任範囲が変わり、応答時間・復旧時間・保守範囲を契約前に取り決めておくと、リリース後の認識ずれを防げます。

委託先は、開発元・第三者保守サービス・自社内製の三択で考えると整理しやすくなるはずです。仕様に精通した開発元は初動が速い一方で費用は下げにくく、第三者保守は費用を抑えられても内部構造の把握に時間がかかります。自社の要件と体制を踏まえて保守まで含めた発注を検討したいときは、要件定義から保守設計までを見据えるWebシステム開発の相談窓口を起点にすると判断を進めやすくなります。

システム保守とは｜システム運用との違いと保守が担う役割の全体像

システム保守は、開発工程の後に続く「作った後」のフェーズです。まず保守が何を指すのかと、隣り合うシステム運用との線引きを押さえておくと、見積書に並ぶ「運用保守」という一括りの費用を分解して読めるようになります。

システム保守の定義と、システムを安定稼働させ続ける目的と範囲

システム保守の目的は、稼働中のシステムを想定どおりに使い続けられる状態に維持することです。具体的には、発生した障害の修正、セキュリティパッチの適用、法改正やOSのバージョンアップへの追随、利用者からの改善要望への対応が含まれます。開発が「新しく作る」行為なら、保守は「作ったものを直し、変化に合わせて手を入れる」行為だと考えると分かりやすくなります。システム開発そのものの全体像はシステム開発とは何かを工程から整理した解説が参考資料です。保守は、その開発が終わった地点から始まります。

保守と運用の違い｜変更を伴う修正と、日々の稼働を保つ運用の分担

保守と運用は、現場では「運用保守」とまとめて呼ばれますが、担当する作業は分かれています。運用は、サーバーの死活監視、バックアップの取得、ジョブの実行監視など、システムを止めずに動かし続ける定常業務です。運用の具体的な業務範囲や、内製で回すか委託するかの判断軸はシステム運用とは何かで詳しく整理しました。保守は、その運用中に見つかった不具合の修正や、環境変化に合わせたプログラムの改修など、システムに手を加える変更を伴う業務を指します。

両者の境目は「システムに変更を加えるかどうか」に置くと切り分けられます。ログを見て異常がないか確認するのは運用、異常の原因となったバグを直すのは保守です。この線引きを見積もり段階で共有しておくと、どちらの作業がどの費用に含まれるのかが明確になります。

システム保守の業務内容と、JIS規格に基づく4つの保守タイプ

保守と一言でいっても、その中身は性質の違う作業に分かれます。ソフトウェアの保守はJIS X 0161（国際規格ISO/IEC 14764に対応）で4つに分類されており、この枠組みで自社が必要とする保守の範囲を言語化できます。

是正・予防・適応・完全化｜JIS X 0161が定める保守の4分類

JIS X 0161は、ソフトウェア保守を目的別に4種類へ整理しています。是正保守は、顕在化した障害を取り除く修正です。予防保守は、まだ表面化していない潜在的な欠陥を、障害になる前に手当てします。適応保守は、OSの更新や法改正、業務環境の変化にシステムを合わせる改修を指します。OSやハードのサポート終了に伴ってシステムを別環境へ移す場合は、マイグレーションの種類・手法・費用を発注者視点で整理した解説もあわせて確認できます。完全化保守は、性能や保守のしやすさを高めるための改善です。

この4分類のうち、契約でまず対象になりやすいのは是正保守と適応保守です。予防保守と完全化保守はどこまで含めるかで費用が動くため、範囲を明示しておくと後の見積もり交渉がぶれません。

障害対応・パッチ適用・法改正対応まで含む具体的な作業項目の範囲

4分類を日々の作業に落とすと、保守の作業項目は次のように並びます。稼働中に発生した障害の切り分けと復旧、セキュリティパッチやミドルウェアの更新適用、インボイス制度や電子帳簿保存法のような法改正への対応、利用者からの改善要望を受けた小規模な機能改修です。

• 障害の一次切り分けと復旧、原因調査と再発防止
• OS・ミドルウェア・ライブラリのパッチ適用と検証
• 法改正・制度変更に合わせたプログラムの改修
• 利用者要望に基づく画面や帳票の小規模改修

これらの作業をどこまで一契約に含めるかは会社ごとに幅があります。「システム保守 作業項目」で具体を探す発注担当者が多いのは、契約書の「保守」という言葉だけでは何をしてもらえるのかが読み取れないからです。作業項目を一覧で突き合わせておくと、必要な範囲と不要な範囲を仕分けられます。

システム保守費用の相場と、開発費に対する比率で見る見積もりの根拠

保守費用は、金額の絶対値だけを見ても高いか安いか判断できません。初期の開発費に対する比率と、対応レベルという二つの軸で捉えると、提示された見積もりの妥当性を検討しやすくなります。

保守費用は初期開発費の年5〜15%が一般的とされる相場の目安

システム保守の費用は、初期開発費を基準にした年間比率で語られることが多く、一般には年5〜15%程度が目安とされます。1,000万円で開発したシステムなら、年50万〜150万円、月額にして数万〜十数万円が一つの目安です。この比率は要件によって上下する概算であり、断定できる固定値ではありません。対応の手厚さと、保守に含める作業範囲で変わります。

開発費と保守費は本来ひと続きのコストです。開発時に費用を切り詰めてテストや設計を省くと、リリース後の是正保守が増え、保守費が膨らむ逆転が起こります。開発と保守を通した総額で見る観点は、システム開発費用の相場と内訳を発注者視点でまとめた解説と合わせて押さえておくと、初期費用だけに引きずられずに判断できます。

対応時間帯・SLA水準・システム規模で保守費用が上下する要因

同じシステムでも、保守費用は三つの要因で大きく動きます。第一に対応時間帯で、平日日中のみと24時間365日では、待機する体制の人件費が変わるため費用が数倍になることもあります。第二にSLAの水準で、障害発生から復旧までの時間を短く縛るほど、常時待機の要員が必要になり、費用も上がる仕組みです。第三にシステムの規模と複雑さで、連携する外部システムやデータ量が多いほど保守の手間が増えます。

費用を抑えたいなら、まず対応時間帯を業務の実態に合わせて絞るのが現実的です。夜間に誰も使わない社内システムに24時間対応をつける必要はありません。守るべき稼働時間を業務から逆算し、それに見合うレベルを選ぶと、過剰な保守費を避けられます。

システム保守契約の主な形態と、契約前に取り決める範囲の確認点

保守の費用と品質は、契約の形態と、そこで何を約束するかで決まります。契約書に「保守」とだけ書かれていると、いざ障害が起きたときに対応の可否をめぐって認識がぶつかりがちです。形態の違いと、事前に文書化しておくべき項目を押さえておきます。

準委任と請負の契約形態の違いと、SLAで定める応答・復旧時間の水準

保守契約は、準委任契約と請負契約のどちらかを土台にすることが多く、責任の重さが異なります。準委任は、決められた工数や体制で保守作業を提供する契約で、受託側は善良な管理者としての注意義務を負いますが、特定の成果の完成までは保証しません。請負は、修正の完成という結果に責任を持ち、納品物に不具合があれば契約不適合責任を問えます。月々の保守は準委任、個別の大きな改修は請負と、作業の性質で使い分けるのが一般的です。

契約形態と合わせて、SLA（サービス品質保証）で応答時間と復旧時間の水準を数値化しておきます。「障害連絡から30分以内に一次応答、4時間以内に復旧着手」のように具体的な時間を約束事にすると、対応の速さを費用と釣り合った形で管理する仕組みです。請負と準委任の使い分けは、契約形態による費用の違いを整理した費用相場の解説でも触れています。

保守範囲・対応窓口・エスカレーション体制を契約前に確定する項目

契約前に文書で確定させておきたいのは、保守の対象範囲、連絡窓口、そして緊急時のエスカレーション経路です。保守範囲では、どのサーバー・どのアプリケーションまでを面倒見るのか、OSやミドルウェアの更新は含むのかを線引きします。対応窓口は、誰がいつ連絡を受け、どのくらいで折り返すのかを決めます。

1. 保守対象の範囲（サーバー・アプリ・連携先の線引き）
2. 連絡窓口と受付時間、一次応答までの時間
3. 重大障害時のエスカレーション経路と責任者

この三点があいまいなまま契約すると、深夜の障害時に「その対応は契約外」と押し問答になります。特にエスカレーション経路は、担当者が不在でも判断できる代替の連絡先まで決めておくと、初動が止まりません。

開発元・第三者保守・内製のどれを選ぶか｜保守委託先を決める判断軸

ここからは、保守を誰に任せるかの判断です。競合記事の多くは「外注のメリット」を並べて終わりますが、実務では開発元・第三者保守・自社内製の三択を、費用と初動の速さ、内部構造の把握しやすさで天秤にかける場面がほとんどです。条件を示して、どの場合にどれを選ぶかを言い切ります。

開発元・第三者保守・内製をそれぞれ選ぶ条件と切り替えの損益分岐

開発元への委託は、システムの内部仕様を最も理解している相手に任せられるため、障害時の原因特定が速く、改修の手戻りも少なくなります。稼働から間もない時期や、頻繁に機能追加が続くシステムでは、開発元の継続保守が総合的に有利です。一方で費用は下げにくく、乗り換え先がない状態が続くと価格交渉力を失います。

第三者保守サービスは、開発元より保守費を抑えられる場合が多く、複数システムをまとめて任せて窓口を一本化できます。仕様が安定して大きな改修が少なくなったシステムでは、第三者保守への切り替えが費用面で効いてくる場面です。ただし内部構造の把握に時間がかかるため、切り替え直後は障害対応が遅くなる期間を見込む必要があります。内製は、社内にエンジニアがいて、システムがビジネスの中核で改修判断を素早く回したい場合に向く選択肢です。人件費を固定で抱える点が損益分岐で、月々の外注費が常勤エンジニアの人件費を上回るなら内製化を検討する目安になります。

保守を安易に外注すべきでない場面と、委託で失敗する典型パターン

すべてを外注すればよいわけではありません。外注を避けるべきなのは、システムが競争優位の源泉で、改修のたびに外部と仕様調整をしていては事業のスピードが落ちる場合です。ECの独自ロジックや、自社サービスの根幹を担うシステムは、保守の一部でも社内に残したほうが機動力を保てます。

委託で失敗する典型は、保守範囲をあいまいにしたまま安さだけで発注先を決めるパターンです。範囲が不明確だと、障害のたびに「これは契約外」と追加費用を請求され、結果的に高くつきます。もう一つは、開発を任せた会社にドキュメントを残させず、担当者の頭の中だけに仕様がある状態で保守契約を切ってしまうパターンで、引き継ぎ先が構造を読めず保守が事実上止まります。発注の段階から保守を見据えて設計と文書化を求めておくのが、こうした行き詰まりを避ける近道です。Webシステム開発の相談では、開発だけでなく引き継ぎやすい保守体制まで含めて設計を組み立てられます。

よくある質問

システム保守の検討でよく挙がる疑問を、発注する側の視点でまとめます。

システム保守と運用の違いは何ですか？

運用はシステムを止めずに動かし続ける定常業務で、監視・バックアップ・ジョブ実行などが含まれます。保守は運用中に見つかった不具合の修正や、環境変化に合わせた改修など、システムに変更を加える業務です。「動かし続ける」のが運用、「直して変える」のが保守と切り分けると分かりやすくなります。現場では両方まとめて運用保守と呼ばれます。

システム保守費用の相場はどのくらいですか？

初期開発費に対して年5〜15%程度が一般的な目安とされます。1,000万円で開発したシステムなら年50万〜150万円が概算です。ただし対応時間帯が24時間365日か平日日中のみか、SLAで復旧時間をどこまで縛るかで数倍動くため、固定の相場としてではなく要件次第で上下する幅として捉えてください。

システム保守契約にはどんな形態がありますか？

月々の保守作業は準委任契約、個別の大きな改修は請負契約を土台にすることが多いです。準委任は作業の遂行に責任を持ち、請負は成果の完成に責任を持ちます。あわせてSLAで応答時間・復旧時間・保守範囲を数値化しておくと、費用と対応品質の釣り合いを管理できます。

開発した会社以外にシステム保守を頼めますか？

第三者保守サービスに切り替えれば、開発元以外にも委託できます。保守費を抑えやすく、複数システムの窓口を一本化できる利点があります。一方で内部構造の把握に時間がかかるため、切り替え直後は障害対応が遅くなる期間を見込んでください。ドキュメントが整っているほど、乗り換えはスムーズになります。

システム運用保守が「きつい」と言われるのはなぜですか？

夜間や休日の障害呼び出し、原因が特定しづらいトラブルの切り分け、属人化した古いシステムの引き継ぎなどが負担として挙げられます。裏を返せば、これらは社内の少人数で抱えると疲弊しやすい領域です。対応時間帯を業務に合わせて絞り、負荷の高い部分を外部の保守体制に委ねる判断が、内製と外注を分ける現実的な基準になります。監視や夜間対応を専業のMSPへ切り出す選択肢は、MSP（マネージドサービスプロバイダー）の役割と委託判断を整理した記事で詳しく解説しています。

関連記事

• システム開発とは？種類・工程・依頼方法までの全体像をわかりやすく解説：保守の前段にあたる開発工程の全体像を確認できます。
• システム開発の費用相場は？内訳・人月単価と見積もりの妥当性を発注者視点で解説：初期開発費と保守費を通した総額で費用を捉えるための解説です。