ITシステムの定期メンテナンスを外注するには、まず委託範囲を定め、次に契約形態と見積もりを検討し、最後に委託先を選ぶという流れになります。
定期メンテナンスは数年単位の固定費として残るため、発注前に条件を詰めておかないと、ブラックボックス化したコストや追加請求に悩まされることになります。
- 委託範囲：契約前に、委託する作業の範囲と責任分界点を明確にしておく
- 見積もりの内訳：費用の内訳と追加請求の条件を、見積もりの段階で確かめる
- 見直しの基準：監視・自動化・クラウド移管について、判断の基準を整理しておく
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム定期メンテナンスの委託範囲と発注の全体像
定期メンテナンスの外注では、まず「何を委託するのか」という範囲を定義しておく必要があります。作業の種類は多岐にわたり、定型的な作業には稼働監視、バックアップ、ログ削除があります。
さらに、OSやミドルウェアへのパッチ適用や再起動も定型作業に含まれます。計画保守には、メンテナンスウィンドウの設定、ユーザーへの告知、実施後の報告があります。この範囲を曖昧にしたまま発注すると、後になって「それは契約外の作業です」と言われ、追加費用を請求される温床になります。
定期保守内に含まれる作業と追加費用になる作業の線引き
定期メンテナンスを委託する際は、月額保守費用に含まれる作業と別途見積もりになる作業の境界を、契約前に決めておく必要があります。一般的には、バックアップやログ削除、再起動といった定型作業や、障害発生時の一次対応は、月額保守費用の範囲内とされます。OSやミドルウェアの軽微なアップデート適用も、範囲内に含まれます。
一方で、大幅なデザイン変更や新機能追加など、プログラムの根本修正を伴う仕様変更は保守範囲外で、別途制作作業として追加費用が発生するのが、ほぼ業界共通の切り分けです。判断に迷いやすいのは、OSのメジャーアップデートやブラウザの仕様変更への対応です。法改正対応や、WordPressなどOSSのバージョンアップに起因する不具合への対応も、判断が分かれやすい作業です。
こうした作業は、定期保守内か別途見積もりかが契約書に書かれていないことが多く、トラブルの火種になりがちです。そこで発注時には、グレーゾーンの作業を数値の基準で取り決めておくと、後の認識のずれを防げます。たとえば、軽微な改修は保守内とし、月あたりの改修工数が一定の上限を超えたら別途見積もりとする、といった決め方が考えられます。
自社対応範囲と委託範囲の役割分担の決め方
定期メンテナンスは、自社で対応する範囲と委託する範囲に切り分けておくと、無駄なコストを抑えやすくなります。役割分担は、次の順で決めていくと進めやすくなります。
- 現状の把握：「1日平均300人が利用するシステム」のような平均値だけでは実態とずれることがあるため、曜日や時間帯のばらつきを観察して、過剰な保守を避けます。
- 作業の切り分け：日常的な監視やアラート確認は自社のクラウド管理画面で行い、専門性が必要なパッチ検証やトラブルシューティングだけを外注する形が考えられます。
- 責任の範囲：どの作業を誰が、いつ、どこまで責任を持つかを一覧にすると、責任分界点がはっきりし、SLA（サービスレベル合意）の交渉も進めやすくなります。
実際に、ある政府情報システムでは、PCの定期保守契約を結んでいたものの、故障率が低く年に数回しか利用していない事実を突き止めました。そのうえで、スポット保守契約に切り替え、費用を大幅に減らしています。このように、発注前の現状分析は、適切な委託範囲の設計に直結します。
定期メンテナンス委託に適した契約形態の選び方
定期メンテナンスを外注する際の契約形態は、大きく請負契約と準委任契約に分かれます。どちらを選ぶかで、完成責任の所在や仕様変更への柔軟性、法的リスクの負い方が大きく変わります。そのため、自社の保守ニーズに合った形態を選ぶことが、発注の成否を分けます。
請負契約と準委任契約の違いと向き不向き
請負契約は、成果物の完成義務と契約不適合責任（旧瑕疵担保責任）を伴う契約形態です。「この機能を完成させて納品する」といった成果が明確なケースで用いられます。一方で、完成という結果に責任を負うため、要件が固まっていない段階での発注には向きません。
請負契約は、定期メンテナンスのなかでも特定のバージョンアップ作業や大規模改修など、ゴールがはっきりした作業を切り出して発注する場合に適しています。これに対して準委任契約は、善管注意義務に基づいて業務を遂行する契約形態です。完成責任は負わないものの、専門家として注意を払って作業する義務を負います。
定期メンテナンスは、月々の状況に応じて軽微な改修や監視、障害対応を柔軟に行う継続的な保守です。そのため、要件変更に強い準委任契約が適するケースが多くなります。継続的なアップデートや保守を前提とするなら、まずは準委任を中心に検討するのが現実的です。
契約書におけるSLAと責任分界点
契約形態が決まったら、SLAと責任分界点を契約書に具体的に落とし込む必要があります。定期メンテナンスでは、サービスレベルを数値で定義しておくことが欠かせません。対象になるのは、計画停止の告知、障害時の初動、復旧の3つの場面です。
- メンテナンスウィンドウ：計画停止を行う時間帯の事前告知ルール
- 一次対応の開始：障害発生時に、一次対応を始めるまでの時間
- 復旧目標：障害からの復旧を目指す時間
報告フォーマットも、あわせて定めておくとよいでしょう。数値があれば、外注先の対応品質を客観的に評価でき、未達だった場合の対応も交渉しやすくなります。
クラウドや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%の削減に成功した事例のように、コストを継続的に適正化できます。
発注側が主導権を持って委託内容を見直す姿勢が、定期メンテナンスを高止まりさせないためにもっとも大切です。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。