サービスマネジメント｜SLA・インシデント管理・サービスデスクと稼働率の計算【ITパスポート】

ITパスポート 第1部 ビジネス変革4-1　サービスマネジメント最終更新 2026-10-18

サービスマネジメントは、ITサービスを利用者が約束どおりに使える状態に保ち、その品質を少しずつ上げていくための、組織の活動と仕組みです。

サービスの価値と、サービスマネジメント

ITを使って利用者に価値を届けるものがITサービスです。その価値は価格・機能・保証の3つの釣り合いで決まります。

「他のソフトと連携できる」はできることが増える話なので機能、「無料で使える」は価格です。 「24時間365日使える」「同時に大勢が使っても遅くならない」「不正に読まれない」は、どれも約束どおりに使えるかの話です。 いつでも・止まらず・安全に使えることは、機能ではなく保証の側に入ります。

ITサービスマネジメントは、人材・プロセス・情報技術を組み合わせ、提供しているITサービスが事業のニーズを満たすように、サービスの計画立案・設計・移行・提供・改善を継続的に改善しながら管理する活動です。 よい事例を集めた枠組みが ITIL、この活動を管理する仕組み全体がサービスマネジメントシステム（SMS）で、PDCA で回して継続的改善を続けます。 似た名前のシステム監査は独立した立場で点検・評価する活動、ヒューマンリソースマネジメントは人材の活動、ファシリティマネジメントは建物や設備の活動です。

SLAとサービスレベル管理

SLA（Service Level Agreement、サービスレベル合意書。サービスレベル契約とも訳します）は、顧客とサービス提供者のあいだで、 提供するサービスの内容と品質の目標値を取り決めた合意文書です。 稼働率や受付時間、復旧時間などを数値で決めて書き込み、提供者はそれを測って品質を改善していきます。 結ぶのは、できあがったサービスを使う側と、運用して提供する側です。システムを作る段階の発注者と受託者の取り決めではありません。 約束する目標値を SLO、実際に測る指標を SLI と呼び分けることもあります。

サービスレベル管理（SLM）は、SLA の計画立案、サービス内容の交渉、草案作成、合意、導入、測定までを受け持ち、 結果を顧客に報告して（サービスの報告）、品質を維持・改善する活動です。 SLA は合意した「文書」、SLM はそれを作って守らせる「活動」です。 「合意に用いる文書」なら SLA、「遵守状況を確認して品質を維持・改善する活動」なら SLM です。

SLA に書く項目は、それを受け持つ管理と結びついています。

稼働率から、止めてよい時間を出す

SLA でいちばんよく使う数値が稼働率（可用性）です。 稼働率は、合意したサービス提供時間のうち、実際に利用者が使えた時間の割合です。

稼働率
  ＝ 実際に使えた時間 ÷ 合意したサービス提供時間

ここから、止まってもよい時間を逆算できます。 平日（月曜日から金曜日）の9時から18時まで提供し、稼働率99%以上で合意したサービスなら、1週間では次のとおりです。

1日の提供時間
  18時 − 9時 ＝ 9時間
1週間の提供時間（平日の5日）
  9時間 × 5日 ＝ 45時間
止まってもよい割合
  100% − 99% ＝ 1%
止まってもよい時間
  45時間 × 0.01 ＝ 0.45時間（27分）

分母にするのは合意した時間だけです。24時間や7日で数えません。

稼働率の分母は「24時間・7日」ではなく、SLA で合意した提供時間です。 日数の数えまちがいと、1日分で止めてしまうのが典型的な誤りです。

稼働率の計算だけを5つの形でまとめ、数字を入れると途中の式まで出る計算機を置いたページもあります ── 稼働率の計算。

インシデント管理と、問題管理・変更管理・構成管理

インシデントは、サービスの計画外の中断や品質の低下です。インシデント管理の目的は、中断しているサービスを可能な限り迅速に回復させることで、 原因が分からなくても一時的な回避策で利用者が仕事を続けられるようにするのが先です。 インシデント管理の目的は原因を突き止めることではなく、サービスを早く元に戻すことです。

原因を調べるのは、別の管理の仕事です。

問題管理は根本原因を突き止めて再発を防ぐ、変更管理はサービスへのすべての変更を一元的に管理する、 構成管理は組織が持つIT資産の情報を最新で正確に保つ管理です。 このほか、承認された変更を本番の環境に組み込むリリース及び展開管理、障害ではない依頼（パスワードの再発行など）に応えるサービス要求管理があります。 新しいサービスを本番に移す（サービスの移行）前には、受け入れて運用を始める条件であるサービス受入れ基準を満たしているかを確かめます。

同じトラブルに、3つの手

在宅勤務で使う VPN の接続数が上限に達し、接続できない人が出たとします。担当者は月に1回だけ接続数を確かめていました。

いま足りない分を補う手当て（接続を空ける、上限を増やす手続をすぐ進める）は、このトラブルへの対処です。 確認の頻度や監視の方法といった管理のやり方そのものを変えるのが、サービスマネジメントシステムの改善です。

サービスデスク

サービスデスク（ヘルプデスク）は、システムが稼働したあとに利用者からの問合せを受け付ける窓口です（要件定義・開発・受入テストの段階の窓口ではありません）。 利用者に対しては単一の窓口（SPOC：Single Point Of Contact）になります。種類ごとに窓口を細かく分けると、利用者はどこに聞くか迷います。 利用者から見た窓口は1つにまとめ、振り分けはサービスデスクの内側で行います。

問合せは記録と分類、優先度付け、対応、終了と結果の記録の順に扱います。優先度は受付順ではなく業務への影響と緊急度で決め、 障害には根本原因の調査を待たずに回避策を案内します。解決できないものは専門部署などの二次担当へ引き継ぎます（エスカレーション）。

問合せの内容・回答・かかった時間を記録して分析することが改善の出発点です。 過去のインシデントを FAQ にまとめると、最初の窓口で解決できる割合（一次回答率）が高まります。 FAQ で構成情報や要員の経歴が確かめられるようになるわけではありません。

サービスデスクを測る指標

成果は KPI（重要業績評価指標）で評価します。顧客満足のためには、値が大きいほうがよいものと小さいほうがよいものがあります。

エスカレーションの割合が高いのは、最初の窓口で解決できず利用者を待たせた件数が多いということです。

チャットボットとAIの使い方

利用者の問合せに答えるのはインシデント管理（とサービス要求管理）の入口なので、自動応答のチャットボットが効くのはインシデント管理です。 構成管理・変更管理・問題管理は、利用者と直接やりとりしない裏側の仕事です。 チャットボットはソフトウェアが自動で応答するので、受付時間を広げられます。オペレーターの技量が上がる、FAQ が充実する、といった効果はありません。

オペレーター支援のAIは、会話を聞き取って知識データベースと照合し、回答の候補を画面に出します。 経験が浅くても同じ水準で答えられ（ばらつきが減る）、情報を探す手間が消えて対応時間が短くなります。 ただし答えるのは人なので、オペレーターがいない時間に対応できるようにはなりません。 運用の監視データを AI で分析して異常を早く見つける考え方は AIOps といいます。

自動化の効果を計算する

削減率は、導入前と導入後の延べ時間を出してから比べます。例：1日500件の振り分けに、導入前は1件3分。 導入後は80%を自動で振り分け（0分）、そのうち10%は誤って人が直し（1件6分）、残りの20%は人が振り分ける（1件3分）。

導入前
  500件 × 3分 ＝ 1,500分
自動で振り分けた件数
  500件 × 80% ＝ 400件
そのうち、誤った件数（400件の10%）
  400件 × 10% ＝ 40件
誤った件数の時間
  40件 × 6分 ＝ 240分
正しく振り分けた件数の時間
  360件 × 0分 ＝ 0分
自動で振り分けられなかった件数の時間
  500件 × 20% ＝ 100件
  100件 × 3分 ＝ 300分
導入後の合計
  0分 ＋ 240分 ＋ 300分 ＝ 540分
削減率
  （1,500 − 540） ÷ 1,500 ＝ 0.64 → 64%

「そのうち」の割合は、直前の件数（400件）に対する割合です。全体の500件に掛けると 50件になり、答えがずれます。

まとめ

この節で解ける公開問題

令和4〜8年度の公開問題のうち、この節の知識で解ける問題は次の18問です。

この節の過去問を続けて解く（18問） →

教科書の一覧（現行の試験の順）教科書の一覧（新しい試験の順）過去問

Udemy の ITパスポート講座を、受講者数・★評価・口コミで比べたページです（広告を含みます）。

出典：IPA「ITパスポート試験 シラバス（案）Ver0.1」（2026年8月31日）、「ITパスポート試験 シラバス Ver6.5」。 練習問題と計算の例は当サイトが説明のために作ったものです。