Claudeで監視ツール連携による障害対応ワークフローを設計する

DatadogでログとトレースとPagerDutyでオンコール通知を別々のタブで追いかける作業は、Claudeに3つの公式Connectorを繋げば1つの会話にまとめられます(個別の接続手順はClaudeでDatadogとSentryを連携するやDatadog MCP ServerをClaude Codeに接続する方法を参照してください)。ただし3つを同時に繋ぐと、読み取り用に加えてモニター作成やインシデント作成などの書き込み用ツールも同時に使える状態になります。ここでは、接続が済んでいる前提で、ログ→トレース→アラート→オンコール通知という一次調査の流れをどう設計し、書き込み操作をどこで止めるかをまとめます。

ログ→トレース→アラート→オンコール通知の4段階と担当ツール

本番障害の一次調査は、原因の特定と人への連絡という性質が異なる作業の連続です。この連続を4段階に分けると、各段階でどのConnectorのどのツールを使うかが決まります。

最初の3段階は「何が起きているか」を調べるだけの読み取り作業です。最後の1段階だけが、実際に人を呼び出す書き込み作業に変わります。この境界を設計の軸にします。

3つのConnectorを繋ぐと書き込みはどれだけ増えるか

DatadogConnectorは182個のツールを持ちます。ログ・トレース・モニターの参照系に加えて、create_datadog_monitor(モニター作成)、create_datadog_notebook(ノートブック作成)、create_datadog_security_detection_rule(検知ルール作成)のような書き込みツールも含みます。PagerDutyConnectorは64個のツールを持ち、create_incident add_responders create_schedule_override create_status_page_postなど、書き込み系のツールも一定数含まれています。

Sentryも接続すると、Issue検索に加えて、Seerによる自動修正の呼び出しも候補に加わります(Seerの具体的な使い方はSentry MCPをOAuthでClaude Codeに接続する方法を参照してください)。ログを調べているだけのつもりでも、Claudeが選べる次の一手には「モニターを作る」「インシデントを作る」「対応者を追加する」が常に並んでいる状態です。

読み取り専用の運用方針をどこで強制するか

「読み取り専用で使う」という方針は、宣言するだけでは効きません。実際に効かせる場所は4つあります。

1つ目はConnector自体の権限カテゴリです。接続済みのConnectorを選ぶと「Tool permissions」の一覧が開き、読み取り専用ツールと書き込み・削除ツールがカテゴリ単位で分かれています。各カテゴリ(または個別のツール)ごとに「常に許可」「承認が必要」「ブロック」のいずれかを選べます。モニターやIssueの参照系カテゴリを「常に許可」、create_datadog_monitorのような作成系カテゴリを「承認が必要」にすれば、調査は止まらず作成だけが人の確認待ちになります。この設定自体の考え方はClaudeのツールアクセス設定にまとめてあります。

2つ目は組織レベルのアクション制限です。TeamプランやEnterpriseプランのオーナーは、接続済みサービスが実行できるアクションを組織全体で制限でき、個々のメンバーはこの制限を自分の設定で上書きできません。個人のConnector設定を全員が正しく運用できるとは限らない組織では、こちらのほうが実質的な強制力を持ちます。

3つ目はClaude CodeのPreToolUseフックです。MCPツールはmcp__<サーバー名>__<ツール名>という名前で呼ばれるため、フックのmatcherにこの形式の正規表現を書けば、書き込み系のツール呼び出しだけを狙って止められます。公式ドキュメントが挙げる例は、任意のサーバーのwriteから始まるツールを一括で捕まえる書き方です。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "mcp__.*__write.*",
        "hooks": [
          {
            "type": "command",
            "command": "/home/user/scripts/validate-mcp-write.py"
          }
        ]
      }
    ]
  }
}

同じ仕組みで、create_datadog_monitorやcreate_incidentのような具体的なツール名をmatcherに指定し、フック側でpermissionDecisionをdenyにして返せば、その呼び出しだけを一律で拒否できます。公式ドキュメントは、データベースへの書き込みを一律拒否する例でpermissionDecisionReasonに理由を添える書き方を示しています。フックはツール名でしか判定できないため、「モニターの新規作成は拒否するが閾値の提案は許可する」のように、読み取りと書き込みが別ツール名に分かれている今回のようなケースと相性が良い仕組みです。

4つ目は接続先サービスのアカウント権限そのものです。Claudeは接続されたサービスから、そのアカウントが持つ権限をそのまま引き継ぎます。つまりClaude側の設定は、接続に使ったアカウントの権限を狭める方向にしか働きません。DatadogやPagerDutyに読み取り専用のロールを持つアカウントを用意し、そのアカウントでConnectorを接続すれば、Claude側の設定を待たずにこの制御点がそのまま効きます。同じ発想は自前で立てるMCPサーバーにも当てはまり、公式ドキュメントは自前のPostgreSQLに接続するDBHubサーバーの例で、接続文字列に読み取り専用のデータベースユーザーを使うよう明記しています。

4つの制御点は、どの面でも同じように使えるわけではない

この4つの制御点は、効く範囲が異なります。Connectorの権限カテゴリは、claude.aiの「カスタマイズ」からConnectorごとに設定するアカウント単位の設定です。組織レベルのアクション制限はTeam・Enterpriseプランでオーナーが設定するもので、個人の権限カテゴリより優先され、メンバー側では上書きできません。一方、PreToolUseフックはClaude Code固有の仕組みです。フックは元々Claude Codeの設定ファイルに書く仕組みで、この方法で書き込みを止められるのはClaude Codeから同じConnectorをMCPサーバーとして直接繋いだときだけです。

claude.aiのチャットやCoworkだけで運用する場合、個人が直接操作できる制御点はConnectorの権限カテゴリだけですが、TeamやEnterpriseであればそれに加えて組織レベルのアクション制限を重ねられます。逆にClaude Codeでこの3つのConnectorを使う場合は、権限カテゴリとフックを二重に設定できます。フック側でツール名を具体的に列挙しておけば、Connectorの設定を誰かが誤って緩めても、フックの層で書き込みを止め続けられます。

横断調査は読み取りだけで完結させる

3つのConnectorを繋いだ状態で、次のような指示は書き込みを一切経由せずに完結します。

「Sentryで直近30分に急増しているエラーを調べ、最初に発生した時刻を特定して。その時刻を起点に、該当サービスのDatadogログとトレースで何が変わったかを見て。すでにPagerDutyにこのサービスの未解決インシデントがあるかも確認して」

この指示に登場する操作は、SentryのIssue検索、Datadogのログ・トレース検索、PagerDutyのインシデント参照(get_incident)だけです。いずれも読み取り専用の権限カテゴリに設定していれば、承認を挟まずに実行が完了します。原因の当たりが付いた後、新しいモニターを作る・新しいインシデントを作る・対応者を追加するといった一手だけを、人の確認を挟む書き込みとして切り離せます。

通知とエスカレーションだけは承認を挟む

読み取りと書き込みを分けたら、書き込み側の運用はもう1段細かく分けられます。「担当チームに通知する」という行為は取り消しにくく、誤った相手に送ると混乱を招きます。一方で「未解決インシデントを一覧する」という読み取りは、無人で回しても実害がありません。

Cowork上でPagerDutyの監視を無人化しつつ、通知に相当する書き込みだけを人の承認で止める具体的な組み方は、PagerDuty×CoworkでSLA監視とエスカレーションを自動化するで扱っています。この記事の設計は、その承認境界を「PagerDuty単体」ではなく「Datadog・Sentry・PagerDutyの3つを跨いだ調査全体」に広げたときの考え方に相当します。

この設計は3ツールを常時繋ぐ運用に向くか

3つのConnectorを常時接続しておく価値があるのは、原因調査が複数サービスをまたぐ組織です。単一サービスの小規模な構成では、DatadogとPagerDutyを往復する手間自体が小さく、Connectorを跨いだ自動調査を組むコストのほうが上回ります。逆に、決済・認証・通知のように依存関係の深いサービス群を持つチームでは、この4段階の切り分けが調査時間を直接短縮します。

読み取りと書き込みの境界を先に決めておかないと、この構成は「便利だが何をしても許可を求めてくる」か「速いが何でも実行してしまう」のどちらかに寄ります。境界を明示したうえで運用を始めるのが、この設計の前提です。

まとめ

Datadog・Sentry・PagerDutyを1つのClaudeセッションに繋ぐと、ログ→トレース→アラート→オンコール通知という4段階のうち、最初の3段階は読み取りだけで完結し、最後のオンコール通知だけが書き込みに変わります。読み取り専用の方針は、Connectorの権限カテゴリ・組織レベルのアクション制限・PreToolUseフックのmcp__<サーバー>__<ツール>マッチャー・接続先サービスのアカウント権限という4つの制御点で重ねて効かせられます。PagerDuty側のエスカレーション自動化は専用の記事を参照してください。