システム保守のSLAと費用｜連絡まで1時間と復旧まで1時間は別物

たとえば、こういう場面を考えてみてください。保守の提案書に「障害発生時は1時間以内に対応」と書いてある。同じ条件で別の会社に聞いたら、そちらも「1時間以内」だった。金額は、仮に月20万円と月35万円だったとします。

この2社は、同じものを売っていません。片方の1時間は「担当者から折り返しの連絡が来るまで」で、もう片方の1時間は「システムが動くようになるまで」かもしれない。そして、その1時間の時計がいつ動き出すのかも、両社で違っている可能性があります。

この記事は、SLAに書かれた数字が何を約束しているのかを、契約書と見積書から特定するための手順書です。相場のレンジは示しません。示せるほどの公開データがないからです。代わりに、公開されているSLA約款と公共調達の仕様書を原文で確認し、数字の意味を決めているのは数字そのものではなく、その周りにある6つの定義だということを見ていきます。①どの指標か　②時計の起点と終点　③重要度を誰が決めるか　④免責・除外事由　⑤未達のとき何が起きるか　⑥誰が測って報告するか。以降は、この順に見ていきます。

TL;DR｜SLAの数字は、単独では何も約束していない

• 「1時間以内」は最低4通りに読めます。 一次応答（連絡が来る）／一次切り分け（原因の当たりがつく）／復旧（使えるようになる）／稼働率（月間で止まってよい合計時間）は、それぞれ別の指標です。見積書に数字が1つしか書かれていないなら、どれなのかは決まっていません
• 見積書でいう「一次対応」は、公開されている約款では「直すこと」ではなく「原因を調べて報告すること」と定義されています。 業界団体が公開しているSLAサンプルは、第一次対応を「その原因の調査を行い、報告する」と定義しています。これは「1時間で直る」という意味ではありません
• 公開されているSLAサンプルは、時計の起点を「ベンダーが知った時刻」に置いています。 同じサンプルは「乙による感知又は甲からの連絡があった時刻から」と書き、さらに「通常業務時間内において」という限定を付けています。夜間に起きた障害の時計は、翌朝から動き出す設計もありえます
• 障害の重要度を誰が決めるかが書かれていないSLAは、いちばん速い数字が使える保証になりません。 重要度の判定権がベンダー側にあるなら、その数字は「ベンダーが最上位と判断したとき」の数字です
• 未達のときに何が起きるかは、契約の型で3つに分かれます。 クラウド事業者はサービスクレジット（将来の請求への充当。返金ではない）、公共調達は減額ポイントによる保守費の減額、そして「何も起きない」型も実在します
• クラウド事業者のSLAでは、クレジットは自分で請求しないともらえません。 AWSはインシデント発生後2回目の請求期間の末日まで、Google CloudとAzureは60日以内という期限を明記しており、いずれも必要情報を出さなければ権利を失うと書いています
• 数字を厳しくすれば費用は上がります。 ただし上がるのは保守費だけとは限りません。復旧目標を短くする手段の多くは構築費側（冗長化＝同じ役割の設備をあらかじめ二重に持ち、片方が壊れても業務が止まらないようにする構成・予備機）に乗ります。逆に、SLAだけ厳しくして構築を変えない見積もりは、達成できない約束を売っている可能性があります
• 最初にやることは交渉ではなく、手元の契約について、上の6つの定義を1つずつ確定させることです

「24時間365日」という表記が、稼働時間・受付・監視・対応のどれを指すのかという問題は、本記事では扱いません。監視費用の記事で、公的な項目定義と対応づけて整理しています（サーバー監視費用の内訳と有人対応の判断）。

本記事が扱うのは、時間帯が決まったあとに残る「数字の定義」の部分です。何時から何時まで対応するかが決まっていても、その時間帯の中で「1時間以内」が何を意味するかは、まだ決まっていません。

「1時間以内」が何の1時間なのか｜SLAの数字は4層に分かれる

保守のSLAで使われる時間の数字は、大きく4つの層に分かれます。この4つは測っているものが違うので、数字の大小を横に並べても比較になりません。

なお「受付（連絡がつくこと）」は、この4層の手前にある別の層です。何時から何時まで連絡がつくかは「24時間365日」が受付・監視・対応のどれを指すかの整理で扱っており、本記事の4層は受付が済んだあとの話です。

見積書で使われる「一次対応」という言葉は、上の表でいえば一次応答と一次切り分けにまたがる語で、いずれにしても「直す」約束ではありません。 これは解釈ではなく、公開されている約款がそう定義しています。

「リモート保守サービス SLA（Service Level Agreement）サンプル Ver.1.0」（2023年4月、2026年8月21日取得。発行者は文書上「JAHIS/JIRA 合同リモートサービスセキュリティ作成WG」と表記されています）は、第一次対応を次のように定義しています。

本サービスの提供に際して障害等が生じた場合に、乙は、甲の連絡又は自己の判断に基づき、その原因の調査を行い、報告する（第一次対応）。

「調査を行い、報告する」までです。復旧はこの定義に含まれていません。 この定義は、上の表でいえば一次応答（第一報を返す）と一次切り分け（原因の所在を特定する）を合わせた範囲にあたります。見積書に「一次対応」とだけ書かれているとき、それが原因の特定まで含むのか、第一報だけなのかは決まっていません。

以降、原典を引くときは原典の語（「第一次対応」）を使い、上の4層を指すときは「一次応答」「一次切り分け」と書き分けます。

なお同サンプルでは、第一次対応の結果によって、その先の責任が3つに分かれる設計になっています（後述の責任分界の節で扱います）。

一次切り分けについても、定義を書いている調達仕様書があります。三重県の「三重県情報ネットワーク 設計・構築・運用保守業務 詳細仕様書」（令和7年度〈2025年度〉の契約締結を前提とする調達仕様書。2026年8月21日取得）は、障害発生時における対応の項でこう書いています。

ここでいう一次切り分けとは、本業務において導入される機器、サービスにおいては機器、サービス単位で障害箇所を特定すること、既存システム、回線等においては障害箇所が次期ネットワーク側か、既存システム、回線側によるものかを切り分けることを指す。

「どこが悪いかを特定するところまで」であって、直すところまでではありません。 発注側から見ると、一次切り分けが終わった時点では業務はまだ止まったままです。

見積書と提案書では、SLAはこう書かれている

保守の見積書でSLAが独立した行として立っていることは、あまりありません。多くの場合、次のどれかの形で紛れ込んでいます。

最後の行が、実は一番多いパターンです。 SLAの記載がない保守契約は珍しくなく、それ自体が直ちに問題というわけでもありません。月額が安く、業務が半日止まっても困らないシステムなら、SLAを付けないことは合理的な選択です。問題になるのは、止まると困るシステムなのに、止まったときの約束が契約に書かれていないときです。

見積書の1行に潰れているもの

「障害対応 月額◯◯円」という1行は、少なくとも次の5つを同時に買っています。このうちどれが入っていてどれが入っていないかで、同じ金額でも中身がまったく変わります。

見積書の金額そのものを実費／人の作業／システムの作業／待機の4区分へ割る手順は、システム保守見積書の見方で扱っています。上の表はそれとは別の軸で、「待機」と「人の作業」の中身をSLAの観点から割ったものです。金額の割り振りはあちら、その金額が何時間の約束を買っているのかは本記事、という分担になります。

時計はいつ動き出し、いつ止まるのか

SLAの数字でもっとも見落とされるのが、起点と終点の定義です。「1時間以内」という数字が同じでも、起点が3時間ずれれば、業務が止まっている時間は3時間変わります。

起点になりうる時刻は、少なくとも6つある

公開されているSLAサンプルは、起点を「ベンダーが知った時刻」に置いています。 前掲のJAHIS・JIRAのSLAサンプルは、次の形で書かれています。

甲の業務に継続な（原文ママ）支障をきたす程度の機器、ソフトウェア等のシステム障害等、及びサービス利用における応答速度の低下については、４．４(2)に示す通常業務時間内において、乙による感知又は甲からの連絡があった時刻から、●時間以内に第一次対応（４．１②参照）をする。

読むべき点が3つあります。

1. 起点は「乙による感知又は甲からの連絡があった時刻」 — ベンダーが自分で気づいた時刻か、発注側から連絡が入った時刻の、早いほうです
2. 「通常業務時間内において」という限定が付いている — ただし同サンプルは、参照先の連絡体制の項で「通常業務時間」の時間帯そのものを空欄のまま置いており、通常業務時間が何時から何時までかを定義していません。一方で本サービスの提供時間としては【平日】9:00〜17:00、【土曜日・日曜・祝日】提供なし、と書かれています。両者が一致するなら、金曜18時の障害の時計は月曜9時から動くことになります（この対応づけは本記事の読みで、サンプルが明示した設計ではありません）
3. 時間の数値そのものは「●時間以内」と空欄 — このサンプルは数値を埋めていません。埋めるのは契約当事者の仕事であり、雛形が決めてくれるものではない、という設計です

3点目は、SLAという文書全般に言えることです。同サンプルは「サービスレベル算定除外事項」も「＜ここに算定除外事項が入る＞」と空欄のまま置いています。雛形をそのまま受け取っただけの契約書は、肝心のところが決まっていない可能性があります。

終点も1つではない

「復旧まで4時間」と書かれているとき、それが暫定復旧なのか恒久復旧なのかで、意味はかなり違います。 暫定復旧は「今日の業務は回る」という約束、恒久復旧は「同じことが起きない状態まで戻す」という約束です。前者しか買っていない契約で恒久対策を求めると、別見積もりになります。

顧客側の待ち時間は、時計を止めるのか

これは見積書にも契約書にも書かれていないことが多い項目です。障害対応の途中で、ベンダーが発注側の回答・承認・作業を待っている時間を、SLAの計測に含めるかどうか。

実際の障害対応では、次のような待ちが発生します。

• 本番データの復元可否について、発注側の業務部門の判断を待つ
• 深夜作業の実施承認を、発注側の決裁者から得るのを待つ
• 発注側が管理しているアカウント・権限の発行を待つ
• 発注側が契約している別のベンダー（回線・パッケージ提供元）の回答を待つ

ベンダー側の言い分としては、これらを計測から外したいのは自然です。 自分でコントロールできない時間の責任は負えません。ただし、それが契約に書かれていないと、未達が起きたときに「あれは御社の待ち時間でした」という事後の主張が出てきます。逆に、発注側から見れば、待ち時間を止めるなら「誰が・いつまでに・何を」返すのかもセットで決めておかないと、ベンダー側が待ちを申告しさえすれば時計が止まる運用になりかねません。

参考になるのは、公開されているクラウド事業者の約款の書き方です。Microsoftの「Service Level Agreement for Microsoft Online Services」（2026年8月10日版、2026年8月21日取得。原文は英語）は、SLAの適用対象外となる事象のひとつとして、顧客側の「無許可の行為、または必要とされたときに行動しなかったこと」に起因するものを挙げています。同様に、Amazon Web Servicesの「Amazon Compute サービスレベルアグリーメント」（最終更新2022年5月25日、2026年8月21日取得）も、例外事由の1つとして「サービス利用者の作為または不作為」を挙げ、その例として「回復ボリュームの認識失敗やリソース健全性に関する懸念への不対応」を挙げています。

大手が明文化しているということは、書いていない契約では争点になる、ということです。 手元のSLAに待ち時間の扱いが書かれていないなら、それは決まっていない項目です。

障害の重要度は、誰がどう決めるのか

SLAの表が「重大障害は1時間以内、軽微な障害は翌営業日」のように段階で書かれているとき、その段階を誰が判定するかで、表の意味が変わります。

判定権がベンダー側にあり、重要度の定義が書かれていない場合、その表は実質的に「ベンダーが重大と判断したときは1時間以内」という約束です。発注側が「これは重大だ」と思っても、その主張を通す根拠が契約にありません。

前掲のJAHIS・JIRAのサンプルでも、対象となる障害は「甲の業務に継続な（原文ママ）支障をきたす程度の機器、ソフトウェア等のシステム障害等」と定性的に書かれています。同サンプルはサービス稼働率の定義でも、サービス停止時間から「サービス機能の一部が停止している場合でも、甲の業務に重大な支障を及ぼさない場合」を除くとしています。「重大な支障」に当たるかどうかを、誰がどう決めるかは書かれていません。

これは、このサンプルの手落ちというより、重要度は業務側の事情でしか決められないので、雛形には書けないということだと読むべきです。書けるのは発注側だけです。

重要度の定義に必要な5要素

重要度の区分を契約で決めるとき、少なくとも次の5つが埋まっていないと、判定は運用時にぶれます。

2番目が実務上いちばん効きます。「サーバーがダウンした」ではなく「受注が受けられない」「請求書が発行できない」という書き方にすると、技術者でなくても判定に参加でき、SLAの数字が経営判断とつながります。

稼働率99.9%は、月に何分止まってよいのか

稼働率だけは、定義から機械的に停止許容量へ換算できます。ここは意見の入る余地がないので、先に出しておきます。

以下は30日の月（43,200分）を分母として本記事で計算した値です。月の長さで変わります（31日なら約3%多く、28日なら約7%少なくなります）。

99.9%と99.5%の差は、数字の見た目では0.4ポイントですが、停止許容量では5倍です。 そして、この差を埋める手段は保守体制の強化ではなく、たいていシステム構成の変更（冗長化）です。ここが費用のどこに乗るかは後述します。

なお、稼働率は事後の集計値です。「99.9%保証」は「1回の障害が43分以内に直る」という意味ではありません。月に1回、5時間止まる障害が起きれば、その月の稼働率は99.9%を下回りますが、その障害の最中に稼働率の約束が何かを助けてくれるわけではありません。復旧の速さを買いたいなら、稼働率ではなく復旧目標の数字を見てください。

公開されているSLA約款3件を、同じ条件へそろえる

日本の受託保守会社がSLAの全文を公開している例はほとんどありません。一方で、クラウド事業者は稼働率SLAを全文公開しています。金額の相場としては使えませんが、「SLAという文書が成立するために何が書かれている必要があるか」の実例としては使えます。

適用条件を先に書きます。 以下はクラウド事業者が自社のインフラサービスについて定めた稼働率SLAであり、他社が構築したシステムの保守契約とは対象が違います。ここに出てくる数値を、受託保守の相場や妥当な水準として読み替えることはできません。 AWSの日本語版PDFには「本翻訳版と英語版の間に差異、不一致、矛盾が存在する場合、（特に翻訳による遅れもあり）英語版が優先します」と明記されています。Google CloudとMicrosoftの文書は英語のみを確認しており、本記事の日本語は筆者による訳です。

以下は3社の稼働率SLAを同じ項目でそろえたものです（いずれも2026年8月21日取得）。

Google Cloudが水準の呼び名に「Objective（目標）」を使っている点は、そのまま読んでおく価値があります。文書名は Service Level Agreement で、SLOを満たさなければクレジットの受給資格が生じる設計なので、約束が無いという意味ではありません。ただし、水準そのものは「目標」という語で呼ばれているということです。手元の別紙の数字が「目標値」なのか「保証値」なのかは、達成できなかったときに何が起きるか（後述の3類型）とセットでしか判断できません。

用語について。 未達時の給付は3社で呼び名が違います（AWS：サービスクレジット、Google Cloud：Financial Credit、Microsoft：Service Credit）。中身はいずれも「将来の請求への充当」で同じなので、本記事ではこれ以降、総称として「サービスクレジット」（短縮して「クレジット」）と書きます。

3社に共通していた5つの構造

金額を横に置くと、3社の書き方には共通の骨格があります。手元のSLAにこの5つが書かれているかどうかが、そのまま確認事項になります。

1つめについて、Microsoftの単一構成でStandard HDDを使ったときの95%は、前節の換算表でいえば月36時間です。構成を選ぶことは、停止許容量を選ぶことでもあります。 | 2 | 停止時間の数え方が定義されている | Google Cloudは「1分以上連続した停止」をDowntime Periodとし、分の端数（partial minutes）や、1分未満の断続的な停止は数えないと明記。Microsoftは計画停止（5日前までに通知）をDowntimeに含めないと明記 | 停止の起点・終点。計画停止の扱い。短時間の断続的な停止の扱い | | 3 | 給付は請求しないと出ない | 上表の請求3行のとおり、3社とも発注側からの請求が前提 | 未達時に自動で減額されるのか、こちらから請求するのか。請求期限はいつまでか | | 4 | 給付には上限がある | 3社とも、対象期間における当該サービスの料金が上限（Azureの従量課金では対象期間が暦月ではない点は上表のとおり）。逸失利益は対象外 | 上限額。損害賠償と別枠か、これが唯一の救済か | | 5 | 除外事由が列挙されている | 3社とも自社の支配が及ばない要因・利用者側起因・第三者製品起因などを列挙 | 除外事由が列挙されているか。「その他当社が認める場合」のような包括条項だけになっていないか |

2番目は見落としやすい項目です。「実際には止まっていないが極端に遅い」状態の扱いが典型で、Microsoftの文書はSLAの適用対象外となる事象として「実際のサービス停止を伴わない、パフォーマンス低下やレイテンシの問題に起因するもの」を挙げています（パフォーマンスに基づくService Levelが明示されているサービスを除く）。業務側から見ると、遅すぎて使えない状態と止まっている状態は同じですが、SLA上は別扱いになりうるということです。

日本の公共調達では、SLAはこう書かれている

民間の受託保守でSLAの全文が公開されている例は少ないのですが、自治体の調達仕様書は公開されています。未達時の扱いを日本語の契約でどう書くかの実例として確認しておきます。

三重県の「三重県情報ネットワーク 設計・構築・運用保守業務 詳細仕様書」（令和7年度〈2025年度〉の契約締結を前提とする調達仕様書。2026年8月21日取得）は、サービスレベル要件を次のように設計しています。

注目すべきは最後の行です。 保守ベンダーが裏でクラウドを使っている場合、そのクラウドのSLAが実質的な上限になります。ベンダーが「稼働率99.99%」と約束していても、その裏で使っているサービスのSLAが99.9%なら、差分はベンダーが自社の構成でカバーしていることになります。 カバーしていないなら、その約束は根拠のない数字です。三重県の仕様書は、これを事前提示と承認の対象にしています。

同仕様書はSLA適用除外条件として、次の7項目を挙げています。

1. 本庁舎や総合庁舎の計画停電
2. 公共交通機関の停止、災害による電源供給の停止や通信障害の場合
3. 本県又は他の事業者の過失及び故意による障害の場合
4. 本受託事業者の瑕疵によらず障害復旧が行えない場合
5. 本受託事業者の瑕疵によらず障害監視が行えない場合
6. 本受託事業者の瑕疵によらず障害通知の受信ができない場合
7. 本県及び本受託事業者双方の協議のうえ、計測の除外とした場合

3番目に発注側自身の過失・故意が入っていることに注意してください。除外事由は「災害」のような大きな話だけでなく、発注側の行為も含みます。7番目は協議による除外で、これがあること自体は運用上合理的ですが、協議の記録が残らないと事後に検証できなくなります。

測定するのは誰か

もう一件、三重県の「三重県公共工事進行管理システム 運用保守仕様書（案）」（別添資料1-4。文書冒頭に「※記載内容はRFIの結果を受けて変更される可能性があります」と明記された案の段階の文書。2026年8月21日取得）には、測定の主体が明記されています。

サービスレベルの測定は、三重県が行う。

続けて、測定方法は「三重県独自の検査又は本業務受注者からの報告に基づき行う」、測定時期は原則として協議により定めた期間で対象月の翌月末までに行い、「三重県は、必要と認めるときは、測定結果を取り消し、再測定を行うことができる」としています。

測定するのは発注側だ、と書いてある点が重要です。 民間の保守契約では、SLAの達成状況をベンダーが自己申告し、発注側はその報告書だけを見る形が一般的です。この形でも運用は回りますが、報告の元になった生データ（監視ログ、受付記録、対応記録）に発注側がアクセスできるかどうかは、契約前に決めておく価値があります。

免責条項と責任分界｜「対応します」の範囲はどこで切れるか

SLAの数字が守られなかったとき、最初に出てくるのが免責条項です。免責が書かれていること自体は正常です。 自社の支配が及ばない事象まで責任を負う契約は、そもそも引き受け手がいません。問題になるのは、免責の書き方が包括的すぎて、実質的に何も約束していない状態になっているときです。

前節の三重県の除外7項目と、クラウド3社の除外事由を突き合わせると、除外の理由は次の4類型に整理できます。

2番目の「発注側起因」がいちばん揉めます。 発注側の義務が契約に書かれていないと、事後になってから「あれは御社側の対応待ちでした」という主張が出てきます。除外事由に発注側起因が入っているなら、発注側の義務も同じ契約に書かれているべきです。

責任分界は「第一次対応の後」に決まる

責任分界点は、障害が起きる前に線として決まっているとは限りません。前掲のJAHIS・JIRAのSLAサンプルは、第一次対応の結果によって責任の所在が分かれるという設計を採っています。分岐は3つです。

2行目の「支援に努める」という表現に注意してください。これは努力義務であって、復旧の約束ではありません。 発注側の設備が原因だと判明した時点で、このサンプルではベンダーの義務が支援の努力義務に切り替わります（なお同サンプルは復旧までの目標時間そのものを定めておらず、時間の目標は第一次対応と稼働率にしか置かれていません）。復旧目標を定めている契約であれば、その目標が甲起因の障害にも適用されるのかどうかを、別途確認する必要があります。

3行目も実務上効きます。同サンプルには、元にした参考例が「甲乙いずれにも起因しない」という趣旨だったところを「不明な場合は」という表記に変えた、と解説が付されています。原因不明のまま長時間が経過するケースを、協議に落とす設計です。 つまり、原因が特定できていない間は協議に入るだけで、対応の期限はそこでは決まりません。復旧目標を定めている契約であれば、その目標が原因不明の局面でも走り続けるのかを、あらかじめ確認しておく必要があります。

なお、このサンプルは医療機関向けのリモート保守サービスを想定して作られたもので、文書自身も「利用する各社はあくまで参考として自社サービスのSLAおよびSDS策定の参考とされたい」と書いています。業種も対象システムも読者の状況とは異なりえます。 ここで持ち帰るのは数値ではなく、責任分界が第一次対応の後に決まるという構造だけにしてください。

未達のとき何が起きるか｜補償は3つの型に分かれる

SLAを満たさなかったときに何が起きるかは、契約の型で大きく3つに分かれます。どの型かによって、SLAの数字が持つ拘束力がまったく違います。

3番目は「手抜き」ではありません。JAHIS・JIRAのサンプルは、損害賠償の記載を削除した理由を解説として明記しています。要約すると、リモートサービスのサービスレベル低下に起因して賠償責任が発生する場面が極めて少ないと考えられるため、という判断です。同時に「これによって、乙を原因としたセキュリティ事故に関する損害賠償責任を逃れるものではありません」とも書かれています。賠償を書かない代わりに、改善義務と解約権で担保する設計です。

同サンプルのサービスレベルマネジメントは6つの取り決めからなります。まず未達があれば報告と改善策の提示を求め、そのうえで契約解除を申し入れられる場面を4つ置いています。残る1つは必要に応じて協議を行うという定めなので、下には挙げていません。

1. 月次報告でSLAに達しない内容があった場合、ベンダーはその事由を報告し、改善策を提示する
2. その項目について1年以上改善が見られない場合、発注側は契約解除を申し入れることができる
3. 評価がCで、続く1回の評価でも改善しない場合、契約解除を申し入れることができる
4. 評価がDになった場合、契約解除を申し入れることができる
5. 巻末に示す事項が遵守されていないと判明した場合、発注側は相当の期間を定めて改善を図る旨を要請する。その期間を過ぎても改善が見られない場合は、契約解除を申し入れることができる

発注側として確認すべきは「うちの契約はどの型か」です。 クレジット型なのに請求手続きを知らない、減額型なのに測定していない、定めなし型なのに解約予告期間が長い、といったズレがあると、SLAは書いてあるだけの文書になります。

誰が測って、誰が報告するのか｜実績報告がないと達成を検証できない

補償の型がどれであっても、前提になるのは実績が測られて報告されていることです。ここが抜けている契約は珍しくありません。

前掲のJAHIS・JIRAのサンプルは、ベンダーが発注側に報告し、共同で評価する管理指標として次の4つを挙げています。

1. サービス稼働率
2. 障害対応時間
3. ウイルス対策のためのパターンファイル、およびOS・ミドルウェア等のセキュリティパッチの対応状況
4. 巻末に示す事項の実施状況

そのうえで、月次報告の項目にこの管理指標を含め、サービスレベルの評価そのものは年次ごとに実施するとしています（甲乙協議のうえ、必要に応じて別途評価も可能）。

次の3つは両立します。 月次で数字を受け取り、年次でまとめて評価し、測定の元データには発注側がアクセスできる。この形が、確認事項としてはもっとも安全です。

SLAの数字を1段厳しくすると、どの費用が増えるのか

ここまでの6つの定義が確定したら、次は金額の話です。「SLAを厳しくすれば保守費が上がる」は、半分しか正しくありません。厳しくする項目によって、費用が乗る場所が変わります。

この表の意味は2つあります。

1つめ。値上げの提案が来たとき、何の対価かを聞き分けられます。 「SLA強化のため」という理由での値上げが、待機の話（人を増やす）なのか、構成の話（冗長化する）なのかで、妥当性の判断材料が変わります。構成を変えないまま復旧目標だけを短くする提案は、達成手段が示されていない値上げです（この点は次節の合理性の条件にそのまま効いてきます）。

2つめ。安い見積もりのほうが危険な場合が特定できます。 保守の見積もりで「復旧2時間以内」を約束しながら、月額が同条件の他社より大幅に安いとき、次のどれかが欠けている可能性があります。

• 夜間・休日の待機費が見積もりに入っておらず、実際には翌営業日対応になる
• 冗長構成が無く、機器故障時は部品調達から始まるため、2時間では物理的に届かない
• 復旧手順の整備・訓練の工数が入っておらず、初回の障害時にその場で手順を考えることになる
• 実績の測定と報告が入っておらず、達成できていないことに発注側が気づけない

SLAの数字が同じで金額が大きく違うときは、高いほうを疑う前に、安いほうの達成手段を聞いてください。 保守見積もりの過小見積もりの見分け方は、システム保守費用の相場と妥当性の検証手順でコストドライバー別に整理しています。

その料金体系が合理的といえる条件

ここまで定義と費用を見てきましたが、SLAが緩いこと、あるいはSLAが無いこと自体は、不当ではありません。 次の条件を満たしているなら、その保守契約は合理的です。

• 業務影響の大きさと、SLAの水準が釣り合っている。 半日止まっても業務が回るシステムに、復旧2時間のSLAを付けて費用を払う必要はありません
• 数字が達成手段とセットで説明されている。 復旧目標が短いなら、それを可能にする構成（冗長化・予備機・事前手順）が見積書か構成図のどこかにあるはずです
• 除外事由が具体的に列挙されていて、包括条項に依存していない。 そして発注側の義務も同じ契約に書かれています
• 未達時の扱いが3類型のどれかに決まっている。 金銭的補償が無い型でも、改善義務と解約条件が書かれていれば機能します
• 実績が測られ、報告されている。 数字が守られているかどうかを、発注側が検証できます
• 数字を上げない選択が説明されている。 「99.9%まで上げるには冗長化が必要で、費用は◯◯円。現在の業務影響ならそこまで不要と考えます」と言えるベンダーは、数字の意味を理解しています

最後の条件を満たすベンダーは、実は多くありません。 提案側にとって、SLAを厚くするのは単価を上げる方向の提案です。それを自分から引き算してくる提案は、信用の材料になります。

確認が必要なケース・高リスクのケース

逆に、次のパターンは確認が必要です。「不当だ」という意味ではありません。書かれていないことが多すぎて判断できない、という意味です。

冒頭の2社を、同じ条件へそろえるとどう見えるか

後述の確認質問9問（この節のあとに置いています）への回答が返ってきたら、次の形で並べます。冒頭の「月20万円と月35万円」の2社を例にした記入例です（実在の見積もりではなく、表の使い方を示すための書き方の例です）。

この表を作ってはじめて、「A社が安い」ではなく「A社は一次応答を、B社は復旧を売っている」と社内で説明できます。金額差の妥当性は、そのあとの話です。

4状態への割り当て

集めた回答は「妥当／不当」ではなく、4状態で仕分けてください。金額の話に入るのは、この仕分けが終わってからです。

「判断不能」を「高リスク」と混ぜないでください。別紙が出てこない状態は、悪い契約ではなく、まだ読んでいない契約です。 契約範囲そのものの仕分け方はシステム保守契約の範囲で扱っています。本記事の4状態はSLAの数字の定義について、あちらの4状態（含む／別料金／対象外／不明）は作業範囲についての区分なので、混ぜて使わないでください。

ベンダーへそのまま送れる確認質問9問

技術的な知識がなくても送れる形にしてあります。口頭ではなく書面（メール）で受け取ってください。 口頭の回答は契約の一部になりません。

1. 「◯時間以内」の対象｜見積書（提案書）に記載の「◯時間以内」は、一次応答・一次切り分け・復旧のどれを指しますか。それぞれについて目標時間を分けてご記載ください
2. 計測の開始・終了時刻｜その時間の計測開始時刻は、（a）監視による検知、（b）弊社からの連絡受領、（c）受付票の起票、（d）対応時間帯の開始、のどれですか。計測の終了時刻は、（a）第一報の連絡、（b）原因箇所の特定、（c）暫定復旧、（d）恒久復旧、のどれですか
3. 障害の重要度区分｜障害の重要度区分はいくつありますか。各区分の定義を、技術的な現象ではなく業務への影響（例：受注が受けられない／一部利用者のみ影響）でご記載ください。あわせて、区分を判定するのはどちらか、判定に異議がある場合の手続きをご教示ください
4. 弊社側の待ち時間の扱い｜障害対応中に弊社側の回答・承認・作業を待っている時間は、目標時間の計測に含まれますか。含まれない場合、待ち時間として扱う条件と、弊社が何をいつまでに返すべきかをご記載ください
5. 免責・除外事由と、弊社側の義務｜SLAが適用されない場合（免責・除外事由）を、包括的な表現ではなく個別に列挙してください。あわせて、除外の前提となる弊社側の義務（連絡方法、担当者の配置、環境の維持など）もご記載ください
6. 責任分界｜障害の原因が弊社の管理する機器・回線・他社システムにあった場合、御社の対応はどこまでですか。原因が特定できない状態が続いた場合の取り扱いもご記載ください
7. 未達時の取り扱い｜目標時間や稼働率が達成できなかったとき、何が起きますか。（a）減額、（b）サービスクレジット、（c）改善報告のみ、（d）定めなし、のどれですか。減額・クレジットの場合、弊社からの請求が必要か、請求期限はいつまでか、上限額はいくらかをご記載ください
8. 実績の測定と報告｜SLAの達成状況を測定するのはどちらか、報告の頻度と様式、および測定の元になる記録（監視ログ・受付記録・対応記録）を弊社が確認できるかをご教示ください
9. 達成手段と、水準を変えた場合の差額｜ご提示の目標時間・稼働率を達成するための手段（対応時間帯の人員配置、冗長構成、予備機、事前に用意した復旧手順、復旧訓練）をご記載ください。あわせて、水準を1段上げた場合・下げた場合の月額の差額をご提示ください

そのまま送れるメール文面

件名：保守契約のサービスレベル（SLA）に関する確認のお願い

◯◯株式会社
△△様

いつもお世話になっております。□□株式会社の◇◇です。

保守のご提案（お見積書）について、社内で稟議を通すにあたり、
サービスレベルの条件を確認させていただきたく、ご連絡いたしました。

御社の対応品質を疑うものではなく、障害が起きたときに
弊社側が社内・取引先へどう説明できるかを整理するための確認です。
お手数ですが、下記について書面（本メールへのご返信）でご回答いただけますでしょうか。

【1】「◯時間以内」の対象
ご提示の「◯時間以内」は、一次応答・一次切り分け・復旧のどれを指しますでしょうか。
それぞれについて目標時間を分けてご記載ください。

【2】計測の開始・終了時刻
その時間の計測開始時刻は、（a）監視による検知 （b）弊社からの連絡受領
（c）受付票の起票 （d）対応時間帯の開始 のいずれでしょうか。
また終了時刻は、（a）第一報のご連絡 （b）原因箇所の特定
（c）暫定復旧 （d）恒久復旧 のいずれでしょうか。

【3】障害の重要度区分
重要度の区分数と、各区分の定義をご記載ください。
定義は技術的な現象ではなく、業務への影響（例：受注が受けられない、
一部利用者のみ影響）でお示しいただけると助かります。
あわせて、区分を判定するのはどちらか、判定に異議がある場合の手続きも
ご教示ください。

【4】弊社側の待ち時間の扱い
対応中に弊社の回答・承認・作業をお待ちいただく時間は、
目標時間の計測に含まれますでしょうか。
含まれない場合、その条件と、弊社が何をいつまでにお返しすべきかを
ご記載ください。

【5】免責・除外事由と、弊社側の義務
SLAが適用されない場合を、個別に列挙してご記載ください。
あわせて、除外の前提となる弊社側の義務（連絡方法、担当者の配置、
環境の維持など）もご教示ください。

【6】責任分界
障害の原因が弊社の管理する機器・回線・他社システムにあった場合、
御社のご対応はどこまででしょうか。
また、原因が特定できない状態が続いた場合の取り扱いもご記載ください。

【7】未達時の取り扱い
目標時間・稼働率が達成できなかった場合、何が起きますでしょうか。
（a）減額 （b）サービスクレジット （c）改善報告のみ （d）定めなし
減額・クレジットの場合は、弊社からの請求が必要か、請求期限はいつまでか、
上限額はいくらかをご記載ください。

【8】実績の測定と報告
達成状況を測定するのはどちらでしょうか。報告の頻度と様式、
および測定の元になる記録（監視ログ・受付記録・対応記録）を
弊社が確認できるかをご教示ください。

【9】達成手段と、水準を変えた場合の差額
ご提示の水準を達成するための手段（対応時間帯の人員配置、冗長構成、
予備機、事前に用意した復旧手順、復旧訓練）をご記載ください。
あわせて、水準を1段上げた場合・下げた場合の月額の差額をご提示いただけますと、
社内で費用対効果を判断しやすくなります。

お忙しいところ恐れ入りますが、◯月◯日までにご回答いただけますと幸いです。
不明点がございましたら、お電話でも構いませんのでご連絡ください。

よろしくお願いいたします。

回答をどう読むか

回答が揃ったあとの進め方

回答が揃ったら、やることは4つだけです。

1. 定義を書かせる段階と、水準を上げる段階を分ける。 前者はいま何を約束しているのかを文章にしてもらう作業で、サービス水準そのものを変えません。後者は費用が動きます。先に定義だけを確定させてから、水準を上げる必要が本当にあるかを判断してください。 順番を逆にすると、定義が曖昧なまま値上げだけが乗ります
2. 契約に綴じる。 回答メールの内容を、業務仕様書または受託条件明細（SLA別紙）へ反映してもらいます。提案書に書いてあるだけでは契約条件になりません
3. 業務影響と水準を照らす。 「この業務が◯時間止まると、いくらの損失か／誰に説明が必要か」を先に決めてから、水準が過剰か不足かを判断します。水準から決めると、必ず高いほうへ流れます
4. 測り方を決める。 誰が測り、いつ報告し、元データを誰が見られるか。ここが決まれば、次の更新交渉は実績ベースで行えます

結論として「現行の水準のままでよい」となることも普通にあります。 この記事のゴールは水準を上げさせることではなく、いま何を買っているのかを社内で説明できる状態にすることです。

手元の保守見積書や契約書を見ながら整理したい場合は、保守見積書の契約範囲チェック（登録不要）が使えます。対応時間・障害対応の範囲・SLAの記載有無などを入力すると、確認事項が整理されます。結果を見るまでメールアドレスの入力も不要です。

根拠資料と適用条件

本記事で使用した資料と、その適用条件です。いずれも2026年8月21日に取得しました。

本記事で提示していないもの、およびその理由です。

なお本記事は、法的・会計的な最終判断を提供するものではありません。契約解釈、免責条項の有効性、損害賠償の範囲については、それぞれの専門家にご確認ください。

よくある質問