2026.10.05

システム保守運用の費用はどう決まる？月額の内訳と見積もりの見方

システムは完成した時点で費用の支払いが終わるわけではありません。サーバーやクラウドの利用料、障害が起きたときの対応、OSやライブラリの更新、小さな改修など、使い続ける限り毎月の費用が発生します。

保守運用の見積もりを受け取ったときに「月額いくらが妥当なのか分からない」と感じる発注担当者は多いはずです。保守運用費は、開発費のように画面数や機能数から積み上げにくく、会社によって含まれる作業の範囲も大きく異なるため、金額だけを並べても比較できないからです。

保守運用費の相場として「年間で開発費の一定割合」という目安が語られることがありますが、その割合は会社や案件によって幅があり、根拠も示されないことがほとんどです。発注側にとって大切なのは、割合で判断することではなく、月額費用がどの作業の対価なのかを内訳で確認することです。

この記事では、保守と運用の違い、月額費用の内訳、金額が決まる要素、契約の外で発生しやすい費用、見積もりの見方を、発注側の立場から解説します。

保守と運用は何が違うか

「保守運用」とひとまとめに呼ばれることが多いものの、保守と運用は性質の違う作業です。見積もりを読むときは、まずこの二つを分けて考えると内訳が理解しやすくなります。

区分	主な作業	費用の性質
運用	稼働監視、バックアップの確認、アカウント管理、定期的なデータ処理、問い合わせ対応	システムが動いている限り毎月ほぼ一定量発生する
保守	障害の調査と復旧、不具合の修正、OSやライブラリの更新、セキュリティ対応	発生量が月によって変わる。予防的な作業と事後対応がある
改修・機能追加	画面や帳票の変更、新しい機能の追加、業務変更への対応	保守契約の範囲外として別見積もりになることが多い

発注側と開発会社の認識がずれやすいのは、保守と改修の境目です。発注側は「ちょっとした修正」も保守に含まれると考えがちですが、開発会社は仕様どおりに動いているものを変える作業を改修として扱うことが一般的です。どこまでを月額に含めるのかは、契約書や見積書に作業の例を挙げて書いておく必要があります。

また、運用のうち、ユーザーからの問い合わせ受付やアカウント発行などの作業を社内で行うのか、開発会社に任せるのかによっても月額は変わります。情報システム部門がない会社では、運用の大半を開発会社に任せることになりがちですが、その分の工数は月額に反映されます。社内でできる作業と任せる作業を分けて考えることが、費用を適正にする第一歩です。

保守契約は作業に対して払う契約が多い

保守運用の契約は、一定期間の作業に対して報酬を支払う準委任の形を取ることが一般的です。開発のように「完成したもの」に対して支払うのではなく、監視や問い合わせ対応といった作業の遂行に対して支払うため、作業がどれだけ行われたかを発注側が確認できる仕組みが重要になります。一方、改修や機能追加は、内容を決めて個別に見積もり、完成に対して支払う請負の形で発注することもあります。月額の保守契約と個別の改修契約を分けておくと、どこまでが月額の対価なのかがはっきりします。

社内で担える運用作業を切り出せるかどうかも、月額を左右します。たとえば、利用者のアカウント発行やパスワード再設定、マスタデータの更新などは、管理画面を整えれば社内の担当者でも対応できます。こうした作業を開発会社に依頼し続けると、その分の工数が毎月発生します。開発の段階で「社内で行う運用作業」を洗い出し、そのための画面や手順書を用意しておくと、保守の月額を抑えやすくなります。

月額費用の内訳

保守運用の月額費用は、大きく分けると、インフラなどの実費と、人が作業する工数の二つで構成されます。見積書がこの二つを分けて書いているかどうかで、比較のしやすさが大きく変わります。

費目	内容	金額の決まり方
インフラ費用	サーバー、クラウド、データベース、ストレージ、通信量	利用量に応じた従量課金や月額固定。構成とアクセス量で変わる
ライセンス・外部サービス費用	有償のミドルウェア、メール送信、地図、決済、監視などの外部サービス	各サービスの料金体系に従う。利用者数や件数で変わるものが多い
ドメイン・証明書	ドメインの更新、SSL/TLS証明書	年額のものが多い。無償の証明書を自動更新する構成もある
監視・定常運用の工数	稼働監視、バックアップ確認、定期作業、月次報告	作業内容と頻度から見積もる固定的な工数
保守対応の工数	問い合わせ対応、障害の調査、軽微な不具合修正、更新作業	月あたりの対応時間の枠や、待機体制の費用として見積もる

インフラ費用は実費に近いため、開発会社が手数料を上乗せしているかどうか、クラウドの契約者が発注側と開発会社のどちらなのかも確認しておきます。クラウドの契約を開発会社名義で行うと、請求はまとまって楽になる一方で、将来ほかの会社に保守を移すときに環境の移管作業が必要になります。発注側名義で契約し、開発会社には作業用の権限を付与する形にしておくと、費用の透明性と移管のしやすさの両方を確保できます。

工数の部分は、「月に何時間まで対応するか」という時間枠で契約する方法と、「障害時に何時間以内に対応を始めるか」という体制で契約する方法があります。時間枠の契約は使った分が見えやすく、体制の契約は待機している人の費用が含まれるため、作業がなかった月でも費用が発生します。どちらが適切かは、システムが止まったときの業務への影響で決まります。

月額費用はどう決まるか

同じ規模のシステムでも、保守運用の月額は条件によって大きく変わります。金額を左右する主な要素は次のとおりです。

対応時間帯と初動の速さ

平日の日中だけ対応すればよいのか、夜間や休日にも対応が必要なのかで、必要な人員と待機の費用が変わります。障害発生から何時間以内に対応を始めるか、何時間以内に復旧を目指すかといった目標を厳しくするほど、費用は上がります。社内の業務時間内に使う管理システムと、顧客が24時間利用する予約サイトでは、必要な体制がまったく異なります。

システムの構成と古さ

使用しているOS、言語、フレームワークには、それぞれサポート期限があります。たとえばPHPは、各バージョンがリリースから2年間のバグ修正と、その後2年間のセキュリティ修正のみの期間を経てサポートを終える方針を公式に示しています。サポートが終わった環境を使い続けると、脆弱性が見つかっても修正が提供されないため、保守側で個別に対策するか、更新作業を行う必要が出てきます。古い構成のシステムほど、保守の工数は増える傾向にあります。

開発時の品質と資料の有無

設計書やテストコードが残っているシステムは、不具合の調査や修正にかかる時間が短くなります。反対に、資料がなく、作った本人しか構造を知らないシステムは、調査に時間がかかり、保守を引き受ける会社が見積もりに不確実性の分を上乗せすることがあります。

変更の頻度

業務の変更に合わせて頻繁に修正が入るシステムは、毎月一定の開発工数を確保しておくほうが効率的です。この場合は保守契約とは別に、月あたりの開発工数を確保する準委任型の契約を組み合わせる方法もあります。

月額を比較するときは、これらの条件を揃えたうえで比べることが前提です。対応時間帯や初動の目標が違う見積もりは、金額だけを比べても意味がありません。

もう一つ確認しておきたいのが、月あたりの時間枠を使い切らなかった場合と、超えた場合の扱いです。余った時間を翌月に繰り越せるのか、超えた分はどの単価で精算するのかによって、実際の年間費用は変わります。対応の量が月によって大きくぶれるシステムでは、繰り越しや四半期単位での精算ができる契約のほうが無駄が出にくくなります。

参考：Supported Versions／PHP

契約の外で発生しやすい費用

保守運用でトラブルになりやすいのは、月額に含まれていると思っていた作業が、実は別料金だったというケースです。次の費用は、契約の外で発生しやすいため、事前に扱いを決めておきます。

OS、言語、フレームワークのメジャーバージョン更新
外部サービスの仕様変更や提供終了への対応
法改正や制度変更に伴う計算ロジックや帳票の変更
データの一括修正や、過去データの抽出依頼
利用者の増加に伴うサーバー構成の見直し
セキュリティ診断と、その結果に基づく修正

このうち、バージョン更新と外部サービスの変更は、発注側の都合と関係なく発生するため、予算に組み込んでおく必要があります。数年に一度、まとまった更新作業が必要になると考えておくと、突然の出費に慌てずに済みます。

証明書の更新も、運用の手間が変わりつつある項目です。ブラウザやOSの事業者と認証局でつくる業界団体CA/Browser Forumは、2025年に公開サーバー証明書の最大有効期間を段階的に短縮することを決め、2026年3月から短縮が始まり、2029年3月には最大47日になる予定です。手作業で証明書を更新している構成では作業回数が増えるため、自動更新の仕組みに切り替える作業が必要になる場合があります。自社のシステムがどちらの構成なのか、保守担当の会社に確認しておくとよいでしょう。

法改正への対応も、保守の範囲に含むかどうかで揉めやすい項目です。軽微な税率変更などは保守の範囲で対応する会社もあれば、すべて改修として扱う会社もあります。消費税や給与計算など、制度に依存する処理を含むシステムでは、契約時に扱いを確認しておきます。

参考：Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods／CA/Browser Forum

保守見積もりの見方と比較の手順

保守運用の見積もりを受け取ったら、次の順で確認すると、金額の妥当性を判断しやすくなります。

インフラなどの実費と、作業の工数が分かれているかを確認する
工数の部分について、含まれる作業の一覧と、月あたりの対応時間の上限を確認する
対応時間帯、障害時の初動目標、連絡手段を確認する
月額に含まれない作業と、その場合の単価や見積もり方法を確認する
月次報告の有無と内容を確認する
契約期間、更新、解約時の引き継ぎ方法を確認する

見積書が「保守運用一式、月額◯円」とだけ書かれている場合は、この順で質問して内訳を出してもらいます。内訳を出せない会社は、作業の範囲を自社でも整理できていない可能性があり、後から範囲外の請求が発生するリスクが高くなります。

判断の目安を、システムの条件ごとにまとめると次のようになります。

システムの条件	向いている契約の形
社内向けで、止まっても数日なら業務を回せる	平日日中対応、月あたりの時間枠を小さめに設定した契約
顧客が利用し、停止が売上や信用に直結する	監視と夜間休日の初動を含む体制型の契約
業務変更に合わせて毎月のように修正が入る	保守契約に加え、開発工数を月単位で確保する準委任契約
ほとんど変更がなく、安定して動いている	監視と障害対応を中心にした最小限の契約と、年1回程度の更新作業の別見積もり

月次報告の内容も重要です。対応した作業と時間、発生した障害と原因、次に必要になりそうな更新作業が報告されていれば、月額が実態に見合っているかを発注側が判断できます。報告がなく、何も起きていない月にも同じ金額を払い続ける状態は、発注側にとって判断材料がない状態です。

解約時の引き継ぎ方法も、契約時に決めておくべき項目です。ソースコード、設計書、サーバーの管理者権限、各種アカウントの情報を、どの形式で引き渡すのかを決めておけば、将来保守先を見直すときの負担を減らせます。

まとめ

保守運用の月額費用は、インフラなどの実費と、人が作業する工数の二つで構成されます。工数の部分は、対応時間帯、障害時の初動目標、システムの古さ、資料の有無、変更の頻度によって大きく変わるため、開発費に対する割合だけで妥当性を判断することはできません。

見積もりを受け取ったら、実費と工数が分かれているか、月額に含まれる作業と含まれない作業がどこで区切られているかを確認してください。そのうえで、自社のシステムが止まったときに業務にどれだけ影響するかを基準に、必要な対応体制を決めます。

すでに保守契約を結んでいる場合は、現在の契約書と直近数か月の対応実績を並べ、払っている金額に対してどの作業が行われているかを確認するところから始めると、見直しの材料が揃います。料金や業界ルールは変わることがあるため、契約更新のたびに内訳を確認し直すことをおすすめします。