システム保守費用の相場｜妥当か判断する方法

「今のシステムの保守料は、高いのか安いのか」。この質問に、社内の誰も答えられない会社は珍しくありません。毎月・毎年、同じ金額が引き落とされ続けているのに、その金額が何に対する対価なのかが分からない。ところが金額の根拠を調べようと検索すると、出てくるのは「保守費用は開発費の何%が相場」という、割合で示された説明ばかりです。

結論から書きます。この「開発費の何%」という言い方は、それだけでは判断材料になりません。仮に同じ割合であっても、含まれる作業がまったく違うからです。障害の受付だけで成り立っている契約と、障害対応と問い合わせ回答と毎月の改修枠まで含んだ契約を、同じ物差しで比べても意味がありません。

この記事は、すでに動いているシステムの保守にいくら払うのが妥当かを、自社で判断できるようにするための記事です。保守契約に何が含まれ何が別料金になるのか、運用と保守はどう違うのか、SLA（サービスレベル合意）の何を見るのか、払いすぎ・足りていないをどう見分けるのかを、経済産業省とIPA（情報処理推進機構）が公開している資料の原文にあたりながら整理します。なお、システムそのものを替えるかどうかの判断は基幹システム刷新の進め方で扱っていますので、本記事は替えないまま、今の契約をどう見るかに絞ります。

結論｜割合ではなく中身で見る

保守費用が妥当かどうかは、金額の大小ではなく「その金額で何をしてもらう約束になっているか」で判断します。順番としては、金額の比較はいちばん最後です。

「開発費の何%」で判断できない

「保守費用は開発費の何%」という言い方が判断材料にならない理由は3つあります。

1. 分子（保守の中身）が会社ごとに違う：障害対応だけなのか、問い合わせ回答や小さな改修まで入るのかで、同じ%でも実質的な単価が数倍変わります
2. 分母（開発費）の定義も会社ごとに違う：初期費用にハードウェア、データ移行、教育、初年度の保守が含まれているかどうかで、母数そのものがずれます
3. 年数が経つほど分母が意味を失う：10年前の開発費を基準に何%と言われても、その間に業務も対象範囲も変わっています

つまり%は、同じ内容を買っている者どうしでしか比較できません。保守契約はその条件を満たさないため、%だけで高い安いを論じても結論が出ないのです。相場の記事を見て「うちは高い」と感じたときは、たいてい比べている中身が違います。

相場の数字を出さない理由

本記事では、保守費用の金額の目安を提示しません。当社が確認した範囲では、中小企業のシステム保守費用について、全国的な相場を示す公的な統計を見つけられなかったためです。裏付けのない金額を書けば、読んだ方が誤った基準で交渉してしまいます。

代わりに、この記事では金額を左右する要素の構造を示します。要素が分かれば、提示された金額が自社にとって妥当かを自分で検証できます。しかも、この検証は他社の相場を知らなくてもできます。

先に答える3つの問い

保守料の妥当性を考えるとき、最初に答えるべき問いは次の3つです。金額の話はこの後です。

1. そのシステムが止まったら、何時間で誰が困るか（必要な水準が決まる）
2. 直近12か月で、実際に何件・どんな依頼をしたか（使っている量が分かる）
3. 契約書と仕様書に、何をすると書いてあるか（買っているものが分かる）

この3つが揃うと、判断は驚くほど簡単になります。必要な水準より高く買っていれば払いすぎ、実際の依頼が契約の範囲外に何度もはみ出していれば足りていない、という単純な比較になるからです。逆に、この3つがないまま金額だけを交渉すると、値切れたとしても必要な守りまで削ってしまいます。

運用と保守はどう違うか

次に言葉を整理します。「運用保守」とひとまとめに呼ばれることが多いのですが、運用と保守は別の作業であり、公的な資料でも別の工程として定義されています。ここを分けないと、契約の抜けに気付けません。

公的な定義での線引き

経済産業省が公開している「情報システム・モデル取引・契約書」では、システムのライフサイクルを工程に分け、運用と保守をそれぞれ次のように定義しています。

• 運用：業務運用環境で情報システムを稼働して、業務を円滑に遂行するフェーズ。システムの起動・終了や監視、ファイルメンテナンスなどが含まれる
• 保守：情報システムやソフトウェアの現状を業務及び環境に適合するように維持管理を行う工程

（出典：経済産業省「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第一版〉）

言い換えると、運用は「動かし続ける」、保守は「直す・合わせる」です。同じ資料の契約サンプルでも、保守の例として「アプリケーション保守サービス」（アプリの障害調査・修正、仕様変更など）が、運用の例として「オンサイト型アウトソーシングサービス」（監視、トラブル対応、ヘルプデスク、運用管理業務、資産管理業務など）が、それぞれ別のサンプルとして示されています（出典：経済産業省「情報システム・モデル取引・契約書」（保守運用））。

実務で混ざってしまう理由

それでも現場で混ざるのは、中小企業では同じベンダーが両方を一括で請け負い、請求書に「保守料」の1行しか出てこないことが多いためです。混ざったままだと、次の3つの問題が起きます。

• 監視が止まっていても、保守料を払っているから安心だと思い込む
• 改修を頼んだら別料金だと言われ、「保守料は何のためか」と揉める
• サーバーの費用と人の作業費が同じ行に混ざり、値上げの理由が検証できない

どちらを頼んでいるか確認

いま払っている金額が、運用と保守のどちらに対するものかを分けてください。分け方は簡単で、請求明細と契約書を並べ、次の3つの箱に振り分けるだけです。

1. 動かし続けるための費用：サーバー・クラウドの利用料、回線、監視、バックアップの実行
2. 直すための費用：障害対応、原因調査、プログラムの修正、問い合わせ回答
3. 変えるための費用：機能追加、法改正対応、バージョンアップ

この3つに振り分けられない項目が残ったら、そこが確認すべき箇所です。実務上、揉める費用のほとんどは3番目（変えるための費用）に集まります。

保守契約に含まれるもの

ここからが本題です。保守契約に何が含まれるかは、契約書の本文には書かれていません。これは手抜きではなく、公的なモデル契約もそういう構造を推奨しています。

契約書は4層構造で決まる

経済産業省のモデル契約は、保守・運用について「多様なサービス形態が存在するため、基本契約書において各サービスモデルに共通的な事項のみを示し、具体的なサービス内容については、個別契約書及び仕様書において定めるものとする」としています（出典：経済産業省「情報システム・モデル取引・契約書」（情報システム保守運用委託基本モデル契約書））。

実際の構造は次の4層です。

文書	そこに書かれること
基本契約書	複数の委託に共通する条件（責任、秘密保持、解除など）
個別契約書	契約形態、業務内容、対象範囲、期間、役割分担、委託料
業務仕様書	どのユーザーにも共通する、その保守サービスの中身とSLA
受託条件明細	自社固有の条件（対象システム、実施場所、役割分担、数値目標）

同モデル契約の第3条では、個別契約で協議して定める取引条件として、契約形態（請負・準委任）、業務内容、対象とする情報システムの範囲及びその詳細、実施開始日及び実施期間、役割分担、提供する資料、委託料及びその支払方法などが列挙されています（出典：経済産業省「情報システム・モデル取引・契約書」（保守運用委託基本モデル契約書 第3条））。

つまり、契約書だけを読んでも保守の中身は分かりません。「業務仕様書」と「受託条件明細」に相当する書面を持っているかを、まず確認してください。手元にないなら、それがベンダーに要求すべき最初の1点です。なお、請負と準委任のどちらで契約しているかによって責任範囲が変わる点は、準委任と請負の違いで詳しく扱っています。

なお、このモデル取引・契約書は、その後IPA（情報処理推進機構）が第二版として公開し直しています。2020年12月22日公開の第二版には、受託開発・保守運用のほか、パッケージやSaaS・ASPの活用と保守・運用を対象にした追補版も含まれています（出典：IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開））。パッケージやクラウドサービスを使っている場合は、こちらの構成もあわせて確認してください。

含まれる作業の中身

同モデル契約の「アプリケーション保守サービス」の業務仕様書サンプルでは、保守業務が次のように分解されています。自社の契約と突き合わせるときの物差しとして使えます（出典：経済産業省「情報システム・モデル取引・契約書」（業務仕様書サンプル：アプリケーション保守サービス））。

• 案件管理：対処要求、変更要求、リリース要求、質問などの受付と進捗の監視
• インシデント管理：異常や中断への対処と、復旧のための対応、報告ルールに従った連絡
• 問題管理：原因が特定できない事象について、根本原因への対応方法を決定
• 変更管理・リリース管理・構成管理：修正内容の管理、リリースの管理、変更履歴と版数の管理
• 定例報告：実施状況を決められた周期で報告書にまとめて提出
• 本番処理検証：リリース前に、実データまたは試験用データで処理を検証
• 業務アプリケーションの改良：動作環境の変化に対応するための修正、性能や保守性を改善する修正
• トラブル対応・質問対応：修正の設計と実施、検証、質問への調査と回答
• 予防保守：潜在的な障害を顕在化する前に発見した場合の是正
• システム・運用改善提案：稼働状況を分析して改善案を報告

この一覧を見ると、「定例報告」と「改善提案」が保守サービスの構成要素として明記されていることに気付きます。報告書が何年も届いていないなら、契約の一部が履行されていない可能性があります。ここは値下げ交渉より先に指摘すべき点です。

含む含まないの一覧表

実務でよく問題になる項目を、含まれやすいものと別料金になりやすいものに整理しました。「多い・少ない」は当社が相談を受けてきた範囲での傾向であり、最終的には自社の受託条件明細の記載が優先します。

項目	保守契約に含まれるか	確認する場所
障害の受付と一次対応	含まれることが多い	業務仕様書のインシデント管理
原因調査と根本対応	含まれることが多い	業務仕様書の問題管理
操作方法の問い合わせ回答	契約による	質問対応の有無と件数の上限
小さな改修（項目追加など）	契約による	改良の枠（人日・件数の上限）
法改正への対応	契約による	受託条件明細の対象範囲
製品のバージョンアップ	別料金になりやすい	ライフサイクル期間と保守可能期間
OS・ミドルウェアのパッチ適用	契約による	保守契約（ソフトウェア）の範囲
サーバー・クラウドの利用料	別（利用者負担が原則）	受託条件明細の費用負担
回線・通信の費用	別（利用者負担が原則）	業務仕様書の協力義務
死活監視・性能監視	運用側の別サービスが多い	運用の契約または監視の仕様
夜間・休日の対応	別料金になりやすい	時間外の単価と条件
監査への対応	別料金（依頼側の負担）	監査条項の費用負担
新機能の追加開発	含まれない	新規開発との境界線の定義
更改・データ移行	含まれない	別契約

回線や通信の費用が利用者側の負担になる点は、モデル契約の業務仕様書サンプルにも「回線使用料、及び乙への電話、FAX及びE-mail等に係る料金等の通信費用は、甲の負担とします」（甲がユーザー、乙がベンダー）と明記されています。監査についても第13条で「調査費用は甲の負担とし」「当該監査への対応において乙が委託料で賄えない費用を要する場合、当該費用は甲の負担とする」と定められています（出典：経済産業省「情報システム・モデル取引・契約書」（保守運用委託基本モデル契約書 第13条・業務仕様書サンプル））。

別料金になりやすい6項目

ここでは、請求で揉めやすい項目を個別に掘り下げます。揉める原因のほとんどは「境界線が書かれていないこと」です。

法改正対応はどちら扱いか

まず結論として、法改正対応は保守に含めることができる作業ですが、自動的に含まれるわけではありません。

経済産業省のモデル契約は、アプリケーション保守サービスを「ユーザの動作環境などが変化した場合において、対象アプリケーションを使用できるように保ち続けるための修正及び性能改善、保守性改善（例：法律の改正による修正など）を実施するサービス」と説明しています（出典：経済産業省「情報システム・モデル取引・契約書」（アプリケーション保守サービスの定義））。法改正による修正は、保守の例として明示されているわけです。

一方で同資料は、「どこまでの修正が本件保守業務の対象となるか（新規ソフトウェア開発との境界線）については、受託条件明細等によりその範囲を明確に規定しておく必要がある」とも注記しています（同資料）。つまり境界線は自動で決まらず、書いた者勝ちです。

実務では次の3点を書面で確認してください。

• 税率や様式の変更のような軽微な修正は保守に含むか
• 制度そのものが変わり、新しい帳票や機能が必要になる場合はどう扱うか
• 改正の情報を誰が拾ってくるのか（ベンダーからの通知義務があるか）

3つ目が抜けがちです。「改正に気付いた人がいなかった」という理由の事故は、責任の所在が最も曖昧になります。通知の義務がないなら、社内で誰が確認するかを決めておく必要があります。

バージョンアップと保守期限

パッケージ製品を使っている場合、避けて通れないのがバージョンアップです。IPAの「非機能要求グレード2018」は、非機能要求の項目のひとつとして「ライフサイクル期間」を挙げ、レベルを3年・5年・7年・10年以上で示したうえで、「製品の保守可能期間よりも長い期間のライフサイクルとなる場合は、保守延長や保守可能バージョンへのアップ等の対応が必要となる」と注記しています（出典：IPA「非機能要求グレード2018」グレード表（2018年4月））。

ここから読み取るべきは、製品の保守可能期間と、自社がシステムを使い続けたい期間は、別々に決まるということです。前者が先に切れれば、費用は必ず発生します。保守料に含まれるかどうか以前に、いつ発生するかを把握しているかどうかが問題です。

確認すべきは次の3点です。

1. 使っている製品（OS、データベース、パッケージ）のサポート終了日
2. 終了後に延長保守があるか、その費用はいくらか
3. バージョンアップ作業は保守料に含まれるのか、都度見積なのか

サーバー費用と監視の扱い

クラウドに移した会社でよく起きるのが、クラウドの利用料が保守料に含まれているかどうかが曖昧なまま値上げされるケースです。前述のとおり、モデル契約では回線や通信の費用は利用者側の負担が原則です。同様に、サーバーやクラウドの利用料は、人が作業する対価とは別の性質の費用です。

監視についても分けて考えてください。IPAの非機能要求グレードでは、運用監視の水準として、不定期監視（手動監視）からリアルタイム監視（分間隔）、リアルタイム監視（秒間隔）までのレベルが定義されています（出典：IPA「非機能要求グレード2018」グレード表（運用監視））。「監視しています」の一言では、手動で時々見ているのか、秒単位で見ているのかが分かりません。間隔と、異常を検知したときに誰にどう連絡が来るかを、書面で確認してください。

委託しても残る4つの役割

見落とされがちな重要点です。モデル契約に添付された「ITサービスマネジメントの視点での役割分担表」では、アプリケーション保守サービスを委託した場合でも、ITサービス財務管理・可用性管理・キャパシティ管理・ITサービス継続性管理は、ユーザー側（甲）の担当として整理されています（出典：経済産業省「情報システム・モデル取引・契約書」（ITサービスマネジメントの視点での役割分担表））。

ユーザー側に残る役割	具体的に何をするか
ITサービス財務管理	いくら払うか、その水準が必要かを決める
可用性管理	どこまで止まってよいかを決め、達成状況を見る
キャパシティ管理	利用者数やデータ量の増加を見込んで手を打つ
ITサービス継続性管理	災害時に業務をどう継続するかを決める

ただし同表には、アプリケーションプログラムの可用性管理はベンダー側の担当とする、といった但し書きも添えられています（同資料）。全部がユーザー側という意味ではなく、「どこまで止まってよいかを決める」部分が残ると読むのが正確です。

また同資料は、役割分担表の注釈で「この定義が曖昧だと、サービス開始後に、甲と乙どちらが実施すべき作業か不明な事態が多々発生し、サービス実施に支障をきたす」と述べ、開始前に双方が納得いくまでレビューして合意することが肝要だとしています（同資料）。保守を外に出しても、「どこまで止まってよいか」を決める役割は社内から消えません。ここを空席にしたまま金額だけを議論すると、必ず議論が空転します。

保守費用を決める7要素

金額の構造です。保守費用は、次の7つの要素で決まります。このうち5つは、発注側の意思決定で変えられます。

要素	金額が上がる方向	抑える方向
受付時間と体制	24時間365日、常時待機	実績に合わせて平日日中に絞る
復旧目標と稼働率	数時間以内の復旧、高い稼働率	翌営業日で足りる業務は下げる
対象範囲	使っていないサブシステムも対象	使っている範囲だけに絞る
含める作業の種類	改修・法改正・監視を全部込み	発生頻度の低いものは都度払い
改修の枠	毎月の枠を大きく確保する	実績に合わせ、超過は都度精算
資料の有無	設計書も項目定義書もない	資料を整備して調査時間を減らす
技術の古さと属人性	触れる人が世の中に少ない	ここは短期では変えられない

受付時間と体制で変わる

費用に最も効くのは受付時間です。IPAの非機能要求グレードは、可用性の項目である「運用時間」について、「運用時間は、システムの可用性の実現レベルを表す項目であるとともに、運用・保守性に関する開発コストや運用コストを検討する上でも必要となる項目である」と説明し、可用性と運用・保守性の両方に含まれる重複項目として扱っています（出典：IPA「非機能要求グレード2018」グレード表（運用時間））。

同グレード表では、運用時間のレベルが「規定無し」「定時内（9時から17時）」「夜間のみ停止（9時から21時）」「1時間程度の停止有り」「若干の停止有り」「24時間無停止」の6段階で示されています（同資料）。この段階を1つ上げると、必要な体制も、冗長化の構成も、点検のやり方も変わります。費用が階段状に上がるのはそのためです。

資料の有無で工数が変わる

同じ修正でも、設計書とデータ項目定義書がある場合とない場合では、調査にかかる時間がまったく違います。資料がなければ、担当者はソースコードを読むところから始めます。これは値下げ交渉では解消できないコストです。

非機能要求グレードでも、マニュアルの準備レベルが「各製品標準のマニュアルを利用する」から「ユーザのシステム運用ルールに基づくカスタマイズされたマニュアルを提供する」までの段階で定義され、カスタマイズされたマニュアルは「作成するためにコストがかかるため導入コストが増大するが、ユーザが運用時に手順を調査する負担が減少するため運用コストは減少する」と整理されています（出典：IPA「非機能要求グレード2018」グレード表（マニュアル準備レベル））。初期に払うか、毎月払い続けるかの選択だということです。

見積の比べ方

複数のベンダーから見積を取るとき、総額を並べても比較になりません。次の順で並べてください。

1. 受付時間（曜日、時間帯、祝日の扱い）
2. 一次応答の目標時間と復旧の目標時間（別々に確認する）
3. 含まれる作業の一覧（前掲の10分類で突き合わせる）
4. 改修の枠（人日か件数か、超過分の単価）
5. 対象システムの範囲（サブシステム単位で列挙されているか）
6. 報告の頻度と形式
7. 解約の条件（予告期間、中途解約金の有無）

この7項目を揃えたうえで金額を比べれば、初めて比較になります。金額差の大半は1と2で説明が付きます。

SLAとは何を約束する契約か

SLA（Service Level Agreement／サービスレベル合意）は、提供されるサービスの品質を数値で約束するものです。保守運用の分野で必ず出てくる言葉ですが、実際に何が約束されているかを読める人は多くありません。

SLAは仕様書の中にある

まず場所です。経済産業省のモデル契約では、「本モデル契約書における構成では、SLA条項は、ユーザ毎に作成される『仕様書』の中でサンプルとして規定している」と明記されています（出典：経済産業省「情報システム・モデル取引・契約書」（SLAの位置づけ））。契約書の本文を探しても見つからないのは、そういう構造だからです。

同資料は、SLAの導入にあたって留意すべき点として次の4つを挙げています（同資料）。

• 信頼できる客観的な評価の可能性
• 評価項目の妥当性と要求水準の達成可能性
• 時間の経過に沿った見直し
• 管理に係るコスト（測定方法・監視体制）の合理性

3つ目は特に中小企業に効きます。10年前に結んだSLAが今の業務に合っている保証はありません。見直しは契約違反ではなく、資料が想定している正常な運用です。

応答時間と復旧時間は別

ここが最大の誤解ポイントです。モデル契約の業務仕様書サンプルに示されたSLAの項目は、次の3つです（出典：経済産業省「情報システム・モデル取引・契約書」（業務仕様書サンプルのサービスレベル））。

SLAの項目	測っているもの
インシデント管理レスポンス遵守率	障害の受付から一次応答（折り返し）までの時間
質問一次回答時間遵守率	質問の受付から回答または調査状況の提示までの時間
改良納期遵守率	改良要望の受付から受入承認依頼までの時間

3つとも「復旧までの時間」ではありません。一次応答は「連絡を受けて折り返すまで」であり、質問一次回答には「調査状況及び回答予定日の提示」も含まれます。「30分以内に応答」と書いてあっても、30分で直るという意味ではないのです。

復旧の目標時間を約束してほしいなら、それは別に定める必要があります。ここを混同したまま「SLAがあるから安心」と考えていると、実際に止まったときに認識のずれが表面化します。

未達でも返金とは限らない

同じ業務仕様書サンプルでは、サービスレベルを達成できなかった場合の取り扱いとして、「本件業務を実施するための人員による可能な範囲での乙所定の改善努力を行います」と規定されています（同資料）。つまり、サンプルの水準では、未達でも返金や違約金ではなく「改善努力」です。

ただし、同じ資料の本文では、契約書において「サービスレベル達成・不達の結果に対する対応措置（協議手続、解約権、ペナルティ・ボーナス）、ベンダの報告条件等を定めることが必要である」とも述べられています（同資料）。ペナルティやボーナスを定めること自体は、公的資料が想定している選択肢だということです。

したがって、自社の契約が「改善努力」だけで終わっているなら、それは標準的な状態であって、不当ではありません。ただし、止まったときに損害が大きい業務なら、対応措置を交渉する余地があります。逆に、止まっても大きな損害が出ない業務に厳しいペナルティを求めれば、その分は必ず月額に乗ります。

稼働率99%は何時間の停止か

SLAでいちばんよく見る数字が稼働率です。ところが、この数字の意味を正しく読める人は多くありません。

稼働率と停止時間の対応

IPAの非機能要求グレード2018は、稼働率のレベルを「95%以下」「95%」「99%」「99.9%」「99.99%」「99.999%」の6段階で示し、24時間365日稼働の場合に1年間で業務が中断する時間の合計を次のように整理しています（出典：IPA「非機能要求グレード2018」グレード表（稼働率））。

稼働率	24時間365日稼働での年間中断時間
95%	18.3日
99%	87.6時間
99.9%	8.76時間
99.99%	52.6分
99.999%	5.26分

同資料はさらに、1日8時間・週5日稼働のシステムでは、週に1時間の停止が97.5%、月に1時間が99.4%、年に1時間が99.95%にあたるとも示しています（同資料）。

この対応表を見ると、「99%なら十分だろう」と考えるのが、年間87時間以上止まってもよいと言っているのと同じだと分かります。逆に、平日日中しか使わないシステムなら、月に1時間止まっても99.4%です。%だけを見て高い低いを判断してはいけないのは、こういう理由からです。

RTO・RPO・RLOの決め方

復旧の目標は、3つの指標に分けて考えます。IPAの非機能要求グレード2018では、それぞれ次のようなレベルが定義されています（出典：IPA「非機能要求グレード2018」グレード表（目標復旧水準））。

指標	意味	レベルの例
RTO（目標復旧時間）	どれくらいの時間で復旧させるか	1営業日以上／1営業日以内／12時間以内／6時間以内／2時間以内
RPO（目標復旧地点）	いつの時点のデータまで戻せるか	5営業日前（週次バックアップ）／1営業日前（日次バックアップ）／障害発生時点
RLO（目標復旧レベル）	何を復旧の対象とするか	システムの復旧／特定業務のみ／全ての業務

実務でいちばん抜けているのはRPOです。「1日で復旧します」と言われて安心していたら、戻せるのは前日夜のバックアップ時点で、当日入力した伝票は全部消えていた、という事故が起こります。復旧にかかる時間と、失われるデータの量は、別々に確認してください。

目標を上げると費用が増える

非機能要求グレードのグレード表には「運用コストへの影響」という欄があり、項目ごとに水準を変えたときのコストへの影響が注記されています。たとえば計画停止について、「計画停止有りの場合、事前のバックアップや、システム構成に応じた手順準備など、運用時のコストがかさむ」とされています（出典：IPA「非機能要求グレード2018」グレード表（計画停止））。

逆方向の指摘もあります。ハードウェアとソフトウェアの保守契約について、同資料は「サポート契約を行うと運用コストが増大するように感じられるが、問題が発生した際に必要となる費用が膨大となるため、サポート契約を行ったほうが結果として運用コストは小さくなる場合がある」と述べています（同資料）。

つまり保守は、単に削れば得をする費用ではありません。削ってよいのは「使っていない水準」であって、「必要な守り」ではない、という当たり前の線引きが必要です。この線引きをするための道具が、次の判定表です。

ちなみに、非機能要求グレードは初版が2010年4月に公開され、その初版は全体236のメトリクス（測定項目）で構成されていました。2018年の改訂では、そのうち2項目が新規追加、20項目が修正されています（出典：IPA「非機能要求グレード2018 改訂情報 ～初版との差異～」（2018年4月25日））。止まってよい時間ひとつ決めるだけでも、本来これだけの項目が背後にあります。中小企業がこれを全部埋める必要はありませんが、「保守料の中身が分からない」のは自然なことだと分かります。分からないまま払い続けるのではなく、自社に効く数項目だけを選んで書面にする、というのが現実的な進め方です。

24時間365日は必要か

ここが本記事でいちばんお伝えしたい論点です。24時間365日の対応を、惰性で契約し続けている会社は本当に多いと感じています。

止まって困る時間を測る

必要な水準は、業務側から決めます。手順は3つです。

1. そのシステムが止まったとき、最初に困るのは誰かを書き出す（部署名と人数）
2. 止まってから何時間で、取り返しがつかなくなるかを業務ごとに答える
3. 止まった時間帯によって答えが変わるかを確認する（月末だけ厳しい等）

3つ目が重要です。多くの中小企業では、24時間365日が必要なのではなく、「月末の3日間だけ厳しい」というのが実態です。それなら、常時24時間365日で契約するのではなく、特定期間だけ体制を上げる契約のほうが実態に合います。IPAの非機能要求グレードでも、休日・祝祭日や月末月初など通常と異なる運用スケジュールを「特定日」として、通常時とは別にレベルを設定する考え方が示されています（出典：IPA「非機能要求グレード2018」グレード表（運用時間・特定日））。

必要な水準を決める判定表

「止まったら何時間で困るか」から必要な水準を導く判定表です。水準の刻み（稼働率、RTO、運用時間）はIPAの非機能要求グレード2018のレベル定義を用い、業務影響との対応づけは当社の整理です。自社の実態と照らして、行を選んでください。

止まったときに起きること	許容できる停止時間	受付時間の目安	復旧目標（RTO）の目安	稼働率の目安
担当者が別の作業に回れる	数日	平日日中	1営業日以上	95%前後
社内業務は止まるが翌日取り返せる	1営業日	平日日中	1営業日以内	99%
出荷や請求など締切のある業務が止まる	半日	平日9時から21時	12時間以内	99.9%
取引先や顧客が直接影響を受ける	数時間	土日祝も受付	6時間以内	99.99%
社外の多数の利用者に影響が及ぶ	数分	24時間365日	2時間以内	99.999%

この表の下2行に当てはまる中小企業は、実際にはそう多くありません。IPAの非機能要求グレードも、モデルシステムを3つに分け、企業内のネットワークに限定した基幹システムを「社会的影響が限定されるシステム」として想定しています。同モデルの特徴として、稼働率は1年間で1時間程度の停止まで許容できる水準（99.99%）、データのリカバリを伴う復旧では1営業日以内での復旧が目標水準、大規模災害時は1週間以内での復旧を目指す、と整理されています（出典：IPA「非機能要求グレード2018」グレード表（モデルシステムの概要））。

ここで注目すべきは、企業の基幹システムであっても、データ復旧は「1営業日以内」が目標水準として置かれている点です。数時間以内の完全復旧が当然だと思い込んでいると、必要以上の水準を買うことになります。

過剰な水準が招く3つの損

必要以上のSLAを買うと、金額以外にも損をします。

1. 使わない待機の費用を払い続ける：夜間の呼び出し実績がゼロでも、体制の費用は毎月発生します
2. 本当に必要な項目にお金が回らない：予算の総額が決まっている以上、過剰な部分は他を圧迫します
3. ベンダーが慎重になりすぎる：高い水準を約束させると、影響の読めない変更を避ける方向に働きます

3つ目は見落とされがちです。厳しいSLAは、改修のスピードとは両立しにくいという性質があります。止めないことを最優先にすれば、変更は慎重になります。何を優先したいのかを、社内で言語化しておいてください。

「うちの保守契約は今の業務に合っているのか」を一緒に棚卸しします。当社はシステムの開発会社でも保守ベンダーでもないため、特定の契約を勧める立場にありません。契約書と直近12か月の実績を見ながら、必要な水準を整理するところからご一緒します。初回のご相談は無料です。無料相談はこちら。

払いすぎ・足りないの判定

ここまでの考え方を、チェックリストの形にまとめます。片方だけでなく、両方を見てください。実務では「一部は払いすぎで、一部は足りていない」という状態が最も多いためです。

払いすぎを疑う5つのサイン

1. 直近12か月の障害・問い合わせ・改修の件数を、誰も数えていない
2. 定例報告書が届いていない、または届いていても中身が毎月ほぼ同じ
3. 契約に含まれる改修の枠を、一度も使い切ったことがない
4. 24時間365日で契約しているが、夜間や休日に人が動いた実績がない
5. すでに使っていないサブシステムが、対象範囲に残っている

3つ以上当てはまるなら、水準の見直しを検討する価値があります。ただしいきなり解約するのではなく、水準を下げる交渉から始めてください。理由は後述します。

足りていない5つのサイン

1. 障害のたびに「これは保守の範囲外です」と言われ、都度見積が出る
2. 復旧の目標時間が、どこにも書かれていない（応答時間しかない）
3. バックアップからの復旧を、実際に試したことが一度もない
4. OS・ミドルウェア・パッケージのサポート期限を、誰も把握していない
5. ベンダー側の担当者が1人で、その人が休むと連絡がつかない

1番と2番はセットで起きます。範囲が書かれていないから毎回もめ、復旧目標がないから「いつ直るのか」も答えられない。この状態は、金額の高低にかかわらず、契約として不十分です。3番も見落とされがちで、バックアップは取っていても戻せるかを試していない会社が本当に多いです。セキュリティ面での備えについては中小企業のセキュリティ対策もあわせてご覧ください。

実績を数える3つの資料

判定に必要な資料は3つだけです。これを12か月分そろえてください。

• 定例報告書（保守ベンダーからの月次報告。件数と内容が載っている）
• 請求書（月額と、別料金で請求された項目の一覧）
• 社内のメール・チャットの依頼履歴（報告書に載らない依頼を拾う）

この3つを並べて、「何を、何件、どの時間帯に頼んだか」を数えるだけで、必要な水準はほぼ見えます。定例報告書がないなら、その事実自体が最初の交渉材料です。集計そのものは表計算ソフトで十分ですが、依頼履歴の分類のように件数が多く形式が揃っていない作業は、生成AIに下準備をさせると早く終わります。

【モデルケース】保守費の見直し

ここまでの考え方を、具体的な数字で示します。以下は実在の企業ではなく、当社が想定する典型的な状況にもとづくモデルケース（試算）です。金額はすべて説明のために置いた仮の数字であり、相場を示すものではありません。前提は時給換算2,500円・月20営業日とします。

想定した会社と契約内容

• 従業員40名の卸売業。販売管理システムを10年前に導入し、現在も稼働中
• 保守契約は導入時のまま。月額12万円（仮の金額）で自動更新を9年間継続
• 契約書はあるが、業務仕様書や受託条件明細に相当する書面は手元にない
• 受付は24時間365日。復旧の目標時間は契約に記載がない
• 改修の枠は月2人日。使い切ったことがあるか、誰も把握していない
• 事務部門3名が、システムの前後の手作業と社内の問い合わせ対応に追われている

12か月の実績を数える

定例報告書と請求書、社内の依頼メールを12か月分並べて数えた結果（試算）は次のとおりです。

項目	12か月の実績	時間帯
システム停止を伴う障害	0件	該当なし
軽微な不具合（業務は継続可能）	2件	いずれも平日日中
操作方法などの問い合わせ	14件	すべて平日日中
改修の依頼	3件（合計4人日）	平日
夜間・休日の呼び出し	0件	該当なし

この会社は、年間24人日ぶんの改修枠を確保しながら、4人日しか使っていませんでした。また、24時間365日の受付体制に対して、夜間・休日の呼び出し実績はゼロでした。

見直し後の試算

前掲の判定表に当てはめると、この会社は「社内業務は止まるが翌日取り返せる」行に該当しました。月末の3営業日だけは出荷業務があるため、そこだけ水準を上げる形にします。見直し前後の内訳（試算）は次のとおりです。

項目	見直し前	見直し後（試算）
受付時間	24時間365日	平日9時から18時（月末3営業日は21時まで）
復旧目標（RTO）	記載なし	1営業日以内（月末は12時間以内）
復旧地点（RPO）	記載なし	前営業日終業時点（日次バックアップ）
改修の枠	月2人日（込み）	月0.5人日、超過は都度精算
対象範囲	停止済みの旧機能を含む	稼働中の範囲のみ
定例報告	実質なし	月次で件数と対応内容を報告
月額（仮の金額）	120,000円	75,000円

差額は月45,000円です。ただし、この45,000円は「値切って浮いた金額」ではありません。使っていなかった水準（夜間の待機と、使い切れない改修枠）をやめ、代わりに記載のなかった復旧目標と定例報告を契約に入れた結果です。削った項目と、足した項目が両方ある点が重要です。

社内側の手間を減らす試算

保守契約の見直しと並行して、社内側に残っていた手作業にも手を入れました。事務部門3名の合計時間について、着手前と3か月後の試算です。

業務	着手前	3か月後（試算）	削減
社内からの操作方法の問い合わせ対応	18時間／月	7時間／月	11時間
出力データの集計・部門別の資料作成	20時間／月	7時間／月	13時間
受注内容の転記と入力用データ作成	26時間／月	12時間／月	14時間
月次の突合（受注と在庫の差異調査）	12時間／月	6時間／月	6時間
合計	76時間／月	32時間／月	44時間

時給換算2,500円で計算すると、月44時間の削減は110,000円相当です。当社の支援費用を初期0円・月額5万円とした場合、差引で月60,000円相当が手元に残る計算になります。いずれも試算であり、実際の削減幅は業務の内容と量によって変わります。

数字より大きかった変化

この想定で本質的に重要なのは、削減額そのものではありません。次の3つです。

• 復旧目標が契約に入った：以前は「いつ直るか」が誰にも答えられませんでしたが、目標が明文化されました
• 定例報告が復活した：件数が見えるようになり、来年の見直しが実績にもとづいてできます
• 社内に判断者ができた：どこまで止まってよいかを決める役割が、空席でなくなりました

3つ目が最大の成果です。前述のとおり、可用性管理はユーザー側に残る役割です。ここに人がいない限り、契約は毎年そのまま更新され続けます。

契約を見直す進め方

最後に、実際に見直すときの手順です。当社の立場は明確です。いきなり切らないでください。

いきなり切ると危ない理由

保守契約を解約すると、次のことが同時に起こります。

1. 障害時の窓口が消える：止まったときに誰に連絡するかがなくなります
2. 次のベンダーは調査から始まる：前任がいなくなると、同じ改修でも工数が増えます
3. 中途解約の費用が発生することがある：モデル契約の業務仕様書サンプルにも、基本実施期間の満了前に中途解約する場合の中途解約料金と、事前通知の期間を定める条項が示されています（出典：経済産業省「情報システム・モデル取引・契約書」（業務仕様書サンプル：中途解約））
4. 資料が手に入らなくなる：設計書やデータ項目定義書の引き渡し条件を決めていないと、移管できません

4番目が最も深刻です。資料がないまま関係を切ると、そのシステムは誰にも触れない箱になります。「古いから替える」という話とは別に、この状態だけは避けてください。システムそのものを替えるかどうかの判断材料は基幹システム刷新の進め方に整理しています。

見直しの5ステップ

1. 実績を数える：定例報告書・請求書・依頼履歴を12か月分そろえ、件数と時間帯を集計する
2. 買っているものを確認する：契約書、業務仕様書、受託条件明細を並べ、含まれる作業を一覧にする
3. 必要な水準を決める：判定表で行を選び、受付時間・RTO・RPO・改修枠の必要量を決める
4. 現ベンダーに条件変更を打診する：解約ではなく、水準の変更として相談する。同時に、記載のない項目（復旧目標、定例報告、資料の引き渡し）を入れてもらう
5. それでも折り合わなければ相見積を取る：1から3で作った資料をそのまま渡す

4番目を飛ばさないでください。実績と必要水準を数字で示せば、条件変更に応じてもらえる可能性は十分にあります。ベンダー側も、根拠のない値下げ要求には応じられませんが、実態に合わせた範囲の見直しであれば検討の土俵に乗ります。要求のまとめ方は要件定義の進め方の考え方がそのまま使えます。

見直しでよくある3つの失敗

失敗	何が起きるか	防ぎ方
相場の%を根拠に値切る	根拠を示せず交渉が止まる。応じてもらえても、削られるのは報告や予防保守など見えにくい部分	実績と必要水準を数字で示し、削る項目を自分で指定する
安い見積に飛びつく	受付時間や復旧目標が下がっていることに気付かず、止まってから差が出る	金額の前に、受付時間とRTOとRPOを揃えて比較する
資料の引き渡しを決めずに切る	次のベンダーが調査から始め、改修単価が上がる。最悪の場合、触れる人がいなくなる	解約の条件として、設計書・データ項目定義書・データの出力手段を明記する

3つに共通するのは、「金額を先に動かした」という点です。順番は、実績を数える、必要水準を決める、条件を交渉する、最後に金額です。この順番を守るだけで、失敗の大半は避けられます。DX関連の取り組み全般でつまずきやすい点はDXが失敗する理由にまとめています。

AIで減らせる範囲と線引き

当社はAI導入支援の会社ですが、「保守をAIで置き換えられます」とは申し上げません。保守費用が下がるのは、要求水準を実態に合わせたときと、社内側の手間が減ったときであって、AIが保守作業を代行するからではありません。そのうえで、実際に効く使いどころはあります。

AIに任せてよい作業

• 実績の集計と分類：12か月分の依頼メールを、障害・問い合わせ・改修に分類して件数を出す
• 契約書と仕様書の突き合わせ：本記事の一覧表の項目が書かれているかを機械的に確認する
• 社内問い合わせの一次受け：過去の質問と回答を整理し、よくある操作の手順を社内向けにまとめる
• 定例報告書の読み解き：何が起きて、どう処理されたのかを平易な言葉に直す
• 出力データの集計：システムから出したCSVを、部門別・得意先別に集計する

いずれもシステムの中に手を入れずに、出力されたものを扱うだけで成立します。だから古いシステムのままでも始められます。社内向けの小さな道具づくりについてはAIでアプリを作る方法、業務システムを自作する場合の考え方は在庫管理システムの自作で扱っています。固定費全体の見直しは経費削減の進め方もあわせてご覧ください。

AIに任せてはいけない作業

• 障害の切り分けと復旧の判断：本番環境で何を実行するかは、責任を持つ人が決める
• 本番環境への変更の適用：手順の下書きまでは可能でも、実行と確認は人が行う
• パッチ適用の可否判断：業務への影響を含む判断であり、資料だけでは決められない
• SLA未達時の責任の切り分け：契約と事実関係の解釈が必要で、法務の領域に入る
• ベンダーを変えるかの最終判断：金額以外の要素（体制、資料、継続性）を含む経営判断

境界の引き方は明快です。間違えたときに誰かが責任を取る必要がある作業は、人が決める。それ以外の、集計・整理・下書きはAIに任せてよい、という線引きです。実務でどこまで任せるかの設計は業務タスクのAI活用支援でご相談を承っています。

よくある質問（FAQ）

Q. 保守費用の相場はいくらですか？

A. 当社では金額の目安を提示していません。中小企業のシステム保守費用について、全国的な相場を示す公的統計を確認できないためです。代わりに、費用を決める7要素（受付時間と体制／復旧目標と稼働率／対象範囲／含める作業の種類／改修の枠／資料の有無／技術の古さと属人性）で構造的に見てください。このうち5つは発注側の意思決定で変えられます。

Q. 開発費の何%が目安ですか？

A. %だけでは判断できません。理由は3つあります。保守の中身が会社ごとに違うこと、分母である開発費の定義も違うこと、年数が経つほど分母が意味を失うことです。%を使うのは、含まれる作業の一覧をそろえて、同じ内容どうしを比べるときだけにしてください。

Q. 保守契約は必須ですか？

A. 法律上の義務ではありませんが、契約しないという判断は「止まったときに自社で対応する」という意味です。IPAの非機能要求グレードは、サポート契約について「問題が発生した際に必要となる費用が膨大となるため、サポート契約を行ったほうが結果として運用コストは小さくなる場合がある」と述べています（出典：IPA「非機能要求グレード2018」グレード表（保守契約））。切るかどうかではなく、水準を実態に合わせるのが現実的です。

Q. 運用と保守は分けるべき？

A. 契約を分ける必要はありませんが、費用と作業内容は分けて把握してください。経済産業省のモデル取引・契約書では、運用は「業務運用環境で情報システムを稼働して、業務を円滑に遂行するフェーズ」、保守は「情報システムやソフトウェアの現状を業務及び環境に適合するように維持管理を行う工程」と定義されています。混ざったままだと、値上げの理由も、抜けている作業も検証できません。

Q. 保守を止めたらどうなりますか？

A. 障害時の窓口がなくなり、復旧の目標時間も消えます。加えて、次のベンダーは調査から始めるため改修の工数が増え、資料の引き渡し条件を決めていないと移管そのものが難しくなります。中途解約料金が定められている契約もあります。止めるにしても、資料とデータの出力手段を確保してからにしてください。

Q. SLAは必ず結ぶものですか？

A. 義務ではありませんが、水準が数値で書かれていないと「いつ直るのか」に誰も答えられません。経済産業省のモデル契約では、SLA条項はユーザーごとに作成される仕様書の中にサンプルとして規定されており、契約書の本文には出てきません。まず自社の仕様書に相当する書面があるかを確認してください。

Q. 稼働率99.9%は必要ですか？

A. 24時間365日稼働のシステムで99.9%は、年間8.76時間の中断にあたります（出典：IPA「非機能要求グレード2018」グレード表（稼働率））。一方、平日日中しか使わないシステムなら、月に1時間の停止でも99.4%です。必要かどうかは%ではなく、「何時間止まると取り返しがつかないか」から決めてください。

Q. 24時間365日は要りますか？

A. 多くの中小企業では、常時ではなく特定期間だけ水準が必要というのが実態です。IPAの非機能要求グレードでも、休日や月末月初など通常と異なる日を「特定日」として、通常時とは別にレベルを設定する考え方が示されています。まず直近12か月で、夜間や休日に実際に人が動いた件数を数えてください。ゼロなら見直しの余地があります。

Q. 法改正対応は含まれますか？

A. 含めることはできますが、自動的に含まれるわけではありません。経済産業省のモデル契約はアプリケーション保守サービスの説明の中で法律の改正による修正を例として挙げる一方、「どこまでの修正が本件保守業務の対象となるか（新規ソフトウェア開発との境界線）については、受託条件明細等によりその範囲を明確に規定しておく必要がある」と注記しています。軽微な修正と、新機能が必要になる改正を分けて書面化してください。

Q. 改修が毎回別料金なのは普通？

A. 契約次第です。改修の枠が定められていない契約では、改修は都度見積になるのが通常です。問題は金額ではなく、境界線が書面にないことです。まず受託条件明細に相当する書面で、含まれる改良の範囲と量（人日または件数）を確認してください。書かれていないなら、そこを明文化する交渉が先です。

Q. 保守費の値下げ交渉は可能？

A. 可能ですが、順番が重要です。相場の%を根拠にすると交渉は止まります。直近12か月の実績（障害・問い合わせ・改修の件数と時間帯）を示し、使っていない水準を自分で特定して、その項目を下げる形で相談してください。同時に、記載のない復旧目標や定例報告を入れてもらうと、下げるだけの交渉になりません。

Q. ベンダーを変えられますか？

A. 変えられますが、条件があります。設計書とデータ項目定義書があること、データを標準的な形式で出力できること、解約の予告期間と中途解約金を確認していることの3点です。この3つが揃っていない状態で変えると、次のベンダーは調査から始めるため、当初の見積より費用が膨らみます。

Q. 保守の相見積もりは取れる？

A. 取れます。ただし「今と同じ内容で」という依頼では見積は出ません。対象システムの一覧、直近12か月の障害・問い合わせ・改修の実績、必要な受付時間とRTO・RPO、手元にある資料の一覧をまとめて渡してください。この資料は、現在のベンダーへの条件変更の相談にもそのまま使えます。

Q. 自社でできる部分はありますか？

A. あります。実績の集計、資料の整理、社内向けの操作手順のまとめ、簡単な問い合わせの一次受けは自社で担えます。一方、可用性管理（どこまで止まってよいかを決める）は、そもそも委託しても発注側に残る役割です。経済産業省のモデル契約の役割分担表でも、可用性管理・キャパシティ管理・ITサービス継続性管理・ITサービス財務管理は、一部の但し書きを除きユーザー側の担当として整理されています。

Q. クラウドなら保守は不要？

A. 不要にはなりません。ハードウェアの保守や設備の管理は事業者側に移りますが、業務アプリケーションの修正、問い合わせ対応、法改正への対応、利用者管理は残ります。加えて、クラウドの利用料は人の作業費とは別の費用です。請求の中で「利用料」と「作業費」が分かれているかを確認してください。

Q. 何から手を付ければよいですか？

A. 次の3つからです。直近12か月の定例報告書・請求書・依頼履歴を1か所に集めること、契約書に加えて業務仕様書と受託条件明細に相当する書面を取り寄せること、そのシステムが止まったとき何時間で取り返しがつかなくなるかを業務側に聞くこと。この3つが揃えば、金額が妥当かどうかは自社で判断できます。

まとめ

• 保守費用は「開発費の何%」では判断できない。中身も分母も会社ごとに違う
• 公的な定義では運用は「動かし続ける」、保守は「直す・合わせる」で別の工程
• 契約の中身は本文ではなく業務仕様書と受託条件明細に書かれる
• 法改正対応は含められるが、境界線を書面化しないと自動では含まれない
• SLAのサンプルが約束しているのは一次応答であって復旧ではない
• 未達時の標準は返金ではなく改善努力。対応措置は交渉の余地がある
• 稼働率99%は、24時間365日稼働なら年間87.6時間の中断を許す水準
• 必要な水準は「止まったら何時間で困るか」から決める。%から決めない
• 払いすぎと不足は同時に起きる。両方のチェックリストを見る
• 見直しは実績を数える、必要水準を決める、条件を交渉する、最後に金額の順で
• いきなり切らない。資料とデータの出力手段を確保してから動く

保守費用の話は、金額の交渉に見えて、実際には「自社のシステムが止まったとき、どこまで困るのかを自社で決められているか」という問いです。ここが決まっていない限り、高いか安いかは永遠に判断できません。逆に、これが決まっていれば、契約を続けるのも、水準を変えるのも、ベンダーを変えるのも、落ち着いて選べます。

無料相談はこちら（初回のご相談・お見積りは無料です）

参考にした一次情報

• 経済産業省「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第一版〉
• IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開）
• IPA「非機能要求グレード2018」（グレード表・項目一覧・樹系図／2018年4月）
• IPA「非機能要求グレード2018 改訂情報 ～初版との差異～」（2018年4月25日）

システムそのものを替えるかどうかの判断は基幹システム刷新の進め方、委託の契約形態は準委任と請負の違い、要求のまとめ方は要件定義の進め方にまとめています。