Sentry／Datadog MCP｜インシデント要約とアラート操作の権限（要調査）

モダンなシステム運用において、SentryやDatadogから飛んでくる膨大なアラートのハンドリングは、エンジニアの認知負荷を限界まで高めています。この課題に対し、Anthropicが提唱したMCP（Model Context Protocol）は、LLM（大規模言語モデル）が監視ツールのデータに直接アクセスし、文脈を理解した上でインシデントの要約や操作を行うための標準規格として急速に普及し始めています。

本記事では、SentryおよびDatadogを対象に、MCPを活用したインシデント要約の仕組みと、アラート操作（Resolve/Mute等）の権限をAIにどのように安全に付与すべきか、実務的な観点から徹底解説します。

1. 監視・オブザーバビリティにおけるMCP（Model Context Protocol）の衝撃

1-1. なぜ今、SentryやDatadogにMCPが必要なのか

従来の監視ツールとAIの連携は、主にWebhookを介した「通知の転送」に留まっていました。しかし、これではAIが「なぜそのエラーが起きたのか」「過去に同様の事象があったか」を自ら深掘りすることができませんでした。MCP（Model Context Protocol）を採用することで、Claude DesktopやカスタムAIエージェントが、必要に応じてSentryのスタックトレースやDatadogのメトリクスを「自ら読み取りに行く」ことが可能になります。

1-2. 従来のWebhook連携とMCP連携の決定的な違い

Webhook連携が「Push型」であるのに対し、MCPは「Pull/Interactive型」です。これにより、AIはエンジニアと同じように、発生している事象の周辺情報を能動的に収集し、解決策を提示できます。例えば、Sentryで発生した ZeroDivisionError に対し、関連するプルリクエストの差分を読み取って原因を特定する、といった高度な推論が可能になります。

1-3. インシデント対応のライフサイクルにおけるAIの役割

インシデント対応には、検知・調査・修正・事後分析の4段階があります。MCPを活用することで、特に「調査（要約）」と「事後分析（レポート作成）」の時間を大幅に短縮できます。また、適切な権限設計を行えば、「軽微なアラートの自動ミュート」といった「修正・対応」のフェーズまでAIに委ねることが現実味を帯びてきます。

こうした自動化の波は、インフラ運用だけでなく、社内のバックオフィス業務のDXにも通ずるものがあります。例えば、Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイドで語られているような、「人間が介在しなくてもデータが繋がる状態」を、SREの領域でも実現するのがMCPの本質です。

2. Sentry MCP：エラー解析とアラート操作の自動化

2-1. Sentryにおけるインシデント要約の仕組み

Sentryは公式にMCP Serverを提供（または推奨）しており、これを利用することでLLMはIssueのリスト取得、詳細の閲覧、タグによるフィルタリングが可能になります。要約の精度を高めるためには、Sentry側で「Breadcrumbs（パンくずリスト）」や「Environment」が適切に設定されていることが前提となります。

2-2. MCP Serverを用いたSentryデータのコンテキスト抽出

Sentry MCP Serverを起動すると、LLMは get_issue や list_issues といったツールを使用できるようになります。ここで重要なのは、LLMが「直近1時間で発生頻度が急上昇しているIssue」を特定し、そのスタックトレースからコードの不備を指摘できる点です。

2-3. アラート操作権限（Mute / Resolve）の安全な管理方法

SentryのAPIキーには「Read-only」と「Admin/Write」のスコープがあります。AIにアラートの解決（Resolve）や無視（Ignore）を許可する場合、project:write 権限が必要になります。これを安全に運用するためには、特定のアラートグループに限定した権限付与や、Sentry内の「Integration」設定での制限が不可欠です。公式ドキュメント（Sentry Authentication）によれば、内部統合（Internal Integration）用のトークンを発行し、必要なスコープのみにチェックを入れるのが実務上の定石です。

3. Datadog MCP：メトリクス相関分析とAIエージェント

3-1. Datadog Bits AIとMCPの補完関係

Datadogには標準で「Bits AI」というアシスタントが搭載されています。これに加え、MCP Serverを介して外部のLLM（Claude 3.5 Sonnet等）を接続することで、Datadogのダッシュボード情報を読み取らせることができます。Bits AIはDatadog内部の操作に長けていますが、MCP経由の外部LLMは「GitHubのコードやSlackのやり取りと組み合わせた総合判断」において強みを発揮します。

3-2. モニター（Alert）の状態変更をAIに許可する際の設定

DatadogのモニターをAIに操作させる場合、APIキーとAPPキーの両方が必要になります。権限管理（RBAC）においては、AI専用の「Service Account」を作成し、特定のタグが付与されたモニターのみを編集できるロールを割り当てることが推奨されます。特に monitors_write 権限をAIに与える際は、誤って本番環境の全監視をオフにされないよう、スコープの限定を徹底してください。

3-3. カスタムMCPによるランブック（復旧手順書）の自動実行

高度な実務では、DatadogのMCPと自社のデプロイパイプライン（AWS SDK等）を組み合わせた「カスタムMCP Server」を構築します。これにより、メトリクスが閾値を超えた際にAIが「自動でインスタンスを再起動する」「特定の機能をフラグでオフにする」といったアクションを、エンジニアの承認フロー（Human-in-the-loop）付きで実行可能になります。

このような高度なSaaS連携は、企業のITコスト最適化にも直結します。SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方でも触れられている通り、ツールの権限とコストを適正化することは、技術債務を増やさないための基本戦略です。

4. 【実務比較】Sentry vs Datadog：AI/MCP機能と権限モデル

両者のAI連携における特性を以下の表にまとめました。導入の際の判断基準として活用してください。

※料金の詳細は、必ず Sentry Pricing および Datadog Pricing をご確認ください。

5. インシデント要約と操作を安全に実装するステップバイステップ

5-1. APIキーの作成と最小権限（Least Privilege）の設定

まず、AI専用の認証情報を作成します。Sentryの場合は「Developer Settings」から、Datadogの場合は「Organization Settings > API Keys/Application Keys」から行います。絶対に自分の個人用管理者トークンをAIに渡さないでください。

• Sentry: event:read, issue:read (要約のみの場合)
• Datadog: monitors_read, logs_read

5-2. MCP Serverのデプロイと環境変数の秘匿化

MCP ServerをDockerやAWS Lambdaなどで稼働させる際は、APIキーを .env ファイルに直接書くのではなく、AWS Secrets ManagerやGitHub Secretsなどの秘匿情報管理ツールを使用してください。MCP Server自体が脆弱性を持つと、監視データが外部へ漏洩するリスクがあります。

5-3. 動作確認：AIによる要約とフィードバックループの構築

最初に「過去のインシデント」を読み取らせ、人間が作成した事後分析レポート（Post-mortem）と比較してください。AIが適切なコンテキストを拾えているか確認した上で、アラートのミュートなどの「書き込み権限」を段階的に解放していきます。

6. セキュリティとガバナンス：AIに「操作」を許す際の防壁

6-1. Human-in-the-loop：最終判断を人間に委ねる設計

AIが「このアラートは誤検知なので無視して良いですか？」と聞き、人間がSlack上で「Yes」と答えて初めてAPIが叩かれる仕組みを推奨します。完全自動化は、誤検知によるドミノ倒し（カスケード障害）を招く恐れがあるためです。

6-2. ログマスキングとPII（個人情報）の保護

SentryやDatadogに送られるログに、ユーザーのメールアドレスやクレジットカード番号が含まれている場合があります。AIに要約させる前に、Sentryの「Data Scrubbing」機能やDatadogの「Sensitive Data Scanner」を有効にし、AIモデルに機密情報が渡らないように設定してください。

6-3. 監査ログ（Audit Logs）によるAI操作の追跡

AIが行ったすべての操作は、誰が（どのAPIトークンが）いつ実行したかを監査ログで追跡可能にしておく必要があります。これは、退職者のアカウント管理と同様に重要なガバナンスの一環です。SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャで紹介されているようなID管理の思想を、AIエージェントの権限管理にも適用することが求められます。

7. まとめ：オブザーバビリティの未来と実務者のロードマップ

SentryやDatadogとMCPの連携は、単なる「便利な要約ツール」の導入ではありません。それは、オブザーバビリティ（可観測性）のデータを「人間が読むためのもの」から「AIと共にシステムを自律運用するための資産」へと昇華させるプロセスです。

まずは読み取り専用権限での「インシデント要約」から始め、徐々にAIの推論結果を運用フローに組み込んでいくのが、最も安全で効果的なロードマップです。権限設計に細心の注意を払いながら、AI時代の新しいSREプラクティスを構築していきましょう。