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

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

この記事では、調査と作成の境界で承認を挟む構成を組みます。途中で、Coworkの承認モードによっては「承認が必要」の設定でも確認画面が出ない場合があること、作成したモニターは下書きで通知を送らないことも扱います。

前提条件

Coworkはデスクトップ版がPro・Max・Team・Enterpriseの全プランで使えます。webとモバイルはPro・Max・Teamで使え、Enterpriseではオーナーが有効化した場合に使えます。2026年10月6日から、ProとMaxの新しいCoworkタスクはクラウドで動きます。ローカルのMCPサーバーを含むプラグインはデスクトップアプリ経由でのみ動きます。Datadog Connectorはリモートのコネクタです。

Datadog Connectorが接続済みであることが前提です。接続手順そのものはClaudeでDatadogとSentryを連携するにまとめてあるので、未接続の場合は先にそちらを済ませます。

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

「承認が必要」でも確認が出ないモード

Connector側の設定とは別に、Coworkには会話ごとのモードがあります。「承認が必要」のツールを呼んだときの動きは、モードによって次のように変わります。

自動承認では、書き込み系のツールを「常に許可」にしていても、実行するかはClaudeが決めます。作成を止めたいときは、会話の承認モードを手動承認にしたうえで、create_datadog_monitorを「承認が必要」にします。新しいClaudeの画面では、メッセージ欄の権限設定に出る選択肢が「Auto」と「Manual」(既定)の2つです。

Team・Enterpriseでは組織側にも1層あります。「承認が必要」にしてあっても、自動承認そのものを管理者が無効にしている場合があります。書き込みができるConnectorのツールに、タスクごとの承認を組織として求めている場合は、個人の「常に許可」が効かないこともあります。

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

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

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

サービス名・時間範囲を明記すると、search_datadog_logsとanalyze_datadog_logsが対象を絞って動きます。search_datadog_logsはtime・query・service・hostなどのフィルターを取るので、依頼文でこれらを指定すると調査範囲を絞り込めます。

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

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

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

search_datadog_monitorsは、モニターの状態・閾値・アラート条件を返すツールです。ここでモニターIDを控えておくと、次の閾値提案のやり取りで「どのモニターの話をしているか」をClaudeと人の双方が取り違えずに進められます。似た名前のモニターが並んでいても、IDで特定すれば取り違えません。

現在の状態も一緒に見ておくと、そもそも閾値の調整が必要な状態なのか、別の原因で通知が来ていないだけなのかの切り分けに使えます。モニターの有無を先に見たいときは、Datadog側のツール一覧にあるget_monitor_coverageが、サービスやホストごとにエラー率・レイテンシー・リクエスト率のどれが既存のモニターで覆われているかを返します。

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

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

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

Datadog上にモニターを作成するのはcreate_datadog_monitorだけなので、草案の段階ではDatadog側にまだ何も反映されません。なお、検証ツールの名前は資料で食い違います。Claudeのコネクタ紹介ページにはvalidate_monitor_definition、Datadogのツールリファレンスにはvalidate_datadog_monitorと載っています。ツール名で指示を書くより、「定義を検証して」と依頼するほうが取り違えません。

作成したモニターは下書きで、通知を送らない

Datadogのツールリファレンスによれば、create_datadog_monitorはモニターを下書き(draft)モードで作ります。このツールで作ったモニターは通知を送らず、優先度は5(低)に設定されます。Datadogの画面で公開して初めて、通常のモニターとして動きます。作成に必要な権限は「Monitors Write」で、MCPサーバーは呼び出しのたびに権限を検査します。読み取り専用のユーザーが書き込み系のツールを呼ぶと、拒否されます。

この仕様は、運用の順序を変えます。作成した直後の新しいモニターは鳴らないので、数日様子を見ても動作の確認にはなりません。確認の順序は次のようになります。

• 作成後に、Datadogの画面で定義・閾値・通知先を見て、問題がなければ公開する
• 公開したあとで、新しいモニターが想定した条件で動いていることを数日見る
• 問題がなければ、古いモニターをDatadog本体でミュートまたは削除する

古いモニターを先に止めると、新しいモニターが公開されるまでの間は何も鳴らない空白ができます。逆に、閾値を上げすぎた新しいモニターを公開したまま旧モニターも止めると、見逃しにつながります。

承認の場面で確認すること

create_datadog_monitorの承認を求められたとき、会話にはすでにモニター定義の草案が出ています。承認するかどうかは調べ直さず、その草案と直前のやり取りを見比べて判断します。個人の「Tool permissions」を「常に許可」に変えても、組織側の設定が優先される場合があります。Team・Enterpriseのオーナーは、コネクタが書き戻せるアクションを組織全体で制限でき、個々のユーザーはこれを上書きできません。想定どおりに承認プロンプトが出ない、あるいは作成自体が失敗するときは、まず会話の承認モードを見て、次に組織のConnector設定を確認します。

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

Datadogのツールリファレンスのアラート系ツール(validate_datadog_monitor get_datadog_monitor_templates search_datadog_monitor_groups search_datadog_slos create_datadog_monitor get_monitor_coverage)には、recommend_monitor_thresholdの項目がありません。Claudeのコネクタ紹介ページには載っています。ツールの算出方法はどちらの資料にも載っていないので、障害の再発防止として十分な値かどうかは、ツール任せにしないのが安全です。

承認する前に、依頼時に指定した時間範囲を思い出し、「平常時のデータではなく、いま起きている障害そのものの数値を根拠にしていないか」を確かめます。疑わしいときは、障害の起きていない直近の期間だけを指定して、もう一度提案を依頼します。

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

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

よくあるつまずき

• 「更新して」と頼んでも動かない: 更新用のツールが無いため、その依頼はそのままでは実行できません。「更新」ではなく「新しい閾値案を作って」という頼み方のほうが、意図した動きになります
• 作ったモニターが鳴らない: create_datadog_monitorで作ったモニターは下書きで、通知を送りません。Datadogの画面で公開します
• 古いモニターが鳴り続ける: 新しいモニターを作成しても、古いモニターは自動では止まりません。Datadog本体でのミュート・削除を、新モニターを公開したあとの手順として組み込みます
• 承認を求められないまま作成された: 会話の承認モードが自動承認またはスキップだと、「承認が必要」の設定でも確認画面が出ないことがあります。手動承認に切り替えます
• 調査範囲を絞らないと時間がかかる: サービス名・時間範囲・クエリを依頼文で指定すると、ログ調査の対象を絞り込めます
• 作成ツールをブロックにすると承認の機会なしに作成が失敗する: create_datadog_monitorを「ブロック」にすると、承認を求める前にツール呼び出し自体が失敗します。作成を承認制で残しつつ提案は進めたい場合は「承認が必要」を選びます
• 承認しても作成が失敗する: 接続した本人のDatadogアカウントに「Monitors Write」の権限が無ければ、作成は失敗します。Claude側のAction制限は、Datadog本体の権限を超えて許可を広げるものではなく、狭める側にしか働きません

PagerDutyでの通知とインシデント対応

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

まとめ

作成を止める設定が効くのは、会話の承認モードが手動承認のときです。自動承認やスキップでは「承認が必要」でも確認が出ないことがあるため、create_datadog_monitorの承認に頼る運用では、モードを先に確かめます。作ったモニターは下書きなので、公開してから旧モニターを止める順序にします。