LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

保守SLA設計とは何か

保守契約のSLA設計とは、システム保守を外部パートナーに委託する際に、提供されるサービスの品質水準を数値と条件で事前に合意する一連のプロセスを指します。対応範囲・応答時間・復旧目標・未達時の罰則・解約時の引継ぎ要件を文書として定め、委託者とベンダーが共通の期待値を持てる状態にする取り組みです。

SLAとは——保守委託に必要なサービス品質の合意

SLA（Service Level Agreement、サービスレベル合意書）とは、情報サービスの提供者と利用者の間で交わす、サービス品質を定量的に定めた合意文書です。保守委託においては「稼働率〇%以上」「障害発生時の一次応答は〇分以内」「完全復旧は〇時間以内」といった指標と水準を記載します。

重要なのは、SLAは単独の文書ではなく、保守委託契約書の一部として機能させる点です。弁護士法人内田・鮫島法律事務所の解説によれば、ベンダーが単独でSLAを作成しても、契約書と紐づけられていない場合は当該SLAが法的拘束力を持たない可能性があるとされています^*1。SLAは保守委託契約書と連動させる設計が求められます。

なぜ外注前にSLAを設計するのか

外注前にSLAを設計することには、2つの実務上の意義があります。第一に、自社が求める品質水準を明文化することで、複数のパートナー候補を同一基準で評価できます。第二に、SLA草案をRFP（提案依頼書）に添付することで、ベンダーの対応力と誠実さを確認する選定軸として機能します。

逆に、SLA設計をベンダーに丸投げすると、ベンダーにとって達成しやすい水準のみが盛り込まれるリスクがあります。自社の業務特性（ピーク時間帯・障害許容度・復旧優先度）を踏まえた設計は、委託者側が主導して行うことが実務上の鉄則です。

対応範囲の決め方——何を保守するかを明確化する

対象システム・業務の明確化

SLA設計の出発点は、保守の対象を精確に定めることです。「サーバ」「アプリケーション」「ネットワーク」「データベース」といったシステム層ごとに対象範囲を列挙し、それぞれについて「監視のみ」か「障害対応まで含む」かを区分します。

対象が曖昧なまま契約すると、障害発生時に「この作業は保守範囲外」という解釈の相違が生じます。ITシステムアウトソーシングのSLA設計ガイドでは、「対象システム・業務の明確化」がサービス範囲として最初に記載すべき事項と位置づけられています^*2。システム名・バージョン・ホスト数・担当業務を表形式で列挙することが推奨されます。

対応時間帯・休日対応の設定

対応時間帯はSLAの費用対効果を左右する主要因です。「平日9時〜18時のみ」「24時間365日」「平日夜間・土日は二次対応のみ」など、業務の重要度に応じて設定します。対応時間帯が広がるほど委託費用は上昇するため、システムごとに業務影響度を整理したうえで設定することが重要です。

特に注意が必要なのは「緊急連絡体制」の明記です。障害発生時に誰がどの手段（電話・メール・チャットツール）で何分以内に初報を行うかを具体的に定めます。この連絡体制があいまいな場合、障害発生から初報までの時間が計測不能となり、SLA評価自体ができなくなります。

対応範囲をIPA非機能要求グレードで体系化する

IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード2018」は、システムの非機能要求を可用性・性能・拡張性・運用・移行・セキュリティの6大分類・34中分類・116小項目・238指標に体系化したツールです^*3。保守SLAの対応範囲を設計する際に、この体系を参照することで網羅性が高まります。

特に「可用性」分類には、稼働率・計画停止・バックアップ取得・リカバリ目標（RTO・RPO）などSLA設計に直結する指標が整理されています。非機能要求グレードは2018年公開のアーカイブ資料ですが^*3、保守SLA設計の体系整理として現在も実務で参照されています。

応答・復旧目標の数値化——稼働率と優先度別タイムライン

稼働率（可用性）の設定

稼働率はSLAの中核指標であり、「システムが稼働している時間の割合」として定義されます。一般的な設定水準として、一般業務システムでは99.5〜99.9%、ECサイトや基幹システムでは99.9%、金融・医療など高可用性が求められるシステムでは99.99%以上が参考値として使われます（いずれも市場参考値であり、一次資料ではありません）。

稼働率の水準を高く設定するほど、インフラ冗長化・24時間監視体制・即応対応など委託費用が増加します。業務への影響度を「障害が〇時間継続した場合の事業損失」として試算し、その水準に見合った稼働率目標を設定することが現実的な設計手順です。

優先度（Priority）別の応答・復旧時間

保守SLAでは、障害の重大度に応じた優先度（Priority）を定義し、各優先度ごとに「応答時間（初報）」と「復旧時間（解決）」を数値化します。障害の重大度に応じて応答・復旧の目標を段階的に設定します。以下は一般的な設計例で、実際の数値はシステムの重要度に応じて双方で合意します（市場参考値であり、一次資料ではありません）。

出典：BTNコンサルティング「IT運用アウトソーシングのSLA設計ガイド」（2026年3月）の考え方を参考に独自に構成した設計例。実際の数値はシステムの重要度と委託費用を踏まえて双方で合意すること。市場参考値であり、一次資料ではありません。

数値水準の選び方と外注コストへの影響

SLA数値を高く設定するほど委託費用が上昇します。特に「P1の復旧時間を4時間以内」から「2時間以内」に変更する場合、オンコール体制の強化や冗長構成の追加が必要になり、費用は大きく変わる可能性があります。

費用対効果を判断するには、「障害が〇時間続いた場合の業務損失額」と「SLA水準を上げた場合の追加費用」を比較する方法があります。この試算を外注前に行っておくと、ベンダーとの交渉においても根拠ある水準設定が可能になります。なお、具体的な費用額は委託規模・システム複雑度・ベンダーの体制によって異なるため、見積もり段階で確認してください（市場参考値であり、一次資料ではありません）。

罰則・ペナルティ条項の設計——努力目標型と確約型の違い

SLAの法的性質——努力目標型と確約型

SLAの法的性質は、契約書への組み込み方によって大きく異なります。弁護士の坂生雄一氏の解説によれば、SLAの法的効力は主に3類型に分類されます^*4。

• 努力目標型：SLAで定めた水準の達成を「努力する」と定める。未達でも直ちに契約違反にはならない
• 商業的合理性型：「商業的に合理的な努力をもって達成する」と定める。達成不可能な場合は違反とならないが、努力の怠りは問われる
• 確約型：指定水準を達成することを契約上の義務として定める。未達は原則として契約違反となり得る

保守委託においてSLAを実効的にするには、確約型または商業的合理性型で記載し、未達時の措置を明記することが重要です。「SLAは単なる努力目標」という設計では、品質トラブル発生時に委託者が損失を補填できない状態になります。

未達時の措置（クレジット返金・利用料減額）の設計

SLA未達時の措置として実務でよく使われるのは、「月額委託費用の一定割合を返金するクレジット方式」です。IT法務の専門家の解説では、「利用料金を減額するといった具体的な効果が定められている例もあれば、特段の効果を生じさせない（SLAは単に努力目標を定めたのみ）というものもあります」^*1とされており、措置の内容は契約書に明記することが必要です。

クレジット率の設計においては、稼働率の未達度合いに応じて段階的に設定する方法が一般的です。たとえば「稼働率が99.5%を下回った場合は月額費用の10%を返金、99.0%を下回った場合は20%」のような形が参考例として挙げられます（市場参考値であり、一次資料ではありません）。損害賠償の上限額についても、「月額委託費用の〇か月分を上限とする」といった条項を設けることが通例です。

IPAモデル契約書に見るSLA規定の実務

IPA（独立行政法人情報処理推進機構）が公開している「情報システム・モデル取引・契約書（第二版）」（2020年12月公開・2025年4月更新）は、受託開発・保守運用を対象としたモデル契約書です^*5。民法改正に対応した内容を含み、セキュリティ・プロジェクトマネジメント義務・協力義務の明確化が盛り込まれています。

同資料はWord形式でダウンロードでき、自由にカスタマイズして使用できます。保守委託契約書の雛型として参照し、そのなかのSLA関連条項（サービスレベルの設定方法・未達時の扱い等）を自社の実情に合わせて修正する活用が実務上有効です。

解約・引継ぎ条項の決め方

解約時データ返却と引継ぎ期間の明記

保守委託契約において、解約時の対応を事前に定めておくことは、SLA設計と同様に重要です。委託期間中に蓄積した監視ログ・障害対応記録・設定変更履歴などのデータを、どの形式でいつまでに返却するかを契約書に明記します。

IT運用アウトソーシングのSLA設計の観点からは、「契約終了時のデータ返却・引き継ぎ期間を明記する」ことが交渉ポイントとして示されています^*2。引継ぎ期間は一般に1〜3か月程度が参考値として挙げられますが（市場参考値であり、一次資料ではありません）、システムの複雑度によっては長期化することもあります。契約締結時に最低引継ぎ期間と費用負担者を合意しておくことが肝要です。

知識移転（ドキュメント・運用手順書）の要件化

引継ぎで問題になるのは、ベンダーの担当者のみが把握している「暗黙知」です。障害対応の手順・定期メンテナンスの内容・構成変更の履歴といった情報が文書化されていない場合、引継ぎ完了後に新ベンダーまたは内製チームが実務を引き継げない事態が生じます。

これを防ぐには、SLA文書または保守委託契約書の附属文書として「引継ぎドキュメントの要件」を定めることが有効です。具体的には、システム構成図・運用手順書・インシデント対応フロー・設定台帳・定期作業一覧を「引継ぎ成果物」として列挙し、更新頻度と保管場所も定めます。

引継ぎ不備が招くリスクと防止策

引継ぎ不備の典型的なリスクは、「旧ベンダーが離脱した後にシステムの挙動が理解できない状態になる」ことです。ベンダーロックイン（特定のベンダーなしには運用できない状態）を防止するには、運用ドキュメントの整備を委託開始時から義務化することが予防策になります。

内製チームへの引継ぎを想定する場合は、必要なスキルセット（サーバOS管理・監視ツール操作・インシデント対応手順）を洗い出し、習熟に必要な期間を逆算して引継ぎ計画を作ることが実務上の手順です。自社に該当スキルを持つ人材がいない場合は、引継ぎ支援を含めた新ベンダーへの再委託や、元請（プライムベンダー）への一本化を検討する選択肢があります。

外注パートナー選定でSLA設計力を見極める

SLA草案提示力を確認する

保守委託のパートナーを選定する際、自社でSLA草案を作成してRFPに添付し、各候補ベンダーに「このSLAに対応できるか・どのような条件で達成可能か」を提案してもらう方法は、設計力を見極める有効な手段です。

SLA草案への対応時に確認すべき点は3つあります。第一に、記載した指標すべてに対して具体的な対応方法を示せるか。第二に、実現困難な水準に対して代替案や段階的な達成計画を提示できるか。第三に、未達時のクレジット条項や解約引継ぎ条項に対して前向きに合意できるかです。

これらに明確に答えられないベンダーは、SLA実績や体制が不十分である可能性があります。SLA対応の丁寧さは、実際の保守運用における誠実さと相関することが実務上指摘されています。

元請（プライムベンダー）への委託が有効な理由

保守SLAを外注で設計・運用する際、元請（プライムベンダー）への一本化には実務上の利点があります。元請（プライムベンダー）は複数の下請けベンダーを管理しながら委託者に対して一元的に責任を持つため、SLAの当事者が明確になります。複数の保守ベンダーが混在するマルチベンダー構成では、障害発生時に責任所在が曖昧になりやすく、SLAの測定も複雑になります。

元請（プライムベンダー）に一本化することで、SLAの管理窓口が一つになり、未達時のクレジット算定や解約交渉もシンプルになります。

保守委託のSLA設計において自社に専門知識がない場合は、SLA草案作成の段階から元請（プライムベンダー）と協力して設計することを検討してください。SLA条項を含む契約書のレビューには、IT案件に知見のある弁護士または法務専門家への確認も合わせて行うことを推奨します。

まとめ：SLA設計を成功させる3つの判断軸

本稿では、保守契約のSLA設計を外注で進めるための手順を整理しました。要点を3つに集約します。

第一に、SLAは「対応範囲・応答復旧目標・罰則条項・解約引継ぎ要件」の4軸を揃えて初めて機能します。1つでも欠けると、障害発生時や契約終了時に判断の根拠が失われます。第二に、SLAの法的性質を「努力目標型」ではなく「確約型」として契約書に組み込むことで、品質トラブル時の損失補填が現実的になります。第三に、外注パートナーの選定前にSLA草案を自社で用意しておくことが、ベンダーの実力と誠実さを評価する実践的な手段になります。

SLA設計は外注前の「投資」です。設計に要する時間と労力が、委託後のトラブル対応コストを大幅に下回ることは実務上広く認識されています。IPA公開のモデル契約書とIPAの非機能要求グレードを参照軸として活用しながら、自社の業務特性に合ったSLAを設計することをお勧めします。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：弁護士法人内田・鮫島法律事務所「SLAに関する注意点」
2. *2　出典：BTNコンサルティング「IT運用アウトソーシングのSLA設計｜サービスレベル合意書の作り方と交渉ポイント」（2026年3月）
3. *3　出典：IPA（独立行政法人情報処理推進機構）「非機能要求グレード」（2018年）
4. *4　出典：弁護士 坂生雄一「サービスレベルアグリーメント（SLA）の未達は契約違反なのか」（2020年12月）
5. *5　出典：IPA（独立行政法人情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2020年12月公開・2025年4月更新）

Tweet