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

DatadogのログとトレースとPagerDutyのオンコール通知を別々のタブで追う作業は、Claudeに3つの公式Connectorを繋げば1つの会話にまとめられます(個別の接続手順はClaudeでDatadogとSentryを連携するやDatadog MCP ServerをClaude Codeに接続する方法を参照してください)。

ただし3つを同時に繋ぐと、読み取り用に加えてモニター作成やインシデント作成などの書き込み用ツールも同時に使える状態になります。ここでは、接続が済んでいる前提で、ログ→トレース→アラート→オンコール通知という一次調査の流れをどう設計し、書き込み操作をどこで止めるかをまとめます。

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

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

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

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

Connectorの紹介ページに載っているツール名を、先頭の動詞で数えると次のとおりです。参照系のsearch_やget_で始まるツールは数えていません。

Datadogの書き込み系は、モニターに限りません。create_datadog_notebookのようなノートブック系があります。upsert_datadog_dashboardやdelete_datadog_dashboard、検知ルールを作るcreate_datadog_security_detection_rule、ワークフローを動かすexecute_datadog_workflowも並びます。PagerDutyではcreate_incidentとadd_respondersのほか、create_schedule_overrideやcreate_status_page_postがあります。manage_incidentsやdelete_teamも含まれます。

Sentryを足すと、参照系のfind_issuesやget_issue_detailsに加えて、書き込み側の候補も増えます。Seerによる分析のanalyze_issue_with_seer、Issueの状態を変えるupdate_issue、create_projectやcreate_dsnです(Seerの具体的な使い方はSentry MCPをOAuthでClaude Codeに接続する方法を参照してください)。ログを調べているだけのつもりでも、Claudeが選べる次の一手には「モニターを作る」「インシデントを作る」「Issueを更新する」が常に並んでいる状態です。

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

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

1つ目は、コネクタのTool permissions(ツール権限)です。TeamプランとEnterpriseプランの所有者がclaude.aiの「Customize」→「Connectors」でコネクタを選ぶと、ツールがタイプ別に分かれて表示されます。読み取り専用ツールと、書き込み・削除ツールです。タイプ単位でも個別のツール単位でも、「常に許可」「承認が必要」「ブロック」の3つから選べます。参照系を「常に許可」、create_datadog_monitorのような作成系を「承認が必要」にすれば、調査は止まらず作成だけが人の確認待ちになります。

この設定は組織全体にかかります。サポート記事は、所有者が設定した制限は全員に適用され、個別のユーザーは上書きできないと説明しています。個人アカウントが自分のコネクタに同じ設定をかけられるかどうかは、サポート記事に書かれていません。なお、Claudeのツールアクセス設定で選ぶ自動・オンデマンドなどのモードは、ツールの読み込み方を決めるもので、この権限とは別の設定です。

2つ目はClaude CodeのPreToolUseフックです。MCPツールはmcp__<サーバー名>__<ツール名>という名前で呼ばれます。フックのmatcherはこの名前に対する指定で、公式ドキュメントの例は、任意のサーバーのwriteで始まるツールを一括で捕まえるmcp__.*__write.*です。同じ命名規則はPrefect連携のMCPサーバーにも使え、この記事で扱っています。

ただしこの例のwriteは、DatadogにもPagerDutyにも効きません。ツール名の先頭がcreate_ update_ add_などだからです。この3つのConnectorには、動詞を並べたmatcherを書きます。start_incident_workflow(PagerDuty)やretry_datadog_ci_job(Datadog)も書き込み系なので、例にはstartとretryを加えています。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "mcp__.*__(create|update|edit|delete|upsert|append|add|remove|manage|execute|start|retry)_.*",
        "hooks": [
          {
            "type": "command",
            "command": "/home/user/scripts/block-monitoring-writes.py"
          }
        ]
      }
    ]
  }
}

フック側でpermissionDecisionをdenyにして返すと、その呼び出しを拒否できます。permissionDecisionReasonに理由を書くと、denyのときはClaudeにその理由が渡ります。上の動詞リストはConnectorのツール名から作った例で、ツールが増えれば漏れが出ます。許可する書き込みだけをcreate_incidentのように具体名で除外する運用も取れます。

3つ目は接続先サービスのアカウント権限です。サポート記事は、アクション制限はソースシステムの権限と並んで働き、Claudeで制限をかけても元のアクセスより多くが付与されることはない、と説明しています。つまりClaude側の設定は、接続に使ったアカウントの権限を狭める方向にしか働きません。DatadogやPagerDutyに読み取り専用のロールを持つアカウントを用意し、そのアカウントでConnectorを接続すれば、Claude側の設定とは別の層で書き込みが止まります。自前で立てるMCPサーバーでも同じで、公式ドキュメントは自前のPostgreSQLに接続するDBHubの例で、接続文字列に読み取り専用のデータベースユーザーを使うよう案内しています。

3つの制御点は、使う面によって効き方が違う

3つの制御点は、どの面からConnectorを使うかで効き方が変わります。

APIキーやサードパーティのプロバイダー(Amazon BedrockやGoogle Cloud)で認証している場合、Claude Codeはclaude.aiのコネクタを取りに行きません。その場合にDatadogやPagerDutyを使うなら、MCPサーバーとして自分で登録することになり、組織のツール制御ではなくPreToolUseフックとアカウント権限が主役になります。

個人アカウントのチャットでは、サポート記事にToolの権限設定の記述がなく、接続アカウントのロールが実質の防壁です。Coworkのツール単位の承認設定はPagerDuty×Coworkにあります。Claude Codeで使うなら、組織の制限とフックを二重にかけられます。フックでツール名を具体的に押さえておけば、コネクタ側の設定が誰かの操作で緩んでも、フックの層で書き込みが止まります。

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

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段階の切り分けが調査時間を直接短縮します。

常時接続にはもう1つ、会話の側のコストがあります。Datadogだけで182個、PagerDutyで64個とツール数が多く、会話の余白を圧迫します。そこでClaudeのツールアクセス設定(自動がデフォルト)でオンデマンドを選ぶ手もあります。サポート記事は、10個以上のコネクタがアクティブなときにオンデマンドへの切り替えを検討するよう案内しています。

まとめ

読み取り専用の方針は、コネクタのTool permissions、Claude CodeのPreToolUseフック、接続アカウントの権限の3層で重ねます。使う面で効く層が変わるので、自分の環境でどの層が実際に書き込みを止めているかを、承認が出る場面で一度確かめておくと安心です。