ClaudeとNew Relicを連携してアラート調査を自動化する
New Relic公式のMCPサーバーをClaude Code / Claude Desktop / VS Codeに接続し、NRQLクエリ・アラート調査・デプロイ影響分析を自然言語で行う手順です。
ClaudeとNew Relicの連携で何ができるか
New Relicはmcp.newrelic.comへのリモート接続で使えるMCPサーバーを公式提供しています。Claude Code・Claude Desktop・VS Code・Windsurf・Kiro CLI・Gemini CLIから接続でき、ローカルにサーバーをインストールする必要はありません。接続すると、NRQLクエリの実行、アラートポリシーの調査、インシデントレスポンス、デプロイの影響分析までを自然言語の依頼で扱えるようになります。
本サーバーはプレビュー段階の機能として提供されています。FedRAMP準拠が義務付けられたアカウントでの利用は明示的に禁止されているため、規制業界のチームは利用可否を先に確認してください。
接続先とエンドポイント
New Relicはリージョンごとに異なるMCPエンドポイントを用意しています。
| リージョン | エンドポイント |
|---|---|
| US | エンドポイントhttps://mcp.newrelic.com/mcp/ |
| EU | エンドポイントhttps://mcp.eu.newrelic.com/mcp/ |
| JP | エンドポイントhttps://mcp.jp.newrelic.com/mcp/ |
いずれもHTTPトランスポートで、ローカルにプロセスを起動するstdio型ではなくリモートサーバーへの接続になります。手元でバイナリやDockerイメージを管理する必要がなく、New Relic側でサーバーが更新されればクライアント側は接続先URLを変えずに新機能を使えるのが利点です。反面、社内ネットワークに閉じた自前のオブザーバビリティ基盤(Prometheus等)を扱う場合とは異なり、認証情報が外部サービスへのリクエストとして毎回飛ぶことになるため、権限設計は接続前に済ませておく必要があります。
認証は2方式
OAuth(推奨): Claude Code(v2.1.186以降)・Claude Desktop・VS Code・Windsurf・Kiro CLIで利用できます。クライアント側でブラウザ認証を挟む方式で、APIキーをコード内やファイルに残さずに済みます。
ユーザーAPIキー: NRAK-で始まる形式のキーをヘッダーに直接渡す方式です。CI環境やヘッドレス実行など、ブラウザ認証を挟めない場面向けです。
Claude Codeへの接続設定
OAuth方式ではコマンド2行で接続と認証が完結します。
claude mcp add --transport http newrelic https://mcp.newrelic.com/mcp/
claude mcp login newrelic~/.claude.jsonに直接書く場合は次の形になります。
{
"mcpServers": {
"newrelic": {
"type": "http",
"url": "https://mcp.newrelic.com/mcp/"
}
}
}APIキー方式でCI等から接続する場合は、ヘッダーにキーを渡します。
claude mcp add --transport http newrelic https://mcp.newrelic.com/mcp/ \
--header "api-key: NRAK-YOUR-KEY-HERE"Claude Desktop / VS Codeへの接続設定
Claude Desktopはmcp-remoteをローカルプロキシとして使い、OAuthのブラウザフローをリモートMCPサーバーへ橋渡しします。
{
"mcpServers": {
"new-relic-mcp": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.newrelic.com/mcp/"]
}
}
}設定ファイルの場所はmacOSが~/Library/Application Support/Claude/claude_desktop_config.json、Windowsが%APPDATA%\Claude\claude_desktop_config.jsonです。
VS Codeは.vscode/mcp.jsonにHTTP接続を直接記述できます。
{
"servers": {
"new-relic-mcp": {
"url": "https://mcp.newrelic.com/mcp/",
"type": "http"
}
}
}使えるツールのカテゴリ
New Relic MCPサーバーは目的別にタグ分けされたツール群を提供します。代表的なものは次のとおりです。
| カテゴリ | 主なツール | できること |
|---|---|---|
| アラート・監視 | 主なツールlist_alert_policies / list_alert_conditions / search_incident | できることアラートポリシーと条件の一覧、開閉両方のインシデント検索 |
| インシデント対応 | 主なツールanalyze_deployment_impact / list_change_events / generate_alert_insights_report | できることデプロイのパフォーマンス影響分析、変更イベント履歴、アラート傾向レポート |
| エラー・パフォーマンス分析 | 主なツールlist_entity_error_groups / analyze_entity_logs / analyze_transactions | できることエラーインボックスの取得、ログの異常パターン特定、遅いトランザクションの分析 |
| データアクセス | 主なツールexecute_nrql_query / natural_language_to_nrql_query | できることNRQLの直接実行、自然言語からNRQLへの変換・実行 |
| エンティティ探索 | 主なツールget_entity / search_entity_with_tag / list_dashboards | できることGUIDやタグでのエンティティ検索、ダッシュボード一覧 |
| ユーザー影響分析 | 主なツールgenerate_user_impact_report / list_synthetic_monitors | できることエンドユーザー影響レポート、Synthetic監視の一覧 |
natural_language_to_nrql_queryは名前のとおり、日本語や英語の質問文をNRQLへ変換したうえで実行まで担うツールです。NRQL構文を覚えていなくても「先週のエラー率をサービス別に見せて」といった依頼がそのままクエリ実行に変わります。
OAuthとAPIキー、どちらを選ぶか
| 利用シーン | 推奨方式 | 理由 |
|---|---|---|
| 開発者が手元のClaude Code / Desktopで対話的に使う | 推奨方式OAuth | 理由ブラウザ認証だけで済み、キーの管理・失効対応が不要 |
| CIパイプラインでの自動チェック | 推奨方式APIキー | 理由ブラウザを開けないヘッドレス環境でも動く |
| 複数人のチームで共有環境から使う | 推奨方式APIキー(専用ロール発行) | 理由個人アカウントに紐づくOAuthより権限の切り分けがしやすい |
| VS Code拡張からの利用 | 推奨方式OAuth | 理由エディタ上での認証フローが完結し、キーをワークスペース設定に残さずに済む |
どちらの方式でも、接続後にモデルが呼び出せる操作の範囲は接続に使ったアカウント・キーのNew Relic権限に従います。方式の選択とロール設計は別問題として扱う必要があります。
パフォーマンス分析系ツールの中身
analyze_transactionsはトランザクションのレイテンシー分布を見て遅いものとエラー傾向をまとめて返すツールで、APMのトランザクショントレース画面を毎回開かなくても「今どのエンドポイントが遅いか」を掴めます。analyze_entity_logsはログのエラーパターンや異常値を横断的に拾うため、特定のサービスから出ているログの傾向を短時間で把握したいときに向きます。
エンティティ探索系のget_entityはGUID指定でもパターン検索でも動作し、search_entity_with_tagはタグのキー・バリューでの絞り込みに対応します。「本番環境のタグが付いたサービスを全部リストして」のような依頼から、list_dashboardsと組み合わせて既存ダッシュボードへの導線を確認する使い方もできます。
障害調査での具体的な流れ
デプロイ後にアラートが鳴ったときの一次調査を例に、実際にどのツールが呼ばれるかを追ってみます。
- アラートの発生状況を確認する: 「直近1時間で開いているインシデントを見せて」と聞くと
search_incidentが該当時間帯のアラートイベントを検索する - 直前のデプロイと突き合わせる: 「このサービスの直近のデプロイ一覧と、デプロイ後のパフォーマンス影響を教えて」で
list_change_eventsとanalyze_deployment_impactが連携し、変更イベントとレイテンシー・エラー率の変化を並べて提示する - エラーの中身を掘る: 「エラーインボックスの中身を見せて、パターンがあれば教えて」で
list_entity_error_groupsとanalyze_entity_logsがエラーグループと異常パターンを返す
いずれのステップもNRQLを手で書く必要はなく、ダッシュボードを開いてクリックしていく代わりに会話で調査を進められます。根本原因の判断と対処の実行までは自動化の範囲外で、調査結果を材料にチーム側で決める形になります。
よくあるつまずき
- OAuthがログインを求め続ける: OAuth接続はClaude Code v2.1.186以降が前提です。古いバージョンでは
claude mcp loginが機能しないため、APIキー方式に切り替えるかバージョンを更新してください - CI・ヘッドレス環境でOAuthが完結しない: OAuthはブラウザ認証を挟む方式のため、対話的なブラウザを開けない実行環境では使えません。この場合は
NRAK-形式のユーザーAPIキーをヘッダーで渡す方式を使います - Claude Desktopで接続が失敗する:
mcp-remoteはnpx経由で起動するため、Node.jsがインストールされていないと接続コマンド自体が失敗します - リージョンを取り違える: US・EU・JPでエンドポイントが分かれているため、データのあるリージョンと違うエンドポイントに接続すると期待したデータが見えません。アカウント作成時のリージョンをNew Relic側の管理画面で確認してから接続先を選ぶと迷いません
ユーザー影響とSyntheticモニタリング
generate_user_impact_reportは障害がエンドユーザーにどこまで影響したかをまとめるレポート生成ツールで、社内向けの障害報告書を書く際の下書きとして使えます。list_synthetic_monitorsは自動テストの監視対象を一覧化するツールで、「どのシナリオが失敗しているか」を確認してからsearch_incidentで該当時間帯のインシデントに戻る、という往復がしやすくなります。
generate_alert_insights_reportはアラート発生の傾向をまとめるレポートツールで、単発のインシデント調査だけでなく「先月どのポリシーが最も多く鳴ったか」のような振り返りにも使えます。定期的なアラートの棚卸しをダッシュボード操作なしで済ませたいチームに向いています。
前提条件と権限設計
接続にはAPIアクセスが有効なNew Relicアカウントが必要です。組織のダッシュボードやアラートポリシーを見るには、該当するNew Relic組織への所属と参照権限が前提になります。組織スコープのロール(「Organization Read Only」「Organization Manager」「Organization Product Admin」のいずれか)を割り当てたうえで接続することが推奨されています。読み取りだけで足りる調査用途なら「Organization Read Only」を選び、設定変更まで任せる場合に限って上位のロールを検討する、という順番で選ぶのが安全です。一部の認証方式ではNode.jsのインストールも前提になるため、事前にバージョンを確認しておくと接続時のつまずきを減らせます。
New Relic自身のドキュメントは「AIがユーザーに代わって操作を行う」ことを明記したうえで、適切なRBACと最小権限の原則を設定するよう注意喚起しています。読み取り専用の調査用途であれば、書き込み権限を持たないロールで運用するのが安全です。アラートポリシーの変更や設定操作まで任せる場合は、そのぶんロールの権限も広げる必要があるため、まず読み取り専用で始めて運用の様子を見ながら範囲を広げるのが現実的な進め方です。
まとめ
New RelicのMCPサーバーはリモート接続型で、Claude Code・Claude Desktop・VS Codeのいずれからも数行の設定で使い始められます。NRQLを書かずにアラート調査・デプロイ影響分析・エラーパターンの特定まで一通りをカバーする一方、プレビュー機能としての提供のためFedRAMP対象アカウントは利用対象外です。まずは読み取り専用ロールでOAuth接続を試し、実際のインシデント調査フローに組み込めるか確認するのが安全な始め方です。
同じ監視・運用系の連携ではPrometheusのMCPサーバーがメトリクス基盤への自然言語クエリを担い、デプロイパイプライン側の操作はAWS CLI MCPサーバーで扱えます。障害調査の起点をNew Relicのアラートに置きつつ、インフラ側の変更履歴や設定の確認は別のMCPサーバーに任せる、という役割分担が現実的な組み合わせ方です。