こんにちは！プロダクトの成長とともに増えていくアラート、夜中の容赦ないPagerの鳴り響き、そして「これ、誰が対応するんだっけ？」とSlackのチャンネルで押し付け合う絶望的な朝……。そんな地獄のようなインシデント対応のループから、あなたを救い出すための話をしよう。
世の中には便利な監視ツールがたくさんある。しかし、標準のインテグレーションだけでは、どうしても「組織のリアルなワークフロー」に微妙に噛み合わない瞬間が訪れる。
今回は、Datadog Incident ManagementのWebhookを徹底的にハックし、既存のSaaSの枠を超えた「完全自動化された独自のエスカレーション＆チャットボット連携」の裏技を伝授する。
これをマスターすれば、あなたのチームの障害対応は劇的にスマートになり、毎日の運用ストレスから解放されるはずだ。さあ、一緒に深淵なるオブザーバビリティの世界へ踏み出そう。
—
1. なぜ「標準のインテグレーション」だけでは物足りないのか？
Datadogは、PagerDutyやSlackへの標準的なインテグレーションを提供している。これらは非常に強力で、導入も簡単だ。しかし、現場の規模が大きくなり、複雑な組織体制になると、次のような「壁」にぶぶつかる。
- 「今週のオンコール担当」を、自社の社内人事DBやシフト管理システムと連動させたい
- 障害の深刻度（Severity）や影响範囲に応じて、特定の社内システムのAPIを叩いて自動で専用の対応ルーム（Zoomや社内ツール）を生成したい
- Slack上で「一次対応完了」「原因調査中」などのボタンを押したら、それが即座にDatadog側のインシデントステータスに双方向で同期されるようにしたい
これらを実現する鍵が 「Datadog Webhook × カスタムサーバー（あるいはServerless Function）」 だ。Datadogでインシデントが起きた瞬間、その全ての文脈（Context）を含んだJSONペイロードを任意の宛先に飛ばし、我が意のままに料理する。このアーキテクチャの基本を、今日ここで完全にモノにしよう。
—
2. 全体像の理解：Webhookが奏でる自動化のシンフォニー
私たちが目指すアーキテクチャは非常にシンプルだ。
[ Datadog Incident Management ]
│
▼ (Webhook: POSTリクエスト)
[ API Gateway / AWS Lambda (あなたのカスタムボット) ]
├── 1. 担当者自動アサイン (社内DB/カレンダー照会)
├── 2. 独自Slackチャンネルへのリッチ通知 ＆ アクションボタン付与
└── 3. 外部チケット管理システム（Jira/Notion等）への自動起票
Datadogは「何が起きたか（What）」を教えてくれる。それをどうハンドリングするかは、私たちのコード次第というわけだ。
—
3. ステップ・バイ・ステップ：カスタムWebhookの基礎セットアップ
まずは、Datadogからシグナルを受け取るための「受け皿（エンドポイント）」を作り、Datadog側からWebhookを飛ばす設定を行おう。今回は最も手軽で堅牢な AWS Lambda + API Gateway の構成を例に解説するが、Node.jsやPythonが動く環境であれば何でも構わない。
Step 3-1: 受け皿となるサーバーレス関数の作成（Python）
まずは、Datadogから送られてくるJSONを受け取り、ログに出力するだけのシンプルなスクリプト（Lambda関数）を書こう。これが私たちの「Hello World」だ。
import json
import logging
ロガーの設定（CloudWatch Logsで美しく確認するため）
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
“””
Datadog Incident Webhookを受け取るエントリーポイント
“””
logger.info(“=== Datadog Incident Webhook Received ===”)
try:
# API Gateway経由の場合、ボディは文字列として入っているためパースする
body = json.loads(event.get(‘body’, ‘{}’))
# インシデントの基本情報を抽出
incident_id = body.get(‘id’, ‘unknown’)
title = body.get(‘title’, ‘No Title’)
severity = body.get(‘severity’, ‘UNKNOWN’)
status = body.get(‘status’, ‘ACTIVE’)
logger.info(f”Incident ID: {incident_id}”)
logger.info(f”Title: {title}”)
logger.info(f”Severity: {severity}”)
logger.info(f”Status: {status}”)
# ここに独自のビジネスロジック（Slack通知やDB保存）が入る
return {
‘statusCode’: 200,
‘body’: json.dumps({‘message’: ‘Successfully processed webhook’})
}
except Exception as e:
logger.error(f”Error processing webhook: {str(e)}”, exc_info=True)
return {
‘statusCode’: 500,
‘body’: json.dumps({‘error’: str(e)})
}
Step 3-2: Datadog側でのWebhook統合設定
コードの準備ができたら、API GatewayのエンドポイントURLを控えて、Datadog側でWebhookの設定を行う。
1. Datadogの管理画面にログインし、左メニューの Integrations から Webhooks を検索して選択する。
2. New Webhook ボタンをクリックする。
3. 以下の項目を入力・選択する：
- Name: `my-custom-incident-bot`
- URL: 先ほど作成した API Gateway のエンドポイントURL
- Payload: デフォルトのままでも良いが、インシデント管理に特化させるため、以下のようなカスタムペイロードを定義することも可能だ。
{
“id”: “$INCIDENT.ID”,
“public_id”: “$INCIDENT.PUBLIC_ID”,
“title”: “$INCIDENT.TITLE”,
“severity”: “$INCIDENT.SEVERITY”,
“status”: “$INCIDENT.STATUS”,
“created_at”: “$INCIDENT.CREATED_AT”,
“url”: “$INCIDENT.URL”,
“creator”: “$INCIDENT.CREATOR.NAME”
}
4. Save を押して保存する。これでDatadog側の準備は完了だ。
—
4. 精度高い「HelloWorld」：テストイベントを飛ばして検証する
設定が正しく行われているか、実際にインシデントを発生させて（あるいはテスト機能を使って）動作確認をしよう。
Datadogの Incident Management 画面から、手動で新規インシデントを起票してみる。
- Title: `[Test] データベースの応答遅延検知`
- Severity: `SEV-2`
起票ボタンを押した瞬間、DatadogからあなたのLambdaへHTTP POSTリクエストが飛ぶ。AWSのCloudWatch Logsを開いてみよう。そこには先ほど記述したログが美しく出力されているはずだ。
[INFO] 202X-XX-XXT… === Datadog Incident Webhook Received ===
[INFO] Incident ID: inc-12345-abcde
[INFO] Title: [Test] データベースの応答遅延検知
[INFO] Severity: SEV-2
[INFO] Status: ACTIVE
おめでとう！これでDatadogとあなたのカスタムシステムの間に、強固なデータパイプラインが開通した。
—
5. 【現場の裏技】ここから先へ：Slackとのリッチな双方向連携への応用
「ログに出力できたから何なの？」と思うかもしれない。ここからが本番だ。受け取ったLambdaの中で、例えば以下のような処理を実装していく。
1. オンコール・カレンダーの参照:
今日が何曜日で、誰が当番かを持つ社内APIをLambdaから叩き、Datadogインシデントの `commander`（司令塔）に自動アサインする。
2. Slack Block Kitを使ったインタラクティブ通知:
単なるテキストではなく、Slackの「対応開始」「エスカレーション」ボタンが付いたリッチなメッセージを独自のSlackボット経由で送信する。
import urllib.request
import json
def send_slack_interactive_message(incident_id, title, severity):
slack_webhook_url = “https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK”
payload = {
“text”: f”🚨 インシデント発生 [{severity}]”,
“blocks”: [
{
“type”: “section”,
“text”: {
“type”: “mrkdwn”,
“text”: f”Title: {title}\nID: {incident_id}”
}
},
{
“type”: “actions”,
“elements”: [
{
“type”: “button”,
“text”: {“type”: “plain_text”, “text”: “️️⚡️ 一次対応を開始する”},
“style”: “primary”,
“value”: f”acknowledge_{incident_id}”
},
{
“type”: “button”,
“text”: {“type”: “plain_text”, “text”: “🔥 シニアにエスカレーション”},
“style”: “danger”,
“value”: f”escalate_{incident_id}”
}
]
}
]
}
req = urllib.request.Request(
slack_webhook_url,
data=json.dumps(payload).encode(‘utf-8’),
headers={‘Content-Type’: ‘application/json’}
)
urllib.request.urlopen(req)
ユーザーがSlackのボタンを押したときのイベント（Interactive Components）を別のエンドポイントで受け取り、Datadog API（`/api/v2/incidents/{incident_id}`）を叩いてステータスを更新する――ここまで作り込めば、チームのインシデント対応体験は完全にオートメーション化され、無駄なコンテキストスイッチ（作業の分断）が消え去る。
—
おわりに：監視の自動化は、エンジニアの心を守る盾である
今回は、Datadog Incident ManagementのWebhookを活用した独自の障害エスカレーション自動化の基礎について解説した。
監視ツールは、ただアラートを鳴らすためのものではない。私たちが夜穏やかに眠り、プロダクトの価値創造に集中するための「守るための技術」だ。既製品の枠に囚われず、自分たちの組織に最適なフローをコードで表現できるようになると、オブザーバビリティの本当の楽しさが見えてくる。
これをマスターしたあなたなら、日々のオペレーションを劇的に楽にできるはずだ。さあ、今すぐ自分の環境でも試してみてほしい。健闘を祈る！