Incidents / Tasks の概要

トリガールールから自動で起票されるインシデントの対応と集約の仕様、タスクの作成と定期の自動生成、および両方の画面に共通するステータス管理、アクティビティ、検索・絞り込み、統計を説明します。

概要

Lorel.ai では、発生したインシデントへの初動から解決までの対応と、日常の運用業務を、「Incidents」と「Tasks」の2つの画面で、統合的に管理します。

• Incidents
  • 発生したインシデントの初動から解決までの対応を、組織・プロジェクトを横断して一元的に管理・追跡する画面です。
  • トリガールール（検知ルール・複合ルール・メトリクスルール）の発火に基づき、有効なインシデントポリシーを経由して、自動で起票されます（手動での新規起票はできません）。
  • AI エージェントによる原因分析のレポートや検知イベントの確認、担当者の割り当て、対応ステータスの進行、プロジェクトのメンバーとのコメントによる状況の共有など、インシデント対応の各フェーズを速やかに進めるための作業画面です。
  • ［概要］タブでは、発生の傾向や解決までの時間などの統計を確認できます。
• Tasks
  • 障害対応のあとの恒久的な対応、システムの定期点検、日常の定常的な運用業務を、計画・遂行・追跡する画面です。
  • 手動での個別の起票のほか、繰り返し設定による定期のタスクの自動生成と、紐付けた Runbook の自動実行にも対応しています。担当者の割り当て、期限の管理、進捗ステータスの更新、コメントによる作業ログの記録など、運用の作業を着実に進めて完了させるための作業画面です。

インシデントとタスクは、ステータスの変更、担当者の割り当て、コメントとメンション、ユーザー・AI エージェント・システムの操作履歴（アクティビティ）を、共通の仕組みで扱います。以降では、インシデントとタスクを総称してチケットと呼びます。

できること

インシデントとタスクの管理で、ユーザーとシステムが実行できる機能・操作の一覧です。

インシデントの自動起票と集約の仕様

インシデントは、トリガールールが発火すると、自動で起票されます。ユーザーが画面から手動で新しいインシデントを作成することはできません。

自動起票の仕組み

• 起票のトリガー。 単一の検知ルールの発火、複合ルールの条件の成立、またはメトリクスルールの条件の成立によって、起票されます。
• ポリシーとの連動。 有効になっているインシデントポリシーを経由して、起票されます。無効になっているポリシーに紐付く検知の条件が発火しても、インシデントは起票されません。
• 初期のステータス。 すべてのインシデントは、［未対応］の状態で起票されます。
• 初期の項目の設定。
  • タイトルには、発生元となったインシデントポリシーの名前が初期設定されます（起票のあとで変更できます）。
  • 説明は、空の状態で起票されます。現在、画面から編集することはできません。
  • 重要度には、ポリシーに設定されている初期の重要度が、そのまま設定されます。
  • 担当者には、ポリシーで指定された初期の担当者が設定されます。指定された担当者が起票の時点でプロジェクトのメンバーにいない場合は、［未割当］になり、未割当になった理由が操作履歴に記録されます。

アラートの集約と追記のルール（再発時の動作）

短時間に同じアラートが連続して発生したとき、チケットが重複して作成されないように、自動で集約されます。

• 未解決のインシデントへの集約と追記。 同じポリシー・同じルール（およびインシデントポリシーの「インシデントの分け方」で指定した識別ラベルの組み合わせ）で、未解決（［未対応］・［対応中］・［エスカレーション中］）のインシデントがすでに存在する場合、新しいインシデントは作成されません。既存のインシデントの画面にある「検知レコード」の一覧に、発火したイベントが履歴として集約・追記されます。詳しくは、Rules の概要を参照してください。
• 解決済みのインシデントとの関係。 該当する過去のインシデントが［解決済］になっている場合は追記されず、新しいインシデントとして起票されます（解決済みのインシデントに、新しい検知の記録を追記することはできません）。
• プロジェクト間の独立。 同じポリシーや検知の条件でも、別のプロジェクトのインシデントに集約されることはありません。プロジェクトごとに、独立して起票されます。
• 追記時の AI エージェント・Runbooks の動作。 既存のインシデントへの検知の記録の追記では、AI エージェントによる原因分析や Runbooks の自動実行は、再度実行されません。AI エージェントの実行は、ポリシーで指定した状態の変化（作成時・解決時・再オープン時。エスカレーション時は、現在は画面から選べません）を契機に、別に行われます。ポリシーの既定として設定した Runbooks は、インシデントの作成時にだけ自動で実行されます。

タスクの作成と定期の自動生成

タスクは、障害対応のあとの是正の作業、定期点検、定常的な運用の作業などを管理するためのチケットです。タスクは、手動で作成できるほか、繰り返し設定による定期の自動生成にも対応しています。

手動でのタスクの作成

「Tasks」画面の［タスクを作成］から、次の項目を設定して、タスクを作成できます。作成先は、プロジェクトを指定して開いた Tasks 画面ではそのプロジェクト、それ以外ではサイドバーで選択中のプロジェクトです（一覧の絞り込みで選んだプロジェクトではありません。どちらも未指定の場合、［タスクを作成］は表示されません）。

• タイトル（必須）。 作業の内容を端的に表す名称を入力します。空欄にはできません。
• 説明（任意）。 作業の手順や背景の情報を、テキストで入力できます（改行は保持されますが、Markdown 記法は整形されず、そのままの文字で表示されます）。
• 重要度（任意）。 ［緊急］［高］［中］［低］から選択します。［未設定］のままにすると、［低］が設定されます。
• 期限（任意）。 対応を完了する目標の日を指定します。画面では日付のみ指定できます（時刻は指定できません）。
• 担当者（任意）。 プロジェクトのメンバーから、担当者を指定できます。作成のダイアログでは、自分が初期の担当者として選択されています。選択を外すと、［未割当］になります。
• 繰り返し（任意）。 定期の作業として実施する場合は、繰り返しの周期を指定します。指定しない場合は、［繰り返しなし］になります。
• Runbook の紐付け（任意）。 関連する Runbook（実行の手順）を1件紐付けできます。

タスクへの Runbook の紐付け

• 実在の検証。 タスクに Runbook を紐付けるときは、対象の Runbook が同じプロジェクトの中に実在していることが必須です。別のプロジェクトの Runbook や、すでに削除された Runbook は、紐付けられません。
• 下書きの Runbook の紐付け。 現在、画面の選択肢には、有効な状態の Runbook だけが表示されます。
• 紐付けの解除。 Runbook の紐付けは、いつでも解除できます。解除すると、繰り返しのタスクから Runbook が自動で実行されることはなくなります。

繰り返しのタスクの自動生成（定期の自動生成）

繰り返し設定を持つタスクからは、設定した周期に従って、子のタスクが自動で生成されます。生成の対象になるのは、親のタスクが［未対応］の間だけです。［対応中］や［解決済］にすると、生成は止まります。

• 生成処理の実行間隔。 生成処理は5分間隔で動作し、次回生成日時（次に子のタスクを生成する予定の日時）を過ぎた、未対応の親のタスクが対象になります。
• 選択できる周期。 ［繰り返しなし］（既定値）、［毎日］、［毎週］、［毎月］、［毎年］から選択します。［繰り返しなし］以外を選択する場合は、期限の指定が必須です。
• 次回生成日時の自動計算。 繰り返し設定を持つタスクには、次回生成日時が自動で設定されます。期限や繰り返し設定を変更した場合は、変更の内容に基づいて、次回生成日時が再計算されます。初回の子のタスクは、期限の日ではなく、期限から1周期後に生成されます。また、次回生成日時は、常に現在の時刻より未来になるように、自動で補正されます。そのため、期限に過去の日時を指定した場合でも、次回生成日時が過去のまま滞留することはありません。
• 親のタスクから引き継がれる項目。 子のタスクには、次の情報が自動で引き継がれます。子のタスクの繰り返し設定は、常に［繰り返しなし］として生成されます。
  • タイトル
  • 説明
  • 重要度
  • 担当者
  • Runbook の紐付け
• 子の期限の設定と親タスクの更新。 子のタスクの期限には、親のタスクの次回生成日時が設定されます。子のタスクを生成したあと、親のタスクの次回生成日時は、生成処理を実行した時刻を基準に、1周期先へ更新されます。生成が遅れていた場合でも、未生成の期間の分の子のタスクを、まとめて生成することはありません。
• 月末の日の自動調整。 毎月または毎年の繰り返し設定で、生成の対象の日が存在しない場合は、その月の最終日に自動で調整されます（例：1月31日を基準にした毎月の繰り返しでは、2月は28日（うるう年は29日））。次回以降は、生成処理を実行した時刻を基準に1周期ずつ進むため、元の日付（31日など）には戻りません。
• 担当者の再検証。 子のタスクの生成時に、担当者が対象のプロジェクトのメンバーであることを、あらためて確認します。担当者がプロジェクトのメンバーでなくなっている場合は、子のタスクの担当者は［未割当］になり、その理由が操作履歴に記録されます。
• Runbook の自動実行と実在の検証。 親のタスクに Runbook が紐付いている場合、子のタスクの生成時に、その Runbook の自動実行が開始されます。ただし、実行されるのは、Runbook が有効な状態のときだけです。下書きなどの場合は、実行されません。生成時には、Runbook の存在も検証され、Runbook が削除されている場合や、別のプロジェクトの Runbook に変更されている場合は、Runbook の引き継ぎと自動実行は行われません。単発のタスクに紐付けた Runbook は、自動では実行されません。

チケットに共通の操作・管理

インシデントとタスクには、共通の操作と管理のルールがあります。

ステータスの遷移

• ステータスの種類。 ［未対応］［対応中］［解決済］の3つです。インシデントでは、これに加えて［エスカレーション中］も利用できます。
• 遷移のルール。
  • 開始は、［未対応］から［対応中］への遷移です（ボタンは［対応開始］）。
  • 解決は、［対応中］から［解決済］への遷移です。
  • 再オープンは、［解決済］から［未対応］への遷移です。
  • インシデントのみ、［エスカレーション］で、［未対応］または［対応中］から［エスカレーション中］に遷移できます。宛先のユーザーを1名選択する必要があり、宛先のユーザーが担当者になります。［エスカレーション中］からは、［対応を再開］で［対応中］に戻せます。解決は、［対応中］からのみ行えます。
  • 定義された遷移以外は、実行できません。
• インシデントの再オープン時の制限。 インシデントを再オープンするとき、同じ検知の条件に紐付く未解決のインシデントがすでに存在する場合は、再オープンできません。エラーのときには、競合しているインシデントへのリンクが、そのインシデントのタイトルで表示されます。
• 解決済みのチケットへの操作。 解決済みのチケットでも、次の操作は行えます（解決済みのインシデントへの検知の記録の追記だけは行えません）。
  • コメントの投稿
  • タイトルの更新
  • 説明の更新（現在、画面から編集できるのはタスクのみです）
  • 重要度の変更
  • 担当者の変更

コメントの投稿

• 文字数。 1文字以上10,000文字以下で入力できます（空のコメントは投稿できません）。
• Markdown への対応。 太字、斜体、インラインコード、コードブロック、箇条書き、引用、テーブルなどの記法に対応しています。入力のモードには、リッチテキストの編集と、Markdown のテキストの編集があり、Markdown のテキストの編集では、投稿の前にプレビューで表示の内容を確認できます。ただし、コメントに @ のメンションや I# / T# の引用が含まれる場合は、コメント全体が書式なしのテキストとして表示され、Markdown の記法は整形されません（メンションと引用のリンクだけが、チップとして表示されます）。
• ショートコード。
  • @ によるメンション。 入力すると、プロジェクトのメンバーの候補が表示されます。選択したユーザーに、メンションの通知を送信します。通知の本文には、コメントの先頭の200文字が含まれます。同じコメントの中で同じユーザーを複数回メンションしても、そのユーザーへの通知は1件です。自分自身を指名した場合も、通知の対象になります。
  • I# / T# による引用。 入力すると、候補が表示され、入力に合わせて絞り込まれます。候補を選択すると、そのチケットへのリンクを挿入できます。

担当者の指定

• 担当者を指定または変更する場合、対象のユーザーが、そのプロジェクトのメンバーである必要があります（作成時・更新時のどちらにも適用されます）。
• 担当者は、いつでも［未割当］に変更できます。

内容の更新

• 重要度を空にすることはできません。
• インシデントのタイトルは空にできますが、タスクのタイトルは空にできません。
• タスクの繰り返し設定を空にすることはできません。
• 説明と担当者、およびタスクの期限と Runbook の紐付けは、空にすることで解除できます（現在、画面から説明を編集できるのはタスクのみです）。
• ただし、繰り返し設定が［繰り返しなし］以外のタスクでは、期限を空にできません（同じ更新で、繰り返し設定を［繰り返しなし］に変更する場合を除きます）。

削除

• チケットとその操作履歴は、完全に削除されます。削除のあとで復元することはできません。
• 削除した時点の担当者（削除した本人を除く）に通知されます。担当者がいない場合は通知されません。通知の受信は、通知設定に従います。

操作履歴（アクティビティ）

チケットに対して行われたすべての操作は、発生した順に、タイムラインとして記録されます。記録は追記のみで行われ、あとから書き換えられることはありません。

操作履歴の閲覧の方法

• 詳細画面でのタイムラインの表示。 インシデントやタスクの詳細画面を開くと、そのチケットに紐付く一連の操作履歴が、タイムラインの形式で表示されます。
• 監査ログとの違い。 操作履歴は、チケットの単位で行われた作業や状態の変化を記録するものです。組織全体のセキュリティやガバナンスに関わる重要な操作の証跡である監査ログとは、記録の範囲や閲覧の権限が異なります。

記録される操作と対象

各記録には、操作を行った主体の種別として、「人間」「AI エージェント」「システム」のいずれかが付きます。インシデントの自動起票や、繰り返しのタスクの自動生成など、ユーザーの操作を伴わない動作は、「システム」による記録として残ります。

• 変更の記録のルール。 タイトル、重要度、担当者の変更、およびタスクの期限、繰り返し設定、Runbook の紐付けの変更は、実際に値が変わった場合にのみ記録されます。値を変えずに同じ内容で更新した場合は、操作履歴の記録は増えません。
• 例外。 説明の変更は、操作履歴には記録されません。また、チケットを削除した場合は、チケット自体がなくなるため、履歴も残りません。
• AI エージェントの実行の記録。 画面には、実行の承認を待っている間、承認待ちであることが表示されますが、承認待ちの状態は履歴には記録されません。また、インシデントから起動された本番の実行だけが記録され、テスト実行は記録されません。

タブによる絞り込み

インシデントとタスクの詳細画面の操作履歴は、［すべて］［コメント］［AI］［ランブック］［システム］のタブで絞り込めます。

• ［コメント］は、人が書いたコメントです。
• ［AI］は、AI エージェントのコメントと実行です。
• ［ランブック］は、Runbooks の実行です。
• ［システム］は、それ以外のすべての記録です（人によるステータスや担当者の変更を含みます）。

一覧・検索・絞り込み

「Incidents」画面と「Tasks」画面では、多数のチケットの中から目的のチケットを検索し、絞り込みや並び替えをしながら、効率的に管理できます。

一覧の取得の範囲と表示の仕様

• プロジェクトの指定と横断表示。 対象のプロジェクトを指定しない場合は、所属しているすべてのプロジェクトのチケットを横断して、一覧に表示します。対象のプロジェクトを指定した場合は、そのプロジェクトだけが対象になります。
• 所属しているプロジェクトがない場合。 ユーザーが所属しているプロジェクトが1件もない場合は、一覧は空（0件）になります。
• 画面の初期の表示。 初期状態では、解決済みを除く自分の担当のチケットが表示されます。Incidents 画面では、前回の絞り込みの条件と並び順が記憶されます（検索語と高度な検索の選択を除く）。Tasks 画面では記憶されません。記憶される内容は、使用しているブラウザに保存され、端末間では同期されません。

一覧画面の表示項目

一覧のテーブルには、次の情報が表示されます。一部の列は、列ヘッダーをクリックして並び替えができます。

画面上部の絞り込みとクイックフィルター

一覧画面の上部には、目的のチケットを素早く抽出するためのフィルターが用意されています。

ステータスのバッジ（クイックフィルター）

クリックして、そのステータスのチケットだけを表示できます。複数のステータスを同時に選ぶこともでき、［すべて］を選ぶと解除されます。各バッジには、該当する件数がリアルタイムで表示されます。

• インシデントでは、［すべて］［未対応］［対応中］［エスカレーション中］［解決済］が並びます。
• タスクでは、［すべて］［未対応］［対応中］［解決済］が並びます。

［自分の担当］では、ログイン中のユーザーが担当者として割り当てられているチケットだけを表示します。

フィルターバー

• 検索。 フリーテキストで、チケットを検索できます。
• プロジェクト。 組織とプロジェクトを指定して、絞り込みます。未指定の場合は、所属しているすべてのプロジェクトを横断して表示します。プロジェクトを指定した場合は、そのプロジェクトのチケットだけを表示します。
• 重要度。 ［すべて］［緊急］［高］［中］［低］のいずれかで絞り込みます。
• 担当者。 担当者を指定して絞り込みます。特定の担当者を指定するほか、［未割当］を選択できます。
• 繰り返し（Tasks 画面のみ）。 繰り返し設定の有無（［すべて］［繰り返し］［単発］）を指定して絞り込みます。
• 高度な検索（Incidents 画面のみ）。 クリックすると、直下に詳細な絞り込みのパネルが展開されます。次の条件を組み合わせて、絞り込みます。
  • データソース。 提供元のプロバイダと、その配下の Source の種別で絞り込みます。
  • ルール。 トリガールール（検知ルール・複合ルール・メトリクスルール）で絞り込みます。
  • ポリシー。 インシデントポリシーで絞り込みます。
  • データソース、ルール、ポリシーの3種は、いずれもチェックボックスによる複数の選択ができます。各列の上部には検索窓があり、各項目には、該当する件数がリアルタイムで表示されます。

フリーテキストの検索

• 検索する文字列は、2文字以上255文字以下で入力できます。
• 大文字・小文字を区別しない、部分一致の検索を行います。
• % と _ は、ワイルドカードとしては扱われず、そのまま検索する文字列として扱われます。
• インシデントの検索の対象は、タイトル、説明、発火した検知ルールと複合ルールの名前です（メトリクスルールの名前は検索の対象外です）。
• タスクの検索の対象は、タイトルと説明です。

並び替え

• 並び替えは、列ヘッダーをクリックして行います。並び替えできる項目は、重要度、ステータス、最終更新、タイトルです。各項目について、昇順・降順を切り替えられます。
• 画面の既定の並び順は、インシデント・タスクとも、最終更新の新しい順（降順）です。
• 重要度（昇順）は、緊急、高、中、低の順です。
• ステータス（昇順）は、未対応、対応中、（インシデントのみ）エスカレーション中、解決済の順です。
• タスクを重要度の昇順で並べているときは、未対応のタスクが先頭に集約され、それぞれが重要度の順に表示されます。
• タイトルで並び替えたとき、タイトルが設定されていないインシデントは、昇順・降順のどちらでも、一覧の末尾に表示されます。

インシデントの統計の概要（［概要］タブ）

「Incidents」画面の［概要］タブでは、インシデントの発生の推移、対応のスピード、重要度の配分、チームの対応の実績などを、直感的に可視化して分析できます。

取得の条件

• 対象の期間。 ［7 日］［30 日］（既定）［90 日］の3種類から選択します（任意のカスタムの期間は指定できません）。Starter プランの組織では、画面上、期間は7日のみ選択できます。
• 集計期間の境界。 集計期間は、現在の時刻からさかのぼって指定した日数の分を、時刻単位で区切った区間です。日付の境界には丸められません。区間の開始の時刻は集計に含み、現在の時刻は含みません。ただし、日次トレンドとミニグラフだけは日付ごとに集計します（日付ごとに1つの区間で、最初と最後の日付は1日分に満たない場合があります）。
• 対象のプロジェクトと横断集計。 画面では、所属しているすべてのプロジェクトを横断して集計します。所属しているプロジェクトが1件もない場合は、すべての項目が0件の状態になります。
• 母集団。 原則として、対象の期間の中で作成されたインシデントです（平均解決時間だけは、現在の状態が解決済みのものを対象とし、日次の推移の解決件数は、解決した日を基準にします）。
• 絞り込みの条件の制限。 統計の概要には、絞り込みの条件を指定できません。重要度・状態・担当者・データソースなどによる絞り込みは行えません（一覧や高度な検索との違いです）。

主要な指標

• 前期との比較（変化率）。 総インシデントと平均 MTTR は、直前の同じ長さの期間の値と比べた変化率が表示されます。解決率のカードには、解決した件数の前期との比較が表示されます（比較元の期間が0または値なしの場合、変化率は表示されません）。
• 再オープン時の計算の仕様。 再オープンを行うと、解決の日時の記録が外れて、いったん平均 MTTR の集計の対象から外れます。再び解決したときに、最初の作成の時刻から最後の解決の時刻までの時間として、再計算されます。

グラフ・分析のセクション

画面の下部に展開される、詳細な分析のチャートとランキングです。

• 日次トレンドと指標のカード。 日次トレンドのグラフは、発生と解決の2つの系列を表示します。指標のカードにあるミニグラフは、日別の簡易的な推移です。
• 0件の項目の非表示。 「Severity 配分」「Severity 別 平均 MTTR」「組織 / プロジェクト別」では、該当する件数が0件の行や項目は、表示されません。「Top 対応者」は、担当者が割り当てられたインシデントがあれば、解決が0件でも表示されます。
• 「Top 対応者」の集計のルール。
  • 対応者は、現在の担当者を指し、解決の操作を行ったユーザーではありません。解決のあとで担当者を付け替えた場合は、付け替えたあとの担当者に実績が計上されます。
  • 担当者が未割当のインシデントは、ランキングの対象から除外されます。
• MTTR の算出の共通のルール。 どのセクションでも、平均 MTTR は、現在の状態が［解決済］になっているインシデントだけを対象に算出されます。

高度な検索の件数の表示

絞り込みの候補ごとに、インシデントの件数をあらかじめ集計して、条件を選択する前に、どの条件に何件が該当するかを確認できる機能です。各項目には、絞り込みに使う値、画面に表示するラベル、件数の3つが含まれます。

集計の軸と構造

表示のルールと集計の動作

• 一覧の絞り込みの条件との連動。 件数は、インシデントの一覧の上部で指定されている絞り込みの条件（状態、重要度、担当者、プロジェクトなど）と同じ条件を反映して、集計されます。フリーテキストの検索は、タイトルと説明が対象です。
• 件数順の一覧表示と上限。 3つの集計の軸と、プロバイダの配下の内訳は、いずれも件数の多い順に固定して表示されます（ユーザーが並び順を変更することはできません）。表示される候補の項目の数に上限はなく、該当する項目がすべて表示されます。該当する件数が0の項目は、画面に表示されません。
• 軸自身の絞り込みを外した件数。 各集計の軸の件数は、その軸自身の絞り込みを外した条件で数えられます。これにより、ある条件で絞り込んでいる状態でも、ほかの候補に切り替えた場合に何件になるかを、事前に見比べられます。プロバイダの集計の軸では、プロバイダと Source の種別の、両方の絞り込みを外して集計されます。
• プロバイダの配下の内訳の表示のルール。 内訳の絞り込みの単位は Source の種別ですが、表示するラベルには Source の表示名が使われます。同じ種別の Source を、異なる表示名で複数登録している場合、内訳は表示名ごとに分かれて集計・表示されます（どれを選択しても、絞り込みは種別の単位で実行されます）。
• プロバイダの軸の合計と重複。 各項目の件数は、インシデントの重複を除いて数えられますが、プロバイダの件数は、その配下の内訳の合計として算出されます。1件のインシデントが、同じプロバイダの複数の Source にまたがる場合（複合ルールなど）は、重複して数えられるため、集計の軸の合計が、対象のインシデントの総数を上回ることがあります。
• 削除済みの項目の識別子の表示。 検知ルールやインシデントポリシーがすでに削除されていて、名称を解決できない場合も、その件数は集計から落とされず、名称の代わりに識別子（ID）が表示されます。
• 過去のインシデントの件数は変わりません。 集計の対象は、インシデントが生成された時点で記録された Source の組み合わせです。生成のあとに Source 側の設定を変更しても、過去に生成されたインシデントの件数の帰属が変わることはありません。ただし、表示名や種別のラベルには現在の設定が表示され、削除された Source は、内訳に表示されません。

保存期間

• インシデント・タスクには、保存期間の経過によって自動で削除される仕組みはありません。削除は、ユーザーによる削除の操作、プロジェクトの削除に伴う削除の処理、または組織の契約の終了に伴う削除の処理によってのみ行われます。
• インシデント・タスクとして保存できる件数に、プランごとの上限はありません。ただし、保存したデータの量は、ストレージの従量課金の対象に含まれます。
• プロジェクトを削除した場合、そのプロジェクトに属するインシデント・タスクは、削除から一定の猶予期間（現在は 3 日）を経て、システムにより完全に削除されます。猶予期間のあいだも、プロジェクト自体にアクセスできなくなるため、閲覧や操作は行えません。削除したプロジェクトを復元することはできません。

詳細は、取得データの取り扱いを参照してください。

ロールと権限

インシデントとタスクの各操作を実行できる、プロジェクトのロールの一覧です。

※契約の支払いの状況によって、一部の操作が制限される場合があります。支払いが遅延した場合は、タスクの新規作成、タスクの繰り返し設定の変更、タスクの Runbook の紐付けの変更ができません。削除、コメント、ステータスの変更は、引き続き行えます。契約が終了し、データエクスポート期間にある組織は、コメントやステータスの変更を含む、すべての書き込みができません。詳細は、お支払いが遅延した場合の制限を参照してください。

詳細は、ロールと権限を参照してください。

制限事項

• インシデントの手動作成はできません。 インシデントは、トリガールール（検知ルール・複合ルール・メトリクスルール）の発火を起点とした自動生成だけで作成され、手動で起票する手段はありません。
• 解決済みのインシデントへの追記はできません。 解決済みのインシデントに、新しい検知の記録を追記することはできません（再発したときは、別のインシデントとして新しく起票されます）。
• 再オープンの競合の制限。 同じ検知の組み合わせで、未解決の別のインシデントがすでに存在する場合は、再オープンできず、エラーになります。
• 削除は元に戻せません。 チケットの削除は完全な削除であり、元に戻すことはできません。削除の操作の履歴も残りません。
• 子のタスクは単発に固定されます。 繰り返しのタスクから自動生成された子のタスクに、繰り返し設定を持たせることはできません（常に繰り返しなしとして扱われます）。
• 滞留したときのまとめての生成は行われません。 繰り返しのタスクの自動生成は、生成が滞留した場合でも、過去の分をまとめて生成することはありません。
• 統計の概要の絞り込みの制限。 インシデントの統計の概要には、絞り込みの条件（重要度や担当者など）を指定できません。
• 統計の概要の対象の期間の固定。 インシデントの統計の概要の対象の期間は、7日・30日・90日のいずれかで、任意の期間（カスタムの期間）を指定することはできません。
• 説明の変更の履歴は保持されません。 説明の変更は、操作履歴（アクティビティ）には記録されません。

関連機能

• Rules の概要（インシデントの自動起票のトリガーとなる検知ルール・メトリクスルール・複合ルールと、初期の重要度・初期の担当者・自動で実行するエージェントを設定するインシデントポリシー）
• AI Agents の概要（起票されたインシデントの原因分析や、自動の初動対応を行うエージェント）
• Runbooks の概要（タスクやインシデントから、手動または自動で実行される作業手順）
• Integration の概要（インシデントの検知元となる Sources）
• ロールと権限（プロジェクトでのチケットの操作に必要な、プロジェクト管理者・編集者・ワーカー・閲覧者のロールの詳細）