Rules の概要

Sources 経由で取り込んだ受信イベントの検知条件や、インシデントの自動起票・初動対応を制御するポリシーの定義・管理について説明します。

概要

Lorel.ai の Rules は、「トリガールール」と「インシデントポリシー」という2つの仕組みで構成されています。

1. Sources — イベントを受信します。
2. トリガールール — 受信イベントを判定し、検知イベントを生成します。
   • 検知ルール（単一イベントの条件判定）
   • 複合ルール（複数検知の発生頻度・しきい値判定）
   • メトリクスルール（収集したメトリクスのしきい値判定）
3. インシデントポリシー — 検知イベントをもとにインシデントを自動生成し、以下を決定します。
   • 初期重要度（緊急〜低）の決定
   • 担当者の自動割り当て
   • インシデントの分け方（グルーピング条件）
   • 初動対応の自動起動（AI エージェントまたは Runbooks）
4. インシデント自動起票・対応開始

トリガールールの役割

Sources 経由で取り込んだ受信イベントやメトリクスを判定し、検知イベントを生成する機能です。単一のイベントを評価する「検知ルール」、複数の検知結果を累積判定する「複合ルール」、収集したメトリクスの値をしきい値で判定する「メトリクスルール」の3種類を提供します。

• 検知ルール: 単一の Source から受信したイベントを判定します。
• 複合ルール: 検知ルールまたはメトリクスルールの発生状況を累積判定します。一定時間内に特定回数以上検知された場合にのみ反応させる（頻度ベースで異常を検出する）設計に適しています（入力元として指定できるルールは現在1件のみです）。
• メトリクスルール: 収集したメトリクスの数値を、しきい値と比較して判定します。画面上は、ルールの作成時に「検知ルール」を選び、データソースとしてメトリクス系のものを選ぶと作成できます。一覧では、［トリガールール］タブの「ルール種別」で「検知ルール」を選ぶと、データ型「メトリクス」として表示されます。

インシデントポリシーの役割

トリガールール（検知ルール・複合ルール・メトリクスルールのいずれも）の発火に伴い、インシデントを自動生成するためのルールセットです。1件以上のトリガールールを紐付け、生成されるインシデントの初期重要度・初期担当者・対応するエージェントまたは Runbook を定義します。

できること

プロジェクト内で定義・管理可能な Rules 関連の機能および必要なロールの一覧です。

※トリガールール・インシデントポリシーの作成・編集・削除・有効化/無効化操作には、編集者以上のロールが必要です。

トリガールール

1. トリガールールを構成する設定項目

トリガールールを構成する設定項目およびその仕様は以下の通りです。

基本情報

• データソース（必須）: Sources に登録済みで、有効な状態のデータソースを、表示名で選択する項目です。「イベント系」「メトリクス系」に分類されて表示されます。選択すると、ルール名やソース、検知ロジックなどの詳細設定項目が画面上に展開されます。
• ルール名（必須）: 作成するトリガールールを識別するための表示名称です（画面上は最大100文字。同名のルールも登録できます）。
• ソース（必須）: 選択したデータソースの配下から、監視対象とする具体的な接続先（受信エンドポイント。SNS Topic の ARN、GitHub のリポジトリ、Sentry の organization など）を選択する項目です。1つのトリガールールに対して紐付けられるソースは1件のみとなります。メトリクス系のデータソースを選んだ場合、この項目はありません。

検知ロジック

受信したイベントを評価・抽出する条件を定義するセクションです。

• 検知条件（AND結合・必須）: イベント検知を行うための必須条件です。対象フィールド（属性パス）、演算子、判定値の組み合わせで構成され、複数登録した場合はすべてを満たす必要があります（AND結合）。1件以上の登録が必須です。
• 除外条件（OR結合・任意）: 検知対象からスルー（除外）するためのフィルター条件です。設定したいずれかの除外条件に該当した受信イベントは検知対象外となります（OR結合）。0件でも設定可能です。

対象の分け方

検知したイベントをインシデント起票や集計に回す際の、システムの集約単位を定義するセクションです。

• 識別ラベル: インシデントや検知データを切り分けるための識別ラベル（ホスト名やインスタンス名など）を指定します。最大8件まで指定でき、複数指定した場合はその組み合わせ（複合キー）ごとに切り分けられます。
  • 識別ラベルを指定しない場合: 対象の切り分けは行われず、全体で1つのイベントとして集約されます。この場合、後段のインシデントポリシーで「識別ラベルで分ける」を選択することはできません。
  • 識別ラベルを指定する場合: 指定した識別ラベルの値（複数指定時はその組み合わせ）ごとに、独立したイベントとしてそれぞれ並行して評価・起票処理が実行されます。

データ保存期間

ルールに合致して生成された検知イベントデータをシステム側で保持する日数を1日以上の範囲で指定します。省略した場合はご契約プラン毎の初期値が自動適用されます（プランによっては変更できない場合があります）。具体的な保存日数（プランごとの上限や初期値）については、プラン・料金のページをご参照ください。

2. 各ルールの動作仕様

検知ルール（単一イベント検知）

1つのデータソースから受信したイベントを、指定した属性条件で判定します。

• データソースとの関係と送信元: 1つの検知ルールは1つのデータソースに属します（1ルール＝1データソース）。検知ルールが受け取るイベントの送信元は複数の方式に対応しており、HTTP Webhook 経由も含まれます。
• 条件の指定方法と演算子の仕様: 各条件は「対象フィールド」「演算子」「値」で構成します。
  • 対象フィールド: 取り込んだイベントの属性をドット記法の属性パスで指定します(先頭の$.は省略可）。
  • 等しい（eq）: 値が完全一致する場合に合致。
  • 含む（contains）: 指定した文字列を含む場合に合致。※大文字・小文字を厳格に区別します。
  • 正規表現（regex）: 値の一部が正規表現のパターンに一致すれば合致（部分一致）。※標準的な正規表現の記述に対応していますが、一部の特殊な記述（前後の文字パターンを条件とする先読み・後読み、マッチした文字を後から再利用する後方参照など）は使用できません。
• 評価ルールと評価順序: 検知条件は1件以上必須、除外条件は任意（0件でも可）です。評価順序は、まず検知条件をすべて満たし（AND）、かつ除外条件のいずれにも該当しない（OR）イベントを検知します。
• 検知結果と実測値の確認: 検知イベントの詳細画面では、検知条件ごとに検知時の実測値を確認できます。なお、値が長い場合は切り詰めて表示されることがあります。

複合ルール（発生頻度・しきい値判定）

指定した検知ルールの発火頻度を一定時間で集計し、条件を満たした場合にのみ発火するルールです。

• 入力元の種類による数え方の違い: 検知ルール（イベント型）は受信したイベントの件数を、メトリクスルール（メトリクス型）は1分ごとの評価の回数を数えます。同じ「〇件」という指定でも、入力元の種類によって数えているものが異なる点にご注意ください。メトリクスルールを入力元にする場合、メトリクスは1分ごとにしか評価されないため、発生回数は時間窓（分）を超える回数には設定できません。
• 集計期間の計算ルール（スライディングウィンドウ方式）: イベントを受信するたびに、その時点から過去「設定した集計期間分」に遡って発生件数を都度計算します。しきい値に達して発火した後も、集計期間やカウントがゼロにリセットされることはありません。発火判定はイベントが発生するたびに即時評価されます。
• アラート発火と再通知のルール（レベルトリガー方式）: 件数がしきい値以上の間、同じ異常による再発火や重複した通知は行われません（通知は最初の1回のみ）。一度発生件数がしきい値を下回って正常状態に戻った後、再度しきい値以上に達した場合にのみ、新しい検知イベントとして再発火します。※正常状態への復帰判定は定期評価で行われるため、件数が下回ってからステータスが解除されるまでに多少のタイムラグが生じる場合があります。
• 発火・解除ステータスとルール状態の独立性: 複合ルールの判定による「発火（ON）／解除（OFF）」は、複合ルール自体の管理状態（有効／無効／エラー）とは別の独立した情報です。

検知イベントの保存期間（保持ポリシー）

• 検知ルールの作成時・更新時に、検知イベントの保存期間（日数）を1日以上の範囲で個別に指定できます。
• 省略した場合は、ご契約プランの既定日数が適用されます。既定日数・上限はプランにより異なり、プランによっては変更できない場合があります。
• 保存期間の変更には編集者以上のロールが必要です。
• 保存期間を短く変更した場合、変更後の期間を超える既存の検知イベントは自動的に削除の対象となり、元に戻すことはできません。
• 複合ルールには保存期間の個別設定はありません。入力元が検知ルールの場合は、その検知ルールに設定された保存期間の値がそのまま適用されます。入力元がメトリクスルールの場合は、メトリクスルール側の保存期間設定が適用されます。

3. トリガールールのステータスと権限

• ルールの状態（ステータス）
  • 検知ルール: 「有効」「無効」の2種類。
  • 複合ルール: 「有効」「無効」「エラー」の3種類。
• 新規作成時の初期状態: 新規作成されたルールは、安全のため初期状態が「無効」です。明示的に有効化することで検知が開始されます。
• 入力元削除時のエラー遷移: 検知ルールまたはメトリクスルールを削除した場合、それを入力元としている複合ルールは自動的に「エラー」状態に遷移します（複合ルール自体は自動削除されません）。また、入力元のルールの識別ラベルの構成を変えた場合も「エラー」状態になり、判定の分け方を選び直すまで回復しません。エラー状態は、入力元の参照を修正して復旧させることで、無効状態に戻してから再度有効化できます。
• 操作に必要なロール
  • 閲覧・一覧・プレビュー: プロジェクトの「閲覧者」以上のロールが必要です。
  • 作成・編集・削除・有効化／無効化: プロジェクトの「編集者」以上のロールに加え、利用料金の未払いによる操作制限が適用されていないことが必要です。

インシデントポリシー

トリガールール（検知ルール・複合ルール・メトリクスルール）が検知したイベントをもとに、どのような条件でインシデントを自動起票し、初期重要度・担当者の決定や初動対応（AI エージェント / Runbook）を自動実行するかを定義・管理する機能です。

1. インシデントポリシーの設定項目

インシデントポリシーは、基本情報および以下の4つのセクションを定義することで構成されます。

ポリシーの作成・更新仕様

• 作成時の仕様: ポリシー名・初期重要度は必須です。紐付けるトリガールールは指定しなくても作成可能です（0件の状態で作成可能）。新規作成時は必ず「無効」の状態で作成されます（作成時点で有効化状態を指定することはできません）。
• 更新時の仕様: 紐付けるトリガールールを、更新によって0件にすることはできません（0件にできるのは作成時のみです）。

トリガールールとの紐付けパターン

検知ルール・メトリクスルール・複合ルールのいずれも紐付け対象にできます。1件のポリシーに複数のトリガールールを紐付けられ、逆に1件のトリガールールを複数のポリシーに紐付けることも可能です。トリガールールを新規作成する際に「インシデントを自動生成する」を選ぶと、このトリガールールに紐づく新規インシデントポリシーを作成して紐付けます（自動生成されるポリシーは無効の状態で作成されるため、有効化して運用を開始します）。既存のポリシーへの紐付けは、ポリシー画面のトリガールール設定から行います。

インシデント生成時の反映

ポリシーで指定した初期重要度および初期担当者は、インシデント起票時にそのまま初期値として設定されます。

2. 設定・設計時の重要ルールと注意事項

グルーピング（インシデントの分け方）の仕様と制限

• インシデントの分け方の定義: 検知されたイベントを発火条件のルールごとに1件のインシデントにまとめるか、あるいはリソース単位（ホスト名やインスタンス名などの識別ラベル）ごとに独立したインシデントとして切り分けて起票するかを選択する設定です。
• 共通ラベルのみ指定可能: 「識別ラベルで分ける」に指定できるのは、発火条件（トリガールール）に指定したすべてのルールが共通して持っている識別ラベルのみとなります。共通しないラベルで切り分けることはできません。
• 設定変更後の自動起票とリソース急増への注意: 「識別ラベルで分ける」に変更（または設定）した後は、識別ラベルごとに個別のインシデントとして分かれて自動起票されるようになります。起票されたインシデントの数（分割された数）だけ、自動通知、および Runbook や AI エージェントの自動実行がそれぞれ個別に並行して走り出すため、通知やリソース消費の急増に十分ご注意ください。
• 進行中（未対応）のインシデントへの影響（非遡及ルール）: 設定を変更しても、すでに発生している進行中のインシデントに対して、新しい「分け方」のルールは後から適用されません。これまで1件にまとめられていた既存のインシデントは、新しい「識別ラベル別」の構成へと自動的にバラバラに分割されることはなく、そのまま1つのインシデントとして「未対応」のまま画面上に残ります。この残された既存のインシデントについては、アラートが解消されても自動で「解決済」ステータスに切り替わらない場合があるため、運用メンバーによる手作業でのステータス変更（解決）が必要となります。

初期担当者における所属メンバーの自動検証

• 設定時の検証: 初期担当者を設定する際は、指定したユーザーがプロジェクトメンバーであることをシステムが確認します。プロジェクトメンバーでないユーザーは設定できません。
• 起票時の再検証: インシデント生成の都度、初期担当者が改めてプロジェクトメンバーであるかを自動で再確認します。すでにプロジェクトを離脱している場合は、安全のため「未割当」の状態でインシデントが起票され、操作履歴（アクティビティログ）にその旨が記録されます。

AI エージェントの割り当て仕様

インシデントのライフサイクルにおける状態変化（発火条件）に合わせて、最大4件まで AI エージェントを自動起動するように設定できます。

• AI エージェントにおける4種類の発火条件（起動トリガー。現在、画面で選べるのは作成時・解決時・再オープン時です）
  • 作成時: インシデントが新規に生成（起票）された時点をトリガーとして非同期で起動します。
  • 解決時: インシデントのステータスが「解決済」へ遷移した時点をトリガーとして非同期で起動します。
  • 再オープン時: ステータスが「解決済」から「未対応」へ戻った（再オープンされた）時点をトリガーとして非同期で起動します。
  • エスカレーション時: インシデントがエスカレーションされた時点をトリガーとして非同期で起動します（現在は画面から選択できません）。
• エージェント割り当てにおける制限事項
  • 標準エージェントの適用制限: 標準エージェント（インシデント原因分析エージェント等）は、起動時の発火条件が「作成時」のみに固定されており、解決時・再オープン時・エスカレーション時には設定できません。
  • 同一発火条件への重複設定禁止: 1つの発火条件に対して複数のエージェントを同時に設定（重ねて設定）することはできません。選べる発火条件が4種類であるため、1つのポリシーに設定できるエージェントは最大4件までとなります。この制約は発火条件ごとに適用されるため、同一のカスタムエージェントを複数の異なる発火条件（例：作成時と解決時の両方）に割り当てること自体は可能です。

既定 Runbook の割り当て仕様と注意点

• Runbook の割り当て: プロジェクト内で有効化されている Runbook の中から、インシデント発生時に自動起動するものを1つ設定できます。
• AI エージェントとの同時設定について（併用不可）: インシデントポリシー内に AI エージェントが1つでも設定されている場合は、Runbook を同時に割り当てることはできません（設定しようとするとエラーになります）。
• 設定後の削除・無効化による影響: ポリシーに Runbook を割り当てた後、その Runbook 自体が削除されたり無効化されたりした場合、インシデント発生時にはその Runbook は実行されません。

3. ポリシーのステータス・一覧・権限・削除時の挙動

• 有効化と無効化: 新規作成時は安全のため、必ず「無効」の状態で作成されます。有効化して初めて、紐づく検知ルール・メトリクスルール・複合ルールの発火に応じたインシデント生成が働きます。無効化中は検知イベントが発生してもインシデントは生成されません。
• 一覧のフィルタ・ソート仕様: プロジェクト内のポリシー一覧表示では、名前でのキーワード検索、有効/無効状態や初期重要度による絞り込みに対応しています。名前の順、更新日時の順、または初期重要度の順での並び替えに対応しています。重要度で並び替えた場合は、緊急→高→中→低の順になります。
• 操作に必要な権限とお支払い状況: 閲覧・一覧表示にはプロジェクトの「閲覧者」以上のロールが必要です。作成・編集・削除にはプロジェクトの「編集者」以上のロールに加え、ご契約における利用料金の未払い（お支払い遅延）による操作制限（書き込み制限）が適用されていないことが必要です。※閲覧・一覧表示には本お支払い状況による制限は適用されません。
• 削除時の影響（過去データへの安全性と仕様）: ポリシーの削除は完全な削除であり、後から元に戻すことはできません。ポリシーを削除しても、過去にそのポリシーから自動起票されたインシデントデータが削除されたり、ポリシーとの紐付けが自動的に解除されたりすることはありません。インシデント側には削除されたポリシーの紐付け情報がそのまま保持され、一覧画面やファセット集計画面も、紐付け先のポリシーが既に削除されている状態を許容して正常に表示・動作します。

制限事項

• 複合ルールの判定パターンの制限: 複合ルールで利用できる判定方式は、集計期間内の発生回数を集計する「発生頻度」のみです。
• 複合ルールの多段構成（重ね掛け）の禁止: 複合ルールを入力元とする多段構成（複合ルールの判定結果を、別の複合ルールの入力元としてさらに重ねる設計）は行えません。入力元に指定できるのは、検知ルール（単一イベント検知）またはメトリクスルール1件のみとなります。
• 複合ルールの上限なし仕様: プロジェクト内の複合ルールの作成個数、および1件の検知ルールに対して紐付けられる複合ルールの個数に上限はありません。
• 複合ルールの同時ポリシー作成画面の非提供: 複合ルールの新規作成と同時にインシデントポリシーを設定・作成する専用の画面オプションはありません（検知ルールのみ対応）。
• 複合ルールのエラー遷移: 入力元として指定している検知ルールまたはメトリクスルールを削除した場合、それを参照している複合ルールは自動的に「エラー」状態に遷移し、監視・判定が一時停止します（入力元のルールの識別ラベルの構成を変えた場合も同様です）。※複合ルール自体は自動削除されません。
• 複合ルールにおける集計状況（実測値）の非表示: 複合ルールにはプレビュー機能はありません。実際のリアルタイムな集計値（現在の該当件数など）や実測値も画面上で確認することはできません（設定値と状態のみが表示されます）。
• メトリクスルールの作成場所: 収集したメトリクスの数値そのものをしきい値で直接監視する「メトリクスルール」は、Rules 画面でルールを作成する際に、データソースとしてメトリクス系のものを選ぶと作成できます。作成済みのメトリクスルールは、複合ルールの入力元として選択できます（上記「トリガールールを構成する設定項目」参照）。
• 利用可能な演算子の制限: 検知ルールで利用できる演算子は「等しい（eq）」「含む（contains）」「正規表現（regex）」の3種類のみです。数値の大小比較、フィールドの存在有無判定、前方／後方一致などは提供していません。
• 初動対応の排他制御（併用不可）: 同一のインシデントポリシー内で、AI エージェントの自動起動と、既定 Runbook の自動実行の両方を同時に設定（併用）することはできません。
• カスタムエージェントの新規作成: インシデントポリシーに紐付けるカスタムエージェント自体の新規作成・追加は、現在サポートしていません。カスタムエージェントを紐付けるには、あらかじめプロジェクトに作成済みのカスタムエージェントが必要です。

関連機能

• Integration の概要（トリガールールの検知元となる Sources と、Runbooks や AI エージェントが利用する Access）
• AI Agents の概要（AI エージェントの割り当て先）
• Runbooks の概要（既定 Runbook の割り当て先）
• Incidents / Tasks の概要（発火条件のうち「解決時」「再オープン時」が対応するインシデントの状態遷移の定義元、およびポリシー削除後もインシデントが正常に残る関係）
• プラン・料金（支払い状況によるアクセス制御、および検知イベント保存期間のプラン別既定値・上限）