ITシステムの定期メンテナンスを外部に委託しているものの、「月額の保守費用が本当に妥当なのか分からない」「契約書に何を書けば自社を守れるのか不安」と感じている情報システム部門の担当者は少なくありません。定期メンテナンスは一度契約すると数年単位で固定費として残り続けるため、発注・外注の段階で条件を詰め切れていないと、ブラックボックス化したコストや想定外の追加請求にじわじわと苦しめられることになります。
この記事では、ITシステム定期メンテナンスを発注・外注・依頼・委託する際の具体的な進め方を、契約形態の選び方や見積もりの見極め方、隠れコストの洗い出し方まで踏み込んで解説します。さらに、監視項目の見直しやスクリプト化、クラウド移管、スポット保守への切り替えといった、委託範囲を最適化してコストを適正化する判断軸も紹介します。政府・民間で実際にメンテナンス費用を28.6%削減した事例なども交えながら、発注側が主導権を握って外注先と向き合うためのノウハウをお伝えします。
ITシステム定期メンテナンスの委託範囲と発注の全体像
定期メンテナンスを外注する際にまず押さえておきたいのが、「何を委託するのか」という範囲の定義です。ひとくちに定期メンテナンスといっても、サーバの稼働監視やバックアップ、ログ削除、OSやミドルウェアへのパッチ適用、再起動といった定型的な作業から、計画保守としてのメンテナンスウィンドウの設定、ユーザーへの告知、実施後の報告まで、多岐にわたります。この範囲を曖昧にしたまま発注すると、後から「それは契約外の作業です」と追加費用を請求される温床になります。
定期保守内に含まれる作業と追加費用になる作業の線引き
定期メンテナンスの委託では、月額保守費用の範囲に含まれる作業と、別途見積もりとなる作業の境界線を契約段階で明確にしておくことが何よりも重要です。一般論として、バックアップやログ削除、再起動といった定型作業、障害発生時の一次対応、OSやミドルウェアの軽微なアップデート適用は、月額保守費用の範囲内とされます。一方で、大幅なデザイン変更や新機能追加など、プログラムの根本修正を伴う仕様変更は保守範囲外となり、別途制作作業として追加費用が発生するのがほぼ業界共通の切り分けです。
判断に迷いやすいのが、OSのメジャーアップデートやブラウザの仕様変更、法改正対応、WordPressなどOSSのバージョンアップに起因する不具合への対応です。これらは「定期保守内なのか別途見積なのか」が契約書に書かれていないことが多く、トラブルの火種になります。発注時には、こうしたグレーゾーンの作業について「軽微なものは保守内、一定工数を超える改修は別途見積」といった基準を数値（たとえば月あたりの改修工数の上限）で取り決めておくと、後の認識齟齬を防げます。
自社対応範囲と委託範囲の役割分担を決める
定期メンテナンスをすべて丸投げするのではなく、自社で対応する範囲と委託する範囲を切り分けることで、無駄なコストを抑えられます。たとえば、日常的な監視やアラート確認は自社のクラウド管理画面で行い、専門性が必要なパッチ検証やトラブルシューティングのみを外注する、という役割分担が考えられます。発注前に「誰が・何を・どの時間帯に・どこまで責任を持つか」を一覧化しておくと、外注先との責任分界点が明確になり、SLA（サービスレベル合意）の交渉もスムーズに進みます。
この役割分担を考えるうえで欠かせないのが、現状の事実把握です。たとえば「1日平均300人が利用するシステム」という平均値だけを見て保守体制を組むのではなく、曜日差や時間帯のばらつきといった裏の事実を観察することが、過剰な保守を避ける鍵になります。実際に、PCの定期保守契約を結んでいたものの故障率が低く年数回しか利用していない事実を突き止め、スポット保守契約に切り替えて費用を大幅に低減した政府情報システムの事例もあります。発注前の現状分析が、適切な委託範囲の設計に直結します。
定期メンテナンス委託に適した契約形態の選び方
定期メンテナンスを外注する際の契約形態は、大きく請負契約と準委任契約に分かれます。どちらを選ぶかによって、完成責任の所在や仕様変更への柔軟性、そして法的リスクの負い方が大きく変わるため、自社の保守ニーズに合った形態を選ぶことが発注成功の分かれ目になります。
請負契約と準委任契約の違いと向き不向き
請負契約は、成果物の完成義務と契約不適合責任（旧瑕疵担保責任）を伴う契約形態です。「この機能を完成させて納品する」といった成果が明確なケースに向いており、定期メンテナンスのなかでも特定のバージョンアップ作業や大規模改修など、ゴールがはっきりしている作業を切り出して発注するのに適しています。一方で、完成という結果に責任を負うため、要件が固まっていない段階での発注には向きません。
これに対して準委任契約は、善管注意義務に基づいて業務を遂行する契約形態で、成果物の完成責任は負わないものの、専門家として注意を払って作業する義務を負います。定期メンテナンスのように、月々の状況に応じて軽微な改修や監視、障害対応を柔軟に行う継続的な保守には、要件変更に強い準委任契約が適すケースが多くなります。継続的なアップデートや保守を前提とするなら、まずは準委任を軸に検討するのが現実的です。
SLAと責任分界点を契約書に明記する
契約形態を決めたら、SLAと責任分界点を契約書に具体的に落とし込みます。定期メンテナンスでは、メンテナンスウィンドウ（計画停止を行う時間帯）の事前告知ルール、障害発生時の一次対応の開始時間、復旧目標時間、報告フォーマットなどをサービスレベルとして数値で定義しておくことが重要です。これにより、外注先の対応品質を客観的に評価でき、未達時の対応も交渉しやすくなります。
クラウドやSaaSを利用している場合は、クラウド事業者のSLAが自社要件に合わない場合の対応や、クラウド事業者側の障害でデータ消失や損害が生じた際の責任分界も取り決めておく必要があります。また、ランサムウェアなどのセキュリティインシデント発生時に、調査（フォレンジック）費用や復旧費用、業務停止に伴う損害賠償を保守契約でどこまでカバーするのかも、発注時に確認すべき重要な論点です。保守契約で賄いきれない部分は、サイバー保険で補完する設計を併せて検討すると安心です。
定期メンテナンス費用の見積もりと隠れコストの見極め方
定期メンテナンスを外注する際の費用は、相見積もりを取って比較するのが基本ですが、提示された月額だけを見て判断すると、隠れコストを見落とすことになります。発注側が見積もりの内訳を読み解き、適正な金額かどうかを自ら判断できるようになることが、コスト適正化の第一歩です。
保守費用の相場と内訳割合の目安
保守費用の相場は、初期開発費の年間5〜20%が一つの目安とされ、業界標準は15〜20%程度です。たとえば1,000万円で開発したシステムなら、年間150〜200万円前後が標準的な保守費用となります。システムの種別によっても変動し、基幹システムは年額5,000〜25万円程度、ECアプリは年額10〜15万円程度といった幅があります。自社の保守費用がこの相場感から大きく外れていないかを、まず確認しましょう。
内訳の標準的な割合も把握しておくと、過剰請求を見抜く判定基準になります。一般的には、定期保守・メンテナンスが全体の20〜30%、障害対応が25〜35%、軽微な改修・改善が10〜15%程度とされます。見積もりにこうした内訳が示されておらず一式で計上されている場合は、内訳の開示を求めるべきです。内訳が見えない見積もりは、ブラックボックス化したコストの温床になります。
時間外対応費や更新費用などの隠れコストとTCO
月額の保守費用だけに目を奪われると、時間外対応費や更新費用、トランジション（引き継ぎ）コストといった隠れコストを見落とします。たとえば、夜間や休日のメンテナンス対応に割増料金が設定されているケース、契約更新時に値上げが見込まれるケース、将来ベンダーを切り替える際に発生する膨大な引き継ぎコストなどは、契約時には見えにくい費用です。これらを含めた総保有コスト（TCO）の視点で外注先を評価することが、長期的なコスト適正化につながります。
隠れコストの洗い出しが、実際に大きな削減につながった事例もあります。ある民間企業では、保守費の内訳を精査した結果、利用していないサービスが含まれていることを発見し、月額28万円だった保守費用を20万円まで圧縮しました。これは28.6%の削減で、年間に換算すると96万円のコスト削減になります。見積もりの内訳を一つずつ精査し、本当に必要な作業かどうかを問い直すだけで、これだけの適正化が可能になるのです。
定期メンテナンスの委託先を選定する際のポイント
定期メンテナンスの委託先を選ぶ際は、単に月額が安いかどうかではなく、計画保守を着実に回す体制があるか、運用を効率化する技術力があるか、そして発注側に運用を返してくれる協力的な姿勢があるかを見極めることが大切です。安さだけで選ぶと、属人的な運用やブラックボックス化に陥り、結果的にTCOが膨らむリスクがあります。
自動化・標準化への取り組みで運用効率を見極める
保守費用が高止まりする主な要因は、手作業の多さとシステムのブラックボックス化にあります。優れた委託先は、バックアップやログ削除、再起動、パッチ適用といった定型作業をスクリプト化して自動化し、標準化やドキュメント化によって属人性を排除しています。発注時には、こうした自動化・標準化への取り組み方針を具体的に確認しましょう。「誰がやっても同じ品質で保守が回る」体制を持つ委託先は、長期的に見て運用コストを抑えやすいパートナーです。
ただし、自動化にも保守コストが伴う点には注意が必要です。スクリプトや自動化の仕組み自体を維持・更新するコスト、生成AIで障害予測を行う場合の学習データ整備コストなどは、導入前にシビアに評価しておくべきです。自動化を導入すれば必ず安くなるわけではなく、自動化の仕組みを保守する負担と削減効果を天秤にかけたROIの見極めが、賢い発注には欠かせません。
ベンダーロックインを避け引き継ぎコストを抑える
委託先を選ぶ際は、将来その委託先から離れる場面まで見据えておく必要があります。設計書やソースコード、運用手順書がきちんとドキュメント化され、発注側に共有されているかは、ベンダーロックインを避けるための重要なチェックポイントです。ドキュメントが整備されていない委託先に依存すると、いざ切り替えようとした際に膨大な引き継ぎコストが発生し、実質的に身動きが取れなくなります。
内製化への移行や新ベンダーへの運用移管を見据えるなら、契約時にドキュメントの整備・引き渡し義務を明記し、非協力的なベンダーに陥らないよう牽制しておくことが有効です。設計書やソースコードのバージョンを一元管理し、変更理由や履歴を追跡できる変更管理の体制を持つ委託先であれば、トランジションの際もスムーズに引き継ぎが進みます。こうした観点を含め、発注前に開発会社の選び方を体系的に押さえておくことをおすすめします。詳しくはITシステム定期メンテナンスのおすすめ会社比較の記事も参考にしてください。
委託範囲を最適化してコストを適正化する判断軸
定期メンテナンスの委託は、一度契約したら終わりではありません。監視項目の見直しやスクリプト化、クラウドへの移管、スポット保守への切り替えといった選択肢を持ち、定期的に委託範囲を最適化していくことで、コストを適正な水準に保てます。発注後も継続的に判断軸を持って委託内容を見直す姿勢が、高止まりを防ぐ最大の防波堤になります。
監視項目見直し・スクリプト化・クラウド移管の判断
委託範囲を最適化する第一歩は、現在の監視項目が本当に必要かどうかを見直すことです。過剰な監視は、その分のコストを生み続けます。実際に、ある政府情報システムでは、CPU使用率が低い過剰なサーバを、稼働率が50%を超えない範囲で停止し、複数のテスト環境を統合・廃止することで運用コストを削減しました。利用実績というデータに基づいてインフラを最適化することで、委託する保守作業そのものを減らせます。
定型作業をスクリプト化して自動化すること、そしてクラウドへ移管してOSやミドルウェアのメンテナンスをクラウド事業者に移すことも、委託範囲を縮小する有効な手段です。クラウドを活用すれば、これまで外注していたパッチ適用やインフラ保守の一部を事業者に移管でき、自社が委託すべき作業を絞り込めます。どの作業を自動化・移管し、どの作業を引き続き委託するのかを、コスト削減効果と運用リスクのバランスで判断することが重要です。
スポット保守切替と第三者保守のセキュリティ担保
定期保守契約を結んでいても、実際の利用頻度が低ければ、スポット保守契約への切り替えを検討する価値があります。前述のPC保守の事例のように、年に数回しか保守を利用していない実態を把握できれば、必要なときだけ依頼するスポット契約に切り替えることで、固定費を大幅に圧縮できます。判断の鍵は、契約の前提となっている利用頻度の想定と、実際の利用実績のギャップを正確に把握することです。
メーカー保守が切れた機器（EOSL）については、第三者保守を活用してコストを削減する選択肢もあります。実際に、約50台の物理サーバについてメーカー直接保守ではなく第三者保守に切り替えた政府情報システムの事例があります。ただし第三者保守では、メーカー製のセキュリティパッチが提供されなくなる点に注意が必要です。パッチが提供されない場合の脆弱性リスクをどう担保・評価するかをセットで検討し、必要なら代替の緩和策を講じたうえで切り替えを判断しましょう。費用面の詳細な相場感はITシステム定期メンテナンスの費用相場の記事でも解説しています。
定期メンテナンス費用の経理処理と契約上の留意点
定期メンテナンスの発注では、費用の経理処理をどう扱うかも見落とせない論点です。同じメンテナンス費用でも、内容によって修繕費として期間費用にできるか、資本的支出として資産計上が必要かが変わるため、発注内容と経理処理の関係を理解しておくと、社内の予算化や決裁がスムーズに進みます。
修繕費と資本的支出の切り分け
税務上、障害の除去や現状維持を目的とした修正は「修繕費」として、その期の費用に計上できます。定期メンテナンスのうち、バグ修正や障害対応、現状維持のための保守作業は、基本的に修繕費として処理されるのが一般的です。一方で、新機能の追加や性能の向上を伴う改修は「資本的支出」として資産計上が必要になり、減価償却を通じて費用化していくことになります。発注する作業がどちらに該当するかを意識して見積もりを取ると、経理処理の見通しが立てやすくなります。
資本的支出として資産計上する際には、「既存部分の除却」という視点を持つと費用処理の幅が広がります。改修によって既存の機能の一部が作り替えられる場合、建物の一部を取り壊して建て直すのと同様に、「既存の資産計上部分は除却された」と捉えれば、その部分を費用として処理できるという法務・経理上の考え方です。発注内容を経理担当と共有しておくことで、こうした処理の余地を見落とさずに済みます。
公正な調達のための社内体制づくり
定期メンテナンスの委託先を選定する調達プロセスでは、特定の立場の担当者だけで判断すると、意思決定に偏りが生じやすくなります。技術担当だけで決めると技術的な観点に、コスト担当だけで決めると価格面に偏りがちです。会計担当と技術担当など、異なる立場の職員がそれぞれの視点から要件を検討し、公正に意見交換することで、自社にとって本当に適切な調達が実現します。
相見積もりを比較する際も、複数の立場から評価軸を持ち寄ることが大切です。料金体系の妥当性、サービス内容の自社適合性、SLAの水準、ドキュメント整備の有無といった項目を一覧で比較し、価格だけでない総合的な判断を行いましょう。発注前の準備段階で進め方を体系的に整理しておきたい場合は、ITシステム定期メンテナンスの進め方の記事や、全体像を俯瞰できるITシステム定期メンテナンスの完全ガイドも併せて確認すると理解が深まります。
まとめ
ITシステムの定期メンテナンスを発注・外注・委託する際は、まず委託範囲を明確に定義し、定期保守内に含まれる作業と追加費用になる作業の線引きを契約段階で取り決めることが出発点になります。契約形態は、柔軟な保守を前提とするなら準委任を軸に検討し、SLAや責任分界点、インシデント時のコスト負担まで契約書に落とし込んでおくことが、後のトラブルを防ぐ鍵です。
費用面では、初期開発費の年5〜20%という相場感や内訳割合を物差しに、時間外対応費や更新費用、引き継ぎコストといった隠れコストまで含めたTCOで判断することが重要です。発注後も、監視項目の見直しやスクリプト化、クラウド移管、スポット保守や第三者保守への切り替えといった判断軸を持ち続けることで、月額28.6%の削減に成功した事例のように、コストを継続的に適正化できます。発注側が主導権を持って委託内容を見直す姿勢こそが、定期メンテナンスを高止まりさせない最大の防波堤になります。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。