New Relicとは｜オブザーバビリティの基本・Datadogとの違い・案件動向

New Relicとは｜統合オブザーバビリティ基盤の全体像

New Relicは、メトリクス・トレース・ログ・イベントを1つの基盤で時系列に紐づけて可視化するSaaS型の観測プラットフォームです。米New Relic社が提供しており、2008年からAPM（Application Performance Monitoring）の老舗として知られてきました。

New Relicの基本定義

New Relicは、アプリケーションのレスポンス、サーバのリソース、エンドユーザーのブラウザ計測、エラー、ログまでを共通プラットフォーム上で関連付けて分析できるオブザーバビリティ基盤です。「アプリの遅延が、どのSQLクエリで、どのホストで、どのユーザー画面で発生しているのか」を1つの画面でたどれる点が、単機能の監視ツールとは異なる特徴になります。

エージェントは主要言語（Java・.NET・Node.js・Python・PHP・Ruby・Go）に対応し、Kubernetes・Docker・主要クラウドサービスとのインテグレーションも整備されています。最新の対応一覧はNew Relic Documentationで確認できます。

なぜ「オブザーバビリティ基盤」と呼ばれるのか

監視ツールは長くサーバ監視・APM・ログ・エラー追跡などの用途別に分かれていました。New Relicはこれらをひとつの基盤に統合し、メトリクス・イベント・ログ・トレース（MELT）を共通のクエリ言語NRQLで横断分析できることを訴求しています。一般的な「監視（Monitoring）」が事前に決めた指標を眺める活動だとすれば、オブザーバビリティは「想定外の事象も、後からデータを掘れば分かる」状態を作る考え方です。

提供形態とエディション

New Relicは基本的にSaaSとして提供されます。利用可能なデータ保存リージョン・データレジデンシー条件は時点・プランで変わるため、最新の公式ドキュメントで確認してください。エディションはフリープラン／Standard／Pro／Enterpriseの4段階で、機能差は主にユーザー権限・サポート・データ保持期間に現れます（執筆時点。詳細はNew Relicのpricingページを必ず確認してください）。

ミニFAQ

• Q. 個人で試せますか？　A. クレジットカード登録なしで使えるFree Tier（執筆時点では取り込みデータ100GB/月、フルプラットフォームユーザー1名）が用意されています。最新条件は公式pricingで必ず確認してください。

• Q. 日本リージョンはありますか？　A. 利用可能なデータ保存リージョンや契約条件は時点・プランで変わるため、最新の公式ドキュメントで確認してください。日本国内へのデータ保管要件がある場合は、契約条件と社内要件を照らし合わせて慎重に判断する必要があります。

New Relicでできること｜主要機能の整理

主要機能はおおむね6系統に分けて理解すると、案件の要件と紐づけやすくなります。

APM（アプリケーション性能監視）

New RelicのコアであるAPMは、リクエストごとの分散トレースを収集し、メソッド・SQL・外部APIコールの呼び出し階層を可視化します。アプリにエージェントを組み込み、Apdex（応答時間に基づくユーザー満足度指標）やエラーレートを継続的に記録します。「平均は遅くないが、p99のレイテンシだけ悪化している」のように分布の偏りを掴みたいケースで力を発揮します。

Infrastructure Monitoring

サーバ・コンテナ・クラウドサービスにエージェントを入れ、CPU・メモリ・ディスク・ネットワーク・カスタムメトリクスを取得します。Kubernetes向けの統合（New Relic Kubernetes Integration）が提供され、PodやNodeの状態をマップ表示できます。

Logs in Context

ログを単独で見るだけでなく、関連するAPMトレース・エラーと紐づけて表示する「Logs in Context」が特徴です。エラー画面から該当ホストのログへ、トレースから対応ログへとワンクリックで遷移できる設計になっています。ログ単独機能としてはDatadog Log Managementや、オープンソースのELK・Lokiが競合になります。

Browser & Mobile

ブラウザにSDKを埋め込むことで、ページロード時間・Core Web Vitals・JSエラーを実ユーザーから収集できます。モバイルはiOS/Androidそれぞれにエージェントが用意され、クラッシュレポートとANR（Android Not Responding）の追跡が可能です。フロントエンド側のエラー詳細を細かく追う用途では、Sentryと併用される構成も見られます。

Synthetic Monitoring

世界各地のロケーションから定期的にAPI・Webサイトを叩く外形監視機能です。シンプルなPing型から、ヘッドレスブラウザを使ったマルチステップ型まで複数モードがあり、ログイン後の特定画面まで含めた監視シナリオを書けます。

Alerts & Applied Intelligence

NRQLで条件を書くか、テンプレートからアラートを作成します。Applied Intelligenceは類似アラートのグルーピングや異常検知のしきい値自動算出を支援する機能群で、運用が大規模になるほど効きやすい領域です。

ミニFAQ

• Q. 1機能だけ使うことはできますか？　A. 機能単位の契約ではなく、データ取り込み量で課金される構造です。APMだけ・ログだけといった「一部機能のみ契約」という考え方は基本的になく、必要な機能を必要なだけデータ送信する形になります。

New Relicの料金体系｜データ取り込みとユーザー数の二軸

New Relicの料金は、「データ取り込み量（Ingest）」と「フルプラットフォームユーザー数」の2軸で決まります。機能ごとの内訳課金ではないため、全機能込みで使える反面、ログやカスタムメトリクスを大量に流すと取り込み課金が伸びる構造です。

課金モデルの基本

執筆時点ではフリープラン枠は取り込みデータ100GB/月＋フルプラットフォームユーザー1名＋Basicユーザー無制限が基本です。条件は変更されうるため、最新条件は公式pricingで確認してください。フルプラットフォームユーザーはNew Relic上のすべての機能を触れる権限を持ち、Basicユーザーはダッシュボード参照や限定的な編集だけ可能です。

コストが膨らみやすいポイント

• 分散トレースを100%サンプリングで送る（大規模システムでは数十GB/日になることもある）

• 詳細ログを全レベル（DEBUG含む）でNew Relicに転送する

• Custom Eventsを大量に書き込むアプリケーションロジック

• マルチクラスタ・マルチクラウド構成でInfrastructureエージェントを全ノードに配置

設計時点で「観測すべきデータ」と「保存すべきだが集約してよいデータ」を切り分ける設計が必要です。S3など外部ストレージに長期保存し、New Relicには必要な期間だけインデックスするハイブリッド設計を取る現場もあります。

Datadog課金との構造的な違い

「使う機能を最小化したい組織」はDatadog型の機能別課金が、「全機能を使い込みたいがホスト数が多い組織」はNew Relic型のデータ課金が、それぞれ向くケースがあります。

ミニFAQ

• Q. 大規模に使うと結局どちらが安いですか？　A. 利用機能の数とホスト密度で変わるため一概には言えません。「ホスト1台あたりの観測データ量」が小さくホスト数が多い構成ではNew Relic型が、特定機能だけを深く使う構成ではDatadog型が有利になることが多い、と整理しておくのが現実的です。

New Relicと他の観測ツールの違い

代表的な観測ツールとの違いを整理します。「どれが優れているか」ではなく、「どの場面で選ばれやすいか」で見ると判断しやすくなります。

vs Datadog

Datadogも統合観測SaaSという立ち位置は近いですが、課金モデルと得意領域に差があります。詳細はDatadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説を参照してください。

vs Prometheus + Grafana

Prometheus + Grafanaはオープンソースのメトリクス監視構成で、自社運用が前提です。詳細はPrometheus & Grafanaとは｜メトリクス監視の基本・Datadogとの違いで整理しています。

• コスト：ライセンス費はゼロだが、運用工数と冗長構成のインフラ費が発生

• 機能領域：メトリクスが中心。ログ・トレースはLoki/Tempo等を追加構成する必要がある

• データ保持：ローカル保存が基本で、長期保管は別ストレージ設計が必要

「メトリクスだけで十分」「自社オンプレ環境への配置が必須」といった条件ではPrometheus構成が選ばれる傾向があります。

vs Sentry

Sentryはエラートラッキングに特化したツールで、観測対象の範囲が異なります。

• 得意領域：例外スタックトレース・リリースとエラーの紐づけ・フロントエンドエラー

• 観測範囲：エラー中心。インフラリソースやAPMトレースは対象外

• 併用：New Relic（またはDatadog）で全体観測、Sentryでエラー詳細という構成も実務でよく見られる

vs CloudWatch / Azure Monitor / Cloud Monitoring

クラウドベンダーが提供する純正監視サービスは、当該クラウドサービスとの統合が深いことが特徴です。マルチクラウド構成や、SaaS・SDK監視まで広く扱いたい場合にNew Relicのような独立SaaSが選ばれることがあります。

ミニFAQ

• Q. すでにPrometheusを運用していて、New Relicを併用できますか？　A. New RelicはPrometheus形式のメトリクスを取り込めるため、既存Prometheusをデータソースとして残しつつ、長期保存・横断分析側にNew Relicを使う構成も取れます。

NRQLとデータモデル｜「クエリで観測する」基本

New Relicの強みのひとつが、独自クエリ言語NRQL（New Relic Query Language）で全データを横断的に検索できる点です。

NRQLの基本構文

NRQLはSQL風の構文で、データ型（Metric/Event/Log/Span）をFROMで指定し、WHEREで絞り込みます。たとえば「直近30分のトランザクションデータから、アプリ名ごとの平均レスポンス時間とリクエスト件数を集計する」といった処理を、SELECT・FROM・FACET・SINCEを組み合わせた1クエリで表現できます。

NRQLはダッシュボード、アラート条件、アドホック分析のすべてで共通して使えるため、習得すれば一気に運用効率が上がります。公式のNRQLリファレンスに、関数・集計・時間条件の一覧が整理されています。

イベントとメトリクスの違い

• Event：個別のリクエストやトランザクションのレコード。詳細属性を保持

• Metric：時系列のサマリ値。Eventよりも保存効率が高い

両者は使い分けが必要で、「全リクエストを後から詳細分析したい」ならEvent、「ダッシュボード描画と長期保持」ならMetricが向きます。設計を誤ると取り込み課金が想定外に伸びる原因になります。

ダッシュボードとアラート

NRQLで書いたクエリは、そのままダッシュボードのウィジェットやアラート条件として再利用できます。チームで使うダッシュボードは、JSON形式でエクスポート／インポートが可能で、IaC的にGit管理する運用も取れます。

導入と運用でよくある失敗と対策

現場で見聞きする典型的なつまずきポイントを整理します。

失敗1: 全ログをDEBUGレベルでNew Relicに流してしまう

ログ取り込みコストが急増します。アプリ側のロガー設定で、本番はINFO以上、開発はDEBUG以上のようにレベル分離し、必要なフィルタリングをログ転送側で行うのが基本です。

失敗2: アラートが多すぎて見られない

「とりあえず大量のメトリクスにアラートを置く」と、通知が常時鳴り続けて誰も見なくなります。SLO（Service Level Objective）を起点にアラートを設計し、ユーザー影響が大きい少数のシグナルに集約するのが運用上の定石です。SREの考え方はSREとは｜仕事内容・年収・必要スキルとDevOpsとの違いで扱っています。

失敗3: 分散トレースを100%サンプリングしたまま放置

データ取り込みが想定の数倍に膨らみやすい構成です。重要度が低いエンドポイントはサンプリングレートを下げ、エラーや遅延発生時のみ保持するなど、エージェント側のサンプリング設計を見直します。

失敗4: タグ命名がチーム間でバラバラ

ホスト名・サービス名・環境名（env: prod/stg/dev）のタグ命名規約が定まっていないと、横断検索の精度が落ちます。運用開始前にタグ命名ガイドを決め、エージェント側で強制するとあとが楽になります。

失敗5: フリープランで運用を始めて、突然有料移行が必要になる

フリープランの取り込み上限を月途中で超えた場合の挙動はプラン条件で変わりうるため、事前に公式仕様で確認してください。一般的にはアラート閾値（例：80%超過時に通知）を設定し、月初から残量をモニタリングする運用が安全です。

フリーランスエンジニアのNew Relic案件動向

どんな案件で募集されるか

New Relic単独のスキルだけで募集される案件は多くなく、SRE・DevOpsエンジニア・クラウドエンジニアロールの一要素として「New Relic（またはDatadog）の運用経験」が要件に並ぶ形が一般的です。具体的には以下のようなポジションが多く見られます。

• SaaSプロダクトのSRE：APMダッシュボード設計、アラート設計、SLO策定

• マイクロサービス基盤チーム：分散トレース整備、エンジニア向け運用ガイド作成

• クラウドネイティブ移行プロジェクト：オンプレ監視からNew Relic等への移行設計

単価レンジの目安

執筆時点（2026年6月）で主要フリーランスエージェントの公開案件（週2〜5日・業務委託、首都圏・リモート混在）を目視確認した範囲では、SRE／DevOps領域でNew RelicやDatadog運用経験が要件に含まれる案件で、月額70〜100万円前後の募集が見られる傾向があります。これは公開案件ベースであり、非公開案件は含みません。100万円以上の事例は、AWS/GCP/Azureの本番運用経験3年以上、Kubernetes・IaC（Terraform）運用経験、SLO設計まで担えるエンジニア層で見られるケースが中心です。観測ツールの操作経験だけでは単価が伸びにくく、SLO設計・アラート設計・運用フロー整備までできるエンジニアが評価されやすい領域、と整理しておくのが現実的です。

求められるスキルセット

• New Relic（またはDatadog）の主要機能の運用経験

• NRQL（または同等のクエリ言語）でのダッシュボード・アラート設計

• Kubernetes・コンテナ環境での観測エージェント配置

• SLO/SLI設計、アラート設計、インシデント対応プロセスの整備

• Terraform等のIaCツールで観測リソースをコード管理した経験

ツール操作だけでなく、「観測をプロダクトの信頼性指標に接続できる」レベルが評価軸になります。

ミニFAQ

• Q. Datadog経験はあるがNew Relicは未経験、案件で評価されますか？　A. 観測ツールは概念が共通しているため、Datadog経験者がNew Relic案件に応募して評価されるケースは少なくありません。NRQLの基礎学習と、Free Tierでの実機検証を提出資料に含めると説得力が上がります。

ケース別の活用パターン

ケース1: スタートアップ（〜30人規模）

• フリープラン or Standard相当からスタート

• APM + Infrastructure + Logsを中心に最低限の観測を整備

• アラートは「Webサイト落ち」「決済エラー急増」など事業影響の大きい少数指標に絞る

• フルプラットフォームユーザーは1〜2名、他はBasicユーザーで分担

ケース2: 中規模SaaS（30〜300人規模）

• Pro契約に移行し、データ保持期間とサポートを強化

• マイクロサービス全体に分散トレースを展開、サンプリングを設計

• SLO起点のアラート設計と、PagerDuty等とのインシデント連携

• ダッシュボードをチーム別・サービス別に整理し、オーナーを明示

ケース3: エンタープライズ

• Enterprise契約とSSO・監査ログ・データレジデンシー要件への対応

• マルチクラウド・マルチリージョン構成でのデータパイプライン設計

• セキュリティチーム・コンプライアンス部門との要件調整

• 内部利用ガイド・運用ランブックの整備

New Relic学習ロードマップ

ステップ1: Free Tierで全体感を掴む

公式のFree Tierを作成し、自作アプリやサンプルアプリにエージェントを入れて、APM・Infrastructure・Logsを一通り眺めるところから始めます。初日に「自分の手元のNode.js/Pythonアプリのトレース」を見られるところまで進めると、概念が一気に立ち上がります。

ステップ2: NRQLを書いてダッシュボードを作る

公式のNRQLドキュメントを参照しながら、レスポンス時間・エラーレート・ログ件数のグラフを書いてみます。テンプレートを使うのではなく、ゼロからクエリを書く経験が後で効きます。

ステップ3: アラートとSLOを設計する

「何が起きたらPagerに飛ばすか」を設計します。SLOベースのアラート設計はSRE文献（『Site Reliability Engineering』）も合わせて学習すると、運用設計の解像度が上がります。

ステップ4: 認定資格と公式トレーニング

New Relic Universityで提供される無料の学習コースと、Performance Pro認定などの資格は、案件応募時のスキル可視化に有効です。Datadogの認定資格と合わせて取得しておくと、観測ツール領域での提案力が高まります。

ステップ5: 案件への接続

学習履歴・自作ダッシュボード・Free Tierでの検証結果をGitHubやポートフォリオに整理しておくと、SRE・DevOps案件のエントリー時にツール経験を客観的に示せます。

まとめ

New Relicは「データ取り込み量＋ユーザー数」で課金される統合オブザーバビリティ基盤で、Datadogの機能別課金とは構造が異なる選択肢です。フリーランスエンジニアにとっては、SRE・DevOps領域でDatadogと並ぶ採用ツールとして触れておく価値があります。

要点は以下のとおりです。

• 全機能込みの基盤で、料金は取り込みデータ量とユーザー数に連動する

• 100GB/月のフリープラン枠が大きく、個人や小規模チームでも触りやすい

• Datadogが「機能別課金」、New Relicが「データ量課金」と構造が違う点が選定の分岐になる

• NRQLでの分析・ダッシュボード設計・SLOベースのアラート設計までできる人材が評価されやすい

• 学習はFree TierとNRQL習得から始め、案件接続にはSRE/DevOpsの周辺スキルを揃える

観測ツールは「触ったことがある」よりも「事業の信頼性指標と接続できる」かが問われる領域です。Datadog・Prometheus・Sentryとの違いを整理しつつ、自分の運用観点に合うツールを選んでみてください。

参考リンク：

• New Relic公式サイト

• New Relic Documentation

• New Relic Pricing

• NRQL リファレンス

• New Relic University（公式トレーニング）