システム保守費用の相場と妥当性｜「開発費の15〜20%」を鵜呑みにしない検証手順

システム保守費用の相場を調べているとき、多くの場合すでに手元には具体的な紙があります。ベンダーから届いた「システム保守費　一式　月額◯◯万円」という見積書か、何年も同じ金額で届き続けている毎月の請求書です。知りたいのは統計値ではなく、この金額を払い続けてよいのかという一点のはずです。

ところが検索して出てくるのは「開発費の15〜20%」という比率ばかりで、手元の見積書には開発費が書かれていません。書かれていたとしても、その率を掛けた金額と実際の請求額が違ったとき、どちらが間違っているのか判断できません。

本記事は、相場の数字を1つ提示する記事ではありません。すでに受け取っている保守見積書・請求書を、自分の手で検証するための手順をまとめたものです。発注前に予算枠を作る段階の話はシステム開発の予算の組み方で扱っているため、本記事は稼働後の検証に絞ります。

TL;DR｜保守費用の妥当性は「率」ではなく4つの状態で判断する

• 「開発費の15〜20%」は業界慣習値であり、IPAなどが公表している公式相場ではありません。 本記事で確認した限り、根拠として名指しされることの多いIPAの2資料には、この比率にあたる記述が見当たりませんでした（検証の詳細）
• 同じ検索結果の中でも、主張されている年間保守費率は5%から50%まで割れています。しかも比率の分母が「開発費」「初期開発費」「導入費用」「システム構築費」とバラバラです
• 率で判断できない理由は明快で、保守費は開発費の関数ではないからです。実際に費用を生むのは待機体制・人の作業・システムの作業・実費・引き継ぎ困難性という5つの要因で、そのどれも開発費に比例しません
• したがって判断は「高い／安い」の二択ではなく、説明済み／要確認／高リスク／判断不能の4状態で行います
• 「安すぎる」保守見積もりのほうが危険なケースもあります。復旧テスト・セキュリティ更新・引き継ぎ資料の維持が抜けていると、費用は下がっても事故時の損失が跳ね上がります
• 検証の結果、現行ベンダーの継続が合理的という結論も普通にあり得ます。本記事はベンダーを叩くための道具ではありません

この4状態が測っているのはベンダーの善悪ではなく、発注側が根拠を確認できているかどうかです。「高リスク」は「ぼったくり」という意味ではありません。ベンダーが誠実でも、説明されていなければ社内で予算を守れません。

「相場」を調べても答えが出ない3つの理由

理由1｜同じ検索結果の中で、主張されている率が5%から50%まで割れている

2026年8月18日、Google（日本・日本語・デスクトップ）で「システム 保守費用 相場」を検索し、上位2ページに表示された一般検索結果19件すべてについてページのHTMLを取得し、本文から年間保守費率にあたる記述を抜き出しました。内訳は次のとおりです。

• 開発費・導入費用を分母とする年間保守費率を本文に記載していたページ：15件。うち1件はQ&Aサイトの2009年の投稿で、回答者が個人の見聞として5〜25%を挙げたものだったため除外し、残る解説記事14件を下表に採録しました
• 分母が開発費以外だったページ：2件（クラウド利用料に対する比率、サーバー構築費用に対する比率）
• 比率の記述がなかったページ：2件

検索結果のタイトルではなく、必ずページ本文の記述を採録しています。社名は伏せ、記述内容のみを掲載します。なお除外した1件の5〜25%も、下表に現れる5〜50%の範囲に収まっており、除外の有無で結論は変わりません。

出典: 2026年8月18日にkoromo編集部が実施したSERP調査（一般検索結果19ページを取得し、開発費・導入費用を分母とする年間率を記載していた15ページのうち、解説記事14ページを採録）。検索結果の並びは地域・端末・時期で変わるため、同じ結果が再現されるとは限りません

下限は5%、上限は50%です。 10倍の開きがあります。1つのページの中で、本文冒頭と別節の数字が違っている例（#10）や、保守の種類ごとに4つの異なる率を挙げている例（#7）もありました。

この状態で「相場は◯%です」と受け取ると何が起きるか。開発費1,000万円のシステムなら、年間保守費の「相場」は50万円から500万円まであることになります。手元の見積書がその中のどこにあっても「相場の範囲内」と言えてしまいます。これは判断材料として機能していません。

理由2｜分母である「開発費」に何を含めるかが決まっていない

前の表の右列に注目してください。分母として書かれている語が「開発費」「システム開発費」「初期開発費」「導入費用」「システム構築費用」「システム導入費」と揃っていません。これは表記ゆれではなく、実際に含める範囲が違います。

手元の請求書を検証しようとすると、この差がそのまま効いてきます。

同じシステムでも、分母を狭義の開発費に取るか導入費用総額に取るかで、分母が2倍近く変わることは珍しくありません。分母が2倍変われば、同じ月額でも「15%」にも「8%」にもなります。

さらに厄介なのは、稼働から数年たっているシステムでは当時の開発費の内訳がもう社内に残っていないことです。総額だけが残っていて、その総額にハードウェアやライセンスが含まれていたかどうか分からない、という状態がよくあります。この場合、率での検証は原理的に不可能です。

理由3｜同じ数字の出所とされる公的資料に、その数値が見当たらない

「開発費の15〜20%」には、しばしばIPA（独立行政法人情報処理推進機構）が根拠として挙げられます。同じ検索結果の中には、1ページの中で本文が「情報システムの信頼性向上に関するガイドライン」を、FAQが「ソフトウェア開発データ白書」を、それぞれ根拠として挙げている例もありました。

そこで、名指しされている2つの資料を実際にダウンロードして本文検索しました（2026年8月18日実施）。

前者について補足すると、この資料が収集しているのは工数（人時）・工期・規模・生産性・信頼性であって、金額そのものではありません。「保守」という語自体は51回出てきますが、用法は次の3種類で、いずれも費用や比率を表すものではありません。

• 開発プロジェクトの種別としての「b：改修・保守」（42回。うち2回はPDFの段組で「b：改修・」と「保守」が別行に分かれています）
• 非機能要求としての「保守性」（6回）
• プロジェクトに含まれる作業分類としての「保守」（3回。プロジェクトに保守作業が含まれるかを数えたもので、金額ではありません）

つまり保守費率を出すためのデータが、そもそもこの資料には収録されていません。金額に関する項目は「外部委託の金額比率」など比率に限られ、費用の実額は収集対象外です。

後者は信頼性評価指標と自己診断ツールの活用方法を説明した資料で、費用の水準や比率に関する記述がありません。なお、ガイドライン本体を策定したのは経済産業省（2009年3月24日第2版）で、IPAが2012年6月に公表したのはその活用方法・解説にあたる文書です。

ここで慎重に書いておきます。これはIPAの全公表物を網羅的に確認した結果ではありません。 確認したのは「根拠として名指しされていた2資料」だけです。したがって言えるのは次のことに限られます。

「開発費の15〜20%」は、実務で長く使われてきた業界慣習値である。少なくとも、その根拠としてよく挙げられる上記2つのIPA資料には、対応する記述が見当たらない。公式相場として扱うべき数値ではない。

慣習値が無価値だと言いたいのではありません。使いどころが違うだけです。次の章で、その正しい使いどころを整理します。

それでも率が使われる理由と、率が効く場面・効かない場面

率が有効なのは「まだ見積書がないとき」

率が本当に役に立つのは、システムを作る前、保守費の存在自体を予算に計上し忘れないための枠取りです。開発費1,000万円の稟議を上げるときに「翌年度以降、年120万〜200万円の保守費が継続して発生する」と添えられれば、5年間の総保有コストが1,600万〜2,000万円だと経営層に示せます。この用途では幅があっても問題になりません。むしろ幅を潰して単一の数字にするほうが危険です。

この段階の予算の作り方はシステム開発の予算の組み方で解説しています。ただし同記事は枠取りの目安として**年12〜15%**を使っており、本記事の見出しに挙げた15〜20%とは幅が違います。これは誤記ではありません。慣習値は資料によって12%から20%まで動くという、まさにその事実こそが、率を検証に使えない理由です。枠取りの段階では、どちらか一方を選ぶのではなく幅のまま持っておくのが安全です。

一方、すでに見積書や請求書が手元にある段階では、率はほぼ使えません。理由は単純で、率は「いくらになりそうか」を推定する道具であって、「この金額の根拠は何か」を検証する道具ではないからです。目の前に実額があるのに推定値を当てても、一致しても不一致でも、次の行動が決まりません。

プロが作った「％建て料金」は、単一の％になっていない

比率で保守・サポート費を決めること自体が悪いわけではありません。むしろ、公開されている料金表を見ると、％建ては実際によく使われています。ただしその作りが、一般に語られる「一律15〜20%」とはまったく違います。

分かりやすい実例として、AWSサポートの公開料金を見てみます。

出典: AWS公式サイト「AWSサポート料金」2026年8月18日取得。USD建て、料金改定日の表記なし。同ページは「長期契約は必要ありません」「料金は毎月請求」としたうえで、**最低契約期間を30日（Unified Operationsのみ90日）**と定めています。なお同ページに税に関する記載はありません（日本国内での税の取り扱いは別途確認が必要です）

注意: ここでの分母は「月額AWS使用料」であって「開発費」ではありません。金額水準を保守費の相場として読み替えることはできません。参考にすべきは**％建て料金の構造**です。

構造上のポイントは3つあります。

1. 下限額がある。 使用量がゼロに近くても、体制を維持するための最低額は発生します
2. 率が逓減する。 規模が大きくなるほど％は下がります。AWS公式の計算例では、月額使用料20,000 USDのときビジネスサポート+は1,600 USD（実効8.0%）、月額使用料750,000 USDのときエンタープライズサポートは52,000 USD（実効約6.9%）です（いずれも公式の計算例に基づき、実効率はkoromo編集部が算出）
3. 24時間365日の踏み込んだ対応は、別料金として切り出されている。 AWS Incident Detection and Responseは、エンタープライズサポート契約者に対して**最低7,000 USDまたは対象アカウントの月額AWS使用料合計の2%**という別建ての料金が設定されています

この3つは、そのまま自社の保守見積書を見るときのチェック観点になります。下限額の考え方が示されているか。規模が増えたときに率が下がる設計になっているか。24時間365日対応が基本料金に溶け込んでいないか。 一律の％だけが書かれた見積書は、この3点のどれにも答えていません。

保守費用を実際に生む5つのコストドライバー

保守費が開発費に比例しない理由を、費用が発生する側から見ていきます。保守費を動かす要因は次の5つで、このどれも開発費の大きさで決まりません。

この5つは同じ格ではありません。①〜④は見積書の行として金額に現れる費目区分ですが、⑤引き継ぎ困難性は独立した行にならず、①〜④すべての単価を押し上げる形で効きます。したがって見積書を分解するときに使うのは①〜④の4区分で、⑤は「なぜその単価なのか」を説明する背景として扱います。

①待機｜何も起きなくても発生する、体制を空けておく対価

障害が起きたときに30分で人が動ける状態を維持するには、その時間帯に対応できる人を確保しておく必要があります。障害がゼロの月でもこの費用は発生します。「今月は何もしていないのに同じ金額なのはおかしい」という感覚は自然ですが、待機の対価という費目が契約に明示されていれば、それは説明のつく費用です。

待機費用を決めるのは、対応時間帯・応答目標・担当できる人数であって、システムの開発費ではありません。平日9時〜18時と24時間365日では、必要な人員が数倍変わります。

②人の作業｜障害対応・問い合わせ対応・軽微な改修

実際に人が手を動かす部分です。ここは工数に比例します。ただし比例するのは問い合わせ件数・障害件数・改修依頼件数であって、開発費ではありません。開発費が小さくても、利用部門が多く問い合わせが多いシステムなら、この費目は大きくなります。

会計検査院が2006年に公表した検査結果では、この人の作業にあたる部分の単価がどれほどばらつくかが示されています（詳細は後述）。

③システムの作業｜監視・バックアップ・パッチ適用

自動化されている部分です。ここはサーバー台数・監視項目数・バックアップ容量に比例し、人の作業とは増え方がまったく違います。台数が2倍になっても、自動監視の費用は必ずしも2倍にはなりません。逆に、監視でアラートが鳴ったときに人が確認する部分は台数に応じて増えます。

自動監視と有人対応が同じ「監視費」の行に混ざっている見積書は、この2つの増え方の違いを隠してしまいます。

④実費｜クラウド利用料・ライセンス・回線

ベンダーの役務ではなく、ベンダーが立て替えて払っている外部への支払いです。役務費と実費は性質がまったく違います。 実費は使った分だけ変動し、原則としてベンダーの利益が乗るべき部分ではありません（請求代行手数料が別途明示されている場合を除きます）。

役務と実費が同じ月額に溶けていると、クラウド利用料が下がったときに保守費が下がらない、という状態が起きます。

⑤引き継ぎ困難性｜他社に頼めない状態そのものが価格に効く

設計書がない、環境構築手順が属人化している、本番環境の管理権限をベンダーしか持っていない。この状態だと、そもそも他社が見積もりを出せません。競争がない価格は、競争がある価格と同じにはなりません。

これは倫理の話ではなく市場構造の話です。次章の政府調達データは、この構造が価格に与える影響を数字で示しています。

課金単位と実コスト要因のズレを見る

「比例するのがおかしい」と決めつけないでください。台数が増えれば実際に一次対応の手間は増えます。ユーザーが増えればライセンス実費は実際に増えます。 問題は比例そのものではなく、何に比例しているかが書かれていないことです。

保守見積書では、これがどう書かれているか

実際の保守見積書で頻出する書かれ方と、そこから読み取れないことを整理します。

「一式」で書かれた行が1つでもあると、その行については4状態のうち「判断不能」から動かせません。 判断不能は、高いとも安いとも言えない状態です。値下げ交渉の材料にもならず、社内で予算を守る根拠にもなりません。

この表の使い方は単純です。右列が「判断不能」になった行について、中列の「読み取れないこと」をそのままベンダーへの質問文に変換します。たとえば「運用保守サポート費」の行なら、聞くべきは金額の妥当性ではなく「この費目に含まれるのは待機ですか作業ですか、実費は含まれますか」です。金額の話をする前に、何を買っているのかを確定させるという順番になります。

右列が「②（上限が不明）」のように区分まで割り振れている行は、判断不能より一段進んでいます。この場合は区分そのものではなく、括弧内に書いた不足情報だけを聞けば足ります。

行項目を1つずつ読み解く手順はシステム保守見積書の見方にまとめています。次章では、この表で分けた行を実際に集計していきます。

受け取った見積書・請求書を検証する5ステップ

ここからが本題です。手元の紙を使って進めてください。

ステップ1｜金額を4区分に割り振り、割り振れない行を数える

見積書の各行を、前章の費目区分①待機／②人の作業／③システムの作業／④実費のどれかに割り振り、割り振れなかった行を「未分類」とします（⑤引き継ぎ困難性は行にならないため、ここでは使いません）。

未分類の行は、そのままステップ5で「判断不能」と格付けされます。 区分に割り振れないということは、その行について問いを立てられないということだからです。

単位は万円でも円でもかまいません。1行が複数の区分にまたがる場合は、内訳が分からなければ「未分類」に入れてください。推測で割り振らないことが、この作業の要点です。

ここで見るのは金額の大小ではなく、未分類の金額が総額の何割を占めるかです。

• 未分類が総額の2割未満：内訳の分解が進んでいる見積書です。ステップ2へ進めます
• 未分類が総額の2割以上5割未満：主要な費目は見えていますが、確認が必要な部分が残っています
• 未分類が総額の5割以上：この見積書だけでは妥当性を判断できません。まず内訳の分解を依頼してください

ステップ2｜実費と役務を切り離す

④実費に割り振った行を抜き出し、次の3点を確認します。

1. 請求額が変動しているか。 クラウド利用料が毎月まったく同じ金額なら、実費ではなく定額料金として扱われている可能性があります
2. 原価の証憑が見られるか。 クラウド事業者の請求書やコンソール画面の値と突き合わせられるか
3. 手数料が分離されているか。 請求代行の手数料が実費に上乗せされている場合、その率が明示されているか

実費が総額に占める割合が大きいシステムでは、ここを切り離すだけで「保守費」として評価すべき金額が半分以下になることもあります。クラウド利用料を含む契約では、まずこの切り離しから着手してください。

ステップ3｜単発作業と継続作業を分ける

②人の作業の中から、一度きりで終わる作業が月額に含まれていないかを確認します。典型例は次のとおりです。

• 初期のデータ登録・移行作業
• 導入時の操作説明・マニュアル作成
• 環境構築、初期設定
• 特定の法改正への一度きりの対応

これらは本来、初期費用または都度見積もりで処理される性質のものです。ただし月額に含めることが合理的な場合もあります。正当と言える条件は後述の一覧にまとめました。

ステップ4｜請求実績と契約条件を突き合わせる

見積書ではなく、過去12か月の請求書と作業報告書を並べます。

作業報告書が出ていない場合、ステップ4は実行できません。 その時点で、月額固定部分の状態は「判断不能」です。まず報告書の提出を依頼するのが先になります。

ステップ5｜4状態で格付けする

ステップ1〜4の結果を、費目ごとに4状態へ割り当てます。総額に対して1つの判定を出すのではなく、費目ごとに判定します。

4状態の判定表

観点ごとに、4つの状態がどう見えるかをまとめました。手元の見積書と照らしてください。

太字の2項目は、金額の大小と無関係に優先度が高い項目です。 バックアップは取得しているだけでは復旧できず、管理権限がベンダー単独保有だと保守会社を変える選択肢そのものが失われます。後者は、価格の問題ではなく選択肢の問題です。

「これは保守に含まれるのか、追加開発なのか」で迷う項目（法改正対応、OSアップデート対応など）は、保守契約の範囲に判断の考え方をまとめています。

保守費が下がりにくい構造を、公開データで確認する

ここまでは手元の紙をどう読むかの話でした。ここからは、そもそもなぜ保守費が下がりにくいのかを、公開されている3つのデータで確認します。いずれも「相場」を示すものではなく、価格が決まる仕組みを理解するための材料です。

政府調達データが示す「競争の有無」の効き方（2004年度データ・2006年報告）

「なぜ保守費は下がりにくいのか」という問いに、実データで答えている資料があります。会計検査院が参議院からの要請を受けて実施した検査の結果です。

適用条件を先に書きます。

• 対象は国の府省等の情報システム調達であり、民間企業の保守契約ではありません。調達制度も予算制度も異なります
• データは平成16年度（2004年度）、報告は平成18年（2006年）10月25日です。20年以上前のデータです
• したがってこの数字は「現在の民間の相場」ではありません。価格が決まる仕組みを理解するための材料として読んでください

そのうえで、検査対象となった保守・運用契約492件・366億円について、報告されている内容は次のとおりです。

出典: 会計検査院「平成17年度決算検査報告」第4章第2節 第5「各府省等におけるコンピュータシステムに関する会計検査の結果について」（2006年10月25日報告、対象は平成16年度＝2004年度）

複数社が応札した場合の落札比率60.9%と、随意契約の97.4%。 この差が、競争の有無が価格に与える影響の大きさです。そして保守・運用契約の9割超が随意契約でした。さらにその随意契約452件のうち、個別府省の業務・システムに係る94件に限ってみると、9割（85件）が導入時ベンダーまたはその関連会社でした。

もう1つ、価格の決まり方そのものについての記述があります。同報告は、5つの共通業務（システム監視、予防保守、発注者側のシステム担当職員からの問合せへの対応、障害対応、システム運転）を含みSE等の技術者が担当している契約112件を抽出して、予定価格の算定方法を調べています。

• これらの契約を実施していた26省庁には、予定価格の算定に用いる積算マニュアルが存在せず、担当者は前年度実績や参考見積りを徴するなどの方法で予定価格を算定していた
• SE等の人件費単価（円／人月）の採用単価は、いずれの業務においても100万円未満から200万円以上までと幅がある
• 採用単価の根拠資料として最も割合が高いのは、各業務とも「事業者からの見積り」だった
• 根拠資料が異なると、いずれの業務においても単価の平均の最高と最低には2倍以上の差があった
• 予定価格におけるSE等の積算の妥当性について、112件のうち**「特に検証を行っていない」が29件（25.8%）**あった

同報告は「情報システム関係の保守・運用の契約については、工事請負契約等のような積算体系が確立されていないことから、その予定価格等は統一的に比較しにくい面がある」とし、単価の比較についても「各契約の業務内容は厳密には同等でないなどのため、単純に比較することはできないが」と限定を付したうえで、この結果を示しています。

読み取れることを、20年前の政府調達データから民間へ拡大解釈しない範囲でまとめます。

1. 保守・運用には、工事のような公的な積算体系が存在しない。 だから「正しい相場」が公表されようがない
2. 発注側が独自の積算根拠を持たないと、価格の出発点はベンダーの見積りになる。 これは不正ではなく、他に根拠がないという構造の問題です
3. 同じ業務でも単価は倍以上ばらつく。 単価が違うこと自体は、直ちに不当を意味しません
4. 競争が働くかどうかが価格に強く効く。 ただし1者応札では競争契約でも落札比率は高くなります

「相場より高いから不当だ」という主張は、この4点のどれからも導けません。 導けるのは「根拠を確認する必要がある」までです。

現在の民間側の傾向を、上場企業のIT予算から見る

20年前の政府データだけでは現在の話ができないので、直近の民間調査も併せて見ます。JUAS（一般社団法人 日本情報システム・ユーザー協会）の企業IT動向調査です。

この調査は、ランザビジネス予算を「現行ビジネスの維持・運営」、バリューアップ予算を「ビジネスの新しい施策展開」と定義し、IT予算の配分を継続的に調べています。

出典: JUAS「企業IT動向調査報告書2026」（2026年3月31日 初版第1刷発行、2025年度調査）図表2-1-18。調査期間2025年9月5日〜10月24日、東証上場企業とそれに準じる企業4,500社のIT部門長へ依頼、回答957社（有効回答率21.3%）。対象は上場企業層であり、中小企業の実態を表すものではありません

5年間、比率は76対24前後でほとんど動いていません。同報告書は「過去からバリューアップ予算へのシフトを目指す調査結果となっているが、実態として比率は上がっていない」と述べています。3年前の調査で「3年後には33.0%にする」と回答された目標は、実際には達成されませんでした。

IT予算の4分の3が現行維持に向かっているという構図は、保守費が例外的な追加コストではなく、IT支出の本体であることを示しています。同調査ではIT予算の増加理由（2025年度計画）の1位が「既存システム・基盤の刷新・更新・増強」66.3%、2位が「円安・人件費高騰・ベンダー提供価格の値上げなどによる影響」46.6%でした。これはIT予算が増加すると回答した502社を母数とする複数回答なので、「全企業の46.6%が値上げされた」という意味ではありません。またこの選択肢は3つの要因をまとめた1項目なので、値上げだけを取り出すこともできません。それでも、増額の理由として外部要因（円安・人件費高騰・ベンダー提供価格の値上げ）を挙げた企業が半数近くに上るという事実は残ります。値上げ通知を受け取っている企業が特殊なわけではない、ということです。

値上げ通知を受け取った場合は、率の妥当性を議論する前に、どの費目の単価が、いつから、どれだけ上がるのかを書面で確認してください。人件費の上昇が理由なら人の作業にあたる費目が、クラウド事業者の値上げが理由なら実費にあたる費目が動くはずです。値上げ幅が総額に一律で掛かっている場合は「要確認」です。

「保守」と呼ばれている作業の実体は、しばしば開発である

もう1点、費用の性質に関わるデータがあります。IPA「ソフトウェア開発分析データ集2022」が収集した開発プロジェクトの種別内訳です（2016年度〜2021年度）。件数と割合は原典の記載、合計1,479件はkoromo編集部が各区分を合算した値です。

出典: IPA「ソフトウェア開発分析データ集2022」図1-2-1「ソフトウェア開発プロダクトの種別」。同書はソフトウェア開発ベンダ35社の協力を得て収集した累計5,546件のうち、直近6年間（2016年度〜2021年度）を主な対象として分析。同書が収集しているのは工数・工期・規模・生産性・信頼性で、費用の実額は対象外です

同書における「b：改修・保守」の定義は「リリース後のシステムの運用フェーズで、ベースとなるシステムが存在し、機能追加など改修を伴う開発を行う（新規開発部分は約10%未満である）」です。そして同書は「2014年度～2019年度と比較すると、2016年度～2021年度は新規開発が32.5%から29.1%に減少し、改修・保守が45.8%から51.5%に増加している」と記しています。

集計されているプロジェクトの過半が、稼働後の改修です。つまり「保守」という言葉で呼ばれている作業のかなりの部分は、実体としては開発です。 開発である以上、要件の量と品質要求で工数が決まります。開発費に対する固定比率で表現できるものではありません。

なお、この割合はIPAに提出された開発プロジェクトデータの構成比であり、企業のIT支出のうち保守が占める割合ではありません。混同しないでください。

「安すぎる」保守見積もりのほうが危険なケース

保守費の検証というと減額の方向ばかり意識されますが、過小見積もりのほうが損失が大きくなる場面があります。次の費目が抜けている見積書は、金額が下がった分だけリスクを引き受けている状態です。

判断の目安：同じ対象システムで2社以上から保守見積もりを取ったとき、金額差が2倍を超えるなら、原因はほぼ確実に単価ではなく範囲の違いです。安いほうを選ぶ前に、上の表の8項目が両方の見積書に入っているかを確認してください。範囲が揃っていない2つの見積書を金額で比較することには意味がありません。

安さの理由が説明されている場合もあります。どこまでが正当な削り方かは、次章の一覧で条件ごとに整理しました。

ベンダー側の言い分が正当と言える条件

検証していると「これは説明のつく費用なのか、それとも押し付けられているのか」で迷う場面が必ず来ます。次の表は、ベンダー側の言い分が正当である条件をまとめたものです。ここに当てはまり、かつ根拠が示されているなら「説明済み」で構いません。

共通しているのは1点だけです。理由が示されていれば「説明済み」、示されていなければ「要確認」。 金額の水準そのものは、どちらの判定にも使いません。

保守費用が「妥当」と言える3つの条件

検証の結果、次の3条件がそろっていれば、金額の水準にかかわらず現行契約の継続が合理的と判断してかまいません。値下げ交渉をすることが常に正解ではありません。

1. 総額が①〜④（待機・人の作業・システムの作業・実費）へ割り振れており、未分類が総額の2割未満である
2. 毎月の作業報告書が提出され、契約上の上限・実績・超過の扱いが突き合わせられる
3. 引き継ぎに必要な資料と権限（設計書、環境構築手順、本番環境の管理権限）を、発注側がいつでも受け取れる契約になっている

3つ目が重要です。引き継げる状態が確保されていれば、価格は市場で検証可能な状態にあります。 今すぐ他社に切り替えなくても、切り替えられる状態を維持していること自体が、価格の妥当性を担保します。逆にこの条件が欠けていると、他の2条件を満たしていても、次回以降の更新で価格を検証する手段がありません。

ベンダーへそのまま送れる確認質問9問

そのまま送れるメール文面

以下はメールに貼り付けてそのまま送れる文面です。敵対的な聞き方をしていません。社内の予算説明に必要だから、という立て付けにしてあります。

◯◯株式会社
◯◯様

いつもシステムの保守運用でお世話になっております。
社内で次年度の予算説明を行うにあたり、現在の保守費用について
内訳と根拠を整理する必要が生じました。
恐れ入りますが、下記9点についてご回答をお願いできますでしょうか。

1. 現在の月額保守費について、①待機・体制維持の対価、②人が実施する作業、
   ③自動で実施されるシステム作業、④外部への支払いの実費、
   の4区分でおおよその内訳をお教えください。

2. ④実費に該当する費目（クラウド利用料、ライセンス、回線等）について、
   請求代行手数料の有無と、手数料が発生する場合はその率をお教えください。

3. 月額に含まれる作業時間の上限、上限を超えた場合の単価、
   未使用時間の繰越可否と失効条件について、契約上の定めをお教えください。

4. 直近12か月の作業実績（対応件数、作業時間、内容の区分）を
   ご共有いただけますでしょうか。

5. 監視について、自動監視の対象項目と、アラート検知後に人が実施する対応の
   範囲（検知の通知まで／一次切り分けまで／復旧作業まで）をお教えください。

6. 障害発生時の一次応答の目標時間と、復旧の目標時間を、
   それぞれ分けてお教えください。また目標が適用されない条件があれば
   併せてお教えください。

7. バックアップについて、取得頻度・保管世代数に加えて、
   復旧テストを実施しているか、実施している場合はその頻度と
   直近の実施結果をお教えください。

8. 現在の契約で保守対象外となる作業を、別表としてお示しいただけますでしょうか。
   特に、OSやミドルウェアのバージョン更新、法改正への対応、
   利用部門からの機能追加要望の扱いについてお教えください。

9. 弊社が保守運用を引き継ぐ、または他社へ移管する場合に必要となる
   資料（設計書、環境構築手順、運用手順書）と本番環境の管理権限について、
   現在の契約でどこまでお渡しいただけるか、
   別途費用が発生する場合はその金額をお教えください。

お手数をおかけしますが、◯月◯日までにご回答いただけますと幸いです。
よろしくお願いいたします。

回答をどう読むか

「要確認」の回答が返ってきたこと自体は、ベンダーへの評価ではありません。 中小規模の保守では、記録の仕組みがそもそも作られていないことは珍しくありません。重要なのは、次回の契約更新までに記録される仕組みを作れるかどうかです。それが合意できるなら、多くの場合は継続が合理的な選択になります。

質問9への回答が得られない、または高額な費用が提示された場合は、価格の問題ではなくベンダーロックインの問題として扱ってください。

判断が固まったあとの選択肢

検証の結果に応じて、取り得る行動は4つです。

いきなり他社見積もりを取る必要はありません。 内訳の分解を依頼して応じてもらえるなら、切り替えコストをかけずに検証が完了します。他社への相談が必要になるのは、分解を断られた場合と、質問9で引き継ぎ条件が得られなかった場合です。

悩みが具体的に決まっている場合は、次の記事が近道です。

• 見積書の行項目を1つずつ読み解きたい → システム保守見積書の見方
• 「これは保守に含まれるのか」で揉めている → 保守契約の範囲
• 変えたくても変えられない状態を解消したい → ベンダーロックインと保守費の高止まり
• これから作るシステムの保守費を予算に織り込みたい → システム開発の予算の組み方
• 開発費側の相場と妥当性を確認したい → システム・アプリ開発費用の相場と妥当性

手元の保守見積書をその場で分解したい場合は、**保守費用かんたん診断（登録不要）**が使えます。見積書のテキストはブラウザ内で識別情報をマスクしたうえで診断にかけられ、結果を見るまでメールアドレスの入力は不要です。診断結果は、本記事と同じく「高い／安い」ではなく、確認すべき項目とベンダーへの質問として返ります。

根拠資料と適用条件

本記事で使用した資料と、その適用範囲です。数値ごとに性格が違うため、まとめて扱わないでください。

金額を伴う記載については、本記事では取得日・通貨・税の取り扱い・契約期間の条件を併記しています。公開価格は改定されるため、実際の判断時には出典元の最新情報を確認してください。

なお本記事は、法的・会計的な最終判断を提供するものではありません。契約解釈や税務上の取り扱いについては、それぞれの専門家にご確認ください。

よくある質問