【完全ガイド】SLA設計の罠と定義項目一覧｜クラウド×オンプレの責任分界点

「稼働率99.99%を保証してほしい」——事業部門や顧客からのこうした要求に、頭を悩ませた経験はないでしょうか。

特にパブリッククラウドとオンプレミスを組み合わせたハイブリッド環境では、クラウド事業者の「金銭返金型SLA」とオンプレミスの「パーツ駆け付け保守」という全く異なる可用性モデルが混在するため、SLA（サービスレベル合意書）の設計が極めて複雑化します。

本記事では、インフラの要件定義や運用設計を主導するリードエンジニア・システムアーキテクトに向け、実務でそのまま使える「主要SLA項目一覧表」から、現場で血を流さないための「4つの罠と対策」、そして事業部門と無理のない条件で折り合いをつけるための合意形成手順までを体系的に解説します。

ハイブリッド環境でSLA設計が迷走する2つの原因

今日のエンタープライズシステムにおいて、パブリッククラウド（AWS/Azure/Google Cloud）とオンプレミス（自社データセンター・プライベートクラウド）を組み合わせたハイブリッドクラウド構成は一般的な選択肢となっています。

しかし、多くの現場において「SLA（Service Level Agreement：サービスレベル合意）」の策定・運用は困難を極めます。

① ビジネス要求とインフラ現実に生じるギャップ

事業部門（ビジネスサイド）は、インフラの物理構造にかかわらず「システムは24時間365日止まらないこと（稼働率99.99%以上）」を当然のように要求します。

一方で、インフラエンジニアは予算・技術・保守契約の制約の中で可用性を設計しなければなりません。この双方の認識差が、障害発生時の責任追及や過剰投資の要因となります。

⚠️ ハイブリッド環境におけるSLA設計の根本的難しさ

「クラウド側の金銭保証型SLA」と「オンプレ側のHW部品駆け付け保守（MTTR目標）」という、全く性質の異なる2つの可用性モデルを一つのサービスSLAとして統合・再構築しなければならない点にあります。

② SPOF（単一障害点）が集中する「接続境界」の問題

クラウドとオンプレミスを結ぶ専用線（DirectConnect / ExpressRoute）やIPsec VPN、境界ルーター、ファイヤーウォール群は、システム全体の最大の弱点（SPOF）になりがちです。

クラウド基盤がどれだけ高可用であっても、境界ネットワークの冗長化やSLAが不十分であれば、システム全体としての可用性は著しく低下します。

SLA・SLO・SLIの違いとクラウド/オンプレ保守の決定的な差

ハイブリッド環境において実現可能なSLAを策定するためには、まず概念の整理と各レイヤーでの定義が必要になります。

クラウドSLAとオンプレ保守の「決定的な違い」

パブリッククラウドのSLAは「可用性が規定値を下回った場合の利用料返金（クレジット）」を約束する契約概念です。

一方、オンプレミスのハードウェア保守契約（例：24時間365日 4時間オンサイト保守）は「保守要員や交換部品の手配スピード」に関するサービス目標です。

この性質の違いを理解せずにSLAを設計すると、復旧時間（RTO）の計算で破綻します。

SLA・SLO・SLIの役割定義

リードエンジニアは、次の3つの概念を明確に区別して設計・運用に落とし込む必要があります。

• SLI（Service Level Indicator / サービスレベル指標）：何を計測するか（例：HTTP応答時間、外監視でのレスポンス成功率、エラー率）。
• SLO（Service Level Objective / サービスレベル目標）：現場運用チームが目指す内部数値（例：月間成功率99.95%以上）。SLAより厳しい値を設定する。
• SLA（Service Level Agreement / サービスレベル合意）：ビジネス側や顧客と結ぶ対外的な契約約束値（例：月間99.9%）。未達時のペナルティや返金規定を伴う。

💡 関連記事：システムの稼働率計算について

直列・並列接続時の合成可用性（SLAの積算計算）や、稼働率99.9%・99.99%における年間/月間の許容停止時間シミュレーションについては、別記事『【技術解説】システムの稼働率・許容停止時間の計算ガイド』にて詳しく解説しています。

【一覧表】インフラ基盤で定義すべき主要SLA項目

ハイブリッド環境のインフラ設計時に定義すべき主要SLA/SLO項目と、オンプレ・クラウド別の考慮事項を整理したマトリクスです。

カテゴリ	定義項目	オンプレミス側の定義軸	パブリッククラウド側の定義軸	推奨設定値の考え方
稼働率	月間サービス稼働率	HW/OS/ネットワークの通電・疎通時間（計画停止を除く）	マルチAZ構成時におけるAPI/インスタンス応答率	99.9% 〜 99.99%（構成の積算結果に基づく）
性能・応答	エンドツーエンドレイテンシ	LAN内遅延（<5ms）、ストレージI/O（IOPS/Wait時間）	リージョン間遅延、APIスロットリング、CDNキャッシュ率	p95 < 500ms（外監視による計測）
障害復旧	RTO（目標復旧時間）	ハードウェア保守オンサイト時間（例: 4時間駆け付け）	Auto Scaling / スナップショットからの再作成時間	1時間 〜 4時間（ビジネス損失許容度依存）
データ保護	RPO（目標復旧地点）	日次/週次スナップショット、テープ/NASバックアップ周期	レプリケーション遅延（Aurora/RDS等）、ポイントインタイムリカバリ	15分 〜 24時間（データ同期ギャップ許容値）
監視・通知	障害検知〜一次報告時間	Zabbix/Prometheus検知 ＋ オペレーター電話通知時間	CloudWatch/Datadogアラート ＋ PagerDuty連携自動通知	15分以内
保守運用	計画停止（メンテナンス）	年1回のデータセンター定期法定点検（停電）、機器FW更新	ベンダー起因の不可避なメンテナンス通知（通常14日前通知）	事前に双方合意した窓口・ルール

SLA運用で失敗しないための「4つの罠と対策」

罠①：クラウド事業者のSLAは「稼働の保証」ではなく「返金ルール」

「AWSが99.99%のSLAを掲げているから安心」というのは最大の誤解です。

クラウド事業者のSLAは、達成できなかった場合に「翌月利用料の10%〜30%をサービスクレジットとして返金する」という契約上の手打ルールに過ぎません。

障害によって発生したビジネスの売り上げ損失や社会的な信用失墜に対して、クラウドベンダーは一切の補償を行いません。

罠②：計測地点（SLI）のブレが生む「SLA達成」と「顧客不満」のギャップ

「クラウドの仮想サーバーは正常稼働（SLA達成）しているが、ハイブリッド接続ルーターでパケットロスが発生し、ユーザーは画面を開けない」という事態は頻発します。

サーバー内部のCPU/メモリ監視だけでSLA/SLIを判定すると、現場の感覚と乖離します。SLAの測定は必ず「外監視（Synthetics Monitoring）によるユーザー体感レスポンス」を主軸に置く必要があります。

罠③：計画停止（メンテナンス）の定義と除外条項の曖昧さ

オンプレミス環境の定期電源点検や機器更新による計画停止時間を、SLAの母数（分母）から除外するか否かを明確に文章化しておかないとトラブルに発展します。

「事前通知（例: 10営業日前）を行った計画メンテナンスはSLA不稼働時間から除外する」旨を明確に合意しておくことが重要です。

罠④：ハードウェア保守SLAとサービス復旧（RTO）の混同

オンプレミスのサーバー保守契約で「24時間365日 4時間オンサイト保守」を契約していても、それは「パーツを持った保守エンジニアが4時間以内に現場に到着する」ことを意味するだけであり、「4時間以内にシステムが復旧する」わけではありません。

ハードウェア交換後のデータリストアやOS・DBリカバリ時間（RTO）を含めた運用設計を別途行う必要があります。

事業部門とSLAを合意形成する5つの手順

結論：インフラリードに求められるマインドセット

ハイブリッド環境におけるSLA設計とは、単に契約書に数値を書き込む作業ではありません。それは「システムの脆さを正しく認識し、リスクとコストのバランスを事業部門と合意するプロセス」そのものです。

「絶対に壊れないインフラ」は存在しません。リードエンジニアに求められるのは、パブリッククラウドとオンプレミスのそれぞれの特性と制約を数学的・運用的に捉え、「万が一壊れても、あらかじめ合意された許容時間内（SLA/SLO）に確実に回復できるアーキテクチャと運用体制」を作り上げることです。