保守開発の完全ガイド

「現在の保守ベンダーの対応が遅い」「費用が妥当か分からない」「担当者が辞めたらシステムが止まりそう」——保守開発をめぐる悩みは、属人化・ブラックボックス化・費用の不透明さといった構造的課題から生まれています。年間のIT予算のうち、開発費の10〜20%が保守費用として継続的に発生するため、ここの最適化はそのまま経営インパクトに直結します。

本記事では、保守開発の全体像から進め方、開発会社の選び方、費用相場、発注方法までを横断的に整理し、さらに2026年時点のモダン保守像（AIOps・SRE・マイクロサービス化）、紛争時の法的エスカレーション、中小・情シスゼロ企業向けの「最低限ライン」まで踏み込んで解説します。各論の詳細は子記事に譲り、本記事は意思決定者がプロジェクト全体を俯瞰するためのピラー記事として機能する構成です。

保守開発の全体像

保守開発とは、稼働中システムの安定運用と継続的な改善を担う一連の活動を指します。単なるバグ修正にとどまらず、機能追加・パフォーマンス改善・セキュリティ対応・インフラ更改までを含む広範な領域です。2026年現在は、AIOpsやSREの考え方が浸透し、「壊れたら直す」から「壊れる前に検知して自動回復させる」モダン保守への転換期にあります。

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

一方保守は、障害発生時の原因調査・復旧、仕様変更にともなうプログラム修正、性能改善のためのチューニングなど、システムに変更を加える非定型のサポート業務を指します。技術的判断を要する場面が多く、人的スキル依存度が高いのが特徴です。契約書では「運用・保守」とひとくくりにされがちですが、対応範囲・スキル要件・SLA基準が異なるため、見積取得時には必ず分解して確認することが重要です。

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

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

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

保守開発の進め方

保守開発のプロジェクトは「現状分析→体制判断→ベンダー選定→契約→並走移管→再ロックイン防止」というライフサイクルで進めます。とくに他社が開発したシステムの保守を新規ベンダーに移管するケースでは、引継ぎ期間や初期解析費用が膨らみがちなため、最初のステップ設計が成否を分けます。

最初のフェーズは現状分析です。属人化の度合い、ドキュメントの整備状況、ブラックボックス化したコンポーネントの有無を棚卸しします。具体的には、特定担当者しか触れない領域がどれだけあるか、最終更新から3年以上経過したドキュメントが何割か、外部APIの依存先で公式サポート終了に近いものはないかを点検します。

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

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

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

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

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

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

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

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

モダン保守を提供できるベンダーかどうかは、初回提案で見抜けます。「現在の保守体制から自動化により年◯%削減できる見込みです」と、定量的な改善余地を初回時点で提示できるかが目安です。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シミュレーションが不可欠です。基本式は次の通りです。

①現状の月額保守費（X円）×12ヶ月×契約年数
②乗り換え後の想定月額（Y円）×12ヶ月×契約年数＋初期解析費（Z円）
③回収期間＝Z÷（X−Y）（月数）

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

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

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

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

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

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ベースだから安心とは言い切れず、契約書に「成果物の著作権譲渡」を明記しているかを必ず確認します。

解約交渉がこじれて、現ベンダーがソースコード開示を拒否したり、ドキュメント提供を遅延させたりするケースは実在します。波風を立てないトークでもダメな場合、エスカレーションには段階があります。
①社内法務からの書面通知
②外部顧問弁護士からの内容証明郵便
③第三者仲裁機関（ソフトウェア紛争解決センター等）への申立
④民事訴訟

多くは②の段階で動きが出るため、初期から弁護士に相談ラインを引いておくことが重要です。

セキュリティインシデント発生時の責任分界も契約段階で明文化しておきます。一般的にSLAペナルティの上限は「月額利用料の◯◯%」とされ、賠償額が無制限になることはほぼありません。一方で、セキュリティインシデントの対応遅れが数千万円規模の損害賠償に発展した事例もあるため、サイバーリスクに関する責任配分はSLAペナルティとは別建てで取り決めるのが安全です。

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

確保すべきドキュメントは次の3点に絞れます。
①システム構成図（サーバー・DB・外部API連携の全体図）
②運用手順書（障害時の連絡フロー含む）
③アカウント一覧（パスワード管理含む）

契約書に最低限入れる条項も3点です。
①稼働率目標と未達時の対応
②契約終了時のソースコード・ドキュメント引渡し義務
③成果物の著作権譲渡

この6項目さえ押さえておけば、ベンダーが突然倒産しても、担当者が離職しても、最低限の事業継続性は確保できます。完璧を目指すよりも、致命傷を回避することを優先する考え方です。さらに保守エンジニア側のモチベーション維持にも目を向けると、長期的な品質が安定します。他人が書いたコードの尻拭いになりがちな保守担当者には、新技術習得の機会や、運用自動化への投資権限を与えるなど、キャリアパスを設計したベンダーを選ぶと、エンジニア入れ替わりによる品質低下を防げます。

まとめ

保守開発は「壊れたら直す」労働集約型から、AIOps・SRE・自動化を組み合わせたモダン保守へと大きく転換しています。現状の月額保守費の妥当性に疑問を感じたら、ROIシミュレーションで稟議に通る形に整え、他社製システム引継ぎ実績とAIOps提案力のあるベンダーへの乗り換えを検討する価値は十分にあります。

その際、RFPとSLA/SLOの設計、責任分界の明文化、マイクロサービス化による再ロックイン防止、そして紛争時のエスカレーション手順までを契約段階で準備しておくことで、長期にわたって安定した保守体制を維持できます。中小・情シスゼロ企業であっても、ドキュメント3点と契約条項3点という最低限ラインを押さえれば、致命的なトラブルは大半が回避可能です。本記事と4本の子記事を組み合わせて、自社の保守開発体制を一段引き上げる材料としてご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。