Datadog×Coworkで障害時のアラート閾値を調整する

本番障害の最中に「このアラートは閾値が低すぎて毎回鳴っているのか、それとも本当に異常なのか」を調べる作業は、ログを読む調査とモニター定義を書き換える作業の両方を含みます。前者を人力で毎回追いかけていると、原因の当たりを付けるだけでも時間がかかり、その間にアラートは鳴り続けます。Cowork上でDatadog Connectorを使うと、ログ調査からモニターの閾値案を作るところまでは承認を挟まずに進められますが、既存のモニターを直接書き換えるツールはDatadogConnectorにありません。この構成を、調査と作成の境界で承認を挟む形で組みます。

前提条件

Coworkはデスクトップ版がPro・Max・Team・Enterpriseの全プランで使え、webとモバイルはベータ版としてPro・Max・Teamに加えオーナーが有効化した場合のEnterpriseで使えます。DatadogConnectorが接続済みであることが前提です。接続手順そのものはClaudeでDatadogとSentryを連携するにまとめてあるので、未接続の場合は先にそちらを済ませます。

接続後、対象のDatadogConnectorを選んで「Tool permissions」を開きます。読み取り専用のツール(search_datadog_logs analyze_datadog_logs search_datadog_monitorsなど)のカテゴリは「常に許可」に設定します。モニターを新規作成するcreate_datadog_monitorだけは「承認が必要」にしておきます。この非対称な設定が、以降の調査を承認を挟まずに進めつつ作成だけを止める土台になります。

Coworkにはこれとは別に、会話ごとの承認モード(自動承認・すべての承認をスキップ・手動承認)があります。Connector側を「承認が必要」にしていても、会話の承認モードが「すべての承認をスキップ」になっていると、実行前のチェック自体が働きません。この構成を使う会話では、承認モードを「自動承認」または「手動承認」にしておくことも忘れずに確認します。

障害の対象範囲を絞ってログを調べる

Coworkの会話で、まず対象サービスと時間範囲を絞って調査を依頼します。

決済APIサービスで、直近2時間のエラーログを調べて。エラー率が上がり始めた時刻と、その前後で増えているエラーメッセージの種類を教えて。関連するトレースがあれば、レイテンシーが伸びている箇所も特定して。

サービス名・時間範囲を明記すると、search_datadog_logsとanalyze_datadog_logsが対象を絞って動きます。範囲を指定せずに「全部のログを調べて」と依頼すると、応答が遅くなったり、無関係なサービスのログまで拾ったりします。

対象サービスのモニターを先に一覧する

原因の当たりが付いたら、閾値の提案に進む前に、該当サービスに設定済みのモニターを確認します。

決済APIサービスに紐づくモニターを一覧して。それぞれのモニターID・監視対象のメトリクス・現在の閾値・直近の発報履歴を教えて。

search_datadog_monitorsがモニターID・メトリクス・閾値を返します。ここでモニターIDを控えておくと、次の閾値提案のやり取りで「どのモニターの話をしているか」をClaudeと人の双方が取り違えずに進められます。同じサービスに似た名前のモニターが複数あることも珍しくないため、IDでの特定は省略しないほうが安全です。発報履歴も一緒に確認しておくと、そもそも閾値の調整が必要な状態なのか、それとも別の原因で通知が来ていないだけなのかの切り分けにも使えます。

既存モニターの閾値は「更新」できない

この制約を踏まえると、Coworkに依頼する内容は「既存モニターの閾値を変えて」ではなく、次のような形になります。

先ほど確認した決済APIのp95レイテンシーモニターについて、直近2時間の実測値をもとに適切な閾値を提案して。提案した閾値でモニター定義の草案を作り、既存のモニターIDと新しい閾値の差分も添えて。

recommend_monitor_thresholdが閾値の候補を返し、generate_monitor_messageが通知文面を含むモニター定義を組み立てます。Datadog上にモニターを作成するのはcreate_datadog_monitorだけなので、この段階ではDatadog側にはまだ何も反映されません。

モニター作成だけを承認で止める

草案の内容を確認したうえで、実際にcreate_datadog_monitorを実行する段階になって初めて承認プロンプトが表示されます。「Tool permissions」でこのツールを「承認が必要」にしてあるため、Claudeが作成を提案しても、実行前に必ず人の確認を挟みます。誤った閾値のままモニターが作成されることはなく、承認画面でモニター定義の内容を最終確認できます。承認を求められた時点で会話にはすでにモニター定義の草案が出ているため、承認するかどうかは新たに調べ直さず、その場に表示されている内容と直前のやり取りを見比べるだけで判断できます。

作成が完了しても、閾値を上げすぎて元のモニターが鳴り続けている場合は見逃しにつながります。新しいモニターの動作を数日確認したうえで、古いモニターをDatadog本体でミュートまたは削除する作業を忘れずに行います。

Team・Enterpriseプランでは、この個人設定の上に組織設定がもう1層重なります。組織のオーナーは「コネクタが書き戻せるアクション」を組織全体で制限できます。この組織設定がかかっている場合、個々のメンバーが「Tool permissions」でcreate_datadog_monitorを「常に許可」に変えても、組織側の制限が優先されます。個別のユーザーは組織設定を上書きできません。想定どおりに承認プロンプトが出ない、あるいは作成自体が失敗するときは、まず組織のConnector設定を確認します。

提案された閾値をそのまま承認していいか

recommend_monitor_thresholdが具体的に何を根拠に数値を出しているかは、公式ドキュメントに詳細な記載がありません。障害の再発防止として十分な値かどうかまでは、ツール自体は判断してくれないと考えたほうが安全です。

承認画面には、提案された閾値の数値とモニター定義の草案が表示されます。とくに障害対応の直後に依頼した提案は、直前の急増区間そのものを引きずった数値になりやすい場面です。承認する前に、依頼時に指定した時間範囲を思い出し、「平常時のデータではなく、いま起きている障害そのものの数値を根拠にしていないか」を一度確認してから承認します。疑わしいときは、障害の起きていない直近の期間だけを指定して再度提案を依頼するほうが確実です。

Scheduled Tasksではなくその場の会話で行う理由

Coworkには定期実行の仕組み(Scheduled Tasks)もありますが、この閾値調整の流れはその場の会話で進めるほうが向いています。障害時のログ調査は、対象サービス・時間範囲・気になっている症状のどれもが障害ごとに変わり、あらかじめ固定できるプロンプトにしにくい作業です。定期実行に向くのは、PagerDutyの未解決インシデントを一定間隔で見に行くような、条件と手順が毎回同じ監視です。閾値調整のように、その都度の状況を人が見ながら対象を絞り込む作業は、会話の中で都度指示を出したほうが柔軟に対応できます。

よくあるつまずき

• 「更新して」と頼んでも動かない: 更新用のツールが無いため、その依頼はそのままでは実行できません。「更新」ではなく「新しい閾値案を作って」という頼み方のほうが、意図した動きになります
• 古いモニターが鳴り続ける: 新しいモニターを作成しても、古いモニターは自動では止まりません。Datadog本体でのミュート・削除を、新モニター作成のたびに手順として組み込みます
• 調査範囲を絞らないと時間がかかる: サービス名・時間範囲を指定しないログ調査は、応答に時間がかかったり無関係な結果を含んだりします
• 作成ツールをブロックにすると承認の機会なしに作成が失敗する: create_datadog_monitorを「ブロック」にすると、承認を求める前にツール呼び出し自体が失敗します。作成を承認制で残しつつ提案は進めたい場合は「承認が必要」を選びます
• 承認しても作成が失敗する: Connector側の「Tool permissions」で作成を許可していても、接続した本人のDatadogアカウントにモニター作成の権限が無ければ作成は失敗します。ClaudeでのAction制限は、Datadog本体の権限を上書きして許可を広げるものではなく、あくまで狭める側にしか働きません

通知やインシデント作成は別記事の領分

閾値を変えたモニターが実際に鳴った後、誰に通知しどうエスカレーションするかはPagerDutyの役割です。未解決インシデントの定期監視と承認付きの通知の組み方はPagerDuty×CoworkでSLA監視とエスカレーションを自動化するにまとめてあります。Datadog・Sentry・PagerDutyを1つの会話に繋いだうえで、調査から通知までを1つの設計として見る場合はClaudeで監視ツール連携による障害対応ワークフローを設計するを参照してください。

まとめ

Datadog×Coworkでのアラート閾値調整は、ログ調査から閾値案の作成まではDatadog側に何も作らずに進め、モニターを作るcreate_datadog_monitorだけを「承認が必要」にして止める構成で組めます。DatadogConnectorに既存モニターを更新するツールが無いため、閾値の変更は実質的に新モニターの作成であり、古いモニターの停止はDatadog本体での別作業になる点は導入前に把握しておく前提です。この承認の境界は、Connector側の「Tool permissions」・Coworkの会話ごとの承認モード・Datadog本体のアカウント権限という3つが揃って初めて機能します。いずれか1つだけを設定して安心せず、3つを揃えて確認します。