この記事は TVer Advent Calendar 2025 2日目、もしくは New Relic Advent Calendar 2025 6日目です。
TVer ではオブザーバビリティの基盤に New Relic を全面的に採用しています。そして最近 New Relic 公式の MCP Server が Public Preview として公開され、各種生成 AI からテレメトリーの探索や調査が簡単にできるようになりました。
今回は、その New Relic MCP Server を使って SRE の業務を生成 AI にやらせてみます。
なお、執筆時点 (2025年12月1日) では Preview 機能のため、今後変更される可能性がある点に注意してください。
また前提として、TVer では Claude Code がプロダクト開発に関わるメンバーへ提供されています。この記事では Claude Code (Opus 4.5) から New Relic MCP を利用していきます。
ドキュメントから機能をみてみる
New Relic MCP Server の全機能は以下のドキュメントを見てもらうのが一番わかり易いのですが、簡単にまとめておきます。
ツールはカテゴリのタグを持ち、ツールのタグは現在以下の6種類があります。
- エンティティとアカウント管理 (
discovery) - データアクセス (
data-access) - アラートとモニタリング (
alerting) - インシデント対応 (
incident-response) - パフォーマンス分析 (
performance-analytics) - 高度な分析 (
advanced-analysis)
一部のツールは複数のタグを持つため、複数のカテゴリに表示されます。
例えば analyze_deployment_impact は incident-response と advanced-analysis の 2 つのタグを持ちます。
エンティティとアカウント管理 (discovery)
ツール一覧
convert_time_period_to_epoch_ms, get_dashboard, get_entity, list_related_entities, list_available_new_relic_accounts, list_dashboards, list_entity_types, search_entity_with_tag
ざっくり用途
アカウントやエンティティ、ダッシュボードを特定・列挙するためのツール群です。
探索の出発点として、タグや調べたいエンティティを絞り込み、関連エンティティやダッシュボードをたどって AI に「どのサービス群の状態をまとめるか」を決めさせる基盤になります。
データアクセス (data-access)
ツール一覧
execute_nrql_query, natural_language_to_nrql_query
ざっくり用途
NRQL を直接実行したり、自然言語から NRQL を生成して実行するためのツール群です。
個人的に NRQL は癖があって難しいと感じているので、これはとてもありがたいです。
アラートとモニタリング (alerting)
ツール一覧
list_alert_conditions, search_incident, list_alert_policies, list_recent_issues, list_synthetic_monitors
ざっくり用途
アラートポリシー・条件・インシデント・未解決 Issue・Synthetic Monitoring といった、設定されている監視を一覧・取得するためのツール群です。
インシデント対応 (incident-response)
ツール一覧
analyze_deployment_impact, generate_alert_insights_report, generate_user_impact_report, get_entity_error_groups, list_change_events
ざっくり用途
インシデント発生時に「いつ・どんな変更があり」「どんなエラーグループや影響が出たか」を取得するためのツール群です。
デプロイタイミングとエラー発生やアラート状況を組み合わせて、原因候補と影響範囲を整理させるような使い方が想定されます。
パフォーマンス分析 (performance-analytics)
ツール一覧
analyze_entity_logs, analyze_golden_metrics, analyze_kafka_metrics, analyze_threads, analyze_transactions, list_garbage_collection_metrics, list_recent_logs
ざっくり用途
ゴールデンメトリクス／トランザクション／スレッド／GC／ログなど、いわゆるアプリケーションパフォーマンスに関わるデータを解析するツール群です。
「どこが遅い・怪しい・詰まっているか」などを AI に調査させるイメージでしょうか。
高度な分析 (advanced-analysis)
ツール一覧
analyze_deployment_impact, analyze_entity_logs, generate_alert_insights_report, generate_user_impact_report, natural_language_to_nrql_query
これらのツールは他のツールタグにも存在し、重複しています。
「より重たい分析処理をするツールの集合」といった位置づけでしょうか。
これらのツールを Claude Code がうまく使って New Relic からテレメトリーデータを取得し、システムの問題探索や原因調査といった業務を行っていく形となります。
では、早速セットアップからやっていきましょう。
セットアップ
ドキュメントに沿って Claude Code に MCP サーバーを追加していきます。
認証には OAuth と API キーがサポートされています。ここでは OAuth でセットアップしました。
ツールがアクセスできる範囲は、New Relic ユーザーの RBAC 設定に従って制御されます。
New Relic MCP 追加
claude mcp add newrelic --transport http https://mcp.newrelic.com/mcp/
Claude Code 起動
claude
MCP 認証。ブラウザで New Relic の OAuth が起動するのでログインする
/mcp auth newrelic
実際に使ってみる
実際に SRE 業務でよくやる2つのタスクを、New Relic MCP を使って Claude Code にやらせてみます。
- 最近のシステム状態の定点観測
- インシデント発生時のシステムの問題調査タスク
最近のシステム品質の定点観測
サービスを構成するバックエンドAPIの状態に異常や改善の傾向がないか確認するタスクです。普段は毎週ダッシュボードを眺めて、レイテンシやエラーレート、インフラメトリクスを確認していました。今回はそれを Claude Code でやってみます。
プロンプト
過去3日間のシステムの状態を把握したい。異常や改善傾向ないか確認してください。
* xxx-app New Relic アカウントにある xxx-api APM でエラーレートやレイテンシが劣化・または改善したトランザクションがないか確認してください
* xxx-api インフラリソース (ECS/Aurora MySQL/ALB/CloudFront/SQS) のメトリクスに異常や改善傾向がないか確認してください
* Synthetic Monitoring の Result からシステムの可用性とパフォーマンスに問題があったかどうか確認してください
プロンプトには対象の New Relic アカウント名や APM のエンティティ名などを指定しています。Claude は最初に New Relic MCP でエンティティを検索し、そのエンティティの各種データをクエリしにいくので、
- New Relic アカウントの設計
- APM やログコレクタをどう構成しているか
といったコンテキストをあらかじめ別で与えた上で、「何が異常か」のしきい値までは細かく指定せず、ざっくり「劣化・改善傾向がないか」を聞いている形です。
Claude + MCP がやっていたこと（概念的な流れ）
実際の MCP 呼び出しログを眺めると、だいたい次のような流れで調査していました。
- 見るべきエンティティを特定する（discovery）
-
get_entityで xxx-api の APM を特定 - 必要に応じて
list_related_entitiesで関連するインフラエンティティ（ECS / RDS / ALB など）をたどる
-
- ゴールデンメトリクスを俯瞰する（performance-analytics）
-
analyze_golden_metricsで、過去 3 日間のレスポンスタイム・スループット・エラーレートの統計値や傾向を取得 - 「前の 3 日間と比較してどうか」など、期間比較をした NRQL を内部的に投げているケースもありました
-
- トランザクション単位での変化を見る（performance-analytics + data-access）
-
analyze_transactionsで、トランザクションごとの平均レイテンシやエラー率のランキングを取得 - 必要に応じて
natural_language_to_nrql_query→execute_nrql_queryで、「過去 3 日とその前の 3 日の p95 レイテンシを比較する」といったクエリを生成・実行
-
- インフラメトリクスをざっと確認する（data-access）
- CloudFront / ALB / ECS / Aurora MySQL / SQS などのメトリクスを、
execute_nrql_query経由でまとめて取得 - 例えば「SQS の ApproximateNumberOfMessagesVisible が右肩上がりになっていないか」など、各リソースごとの “よく見るメトリクス” を一通りなめる
- CloudFront / ALB / ECS / Aurora MySQL / SQS などのメトリクスを、
- Synthetic Monitoring とアラートの状況を確認する（alerting / incident-response）
-
list_synthetic_monitorsで重要パスの Synthetic を取得し、その Result を NRQL で集計 -
list_recent_issuesで過去数日の New Relic Issue を一覧し、「特定の時間帯だけエラーが跳ねていないか」などを確認
-
最後に、これらの結果をもとに Claude がテキストレポートを組み立ててくれました。
出力結果
それっぽいレポートが生成されました。出てきたレポートに対してさらに Claude に深掘りさせられるのも良かったです。
一方で、テキストベースなので、品質を確認するために設計・運用しているダッシュボードと比べると、時系列変化の把握や可視性の面ではさすがに見劣りします。まだできなさそうですが、MCP が構築済みダッシュボードからデータを引いてインサイトを出せるようになると、かなり実戦投入しやすくなりそうだと感じました。
（このあとインフラメトリクス、Synthetic Monitoring、Alert Issue の状況など、あと4倍くらい長いレポートが続く）
チームの New Relic アラート設定は同じリポジトリの Terraform で管理されているため、得たインサイトや障害の対策検討、モニタリング実装までをシームレスに Claude でそのままシュッと行うことができるのも嬉しいポイントです。
インシデント発生時のシステムの問題調査タスク
ちょうど Staging 環境でアラートが発生したので、Claude Code に調査させます。今回 SQS ApproximateAgeOfOldestMessage が閾値を超え、worker の処理が遅延しているアラートがでていました。
プロンプト
インシデントが発生し、New Relic から以下のアラートが発報されました。
おそらく Worker 処理になんかあったのですが、原因を調べてください。
xxx-app New Relic アカウントにある xxx-worker の APM Transaction とログをまず調べてみて。
`xxx.fifo query result is > 60.0 for 3 minutes on '[Critical] SQS ApproximateAgeOfOldestMessage > 60'`
IncidentId は xxxxxxxxxxxxxxxxxxxxxx です。
Claude + MCP がやっていたこと（概念的な流れ）
Claude Code はざっくり次のような流れで調査していました。
- プロンプトから調査対象の APM や Issue を
get_entityやlist_recent_issuesで探索 -
analyze_golden_metricsやanalyze_transactionsでアプリケーションパフォーマンスを調査 -
list_entity_error_groupsやlist_recent_logsでアプリケーションログを調査し、Deadlock 関連のエラーログを発見 -
execute_nrql_queryでエラーパターンを集計・分析 -
execute_nrql_queryで SQS メトリクスを確認
Claude Code の MCP 呼び出しログはこちら
⏺ 調査を開始します。まず New Relic アカウントの情報を取得し、該当する APM エンティティを探します。
⎿ {
"data": {
"actor": {
… +97 lines (ctrl+o to expand)
⏺ newrelic - get_entity (MCP)(name_pattern: "xxx-worker", domains: ["APM"])
⎿ {
"result": "{\"success\": {\"entities\": [{\"name\": \"xxx-worker\", \"account_id\": ***, \"entity_guid\": \"***\", \"domain\": \"APM\", \"type\": \"APPLICATION\", \"golden_me
trics\": {\"metrics\": [{\"name\": \"responseTimeMs\", \"metric_name\": \"newrelic.goldenmetrics.apm.application.responseTimeMs\", \"definition\": {\"definition_from\": \"Metric\", \"select\": \"average(newrelic.goldenmetrics.apm.application.r
… +10 lines (ctrl+o to expand)
⏺ エンティティが見つかりました。account_id: ***、entity_guid: *** です。次に、最近のエラーやログ、ゴールデンメトリクスを調査します。
⏺ newrelic - convert_time_period_to_epoch_ms (MCP)(text_input: "from 1 hour ago until now")
⎿ {
"result": "{\"start_ms\": 1764541736992, \"end_ms\": 1764545336992}"
}
⏺ newrelic - list_recent_issues (MCP)(account_id: ***)
⎿ {
"data": {
"actor": {
… +791 lines (ctrl+o to expand)
⏺ APMエンティティのゴールデンメトリクス、エラー、ログを並列で取得します。
⏺ newrelic - analyze_golden_metrics (MCP)(entity_guid: "***", account_id: ***, start_time_ms: 1764541736992)
⎿ {
"result": "{\"metadata\": {\"entity_guid\": \"***\", \"time_window\": {\"start_time\": 1764541736992, \"end_time\": 1764545336992}}, \"status\": \"success\", \"links\": {\"text\": \"go to entity summa
ry\", \"url\": \"https://one.newrelic.com/redirect/entity/***?begin=1764541736992&end=1764545336992\"}, \"data\": [{\"name\": \"responseTimeMs\", \"nrql\": \"FROM Metric SELECT average(newrelic.goldenme
… +7 lines (ctrl+o to expand)
⏺ newrelic - list_entity_error_groups (MCP)(entity_guid: "***", start_time_ms: 1764541736992)
⎿ {
"result": "{\"total\": 0, \"categorized\": {}, \"prioritized\": []}"
}
⏺ newrelic - list_recent_logs (MCP)(account_id: ***, entity_guid: "***", number_of_logs: 50, history_period_minutes: 60)
⎿ {
"result": {
"data": {
… +45 lines (ctrl+o to expand)
⏺ newrelic - analyze_transactions (MCP)(entity_guid: "***", start_time_ms: 1764541736992, error_transaction_limit: 20)
⎿ {
"result": "{\"total\": 4782, \"analysis\": {\"total_transactions\": 4782, \"avg_duration\": 0.04704546539517239, \"p95_duration\": 0.0, \"error_rate\": 0.0, \"throughput\": 159.4, \"error_transactions\": []}}"
}
⏺ 重要な情報が見つかりました。エラーログから原因が判明しています。さらに詳細を確認するため、エラーログをもう少し取得します。
⏺ newrelic - execute_nrql_query (MCP)(account_id: ***, nrql_query: "FROM Log SELECT count(*) WHERE entity.name = 'xxx-worker' AND level = 'ERROR' SINCE 1 hour ago FACET message LIMIT 20")
⎿ {
"result": {
"data": {
… +16 lines (ctrl+o to expand)
⏺ newrelic - execute_nrql_query (MCP)(account_id: ***, nrql_query: "FROM Log SELECT * WHERE entity.name = 'xxx-worker' AND level = 'ERROR' SINCE 2 hours ago LIMIT 50")
⎿ {
"result": {
"data": {
… +45 lines (ctrl+o to expand)
⏺ newrelic - execute_nrql_query (MCP)(account_id: ***, nrql_query: "FROM Log SELECT count(*) WHERE entity.name = 'xxx-worker' AND level = 'ERROR' SINCE 24 hours ago TIMESERIES 10 minutes")
⎿ {
"result": {
"data": {
… +731 lines (ctrl+o to expand)
⏺ newrelic - execute_nrql_query (MCP)(account_id: ***, nrql_query: "FROM Log SELECT * WHERE entity.name = 'xxx-worker' AND message LIKE '%Error%' OR message LIKE '%error%' OR message LIKE '%fail%' SINCE 3 hours ago LIMIT 100")
⎿ {
"result": {
"data": {
… +45 lines (ctrl+o to expand)
⏺ SQS キューのメトリクスも確認します。
⏺ newrelic - execute_nrql_query (MCP)(account_id: ***, nrql_query: "FROM Log SELECT * WHERE entity.name = 'xxx-worker' AND level = 'ERROR' SINCE 6 hours ago LIMIT 100")
⎿ {
"result": {
"data": {
… +45 lines (ctrl+o to expand)
⏺ newrelic - execute_nrql_query (MCP)(account_id: ***, nrql_query: "FROM QueueSample SELECT max(provider.approximateAgeOfOldestMessage.Maximum) AS 'Age of Oldest Message' WHERE provider.queueName LIKE '%***%' SINCE 3 hours ago TIMESERIES
5 minutes")
⎿ {
"result": {
"data": {
… +191 lines (ctrl+o to expand)
⏺ さらにログを確認して詳細なエラーパターンを調べます。
⏺ newrelic - execute_nrql_query (MCP)(account_id: ***, nrql_query: "FROM Log SELECT detail, message, timestamp, hostname WHERE entity.name = 'xxx-worker' AND level = 'ERROR' SINCE 24 hours ago LIMIT 50")
⎿ {
"result": {
"data": {
… +172 lines (ctrl+o to expand)
⏺ newrelic - execute_nrql_query (MCP)(account_id: ***, nrql_query: "FROM Log SELECT count(*) WHERE entity.name = 'xxx-worker' AND level = 'ERROR' FACET detail SINCE 24 hours ago LIMIT 20")
⎿ {
"result": {
"data": {
… +151 lines (ctrl+o to expand)
⏺ 原因が判明しました。以下が調査結果です。
...
出力
---
調査結果まとめ
インシデント概要
xxx.fifo SQS キューの ApproximateAgeOfOldestMessage が60秒を超えてアラートが発生しました。
根本原因
2種類のエラーが発生しています:
1. MySQL Deadlock (主因)
Error 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
- 発生箇所: /go/src/****/task.go:41
- メッセージ: Failed poller task
- 過去24時間で 2件 発生
2. SQS DeleteMessage エラー (二次的な問題)
api error InvalidParameterValue: Value AQEB...
- メッセージ: Failed to delete message from SQS.
- 過去24時間で 約20件 発生
エラーの関連性
1. MySQL Deadlock が発生するとタスクが失敗
2. メッセージが削除されないため、キューに滞留 → ApproximateAgeOfOldestMessage が増加
3. SQS の Visibility Timeout が切れると、同じメッセージが再度処理対象になり、さらに Deadlock や DeleteMessage エラーが発生する悪循環
SQS DeleteMessage エラーの詳細
InvalidParameterValue エラーは、Receipt Handle が期限切れ になった場合に発生します。これは:
- メッセージ処理に時間がかかりすぎた
- Visibility Timeout を超えた後に削除しようとした
ゴールデンメトリクス
- Throughput: スパイク検出
- Response Time: 13.5ms で安定
- Error Rate: 0.02% で安定
結論
根本原因は MySQL の Deadlock です。*** タスクで同時に複数のトランザクションが同じレコードをロックしようとして Deadlock が発生しています。
これにより処理が遅延し、SQS の Visibility Timeout を超過、その結果 DeleteMessageも失敗してメッセージがキューに滞留しました。
推奨対応
1. 短期: Deadlock 発生時のリトライロジックを確認・改善
2. 中期: タスクのトランザクション設計を見直し（ロック範囲の最小化、トランザクション分離レベルの調整）
3. 長期: SQS Visibility Timeout の調整、および処理タイムアウトの設定見直し
対象の worker の APM Transaction とログを調査し、DB のデッドロックが発生していることを「原因」として特定してくれました。
しかし、実際の原因は違っていました。
本当のところは Deadlock とは関係なく、データの問題で長時間実行中の Transaction がいて、その処理に時間がかかった結果、SQS の可視性タイムアウトまで時間がかかってしまった、というだけでした。
「長時間かかっている Transaction を調べて」など、worker の挙動にもう少し踏み込んだデバッグ指示を追加でプロンプトに書けていれば、もっと正確な結論に近づけていたと思います。また、インシデントの情報として発生時間・収束時間も、より正確に与えるべきでした。
さらに、インフラのメトリクスやログとアプリケーションのトレースが十分に紐づいていなかったのも敗因の一つです。Trace ID や Request ID など何らかのキーで事象を紐づけておかないと、生成 AI が正しい事象の関係性を引けず、それらしい事象をそれっぽく結びつけて間違った結論になることも多いと感じました。
やはり、ログ・メトリクス・トレースの整備と相互の関連付けは重要ですね。
今後
New Relic の Public Preview 機能である MCP で、SRE でよくやっているタスクを Claude Code でやってみました。New Relic のデータを探索して、システムの問題検知や深い洞察など、信頼性向上に役立てそうです。
また、今回は出番がありませんでしたが、我々のシステムのテレメトリーは（主にコストの問題で）New Relic 以外にも S3 や CloudWatch Logs, BigQuery など様々な場所に点在しています。その点在しているデータをローカルの生成AIから同じ様に引くことができれば、調査のインターフェースが統合され体験はかなりよくなりそうです。今後はこの Claude Code x New Relic MCP を使った問題探索を、コードベースやエージェントと協働させ、SRE を加速できればと思っています。
明日の TVer アドベントカレンダーは、 @takanamito さんの「今年AIにやらせてみて捗った作業」です。お楽しみに！