サービスリクエストとインシデントの違い：3つの判断質問と20の分類例

要点： インシデントは、これまで使えていたものが壊れた、または品質が落ちた状態です。サービスリクエストは、サービスカタログにすでにある標準的で繰り返し提供できるサービスを、ユーザーが依頼するものです。インシデントの目的は、できるだけ早くサービスを復旧すること。リクエストの目的は、合意した内容を合意した期限で提供することで、通常は承認が入ります。迷ったら、下の3つの質問を順番に確認してください。

この記事は、サービスデスクの責任者、情シス担当者、チケット管理ツールを設定する方に向けています。読み終えると、どんなチケットも1分以内に正しい種別へ分類でき、20の例で新人を教育でき、日常の依頼が障害対応のように扱われない二つの処理フローを作れます。

サービスリクエストとインシデントの違いは何か

ITIL 4の用語集は、サービスリクエストを「ユーザーまたはその権限を持つ代理人が出す、サービス提供の通常の一部として合意されたサービス行為を開始する依頼」と説明しています。インシデントは「サービスの計画外の中断、またはサービス品質の低下」です（2026年10月28日確認）。

平たく言えば次のとおりです。

• インシデント：「使えていたのに、使えなくなった。または前より悪くなった。」
• サービスリクエスト：「すでに標準的な提供方法があるものが欲しい。」

この区別が大切なのは、計測と処理の方法が違うからです。インシデントの時計は復旧までの速さを測り、リクエストの時計は約束の期日までに提供できたかを測ります。混ぜてしまうと、本当の障害が日常業務の山に埋もれ、日常業務は火消しのように見えてしまいます。

3つの判断質問

順番に聞き、最初の「はい」で止めます。

1. これまで正常だったものが、壊れた、遅くなった、不安定になったか。はいならインシデントです。ユーザーの言い方が依頼調（「メールを直してください」）でも同じです。
2. 何も壊れていないなら、頼まれたものはサービスカタログにある、または標準手順があるか。はいならサービスリクエストです。権限、新しい機器、ソフトのインストール、アカウント変更、「やり方を教えて」がここに入ります。
3. どちらでもないなら、環境の変更や新しいものか。それは変更要求（またはプロジェクト）で、着手前に評価が必要です。同種のインシデントが繰り返され原因が不明なら、問題レコードを起こし、関連インシデントと紐づけます。

境界を判断するときの考え方が二つあります。

• 言葉ではなく、ユーザーが必要としているものを見る。「経理の共有フォルダが開けない」は、権限がもともと付いていない（リクエスト）場合も、共有が止まっている（インシデント）場合もあります。このユーザーが以前開けていたかを確認します。
• 最初の必要に従って分類する。リクエストの提供中に失敗したら、リクエストは開いたままにし、失敗に対してインシデントを起こします。黙って一方をもう一方に変えないでください。

20の分類例

インシデント（8件）

1. 今朝からOutlookが接続できない：昨日は使えたので、サービスの中断です。
2. 共有プリンターが白紙を印刷する：正常だったサービスの品質が落ちています。
3. 会議室のWi-Fiが数分おきに切れる：サービスの劣化です。重複した報告は一つの親インシデントに紐づけます。
4. ノートPCが起動時にブルースクリーンになる：ハードウェアまたはOSの障害です。
5. VPNには繋がるが社内のファイル共有に届かない：サービスの一部が止まっています。
6. 特定のユーザーのTeams通話で音が出ない：そのユーザーにとっては中断です。多くの人に影響するなら、優先度の高いインシデントにします。
7. 社内Webアプリがエラーページを表示する：利用者全員に影響する停止です。
8. 昨夜のバックアップジョブが失敗した：ユーザーはまだ気づいていないかもしれませんが、サービスの失敗なのでインシデントです。

サービスリクエスト（8件）

1. 新入社員のアカウント、ノートPC、メールボックスが必要：標準の入社手続き項目です。
2. 共有メールボックスにメンバーを追加：標準的な権限変更で、通常はメールボックスの所有者が承認します。
3. 承認済みのアプリケーションのインストール：手順が確立しているカタログ項目です。
4. SharePointサイトへのアクセス権の申請：サイト所有者の承認が要るリクエストです。
5. すり減ったキーボードやマウスの交換：標準のハードウェア依頼です。
6. メールボックスやOneDriveの容量の引き上げ：合意した上限内の標準的な変更です。
7. 退職者のアカウント停止と機器の回収：標準の退職手続きで、人事が起点になることが多いです。
8. 「スマホで会社のメールを設定するには？」：情報提供のリクエストです。回答したら、その答えをナレッジに追加します。

判断が分かれるケース（4件）

1. パスワードを忘れた：標準のリセットで解決できるならサービスリクエストです。リセット自体が失敗する、または多数が同時にリセットできないならインシデントです。
2. アカウントがロックされた：一度のロック解除はリクエストです。原因不明のまま何度もロックされるならインシデントで、多くの場合は問題レコードも必要です（例：スマホに古いパスワードが保存されている）。
3. 「ノートPCが遅い」：以前より遅くなったならインシデント。標準より速い機種が欲しいというなら、承認が必要な例外申請です。
4. ソフトのインストールがエラーで失敗する：インストールがリクエストで、エラーはそのリクエストに紐づくインシデントです。こうすると二つの時計がどちらも正確になります。

処理フローの違い

両方のフローを文書化するときは、項目の順番を揃えておくと、担当者が見比べやすくなります。

インシデントのフロー

• きっかけ：何かが止まった、または悪くなった。
• 目的：サービスの復旧。暫定的な回避策も復旧に含めます。
• 優先度：影響度と緊急度で決めます。重大度と優先度の違いとITサポートSLAの優先度P1〜P4を参照してください。
• 承認：着手に承認は不要です。修復のための緊急変更は、変更管理のルールに従います。
• 目標時間：優先度ごとの応答時間と解決時間。
• エスカレーション：サポートレベルを上げ、ベンダーへ。影響が広ければ重大インシデント対応へ移します（重大インシデント管理）。
• クローズ：ユーザーが復旧を確認して終了します。繰り返すものは問題管理へ渡します。

サービスリクエストのフロー

• きっかけ：ユーザーがカタログから項目を選ぶ、または標準フォームを送る。
• 目的：合意した内容どおりに提供する。
• 優先度：カタログ項目ごとに合意した提供時間を使うのが一般的で、影響度と緊急度のスコアは使いません。特急対応は上長が決め、ユーザーが「高」を選ぶことでは決めません。
• 承認：項目ごとに定めます（上長、データ所有者、セキュリティ）。承認なしは例外であり、標準にしません。
• 目標時間：項目ごとの提供時間。例：「入社前日までに新入社員の機器を用意する」。
• エスカレーション：承認や提供が遅れたときだけ。
• クローズ：提供が完了し、ユーザーが確認し、承認と作業が記録に残っている。

チケット管理ツールでの設定

1. チケット種別を必須項目にし、インシデント、サービスリクエスト、変更要求の三つにする。問題はインシデントに紐づく別のレコードであり、フォームの四つ目の選択肢にはしない。
2. サービスカタログからリクエストフォームを作り、必須項目（誰が、何を、開始日、承認者）を入れて、聞き返しを減らす。
3. カタログ項目ごとに、責任者、承認者、提供時間を決める。
4. SLAの時計を二つ動かす。インシデントは復旧時間、リクエストは提供時間。L1・L2・L3のサポートレベルは同じキューを共有してもかまいませんが、時計は分けます。
5. 再分類は認めるが、理由を必須にして履歴を残す。チケットを削除して作り直さない。
6. 上の20の例をナレッジに載せ、サービスデスクが毎回同じ基準で分類できるようにする。

よくある失敗

• すべてのチケットをインシデントとして扱う。日常の依頼が緊急扱いになり、本当の障害が埋もれます。対策：種別と時計を分ける。
• リクエストフォームで優先度をユーザーに選ばせる。全員が「高」を選びます。対策：提供時間はカタログ項目から決め、例外は上長が判断する。
• ユーザーが「お願いします」と書いたので、壊れているものをリクエスト扱いにする。対策：毎回、最初の判断質問を確認する。
• 承認の経路がない。権限の依頼が、最初に気づいた人の判断で処理されます。対策：項目ごとに承認者を決める。
• フォームの代わりに自由記述欄を使う。最初の返信が不足情報の聞き返しで終わります。対策：項目ごとに必須項目を設ける。
• 黙って種別を変える。集計が信頼できなくなり、ユーザーも混乱します。対策：理由を書いて再分類し、ユーザーにも伝える。

正しく運用できているかの確認

1. 月に一度、クローズ済みチケットを20件ランダムに選び、三つの質問を当てはめて、記録されている種別と比べる。
2. 再分類されたチケットの数を数える。多いなら、フォームか例の見直しが必要です。
3. クローズ済みのリクエストすべてに、カタログ項目と（必要な場合は）承認者が記載されているか確認する。
4. 項目別に提供時間を見る。いつも遅れる項目は、催促を増やすのではなく、目標の見直しか人員の追加が必要です。
5. リクエストのチケットで「動かない」「エラー」「落ちている」などの語を検索する。ヒットしたものは、誤分類されたインシデントの可能性があります。

よくある質問

ServiceNowでは、サービスリクエストとインシデントはどう違いますか？

ServiceNowを含むどのチケット管理ツールでも、判断は同じです。使えていたサービスが壊れた、または劣化したならインシデントを起票し、ユーザーがカタログにある項目を求めているならリクエストを起票します。レコードの種別とSLAの時計は、別々に持ちます。

パスワードのリセットは、サービスリクエストですか、インシデントですか？

通常のパスワードリセットは、ユーザーが受ける権利のある標準的な操作なので、サービスリクエストです。リセットの仕組み自体が壊れている、または多数のユーザーが同時にロックされているなら、インシデントです。

サービスリクエストと変更要求はどう違いますか？

サービスリクエストは、権限付与や標準インストールのように、カタログにあり手順が確立しているものを求めます。変更要求は、新しいファイアウォールルールや新しいシステムのように環境を変更するもので、着手前に評価と承認が必要です。

サービスリクエストのSLAはどう決めますか？

多くの場合、影響度による復旧時間ではなく、カタログ項目ごとにあらかじめ合意した提供時間です。目標の書き方はITサポートにおけるSLAとはをご覧ください。

インシデントとサービスリクエストの例を教えてください。

上の20の例に、障害（インシデント）、標準的な依頼（サービスリクエスト）、判断が分かれる4つのケースを載せています。

インシデントとリクエストを分けて管理し、それぞれレポートまで出せるサービスデスクをお探しなら、24時間365日ヘルプデスクITサポートをご覧ください。