---
title: "New Relicとは｜APM・インフラ監視の構成とデータ量課金の設計を実装目線で解説"
url: "https://www.issoh.co.jp/tech/details/17247/"
published: 2026-09-03
updated: 2026-09-27
categories: ["監視・オブザーバビリティ"]
publisher: "株式会社一創"
---

# New Relicとは｜APM・インフラ監視の構成とデータ量課金の設計を実装目線で解説

New Relicは、アプリケーションの性能監視（APM）とインフラ監視、ログ、ブラウザ計測、外形監視を1つのデータストアに集約して扱うオブザーバビリティ基盤です。パッケージ名やコマンドの中では `newrelic` と1語で表記されるため、検索でも「newrelic」と「New Relic」が混在します。導入検討でつまずくのは機能の多さではなく、料金がデータ取り込み量とユーザー種別の2軸で決まる点、データ保持期間の既定値がAPMで8日しかない点、そして日本リージョンがまだプレビュー扱いである点の3つです。この記事では2026年9月時点の公式料金ページと公式ドキュメントの実測値をもとに、構成要素と計装経路、実機で疎通を確かめる作業手順、費用が膨らむ条件、リージョン選択の順序、採用を見送る場面までを整理します。

## まとめ：導入前に確定させるリージョン・ユーザー種別・取り込み量

結論から示します。New Relicの設計で先に決めるべき順序は、リージョン、ユーザー種別、取り込み量の3つです。リージョンは組織作成後に移行できないため後戻りが効かず、ユーザー種別はAPM画面を誰が見られるかを直接左右し、取り込み量は月額の変動幅そのものです。機能の比較はこの3点を固めた後で足ります。

とくに誤解されやすいのは無料枠の解釈です。データ取り込みは月100GBまで無料、ベーシックユーザーは人数無制限。ここまでは[New Relicの日本語料金ページ](https://newrelic.com/jp/pricing)の記載どおりですが、ベーシックユーザーはAPMもインフラ監視も分散トレースも開けません。「無料枠だけでAPMを全員に配れる」という前提で見積もると、実装フェーズで必ず崩れます。

| 決める順序      | 確定事項               | 後戻りの可否    |
| ---------- | ------------------ | --------- |
| 1\. リージョン  | US / EU / JP のいずれか | 移行は非対応    |
| 2\. ユーザー種別 | APMを見る人数と課金        | 変更可・費用は増減 |
| 3\. 取り込み量  | 100GB超過分の単価        | 削減施策で調整可  |

## New Relicがテレメトリを単一データベースへ集約する構成と計装経路

New Relicの構造上の特徴は、監視対象ごとに別製品を並べず、すべてのテレメトリを同一のデータストアへ入れて同じクエリ言語で引く点です。APMそのものの仕組みは[APM（アプリケーション性能監視）の仕組みと3種の監視データ](https://www.issoh.co.jp/tech/details/15414/)で整理しているため、ここではNew Relic固有の構成要素に絞ります。

### NRDBへの集約とNRQLでの横断クエリを前提にした構成の理解

収集したイベント・メトリクス・ログ・トレースは、NRDBと呼ばれる単一のデータストアに格納されます。参照にはSQLに似た独自のクエリ言語NRQLを使い、[NRQLの公式入門ドキュメント](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)が示すとおり `FROM Transaction SELECT average(duration) FACET appName` のようにイベント型を指定して集計します。

この構造の実務上の効き方は、障害調査でツールを渡り歩かずに済むところに出ます。アプリの遅延（Transaction）と同時刻のホスト負荷（SystemSample）を1本のクエリで並べられるため、切り分けの往復が減ります。反面、NRQLを書けるメンバーがいないとダッシュボードが標準画面のままになり、集約の利点をほとんど回収できません。導入時の学習コストはNRQLに集中します。

### APMエージェントが対応する7言語と自動計装で取得できる指標の範囲

APMエージェントが提供されている言語は、公式ドキュメントの記載でGo、Java、.NET、Node.js、PHP、Python、Rubyの7つです。多くの言語ではアプリケーションへエージェントを組み込むだけで、トランザクションの応答時間、スループット、エラー率、データベースクエリ、外部サービス呼び出しが自動で取れます。

ただしGoは他言語と扱いが異なり、バイトコード書き換えに相当する仕組みがないため、ハンドラやミドルウェアへの明示的な計装コードが必要になります。[go-agentのGitHubリポジトリ](https://github.com/newrelic/go-agent)を見ると、対応フレームワークごとに個別のインテグレーションパッケージが並んでいることがわかります。Go中心の構成では「エージェントを入れれば終わり」という工数見積りが外れる前提で工数を置いてください。RustやElixirのようにエージェントが用意されていない言語は、後述のOTLP経由で送る前提に切り替えてください。

### インフラ・ログ・ブラウザ・外形監視を同一アカウントで束ねる構成

APM以外の計測は、それぞれ別の入り口から同じアカウントへ流し込みます。ホストのCPU・メモリ・ディスクは[インフラストラクチャエージェント](https://docs.newrelic.com/docs/infrastructure/infrastructure-monitoring/get-started/get-started-infrastructure-monitoring/)、コンテナ環境はKubernetesインテグレーション、ログはログフォワーダー、ブラウザ側の実ユーザー計測はブラウザエージェント、外部からの死活・応答確認は外形監視という分担です。

クイックスタートとして700以上のインテグレーションが用意されており、AWSやMySQL、nginxなど主要ミドルウェアはダッシュボードとアラート条件が同梱された形で導入できます。無料枠にはpingモニターの無制限枠と外形監視500回分が含まれるため、まず外形監視だけを入れて疎通と体感を確かめる進め方が取れます。

### OTLPエンドポイント経由でOpenTelemetry計装を送る実装の要件

ベンダー固有エージェントを避けたい場合、OpenTelemetryで計装したままOTLPで送信できます。規格側の前提は[OpenTelemetry（OTel）の3つのシグナルとOTLP・Collectorの役割](https://www.issoh.co.jp/tech/details/3625/)を先に押さえておくと設定項目の意味が読み解けます。

[OTLPエンドポイントの公式ドキュメント](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-otlp/)では、2026年9月時点で送信先はUSが `otlp.nr-data.net`、EUが `otlp.eu01.nr-data.net`、JPが `otlp.jp.nr-data.net`、米国連邦向けが `gov-otlp.nr-data.net` と示されています。ポートは443・4317・4318に対応し、gRPCは4317、HTTPは4318で、HTTPではバイナリProtobufが推奨されています。認証はライセンスキーを `api-key` ヘッダーに載せる方式です。

実装で引っかかるのは上限値のほうです。ペイロードは1リクエストあたり1MB（10の6乗バイト）を超えると拒否されます。圧縮はgzipとzstdに対応し、同ドキュメントではzstdが推奨されています。TLSは1.2以上が必須です。属性側の上限も明記されており、文字列値は4,095文字、キーは255文字、配列は64要素、バイト配列は128,000、リソース属性は64個、スコープ属性は8個、レコード属性は128個までです。ログに巨大なJSONを丸ごと積む設計は、この4,095文字で切られます。

## Goエージェント導入からNRQL疎通までを実機で確かめる作業手順

ここまでの構成理解を、動くコードに落とします。以下は検証用アカウントを1つ作り、ライセンスキーを環境変数へ置いた状態から始める前提です。手を動かす順番は、エージェント1本で疎通を取る、OTLPへ切り替えて上限値を確かめる、NRQLで実データを引く、の3段です。

### Goエージェントをgo getで導入しNewApplicationを組む

Goの導入は[Go agentのインストール手順](https://docs.newrelic.com/docs/apm/agents/go-agent/installation/install-new-relic-go/)にあるとおり、モジュールを取得してアプリケーションを1つ作るところから始まります。公式ドキュメントの要件はGo 1.19以上で、モジュールパスはv3系です。ライセンスキーはソースへ書かず環境変数から読みます。

```
$ go get github.com/newrelic/go-agent/v3/newrelic

app, err := newrelic.NewApplication(
    newrelic.ConfigAppName("my-api"),
    newrelic.ConfigLicense(os.Getenv("NEW_RELIC_LICENSE_KEY")),
    newrelic.ConfigFromEnvironment(),
)
if err != nil {
    log.Fatal(err)
}
if err := app.WaitForConnection(5 * time.Second); err != nil {
    log.Println("new relic did not connect:", err)
}
defer app.Shutdown(10 * time.Second)

http.HandleFunc(newrelic.WrapHandleFunc(app, "/healthz", healthz))
```

`WaitForConnection` を入れておくと、キーやリージョンの設定違いが起動時点で切り分けられます。ここを省くとデータが上がらない原因がキー誤りかネットワークか計装漏れか判別できず、調査が長引きます。`WrapHandleFunc` のようにハンドラを包む記述がGoで必要な明示的計装で、包み忘れたエンドポイントはトランザクションとして計上されません。

### OpenTelemetry計装をOTLPで送る環境変数と上限値の設定

エージェントを外してOTelへ寄せる場合、送信先とヘッダー、上限値を環境変数で与えます。JPリージョンへHTTP（4318）で送る例が次の形です。既定の圧縮はgzipで、公式ドキュメントの推奨に合わせるならzstdへ切り替えます。

```
export OTEL_EXPORTER_OTLP_ENDPOINT="https://otlp.jp.nr-data.net:4318"
export OTEL_EXPORTER_OTLP_HEADERS="api-key=${NEW_RELIC_LICENSE_KEY}"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_COMPRESSION="gzip"
export OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT="4095"
export OTEL_EXPORTER_OTLP_TIMEOUT="10000"
export OTEL_SERVICE_NAME="my-api"
```

疎通しない場合に疑う順序は決まっています。まずエンドポイントのリージョン、次に `api-key` ヘッダー名の綴り、最後にペイロード1MBの上限です。バッチサイズを大きく取る構成では、圧縮後ではなく圧縮前のサイズで上限に当たる挙動を前提に、エクスポーターのバッチ上限を下げて確かめてください。TLS 1.2未満の環境からは接続そのものが張れません。

### NRQLでアプリの遅延とホスト側の負荷を1本のクエリで並べて引く

データが上がったら、標準画面ではなくNRQLで引いて確かめます。集約の利点が出るのは、アプリ側のイベント型とインフラ側のイベント型を同じ時間軸に並べたときです。次の2本を同じダッシュボードへ置くと、遅延の山がアプリ内部かホスト資源かを1画面で切り分けられます。

```
SELECT average(duration) AS 'latency_sec', count(*) AS 'throughput'
FROM Transaction
WHERE appName = 'my-api'
SINCE 6 hours ago TIMESERIES

SELECT average(cpuPercent), average(memoryUsedPercent)
FROM SystemSample
WHERE hostname = 'web-01'
SINCE 6 hours ago TIMESERIES
```

ここで `SINCE 6 hours ago` を `SINCE 30 days ago` に変えると、APMイベントは既定8日で切れているため後半が空になります。保持期間の実物をこの時点で目視しておくと、後述の振り返り設計の判断が早いです。検証段階でこの空白を確認しておけば、ダッシュボードを作り込んだ後の手戻りを避けられます。

## データ量課金とユーザー課金という2軸の料金構造と費用が膨らむ条件

New Relicの月額は、取り込んだデータ量と、フルプラットフォーム相当の権限を持つ人数の掛け合わせで決まります。片方だけを見た見積りは必ず外れるため、2軸で並べて計算します。

### 無料枠100GBと超過分の1GB単価、Data Plusとの差額の見積り

無料枠は月100GBの取り込みと、フルプラットフォームユーザー1名分です。超過分の単価は日本語の料金ページでOriginal data optionが1GBあたり0.30ドル、Data Plusが0.50ドル。Data PlusにEUデータセンターを追加する場合はさらに1GBあたり0.05ドルが加算されます。

ここで注意したいのは、[英語版の料金ページ](https://newrelic.com/pricing)では2026年9月時点で超過分がOriginal data optionで1GBあたり0.40ドル、Data Plusで0.60ドルと示されている点です。日本語ページの0.30ドル・0.50ドルとは1GBあたり0.10ドルの差があり、月1TBを取り込む規模では月100ドル前後の開きになります。単価はプランと契約形態、参照したページで変わるため、「1GBいくら」を調べる前に、どのプランのどのページを根拠にした見積りなのかを確定させる必要があります。見積書と公式ページの数字が合わない相談は、ここが原因のことが多いです。

| 課金項目                 | 無料枠     | 日本語ページの単価    | 英語ページの単価  |
| -------------------- | ------- | ------------ | --------- |
| Original data option | 100GB／月 | 0.30ドル／GB    | 0.40ドル／GB |
| Data Plus            | 100GB／月 | 0.50ドル／GB    | 0.60ドル／GB |
| Data Plus（EU DC追加）   | 同上      | 上記＋0.05ドル／GB | 記載なし      |

いずれの数字も2026年9月時点の表示です。単価は改定されるため、見積り時点で両方のページを開いて突き合わせる運用にしておくと差分に気づけます。

### Basic・Core・Full Platformの機能差とAPM閲覧者数の設計

ユーザー種別は3つあり、開ける画面が明確に分かれています。[ユーザー種別の公式ドキュメント](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-type/)の記載では、ベーシックユーザーは無料かつ人数無制限ですが、APM、ブラウザモニタリング、分散トレース、インフラストラクチャモニタリング、モバイルモニタリング、Kubernetesモニタリング、外形監視のいずれも対象外です。使えるのはカスタムチャートとダッシュボード、アラート通知の受信、ログの検索と閲覧、カスタムイベント、NerdGraph（GraphQL API）などに限られ、クイックスタート由来のダッシュボードは最大7日間の参照となります。

コアユーザーはベーシックの範囲にCodeStream、Errors inbox、ログUIが加わり、月額49ドル。フルプラットフォームユーザーで全機能が開き、Proが年間契約で月額349ドル（毎月従量なら418.80ドル）、Enterpriseが年間契約で月額549ドル（毎月従量なら658.80ドル）です。英語版ページではEnterpriseが個別見積り扱いに変わっているため、正式な金額は日本法人へ確認する前提で置いてください。

設計としては、APM画面を実際に触る人数をできるだけ絞り、残りのメンバーはダッシュボードとアラート受信で足りる構成に寄せるのが現実的です。10人全員をフルプラットフォームにすると年間契約でも月額3,490ドル。ダッシュボードで足りる7人をベーシックへ回すだけで月額1,047ドルまで落ちます。

### Compute（CCU）課金とData＋Userモデルの選び分けの判断軸

ユーザー数課金とは別に、消費量ベースのComputeモデルも用意されています。Core Computeはユーザー数無制限のまま、クエリ実行・アラート条件の評価・API呼び出し・画面表示といった操作の成功分をCore CCU（Compute Capacity Unit）として計上する方式です。Transaction 360、Security RX、Cloud Cost Intelligence、New Relic AIといった機能群はAdvanced Computeのアドオンに入り、こちらはaCCUで計測されます。

選び分けの軸は人数と操作量のどちらが伸びるかです。閲覧者が多く1人あたりの操作は軽い組織はComputeが有利になり、少人数が終日ダッシュボードを開いてクエリを回す運用ではユーザー数課金のほうが読みやすくなります。Computeを選ぶ場合はCompute Budgets（一般提供済み）でCCU使用量にアラートを張り、上振れを検知できる状態にしてから本番へ載せてください。

### 取り込み量を抑えるPipeline Controlとサンプリングの手立て

データ量課金である以上、取り込み側の絞り込みが費用管理の本体になります。ここは2026年に仕組みが入れ替わった箇所なので、古い記事の手順をそのまま踏むと動きません。長く案内されてきた[NerdGraphのNRQLドロップルール](https://docs.newrelic.com/docs/data-apis/manage-data/drop-data-using-nerdgraph/)（`nrqlDropRulesCreate`）は、[公式のEOL告知](https://docs.newrelic.com/eol/2025/05/drop-rule-filter/)で2026年8月31日16:00 UTCをもって提供終了と示されました。後継は[Pipeline Control](https://docs.newrelic.com/docs/new-relic-control/pipeline-control/overview/)で、APIとしては[Pipeline cloud rules API](https://docs.newrelic.com/docs/new-relic-control/pipeline-control/cloud-rules-api/)が同等の機能を担います。

新APIのミューテーションは `entityManagementCreatePipelineCloudRule` で、条件は `DELETE FROM` 形式のNRQLで書きます。デバッグログを課金対象から外す最小例が次の形です。

```
mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      name: "drop debug logs"
      description: "cost control, ticket DM-1234"
      nrql: "DELETE FROM Log WHERE level = 'DEBUG'"
      scope: { id: "YOUR_ACCOUNT_ID", type: ACCOUNT }
    }
  ) {
    entity { id name nrql }
  }
}
```

`enabled` は省略時 `true` で、ルール作成時にのみ指定できます。条件の書き間違いは課金対象データを丸ごと落とすため、まず `SELECT` 形式で同じ `WHERE` 句を実行し、消える件数を数えてから `DELETE FROM` へ置き換える手順を踏んでください。ドロップしたデータは後から取り戻せません。

ルールを自インフラ側で持ちたい場合は、Pipeline Control gatewayをOpenTelemetryベースの前段プロセスとして立てる選択もあります。[公式のサイジング資料](https://docs.newrelic.com/docs/new-relic-control/pipeline-control/sizing-and-scaling/)では、CPU 1コアとMELT種別ごとに100ルールという条件で、メトリクスが毎秒7,000データポイント、イベントが毎秒4,500件、ログが毎秒2,700件、トレースが毎秒3,300スパンという処理量が示されています。1ポッドで受けられるエージェント数は15〜35台、リクエストサイズは毎秒26〜250KBの非圧縮データが目安のため、自社の取り込み量からポッド数とコア数を逆算してください。

API以外の削減手立ては従来どおりです。トランザクションイベントと分散トレースのサンプリングレート調整、インフラ側のネットワーク・ストレージ・システムイベントのサンプリング調整、クラウド統合やホスト統合のポーリング間隔の延長が効きます。プロセスメトリクスは既定で無効です。ログでは、自動ログインコンテキストの有効・無効の切り替え、フォワーダー側でのフィルタリング、4KBを超えるログを複数イベントへ分割するLogExtendedRecordの挙動が費用に直結します。1レコード4KB超の構造化ログを大量に流す設計は、想定より多くのイベントを生みます。

トレース側の削減は率の決め方で結果が変わります。ヘッドベースとテールベースの違いや率の決め方は[トレースサンプリングの仕組みとサンプリング率の決め方](https://www.issoh.co.jp/tech/details/15713/)にまとめており、New Relicでも同じ判断軸がそのまま使えます。

## データ保持期間の既定値がAPM 8日である前提での振り返り設計

費用の話と同じくらい見落とされるのが保持期間です。既定値のまま運用すると、月次の振り返りに必要なデータがもう消えている状況が起きます。

### 主要データ種別の既定保持日数とData Plusで98日へ伸びる範囲

[データ保持期間の公式ドキュメント](https://docs.newrelic.com/docs/data-apis/manage-data/manage-data-retention/)の一覧では、Original data optionとData Plusで保持日数が次のように分かれています。

| データ種別                   | Original data option | Data Plus  |
| ----------------------- | -------------------- | ---------- |
| APM／APMエラー              | 8日                   | 98日        |
| APMエラースタックトレース          | 8日                   | 8日         |
| トランザクションイベント            | 8日                   | 8日         |
| 分散トレース                  | 8日                   | 98日        |
| ロギング／カスタムイベント           | 30日                  | 120日       |
| Infrastructureプロセス      | 8日                   | 98日        |
| Infrastructureインテグレーション | 395日（13か月）           | 485日（16か月） |
| 外形監視データ                 | 395日（13か月）           | 395日（13か月） |
| モバイル一般                  | 8日                   | 98日        |

スタックトレースとトランザクションイベントはData Plusでも8日のまま伸びません。外形監視データは両オプションで395日固定、かつ編集不可と公式ドキュメントに明記された値です。詳細なトレースを長期保管する要件があるなら、New Relic側の保持設定ではなく外部へのエクスポートで解く必要があります。なおメトリックタイムスライスデータは生データが30日、8日経過後は1時間単位へ集約された形で90日まで残ります。

### 8日を超える振り返りに必要な指標の切り出しとダッシュボード設計

四半期単位の性能推移やリリース前後の比較を残したい場合、APMイベントを直接引くダッシュボードでは8日で参照できなくなります。回避策は、必要な集計値だけをカスタムイベントやメトリクスとして別途記録し、保持日数の長いネームスペースへ寄せることです。ロギングとカスタムイベントは既定30日、Data Plusで120日まで伸びます。

順序を逆にしないでください。先に「何日前まで遡るか」を決め、その日数に合う種別へ指標を落とす。ダッシュボードを作ってから保持切れに気づくと、過去分は取り戻せません。

## 日本リージョン（JP）の提供状況と設計初期に確認すべき機能制約

国内案件でNew Relicを提案するとき、最初に確認すべきはリージョンです。[データセンター選択の公式ドキュメント](https://docs.newrelic.com/docs/accounts/accounts-billing/account-setup/choose-your-data-center/)の記載は、多くの製品紹介記事が触れていない条件を含みます。

### JPリージョンがプレビュー提供である点と日本法人経由の申込要件

JPデータリージョンは提供が開発途上であり、プレリリースポリシーに基づくプレビュー提供として案内されています。一般提供ではありません。加えてJPリージョンはNew Relicの日本法人を通じてのみ利用でき、組織の作成は日本のサインアップページから申し込む必要があります。

金融・公共のように「本番監視データを国内に置く」条件が要件定義に入る案件では、プレビュー段階のサービスを前提にできるかを発注側と先に合意しておく必要があります。合意が取れないなら、製品選定そのものへ戻る判断です。

### JPで使えない機能の一覧とUSを選ぶ場合のデータ所在の兼ね合い

JPリージョンでは、公式ドキュメントの記載でAPMの週次パフォーマンスレポート、NR Lens、CodeStream、ログパターン、Infinite Tracing、Pixie、Insights Query API、NR REST v2 API（RPM）、デプロイメントマーカーAPI（変更追跡）が利用できません。エンドポイントもリージョンごとに異なり、たとえばトレースAPIのホストはJPが `trace-api.jp.nr-data.net`、EUが `trace-api.eu.newrelic.com` です。

影響が大きいのはPixieとInfinite Tracingの不在です。Kubernetesのカーネルレベル計測や全件トレースの取り込みを前提に設計していた場合、JPを選ぶと構成の作り直しになります。旧REST v2 APIやInsights Query APIに依存した自作の連携スクリプトも移植対象です。

### リージョン間のデータ移行が非対応である前提での初期選択の進め方

公式ドキュメントは、既存アカウントから別リージョンへ顧客データを転送・共有する仕組みを現時点で提供していないと明記しています。つまり組織を作った時点でリージョンは固定されます。

手順としては、必要機能の一覧をJPの制約リストと突き合わせる、データ所在の要件を発注側と文書で確認する、既存の連携スクリプトが使うAPIを洗い出す、この3つを終えてから組織を作成します。リージョン違いに後で気づくと、計装のやり直しと過去データの破棄が確定します。

## New Relicを採用する条件とDatadog比較で見送るべき場面の判断

ここからは判断を言い切ります。製品の優劣ではなく、どの構成条件なら選ぶ側に回るかという整理です。ツール全体の選定軸を先に俯瞰したい場合は[オブザーバビリティツールの選定軸と課金モデルの比較](https://www.issoh.co.jp/column/details/16502/)を併読してください。

### Datadogや各クラウド標準の監視と比べてNew Relicを選ぶ条件

New Relicが有利になるのは、閲覧者が多く操作は軽い組織、そして取り込み量が月100GB前後に収まる小～中規模構成です。ベーシックユーザーが無料で無制限という設計は、ダッシュボードとアラートだけを見る非エンジニアが多い現場で効きます。データ量に対する無料枠100GBも、単一プロダクトを数ホストで動かす規模なら超えません。

逆にDatadogは製品ごとのホスト単価が積み上がる構造です。[Datadogの機能構成と導入背景](https://www.issoh.co.jp/tech/details/6476/)と[Datadogの料金体系と費用が膨らむ課金単位](https://www.issoh.co.jp/tech/details/16574/)を見比べると、課金の効き方が正反対であることがわかります。監視対象ホストが増え続ける構成なら単価の読みやすいDatadog、閲覧者が多く取り込み量は読める構成ならNew Relic、という切り分けで判断してください。単一クラウドに閉じていて可視化もクラウド標準のダッシュボードで足りるなら、外部SaaSを挟む必要はありません。

### 採用を見送る2つの場面：所在要件が厳しい構成と短期PoCの検証

採用を見送るべき場面は2つあります。ひとつは、本番監視データの国内保存が要件として固まっている案件です。JPリージョンはプレビュー提供であり、移行も非対応。要件を満たすためにプレビュー段階のリージョンを選ぶ判断は、この場面では取りません。

もうひとつは、2～3週間で終わる短期PoCの性能検証です。エージェント導入とNRQLの習熟、ダッシュボード整備に費用と工数を割いた末、既定8日の保持期間で検証データが消えるという結果になります。この規模ならプロファイラやAPMを常設せず、負荷試験ツールのレポートで足ります。

判断が固まらない段階で計装だけ先に進めると、後戻りの工数が積み上がります。監視設計の切り分けや導入後の運用体制まで含めて相談したい場合は、[システムの保守運用と内製化支援](https://www.issoh.co.jp/service/system/maintenance/)で扱っている範囲を確認してください。

## よくある質問

New Relicの導入検討でよく挙がる質問を、2026年9月時点の公式情報にもとづいて整理します。

### newrelicとNew Relicは同じものですか？

同じ製品を指します。製品名としての表記は「New Relic」で、Goのモジュールパス `github.com/newrelic/go-agent` やnpmパッケージ、環境変数の接頭辞 `NEW_RELIC_` のように、コードやコマンドの中では空白を含まない `newrelic` が使われます。公式ドキュメントを検索するときはどちらでも同じページに当たるため、表記ゆれを気にする必要はありません。

### New Relicの無料枠だけでずっと運用できますか？

取り込みが月100GBに収まる規模なら可能です。ただしベーシックユーザーはAPM・インフラ監視・分散トレース・外形監視の画面を開けません。実務ではAPMを見る担当者だけをフルプラットフォームの無料枠（1名分）に置き、残りをベーシックに寄せる形になります。閲覧者が増えて枠を超えた時点で、コア（月額49ドル）またはフルプラットフォーム（Pro年間契約で月額349ドル）の課金が始まります。

### New RelicとDatadogはどちらを選ぶべきですか？

課金の効き方で分かれます。New Relicはデータ取り込み量とユーザー数の2軸、Datadogは製品別のホスト単価が中心です。監視対象ホストが増え続ける構成はDatadogのほうが見積りが読みやすく、閲覧者が多いのに取り込み量は限られる構成はNew Relicが安く収まります。機能一覧の比較より先に、自社で増える単位がホストか人か取り込み量かを特定してください。

### OpenTelemetryで計装すればNew Relic固有のエージェントは不要ですか？

トレース・メトリクス・ログの3シグナルはOTLP経由で送れるため、計装をOTelに寄せたままバックエンドとして使えます。送信先はUSが `otlp.nr-data.net`、JPが `otlp.jp.nr-data.net` で、`api-key` ヘッダーにライセンスキーを指定します。ただしペイロード上限1MB、属性値4,095文字といった制約があり、JPリージョンではInfinite Tracingが使えません。エージェント固有の自動計装で取れる指標も一部は対象外です。要件表と突き合わせて判断してください。

### ドロップルールで費用を抑える手順は今も同じですか？

変わりました。NerdGraphのNRQLドロップルール（`nrqlDropRulesCreate`）は公式のEOL告知で2026年8月31日16:00 UTCに提供終了となり、現在はPipeline Controlのcloud rules API（`entityManagementCreatePipelineCloudRule`）が同等の役割を担います。条件の書式も `SELECT` ではなく `DELETE FROM` です。古い記事やスクリプトをそのまま流用すると通らないため、移行済みかを先に確認してください。

### APMのデータが8日で消えるのは設定で変えられますか？

Data Plusへ切り替えるとAPMとAPMエラー、分散トレース、Infrastructureプロセスは98日まで伸びます。ただしAPMエラースタックトレースとトランザクションイベントはData Plusでも8日のままです。長期保管が必要なら、必要な集計値をカスタムイベント（既定30日・Data Plusで120日）へ書き出すか、外部へエクスポートする設計にしてください。

### 日本リージョンを選んでおけば安心ですか？

データ所在の観点では国内に置けますが、JPリージョンはプレリリースポリシーに基づくプレビュー提供で、一般提供ではありません。APMの週次パフォーマンスレポート、NR Lens、CodeStream、ログパターン、Infinite Tracing、Pixie、Insights Query API、NR REST v2 APIなどが使えず、申し込みは日本法人経由に限られます。リージョン間の移行も非対応です。必要機能の洗い出しを済ませてから組織を作成してください。

## 関連記事

- [APM（アプリケーション性能監視）とは](https://www.issoh.co.jp/tech/details/15414/)：New Relicが担う監視領域の仕組みと3種の監視データを、製品に依存しない形で解説しています。
- [オブザーバビリティ（可観測性）とは](https://www.issoh.co.jp/column/details/3077/)：従来の監視との違いと3本柱という、製品選定の前提になる考え方を確認できます。
- [オブザーバビリティツール比較](https://www.issoh.co.jp/column/details/16502/)：課金モデルと運用体制別の選び方を横断的に整理しており、他候補との比較材料になります。
- [メトリクス監視とは](https://www.issoh.co.jp/tech/details/15704/)：New Relicへ送る指標の型と収集方式、アラート閾値の決め方を実装目線で扱っています。
- [リアルユーザーモニタリング（RUM）とは](https://www.issoh.co.jp/tech/details/15707/)：実ユーザー計測の仕組みと、外形監視との使い分けがわかります。

---

出典: [New Relicとは｜APM・インフラ監視の構成とデータ量課金の設計を実装目線で解説](<https://www.issoh.co.jp/tech/details/17247/>)（株式会社一創）