ITパスポート｜サポート窓口で全部わかるSLAとインシデント管理

2026年7月20日 04:34

※ 本記事にはアフィリエイトリンク（PR）を含みます。

朝、目覚ましが鳴らなくて飛び起きます。スマホを手に取ると、画面が真っ暗のまま。充電ケーブルは挿さっていたはずなのに、何度押しても、うんともすんとも言いません。「これ、どこに聞けばいいんだろう」——あの日の途方に暮れた感じ、覚えていませんか。

そこからあなたは窓口を探し、電話をかけ、症状を説明し、番号をもらい、担当者が代わり、預けて、しばらくして受け取った。あの一連のやりとり、じつはまるごとITパスポートの出題範囲なんですよね。

この記事は、シリーズ「身近な例で全部わかる ITパスポート」の第10弾であり、第2シーズンの完結回です。スマホの回では、この同じスマホがどうやってつながっているかを見ました。今日はその同じスマホが、動かなくなった日の話です。

この記事でわかること

サポートに問い合わせたときのやりとりに、ぜんぶ名前がついていること
なぜ窓口の人は、原因をすぐ教えてくれないのか（この記事の山場）
「◯営業日以内にご連絡します」が、気持ちではなく約束である理由

この記事の要点（先に結論！）

サービスの中断や品質の低下のことを、ITの世界ではインシデントと呼びます。
サービスデスクとは、利用者からの問合せに対応する単一の窓口のことで、その入口を1つにまとめる考え方をSPOC（単一窓口）と呼びます。
インシデント管理は「まず早く復旧すること」を優先し、問題管理は「根本原因を突き止めて再発を防ぐこと」を担当する、別々の活動です。
SLAとは、提供者と顧客が合意したサービス品質を明記した文書のことです。
これらの用語は、ITパスポートのマネジメント系「サービスマネジメント」（大分類6・中分類11）で出題されます（2026年7月時点・シラバスVer.6.5）。

1. 朝、画面が映らない：その状態には名前がある

充電はできているはずなのに、画面だけが真っ暗。電源ボタンを長押ししても、何も起きません。仕事や授業の連絡も、財布代わりの決済も、路線の乗り換えも、ぜんぶこの板の中に入っていたことに、こういう朝はじめて気づかされますよね。

この「使えるはずのものが、使えなくなった状態」には、ちゃんと名前がついています。インシデントです。サービスの中断や、品質が下がってしまった出来事のことを、こう呼びます。そして、そのインシデントを受け止めて元に戻す仕事の全体が、サービスマネジメントと呼ばれる分野なんですね。

サービスマネジメントの記事では、レストランの運営にたとえてお伝えしました。おいしい料理を作れること（＝作る）と、お店を毎日きちんと回してお客さんに満足してもらうこと（＝回す）は、別の話でしたよね。世の中のシステムづくりは、この作る・回す・点検するの3段でできています。

そして今日のあなたは、この「回す」を受け取る側、つまりお客さんの席にいます。B系の記事はずっと運営する側の視点で書かれていますが、この記事はぜんぶ問い合わせた側の視点です。同じ用語でも、席が変わると見え方がまるで違うんですよ。

【試験ではこう出る】 インシデントとサービスマネジメントは、マネジメント系「サービスマネジメント」（中分類11）のテーマです。本拠地はこちら → ITILとSLAとは？サービスマネジメントを解説

2. どこに聞けばいいの？：入口が1つであるありがたさ

さて、真っ暗な画面を前に、最初の関門がやってきます。どこに連絡すればいいのでしょう。 買ったお店でしょうか。端末を作った会社でしょうか。それとも契約している会社でしょうか。困っている当人からすると、この振り分けがいちばんつらいところですよね。

ここで安心してほしいのですが、きちんと作られたサービスには、たいてい問い合わせの入口が1つ用意されています。この窓口がサービスデスク（ヘルプデスク）です。利用者からの問い合わせに対応する単一の窓口のことで、サービスマネジメントの記事では総合受付にたとえました。困りごとは全部ここへ持ち込んでいい、という約束の場所です。

そして、その入口を1つにまとめようという考え方そのものに名前がついています。SPOC（エスポック。Single Point Of Contact。単一窓口）です。利用者が部署から部署へたらい回しにされずにすむように、わざと入口を1つに設計してあるんですね。

窓口を探しているあいだに、あなたはたぶんFAQ（エフエーキュー。Frequently Asked Questions。よくある質問と回答集）のページにたどり着きます。同じ症状の人が先に質問していて、そこで解決してしまうこともありますよね。深夜でも即座に返事をくれるチャットボット（AIを使った自動応答）も、いまではおなじみです。

ちなみに、こうしたAIの力を使って運用の異常検知や対応を支える考え方を、AIOps（エーアイオプス。Artificial Intelligence for IT Operations。AIを使ったIT運用）と呼びます。シラバスにも名前が挙がっている言葉です。深入りは必要ありませんが、「AIが運用を手伝う流れに名前がついている」とだけ知っておくと十分ですよ。

【試験ではこう出る】 サービスデスク・SPOC・FAQ・チャットボット・AIOpsは、マネジメント系「サービスマネジメント」（中分類11）のテーマです（2026年7月時点・シラバスVer.6.5）。本拠地はこちら → ITILとSLAとは？サービスマネジメントを解説

3. 受付番号をもらう：困りごとが「案件」になる瞬間

やっと窓口につながりました。ところが、なかなか本題に入りません。いつから映らないのか、落としたことはあるか、機種は何か、充電はできているのか。次から次へと質問が続いて、「早く直してほしいのに」と少しもどかしくなる、あの時間です。

そして最後に、受付番号を伝えられます。じつはこの瞬間、あなたの困りごとは「案件」に変わっています。病院の受付票と同じで、番号がついた瞬間から、それは追いかけられる存在になるわけですね。

窓口がやっているのは、思いつきの雑談ではありません。記録して、分類して、優先度をつけて、対応して、終わったら結果をまた記録する。 この一連の流れをサービス要求管理と呼びます。サービスマネジメントの活動の1つとして、シラバスにもそのままの名前で載っている言葉です。

こう並べると、あの長い質問の意味が変わって見えてきませんか。症状を細かく聞かれるのは分類のため。緊急度を確かめられるのは順番を決めるため。番号を渡されるのは、次に電話したときに同じ話をゼロから繰り返さずにすむためです。

あの手続きっぽさは、冷たさではなく忘れられないための仕組みだったんですね。記録が残るからこそ、担当者が代わっても話が通じますし、あとから「あの件はどうなりましたか」と聞くこともできます。

【試験ではこう出る】 サービス要求管理（記録と分類、優先度付け、実現、終了及び対応結果の記録ほか）は、マネジメント系「サービスマネジメント」（中分類11）のテーマです（2026年7月時点・シラバスVer.6.5）。本拠地はこちら → ITILとSLAとは？サービスマネジメントを解説

4. 「担当の者に代わります」：あの保留音の正体

話が進んでくると、こう言われます。「担当の者に代わりますので、少々お待ちください」。そして保留音。正直、少しがっかりしますよね。また最初から説明するのかな、と身がまえてしまう瞬間です。

でも、あれはたらい回しではありません。最初に出てくれた人は入口の役であって、あらゆる故障を自分の手で直す人ではないんです。手に負えない案件を、より深く判断できる人へ渡す。これをエスカレーションと呼びます。

サービスマネジメントの記事では、飲食店で店員さんが「店長を呼びますね」と対応を上に上げる場面にたとえました。自分で解決できない案件を、判断できる人へバトンタッチすること。まさにあの保留音の正体です。

1次の窓口…受け付けて、記録して、よくある症状ならその場で解決する
エスカレーション…解決できない案件を、上位者や専門部署へ引き上げる
利用者から見ると…「担当の者に代わります」＝案件が前に進んだ合図

だから、保留音が鳴ったらこう思ってください。あなたの案件は、いま一段上へ進みました。 そして、さっきの受付番号があるおかげで、代わった人はもう症状の大半を知っている状態で電話に出てくれます。

【試験ではこう出る】 エスカレーションは、マネジメント系「サービスマネジメント」（中分類11）のテーマです。本拠地はこちら → ITILとSLAとは？サービスマネジメントを解説

5. 「原因はあとで。まず使える状態に戻しましょう」

ここが今日の山場です。担当者に代わって、あなたはいちばん聞きたいことを聞きます。「結局、原因は何なんですか？」。ところが返ってくるのは、原因の説明ではありません。「まずはお預かりして復旧を優先させてください」「その間のご不便については、できるかぎりご案内します」。

なんだかはぐらかされた気分になりますよね。わかります。でも、これにははっきりした理由があります。あなたを早く助ける仕事と、原因を突き止める仕事は、そもそも別の仕事だからです。

前者がインシデント管理です。サービスの中断が起きたとき、とにかく早く復旧して、生活や業務を通常に戻すことを最優先にする活動。サービスマネジメントの記事では救急処置にたとえましたね。事故が起きたら、まず止血して命を助ける。原因をじっくり調べるのは、そのあとです。

後者が問題管理です。インシデントの根本原因を突き止めて、二度と同じことが起きないようにする活動。こちらは精密検査にあたります。「なぜ倒れたのか」を時間をかけて調べ、根本から治す仕事です。

面白いのは、この2つが流れている時間の速さがまったく違うことです。インシデント管理は、あなたが困っている今日じゅうに動きます。問題管理は、何日も何週間もかけて、たくさんの報告を突き合わせながら進みます。

その成果があなたの前に現れるのは、だいぶあとになってからです。しばらく経って「同じ症状のご報告が複数寄せられ、原因が判明しました」というお知らせが出ることがありますよね。あれが問題管理の答え合わせです。あなたのスマホが直った日には、まだ出ていなかった答えなんです。

だから、こう覚えてください。あなたを助ける人と、原因を突き止める人は、別の仕事をしている。 冷たいのではありません。そう分けたほうが、あなたが早く助かるからなんですね。

【試験ではこう出る】 インシデント管理（早期復旧）と問題管理（根本原因の除去・再発防止）の違いは、マネジメント系「サービスマネジメント」（中分類11）でよく問われるところです。本拠地はこちら → ITILとSLAとは？サービスマネジメントを解説

6. 「◯営業日以内にご連絡します」：あれは約束だった

預けるときに、こう言われます。「◯営業日以内にご連絡いたします」。そのときはただの目安として聞き流しがちですが、よく考えると不思議ですよね。まだ原因もわからないのに、どうして期間の見通しを先に言えるのでしょう。

答えは、サービスの品質が気持ちではなく、あらかじめ決められた約束として存在しているからです。この約束を書いた文書がSLAです。

SLA（エスエルエー。Service Level Agreement。サービスレベル合意書）とは、提供するサービスの品質について、提供者と顧客が合意した内容を明記した文書のこと。サービスマネジメントの記事では、宅配ピザの「30分以内にお届けします」という約束にたとえました。たとえば「稼働率99.9%以上」といった内容が書かれます。

その中身は、3つの言葉で細かく分かれています。

SLO（エスエルオー。Service Level Objective。サービスレベル目標）…SLAの中で目指す具体的な目標値
SLI（エスエルアイ。Service Level Indicator。サービスレベル指標）…目標をどれだけ達成できたかを測る物差し
SLM（エスエルエム。Service Level Management。サービスレベル管理）…決めた品質を守り、改善し続ける管理の活動

つまり、窓口の人が口にした期間の見通しは、その人の気合いや勘ではありません。組織として先に決めてある水準を、あなたに伝えているだけなんです。そう思うと、あの一言がずいぶん頼もしく聞こえてきませんか。

ついでにもうひとつ。サービスを「使いたいときに使える」状態に保ち続ける管理をサービス可用性管理と呼びます。病院の回で見た「止めない」を、提供する側がずっと守り続ける活動、と思ってください。

なお、こうした運用のうまいやり方を世界中から集めたお手本集があります。ITIL（アイティル。Information Technology Infrastructure Library）です。サービスマネジメントのフレームワークで、本拠地の記事では料理の定番レシピ集にたとえました。今日あなたが受けた対応の背景には、こういう先輩たちの成功例が積み上がっているわけですね。

【試験ではこう出る】 SLA・SLO・SLI・SLMとサービス可用性管理、そしてITILは、マネジメント系「サービスマネジメント」（中分類11）のテーマです（2026年7月時点・シラバスVer.6.5）。本拠地はこちら → ITILとSLAとは？サービスマネジメントを解説

7. 直って戻ってくる：記録が残り、次に生かされる

しばらくして、連絡が来ます。直りました。受け取ったスマホの画面はちゃんと光っていて、うれしいと同時に、ちょっと拍子抜けもしますよね。結局あれは何だったんだろう、と。

見た目には何も変わっていません。でも、あなたに見えないところで記録は確かに増えています。どの機種の、どの部品を、どう交換したのか。何がどこにいくつあるかを正確に記録しておく活動を、構成管理と呼びます。サービスマネジメントの記事の備品台帳ですね。

そして、修理の現場では勝手な改造はできません。手を入れる内容は、影響を確かめて承認を受けてから行われます。これが変更管理、たとえるなら工事の事前申請・承認（勝手に壁を壊さない）でした。承認された変更を実際に反映して引き渡すところまでがリリース及び展開管理です。

この見方をすると、いつものスマホの動きも違って見えます。ある日ソフトウェアの更新が配られてきて、更新したら不具合が直っていた——あれもまさに、承認された変更が世の中に配られるリリース及び展開管理の一場面です。あなたの1件が、まだ壊れていない誰かの明日を静かに変えているわけですね。

ちなみに、作ったあとも直し続けるこの工程は、システム開発の記事で保守として登場しました。住みながらの修繕、というたとえでしたね。使い続けるかぎり、この仕事は終わりません。

【試験ではこう出る】 構成管理・変更管理・リリース及び展開管理は、マネジメント系「サービスマネジメント」（中分類11）のテーマです。保守はシステム開発の最終工程（中分類8）で、分野がひとつ違います。本拠地はこちら → ITILとSLAとは？サービスマネジメントを解説

8. その対応は正しかったのか、外から見る人がいる

もうひとつだけ。窓口の人も、修理をする人も、決められた手順どおりに動いていました。では、その手順そのものが適切だったかどうかは、誰が確かめるのでしょう。

当事者が自分で「うちは大丈夫です」と言っても、なかなか信じてもらえませんよね。だから、外の人が見ます。システム監査です。システム監査の記事では、保健所の立入検査にたとえました。お店の当事者ではない人が外から調べるからこそ、その結果は信頼できます。

この「当事者ではない」という条件が独立性です。同じ記事にあるテストの採点は本人にさせない、という一言がわかりやすいですね。自分の答案を自分で丸つけしたら、どうしても甘くなってしまいます。

サービスマネジメントを扱う大分類6には、このシステム監査も一緒に入っています。回している人と、それを外から点検する人。この2つでひとまとまり、という並びなんですね。くわしい流れは本拠地でどうぞ。

【試験ではこう出る】 システム監査と独立性は、マネジメント系「システム監査」（大分類6・中分類12）のテーマです（2026年7月時点・シラバスVer.6.5）。本拠地はこちら → システム監査・内部統制をやさしく解説

9. 動くスマホから始まって、止まったスマホで終わる

最後に、少しだけ種明かしをさせてください。

このシリーズの第6回は、スマホの回から始まりました。歩きながらでも動画が途切れない、あの当たり前の裏側をのぞく回でしたね。動いているスマホの話です。そして今日、同じスマホが止まった日の話で、このシリーズは終わります。

動いているときは、その仕組みの精巧さに感心します。止まったときにわかるのは、それを支えている人の仕事のほうです。同じ1台の機械から、まったく違う出題範囲が2つ見えたわけですね。

そしてもうひとつ。前回の引っ越しの回で扱ったプロジェクトは、期限があって、終われば解散する仕事でした。今日の話は、その正反対です。サービスは終わりません。 誰かが困るかぎり窓口は開き続け、直しては記録し、また次の問合せを受けます。教科書の大分類5と大分類6の違いは、じつはこの終わる／終わらないの違いだったんですよ。

あの日、真っ暗な画面の前で途方に暮れていたあなたは、知らないうちにサービスマネジメントの当事者をやっていました。用語のほうがあとから追いついてきただけなんですね。

10. まとめ：3行でふりかえり

サービスの中断はインシデントと呼ばれ、それを受け止める入口がサービスデスク（単一窓口＝SPOC）で、手に負えない案件は上へ引き上げられます（エスカレーション）。
まず早く復旧させるのがインシデント管理、時間をかけて根本原因を突き止め再発を防ぐのが問題管理で、この2つは別の仕事です。
「◯営業日以内に」という見通しは気持ちではなく、SLAという合意された品質の約束にもとづいています。

いかがでしたか？次にサポート窓口へ電話をかけたとき、保留音も、細かい質問も、受付番号も、ぜんぶ意味のある手順として聞こえてくるはずです。その耳を持てたなら、中分類11の土台はもうできています。

11. よくある質問（FAQ）

Q1. なぜサポートは、故障の原因をすぐ教えてくれないのですか？

A. まず復旧させる仕事（インシデント管理）と、原因を突き止める仕事（問題管理）が別だからです。窓口が最優先にしているのは、あなたが早く使える状態に戻ること。原因の究明は、別の担当者が別の時間軸で進めています。しばらくして「同じ症状の報告が複数あり、原因が判明しました」と発表されることがありますが、あれが問題管理の結果です。

Q2. サポートに電話すると、なぜ担当者が代わるのですか？

A. エスカレーションという仕組みが働いているからです。最初に出る窓口は入口の役で、あらゆる故障を自分で直す担当ではありません。解決できない案件は、より判断できる上位者や専門部署へ引き上げられます。たらい回しではなく、あらかじめそう設計されているんですね。

Q3. インシデント管理と問題管理の違いは何ですか？

A. インシデント管理は「まず早く復旧する」活動で、いわば救急処置です。問題管理は「根本原因を突き止めて再発を防ぐ」活動で、いわば精密検査にあたります。インシデント管理＝早期復旧、問題管理＝再発防止、と覚えると区別できます。ITパスポートの中分類11でよく問われるところです。

Q4. サービスデスクとSPOCの違いは何ですか？

A. サービスデスク（ヘルプデスク）は窓口そのもので、利用者からの問合せに対応する単一の窓口を指します。SPOC（Single Point Of Contact。単一窓口）は、その入口を1つにまとめるという考え方の名前です。窓口という「もの」と、1つにまとめるという「方針」の関係、と押さえておけば大丈夫です。

Q5. SLAとは何ですか？

A. 提供者と顧客が合意した、サービス品質を明記した文書のことです。正式名称はService Level Agreement（サービスレベル合意書）で、たとえば「稼働率99.9%以上」といった内容が書かれます。その中の具体的な目標値がSLO、達成度を測る物差しがSLI、決めた品質を守り改善し続ける管理がSLMです（2026年7月時点・シラバスVer.6.5）。

Q6. サービスマネジメントは、ITパスポートのどの分野ですか？

A. マネジメント系の大分類6「サービスマネジメント」のうち、中分類11「サービスマネジメント」です（2026年7月時点・シラバスVer.6.5）。同じ大分類6には、中分類12「システム監査」も入っています。回す（運用する）話と、外から点検する話が、ひとまとまりになっている分野ですね。