保守開発の完全ガイド

保守開発は、壊れたら直すだけでなく、運用の自動化と継続的な改善まで含めて設計していく取り組みです。進め方から開発会社の選び方、費用相場、発注方法までを、流れに沿って見ていきます。各論の詳細は関連記事で扱っており、この記事は意思決定者がプロジェクト全体を見渡すための入口として読めます。

「保守ベンダーの対応が遅い」「費用が妥当か分からない」「担当者が辞めたらシステムが止まりそう」といった悩みは、属人化やブラックボックス化、費用の不透明さから生まれがちです。

保守費用は、年間のIT予算のうち開発費の10〜20%が継続的に発生します。そのため、保守費の最適化は経営への影響に直結します。

Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

保守開発の全体像

保守開発とは、稼働中のシステムの安定運用と継続的な改善を担う一連の活動を指します。単なるバグ修正にとどまらず、機能追加、パフォーマンス改善、セキュリティ対応、インフラ更改までを含む広い領域です。

2026年現在は、AIOpsやSREの考え方が浸透してきました。「壊れたら直す」保守から、「壊れる前に検知して自動で回復させる」モダン保守へ移る転換期にあります。

「運用」と「保守」の違いとカバー範囲

多くの企業で「運用」と「保守」が混同されていますが、実務ではまったく性質の異なる業務です。運用は、システムを止めずに動かし続けるための定型業務です。サーバーの起動と停止、ログ監視、定期パッチの適用、ネットワークメンテナンスなどが該当し、スケジュールに沿って淡々とこなすルーティン業務といえます。

一方保守は、障害発生時の原因調査と復旧、仕様変更にともなうプログラム修正、性能改善のためのチューニングなど、システムに変更を加える非定型の業務です。技術的な判断を要する場面が多く、人のスキルへの依存度が高いのが特徴です。

契約書では「運用・保守」とひとくくりにされがちです。対応範囲、スキル要件、SLA基準が異なるため、見積もりを取る際は必ず分けて確認します。

モダン保守（AIOps・SRE・自動化）の登場

従来の保守は、人が監視し、人が対応する労働集約型でした。2026年現在の主流は、AIOpsとSRE（Site Reliability Engineering）を組み合わせたモダン保守です。AIOpsは、ログ・メトリクス・トレースをAIが横断して分析し、異常を予兆の段階で検知します。SREは、エラーバジェットやSLI/SLOといった指標で運用品質を定量管理し、自動復旧の仕組みを設計に組み込みます。

「保守費用は毎年同額」が当たり前だった時代から、「自動化提案で年5〜10%の保守費削減を約束する」ベンダーが選ばれる時代へと変わっています。モダン保守を提案できるベンダーは、保守費用を年々下げていく前提で契約に臨みます。具体的には、TerraformやAnsibleでインフラをコード化し、CI/CDで変更を自動デプロイして、PagerDutyやDatadogで自動通知と自動切り戻しを実装します。

▶ 詳細はこちら：保守開発の進め方（No.2190）

保守開発の進め方

保守開発のプロジェクトは、「現状分析→体制判断→ベンダー選定→契約→並走移管→再ロックイン防止」というライフサイクルで進めます。

とくに他社が開発したシステムの保守を新規ベンダーに移管するケースでは、引継ぎ期間や初期解析費用が膨らみがちです。このため、最初のステップの設計が成否を分けます。

現状分析と内製/外注の判断

最初のフェーズは現状分析です。方針を決める前に、属人化の度合い、ドキュメントの整備状況、ブラックボックス化したコンポーネントの有無を洗い出します。

具体的には、特定の担当者しか触れない領域の広さ、最終更新から3年以上たったドキュメントの割合、外部APIの依存先で公式サポート終了が近いものがないかを点検します。

続いて、内製と外注のどちらで保守体制を組むかを判断します。内製は業務理解の蓄積と意思決定の速さに優れる反面、退職や採用難の影響を受けやすい構造です。外注は体制の継続性を確保しやすい一方、ブラックボックス化と費用増のリスクをはらみます。業務の中核となるコア機能は内製、周辺機能は外注とするハイブリッド構成も有力な選択肢です。

新旧ベンダー並走と本番移管

他社製システムを新規ベンダーへ移管する場合は、1〜3ヶ月の並走期間を設けて、段階的に切り替えるのが鉄則です。並走期間中は、旧ベンダーが一次対応を担当しながら、新ベンダーが障害事例とノウハウを吸収していきます。実務上、保守移管全体には3〜6ヶ月、複雑なシステムでは10ヶ月程度を見込むのが現実的です。

移管完了後に見落としがちなのがアカウント引継ぎのセキュリティです。サーバー、データベース、クラウドコンソール、各種SaaSのアカウントを再設定せずに残すと、旧ベンダー関係者がアクセスできる状態が続きます。そのため、全パスワードの強制リセット、不要権限の削除、SSO連携の見直しを、移管直後に一括で行うチェックリストを準備しておくと安全です。

移管の具体的な手順は、関連記事でチェックリストとともに確認できます。

保守開発の開発会社の選び方

保守開発の発注先を選ぶには、新規開発とは異なる評価軸が必要です。新規開発は「作れるか」、保守は「他社のコードを安全に引き取り、長期にわたって伴走できるか」が論点です。選定の基準はここで整理し、企業ごとの具体的な比較は関連記事で確認できます。

他社製システム引継ぎ実績とインシデント対応力

最初に確認すべきは、他社製システムの引継ぎ実績です。新規開発の実績だけが豊富なベンダーは、ドキュメントが不足した状況で他社のコードを読み解く経験に乏しく、移管が長期化しがちです。過去3年の他社製システム移管件数、引継ぎ成功率、最短移管期間といった具体的な数値を確認します。

次に見るべきはインシデント対応の実績です。過去のSLA達成率、平均復旧時間（MTTR）、24/365対応の有無、エスカレーション体制を示せるベンダーは、信頼性が高いと評価できます。逆に、「対応します」「全力でやります」といった精神論しか返ってこないベンダーは、本番障害時に機能しないリスクがあります。

AIOps提案力とマルチベンダー対応

モダン保守を提供できるベンダーかどうかは、初回の提案で見抜けます。「現在の保守体制から、自動化により年◯%削減できる見込みです」と、定量的な改善余地を初回時点で示せるかが目安です。あわせて、AIOpsツールの導入経験、SREチームの組成を支援した実績、IaC（Infrastructure as Code）の本番運用実績も確認します。

さらに、マルチベンダー対応を許容できるかも重要です。保守を一社に全面委託すると再ロックインが起きやすいため、機能別に複数のベンダーへ分けて発注する設計を認められるかを確認します。とくに、マイクロサービスに分割したうえで、フロントエンド、APIゲートウェイ、データベース層をそれぞれ別のベンダーが保守する構成が増えています。

▶ 詳細はこちら：保守開発でおすすめの開発会社（No.2191）

保守開発の費用相場

保守開発の費用は、月額固定の保守費用、追加開発や障害対応のスポット費用、移管時の初期費用の3つで構成されます。一般的な相場は、年間で開発費の10〜20%（控えめに見て5〜15%）です。たとえば、1,000万円で開発したシステムなら、月額50〜150万円の保守費が継続的に発生する計算になります。

規模別の月額レンジと初期費用

小規模なWebサービスや業務システムでは、月額10〜30万円程度の保守費から始まることが多いです。中規模システムでは月額60〜120万円、大規模なエンタープライズ業務基盤では月額200〜500万円超が相場です。24/365対応や即時の駆け付けが必要な場合は、これに3〜5割の上乗せが発生します。

他社製システムを引き継ぐ場合は、月額費用とは別に初期解析費が必要になります。ドキュメントが揃っていれば100万円程度で済むこともありますが、ブラックボックス化が進んでいると300〜800万円の解析費が発生するケースもあります。

最悪のケースとして、第三者のエンジニアがソースコードから設計書を逆生成する「リバースエンジニアリング」を発注すると、1,000万円超に達する事例も存在します。

乗り換えROIシミュレーションの考え方

「保守費が高い気がする」という漠然とした不満を稟議に通る形にするには、定量的なROIシミュレーションが不可欠です。基本式は次の3つです。

1. 現状の月額保守費（X円）×12ヶ月×契約年数
2. 乗り換え後の想定月額（Y円）×12ヶ月×契約年数＋初期解析費（Z円）
3. 回収期間は、初期解析費（Z円）を月額差額（X−Y）で割って求めます。

たとえば、現状月額150万円、乗り換え後想定100万円、初期解析費500万円のケースでは、500÷50＝10ヶ月で初期費を回収でき、以降は年間600万円のキャッシュフロー改善となります。さらに、モダン保守を提案できるベンダーであれば、年5〜10%の継続的な費用低減も加えて計算できます。この試算表をRFP回答時に提出してもらうルールにすると、稟議が通しやすくなります。

稼働頻度の低いコンポーネントは、年間契約からスポット契約への切替も検討する余地があります。月1回しか変更が発生しない領域に毎月20万円を払い続けるより、不具合発生時にスポットで20万円×4回／年に切り替えるほうが安く済むケースは多々あります。

▶ 詳細はこちら：保守開発の費用相場（No.2192）

保守開発の発注・外注方法

保守開発の発注では、新規開発以上に「契約書の文言」が後のトラブルを左右します。RFP（提案依頼書）の精度、SLA（サービス水準合意書）の設計、責任分界点の合意がそろってはじめて、安定した長期パートナーシップが成立します。

RFPとSLA/SLOの設計

RFPには、次の項目を明記します。

• 対象システムの概要と求める保守範囲
• 稼働率目標と対応時間帯
• エスカレーションフロー
• 報告の頻度と形式
• 契約期間と解除条件

情報を出し惜しむと見積もりの精度が落ち、後から想定外の追加費用が発生します。

相見積もりは3〜4社が適正です。それ以上は比較の工数が膨らみすぎて、意思決定が遅れがちです。SLAとSLOの使い分けにも注意が必要です。SLAは契約上の合意でペナルティ条項を伴い、SLOは事業者側の内部目標です。自社のサービス特性に合わせて、どちらが運用しやすいかを設計段階で選びます。

Amazon S3は、月間稼働率95%を下回ると100%返金、99%未満で25%返金、99.9%未満で10%返金という階層的なSLAを公開しており、参考になります。一方、サイボウズは厳密なSLA契約ではなく「SLOとしての目標値」を採用し、別途、連続24時間単位の返金保証規定を併用するハイブリッド構成を取っています。

なお、SLA条項は民法548条の2第1項の定型約款として扱われる可能性があります。「稼働率〇〇%未満で利用料の〇〇%返金」という条項を一方的に変更する場合、インターネット周知などの法的要件を満たす必要があるため、契約改定時には弁護士の確認を入れておくのが安全です。

契約形態と解約交渉の進め方

保守開発の契約形態は、請負契約と準委任契約が中心です。請負は成果物に対して責任を負う形態で、定型的な保守業務に適しています。準委任は業務の遂行に対して責任を負う形態で、仕様変更の頻度が高い保守や調査業務に向いています。両者を混在させる場合は、どの業務がどちらの契約かを明文化しておかないと、後の責任の所在が不明確になります。

近年は第3の選択肢としてラボ型開発も、保守の領域で使われています。チームを一定期間確保し、試行錯誤しながら保守や改修を進める形態で、仕様変更が頻発するプロダクトに適した契約モデルです。

現行ベンダーへの解約通知は、トーンを誤ると引継ぎの協力を得られなくなります。「御社のサービスに不満がある」と伝えるより、「社内の方針変更により保守体制を見直すことになりました」「マルチベンダー化の方針が決まりまして」といった中立的な言い回しを選ぶのが得策です。相手のメンツを潰さないことで、ドキュメント提供やソースコード移管への協力を引き出せます。

▶ 詳細はこちら：保守開発の発注/外注方法（No.2193）

保守開発で失敗しないためのポイント

保守開発で頻発する失敗パターンを事前に押さえておくと、移管後のトラブルを大幅に減らせます。主な論点は、ベンダーロックイン、紛争時のエスカレーション、責任分界、中小・情シスゼロ企業向けの最低限ラインです。

ベンダーロックインとマイクロサービス化での根本回避

ベンダーロックインには2種類あります。コーポレートロックインは、業務仕様を特定ベンダーが独占して把握している状態です。テクノロジーロックインは、独自フレームワークや独自プロトコルへの依存により、他社が触れない状態を指します。ドキュメント不足、属人化、独自技術の採用が重なると、ロックインは必然的に深まります。

従来は、ドキュメントの最新化と業務の標準化で脱却を図りました。根本的に再発を防ぐには、マイクロサービスアーキテクチャへの分割が有効です。モノリシック構造を機能ごとのサービスに切り出し、サービス間をREST APIやgRPCで連携させると、機能別に別のベンダーへ発注しやすくなります。たとえば、フロントエンドはA社、決済はB社、データ基盤はC社という体制を現実的に組めます。

注意点として、OSSを採用してもベンダー側が独自拡張部分の著作権を保持しているケースがあります。OSSベースなら安心とは限らないため、契約書に「成果物の著作権譲渡」を明記しているかを必ず確認します。

紛争時の法的エスカレーションと責任分界

解約交渉がこじれて、現ベンダーがソースコードの開示を拒否したり、ドキュメント提供を遅らせたりするケースは実際にあります。角を立てない話し方でもうまくいかない場合は、エスカレーションに段階があります。

1. 社内法務からの書面通知
2. 外部顧問弁護士からの内容証明郵便
3. 第三者仲裁機関（ソフトウェア紛争解決センター等）への申立
4. 民事訴訟

多くは2つ目の段階で動きが出るため、初期の段階から弁護士に相談する目安を決めておきます。

セキュリティインシデント発生時の責任分界も、契約段階で明文化しておきます。一般的にSLAペナルティの上限は「月額利用料の◯◯%」とされ、賠償額が無制限になることはほぼありません。

一方で、セキュリティインシデントの対応遅れが数千万円規模の損害賠償に発展した事例もあります。そのため、サイバーリスクに関する責任配分は、SLAペナルティとは別建てで取り決めるのが安全です。

中小・情シスゼロ企業向けの最低限ライン

RFPフル作成、厳密なSLA、マルチベンダー化、AIOps導入は理想ですが、情シス担当が兼任1名だったり、そもそも社内にIT人材がいなかったりする中小企業では、現実的に取り組めません。そうした企業向けに、「最低限これだけ押さえれば致命的なトラブルは防げる」というラインを示します。

確保すべきドキュメントは次の3点に絞れます。

1. システム構成図（サーバー・DB・外部API連携の全体図）
2. 運用手順書（障害時の連絡フロー含む）
3. アカウント一覧（パスワード管理含む）

契約書に最低限入れる条項も次の3点です。

1. 稼働率目標と未達時の対応
2. 契約終了時のソースコード・ドキュメント引渡し義務
3. 成果物の著作権譲渡の明記

この6項目を押さえておけば、ベンダーが突然倒産しても、担当者が離職しても、最低限の事業継続性は確保できます。完璧を目指すより、致命傷を回避することを優先する考え方です。

保守エンジニア側のモチベーション維持にも目を向けると、長期的な品質が安定します。他人が書いたコードの尻拭いになりがちな保守担当者に、新技術を学ぶ機会や運用自動化への投資権限を与えるなど、キャリアパスを設計したベンダーを選ぶと、エンジニアの入れ替わりによる品質低下を防げます。

まとめ

保守開発は、「壊れたら直す」労働集約型から、AIOps・SRE・自動化を組み合わせたモダン保守へと大きく転換しています。

現状の月額保守費に妥当性の疑問を感じたら、ROIシミュレーションで稟議に通る形に整えたうえで、他社製システムの引継ぎ実績とAIOps提案力のあるベンダーへの乗り換えを検討する価値は十分にあります。

その際、RFPとSLA/SLOの設計、責任分界の明文化、マイクロサービス化による再ロックイン防止、紛争時のエスカレーション手順までを契約段階で準備しておくことで、長期にわたって安定した保守体制を維持できます。

中小・情シスゼロ企業であっても、ドキュメント3点と契約条項3点という最低限ラインを押さえれば、致命的なトラブルは大半が回避可能です。

本記事と4本の関連記事を組み合わせて、自社の保守開発体制を一段引き上げる材料としてご活用ください。

▼開発を相談する前に読みたい無料ホワイトペーパー。
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。