はじめに
普段はDatadog等の他ツールを利用しており、New Relicの運用時、「メンテナンス期間の通知抑制（ダウンタイム）をどう設定されてるか？」と疑問となり本記事を執筆しました。New Relicでは一般的に Muting Rules という機能を使用しますが、
「今回のメンテナンスで影響を受けるリソース（エンティティ）は具体的にどれか？」 が画面で設定しても不明確でした。
本記事では、New Relicで確認する際はAPIツールである NerdGraph を使い、AWSタグ名（tags.label.Name）などをキーにして対象エンティティを漏れなく特定・リスト化する手順の解説になります。
New Relicにおける「ダウンタイム相当（通知抑制）」の考え方
New Relicにおいて、Datadogの「Downtime（ダウンタイム）」に相当する機能が Muting Rules です。
よくある利用シーン：
- 定期メンテナンス： 深夜のバッチ処理やOSパッチ適用時
- DB切り替え・フェイルオーバー検証： 一時的にCPU負荷や接続エラーが急増する場合
- カオスエンジニアリング： 意図的に障害を起こす避難訓練時
設定ミスによる「止め忘れ（通知が来てしまう）」や「止めすぎ（必要なアラートまで消してしまう）」を防ぐためには、設定作業の前に実施しチームでレビューすることが推奨されます。
実践：NerdGraphで対象エンティティを特定する
New RelicのUI上でもフィルタリングは可能ですが、運用業務としては NerdGraph API Explorer を使用します。
特に、クラウド環境（AWS/GCP/Azure）と連携している場合、
インスタンスに付与されたタグは tags.label.<タグキー> という形式でNew Relicに取り込まれます。
今回は、AWSのNameタグ（tags.label.Name）を使って対象を検索してみましょう。
具体的な操作手順（NerdGraph API Explorer）
※UIのメニュー名や配置は執筆時点のものであり、環境により表記が異なる場合があります。
- New Relic にログインし、左メニューから Apps（または All Capabilities > Apps）を選択します。
- 一覧から NerdGraph API Explorer を探して選択します。
3.画面左上の API Key ドロップダウンで、適切なUser Keyを選択（または入力）します。
- 注意：APIキーは権限を持つ強力な認証情報です。画面共有やスクリーンショットの際はキーが映り込まないよう十分注意してください。
- 中央のクエリ入力欄に以下のGraphQLクエリを入力し、上部の再生ボタン（または右矢印ボタン）を押して実行します。
- 画面右側に実行結果（JSON）が表示されます。これをコピーして、後述の方法で整形します。
使用するクエリ
以下のクエリは、タグ名に特定の文字列（例: prod-db- など）を含むエンティティを検索し、名前・タイプ・全タグ情報を取得します。 LIKE 'AWS tag name' の部分は、実際の検索したい文字列（例: 'prod-api-%' や '%-kafka-%' など）に書き換えてください。
GraphQL を使用する JSON コード例：
{ actor { entitySearch(query: "tags.label.Name LIKE 'AWS tag name'") { results { entities { name entityType tags { key values } } } count } } }
検索結果を整形して“台帳化”する
NerdGraphの結果はJSON形式のため、そのままでは人間が目視チェックするには不向きです。
GeminiやChatGPTなどのLLM、あるいは jq コマンドを使って、以下のような表形式（CSV）に変換することをおすすめします。
整形後のイメージ（例）：
| Entity Name | Type | Nameタグの値 | 備考 |
|---|---|---|---|
| New Relicに登録されているホスト名など | INFRASTRUCTURE_HOST_ENTITY | EC2のNameタグの値 | 今回のメンテ対象 |
| arnの値 | GENERIC_INFRASTRUCTURE_ENTITY | NLBのターゲットグループのNameタグの値 | 今回のメンテ対象 |
このように一覧化することで、「本来止めるべきではないステージング環境が含まれていないか？」「Webサーバーだけでなく、裏側のWorkerサーバーも含まれているか？」を関係者とダブルチェックできます。
ダウンタイム設定時に確認すべきこと
対象リストができたら、実際に Muting Rules を設定します。
その際、以下のポイントを必ず確認しましょう。
- 対象範囲（Scope）： 先ほど特定したタグ条件で過不足がないか。
2.期間（Schedule）： 1回限り（One-time）か、毎週（Recurring）か。
3.タイムゾーン（Timezone）： ここが最大の落とし穴です。 New Relicのユーザー設定やブラウザ設定に依存せず、Muting Ruleの設定が「JST」になっているか、あるいは「UTC」で計算されているかを必ず確認してください。
4.再発防止/解除漏れ対策： メンテナンス終了後、設定が無効化されているか（あるいは自動終了しているか）を確認するフローを入れましょう。
4) Datadogとの比較表
DatadogとNew Relicはどちらも優れた可観測性プラットフォームですが、メンテナンス設定に関してはアプローチや用語が少し異なります。
優劣ではなく「設計思想の違い」があります。
| 比較項目 | Datadog (Downtime) | New Relic (Muting Rules) |
|---|---|---|
| 主な目的 | 特定期間のモニター（監視）のミュート | 特定期間のIncident通知（Notification）の抑制 |
| 対象の指定方法 | タグ、スコープ（例: host:xxx）、Monitor名 |
NRQLクエリ、タグ（例: tags.label.Name = 'xxx'） |
| 検索/API | DashboardやAPIで管理。タグ補完が強力。 | NerdGraph (GraphQL) で柔軟な検索・取得が可能。 |
| メンテナンス中の挙動 | 基本的にアラート状態自体を記録しない（設定による） | 違反（Violation）は記録されるが、通知だけ飛ばない（後で分析可能） |
| 繰り返しの設定 | GoogleカレンダーライクなUIで柔軟に設定可 | 日時指定、またはiCal形式（RRule）での記述が可能 |
ポイント：
New RelicのMuting Rulesは「裏でアラート検知自体は動いている（データは残る）」という点が特徴です。
これにより、「メンテナンス中に実は予期せぬ別の障害が起きていた」場合でも、後からログやデータを追跡しやすいというメリットがあります。
5) よくあるつまずきポイント
- APIキーの権限不足： NerdGraphを実行するには適切なUser TypeとPermissionが必要です。エラーが出る場合は管理者に相談しましょう。
- タグが見つからない： クラウドインテグレーションの設定によっては、タグの取り込みに時間がかかる、あるいはフィルタリングされている場合があります。
- LIKE検索のワイルドカード： クエリ内の
LIKE演算子では%をワイルドカードとして使います（SQLと同様）。意図通りにヒットしない場合は%の位置を見直してください。 - 結果が多すぎる： 対象が数千件ある場合、NerdGraphの結果がページング（
nextCursor）されることがあります。大規模環境の場合はスクリプトでの全件取得が必要になる場合があります。
6) まとめ
メンテナンス時の通知抑制を成功させる鍵は、設定ボタンを押す前の「対象エンティティの正確な特定」にあります。
- UIだけでなく、NerdGraph (API) を活用して対象を検索する
tags.label.Nameなど一意性の高いタグをキーにする- 検索結果をJSONから表形式に変換し、チームでレビュー（台帳化）する
このプロセスを挟むことで、オペレーションミスを減らし、チームとしての信頼性を高めることができます。
ぜひ次回のメンテナンス作業から取り入れてみてください。
7) 付録：JSON結果を表に整形するための“追加プロンプト”
NerdGraphで取得したJSONを、GeminiなどのAIチャットに貼り付けて表を作成してもらう際のプロンプト例です。
プロンプト例：
以下のJSONデータはNew Relicのエンティティ検索結果です。 これをMarkdownの表形式に変換してください。 条件： 1. カラムは「Entity Name」「Type」「Nameタグの値（tagsの中からkeyが'label.Name'のもの）」の3列にすること。 2. もしNameタグがない場合は「-」と表示すること。 3. JSONデータ： [ここにNerdGraphの結果JSONを貼り付け]
簡単30秒