New Relic AI導入ガイド：機能・設定・運用チェック

New Relic AIの概要とユースケース

New Relic AI はログ・トレース・メトリクス等のテレメトリ文脈を使い、問い合わせ形式で解析支援を行う機能群です。NRQL（New Relic Query Language）生成、ログ要約、RCA支援、runbook作成、自動アラート連携などが主な用途です。

機能概要

ここでは代表的な機能を整理します。利用ケースに応じて組み合わせて運用します。

• チャット形式の解析アシスト（ログ要約・原因候補提示）
• NRQL自動生成・改善支援
• トレース／ログの相関探索支援
• Runbook／ダッシュボード提案
• アラートや外部通知（Slack/PagerDuty）との連携、自動化トリガー（承認フロー必須推奨）

提供形態と確認の注意

New Relic の機能は Preview／GA／Enterprise 向けなど提供形態が異なります。導入前に機能状態とライセンス条件を公式で確認してください。公式情報の確認は本文末の「公式ドキュメント・参考リンク」を参照してください（公式ドキュメントでの確認: 2026-05-12）。

導入前の要件と設計（権限・データ・MCP）

導入成功には事前準備が重要です。権限設計、エージェント稼働、データ品質、外部モデル連携方針（MCP 等）を明確にします。

権限と RBAC 設計

AI がアクセスするデータを最小化することが第一です。推奨するロール設計例を示します。

• AI_Admin（管理者）
• 機能: AI 有効化、データスコープ設定、API キー管理
• 備考: 限定少数に付与
• AI_Analyst（分析担当）
• 機能: ログ／トレース／メトリクスの閲覧、NRQL 実行
• 備考: 出力のエクスポート権限は厳格に管理
• AI_Automation（自動化実行）
• 機能: 承認済みの限定アクション（例: スケール調整、再起動）
• 備考: テスト環境の操作に限定し、ログを必須保存

API キーは最小権限で発行し、定期ローテーションと使用監査を実施してください。

対応データソースと品質チェックリスト

AI が有効な判断を行うには一貫したフィールド設計が必要です。最低限の項目例を示します。

• Logs（推奨: 構造化 JSON）
• 必須例: timestamp、service、severity、message、traceId（可能なら）
• Traces
• 必須例: traceId、spanId、service、duration、error フラグ
• Metrics
• 必須例: metric 名、タイムスタンプ、タグ（host/service/environment）、単位
• Dashboards/NRQL
• 保存済みクエリやウィジェットメタを活用

データ品質チェック項目（簡易）

• タイムスタンプは UTC で一貫しているか
• service/app 名の命名規約は統一済みか
• traceId がログとトレースで相互参照できるか
• 重要フィールドが不要にマスクされていないか

MCP の位置付けと公式確認

MCP（呼称として Model Context Protocol として扱われることがあります）が外部モデル連携の設計要素として紹介される例がありますが、用語や実装は変わり得ます。MCP に関する正式な定義・設定手順は New Relic の公式ドキュメントを参照し、社内ガバナンスと合わせて検討してください。

ステージングでの有効化と検証（GUIの例とチェックリスト）

本番化前にステージングで機能を検証します。GUI 操作は画面が更新されやすいため「例」として扱い、画面名やラベルが変わる可能性を考慮してください。

GUIでの有効化手順（例）

以下は UI 操作の一例です。画面名やメニューは変更される可能性があるため、手順は「例」として扱ってください。

1. one.newrelic.com に管理者でログインする。
2. アカウント設定または「All capabilities」相当の管理画面を開く。
3. Logs ビューや該当サービスのパネルから「AI」または「Assistant」相当の有効化オプションを探す。
4. アカウント／組織レベルで AI 機能を有効化する（管理者の操作）。
5. データアクセススコープを設定し、AI が参照可能なデータを限定する。
6. 外部モデル連携や MCP を構成する場合は、接続情報・認証方式・プロキシ設定を入力する。
7. PII マスキングや出力フィルタ、監査ログの設定を初期化する。

注: 上記は UI の「例」です。詳細は公式ドキュメントとスクリーン表示を参照してください。

ステージング検証チェックリスト（推奨）

ステージング環境での最低検証項目です。各項目は実際の手順に落とし込み、結果を記録してください。

• 権限確認: 開発者と SRE のロールで期待通りのアクセス制御が機能するか
• データアクセス: AI が参照するログ／トレース／メトリクス範囲を確認
• PII 排除: マスキングルールが適用され、出力に PII が含まれないことをサンプルで確認
• プロンプト試験: 代表的なプロンプトと NRQL テンプレを使って応答の妥当性を評価
• 効果測定: MTTD／MTTR のベースライン計測を開始して比較可能にする
• 監査: AI の問い合わせと応答をログ化し、監査トレイルが作成されるか確認

ハンズオン：トリアージ・NRQL実践・プロンプト

ここでは実務で使える手順、NRQL 改善例、再現性の高いプロンプトを示します。ログのサンプルを含め、実行時の注意点も解説します。

典型的なトリアージワークフロー（実践）

短期対応の流れを示します。実行時は必ず人間が検証してください。

1. 調査対象の時間窓を設定（例: 過去30分）。
2. Severity や HTTP ステータスで一次フィルタリングする。
3. FACET（service/host/responseCode 等）で影響範囲を切り分ける。
4. チャットを起動し、要約と上位原因候補を取得する。
5. 提案された NRQL を別タブで実行し、数値で裏取りする。
6. 関連トレースにジャンプし、traceId を用いて深掘りする。
7. 確認済みの対処は runbook 化し、必要なら Slack/PagerDuty 経由でエスカレーションする。

NRQL 改善例とサンプルデータ

データソース（Transaction イベント vs Log イベント）でフィールド名や集計方法が異なります。以下はサンプルログと NRQL の例です。

サンプルログ（構造化 JSON）

改善前（一般例）

改善後（Transaction イベント想定）

改善後（Log イベント想定、duration を durationMs とする例）

期待される出力（列イメージ）

• host | errors | p95
• web-01 | 12 | 842ms

実行上の注意

• データソースによりフィールド名が異なるため、事前にスキーマを確認してください。
• NRQL 実行にはクエリ権限が必要です。権限がないと結果が見えません。
• TIMESERIES を指定すると可視化向けの時系列が返ります。

プロンプトと再現性向上のテンプレ

プロンプトの再現性を高めるため、ログの最小フォーマットと traceId を含めて渡します。モデルの入力制限はモデル依存ですから、接続先の仕様を確認してください。

プロンプト例（トラブルシューティング要約）

• 「直近30分のエラーを日本語で3行で要約し、優先調査手順を3つ提示してください。原因候補と、それぞれで確認すべきログ／トレースの場所を示してください。」
  プロンプト例（NRQL 生成）

• 「以下のログ抜粋に基づき、直近1時間で HTTP 500 を host 別に集計し、count と p95 レスポンスタイムを返す NRQL を出してください。」

再現性向上の実務ガイド

• ログ抜粋は最大で直近 20〜50 行を目安にする（モデルのコンテキスト制限に注意）。
• traceId を必ず含める（例: trace-abc123）。
• モデルのコンテキストウィンドウは数千〜数万トークンの範囲が多いが、使用するモデルの仕様を確認すること。
• 出力に根拠となるログ行番号や traceId を併記させる。

自動化・外部LLM連携の設計とガードレール

外部モデルや自動化は便利ですが、誤動作リスクが高いため安全策が必須です。設計段階で失敗ケースを想定し、承認フローやロギングを組み込みます。

連携アーキテクチャと運用ポイント

外部 LLM を使う場合はコンテキストの最小化と認証・暗号化が重要です。実務的な留意点を示します。

• VPC／プライベートサブネット内での MCP 相当のゲートウェイ配置（外部モデルへの直接流出を防ぐ）
• TLS／相互認証を必須化、API キーのローテーション
• 送信前での PII 削除／疑似化（pseudonymization）
• 監査ログに問い合わせ元・渡したコンテキスト・応答のハッシュを記録

MCP の呼称や実装は変化し得ます。正式な定義と設定手順は公式ドキュメントを参照してください。

自動化・リメディエーションのリスクと失敗事例

自動化の誤動作はインシデントを拡大させる場合があります。代表的な失敗事例と防止策を挙げます。

失敗事例 1: 誤検知による DB 再起動でサービス停止を拡大

• 防止策: 本番では自動再起動を禁止し、まずはオートチケット＋人の承認を必須にする。

失敗事例 2: スケールダウン自動化がピークトラフィックを誤判定して性能劣化

• 防止策: Canary 実行、段階的なアクション、影響確認ウィンドウを挿入する。

失敗事例 3: モデル出力に PII が含まれて外部へ流出

• 防止策: 送信前のフィールドレベルマスキングと外部送信禁止ルールの適用。

承認ワークフローと安全策（サンプル）

自動化は以下のようなヒューマンインザループで安全性を担保します。

• ステップ 1: AI が推奨アクションを生成し、Slack 等に要約を投稿
• ステップ 2: 指定のオンコールが「承認」ボタンを押す（ログに記録）
• ステップ 3: 承認後に限定的な自動アクションを実行
• ステップ 4: 実行ログ・コマンド・結果を監査トレイルへ記録し、定期レビュー

承認情報は改ざん防止のため長期に保存してください。

運用・セキュリティ・コスト管理と比較

運用段階ではセキュリティ、効果測定、コスト管理が継続的に必要です。ここでは実務で使える指標や設定例、簡易比較を示します。

セキュリティ・PII マスキング・監査の実装例

具体的なマスキング例や監査ポリシーを示します。実装はパイプラインの段階で行うのが望ましいです。

PII マスキング（サンプル正規表現）

• Email: (?i)\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}\b → [EMAIL_REDACTED]
• クレジットカード（= 13〜16 桁）: \b(?:\d[ -]?){13,16}\b → [CC_REDACTED] または *****1234（後4桁のみ残す）
• 日本国内電話: \b(?:+?81[- ]?)?0\d{1,4}[- ]?\d{1,4}[- ]?\d{4}\b → [PHONE_REDACTED]
• IP（必要に応じて部分マスク）: \b(?:\d{1,3}.){3}\d{1,3}\b → [IP_REDACTED] または 10.0.0.x のように範囲化

監査ログと保持ポリシー（例）

• AI 問い合わせログ: 1 年〜3 年（規制や社内ルールに応じる）
• セキュリティ関連ログ: 3 年〜7 年（法規制に合わせる）
• アクセスログ: 365 日（必要に応じ延長）

必ず法務／コンプライアンス部門と連携し、GDPR・APPI 等の要件を満たす保持方針を策定してください。

効果測定とコスト管理（指標と方法）

効果測定は導入効果の可視化と改善に不可欠です。

主要指標

• MTTD（Mean Time To Detect）
• MTTR（Mean Time To Repair）
• インシデント頻度
• オペレーターの平均対応時間
• 誤検知率（False Positive Rate）

評価手法

• A/B テストやカナリア展開で段階的に導入する。
• AI 介入の有無をメタタグでログに残し、比較分析を行う。
• 高頻度の問い合わせは低コストモデルへ切替える、サンプリング実施、バッチ化でコスト抑制。

料金の概略（確認ポイント）

• プラットフォーム基本料金（機能階層）
• データ取込量や保持による従量課金
• AI 機能のアドオン料金や外部 LLM のトークン課金
• 自動化 API 呼び出しや外部通知の実行回数に基づく課金

必ず公式の料金ページで最新情報を確認してください（本文末参照）。

競合比較（高レベル・評価軸）

以下は評価軸に基づく高レベル比較です。実運用条件により評価は変わります。

出典は各社の公式ドキュメントを参照して比較検討してください。上表は高レベルの特徴整理に留めています。

まとめ

導入の優先アクションは次の通りです。まずはステージングで検証し、ガバナンスを確立してから本番展開してください。

• 権限設計と最小権限ポリシーを先に確定する。
• ログ／トレース／メトリクスのフィールド統一と traceId の相互参照性を担保する。
• ステージングで NRQL・プロンプト・自動化の動作を検証し、効果指標（MTTD/MTTR）を計測する。
• PII マスキングと監査ログの保存、承認ワークフローを導入する。
• 外部 LLM 連携は MCP 相当のゲートウェイでコンテキスト最小化・監査を実装する。

公式ドキュメント・参考リンク

以下は導入前に必ず確認すべき公式ページです。最新の提供形態や料金は随時更新されますので、導入前に公式ページで状態を確認してください（確認日: 2026-05-12）。

• New Relic ドキュメント（トップ）: https://docs.newrelic.com/
• New Relic 製品情報／プラットフォーム: https://newrelic.com/
• New Relic 料金ページ: https://newrelic.com/pricing
• New Relic ブログ（リリース情報等）: https://blog.newrelic.com/

競合ベンダーの公式ドキュメントも選定時に参照してください（Datadog／Dynatrace の公式サイト）。

（注）本文中の例や正規表現、保持期間はあくまで実務のサンプルです。詳細な法的要件や正式設定は法務・コンプライアンス部門と協議のうえ、公式ドキュメントに基づいて最終決定してください。