保守運用の外部委託SLA設計｜稼働率・対応時間を自社要件から決める手順

システムが本番稼働を始めたとき、多くの発注者が最初に直面するのが「保守運用をどこに、どんな条件で委託するか」という問いです。開発フェーズと異なり、保守運用は長期にわたる継続的な関係になります。その関係の質を左右する重要な取り決めが、SLA（サービスレベルアグリーメント）です。

「SLAが必要らしいとは聞いているが、稼働率を99%にするのか99.9%にするのかまったく判断できない」「委託先から提示されたSLA案をそのまま受け入れていいのかどうか自信がない」——そうした不安を抱えている担当者の方は少なくありません。SLAという言葉は知っていても、自社の状況に合った水準をゼロから設計した経験がある発注者はほとんどいないからです。

保守運用の外部委託でSLAが機能するかどうかは、契約書に「稼働率99.9%」と書くかどうかではなく、その水準を自社の事業インパクトから根拠を持って導いているか、委託先の体制と釣り合っているか、そして締結後に形骸化させない運用が伴っているかで決まります。運用実績のデータがない段階でも、この3点を押さえれば自社に合ったSLAは十分に設計できます。

本記事では、SLAとは何かという定義の解説ではなく、「自社の稼働率をどう決めるか」「障害対応時間の目安はどのくらいか」「委託先のタイプによって何が変わるか」という、意思決定に直結する情報を中心にお伝えします。委託先から提示されたSLA案を評価するためのチェック観点も含めているため、RFPの作成段階でも、すでに提案を受け取っている段階でも、参考にしていただけます。委託開始後にSLAが形骸化しないための運用方法まで、一通りの流れを押さえましょう。

保守運用を外部委託するときSLAが必要になる理由

SLAは「努力目標」ではなく「効果を伴う取り決め」

SLA（サービスレベルアグリーメント）とは、サービスの提供者（委託先）と受注者（発注者）の間で合意する、サービス品質の水準とその達成に関する取り決めです。単なる「こうしたい」という努力目標ではなく、水準が未達だった場合に何らかの効果（料金の減額、違約金、解約事由など）が生じることが前提になっています。

この点が重要です。SLAがない、あるいはあっても「可能な限り迅速に対応します」という文言しかない場合、障害が発生したときの対応期待値は委託先の裁量に委ねられます。発注者から見ると「なぜこんなに対応が遅いのか」と感じても、契約上の根拠がなければ改善を求める手段がありません。

SLAは、委託先の行動に根拠を持たせ、発注者が品質を管理できる状態をつくる仕組みです。これが保守運用の外部委託においてとりわけ重要になるのは、委託関係が長期にわたるため、品質が合意の範囲に収まっているかどうかを継続的に確認する必要があるからです。

SLAがないまま委託すると何が起きるか

SLAを設けずに保守運用を委託した場合に起きやすい問題を3つ整理します。

対応の遅延と根拠なき言い訳: 障害が発生しても、どのくらいの時間で初動対応すべきかが定まっていなければ、委託先の判断で優先度が下がることがあります。「別件が立て込んでいた」「重要度が低いと判断した」という説明を受けても、発注者には対抗手段がありません。

「範囲外」トラブルによる追加費用: 保守範囲が明文化されていないと、障害発生後に「その対応はSLA（契約）の範囲外なので別途費用が発生します」と言われるケースが生じます。発注者がシステムの内部構造に詳しくない場合、範囲外かどうかの判断自体が難しく、追加費用を受け入れざるを得ない状況に陥りがちです。

委託先変更の困難化: 品質水準の合意がなければ、「対応が遅い」「品質が低い」という感覚的な不満しか残りません。契約解除の事由として主張できる根拠がないため、委託先の変更交渉が難航することがあります。

SLA・SLO・SLIの最小限の整理

外部委託の場面で押さえておきたいのは以下の関係性です。

• SLI（Service Level Indicator）: 実際に測定する指標（例：稼働率のパーセンテージ、障害の初動時間）
• SLO（Service Level Objective）: SLIの目標値（例：稼働率99.9%）
• SLA（Service Level Agreement）: SLOを含む合意文書全体。未達時の扱い（料金減額など）も記載される

発注者が委託先と合意するのはSLAです。SLOはSLAの中に記載される目標値として機能します。SLIは委託先がSLOの達成状況を測定・報告するために使う指標です。SLAという言葉を使う際、この3層構造を意識しておくと、委託先との対話がスムーズになります。

外部委託のSLAで設計すべき5つの構成要素

保守運用SLAに盛り込む主要な要素を5つに整理します。これらは「委託先に任せる事項」ではなく、発注者自身が水準を決める対象です。委託先が提示する雛形をそのまま受け入れるのではなく、自社の要件を先に固めてから雛形と突き合わせるほうが、後の交渉が効率的になります。

サービス提供時間・受付時間（24時間か平日日中か）

「システムを何時から何時まで稼働させるか」と「障害発生時の問い合わせを何時から何時まで受け付けるか」を定めます。

• サービス提供時間: 24時間365日か、平日9〜18時かなど、システムの稼働時間帯
• 受付時間（サポート時間）: 障害発生の連絡を受け付ける時間帯。夜間・休日の障害は翌営業日対応でよいのか、即時対応が必要かを判断します

発注者が決めるべきは、自社のエンドユーザー（顧客や従業員）がシステムを使う時間帯と、業務の許容停止時間から、受付時間の範囲を絞り込むことです。ここは費用に最も直結する項目のため、後回しにせず最初に決めてしまうのが得策です。

稼働率（可用性）

年間または月間のシステム稼働時間の割合です。稼働率の具体的な水準の決め方はのちほど「自社に合ったSLA水準の決め方」の章で詳しく解説しますが、ここでは「何を決める対象か」を確認しておきます。

• 稼働率は「サービス提供時間中にシステムが正常に利用できる割合」として定義されます
• 計算の前提（メンテナンス時間の扱い、障害の定義）も合わせて合意が必要です

発注者が決めるべきは、自社の事業インパクトから逆算した稼働率の目標値と、その計算の定義（分母・分子）です。

障害レベル分類と対応時間・復旧目標時間

障害をレベル分けし、レベルに応じた初動対応時間（連絡を受けてから対応を開始するまでの時間）と復旧目標時間（MTTRなど）を定めます。

一般的な障害レベルの例は以下の通りです。

発注者が決めるべきは、自社のシステム特性に合ったレベル分類と、各レベルで許容できる対応時間の上限です。

作業範囲（保守範囲と範囲外の線引き）

何が「保守運用の範囲内」で、何が「範囲外（追加費用が発生）」かを明確にします。これが曖昧なまま委託を開始すると、後から「それは範囲外です」というトラブルが最も起きやすい箇所です。

典型的な範囲内の例: 定常監視、障害対応、セキュリティパッチ適用、定期バックアップ、月次報告

典型的な範囲外の例: 新機能開発、既存機能の大幅な改修、クラウドインフラの増強・再設計

保守と運用の役割区分そのものは保守と運用の違いで整理していますので、区分の詳細を確認したい場合はそちらを参照してください。また、契約類型（請負・準委任）ごとの記載事項は運用保守契約の種類と内容を参考にしてください。

発注者が決めるべきは、範囲内・範囲外の境界線を文章または表で具体的に列挙することです。「その他類似作業」のような包括的な文言は後のトラブル原因になるため避けます。

レポーティング・連絡体制・エスカレーション経路

• 定例レポート: 月次での稼働率・障害件数・対応実績などの報告形式と提出期限
• 連絡体制: 障害発生時の連絡先（担当者名・電話・メール・チャットツールなど）と、発注者側の受付窓口
• エスカレーション経路: 担当者で対応できない場合の上位窓口（管理職・経営層へのエスカレーションルール）

発注者が決めるべきは、誰が・何を・いつ・どの手段で報告するかの合意です。特に緊急障害時の連絡手段は電話など確実な手段を指定しておきます。委託先の担当者が休暇中でも連絡が取れる代替経路を最低1つは確保してください。

自社に合ったSLA水準の決め方——稼働率と対応時間を事業インパクトから逆算する

ここからが本記事の核心です。「結局、自社は何%・何時間に設定すればいいのか」という問いに、根拠を持って答えるための判断フローをお伝えします。

まず「止まると何が困るか」を整理する（事業インパクトの棚卸し）

稼働率や対応時間の水準は、「システムが停止したとき自社の事業に何が起きるか」という事業インパクトの大きさから決まります。以下の問いを整理することから始めてください。

停止の業務影響

• そのシステムが停止すると、どの業務が止まりますか
• 社内業務（従業員のみ影響）か、社外業務（顧客・取引先に影響）か
• リアルタイムに売上・決済が発生するシステムか、それとも時間をずらして処理できる業務支援システムか

許容できる停止時間

• 最大で何時間の停止なら業務を継続できますか（代替手段の有無を含めて）
• 月間・年間で何時間の停止なら事業継続上許容できますか

停止のコスト感

• 1時間停止した場合の機会損失・クレーム対応コストの概算はどのくらいですか
• 停止による信頼失墜のリスクはどのくらいですか（顧客向けサービスか内部ツールかで大きく変わります）

この棚卸しによって、どのレベルの稼働率・対応時間が必要かの判断材料が揃います。数字が出しにくい場合でも、「30分以内に復旧してほしい」「半日止まっても翌日にリカバーできる」といった感覚的な許容ラインは必ず言語化してください。

稼働率の早見表——99.9%は月何分のダウンタイムか

稼働率のパーセンテージは直感的に理解しにくいため、ダウンタイムに換算した早見表を示します。

（出典: 稼働率とダウンタイムの一般的な換算値。1年=365日、1ヶ月=30日で計算）

稼働率99.9%は「年間で約8.8時間の停止を許容する」という意味です。月換算すると約44分になります。この時間が許容できるかどうかを、自社の事業インパクトと照らし合わせて判断します。ECサイトのピーク時間に43分止まれば無視できない損失ですが、社内システムなら十分な水準です。

事業タイプ別の稼働率・対応時間の目安

自社のシステムが以下のどのタイプに近いかを確認した上で、目安を参考にしてください。あくまでも出発点であり、自社固有の状況に応じた調整が必要です。

EC・決済・予約系システム（売上直結）

• 稼働率: 99.9〜99.99%以上
• 緊急障害の初動: 30分以内
• 理由: 停止中は売上機会の損失が直接発生し、顧客信頼にも影響するため高い可用性が求められます

業務支援システム（社内の従業員利用）

• 稼働率: 99〜99.9%
• 緊急障害の初動: 2〜4時間以内（平日日中の場合）
• 理由: 代替手段（紙・電話など）が存在することが多く、許容停止時間が長くなります

情報提供サイト・コンテンツサービス（リアルタイム性が低い）

• 稼働率: 99〜99.9%
• 緊急障害の初動: 翌営業日以内
• 理由: 一時的な停止による直接損失が小さく、夜間・休日の即時対応は必要ないケースが多いです

インフラ・基盤システム（複数サービスが依存）

• 稼働率: 99.9〜99.99%以上
• 緊急障害の初動: 30分〜1時間以内
• 理由: 依存サービスへの波及影響が大きく、停止時間が長いほど影響範囲が拡大します

過剰なSLAはコストを押し上げる（水準と費用のトレードオフ）

稼働率は高ければ高いほどよいわけではありません。これは重要な点なので明確にお伝えします。

99.99%の稼働率を実現するためには、単純な冗長化では足りず、アクティブ・アクティブ構成のクラスター、複数データセンターへの分散、24時間365日のオンコール体制などが必要になります。これらは保守費用を大幅に押し上げます。

費用目安についてはシステム保守費用の目安と根拠で詳しく解説していますが、99.9%から99.99%への引き上げは、コスト構造を大きく変えることが多いです。

事業インパクトの棚卸しで整理した「自社が本当に必要とする水準」を超えた高い稼働率を要求することは、不要なコストを発注者が負担することにつながります。「できる限り高い稼働率」ではなく、「事業継続に必要な最低限の水準を根拠を持って指定する」ことが、発注者にとって合理的なSLA設計です。

過剰SLAを避けるための実務的なコツは次のとおりです。

• 事業インパクトと停止許容時間から必要水準を先に決め、後から委託先案と照合する
• 委託先に「99.9%と99.95%で費用がどう変わるか」を2〜3パターンで見積もらせる
• 一律の水準ではなく、業務時間帯と夜間・休日で水準を分ける（例：平日日中99.9%／夜間ベストエフォート）

委託先のタイプ別に変わるSLA設計の考え方

委託先のタイプによって、SLAに盛り込める範囲・現実的な水準・注意すべきリスクが異なります。委託先タイプを無視して同じ水準を要求すると、契約は成立してもSLAが早晩機能不全に陥ります。

SIer・専業運用会社に委託する場合

大手SIerや専業の運用管理会社は、複数の運用エンジニアによるシェアドサービスとして保守運用を提供することが多いです。

設計の特徴:

• 24時間365日対応や夜間監視が標準メニューとして提供されている場合が多い
• 緊急障害の初動30分以内、月間稼働率99.9%以上といった水準を盛り込みやすい
• 複数人体制のため属人化リスクが低く、担当者の離脱による品質劣化が起きにくい

注意点:

• 標準メニューのSLAをそのまま適用するため、自社固有の要件が反映されにくい場合があります。特に「自社システム特有の障害判定基準」や「業務上の優先度」は、標準テンプレートに上書きして合意しておく必要があります
• 費用水準は高くなりやすいため、稼働率の水準と費用のバランスを確認してください

開発ベンダーに保守運用を継続委託する場合

システムを開発したベンダーにそのまま保守運用を委託するケースは、内部構造への知識がある分、初期は対応品質が高くなる傾向があります。

設計の特徴:

• システムの内部仕様を把握しているため、障害の原因特定や修正が速い
• 開発チームと保守チームが同一または連携しているため、仕様変更・改修との境界がスムーズ

注意点:

• 専業運用会社と異なり、保守専属体制でないことが多く、開発案件が込み合うと保守対応が遅れるリスクがあります。SLAに「保守担当の専任体制またはそれに相当する応答保証」を明記しておくことを検討してください
• 担当エンジニアが退職・異動した場合の引き継ぎ体制（属人化リスク）も確認事項です

フリーランス・複業エンジニアに委託する場合（体制・属人化リスクへの備え）

フリーランスや複業エンジニアに保守運用を委託することは、コスト効率や柔軟性の面でメリットがあります。特に、開発から特定の技術領域までを深く理解している人材と契約できれば、業務単位で最適な依頼ができます。一方で、SLA設計は現実的な体制に合わせた調整が必要です。

設計の特徴:

• 個人の稼働時間は限られるため、24時間対応や30分以内の初動対応は現実的ではないケースが多い
• 「平日10〜18時の対応」「緊急時は4時間以内の初動」など、個人の稼働実態に合わせた水準に調整することが重要です
• 費用対効果が高く、業務支援システムや夜間対応が不要なシステムでは適した選択肢になります

注意点:

• 属人化リスク: 1名に委託している場合、その方が体調不良・案件変更・離脱した際のバックアップ体制がありません。SLAに「バックアップ要員の確保または引き継ぎ計画の提示」を盛り込むか、複数人体制での受注を条件にすることを検討してください
• 稼働保証の実効性: フリーランス・複業エンジニアは副業の場合も多く、本業の状況によって対応時間が変動するリスクがあります。契約前に月間の稼働時間と対応可能な時間帯を確認することが重要です

フリーランス・複業人材への委託でSLAの実効性を担保するには、次のような工夫が有効です。

• 対応時間帯を明確に絞る（例：平日9〜18時、夜間はベストエフォート）
• 複数人チームで契約する、または複数の契約先を並行して確保する
• ドキュメンテーション（構成図・運用手順書）の作成をSLAの一部に組み込み、属人化を計画的に解消する
• 一次対応と復旧対応を分け、一次対応は監視サービスと組み合わせる

複業人材やフリーランスへの委託は、体制設計と組み合わせて初めて機能します。「低コストで高いSLA」を単一の個人に押し付ける設計は必ず破綻するため、体制側で受け止める発想が必要です。

SLA設計でつまずきやすい3つの落とし穴

SLAを設計・締結した後でも、内容次第では実質的な保護が得られないことがあります。契約書に署名する前に、次の3点を必ずチェックしてください。

免責条項の空洞化に注意する

SLAには通常、委託先が責任を負わない例外事項が記載されます。代表的な免責事由は以下の通りです。

• クラウドサービス（AWS・GCP・Azureなど）の障害
• 第三者のAPIやサービスの障害
• 発注者側の操作ミスや設定変更
• 天災・感染症などの不可抗力

これらはある程度やむを得ない免責ですが、免責の範囲が広すぎると、SLAが実質的に無意味になることがあります。例えば、「委託先の管理下外の要因による障害はすべて免責」という条項が入っていると、現代のシステムはほとんどが外部サービスに依存しているため、ほぼすべての障害が免責対象になりかねません。

発注者が委託前に確認すべき質問:

• 過去1年間で、稼働率99.9%を計算するとき、どの障害が「免責対象」として除外されましたか
• クラウド事業者側の障害でも、委託先として一次調査・切り分け・報告までは行いますか
• 免責事由に該当する場合でも、初動確認・一次対応・エンドユーザーへの状況説明はSLAの範囲内に含まれますか

免責を全部否定するのは現実的ではありませんが、「どこまでを委託先の責任として扱うか」を具体化することが重要です。

ペナルティ（サービスクレジット）が機能するか確認する

SLAが未達だった場合のペナルティには大きく2種類あります。

• サービスクレジット型: 月額料金の一定割合を減額（例：稼働率が99%を下回った場合、月額の10%を翌月クレジット）
• 違約金型: 損害賠償として金銭を支払う

どちらが設定されているかを確認するとともに、以下の点を注意してください。

• サービスクレジットの上限: 「月額料金の30%まで」のように上限が設定されている場合、実際の損失額よりも大幅に小さいクレジットしか得られないことがあります
• 「努力します」止まりの記述: 「なるべく速やかに対応する」「可能な限り高い稼働率を維持する」という文言は、SLOの記載ではなく努力目標であり、未達時のペナルティが発動しません
• 損害賠償上限条項: 業務委託契約全体で「損害賠償の上限は月額料金の◯ヶ月分」といった条項が入っていることも一般的です。実際の事業損害額との差を確認してください

発注者が委託前に確認すべき質問: 「稼働率が○○%を下回った場合、具体的にどのような補償が発生しますか。その上限額と適用条件を教えてください」

1時間の停止で数百万円の売上損失が出るECサイトで、SLA未達時のクレジット上限が月額料金の30%（数万円）にとどまるなら、SLAは事業を守る仕組みとしては極めて薄いと言わざるを得ません。ペナルティ額を引き上げるか、あるいはペナルティ以外の効果（早期解除権、追加対応要員の無償投入など）で補うのが実務的な落としどころです。

作業範囲のグレーゾーンを契約前に潰す

「範囲外」トラブルは、実際の業務で最も多く発生する問題の一つです。典型的なグレーゾーンには以下があります。

• バグ修正は範囲内だが、バグ修正に伴う機能改善は範囲外
• 定常監視は範囲内だが、監視アラートの閾値変更は範囲外
• セキュリティパッチ適用は範囲内だが、パッチ適用に伴う動作確認は範囲外
• インフラの正常稼働は範囲内だが、クラウドリソースのコスト最適化は範囲外
• 外部API仕様変更に伴う修正対応は範囲内か

これらのグレーゾーンを契約前にリスト化し、範囲内か範囲外かを確認しておくことが重要です。範囲外と判断された場合の追加費用（時間単価・見積までのリードタイム）も同時に決めておくと、いざその場面が来たときにスムーズに判断できます。

発注者が委託前に確認すべき質問: 「過去に同様のシステムを保守した際、追加費用が発生したケースを教えてください。それは本契約の範囲内になりますか」

委託開始後にSLAを形骸化させない運用

SLAは締結した時点で終わりではありません。委託開始後に実効性を維持するための運用が必要です。

月次の定例レビューでSLA達成状況を確認する

委託先から月次のSLA達成状況レポートを受け取り、定例ミーティングで確認する仕組みを整えてください。最低限、以下の項目をレポートに含めるよう契約前に合意しておきます。

• 月間稼働率の実績値（計算根拠となるダウンタイム時間の内訳）
• 発生した障害の一覧（件数・レベル・発生日時・初動時間・復旧時間・原因）
• 各障害がSLAを達成しているかの判定
• SLA未達があった場合の原因分析と再発防止策
• 次月に向けた改善提案

このレポートを受け取るだけでなく、内容について委託先と対話する場を確保することが重要です。「レポートを受け取ったが内容を確認していない」という状態では、SLAは形骸化します。定例レビューを設けないと、SLAは契約書に書かれているだけの飾りになります。

SLA未達が続いたときの見直し・解除の判断

一度の未達で解除するのは現実的ではありませんが、未達が繰り返される場合の対応をあらかじめ決めておく必要があります。目安として次のような段階的な措置を契約に盛り込んでおくと有効です。

• 単月の未達: サービスクレジット適用、原因分析と改善策の提出
• 連続2ヶ月の未達: 改善計画書の提出、追加要員の無償投入
• 連続3ヶ月の未達、または重大な未達: 契約解除権の発動

段階を用意することで、いきなり解除するのではなく段階的なプレッシャーで委託先の改善を促せます。同時に、改善が見込めない場合の出口も確保できます。契約解除事由としてSLAの重大な未達を明記しておくと、いざというときの交渉が明確になります。

指揮命令ではなくSLA（水準）で品質を管理する

外部委託、特に準委任契約や業務委託契約では、発注者が委託先の担当者に直接業務指示（作業手順・作業時間の細かい指定）を行うと、偽装請負に該当するリスクがあります。フリーランスや複業エンジニアに委託する場合も同様です。

保守運用の品質を維持したいからといって、「今すぐこの対応をしてください」「◯時までに終わらせてください」といった指示を毎日のように送るのは、法的リスクだけでなく、委託先のモチベーションや自律性も損ないます。

外部委託における品質管理の原則は、「指揮命令ではなくSLAという水準で管理する」ことです。すなわち、次のような姿勢に切り替えます。

• 個別の作業手順ではなく、達成すべき成果水準（重大障害の一次応答15分以内、月間稼働率99.9%以上など）を合意する
• 進捗確認は「タスクの進み具合」ではなく「水準の達成状況」で行う
• 品質が水準を下回った場合の対応は、契約書に規定された手続き（改善計画・サービスクレジット・解除権）に沿って進める

障害発生時に「今すぐこのコードを修正してください」と細かく指示するのではなく、「P1障害の初動対応は30分以内というSLAに従って対応してください」という形で水準を基準に求めることが、適切な委託管理の形です。この切り替えができると、SLAは単なる契約書の一部ではなく、委託関係全体の運営原理として機能し始めます。

まとめ——運用実績ゼロからでもSLAは設計できる

本記事では、システム保守運用を外部委託する発注者が、SLAをゼロから設計するための手順を整理しました。要点を振り返ります。

• SLAは「効果を伴う取り決め」であり、未達時のアクションを事前に確定させる仕組み
• 盛り込むべき5要素は、サービス提供時間・稼働率・障害レベル別対応時間・作業範囲・レポーティング／連絡体制
• 水準は事業インパクトから逆算する。稼働率の早見表と事業タイプ別目安を組み合わせて過不足のない水準を選ぶ
• 委託先タイプ（SIer・専業運用会社／開発ベンダー継続／フリーランス・複業人材）ごとに、盛り込める範囲・現実的水準・体制リスクが異なる
• 免責条項の空洞化、ペナルティ上限、作業範囲のグレーゾーンは契約前に潰す
• 締結後は月次レビューで達成状況を管理し、指揮命令ではなくSLAという水準で品質を担保する

運用データがなくても、事業インパクトを起点にすれば自社に合ったSLAは十分に設計できます。次のアクションとしては、まず自社システムが1時間停止したときの損失を大まかに数値化してみてください。次に、RFPや見積依頼書に本記事で挙げた5要素を項目として盛り込み、複数の委託先候補から水準と費用の見積を取り、事業インパクトと照合します。委託先候補からSLA案を提示された段階では、免責条項・ペナルティ・作業範囲の3つの落とし穴を精査してください。

外部人材の活用形態は、SIer・開発ベンダー継続だけでなく、フリーランスや複業エンジニアといった選択肢が広がっています。委託先タイプ別のSLA設計を理解しておけば、コストと品質のバランスに応じて最適な組み合わせを選べるようになります。運用実績ゼロからでも、事業要件を起点にした逆算のプロセスさえ踏めば、自社に過不足のないSLAは必ず設計できます。