MENU

問い合わせ


    システムの保守費用は何に払っている?月額保守費の内訳と見直す前に確認したいこと

    システムのリリース後、毎月請求される保守費用。金額は決まっているのに、請求書には「システム保守費 一式」としか書かれておらず、何にお金がかかっているのか分からない。システム保守費用の内訳が見えないという悩みは、開発会社に発注した多くの方が一度は感じるものです。

    「毎月の保守費用が高い気がするけど、何にお金がかかっているのか分からない…」

    先に結論をお伝えします。月額の保守費用には、目に見える作業だけでなく「何かあったときにすぐ動ける状態を保つ費用」が含まれています。高いか安いかを判断する前に、まずは「何が含まれていて、何が含まれていないか」を開発会社と一緒に一覧にすることが近道です。中身が分かれば、自社に合った内容に調整する相談もしやすくなります。

    この記事では、システムの月額保守費用に含まれやすい項目、内訳を確認する手順、見直しのときにやりがちな失敗を、チェックリストと開発会社への質問例つきで解説します。

    目次

    システムの保守費用が「見えにくい」3つの理由

    保守費用が分かりにくいのは、開発会社が隠しているからではありません。保守という仕事そのものに、見えにくくなる性質があるのです。

    理由1:保守は「何も起きない状態」を守る仕事だから

    保守がうまくいっている月ほど、発注者から見ると「何も起きていない」ように見えます。サーバーの監視やセキュリティの更新、バックアップの確認などは、トラブルを未然に防ぐための作業なので、成果が表に出にくいのです。

    理由2:「待機の費用」と「実作業の費用」が混ざっているから

    多くの月額保守契約には、実際の作業に加えて「問い合わせや障害にすぐ対応できる担当者・体制を確保しておく」費用が含まれています。火災保険や消防のように、使わなかった月にも備えのコストはかかります。この「待機」の部分が見えないため、「今月は何もしていないのに」と感じやすくなります。

    理由3:契約書や請求書の書き方がざっくりしているから

    「保守一式」「運用サポート」のように、項目がまとめて書かれている契約は珍しくありません。発注時は開発の中身に意識が向きがちで、保守の範囲まで細かく決めずに契約していることも多いのです。

    なお、システムを動かし続ける費用が大きくなるのは、個々の会社に限った話ではありません。

    📰 出典:JUAS(日本情報システム・ユーザー協会)「企業IT動向調査報告書 2026」

    JUASが東証上場企業とそれに準じる企業を対象に行った調査では、IT予算を「現行ビジネスの維持・運営」と「ビジネスの新しい施策展開」に分けたとき、2025年度の配分は75.9対24.1でした。IT予算の多くが、今あるシステムや業務を動かし続けることに使われているということです。規模の大きな企業が中心の調査ですが、「作った後にもお金がかかり続ける」のはシステムの一般的な性質だと言えます。

    月額保守費用に含まれやすい主な項目

    保守契約の中身は会社や契約によってさまざまですが、よく含まれる項目は次のとおりです。自社の契約にどれが入っているかを確認する「ものさし」として使ってください。

    項目主な内容発注者から見えにくい理由
    サーバー・インフラ費サーバーやクラウド(=インターネット経由で借りるサーバー)の利用料、ドメイン・SSL証明書の更新開発会社が一括で契約し、保守費に含めて請求していることがある
    監視・障害対応システムが止まっていないかの監視、止まったときの復旧作業障害がなければ作業の記録が残りにくい
    セキュリティ更新・バージョンアップOS・プログラミング言語・部品(ライブラリ)の更新と動作確認画面や機能が変わらないため、作業したことに気づきにくい
    不具合の調査・修正エラーの原因調査、修正、修正後の確認調査だけで時間がかかることもある
    問い合わせ対応操作方法の質問、「データがおかしい」などの相談への回答回答までの調査時間が見えない
    小さな改修・データ修正文言の変更、項目の追加、データの一括修正など「月◯時間まで」などの上限が決まっていることが多い
    定期作業・待機体制バックアップの確認、定期レポート、担当者の確保「備え」の費用なので形に残らない

    サーバー・インフラ費は「実費」に近い部分

    サーバーやクラウドの利用料、ドメイン(=Webサイトの住所)の更新費などは、外部のサービスに支払う実費に近い費用です。利用者やデータ量が増えると上がることもあります。請求書で保守作業の費用と分けて書かれているかどうかを確認しておくと、変動の理由が分かりやすくなります。

    セキュリティ更新は「削ってはいけない」部分

    システムは、OSやプログラミング言語、他社が作った部品など、多くのソフトウェアの組み合わせで動いています。これらには定期的に弱点(脆弱性=攻撃に悪用されうる欠陥)が見つかり、修正版が公開されます。

    📰 出典:IPA(情報処理推進機構)「日常における情報セキュリティ対策」

    IPAは、システム管理者向けの対策として、修正プログラムを適用して最新のバージョンに更新し、ルータなどのネットワーク機器も最新のファームウェアに保つよう呼びかけています。修正版を当てるだけでなく、当てた後にシステムが正しく動くかを確認する作業も必要になるため、ここには一定の手間がかかります。

    さらに、ソフトウェアにはサポート期間(=修正版が提供される期間)があります。

    📰 出典:PHP公式サイト「Supported Versions」

    たとえば、Webシステムでよく使われるプログラミング言語のPHPは、各バージョンについて、リリースから2年間はバグとセキュリティの修正、その後の2年間は重大なセキュリティ問題の修正のみを行い、合計4年でサポートを終えると公式サイトで定めています。サポートが終わる前に新しいバージョンへ移す作業が数年ごとに発生し、この作業が月額保守に含まれるのか、別の見積もりになるのかは契約によって異なります。

    不具合の修正は「誰の責任か」で扱いが変わる

    リリース後に見つかった不具合(バグ)でも、原因によって費用の扱いが変わることがあります。開発時の約束どおりに作られていなかったことが原因なら、開発契約の範囲で直してもらえる場合があります。

    📰 出典:e-Gov法令検索「民法」

    民法では、請負契約で引き渡されたものが契約の内容に合っていない場合(契約不適合)の責任について定めており、注文者は不適合を知った時から1年以内に請負人へ通知する必要があるとされています(第637条)。ただし、実際の扱いは契約書の定めによって変わるため、個別のケースは契約書を確認のうえ、必要に応じて弁護士などの専門家に相談してください。

    一方、OSの更新や外部サービスの仕様変更など、開発時には予測できなかった理由による不具合は、保守契約の中で対応するのが一般的です。

    保守費用の中身を確認する5つのステップ

    「高い気がする」を「中身が分かった」に変えるための進め方です。いきなり値下げを求めるのではなく、まずは現状を一緒に整理するところから始めましょう。

    ステップ1:契約書・見積書・請求書を手元にそろえる

    保守契約書(または覚書)、保守費用の見積書、直近の請求書を集めます。契約書に「保守の範囲」「対応時間」「対象外の作業」が書かれていれば、それが出発点になります。書かれていない場合も、そのこと自体が確認すべきポイントです。

    ステップ2:項目ごとに「含む/含まない/別料金」を一覧にする

    前の章の表を使い、自社の契約で各項目がどう扱われているかを開発会社に確認して一覧にします。特に次の3つは食い違いが起きやすいので、はっきりさせておきましょう。

    • 小さな改修は月額に含まれるか、含まれるなら上限は何時間か
    • バージョンアップ作業は月額内か、別見積もりか
    • 夜間・休日の障害対応は含まれるか

    ステップ3:毎月の作業報告をもらう

    多くの開発会社は、依頼すれば月次の作業報告を出してくれます。問い合わせ件数、対応した障害、適用した更新、改修の作業時間などが分かると、保守費用が何に使われているかが具体的に見えてきます。報告書の作成にも手間がかかるため、どの程度の詳しさにするかは相談して決めましょう。

    「待機や監視のように記録に残りにくい作業も、報告書の形にすると発注者の方に伝わりやすくなります。遠慮なく依頼してください」

    ステップ4:自社に必要な「対応レベル」を考える

    保守費用は、求める対応のレベルによって大きく変わります。たとえば、24時間365日すぐに復旧してほしいのか、平日の営業時間内に対応してもらえれば十分なのかで、必要な体制はまったく違います。こうした対応時間や復旧までの目安を取り決めたものをSLA(=サービスの水準についての合意)と呼びます。

    一般的に、外部のお客様が使うWebシステム(予約・EC・会員サイトなど)は止まったときの影響が大きく、手厚い対応が求められやすい傾向があります。一方、社内だけで使う業務システムは、利用時間が営業時間内に限られるなら、対応時間を絞れる場合もあります。「このシステムが半日止まったら、業務や売上にどのくらい影響があるか」を社内で話し合っておくと、判断の軸になります。

    ステップ5:「削る」ではなく「合わせる」で相談する

    中身が見えてきたら、自社の使い方に合っているかを開発会社と話し合います。たとえば「改修の依頼がほとんどないので、上限時間を減らして月額を下げられないか」「逆に改修が多いので、枠を増やしたほうが結果的に安くならないか」といった相談です。

    見直しは、減らすだけとは限りません。報告を見て「セキュリティ更新が後回しになっている」と分かれば、むしろ費用を増やすべき場合もあります。大切なのは金額の上下ではなく、払っている費用と必要な保守内容が一致していることです。

    保守費用の見直しでやりがちな失敗

    • 金額だけで他社の安い保守に乗り換える:保守の範囲が違えば、単純な比較はできません。また、別の会社がシステムを引き継ぐには、中身を理解するための調査が必要で、その費用や期間が見込まれていないことがあります
    • セキュリティ更新を真っ先に削る:目に見える変化がないため削りたくなりますが、放置すると情報漏えいやシステム停止の危険が高まります
    • 「保守に入っているから改修も無料」と思い込む:小さな改修が含まれていても、上限や対象の範囲が決まっていることがほとんどです。依頼前に範囲内かどうかを確認しましょう
    • 保守契約を解約して様子を見る:解約後にトラブルが起きても、すぐに対応してもらえるとは限りません。体制を組み直すまでに時間がかかり、結果的に高くつくこともあります
    • サーバーなどの契約者が誰か把握していない:開発会社名義でサーバーやドメインを契約している場合、解約や乗り換えの際に手続きが複雑になります。名義と管理方法は早めに確認しておきましょう

    発注者がやることチェックリスト

    • ☐ 保守契約書・見積書・直近の請求書を手元にそろえた
    • ☐ サーバー・監視・セキュリティ更新・不具合修正・問い合わせ・改修の各項目について「含む/含まない/別料金」を一覧にした
    • ☐ 小さな改修の上限(時間・回数)と、超えた場合の料金を確認した
    • ☐ バージョンアップやサポート期限切れへの対応が、月額内か別見積もりかを確認した
    • ☐ 障害時の対応時間(平日のみ/夜間休日も)と、連絡方法を確認した
    • ☐ 月次の作業報告をもらう仕組みを開発会社と決めた
    • ☐ 「システムが止まったら業務にどのくらい影響するか」を社内で話し合った
    • ☐ サーバー・ドメインなどの契約名義とアカウントの管理者を確認した

    開発会社への質問例

    保守費用の中身を確認する打ち合わせで、そのまま使える質問です。

    • 「今の月額保守費用に含まれている作業と、別料金になる作業を一覧で教えていただけますか?」
    • 「サーバーなどの実費と、保守作業の費用はそれぞれどのくらいの割合ですか?」
    • 「毎月、どんな作業にどのくらい時間を使っているか、簡単な報告をいただくことはできますか?」
    • 「使っているOSやプログラミング言語のサポート期限はいつ頃で、そのときの対応は保守に含まれますか?」
    • 「対応時間を平日の日中に絞った場合や、改修の枠を変えた場合、費用はどのように変わりますか?」

    質問の目的は値下げ交渉ではなく、お互いの認識をそろえることです。そう伝えたうえで聞くと、開発会社も率直に答えやすくなります。

    まとめ:保守費用は「中身を一覧にする」ことから見直す

    月額の保守費用が高く感じるのは、その多くが「トラブルを防ぐ作業」や「すぐ動ける体制の確保」といった、目に見えにくいものに使われているためです。判断する前に、次の3つを押さえましょう。

    • 保守費用には、サーバー費・監視・セキュリティ更新・不具合対応・問い合わせ・小さな改修・待機体制などが含まれうる
    • 自社の契約で「含む/含まない/別料金」を一覧にし、月次の作業報告で使われ方を確認する
    • 見直しは「削る」ではなく、自社に必要な対応レベルに「合わせる」視点で開発会社と相談する

    保守費用の中身が分かると、開発会社との会話も「高い・安い」から「何を優先するか」に変わります。まずは手元の契約書を開き、今の契約に何が含まれているかを確かめるところから始めてみてください。

    あわせて読みたい関連記事

    システム制作・運用・保守のお問い合わせはこちら


      よかったらシェアしてね!
      • URLをコピーしました!
      • URLをコピーしました!

      この記事を書いた人

      株式会社THIRD HERO代表取締役 朝野貴朗
      Webシステム開発を中心に、toC向けサービスサイトの運営、ツール開発などを行ってまいりました。

      コメント

      コメント一覧 (9件)

      コメントする

      目次