Workflow Automation
モニターやセキュリティシグナルをきっかけに、チケット起票や通知やクラウド操作といった一連の手順を Datadog の中で自動実行する仕組みです。トリガー、ステップ、分岐と再試行を画面で組み、人の定型作業を実行可能な流れに変えます。
何ができるか
モニターのアラート、セキュリティシグナル、インシデント、スケジュール、手動などのトリガーを起点に、アクションを順に実行する「ワークフロー」を作ります。アクションはクラウドや SaaS の操作から Datadog 内の操作まで公式カタログに並び、if 分岐や繰り返し、HTTP リクエスト、JavaScript でのデータ加工を挟めます。失敗したステップの再試行と、失敗時の別経路も設定できます。
どのような場面で使うか
アラートが鳴ったら Jira にチケットを作って Slack に知らせる、しきい値超過で Auto Scaling Group の台数を増やす、セキュリティシグナルで検知した IP を調査ノートにまとめてから遮断する、ダッシュボードのボタンから安定版へのロールバックを実行する、といった手順の自動化に使います。
身近な例え
工場のラインに置かれた組み立てロボットです。センサー (モニター) が異常を検知したら、部品を取り出し (チケット作成)、ラベルを貼り (通知)、不良品を脇に寄せる (スケール調整) まで、教えた手順をその順番で毎回同じように実行します。教えていない事態が起きたときに止まって人を呼ぶ動きも、あらかじめ手順の一部として組み込めます。
結論 - 手順書をトリガーから実行可能な流れにする
Workflow Automation は Datadog の中で「きっかけ」から「一連の操作」までを 1 本の流れとして組み、自動で回す製品です。公式ドキュメントは、インフラやツールに接続するアクションを組み合わせ、データ操作と論理操作を挟んで分岐や判断を含む流れを作れると説明し、アクションの数は 2,000 を超えるとしています (2026 年 9 月時点・出典: Workflow Automation)。アラート が鳴った後に人がやっている作業、たとえばチケットを切る、当番に知らせる、対象を増設するといった定型の手順を、モニターを起点に自動で実行する形に置き換えられます。毎回の障害で「起票と連絡に 15 分」が消えている組織なら、その 15 分を復旧に回せることが導入の価値です。単価は公開価格表に行が無いため本記事では数字を書きません。手順ページは「公開したワークフローは実行回数に基づいて費用が発生する」と述べ、料金ページへ誘導します (出典: Build workflows)。
- トリガー: モニター、セキュリティシグナル、インシデント、ダッシュボードのボタン、Slack、API、スケジュール、手動など
- ステップ: 公式カタログのアクション (クラウド、SaaS、Datadog 内の操作) と、HTTP リクエストや JavaScript による加工
- 制御: if 条件、switch、for と while の繰り返し、待機、失敗時の再試行と別経路
- 公開: テストして公開すると、以後はトリガーのたびに実行され、実行履歴が残る
11 種のトリガーと実行主体の選び方
公式のトリガー一覧は 11 種で、1 本のワークフローに複数のトリガーを付けられます (2026 年 9 月時点・出典: Trigger a workflow)。見落としやすいのが実行主体です。各実行は 1 つの Datadog の identity で走り、所有者、実行した人、サービスアカウントのいずれかを Run as で選びます。スケジュールや API のように人が介在しないトリガーでは、所有者かサービスアカウントが必須です。この identity が、使える接続情報、読み書きできる Datadog リソース、監査証跡に残る名前を決めます (出典: Access and Authentication)。自動化を増やすほど「誰の権限で動いたか」が問われるため、本番用のワークフローはサービスアカウントで走らせ、権限を RBAC で絞るのが設計の初手です。
| トリガー | 起点 |
|---|---|
| 手動 | ワークフロー画面の Run |
| ダッシュボード | Run Workflow ウィジェット (テンプレート変数を入力に対応付け) |
| モニター | モニターの通知 (既定で自動、手動に切り替え可) |
| インシデント | インシデントのイベント、またはインシデント画面から手動 |
| セキュリティ | セキュリティシグナルと検出結果 (通知ルール経由の自動、パネルからの手動) |
| Software Catalog | カタログのエンティティから |
| GitHub | GitHub 側の Webhook (作成権限が必要) |
| Slack | 手動、または絵文字リアクション (Datadog App の導入が前提) |
| API | API キーと workflows_run スコープのアプリケーションキー |
| スケジュール | 時刻 (サービスアカウントで実行) |
| 別のワークフロー | Trigger Workflow アクションによる子ワークフローの呼び出し |
Webhook で足りる場面と、Workflow が要る場面
Webhook は決めた URL へ通知を HTTP で押し出す送信口で、先は受け側で自作します。Workflow Automation はその「先」を Datadog の中に置きます。違いは 4 点です。認証情報を Connections として Datadog 側で管理し、インテグレーションの資格情報を引き継ぐこと。失敗したステップを回数と間隔を決めて再試行し、尽きたら別経路へ進めること。if 条件、switch、繰り返しで分岐できること。成否を Slack や Microsoft Teams へ通知し、実行履歴が残ることです (2026 年 9 月時点・出典: Build workflows、Getting Started with Workflow Automation、Access and Authentication)。受け口を持つ自動化基盤があり、分岐も再試行も賄えるなら Webhook で足ります。無ければ Workflow の方が認証と失敗処理の作り込みを省けます。
| 観点 | Webhook | Workflow Automation |
|---|---|---|
| 向き | Datadog から URL へ一方向 | アクションの結果を次のステップへ渡す |
| 処理の置き場所 | 受け側のサーバーで自作 | Datadog の中 (アクションとロジック) |
| 認証情報 | 受け側で用意 | Connections で管理、インテグレーションの資格情報を引き継ぐ |
| 失敗時 | 受け側の実装に依存 | 再試行の回数と間隔、失敗時の別経路 |
| 分岐と繰り返し | なし | if 条件、switch、for と while、待機 |
| 記録 | 受け側のログ | 実行履歴と Run as の identity による監査証跡 |
インシデントやケースを自動で作る接続
アクションカタログには外部 SaaS だけでなく Datadog 自身の操作も並びます。2026 年 9 月時点で Datadog Incidents (作成、状態の更新など)、Datadog On-Call、Datadog Events、セキュリティシグナルやセキュリティ検出結果からケースを作るアクションが確認できます (出典: Action Catalog)。モニターが鳴ったら インシデント を宣言し、On-Call の当番に呼び出しを送り、ケース に調査の受け皿を作る、という流れを 1 本にできます。ただしインシデント側には文脈を組み込み済みで追加課金のない Incident Automations が別にあり、公式は複数トリガーの 1 つとしてインシデントを扱う場合にワークフローを使うよう案内しています (出典: Trigger a workflow)。Event Management で束ねたアラートを起点にするか個々のモニターを起点にするかは、実行回数に直結する設計点です。
外部サービスのアクションと上限値の読み方
カタログのアクションは相手先ごとに束ねられ、Slack、Jira、ServiceNow、PagerDuty、GitHub、Kubernetes、Statuspage、各クラウドの操作などが並びます。汎用アクションとして HTTP リクエスト、JavaScript によるデータ変換、フロー制御 (if 条件、switch、sleep、for、while)、保存したアクションの再利用もあります (2026 年 9 月時点・出典: Actions、Workflow Logic)。上限は有料アカウントで下の表のとおりで、超えた分は待ち行列で順に処理されます (出典: Limits)。同じ発生元 50 本 / 分の上限は「1 つのモニターが 500 回鳴る」型の嵐で効くため、モニター側で 通知の集約 を先に済ませてからワークフローを繋ぐ順番が安全です。App Builder は同じアクションカタログを使う別製品で (出典: Action Catalog)、本記事では扱いません。
| 項目 | 上限 |
|---|---|
| ワークフローの作成 | 1 組織あたり 500 本 / 分 |
| ワークフローの実行 | 1 組織あたり 200 本 / 分 |
| 同じ発生元からの実行 | 50 本 / 分 (特定のモニターなど) |
| 待ち行列 | 1 組織あたり 500 件 |
自動化してよい判断と、人が残す判断の線引き
手順が書けるものは自動化でき、書けないものはできません。この基準では、任せてよいのは起票、連絡、情報収集、可逆な緩和の 4 つです。いずれも失敗しても戻せるうえ実行履歴が残ります。人が残すのは不可逆な操作 (削除、決済に関わる設定変更) と原因の判断です。Workflow はこの境目を手順に埋め込む道具を持ち、手動トリガー、Slack の絵文字リアクション、Slack 向けアクションの Make a decision とモーダル表示 (Prompt user with modal)、条件が満たされるまで待つステップで、人の確認を挟んだ後に続きを回せます (2026 年 9 月時点・出典: Trigger a workflow、Build workflows、Action Catalog)。最初の 1 本は公式の入門例「モニターが鳴ったら Jira にチケットを作り Slack にリンクを送る」から始め、判断の部分を手動トリガーとして残すと、範囲を後から広げられます。
| 区分 | 例 | 理由 |
|---|---|---|
| 任せてよい: 起票 | Jira や ServiceNow にチケットを作る | 戻せる、履歴が残る |
| 任せてよい: 連絡 | Slack や Microsoft Teams へ通知、On-Call へ呼び出し | 遅れが直接の損失になる |
| 任せてよい: 情報収集 | 関連ログやメトリクスを集めてチケットに添える | 読み取りだけで副作用が無い |
| 任せてよい: 可逆な緩和 | 上限つきのスケールアウト、フィーチャーフラグの無効化 | 元に戻す手順が明確 |
| 人が残す: 不可逆な操作 | リソースの削除、決済や契約に関わる設定変更 | 失敗を取り消せない |
| 人が残す: 原因の判断 | 根本原因の断定、恒久対策の選択 | 手順に書き下せない |
注意点
- 本記事は 2026 年 9 月時点の公式ドキュメントの記載に基づいています。トリガーの種類、アクションカタログの項目、上限値は変わり得るため、設計時は公式ドキュメントの一覧を優先してください。
- Workflow Automation の単価は公開価格表に行が無いため、本記事では数字を書いていません。公開したワークフローは実行回数に基づいて費用が発生すると公式ドキュメントに記載があります (2026 年 9 月時点)。料金の確認は公式料金ページで行ってください。
- 本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。