ITサービスの品質をどう「約束通り」に保つか。
その鍵を握るのがSLM（サービスレベル管理）です。本記事ではSLMの定義、SLAとの違い、PDCAでの運用イメージまでを、未経験者でも掴めるように整理します。
対象試験と出題頻度
SLM（Service Level Management）は、基本情報技術者・応用情報技術者で出題されるサービスマネジメント領域の定番テーマです。
ITILやJIS Q 20000の枠組みで語られることが多く、特にSLA（サービスレベル合意書）・SLO・OLA・UCといった近接用語との区別が問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「SLMってSLAと何が違うの？合意書のこと？管理のこと？」と混乱しがちです。
SLM（Service Level Management／サービスレベル管理）とは、一言で言うと
「提供するITサービスの品質を、顧客と合意した水準で維持・改善し続ける管理プロセス」
のことです。
イメージとしては、「スポーツジムのパーソナルトレーナー」です。
会員と「3か月で体脂肪を◯％落とす」という目標（=合意）を結び、毎週測定し、停滞すればメニューを見直す。
この「目標設定→測定→改善」を回し続ける役割こそがSLMにあたります。約束した数値そのものではなく、約束を守らせる活動の方を指す点がポイントです。
📊 SLMの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Service Level Management |
| 分類 | サービスマネジメントプロセス（ITIL／JIS Q 20000） |
| 目的 | 合意した品質水準の維持と継続的改善 |
| 中心となる文書 | SLA（サービスレベル合意書） |
解説
ITサービスは「動いていれば良い」という時代を過ぎ、稼働率・応答時間・障害復旧時間など、数値で品質を約束する取引が主流になりました。
しかし、約束しただけでは品質は守られません。誰かが定期的に測定し、未達なら原因を分析し、改善策を打つ必要があります。
その「約束を守らせる仕組み」を担うのがSLMです。
SLM・SLA・SLO・OLA・UCの関係
SLMを理解する最大の山場が、よく似た略語の整理です。試験ではここを混同させる選択肢が頻出します。
| 略語 | 正式名称 | 役割 |
|---|---|---|
| SLM | Service Level Management | 品質を維持・改善する「活動・プロセス」そのもの |
| SLA | Service Level Agreement | 提供者と顧客の間で結ぶ「合意文書」 |
| SLO | Service Level Objective | SLA内で定める個別の「目標値」（例：稼働率99.9%） |
| OLA | Operational Level Agreement | 同じ組織内の部門間で結ぶ運用上の合意 |
| UC | Underpinning Contract | 外部供給者（ベンダー等）と結ぶ契約 |
ポイントは、SLMが「箱（プロセス）」、SLAはその中で扱う「書類」であるという階層関係です。SLAはSLMの成果物の一つに過ぎません。
SLMを取り巻く文書の階層
SLM（プロセス）が束ねる3つの合意
SLA
対 顧客
OLA
対 社内部門
UC
対 外部ベンダー
▲ SLAを支えるためにOLAとUCがあり、3つをまとめてSLMが面倒を見る
SLMはPDCAで回す
SLMの実務はPDCAサイクルに当てはめると整理しやすくなります。
| 段階 | 活動 | 具体例 |
|---|---|---|
| P | サービスレベル項目と目標値の合意 | 稼働率99.9%、平均応答1秒以内などをSLAに明記 |
| D | 合意水準でのサービス提供と運用 | 監視ツールで稼働状況・応答時間を常時計測 |
| C | 実績の測定とレビュー | 月次サービスレビュー会で達成・未達成を報告 |
| A | サービス改善計画（SIP）の実行 | サーバ増強、運用手順見直しなどで未達を解消 |
代表的なサービスレベル項目
SLAに盛り込まれる代表的な数値項目は次の通りです。グラフのイメージは「目標ライン」と「実績」を比較する形で可視化されます。
📈 月次サービスレビューでよく見るグラフ（稼働率のイメージ）
99.95
99.92
99.75
99.97
99.93
▲ Y軸は99.5%〜100%にズーム。3月のみ目標ライン（99.9%）を下回り未達 → 原因分析と改善計画（SIP）に着手するのがSLMの仕事
代表的なサービスレベル項目（例）
稼働率／平均応答時間／障害復旧時間（MTTR）／障害発生間隔（MTBF）／オンライン応答率／問い合わせ一次回答時間／セキュリティインシデント件数 など。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 SLMの核心を3行で
・SLMは「品質を合意水準で維持・改善する管理プロセス」、SLAは「その合意を書面化した文書」
・PDCAで回し、Aの段階ではサービス改善計画（SIP）を実行する
・周辺文書としてOLA（社内）、UC（外部ベンダー）があり、SLAを下支えする
試験ではこう出る！
SLMは基本情報・応用情報のサービスマネジメント分野で繰り返し出題されてきました。問われ方には決まった型があります。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R元秋 午前 問55 |
SLMにおける改善活動として適切なものを選ぶ。 | 「目標未達の項目について改善策を実施する」が正解。合意自体の引き下げや一方的変更はNG。 |
| FE R元秋 午前 問57 |
SLAに記載する内容として適切なものを選ぶ。 | 「サービス提供者と顧客が合意したサービス品質の内容」が正解。 |
| AP H29春 午前 問55 |
SLMで定期的に実施する活動を選ぶ。 | サービスレベルの実績報告とレビューが正解。インシデント対応や構成管理は別プロセス。 |
📝 IPA試験での出題パターン
パターン1：「SLMとSLAの違いを問う」
SLMを「文書のこと」と書いた選択肢、SLAを「改善活動のこと」と書いた選択肢が混在する。プロセス（活動）か文書かで一発で切れる。
パターン2：「改善のあり方を問う」
未達時に「目標値を引き下げて達成扱いにする」「顧客に通知せず仕様を変える」などの不適切選択肢が並ぶ。正解は原因分析と改善策の実施、つまりサービス改善計画（SIP）の実行。
パターン3：「他プロセスとの切り分け」
インシデント管理（復旧優先）、問題管理（恒久対策）、構成管理（CI記録）と混同させる選択肢が出る。SLMは「品質水準そのものを管理する」のが守備範囲。
頻出キーワードは「合意」「レビュー」「改善計画（SIP）」「実績報告」。この4語が出てきたらSLMを疑うのが鉄則です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. SLM（サービスレベル管理）の説明として、最も適切なものはどれでしょうか？
- A. 提供するITサービスの品質を顧客と合意した水準に保ち、実績の測定とレビューを通じて継続的に改善していく管理プロセスである。
- B. ITサービスに用いられるハードウェア・ソフトウェア・ドキュメントなどの構成情報を一元的に記録・管理し、変更時の整合性を保つプロセスである。
- C. ITサービス停止の原因となる事象が発生した際に、サービスを可能な限り早く正常な状態に復旧することを目的とするプロセスである。
正解と解説を見る
正解：A
解説：
SLMの本質は「合意水準を維持し、未達なら改善する」プロセスである点です。実績の測定とサービスレビュー、サービス改善計画の実行までを一連の活動として担うため、選択肢Aが正解となります。
選択肢Bは構成管理（Configuration Management）の説明です。CI（構成アイテム）を記録・管理する別プロセスであり、品質水準の合意・改善は守備範囲外です。選択肢Cはインシデント管理の説明です。「とにかく早く復旧」を目的とするプロセスで、恒久対策を担う問題管理や、品質水準を扱うSLMとは目的が異なります。
よくある質問（FAQ）
Q. SLAの目標値（稼働率99.9%など）はどう決めるのが妥当ですか？
「顧客が業務上必要とする水準」と「提供者が現実的に達成できる水準」のすり合わせで決めます。高すぎる数値は冗長構成や24時間体制のコストを跳ね上げ、低すぎる数値は顧客の業務影響を吸収できません。一般にミッションクリティカル系は99.99%以上、社内業務系は99%前後が目安です。実務では過去の稼働実績データを根拠に交渉します。
Q. SLAの未達が続いた場合、ペナルティは発生しますか？
多くの契約で発生します。代表的なのは「サービスクレジット」と呼ばれる利用料の一部返金・割引です。クラウドサービス（AWS、Azure、Google Cloudなど）では稼働率の達成水準ごとに返金率が明記されているのが一般的です。試験では細かい返金率までは問われませんが、「未達時の補償条項もSLAに含まれる」点は押さえておくと安心です。
Q. SLMとSREのSLO/エラーバジェットはどう違いますか？
出自が異なります。SLMはITIL／JIS Q 20000由来の「契約・運用プロセス」を重視する考え方で、文書としてのSLAが中心です。一方、Google発のSRE（Site Reliability Engineering）は「達成すべき信頼性目標（SLO）」と「許容できる未達量（エラーバジェット）」を運用判断に直結させるエンジニアリング寄りのアプローチです。視点の違いはあるものの、目標値を測定・改善するという根幹は共通しています。
Q. SLAは一度結んだら変えてはいけませんか？
変更可能です。むしろビジネス環境や利用状況の変化に合わせて定期的に見直すことが推奨されます。重要なのは「双方の合意を得たうえで改訂する」プロセスを踏むこと。提供側が一方的に水準を下げて達成扱いにするのは不適切とされ、過去問でも誤答選択肢として頻出します。
