保守運用（運用保守）契約の選び方｜SLA・障害対応・リリース頻度の書き分け

システム開発が完了し、本番稼働を迎える際に最も重要なのが「保守運用契約」の設計です。保守運用の内容は、システムの安定稼働だけでなく、将来的な拡張性やランニングコストに直結します。しかし、多くの現場では「何が含まれていて、何が含まれていないのか」が曖昧なまま契約が締結され、障害発生時にトラブルになるケースが後を絶ちません。

本記事では、IT実務者の視点から、SLA（サービス品質保証）の設定基準、障害対応のレベル分け、リリース頻度に応じた契約の書き分け方について、具体例を交えて詳しく解説します。

保守運用契約（運用保守）の定義と重要性

まず整理すべきは、「保守」と「運用」という言葉の使い分けです。これらが混同されると、見積もりや作業範囲の齟齬に繋がります。

保守と運用の違い：実務上の役割分担

• 運用（Operations）: システムを日々「動かし続ける」ための定常作業です。バックアップの実行、バッチ処理の監視、アカウントの発行・削除、ログの確認などが含まれます。
• 保守（Maintenance）: システムを「修理・改善する」ための非定常作業です。プログラムのバグ修正、OSやミドルウェアのセキュリティパッチ適用、ハードウェアの故障対応などが該当します。

最近では、これらを一体化した「運用保守」として契約することが一般的ですが、作業項目ごとに「誰が」「いつ」実施するのかを定義書（SOW：作業範囲記述書）に明記することが不可欠です。

契約形態の種類（準委任契約 vs 請負契約）

保守運用契約の多くは「準委任契約」となります。これは、特定の成果物（完成したプログラムなど）に対して責任を負うのではなく、一定の善管注意義務を持って業務を遂行することに対して対価を支払う形式です。対して、特定の不具合修正や機能追加を「完了」させることを約束する場合は「請負契約」となることがありますが、未知の障害に対応する保守業務の性質上、準委任契約が合理的です。

関連記事：SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

SLA（サービス品質保証）策定のポイント

SLA（Service Level Agreement）は、ベンダーが提供するサービスの品質基準を数値で定義したものです。基準が高ければ高いほど、ベンダー側の待機工数やインフラ構成（冗長化）のコストが跳ね上がります。

サービス稼働率の計算式と目標設定の目安

稼働率は以下の計算式で算出されます。

稼働率（%） = （月間総時間 – 累計ダウンタイム） ÷ 月間総時間 × 100

「100%稼働」は技術的に不可能であり、SLAに記載されることはありません。一般的には99.9%を基準とし、それ以上の高可用性を求める場合は、AWSやAzureなどのクラウドサービス自体のSLAも加味した設計が必要です。

RTO（目標復旧時間）とRPO（目標復旧時点）の定義

稼働率とセットで決めるべきなのが、災害や大規模障害時の復旧基準です。

• RTO（Recovery Time Objective）: 障害発生から「何時間以内に復旧させるか」。
• RPO（Recovery Point Objective）: 「いつの時点のデータまで戻すか」。例えば、1日1回のバックアップならRPOは最大24時間となります。

SLA未達時のペナルティ（返金規定）の現実解

SLAを下回った場合、月額保守費用の5%〜10%程度を減額する条項を入れることがあります。ただし、これはベンダーへの罰則というよりも「サービス品質を維持するためのインセンティブ」として機能させるべきです。過度なペナルティは、見積もり金額の高騰を招きます。

障害対応体制の書き分けとレベル設定

すべての障害に対して即時対応を求めるのは非効率です。障害の影響度に応じて「優先度」を定義し、対応時間を書き分けます。

インシデントの優先度（Severity）の分類例

1. 優先度1（緊急）: システムの全停止、重要データの損壊。業務が完全に継続不能。
2. 優先度2（重要）: 主要機能の一部制限。代替策（ワークアラウンド）はあるが、業務に大きな支障がある。
3. 優先度3（通常）: 軽微な表示崩れや、頻度の低い機能の不具合。業務への影響は限定的。

1次回答時間と根本解決時間の目標値

契約書には「検知から◯分以内に1次回答（状況報告）を行う」という項目を入れます。24時間365日の監視が必要な場合、ベンダーはシフト制の監視体制（MSP）を組む必要があるため、コストは平日日中対応の3倍〜5倍になることも珍しくありません。

関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

リリース頻度と運用負荷の関係

現代のシステム開発では、一度作って終わりではなく、継続的に改善を行う「アジャイル型」の運用が主流です。これに伴い、保守契約の内容もリリース頻度に合わせる必要があります。

定常リリースと随時リリースのコスト差

月に1回の定常リリースであれば、ベンダー側も人員計画を立てやすいため、月額費用内に含めやすいです。一方、週に数回、あるいは毎日リリースを行う場合は、デプロイ作業や回帰テストの工数が膨大になります。この場合、「月◯回までのリリース作業を含む」といった上限設定を行うか、作業時間ベースの清算（工数枠）を設けるのが適切です。

CI/CDパイプライン導入による運用自動化のメリット

手動でのリリース作業はヒューマンエラーの温床となります。GitHub ActionsやAWS CodePipelineなどを用いたCI/CD（継続的インテグレーション/継続的デプロイ）を構築することで、リリース工数を削減し、保守費用を抑えることが可能です。
公式ドキュメント参照：GitHub Actions 公式ドキュメント

【比較表】保守運用サービスのタイプ別特徴

自社のシステム規模や予算に合わせて、適切なタイプを選択してください。

保守運用コストを最適化する5つのチェックリスト

最後に、無駄なコストを削りつつ、必要な品質を確保するためのチェックリストを紹介します。

1. 不要な24/365対応を外す

夜間や休日にユーザーが利用しないシステムであれば、平日9:00〜18:00の対応で十分です。これだけで保守費用を大幅に削減できます。夜間は自動アラートの検知のみを行い、対応は翌営業日とする「準夜間対応」という選択肢もあります。

2. ドキュメント更新の責任を明確にする

開発時のドキュメントが更新されず、数年後に「誰も中身がわからない」ブラックボックスになることは非常に多いです。「設定変更時は、2週間以内に構成図と手順書を更新する」といった文言を契約に含めるべきです。

3. アカウント管理の自動化による工数削減

入退社に伴うID発行・削除作業は、地味に運用工数を圧迫します。Entra ID（旧Azure AD）やOktaなどのIDプロバイダ（IdP）を活用し、プロビジョニングを自動化することで、運用負荷を下げることが可能です。

関連記事：SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

4. 監視ツールの選定とライセンス費用

監視ツール（Datadog, New Relic等）は高機能ですが、ログの量に応じて費用が高騰します。必要なメトリクスを絞り、コストパフォーマンスの良い監視設計をベンダーに提案してもらうことが重要です。
公式料金参照：Datadog 料金ページ

5. 年次での契約見直しとパフォーマンス評価

保守運用は一度契約したら終わりではありません。年間の障害発生件数、SLAの達成状況、作業工数の実績を確認し、翌年の契約内容（人員配置や金額）を最適化し続ける姿勢が、ITコスト適正化の鍵となります。

まとめ：自社に最適な保守運用契約を結ぶために

保守運用契約は、自社のビジネスを守るための「保険」であると同時に、システムの進化を支える「土台」でもあります。SLAや障害対応レベルを、システムの重要度に応じて正しく書き分けることで、過剰投資を防ぎながら、守るべきサービス品質を維持できます。

ベンダーとの契約交渉時には、本記事で紹介した稼働率の考え方や、優先度の定義をぜひ参考にしてください。実務に即した具体的な定義こそが、長期的なパートナーシップとシステムの安定稼働を実現します。