New Relicのシステム導入は、要件整理、方式選定、設計・開発の順に進みます。続けてテスト、段階稼働、運用定着へ移り、障害対応と改善を業務に定着させます。
導入範囲の決め方、6つの導入フェーズ、費用と見積もりの確認点を順に見ていきます。
▼全体ガイドの記事
・New Relicのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
New Relicのシステム開発・導入の全体像
New Relicは、アプリ、インフラ、ログ、ユーザー体験を横断して観測するSaaS型プラットフォームです。業務機能を提供するシステムではありません。
導入の成否は、エージェントを入れた後の運用設計で決まります。具体的には、誰がデータを見て、どの基準で対応し、どの指標で改善を判断するかを決めておきます。
「New Relicのシステム」が指す範囲
「New Relicのシステム」は、既存の業務システムやWebサービスに監視機能を組み込むことを指します。New Relic本体を自社で作り込むわけではありません。
既存システムに組み込む範囲は、監視から運用までの4つの面で捉えられます。
- 監視機能：APM、Infrastructure monitoring、Logs、Browser monitoring、Synthetic monitoring
- 構築範囲：データ送信、NRQL検索、ダッシュボード、アラート、チケット連携
- 接続方法：エージェント、SDK、OpenTelemetry、クラウド連携
- 運用連携：可視化した情報をメール、チャット、チケット、インシデント手順へつなぐ
これらは、システムやクラウド、サーバーから送ったデータをNew Relicで可視化する構成です。また、公式は50以上の機能と780以上のインテグレーションを案内しています（出典：New Relic「New Relicオブザーバビリティプラットフォーム」、2026年確認）。機能を増やすほど、運用ルールと費用管理も複雑になります。
導入範囲と成功条件の決め方
最初に決めるのは、解決したい経営・業務課題です。監視画面を作ること自体を目的にしないよう、課題から考えます。
課題、評価指標、監視対象、担当範囲は、次の観点で整理します。
- 課題例：原因特定に平均6時間、リリース後のエラー検知、クラウド費用と処理量の関係把握
- 評価指標：平均原因特定時間、MTTR、エラー率、SLO達成率、重大障害件数、ユーザー影響時間
- 監視対象：画面、API、DB、キュー、バッチ、コンテナ、Kubernetes、外部SaaS、ネットワーク、認証基盤
- 記録項目：所有部署、重要度、営業時間、連絡先、個人情報、既存監視、障害時の一次対応者
また、既存監視にはZabbixやPrometheusなども含めます。一覧がないまま設定を進めると、アラートの担当者が決まらず、通知が放置されかねません。
New Relicのシステム導入・開発の進め方
New Relic導入は、要件整理から定着までを一つのプロジェクトとして進めます。設計・開発だけでなく、稼働後のアラート対応者とデータ量の管理者も早めに決めておきます。
1. 要件整理フェーズでの目的と監視対象の定義
対象サービスは、事業影響の大きさと原因調査の難しさで優先順位を付けます。売上や申請処理に直結するもの、複数のAPIやDBを経由するもの、ログだけでは原因を追えないものが、PoCの候補になります。
停止しても業務への影響が小さく、既存監視で足りる対象を最初から含めると、初期費用とデータ量が増える場合があります。
要件整理では、対象の構成と運用の条件を4つの面に分けて記録しておきます。
- 対象・環境：サービス名、環境名、本番・検証の区分
- 処理・データ：ピーク時のリクエスト量、ログ量、利用言語
- システム構成：クラウド・オンプレミス、DBやキューの種類
- 運用・契約：個人情報の有無、既存監視、SLA、対応部署
導入前の原因特定時間やエラー率も、あわせて測っておきます。基準値がなければ、画面が増えただけなのか、障害対応が改善したのかを判断できません。
2. 選定フェーズでの方式と支援会社の比較
選定では、実装方式と、支援会社がどこまで対応するかを比べます。
- 実装方式：標準機能、言語別エージェント、OpenTelemetry、既存監視の併用範囲
- 独自開発：社内ポータル、会社固有のNRQL・画面、申請・権限、チケット・CMDB連携
- 支援範囲：要件定義、計装、NRQL、アラート、SLO、セキュリティ、教育、運用引き継ぎ
- 実績確認：担当者の資格、類似案件の実作業経験、内製化と成果物の引き継ぎ
New Relicは監視バックエンドを自社で開発する製品ではありません。独自開発は必要な範囲に絞るほど、保守しやすくなります。
OpenTelemetryは、ベンダーに依存しない計装と送信経路の分離に使えます。また、公式資料では、OTLPによるメトリクス、ログ、トレースの取り込みが案内されています。OTLP/HTTPでは、ポート443、4317、4318などを利用できます（出典：New Relic公式「New Relic OTLP endpoint」、2026年確認）。
OpenTelemetryでは、標準化やCollectorの運用が必要なため、エージェント方式より常に安価で簡単とは限りません。
2025年9月時点の国内資格者一覧には、NTTデータ先端技術、サーバーワークス、日立ソリューションズ、SCSKなどが掲載されています。なお、資格者数は、実作業者や類似実績を保証するものではありません（出典：New Relic「国内パートナー企業別 有資格者数」、2025年9月）。
3. 設計・開発フェーズでのデータと運用の実装
設計・開発では、データの共通規約を決めたうえで、監視項目とアラートを実装します。機密情報の扱いも、この段階で決めます。
- タグ規約：サービス、環境、リージョン、チーム、版、顧客区分、重要度の表記を統一
- 監視データ：APM、Infrastructure monitoring、Logs in Context、分散トレーシング
- ユーザー体験：重要操作に絞ったBrowser、Mobile、Syntheticの追加
- アラートと保護：対応条件の設定、機密情報の除外・マスキング、APIキーの安全な保管
本番と検証、チームの表記がそろっていないと、NRQLやダッシュボードを使い回しにくくなります。そのため、規約は運用手順書とRFPに記し、アプリ、インフラ、ログで共通に使います。
APMでは、レスポンスタイム、スループット、エラー率を取得します。トランザクションとDB呼び出しも、あわせて取得します。
インフラでは、ホスト、コンテナ、Kubernetesの状態を確認します。さらに、ネットワークとストレージも対象にします。
Logs in Contextや分散トレーシングでは、エラーから関連ログや呼び出し経路へ移れることを、完了条件にします。
アラートは、CPU使用率だけで決めず、エラー率、レイテンシー、SLOを組み合わせます。異常傾向やメンテナンス時間も、あわせて考慮します。
重大度ごとに、通知先と一次対応を決めます。そのうえで、エスカレーションと抑制の条件を決めます。復旧確認とポストモーテムの段取りも整えます。
パスワード、アクセストークン、カード情報は、送信前に除外またはマスキングします。個人情報も、同じ扱いにします。また、APIキーはソースコードに埋め込まず、安全な場所で管理します。
4. テストフェーズでのデータ精度と障害対応の検証
テストでは、データの正確さと障害対応を確かめます。料金の把握やセキュリティ設定についても、確認します。
- データ精度：欠落、タグ、トレースとログの関連、集計値の確認
- 費用把握：想定超過時の料金と取り込み量を示す画面の確認
- 障害対応：通知時間、夜間・休日連絡、連続通知抑制、復旧、チケット記録の確認
- セキュリティ：テスト情報の送信防止、認証・ネットワーク設定の確認
通知テストでは、わざとエラーや遅延を起こし、担当者に届くまでの時間を測ります。
認証設定では、SAML SSOとMFAを確認します。加えて、RBACと監査ログも要件どおりかを確かめます。プロキシと許可先ドメインは、要件に沿って設定します。
5. 稼働フェーズでの段階展開と切り戻しの準備
本番展開と稼働判定では、展開順から切り戻し準備まで4つの項目を確かめます。
- 展開順：最重要の1サービスから関連API、DB、次のサービスへ広げる
- 監視併用：ZabbixやPrometheusを残し、検知漏れ、重複、負荷、データ量、費用を比べる
- 稼働基準：重大通知、原因の絞り込み、手順書での一次対応、想定内のデータ量と料金
- 切り戻し準備：再起動対象、通信許可、リリース凍結期間、問題時の戻し方を確認する
公式事例では、デンソーがNew RelicをZabbixのインフラ監視の補完として導入しています。約2万ユーザーが使う申請承認システムの性能問題も検証しています。既存監視も、すぐには廃止せず、一定期間New Relicと併用します。
6. 定着フェーズでの人とルールの継続的な改善
定着後は、運用の振り返り、手順の共有、担当者の演習を続けます。
- 定期確認：毎月または四半期ごとに、アラート数、誤検知、対応・原因特定時間、SLO、データ量、利用者数、クラウド費用を振り返る
- 設定管理：監視設定と障害対応手順を文書やリポジトリで管理する
- 障害演習：通知、影響確認、ログ・トレース調査、一次対応、記録を体験する
- AI利用：New Relic AIの提案を人が検証してから復旧操作する
未対応のアラートや同じ通知の連発、担当部署の更新漏れが見つかったときは、通知条件と責任分担を見直します。設定を追加するだけでは、こうした問題は解消しません。
NRQLやダッシュボード、アラートは、文書やリポジトリで管理します。サービスマップとタグ規約も、同じ場所に置きます。
エージェントの設定やOpenTelemetry Collectorの設定、障害対応手順を記録しておけば、特定の担当者しか分からない状態を防げます。
公開事例では、AI insideが2025年3月期にクラウドリソース効率を前年度比48％向上させました。加えて、主要機能の処理時間は従来比で2倍以上短縮したと紹介されています。
これは同社の成果であり、全社に同じ効果が出るとは限りません。そのため、導入前の基準値と比べて、自社の事業価値を判断します（出典：New Relic「AI insideがNew Relicを活用」、2025年6月）。
New Relicのシステム導入にかかる費用相場と内訳
費用は、ライセンス料と導入・設計・構築費に分けて見ます。ライセンス料はデータ量、保持期間、ユーザー数で変わり、教育や保守運用の費用も別に見込みます。
日本円の導入支援価格は、一律には公開されていません。そこで、以下のSI費用は、一般的な工数と支援範囲から組み立てた企画段階の推定として示します。
これらを定価と断定せず、対象サービスとログ量を示して個別に見積もりを取ります。運用時間や連携先も、条件として伝えます。
データ量とユーザー数で変わるライセンス料金
2026年時点で確認した公式料金をもとに、無料枠、有料単価、試算例を示します。
- 無料枠：月100GB、Full platform user 1人、基本ユーザー無制限、保持8日以上、Synthetic check 500件
- 有料単価：Full platform userは月10ドルから、Core userは月49ドルから
- データ単価：無料枠超過分は通常1GBあたり0.40ドル、Data Plusは0.60ドル
- 試算例：月200GBとFull platform user 5人なら、単純計算で月90ドル
料金はエディションによって異なります。ここに示す無料枠の内容と有料単価は、公式料金ページに基づきます（出典：New Relic「Transparent Pricing」、2026年確認）。
試算例では、ユーザー料金50ドルと、無料枠を超えた100GB分のデータ料金40ドルを合算しています。1ドル150円で換算すると、約13,500円になります。
ただし、実額は契約内容や為替、税によって変わります。さらに、追加機能、保持期間、Data Plusの有無でも変わります。
見積書では、ユーザー数とは分けて、月間GBと環境別GBを記載してもらいます。保持期間と超過単価も、あわせて書いてもらいます。
導入・設計・構築費の推定レンジ
推定レンジは、導入規模と、含まれる支援内容によって変わります。
- 1サービス検証：無料枠でエージェント、画面、アラートだけを設定する場合、50万〜200万円程度
- 小〜中規模：APM、Infrastructure、ログ、基本アラート、画面を複数環境へ展開し、200万〜800万円程度
- 中〜大規模：複数サービス、分散トレース、SLO、CI/CD・チケット連携、オンプレミス併用で800万〜3,000万円程度
- 全社展開：ハイブリッド・マルチクラウド、24時間運用、セキュリティ・ガバナンスを含む場合、2,000万〜1億円超の可能性
これらは公式の定価ではなく、推定値です。要件整理、設計、設定、テスト、教育のどこまでを含むかで、費用は変わります。
金額とあわせて、PMやアーキテクトなどの担当者が何人月・何週間関わるかを確認します。
ランニングコストと予算超過への備え
運用費とデータ超過を見込んだうえで、費用と利用量を定期的に管理します。
- 運用業務：NRQL・画面改修、アラート調整、ライセンス、技術支援、教育、24時間一次対応
- 保守費の仮置き：初期SI費の年15〜25％という考え方もあるが、対応範囲で変わる
- データ管理：アプリ・ログ・トレース量を測り、送信対象とサンプリング率を決める
- 超過抑制：85％などの社内アラート、不要ログ除外、属性削減、保持期間見直し
24時間監視や障害対応の有無で保守費は変わります。そのため、割合だけで予算を組むことはしません。
支援会社には、月次定例と問い合わせ応答時間を分けて提示してもらいます。対象外作業や休日対応、対応時間も、別々に示してもらいます。
月次で、取り込み量と請求額を確認します。無料枠があっても、全ログを無制限に送るのは避け、業務上必要なデータと調査用データを分けて扱います。
New Relicの見積もりを取る際のポイント
ライセンスと導入作業を一つの月額料金にまとめてしまうと、見積もりの比較がしにくくなります。費目と対象外作業は、分けて明記してもらいます。
見積もりは、ライセンス、初期設計・構築、アプリ改修を分けて出してもらいます。ダッシュボードやNRQL、既存監視連携は、費目ごとに区切ってもらいます。教育と運用保守は、別の費目にしてもらいます。
複数社には同じ条件を示し、価格に加えて、稼働後に自社で変更できる成果物と体制も比べます。
要件資料に書く対象範囲とデータ量
RFPや見積依頼書には、システム構成とデータ量の前提を書きます。機能やセキュリティの前提も、同じ資料に記載します。
- システム構成：サービス数、言語、AWS・Azure・オンプレミス、ホスト・コンテナ数、Kubernetesの有無
- データ条件：月間ログ・トレース量、ピークトラフィック、保持期間、ユーザー数、環境数
- 必要機能：APM、インフラ、ログ、ブラウザ、Synthetic、分散トレース、SLO、アラート等
- セキュリティ：機密情報の除外・マスキング、保存地域、データ削除の条件
不明な項目は空欄にせず、直近30日や繁忙期の実績を測るか、ベンダーに前提を置いてもらいます。
必要機能には、OpenTelemetryやチケット連携も含めます。SSOやRBAC、監査ログも、必要度を分けて選びます。そのうえで、誰が何を判断する画面かを決めます。
パスワードやアクセストークン、カード情報は、ログに出さないか、マスキングする要件を明記します。個人情報についても、ログに出さない要件かマスキングする要件かを明記します。
複数社の同一条件での比較
候補会社は、費用と担当体制を中心に、同じ前提で比べます。
- 提出条件：PoC、本番、月次運用、ライセンス、超過単価、対応時間
- 担当体制：資格、類似実績、実作業者数、内製化支援
- 成果物：NRQL、ダッシュボード、IaC、運用手順書の返却
- PoC判定：別契約にできる場合、1〜2サービスで原因特定時間、アラート適合率、ログ・トレースの関連、対応時間、データ量・月額費用を評価
資格者の人数は、比べる材料の一つにすぎません。実際に自社案件に入る担当者かどうかを確認します。
PoCの設定を本番へ移せるかどうかや、追加費用の条件、不合格時の終わらせ方も、先に決めておきます。
追加費用と運用リスクの条件確認
追加費用とセキュリティ上の適用範囲を、契約前に確認します。
- 利用量の増加：サービス、ログ・トレース量、保持期間、権限、Synthetic check
- 追加機能・支援：Data Plus、高度な計算機能、24時間対応、既存システム改修
- 見積条件：単価、上限、超過時の承認者と通知方法、ピーク時ログ量
- 適用範囲：利用機能、保存地域、業界規制、個人情報の扱いを照合する
ログ量はリリースやキャンペーンで急増するため、通常時だけでなくピーク時も確認します。
公式は、SAML SSOや監査ログ、SOC 2などを案内しています。米国・EUのデータセンターも、あわせて示しています。ただし、すべてのサービスが同じ認証範囲に入るとは限りません。
SOC 2の資料にも、対象外のサービスが明記されています。利用する機能などを、自社のセキュリティ部門と照らし合わせます（出典：New Relic「Security and privacy」「SOC 2」、2026年確認）。
New Relicのシステム導入でよくある質問
導入前によく質問されるのは、製品の位置づけ、既存監視との関係、期間と費用です。発注前に確かめておきたい疑問に、順に答えます。
New Relic自体をスクラッチ開発する必要がありますか？
通常は必要ありません。New RelicはSaaS型のオブザーバビリティプラットフォームだからです。
開発の対象は本体ではなく、既存システムへの計装とデータ設計です。ダッシュボードとNRQL、アラートも、開発の対象に含まれます。さらに、チケット連携や運用手順も対象になります。
たとえば、社内固有の申請フローやCMDB連携など、標準機能で足りない部分は、APIや自動化スクリプトで補います。
ZabbixやPrometheusとNew Relicは併用できますか？
併用できます。既存監視はすぐに廃止せず、New Relicは、APMや分散トレーシングに使えます。ユーザー体験やアプリとインフラの関連付けにも使えます。
Zabbixなどは既存ホストの監視に使う構成が現実的です。重複通知を減らすために、正とするアラート、一次対応者、エスカレーション先をサービスごとに決めます。
New Relicのシステム導入にはどのくらいの期間と費用がかかりますか？
1サービスの検証は2〜6週間、小〜中規模導入は1〜3か月が目安です。複数サービスやハイブリッド環境は3〜9か月、全社展開や24時間運用を含むと6〜18か月以上です。
導入支援費は、検証で50万〜200万円、小〜中規模で200万〜800万円、中〜大規模で800万〜3,000万円程度が推定レンジです。
ライセンス料金は、データ量とユーザー数で変わります。保持期間やエディションによっても異なります。そのため、対象範囲を明記して見積もりを取ります。
まとめ：New Relicのシステム導入は段階展開が近道
New Relic導入は、監視ツールを足すだけの作業ではなく、業務改善のプロジェクトです。要件整理から運用定着まで、一つの流れで進めます。
要件整理で事業影響とKPIを決め、選定ではエージェント、OpenTelemetry、既存監視の役割を分けます。設計・開発では、データ規約とアラートを実装します。そのうえで、テスト、稼働、定着へ進みます。
成功させるための要点
導入を成功させるには、対象の選定と効果測定を先に行い、リスク対策や運用体制も整えておきます。
- 段階導入：全社一括ではなく、業務影響が大きく原因調査に時間のかかる1サービスでのPoC
- 効果測定：導入前の原因特定時間、MTTR、エラー率、アラート対応時間、月間データ量を測り、導入後と比べる
- リスク確認：ログの個人情報、APIキー、保存地域、権限、監査、超過料金の設計段階での確認
- 運用定着：ダッシュボードやNRQLで終わらせず、担当者が対応できる手順と教育まで含めた成果物
監視対象とPoCの合格条件を1枚にまとめる
PoCの準備では、対象と合格条件を整理し、発注方式を同じ基準で比べます。
- 対象情報：サービス、利用者、業務影響、構成、既存監視、ログ量、個人情報、担当部署
- 基準値：導入前KPIの記録
- PoC範囲：APMとエラー監視を中心にした1〜2サービスの選定
- 合格条件：原因特定時間、通知適合性、担当者の対応可否、費用予測
条件が明確であれば、内製、支援会社、既存監視との併用を同じ基準で比べられます。導入後の定着にもつながります。
▼全体ガイドの記事
・New Relicのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。