Work Management
Work Management (旧称 Case Management) は、インシデント未満の対応の件を、担当と状態を持つ作業項目として追跡する機能です。モニターやセキュリティシグナルから起こした件をプロジェクトの中で開いて閉じます。
何ができるか
Datadog と外部連携が検出した問題を、作業項目 (work item) として選別、追跡、是正します。項目には担当者、状態 (open / in progress / closed)、優先度 (P1 から P5) が付き、活動タイムラインで経緯が残ります。Jira / ServiceNow / PagerDuty / Slack / Microsoft Teams と連携します。
どのような場面で使うか
「モニターが鳴ったが今すぐ人を起こす話ではない」「セキュリティシグナルを誰かが見て判断する必要がある」「エラーの修正を来週まで追いたい」といった、インシデント未満で放置もできない件を記録に残すときに使います。承認つきの変更管理や、Jira への起票元としても働きます。
身近な例え
役所の窓口で配られる受付番号札と受付台帳です。持ち込まれた用件は番号を付けて台帳に載り、担当窓口と処理状況が書き足されて、済んだら閉じられます。災害対策本部 (インシデント) を立てるほどではない用件を、窓口で確実にさばくための仕組みです。
結論 - 旧 Case Management、インシデント未満の件を項目にして回す
Case Management という名前で探していた機能は、Work Management に改称されています。公式ドキュメントは冒頭で旧称を明記し、API と権限名には引き続き case の語が残ると注記しています (2026 年 9 月時点・出典: Work Management)。役割は、Datadog と外部連携が検出した問題を選別、追跡、是正する中央の置き場です。作業項目 (work item) に担当者を割り当てると、所有がその項目の生存期間を通して残ります。調査中はグラフやログを項目に貼り、活動タイムラインで協業します。連携先として Jira、ServiceNow、PagerDuty、Slack、Microsoft Teams が挙げられています。この機能が無いと、「鳴ったが緊急ではない」件はチャットに流れて消え、翌月に同じモニターが鳴っても前回の扱いを誰も思い出せません。あると、その件が誰の手元にあり、何が分かっていて、どこで閉じたかが 1 つの画面に残ります。
作業項目とインシデントの線引き
線引きの基準は「今すぐ人を集めて宣言するか」です。サービスに影響が出ていて指揮者を立て、時刻つきで記録しながら復旧する事象は Incident Management の領分で、状態は Active / Stable / Resolved と進みます (遷移の詳細は同解説に譲ります)。一方、モニターの通知やセキュリティシグナル、エラーの件など「誰かが見て判断し、対応を追う必要はあるが宣言はしない」ものが作業項目です。作業項目の状態は open で始まり、in progress を経て closed へ進む 3 段で、優先度は P1 - Critical から P5 - Info の 5 段を任意で付けます (2026 年 9 月時点・出典: View and Manage Work Items)。両者は排他ではなく、作業項目を調べているうちに影響が大きいと分かれば、その項目からインシデントを宣言して昇格できます。逆に振り返りで出た再発防止の作業を項目として追うこともできます。
| 観点 | 作業項目 (Work Management) | インシデント (Incident Management) |
|---|---|---|
| 扱う対象 | 検出された問題の選別、追跡、是正 | 影響が出ている事象の宣言から振り返りまで |
| 状態 | open → in progress → closed | Active → Stable → Resolved |
| 優先度 / 重大度 | P1 - Critical から P5 - Info (任意) | 宣言時に重大度を設定 |
| 所有 | 担当者 1 名 (既定は未割り当て) | 指揮者と役割 |
| 相互の接続 | 項目からインシデントを宣言して昇格 | 再発防止の作業を項目として追う |
作業項目はどこから生まれるか
作られ方は手動、自動、API の 3 通りです。手動では New Work Item を押すほか、モニター、セキュリティシグナル、Error Tracking、Watchdog、Event Management、Cloud Cost Management、Sensitive Data Scanner、Slack の各画面からも起こせます (2026 年 9 月時点・出典: Create a Work Item)。自動では、モニターの通知文に @case-<project_handle> を書くとアラートのたびに項目が作られ、Event Management の相関、Workflow Automation の Create Case アクション、Error Tracking の課題への操作からも作られます。項目には work type が付き、Standard、Change Request、Event Management、Security、Error Tracking とカスタム型があります。
- プロジェクト設定の Integrations で Datadog Monitors を有効にし、@case-<project_handle> を得る
- モニターの通知文にそのハンドルを書く
- アラートのたびに、そのプロジェクトへ作業項目が自動で作られる
- 担当者を割り当て、状態を in progress へ進め、調べたグラフやログを貼る
- closed にする、または影響が大きければインシデントを宣言する
項目の中身は状態と優先度と担当とタイムライン
1 つの項目が持つのは状態、優先度、担当者、活動タイムラインです。状態は作成時に open、優先度と担当者は既定で未設定で、キーボードの S、P、A で変え、I で自分に割り当てます。アーカイブすると検索から外れます。活動タイムラインは状態、担当者、優先度、シグナル、コメントの更新を自動で時刻つきに記録し、コメントで名指しされた人にはメールが届きます (2026 年 9 月時点・出典: View and Manage Work Items)。効くのは、記録が操作の副産物として残ることです。対応中に議事録を取る人はいませんが、状態を変えた事実と貼ったグラフは残ります。さらに Work Management Analytics は項目の集計をクエリできるデータソースで、ダッシュボードやノートブックの時系列、トップリスト、クエリ値、テーブル、円グラフなどのウィジェットで描けます。「先月このプロジェクトで開いた項目のうち、どれだけが 1 週間以内に閉じたか」がグラフになります。
インシデントへの昇格と Jira や ServiceNow との住み分け
項目の出口は 5 つで、インシデントの宣言、Jira の課題作成、ServiceNow のインシデント作成、承認依頼、closed にして閉じる、です (2026 年 9 月時点・出典: View and Manage Work Items)。外部チケットとの住み分けで迷いやすいのは「Jira があるなら Work Management は要らないのでは」という問いです。公式ドキュメントは Jira、ServiceNow、Linear との連携について、Datadog のテレメトリを使って項目を解決しつつ、調査の記録をそれらの外部システムにも保持できると説明し、Jira は自動起票と双方向同期の設定に対応します (出典: Settings)。選択は二者択一ではなく、「調べる場所」と「記録の正本」を分ける設計です。グラフとログを貼って原因を追う作業は Datadog 側、部署をまたぐ承認やチケット番号の管理は既存のチケット基盤、という分け方をすれば二重入力は同期が吸収します。
| 出口 | 何が起きるか | 向く場面 |
|---|---|---|
| インシデントを宣言 | 項目からインシデントを起こし、対応プロセスを開始 | 調べるうちに影響が広いと分かった |
| Jira の課題を作る | 手動作成のほか、自動起票と双方向同期を設定できる | 開発チームの作業管理が Jira にある |
| ServiceNow のインシデントを作る | 手動で ServiceNow 側に起票 | IT サービス管理の記録を ServiceNow に置く |
| 承認を依頼 | 1 人以上のレビュアーに承認を求め、結果をタイムラインに記録 | 変更管理で実施前の確認が要る |
| 閉じる | 状態を closed にして終了 | 追加の対応が不要と判断した |
プロジェクトと権限、放置された項目の自動クローズ
項目は 1 つのプロジェクトに属します。プロジェクトは 1 から 10 文字のキーを持つ容れ物で、項目の ID は NOC-123 のようにキーを接頭辞にします。キーは変更不可、削除した項目は復元不可です (2026 年 9 月時点・出典: Projects)。権限は Manager、Contributor、Viewer、No Access の 4 段 (既定は無制限) です。他製品からの自動作成は権限に関わらず行われます。放置対策として、人の操作 (属性の更新やコメント) が 7、14、30、90、180 日無い項目を自動で閉じる設定があり、判定は 1 日 1 回です (出典: Settings)。承認機能では 1 人以上のレビュアーに合意を求め、Requested / Approved / Declined がタイムラインに残ります (出典: Work Item Approvals)。組織全体の履歴は Audit Trail の領分で、項目のタイムラインはその件に閉じた記録です。
小さな対応を記録に残すと何が変わるか
変わるのは 3 つです。1 つ目は再発が見えることです。同じモニターから毎週項目が作られるなら、しきい値か仕組みの問題で、Analytics で件数を並べれば議論が数字になります。2 つ目は引き継ぎです。担当者と調べた経緯がタイムラインに残るため、休暇や異動で人が替わっても続きから始められます。3 つ目は変更管理です。Change Request 型と承認機能を使えば、「誰が承認して実施したか」が後から追えます。呼び出しの領分とは役割が違い、On-Call が「今すぐ人を起こす」ための仕組みなら、Work Management は「明日でよいが忘れてはいけない」件のための仕組みです。料金は本記事では単価を示さず、公開価格表と担当窓口で確認してください。同じ並びにある Incident Management のシート課金の考え方は同解説の料金節に、料金体系の全体は料金の読み解きにまとめています。
注意点
- Work Management は 2026 年 9 月時点の公式ドキュメントで「以前は Case Management という名称」と注記されています。API のエンドポイントと権限名、モニターのハンドル (@case-<project_handle>) には引き続き case の語が使われます。
- 本記事は 2026 年 9 月時点の公式ドキュメントの記載に基づいています。作成元の製品や work type は追加され得るため、一覧は公式ドキュメントで確認してください。
- 本記事は Work Management の単価を示していません。契約条件は公開価格表と担当窓口で確認してください。