cx-cases

ケース管理スキル

ケースは、関連するアラートイベントを、ステータス、優先度、カテゴリ、担当者を備えた1つの調査単位にまとめたものです。このスキルを使ってケースを調査し、ライフサイクル（active → acknowledged → resolved → closed）に沿って進めます。

CLI コマンド

コマンド	目的
cx cases get <id>	IDを指定してケースを1件取得します
cx cases update <id> [--title] [--resolution-reason]	変更可能なフィールドを更新します
cx cases comment <id> --text <text>	ケースのタイムラインにコメントを追加します
cx cases assign <id> --user <email>	ケースを割り当てます（メールアドレス、またはユーザーIDをそのまま指定）
cx cases unassign <id>	担当者の割り当てを解除します
cx cases acknowledge <id>	ケースを確認します（対応中であることを示し、再通知を停止します）
cx cases unacknowledge <id>	確認を取り消します
cx cases resolve <id> --reason <text>	ケースを解決します（取り消し不可 — 下記を参照）
cx cases close <id>	ケースをクローズします（終端状態）
cx cases set-priority <id> --priority <P1..P5>	算出された優先度を上書きします
cx cases clear-priority <id>	優先度の上書きを解除します
cx cases events list <case-id>	イベントのタイムラインを表示します（ステータス変更、コメント、割り当て）
cx cases events get <event-id>	イベントを1件取得します — 例：コメントスレッドを展開して詳しく確認します
cx cases notifications <case-id> [<case-id> ...]	通知の配信状況を表示します（コネクター、ステータス、時刻）

ケースのライフサイクル

PENDING_ACTIVATION ──► ACTIVE ◄────────► ACKNOWLEDGED
                         │ ╲                │ ╲
                         │  ╲               │  ╲
                         ▼   ╲              ▼   ╲
                      CLOSED  ╲──► RESOLVED ◄─── (from ACK)
                                       │
                                       ▼
                                    CLOSED  (terminal)

現在の状態	許可される遷移	備考
PENDING_ACTIVATION	→ ACTIVE	システムによって有効化されます。ユーザーは操作できません
ACTIVE	→ ACKNOWLEDGED、RESOLVED、CLOSED	確認は任意です。誤報の場合は、resolve を省略して直接 close します
ACKNOWLEDGED	→ ACTIVE、RESOLVED、CLOSED	唯一の「戻る」遷移です。unacknowledge を実行すると ACTIVE に戻ります
RESOLVED	→ CLOSED のみ	取り消し不可 — ACTIVE／ACKNOWLEDGED には再オープンできません
CLOSED	（なし）	終端状態

カテゴリ：AVAILABILITY または SECURITY。優先度：P1（最高）→ P5。

トリアージのワークフロー

1. 調査 — cx cases get <id>。ペイロードには groupings、 labels、impactedEntities、kpiBreaches、aiSummary のほか、 priorityDetails.system（算出値）と priorityDetails.override（ユーザー設定値）が含まれます。
2. 原因を調査 — 操作する前に、アラートの DataPrime / PromQL をクエリして基になるテレメトリを取得し、根本原因を特定します。 必要に応じて cx olly で調査内容をエクスポートするか、ケースの impactedEntities / groupings を取得して影響を確認します。 cx-telemetry-querying スキルを参照してください。
3. 担当する — cx cases assign <id> --user [email protected] を実行し、続けて cx cases acknowledge <id> を実行します。
4. 調査結果を記録する — cx cases comment <id> --text "<note>" を実行して、 調査中にタイムラインへ調査メモ（根本原因、リンク、次の手順）を残します。 コメントは cx cases events list で comment イベントとして表示されます。
5. 解決またはクローズする — 下記を参照してください。
6. 算出値と影響が異なる場合は、優先度を再設定します — cx cases set-priority <id> --priority P1 / clear-priority。ケースがまだオープンの間のみ実行できます。ケースが RESOLVED または CLOSED になると、優先度を上書きできません。

解決

解決は取り消し不可（RESOLVED のケースは CLOSED にしか遷移できません）のため、 CLI では理由と確認の両方が必須です。

• --reason "<text>" を渡します — 根本原因、修正内容、フォローアップを記した1行の事後報告で、チームメイトがタイムラインで確認できます。理由が本当に該当しない場合に限り、--no-reason を使います。
• エージェント／非対話モードでは、--yes も渡します。これを指定しない場合、コマンドは拒否されるため、対話形式でユーザーに実行してもらう必要があります。

不確かな場合は、確信が持てるまで ACKNOWLEDGED のままにします（unacknowledge で取り消し可能）。解決以外の編集（タイトル、事後報告へのリンク追加など）には、cx cases update を使います。

一括操作

一括操作用のエンドポイントはありません。複数のケースを操作するには、ループで ID を渡します。例： ... | jq -r '.[].id' | xargs -I {} cx cases acknowledge {}。

重要な原則

• ユーザー ID ではなく、必ずメールアドレスを使用してください — assign --user とすべての出力で使用します。
• resolve は取り消せず、close は終端状態です — 解決する前に確認してください。誤報の場合は、ACTIVE から直接 close します。
• --no-reason が本当に適用される場合を除き、必ず解決理由を指定してください。
• P1 形式の略記は、優先度／ステータス／カテゴリが求められる箇所で使用できます。
• 複数プロファイルへの一括実行には、-p <profile>（繰り返し指定可能）を使用して、環境をまたいでトリアージします。
• 特定のケースへのリンクを作成するには、<base>/cases?id=<case_id> を組み立てます。ここでの <base> は、このセッション中にいずれかの cx cases コマンドが出力した `View in Coralogix: /...` 行です。`` を独自に作り出してはいけません。

参考資料

• ケースの分析： references/case-analytics.md
• 単一ケースの調査： references/single-case.md

関連スキル

• cx-alerts — ケースにまとめられたイベントの元となるアラート定義です。
• cx-slos — 信頼性ケースにつながる違反の元となる SLO 定義です。
• cx-telemetry-querying — ケースの影響を受けたエンティティからログ／スパン／メトリクスに移動します。