Webシステム保守の外注でSLA確認が必須な理由｜契約後トラブルを防ぐために

Webシステム保守を外注すると、自社で保守要員を常時抱えるよりも、体制やコストを最適化しやすいケースがあります。ただし、契約内容が曖昧なまま委託すると、障害発生時の初動、対応範囲、追加費用、解約時の引き継ぎなどで認識違いが起こりやすくなります。

特に見落とされやすいのがSLA（Service Level Agreement：サービスレベル合意）です。「保守をお願いしているから、当然ここまで対応してくれるはず」という期待は、書面に落ちていなければ契約上の根拠になりません。

本記事では、Webシステム保守の外注先を選ぶ際に、契約前に確認したい5つのSLA項目をわかりやすく整理します。あわせて、保守契約書・SLA・解約条項・責任範囲の見方、比較時のチェックポイントも解説します。

SLA（サービスレベル合意）とは？保守契約における位置づけ

SLAとは、サービス提供者と利用者の間で、提供されるサービスの品質・範囲・目標水準を明文化した合意内容を指します。Webシステム保守では、主に次のような事項がSLAの対象になります。

• 障害発生時の応答時間・復旧目標時間
• 対応時間帯（平日営業時間内、土日含む、24時間365日など）
• 監視対象・保守対象の範囲
• 稼働率の目標値
• SLA未達時のサービスクレジットや補償条件

なお、SLAは単独で存在する場合もありますが、実務上は保守契約書の別紙・付属書として扱われることが多くあります。重要なのは、SLAの内容が契約書本体に組み込まれ、契約上の効力を持つ形になっているかです。

SLA未確認で起こりやすい3つのトラブル

SLAを十分に確認せずに契約すると、次のようなトラブルが起こりやすくなります。

• 障害時の対応が想定より遅い
  「緊急時は対応可能」と説明されていても、実際には夜間は受付のみで、作業着手は翌営業日だったというケースがあります。
• 保守範囲外として追加費用が発生する
  CMS更新後の不具合、SSL証明書更新、バックアップ復元などが別料金扱いになることがあります。
• 解約時にコードや設定情報の引き継ぎで揉める
  ソースコード、設計書、サーバー設定、ドメイン管理情報などの帰属や返却条件が曖昧だと、乗り換え時に支障が出ます。

これらは珍しい例外ではなく、「契約書に何が書いてあるか」で結論が決まる典型的な論点です。口頭説明や提案資料だけで判断せず、契約書・SLA・別紙をセットで確認することが重要です。

保守契約書・SLA・見積書の違い

書類	主な内容	確認ポイント
保守契約書	契約期間、料金、解約条件、責任範囲、損害賠償など	法的拘束力の中心。最優先で確認
SLA（別紙・付属書）	応答時間、復旧目標、対応時間帯、稼働率、補償条件など	契約書と一体化しているか確認
見積書・提案書	費用内訳、作業内容、提案体制など	参考資料として有用だが、契約条項そのものではない場合がある

特に、SLAが別紙になっている場合は、契約書に「本契約と別紙は一体をなす」などの文言があるかを確認しましょう。これが曖昧だと、SLAの扱いが不明確になるおそれがあります。

【SLA確認①】障害発生時の応答時間と復旧目標時間を数値で確認する

Webシステム保守で最初に確認すべきなのは、障害発生時に「どれくらいで反応し」「どれくらいで復旧を目指すのか」です。ここが曖昧だと、緊急時に期待と現実が大きくずれます。

応答時間と復旧目標時間は別物

保守SLAでは、少なくとも次の2つを分けて確認してください。

• 応答時間（First Response Time）
  障害連絡を受けて、受付・一次回答・調査開始の連絡が返るまでの時間
• 復旧目標時間（Target Restore Time / Resolution Target）
  サービスを利用可能な状態へ戻す目標時間

「30分以内に応答」と書かれていても、それは復旧を意味しません。実務では、一次回答は早いが、復旧は「ベストエフォート」とされている契約もあります。応答時間だけでなく、復旧目標時間やエスカレーション条件まで確認することが大切です。

24時間365日対応の意味を具体的に確認する

「24時間365日対応」という表現は、会社によって実態が大きく異なります。以下のどこまで含むのか、必ず書面で確認してください。

• 自動監視のみ
• 電話・メール受付のみ
• 一次切り分けまで実施
• 夜間・休日も実作業に着手
• 重大障害時はオンコール体制で即時対応

たとえば、夜間は受付だけで、実際の復旧作業は翌営業日開始という契約もあります。「24時間受付」と「24時間復旧対応」は別物として見てください。

対応体制	一般的な内容	向いているケース
営業時間内対応	平日昼間のみ受付・対応	社内向けシステム、停止許容時間が長いサイト
拡張時間対応	平日夜間や土日一部まで対応	BtoBサービス、予約受付サイトなど
24時間365日監視・対応	自動監視＋オンコールまたは常時体制	EC、予約、会員基盤、決済連携など停止影響が大きいシステム

なお、保守費用の相場はシステム規模、監視範囲、夜間体制、クラウド構成、セキュリティ要件で大きく変動します。固定的な金額目安は誤解を生みやすいため、必ず複数社から同条件で見積もりを取り、体制とSLAの中身で比較してください。

緊急度レベル別に時間が定義されているか

すべての障害に同じ対応時間を設定するのは現実的ではありません。一般的には、重大度に応じて優先度を分けます。

優先度	例	確認したい項目
P1 / 緊急	サイト全停止、決済不能、ログイン不能	応答時間、作業開始時間、復旧目標時間
P2 / 高	主要機能の一部停止、広範囲の表示不具合	当日中の切り分け有無、暫定対応可否
P3 / 中	一部ユーザーに影響する不具合	営業日ベースの対応期限
P4 / 低	軽微修正、改善要望、文言変更	定例対応か個別見積もりか

中小企業のWebシステムでも、少なくともP1障害については、「何分以内に一次応答」「何時間以内に復旧を目指すか」を明文化しておくと安心です。数値はシステムの重要度や予算で変わるため、一律の正解はありませんが、売上や受付業務に直結するシステムでは厳しめに設定すべきです。

※RTO（目標復旧時間）やRPO（目標復旧時点）は本来、事業継続計画やバックアップ設計とも関係します。重要システムでは、SLAだけでなくBCP・DR方針も含めて確認してください。

【SLA確認②】保守対応範囲と除外事項を明文化する

保守契約で最も揉めやすいのが「どこまでが保守対象か」です。月額固定費の安心感がある一方で、実際には対象外が多い契約もあります。

どのレイヤーまで保守対象かを確認する

Webシステムは複数のレイヤーで成り立っています。次のように分けて確認すると、抜け漏れを防ぎやすくなります。

• インフラ層：クラウド、OS、Webサーバー、DB、ミドルウェア
• ネットワーク・ドメイン層：DNS、ドメイン更新、SSL/TLS証明書
• アプリケーション層：CMS本体、プラグイン、独自開発コード
• セキュリティ層：脆弱性対応、WAF設定、マルウェア検知
• バックアップ層：取得頻度、保存期間、復元対応、復元テスト

たとえば、サーバー監視は対象でも、アプリケーション不具合は対象外という契約は普通にあります。逆に、アプリ改修は含まれても、ドメイン更新や証明書更新は顧客側責任というケースもあります。

SSL/TLS証明書更新、ドメイン更新、バックアップ復元は、実務で見落としやすく、障害時の影響が大きい項目です。対象かどうか、通知義務があるか、誰が費用を負担するかまで確認しましょう。

免責条項で見落としやすいポイント

契約書には、保守対象外や免責事由が記載されています。代表例は次のとおりです。

• 顧客の誤操作や設定変更による障害
• 第三者サービスの障害（クラウド基盤、決済、外部APIなど）
• 自然災害、停電、通信事業者障害などの不可抗力
• 対象外ソフトウェアや未承認プラグインに起因する不具合
• メジャーバージョンアップ後の互換性問題

免責自体は珍しくありませんが、問題は範囲が広すぎることです。たとえば「第三者サービス起因はすべて対象外」とだけ書かれていると、実際には多くの障害が対象外になり得ます。

そのため、「対象外でも、検知・通知・一次切り分け・ベンダーへの連携はしてくれるのか」まで確認するのが実務的です。

保守と追加開発の境界線を決めておく

「不具合修正は保守」「機能追加は別料金」という整理は一般的ですが、境界が曖昧だとトラブルになります。以下のような質問を契約前に投げておくと、実態が見えやすくなります。

• CMSやプラグイン更新後の不具合修正は月額内か
• テキスト・画像差し替えは何回まで含まれるか
• フォーム項目追加や通知先変更は保守か改修か
• 月額内で対応できる工数上限はあるか
• 超過時の時間単価や最低請求単位はどうなるか

「月額固定費に何時間分の作業が含まれるか」を明記してもらうと、追加費用のトラブルを減らしやすくなります。

【SLA確認③】稼働率保証（アップタイム）とSLA未達時の補償条件を確認する

「99.9%稼働保証」と書かれていても、その意味を具体的に理解していないと判断を誤ります。稼働率は、許容される停止時間に置き換えて考えることが大切です。

稼働率ごとの停止時間の目安

以下は、単純計算による一般的な目安です。

稼働率	年間停止時間の目安	月間停止時間の目安
99%	約87.6時間	約7.3時間
99.5%	約43.8時間	約3.65時間
99.9%	約8.76時間	約43.8分
99.95%	約4.38時間	約21.9分
99.99%	約52.6分	約4.38分

ECサイト、予約システム、会員サイトなどでは、99%では停止許容が大きすぎる場合があります。一方、社内向けの補助システムなら、コストとの兼ね合いで許容できることもあります。

大切なのは「高い数字かどうか」ではなく、自社の事業影響に対して妥当かどうかです。

SLA未達時の補償は「返金」ではなくサービスクレジットが一般的

クラウドや保守サービスのSLAでは、未達時の補償として「サービスクレジット」が定められていることが一般的です。これは翌月以降の利用料から差し引く方式で、現金返金ではない場合があります。

確認したいポイントは次の3つです。

• 補償の形式：現金返金か、サービスクレジットか
• 補償の上限：月額料金の何％までか
• 申請条件：申請期限、証跡、申請方法

実務上、SLA補償は「実損害の穴埋め」ではなく、あくまで契約上の限定的な救済にとどまることが多いです。売上損失や信用毀損まで十分に補填されるとは限りません。そのため、損害賠償条項や保険の検討も必要になります。

計画メンテナンスや第三者障害の扱いも確認する

稼働率の計算では、計画メンテナンスや第三者サービス障害が除外されることがあります。これは一般的な取り扱いですが、除外範囲が広すぎると、SLAの実効性が下がります。

• 計画メンテナンスは何日前までに通知されるか
• 実施時間帯は深夜・休日か
• クラウド基盤障害は除外か
• CDN、DNS、決済、メール配信など外部サービス障害は除外か
• 稼働率は月次計測か年次計測か

除外事由が多いほど、見かけ上の稼働率は高く見えます。「何がカウント対象外か」を読まずに稼働率の数字だけで判断しないことが重要です。

【SLA確認④】責任範囲と損害賠償の上限を把握する

障害やセキュリティ事故が起きたとき、どこまでがベンダー責任で、どこからが自社責任かを明確にしておかないと、初動が遅れたり、補償の期待が外れたりします。

責任分界点を曖昧にしない

責任分界点は、保守対象や運用体制に応じて決まります。代表的な整理は以下のとおりです。

領域	ベンダー側の責任例	自社側の責任例
インフラ	監視、設定変更、障害切り分け	クラウド契約主体、利用料支払い
アプリケーション	既存仕様内の不具合修正	仕様変更の判断、要件承認
データ	バックアップ取得・復元支援	入力内容の正確性、誤削除の防止
セキュリティ	パッチ適用、監視、初動連絡	ID管理、権限管理、社内運用ルール
外部サービス	障害通知、一次切り分け、連携支援	外部サービス契約管理

第三者サービス障害そのものはベンダー責任外でも、検知・通知・回避策提案までは期待できる場合があります。そこを契約上どう位置づけるかが重要です。

損害賠償の上限（cap）は必ず確認する

多くの保守契約では、損害賠償額に上限が設けられています。よくある例は次のとおりです。

• 直近1か月分の保守料金を上限とする
• 直近12か月分の支払総額を上限とする
• 直接かつ通常の損害のみ対象とし、逸失利益は除外する

これ自体は珍しい条項ではありませんが、ECや予約システムのように停止損失が大きい場合は、自社リスクに対して上限が低すぎることがあります。

「SLAがあるから安心」ではなく、「SLA未達や事故時に、実際どこまで補償されるか」まで確認することが必要です。

情報漏えい・セキュリティ事故時の対応義務も確認する

個人情報を扱うWebシステムでは、セキュリティ事故時の報告・調査・再発防止の役割分担も重要です。日本の個人情報保護法では、一定の漏えい等事案について、個人情報保護委員会への報告や本人通知が必要になる場合があります。

ただし、法令上の報告義務主体と、委託先ベンダーの契約上の協力義務は別の論点です。契約では次の点を確認しましょう。

• 事故検知後、何時間以内に報告するか
• ログ保全や原因調査を誰が担うか
• フォレンジック調査費用の負担はどうするか
• 対外説明や本人通知にどこまで協力するか
• 再発防止策の提示期限はあるか

個人情報を扱う場合は、保守契約とは別に、個人データの取扱いに関する委託条項や情報セキュリティに関する覚書を整備するのが望ましいです。

※個人情報保護法や漏えい対応は、事案の内容により判断が分かれます。最新の法令・ガイドライン・個人情報保護委員会の公表資料を確認し、必要に応じて弁護士や専門家へ相談してください。

【SLA確認⑤】契約解除・乗り換え時の資産引き渡し条件を確認する

契約時には見落としがちですが、解約時の条件は非常に重要です。乗り換え時に必要な情報や資産が引き継がれないと、システム移行が大きく遅れることがあります。

自動更新と解約予告期間を確認する

保守契約では、1年単位の自動更新が採用されることがあります。解約には「満了日の1か月前まで」「3か月前まで」などの予告期間が必要な場合があります。

この条件を見落とすと、乗り換え準備を進めていても、次年度契約に入ってしまうことがあります。更新日と通知期限は、契約締結時点で社内カレンダーに登録しておくと安心です。

返却・引き渡し対象を具体的に列挙する

解約時に必要になる資産は、あらかじめ契約書や別紙で明確にしておくべきです。

資産	具体例	確認ポイント
ソースコード	アプリ本体、テーマ、カスタムコード	最新版か、リポジトリ単位か
設計書・仕様書	画面仕様、DB定義、API仕様、構成図	最新化されているか、形式は何か
データ	DBダンプ、画像、添付ファイル	形式、文字コード、抽出範囲
認証情報	サーバー、CMS、DNS、CDN、APIキー	棚卸し一覧で受け取れるか
運用情報	監視設定、ジョブ設定、バックアップ設定	再現可能なレベルで引き継がれるか

「何を、いつまでに、どの形式で引き渡すか」を契約時点で決めておくと、解約時の摩擦を減らせます。

知的財産権と利用権の整理も必須

ソースコードや設計書の引き渡しでは、著作権や利用許諾の整理も重要です。委託開発や保守改修の成果物について、誰に権利が帰属するのか、第三者への再委託や引き継ぎが可能かを確認してください。

実務上は、著作権の完全移転だけでなく、発注者が継続利用・改変・第三者委託できる十分な利用許諾を確保する形もあります。どちらが適切かは案件によります。

また、OSS（オープンソースソフトウェア）や市販プラグイン、外部ライブラリが含まれる場合は、ベンダーが自由に権利移転できないこともあります。契約では「何がベンダー独自資産で、何が引き継ぎ可能か」を整理しておくと安全です。

SLA以外で外注先を比較するときに見るべき3つの視点

SLAの条件が近い会社同士を比較する場合は、運用品質や実務体制も見ておく必要があります。

1. 技術スタックとの相性と保守実績

同じ「Web保守会社」でも、得意な技術領域は異なります。WordPress中心の会社もあれば、Laravel、React、Node.js、AWS、GCP、Azureなどに強い会社もあります。

• 自社と同じ言語・フレームワークの保守実績があるか
• 同規模のアクセスやデータ量を扱った経験があるか
• 担当予定者がその技術に精通しているか
• 障害対応の実績や再発防止の進め方を説明できるか

守秘義務の都合で社名非公開でも、構成や業種、規模感を説明できる会社のほうが、透明性の面で判断しやすい傾向があります。

2. 担当者体制とコミュニケーション設計

保守は長期運用になるため、コミュニケーション品質が非常に重要です。次の点を確認しましょう。

• 窓口担当と技術担当は固定か
• 月次レポートや定例会はあるか
• 連絡手段はメールのみか、チャットやチケット管理も使えるか
• 担当者不在時のエスカレーション先はあるか

障害時の連絡手段と、平常時の相談手段は分けて設計されているかも確認すると、運用しやすさが見えます。

3. 見積もりの透明性

「月額○万円、保守一式」という見積もりは比較しづらく、後から追加費用の原因になりやすいです。内訳の透明性を見ましょう。

費目	確認したい内容
監視費	何を監視するか、アラート対応は含むか
定例保守費	アップデート、バックアップ確認、月次報告の有無
工数枠	月何時間まで含むか、超過単価はいくらか
緊急対応費	夜間休日の追加費用、最低請求単位
引き継ぎ費	初期調査やドキュメント整備費用の有無

内訳を明示できる会社は、契約後の説明責任も果たしやすい傾向があります。

複数社比較を効率化するチェックリスト

相見積もりでは、各社に同じ条件を提示しないと比較が難しくなります。簡易RFP（提案依頼書）を用意し、同じ前提で回答してもらうのがおすすめです。

簡易RFPに入れたい項目

• システム概要（言語、FW、CMS、クラウド、外部連携）
• 現在の課題（障害頻度、属人化、ドキュメント不足など）
• 希望する対応時間帯
• 求める応答時間・復旧目標
• 希望する保守対象範囲
• 月間の想定作業量
• 予算感
• 契約開始希望時期

契約前に必ず質問したい10項目

• □ 障害の優先度ごとの応答時間と復旧目標時間は？
• □ 夜間・休日は受付のみか、実作業まで行うのか？
• □ 保守対象はインフラ、アプリ、DNS、SSL、バックアップのどこまでか？
• □ 月額費用に含まれる工数上限は？
• □ 超過時の単価と最低請求単位は？
• □ 稼働率保証はあるか？除外事由は何か？
• □ SLA未達時の補償は現金返金か、サービスクレジットか？
• □ 解約予告期間と自動更新条件は？
• □ 解約時に返却される資産と形式は？
• □ 損害賠償上限と、逸失利益の扱いは？

これらは口頭ではなく、メールや提案書など書面で回答を残してもらうのが基本です。

よくある質問（FAQ）

SLAは交渉できますか？

はい、交渉できることはあります。ただし、応答時間短縮や24時間対応の追加など、体制コストが増える条件は費用増額につながりやすいです。一方で、対応範囲の明文化、報告頻度、引き継ぎ条件の整理などは比較的交渉しやすい場合があります。

小規模サイトでもSLAは必要ですか？

必要です。大規模システムほど厳密でなくても構いませんが、少なくとも対応時間帯、障害時の連絡方法、保守対象範囲、解約時の引き継ぎ条件は決めておくべきです。小規模でも、予約や問い合わせ獲得に直結するサイトなら影響は小さくありません。

現在の外注先のSLAが弱い場合、どう改善を求めればよいですか？

まず現行契約書と実際の運用内容を整理し、どこが曖昧かを洗い出します。そのうえで、過去の障害事例や困った場面を根拠に、改善したい項目を文書で提示すると交渉しやすくなります。契約更新時期が近いなら、そのタイミングで改訂を提案するのが現実的です。

安い保守会社は避けるべきですか？

一概には言えません。シンプルなサイトなら低コストでも十分な場合があります。ただし、24時間対応、高可用性、セキュリティ監視、定例改善提案まで含む保守を低価格で実現するのは簡単ではありません。価格だけでなく、体制・対象範囲・SLA・実績をセットで比較してください。

まとめ｜契約前に確認したい5つのSLA

Webシステム保守の外注では、契約前のSLA確認が、その後の運用品質を大きく左右します。最後に、確認すべき5項目を整理します。

確認項目	要点
①障害時の応答・復旧時間	応答時間と復旧目標時間を優先度別に数値で確認する
②保守対応範囲と除外事項	インフラ、アプリ、DNS、SSL、バックアップの対象範囲を明確にする
③稼働率保証と補償条件	稼働率の数字だけでなく、除外事由と補償方法まで確認する
④責任範囲と損害賠償上限	責任分界点、賠償上限、逸失利益の扱いを確認する
⑤解約・引き継ぎ条件	更新条件、返却資産、知的財産権、認証情報の引き渡しを確認する

良い外注先は、SLAの質問に対して曖昧にせず、書面で丁寧に説明できます。逆に、「柔軟に対応します」「都度相談で大丈夫です」という説明ばかりで具体化を避ける場合は、契約後の認識違いに注意が必要です。

保守外注の成功は、価格の安さだけでは決まりません。自社に必要な保守レベルを整理し、SLA・責任範囲・引き継ぎ条件まで含めて比較し、長く付き合えるパートナーを選びましょう。