Contents
インシデント管理の基本概念と ITIL における位置付け
インシデント管理は、サービス停止や品質低下が発生した際に「速やかに復旧させる」ことを目的とします。本セクションでは、ITIL® 4 が定義するインシデントの意味と、ビジネス影響度・緊急性から優先度を決める基本的な考え方を解説します。
ITIL におけるインシデントの定義と目的
ITIL の公式ガイド（Axelos, 2021）では、インシデント を「サービスの中断または品質低下」と定義しています。目的は、顧客への影響を最小限に抑えるために 迅速な復旧 と 適切なエスカレーション を行うことです。
- インシデントと問題の違い
- インシデント：即時対応が必要な障害やサービス低下。
- 問題：根本原因を分析し、再発防止策を立てるプロセス。
ビジネス影響度と優先度付けの考え方
インシデントの優先順位は 「影響度（Criticality）」 と 「緊急性（Urgency）」 の組み合わせで決定します。この二軸評価により、リソース配分が最適化され、重要な障害に対して迅速に対応できるようになります。
| ビジネス影響度 | 緊急性 | 推奨優先度 |
|---|---|---|
| 高（サービス停止） | 高 | P1 |
| 中（機能低下） | 中 | P2 |
| 低（軽微な不具合） | 低 | P4 |
上表は ITIL の推奨マトリクスを参考にしています（ITIL® 4, Service Management Practices）。
Jira Service Management でインシデントプロジェクトを作成する手順
Jira Service Management (JSM) は、ITIL に準拠したテンプレートと自動化機能を備えており、数クリックでインシデント管理用のプロジェクトが構築できます。本セクションでは、プロジェクト作成からキュー設定までの流れを具体的に示します。
インシデントテンプレートと課題タイプの選択方法
JSM の 「インシデント」テンプレート には、ITIL が推奨するステータスや SLA 設定があらかじめ組み込まれています。
- プロジェクト作成画面で「サービスデスク」→「インシデント」テンプレートを選択
- 自動的に以下が設定されます。
- 課題タイプ: Incident
- 標準フィールド: 影響度、優先度、担当者など
- 設定内容は プロジェクト設定 > 課題タイプ で確認・変更可能です。
サービスプロジェクト作成とインシデントキューの有効化手順
キューを有効にすると、インシデントがリアルタイムで可視化され、担当者への自動割り当ても実現します。
- 左上メニュー > プロジェクト > 作成 をクリック。
- 「サービスプロジェクト」→「インシデントテンプレート」を選択し、名前を入力して作成。
- プロジェクト設定の キュー タブへ移動し、「新規キュー」ボタンで以下を設定。
- フィルタ条件例:
project = INC AND priority = P1（P1 インシデントのみ表示） - キュー保存後、ダッシュボードにピン留めして全員が一覧確認できるようにします。
標準ワークフローの構成とカスタマイズ例
JSM のデフォルトワークフローは ITIL が推奨する 5 ステータス（Open → Acknowledged → In Progress → Resolved → Closed）で構成されています。ここでは標準構造と、実務で役立つカスタマイズパターンを紹介します。
デフォルトステータスの概要
この流れは「検知 → 分類 → 対応 → 復旧 → 完了」の ITIL プロセスに対応しています。
| ステータス | 主な役割 |
|---|---|
| Open | インシデント受領直後、未対応キューへ自動投入 |
| Acknowledged | 担当者がインシデントを認識し、対応開始の意思表示 |
| In Progress | 実作業中。SLA の計測が始まるポイント |
| Resolved | 復旧完了。顧客確認待ち |
| Closed | 顧客承認後に最終クローズ。レポート対象になる |
カスタマイズパターンと実装手順
組織固有のプロセスが必要な場合は、ステータスや遷移条件を追加します。以下は代表的な例です。
| カスタムステータス | 目的 | 主なポスト関数 |
|---|---|---|
| Investigating | 原因調査中（自動トリアージで「不明」判定時） | 担当者自動割り当て、通知送信 |
| Awaiting Customer | 顧客回答待ち。SLA を一時停止 | SLA pause 設定、リマインダー送信 |
| Post‑Review | 完了後のレビュー・改善策作成 | ポストモルテンプレート自動生成 |
実装手順
- プロジェクト設定 > ワークフロー編集 を開く。
- 「ステータスを追加」し、名称とアイコンを設定。
- 必要な遷移線を描き、条件（例: カスタムフィールド「原因不明」）やポスト関数（自動通知）を付与。
SLA の定義・自動エスカレーションと AI 自動振り分け機能
SLA はサービス品質の保証に不可欠です。また、2026 年リリースの AI トリアージ 機能は、過去のインシデント履歴を学習し担当者割り当てを自動化します。以下では設定手順と注意点を説明します。
SLA メトリクスの定義方法
JSM では「応答時間」と「解決時間」の 2 種類を設定できます。ビジネス影響度別に目標値を分けることで、重要インシデントへの迅速な対応が可能になります。
- プロジェクト設定 > SLA を開く。
- 「新規 SLA」ボタンで Response Time と Resolution Time を作成。
- 条件例:
priority = P1 AND "Business Impact" = 高→ 応答 15 分、解決 2 時間。 - 必要に応じて エスカレーションルール（SLA 超過時の自動通知）を設定。
※具体的な時間は組織の契約条件や業界標準に合わせて調整してください（例: ITIL® 4 のベストプラクティスでは「高優先度は 1‑2 時間以内」等が推奨されています）。
AI 搭載インシデントトリアージの有効化手順
AI トリアージは過去 90 日間のインシデントデータを学習し、最適な担当チームへ自動割り当てします。
- プロジェクト設定 > AI トリアージ にアクセス。
- 「AI 自動割り当て」をオンにし、学習期間（例: 90 日）を指定。
- 優先度別の割り当てルールを追加。例:
P1 → SRE チーム, P2 → アプリケーションチーム。 - 設定後、テストインシデントで割り当て結果を確認し、必要に応じて微調整します。
注意点：AI の学習データは社内のプライバシーポリシーに従い匿名化することが推奨されます（Atlassian Security Documentation, 2024）。
通知・オートメーションとダッシュボード／レポート作成
インシデント対応速度は 適切な通知 と 可視化 に大きく左右されます。本節ではメール/Slack の設定、外部監視ツールとの連携、主要 KPI を表示するダッシュボードの作り方を解説します。
メール・Slack 通知の設定方法
リアルタイム通知は担当者がインシデント情報を即座に把握できるようにします。
- プロジェクト設定 > 通知スキーム を開く。
- 「イベント」列で「インシデント作成」「ステータス変更」を選択し、受信者に 担当者・ウォッチャー を指定。
- Slack 連携は Atlassian の公式 Slack アプリ（Marketplace）をインストールし、対象チャンネル（例:
#incidents）へ自動投稿を有効化するだけです。
監視ツールとの Webhook 連携手順
Datadog や New Relic のアラートを JSM に取り込むと、インシデント生成が完全に自動化されます。
- Jira プロジェクト設定 > インテグレーション > Webhook でエンドポイント URL を取得（例:
https://your-domain.atlassian.net/rest/api/3/issue）。 - 各監視ツール側で Webhook 設定を行い、以下のような JSON ペイロードを送信させます。
|
1 2 3 4 5 6 7 8 9 10 |
{ "fields": { "project": { "key": "INC" }, "summary": "[Datadog] {{alert_title}}", "description": "{{alert_body}}", "issuetype": { "name": "Incident" }, "customfield_10030": "{{priority}}" // 優先度マッピング } } |
- テストアラートでチケットが正しく生成されることを確認します。
KPI ダッシュボードの作成手順
主要指標（インシデント件数、MTTR、SLA 達成率）をリアルタイムで把握できれば、マネジメント層は迅速に改善策を講じられます。
- ダッシュボード > 作成 をクリックし、新規ダッシュボードに名前を付ける。
- ガジェット追加で「Issue Statistics」「Average Time to Resolution（MTTR）」「Filter Results」を配置。
- フィルタ例:
project = INC AND created >= -30d（直近 30 日のインシデント）。 - ビジネス影響度別件数は JQL
project = INC AND "Business Impact" = 高を使用し、円グラフで表示。
ITIL 準拠チェックリストと事後レビュー（Post‑mortem）プロセス
インシデント対応が終わったら ITIL 準拠性の確認 と 学びの蓄積 が重要です。本節ではギャップ分析手順と、標準化された Post‑mortem テンプレートの活用方法を示します。
ギャップ分析と改善ポイント抽出
チェックリストで現状を点検し、未達項目を具体的なタスクに落とし込むことで、継続的改善が実現します。
| 項目 | ITIL 要件 | 現在の実装 | ギャップ | 改善策 |
|---|---|---|---|---|
| インシデント記録 | すべて Jira に自動登録 | 手動入力が残る (約20%) | 手作業による抜け漏れ | AI トリアージで自動化 |
| SLA 計測 | 応答・解決時間を計測 | 応答は計測済み、解決未計測 | 解決計測不足 | 「Resolved」遷移にポスト関数追加 |
| エスカレーション | 超過時自動通知 | 未設定 | 手動エスカレーション | SLA 超過で自動エスカレーションルール作成 |
実施手順
1. プロジェクトオーナーがチェックリストをダウンロード。
2. 各項目の現行設定と比較し、ギャップを記録。
3. ギャップごとに担当者・期限を設定した改善タスクを Jira のサブ課題 として作成。
Post‑mortem テンプレートと継続的改善サイクル
標準化されたテンプレートを用いることで、インシデントから得た教訓が組織全体に共有されます。
テンプレート項目例
- インシデント概要（ID・開始日・終了日）
- ビジネス影響度と顧客への影響
- 根本原因分析（5 Whys 等）
- 対応経緯（タイムライン）
- SLA 達成状況（MTTR、応答時間）
- 改善策・実施計画（担当者・期限）
運用フロー
- インシデントが Closed になると自動でサブ課題「Post‑mortem 作成」を生成（Automation ルール）。
- 担当エンジニアがテンプレートに沿って記入し、レビュー担当者が承認。
- 承認後、改善策は別プロジェクトの 改善イテレーション 課題としてリンク付けし、実装をトラッキングする。
参考文献・出典
- Axelos, ITIL® 4 Foundation, 2021.
- Atlassian Documentation, Jira Service Management – Incident Management (2024). https://www.atlassian.com/software/jira/service-management/incident-management
- Atlassian Security Documentation, Data Privacy for AI Features (2024). https://support.atlassian.com/security/ai-data-privacy/
- ITIL® 4 Practices, Service Management – Incident Management (公式ガイドライン)。
本稿は ITIL のベストプラクティスと Atlassian 製品の最新機能（2026 年リリース）を組み合わせ、実務で即活用できる形にまとめました。各設定項目は組織固有のポリシーや契約条件に合わせて調整してください。