ヘルプデスク / 社内SE の現場で最初に問われるのは「この問い合わせは何の種類か」の判断です。種類を間違えると、優先度・担当者・SLA・記録テンプレが全て噛み合いません。
このドキュメントは、ITIL の標準的な区分にあわせて インシデント / サービスリクエスト / 問題 / 変更 の 4 種類を整理し、受付時に分類するためのフローチャートと、それぞれの受付テンプレートをまとめたものです。
用語と分類は ITIL 4 の Service Management Practices をベースにしていますが、用語は社内SEで一般的な表現に寄せています。
| 区分 | 一言で | 例 | SLA（Lab 想定） | 主な記録先 |
|---|---|---|---|---|
| インシデント (Incident) | サービスが期待通り動かない | 「Outlook が起動しない」「共有フォルダが見えない」 | P1 1h / P2 4h / P3 1営業日 | チケット + Postmortem（P2 以上） |
| サービスリクエスト (Service Request) | 標準カタログにある依頼 | 「新入社員 PC キッティング」「ライセンス追加」「共有権限の追加」 | カタログ別（多くは 3 営業日） | チケット + 申請台帳 |
| 問題 (Problem) | インシデントの根本原因 | 「月1で発生する Outlook プロファイル破損の真因調査」 | 影響度別（緊急の脆弱性は 24h） | 問題管理台帳 + RCA |
| 変更 (Change) | 構成・設定を意図して変える | 「ADグループ構成変更」「FW ルール追加」「サーバー再起動」 | 標準変更 / 通常変更 / 緊急変更で分岐 | CAB 議事録 + 変更ログ + Runbook |
flowchart TD
A[問い合わせ受付] --> B{利用者から見て<br/>サービスは動いているか?}
B -- いいえ / 一部停止 --> C[インシデント]
B -- はい / 正常 --> D{依頼内容は<br/>標準カタログに<br/>あるか?}
D -- はい --> E[サービスリクエスト]
D -- いいえ --> F{構成・設定を<br/>意図して変える<br/>必要があるか?}
F -- はい --> G[変更]
F -- いいえ --> H{過去に類似事象が<br/>繰り返し発生?}
H -- はい --> I[問題]
H -- いいえ --> J[要相談: 上位担当へエスカレ]
C --> K[影響範囲 / 業務影響を確認<br/>→ P1/P2/P3 判定]
E --> L[申請者 / 承認者 / 期日確認<br/>→ カタログ別 SLA]
G --> M[CAB / 影響範囲 / ロールバック<br/>→ 標準 / 通常 / 緊急で分岐]
I --> N[インシデント履歴の集約<br/>→ RCA / 暫定対応 / 恒久対応]
style C fill:#fde0e0,stroke:#c62828
style E fill:#e3f2fd,stroke:#1565c0
style G fill:#fff8e1,stroke:#f9a825
style I fill:#e8f5e9,stroke:#2e7d32
Mermaid 図が表示されない GitHub クライアントでは、上のコードブロックがそのまま見えます。GitHub の Web UI、VS Code Preview、
mdr等で自動描画されます。
| 質問 | 判定 | 理由 |
|---|---|---|
| 「メール送受信ができない（本人のみ）」 | インシデント | サービスは動かない側 |
| 「メール送受信ができない（全社）」 | 重大インシデント (P1) | 影響範囲が大きい |
| 「共有フォルダに同僚を追加したい」 | サービスリクエスト | カタログ標準作業 |
| 「FW ルール追加したい（業務新規）」 | 変更 | 標準カタログ外 / 意図的な構成変更 |
| 「同じ人で月 1 回 Outlook が壊れる」 | 問題（裏でインシデントは複数残す） | 1 回 1 回はインシデントだが、繰り返しの真因調査が必要 |
| 「Defender 定義が古い」(警報経由) | インシデント or 問題 | 1 台だけ → インシデント、全社規模 → 問題 |
■ 受付情報
- 受付日時 : 2026-05-25 09:32
- 受付者 : 島田
- 通報者 : 山田太郎（営業部）
- 連絡手段 : 電話 / 内線 1234
■ 現象（利用者の言葉そのまま）
共有フォルダ「営業」が開けない。「ネットワークパスが見つかりません」と表示される。
■ 影響範囲（最初の判定）
- 利用者数 : 1 名（本人のみ確認）→ 周囲 3 名に聞き取り → 部署全体 8 名で再現
- 業務影響 : 提案書アクセス不可、本日中の納品に影響あり
- 発生時刻 : 09:15 頃
■ 初期判定
- 重大度 : P2（部署単位、業務影響あり、当日中復旧必要）
- カテゴリ : ファイルサーバー / 共有
- 関連サービス : fs01
■ 切り分け（時系列で追記）
09:32 本人 PC で確認: \\fs01\営業 が開けない
09:35 別 PC（営業部 田中）で確認: 同じく開けない
09:38 fs01 への ping 不通 → ネットワーク側を疑う
09:42 fs01 へ SSH ログイン: SMB サービス停止確認 → 再起動
09:45 利用者で開封確認 OK
「現象 → 影響 → 切り分け」を必ず時刻付きで残します。後工程の Postmortem / 問題管理に直結します。
■ 申請情報
- 申請日時 : 2026-05-25
- 申請者 : 山田太郎（営業部）
- 承認者 : 営業部長 + IT 管理者
- 希望期日 : 2026-05-30
- カタログ : 共有フォルダ アクセス権 追加（標準カタログ #SF-002）
■ 申請内容
- 対象 : \\fs01\営業\提案書
- 追加対象 : 田中花子（営業部 / 4/1 入社）
- 権限 : 読み取り + 書き込み
- 期限 : 無期限（部署所属中）
■ 事前確認（受付担当）
- [x] 申請書（PDF）添付済
- [x] 上長承認確認
- [x] 入社情報と整合
- [ ] AD グループ運用ルールに沿っているか確認 → SG-Eigyo へ追加で対応可
■ 作業
- 担当 : IT 運用 B
- 実施予定 : 2026-05-26 始業前
- ロールバック : SG-Eigyo から削除
- 完了通知先 : 申請者 + 承認者
■ 変更概要
- 変更番号 : CHG-2026-0145
- タイトル : fs01 SMB バージョン v1 廃止、v2 / v3 のみ許可
- 種別 : 通常変更（標準カタログ外 / 影響範囲調査要 / CAB 承認必須）
■ 影響範囲と根拠
- 対象 : fs01 サーバー（営業 / 総務 / 開発 共有）
- 影響時間 : 22:00 - 23:00（業務時間外、影響想定なし）
- 影響利用者 : 0 名想定（v1 のみで接続している端末 0 台と棚卸し済）
- 根拠 : Defender for Endpoint の脆弱性レポート、社内 IT セキュリティ規程
■ 事前確認
- 棚卸しスクリプト : Get-SmbVersionInventory.ps1 で接続元 SMB バージョン確認
- ベースライン : 全 240 台で v2 以上を確認済（証跡: 棚卸し台帳 §3）
- バックアップ : fs01 構成バックアップ取得（証跡: \\bk01\fs01-config\20260525）
■ 作業手順（Runbook 参照）
1. fs01 で SMB v1 無効化: Set-SmbServerConfiguration -EnableSMB1Protocol $false
2. Get-SmbServerConfiguration で v1 = False を確認
3. 利用者代表 3 名で共有アクセスのリトライ
4. 24 時間モニタリング後、変更クローズ
■ ロールバック
- 条件 : 利用者影響発生時 / 想定外端末で接続不可
- 手順 : Set-SmbServerConfiguration -EnableSMB1Protocol $true
- 所要時間 : 5 分以内
■ CAB / 承認
- レビュー日 : 2026-05-22
- 承認者 : IT マネージャー / 情報セキュリティ責任者
- 結果 : 承認
| 区分 | いつ使うか | 例 |
|---|---|---|
| 標準変更 | リスク評価済・手順確立済 | PC キッティング、退職者アカウント停止、月次パッチ |
| 通常変更 | 個別のリスク評価が必要 | サーバー構成変更、FW ルール変更、AD 設計変更 |
| 緊急変更 | サービス停止リスクを伴う緊急対応 | ゼロデイ脆弱性対応、重大インシデント時の構成変更 |
■ 問題情報
- 問題番号 : PRB-2026-0007
- タイトル : Outlook プロファイル破損の繰り返し発生
- 起票根拠 : 過去 90 日で INC-2026-0421/0498/0612 の 3 件発生
■ インシデント履歴
| INC | 日時 | 影響範囲 | 暫定対応 |
|---|---|---|---|
| 0421 | 2026-03-12 | 営業部 1 名 | プロファイル再作成 |
| 0498 | 2026-04-08 | 総務部 1 名 | プロファイル再作成 |
| 0612 | 2026-05-19 | 営業部 1 名 | プロファイル再作成 |
■ 真因分析（5 Whys）
Q1: なぜプロファイルが破損したか?
A1: Outlook 起動中に PC がスリープ → スリープ復帰時に PST が不整合
Q2: なぜ Outlook 起動中にスリープが起きるか?
A2: 電源プランがデフォルトで「30 分」設定
Q3: なぜ電源プランがデフォルトのままか?
A3: キッティング手順に電源プラン設定の項目が無い
Q4: なぜキッティング手順に項目が無いか?
A4: 過去の手順を踏襲、改訂タイミングを設けていない
Q5: なぜ手順改訂のタイミングが無いか?
A5: 障害から手順への反映フローが整備されていない
■ 真因
キッティング手順に Outlook 利用前提の電源プラン設定が無く、改訂サイクルも整備されていない。
■ 対応
- 暫定 (5/22 完了) : 既知の影響範囲 12 名に手動で電源プラン変更
- 恒久 (5/30 予定) : キッティング手順書 §4 に追記、全 240 台へ GPO 配布
- プロセス (6/30) : 障害 → 手順改訂のフローを月次レビューに追加
■ クローズ条件
- 60 日間、類似 INC が再発しないこと
- 月次レビューで「手順改訂フロー」を運用していること
| 番号 | 質問 | 目的 |
|---|---|---|
| 1 | 現象は何か（利用者の言葉そのまま） | 解釈を入れない |
| 2 | いつから発生しているか | 直近の変更との突き合わせ |
| 3 | 誰に発生しているか | 影響範囲の初期判定 |
| 4 | 直前に変わったことはあるか | 端末・社内・外部の変化 |
| 5 | 業務への影響度合いは | 優先度判定 |
| 6 | 再現するか / どうすると再現するか | 切り分け手順の組立 |
| 7 | 同じことが過去にあったか | 問題（Problem）への昇格判断 |
| 8 | 期待される復旧時間 | SLA と現実のすり合わせ |
「不調」「動かない」「遅い」のような曖昧な表現は、必ず観測可能な動作に翻訳してチケットに残します。
| パターン | なぜダメか | 代替 |
|---|---|---|
| 全部「インシデント」で起票 | 標準作業まで個別評価され、台帳が肥大化 | カタログ化できる作業はサービスリクエストに切り出す |
| インシデントを毎回プロファイル再作成だけで終了 | 真因に気付かず再発し続ける | 3 件以上同種が発生したら問題管理へ昇格 |
| 変更を「ちょっとした作業」で済ます | ロールバック不可、影響想定外で被害が拡大 | 標準 / 通常 / 緊急の 3 区分を運用し、CAB 通過の有無を明確化 |
| 「分からないので保留」 | 利用者からの信頼を失う | 要相談を 1 つの状態にして、上位担当へエスカレ判断を残す |