New Relicのシステム開発の発注/外注/依頼/委託方法について

New Relicの発注は、目的と対象範囲を決め、PoCで計装や運用を検証してから、設計・構築と運用移管へ進めます。この流れを踏むと、障害対応や改善につなげやすくなります。

発注形態から委託先選定まで、順に見ていきます。全体像は、New Relicのシステム開発の完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・New Relicのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

New Relicのシステム発注・外注の概要

New Relicの発注・外注では、監視ツールの初期設定に加えて、障害対応や改善につなげる仕組みを設計・構築します。New RelicはSaaS型のオブザーバビリティプラットフォームで、APM、Infrastructure monitoring、Logs、Browser、Synthetic monitoringなどを備えます。

New Relicは、販売管理システムやERPのような業務機能を新規に開発する製品ではありません。

発注する対象は可観測性の仕組み

外注では、可観測性の設計から障害時の運用までを対象に、必要な作業を成果物の単位で決めます。

• 対象整理と計装：監視対象の洗い出し、タグ規約、エージェント・SDKの導入、OpenTelemetryによる計装
• データと可視化：ログ収集、NRQL検索、ダッシュボード、アラート条件、通知先
• 運用設計：SLOと障害時のエスカレーション

業務システム、API、データベースが混在する場合があります。さらに、バッチやキュー、コンテナ、Kubernetesも混在することがあります。クラウドとオンプレミスも混在すると、単純なエージェント導入では運用が回らなくなります。

見積依頼を「New Relic導入」とだけ書くと、会社ごとに作業範囲が変わります。そのため、「本番3サービスのAPMとインフラ監視」「ログはエラー系だけ」「重大度別にSlackとチケットへ通知」のように、成果物の単位で指定します。さらに、運用手順書と引き継ぎ研修まで含めるかも明記すると、見積もりの範囲をそろえられます。

発注前に決める改善目標

導入目的は、ツールの機能名ではなく、業務上どう変わるかで定めます。たとえば、障害検知を早めたい場合は、導入前後で比べる指標も決めておきます。

• 復旧と原因調査：平均復旧時間（MTTR）と性能問題の原因特定時間
• 障害対応：重大障害件数とアラートから一次対応までの時間
• サービス影響：SLO達成率とユーザー影響時間

目的が曖昧なままダッシュボードを増やすと、画面は充実しても誰も見ない状態になりやすいです。参考になる例として、New Relic公式のデンソー事例では、約2万ユーザーの申請承認システムで、熟練エンジニアが3日かけた原因特定を3時間に短縮したと紹介されています（出典: New Relic「デンソー導入事例」、2025年確認）。ただし、これは参考事例であり、同じ成果を保証する数字ではありません。

自社では、PoCの合格条件として検証します。

New Relicの発注形態の選び方

発注形態は、ライセンスと導入支援を分けるか、一括で委託するか、内製と外注を組み合わせるかで選びます。担当者がいる場合は、設計やPoCだけを外注し、日々のNRQL改修やアラート調整を内製できます。

ライセンス販売会社への導入支援の依頼

販売会社へ依頼する場合は、窓口や責任の範囲、料金の管理、支援の範囲を確かめます。

• 窓口と責任：契約、請求、製品問い合わせ、導入作業を同じ会社にまとめやすい
• 利用料の管理：ユーザー数とデータ量を見積もり、予測と上限監視を含める

たとえば、SCSKはライセンス販売に加え、要件定義、設計、構築、テスト、引き渡しまでを公開サービスに含めています。運用、サポート、コンサルティング、教育、PoCも含まれます（出典: SCSK「SCSK Plus サポート for New Relic」、2026年確認）。

支援範囲は販売会社ごとに異なるため、サービス名だけで判断せず、作業項目と成果物を確かめます。

システムインテグレーターへの一括外注

複数の業務システムや監視環境が混在し、運用設計も見直す場合は、一括外注が選択肢になります。

• 対象となる環境：業務システム、オンプレミス、AWS・Azure、Zabbix・Prometheusの混在
• まとめて管理する作業：監視設定、ネットワーク許可、リリース、審査、障害管理、既存ベンダー調整

一括契約では、ライセンス費、導入SI費、月次運用費、24時間対応費が一つの金額にまとまり、比較しにくくなります。そのため、RFPでは利用料と作業費を分け、対象外の作業を明記します。さらに、契約終了時にダッシュボード、NRQL、IaC、手順書を返却することも指定します。

PoCや専門領域の外注と内製の組み合わせ

運用チームがある企業では、専門領域だけを外注し、本番展開と日常運用を内製できます。

• 外注する領域：PoC、OpenTelemetry設計、複雑な分散トレース、セキュリティ設計
• 標準化：ダッシュボードを整え、外部の知見を取り入れる
• 内製に残す運用：本番展開や日常運用を通じ、NRQLやアラートの知識を蓄積

内製と外注の境界が曖昧だと、障害時に誰が確認し、誰が設定を変えるのか分からなくなります。そのため、RACIのような責任分担表を作り、担当者を契約書と運用設計書の両方に記載します。

• 障害対応：一次対応と原因調査
• システム変更：New Relic設定変更とアプリ修正
• 継続管理：ライセンス管理と月次レポート

RFPと要件整理の内容

RFPは、自社のシステムと運用課題を委託先が同じ条件で理解するための資料です。対象範囲、現状、目標、制約を書き出し、そのうえで成果物、日程、費用の分け方、提案書の形式をそろえます。

現状のシステムと監視範囲の一覧

見積もりの前提をそろえるため、システムと監視の現状を一覧にします。

• システム情報：サービス名、URL、担当部署、言語、実行環境、クラウド・オンプレミス、DB
• 構成と負荷：外部API、バッチ、キュー、コンテナ、Kubernetes、ピークトラフィック、稼働時間、重要度
• 既存監視：Zabbix、Prometheus、Grafana、クラウド監視、ログ基盤、チケット管理と通知経路

一覧がないと、サービス数や計装作業、ネットワーク設定、テストケースが定まりません。そこで、全システムではなく、業務影響が大きく調査に時間がかかる1〜2サービスをPoCの候補にします。

RFPに含めるデータ量とセキュリティ条件

料金とリスクは、ホスト台数に加えて、データ量やセキュリティ条件から見積もります。よって、これらをRFPに含めます。

• データ量：月間ログ・メトリクス・トレース量、保持期間、サンプリング率、属性数
• 環境と利用者：開発・検証・本番の環境数、ユーザー種別、将来のサービス増加
• 試算と管理：月間量、繁忙期の増加幅、ログ削減設計、請求額確認用ダッシュボード

セキュリティ条件には、パスワード、アクセストークン、カード情報、個人情報をログに出さないことを書き入れます。さらに、マスキングや難読化、APIキーの保管とローテーション、SAML SSO、MFA、RBAC、監査ログも対象になります。

保存リージョンと外部通信の許可先も記載します。SOC 2 Type 2などの認証があっても、全機能や全データが同じ認証範囲に入るとは限りません。そのため、対象サービスと保存条件を個別に確かめます。

成果物とPoCの合格条件

「設定一式」とだけ書くと納品時に認識がずれやすいため、成果物を具体的に書き出します。

• 設計と計装：監視設計書、サービスマップ、タグ・命名規約、計装設定、OpenTelemetry設定
• 監視設定：NRQL、ダッシュボード、アラート一覧、通知連携、権限設計
• 運用引き継ぎ：テスト結果、手順書、障害対応フロー、教育資料、コード化設定、引き継ぎ記録

PoCでは、トレースの確認、性能劣化の再現と原因特定、重大度別の通知、誤検知への対応、月間の取り込み量と費用の予測を確かめます。画面が表示されるかより、担当者が実際の障害シナリオを解決できるかで判断します。

New Relicのシステム発注の進め方

発注後は、要件整理、限定的なPoC、設計・計装、テスト、本番展開、運用移管の順に進めます。New Relicは、データを送信した時点で業務運用が完成するものではありません。そこで、各工程の判断者、確認する内容、残す資料をあらかじめ決めておきます。

企画とPoCによる小規模な検証

PoCは、事業上の重要度と現在の障害対応時間を踏まえて、対象を絞って行います。

• 対象と構成：最重要の1サービスまたは2サービスを選び、APMとInfrastructure monitoringを基本にする
• データと既存監視：必要なログ・分散トレースを加え、Zabbixなどはすぐに捨てず補完する
• 計装方式：OpenTelemetryと、言語別のNew Relicエージェントを比較する
• 動作確認：通常時、遅いAPI、DB待ち、外部API遅延、エラー、通知、一次切り分けを試す

OpenTelemetryは、トレース、メトリクス、ログを扱う標準仕様です。また、New RelicはOTLPエンドポイントでデータを受け取れます（出典: New Relic公式OpenTelemetryドキュメント、2026年確認）。将来の監視基盤の変更や複数ツールの併用を考える場合は、方式を選んだ理由を設計書に残します。

設計・計装・ダッシュボード構築

本番展開では、タグを標準化し、サービスマップとダッシュボードを同じサービス単位で設計します。

• タグ：サービス名、環境、地域、チーム、リリース版、顧客区分、重要度
• 可視化：アプリ、データベース、インフラ、ユーザー体験を同じサービス単位で表示
• アラート運用：重大度、通知先、営業時間、抑制、一次対応、エスカレーション、復旧確認、ポストモーテム

タグの付け方がばらばらだと、複数のサービスをまたいだ検索や、チーム別の費用分析が難しくなります。アラートを増やしても安心にはつながりにくいため、担当者が対応できる数に絞ります。そのうえで、エラー率、レイテンシ、SLOなど事業影響に近い指標を優先します。

テストと本番展開後の運用移管

本番前の確認と運用移管を段階的に行います。

• データと監視：欠落、マスキング、権限、アラート重複、通知先をテストする
• 本番への影響：性能や再起動を確認し、安全に障害を再現できるテスト環境を使う
• 知識の移管：設定、NRQL、画面、アラート、費用確認、障害対応を自社担当者へ引き継ぐ
• 運用への定着：演習、月次データ量レビュー、変更申請、契約終了時の返却を組み込む

本番では、無理に負荷をかけないようにします。

New Relicの外注の契約形態

契約形態は、作業範囲と変更の多さで選びます。PoCや標準化された初期構築は請負が合い、調査しながら範囲を決める支援や継続改善は準委任が合います。

ライセンス、初期導入、保守運用を一つの契約にまとめず、責任と費用の単位を分けると比較しやすくなります。

請負契約の成果物と検収条件

請負契約では、成果物と検収条件を具体的に定めておきます。

• 納品物：監視設計書、計装設定、ダッシュボード、アラート一覧、テスト仕様書、運用手順書
• トレース検収：対象3サービスで指定したトレースを確認できる
• 通知と安全性：重大度1の通知が指定先へ5分以内に届き、マスキングテストに合格する

PoCで対象サービスが増えたり、セキュリティ審査で保存条件が変わったりすると、当初の範囲を超える可能性があります。そのため、変更管理、追加作業の単価、納期への影響、発注者の承認者を契約前に決めておきます。

準委任契約の作業時間と役割

準委任契約では、作業時間や役割、作業結果の残し方を定めておきます。

• 支援内容：調査、設計レビュー、設定変更、定例会、教育、障害時の技術支援
• 稼働条件：月の時間、対応可能な曜日・時間、緊急連絡、未消化時間の扱い
• 結果と管理：定例レポート、変更承認者、設計書、設定一覧、議事録、課題一覧

要件が未確定の段階や既存監視との共存を検証する場面には適しています。ただし、成果物や完了条件が曖昧になりやすいため、注意が必要です。

運用契約の対応時間と除外範囲

運用委託では、24時間365日の監視なのか、平日営業時間のリモート支援なのかを区別します。

• 監視と調査：アラート一次受信、原因調査、障害報告、再発防止策
• 変更作業：アプリ修正、クラウド設定変更、NRQL改修、ダッシュボード追加
• 運用支援：ユーザー連絡、ライセンス管理、費用分析、教育

「保守費用」に設定変更の回数などが含まれるかで、価値は変わります。さらに、応答時間や復旧時間の目標を入れる場合は、アプリ開発会社やクラウド事業者の責任範囲も整理しておきます。

New Relicの発注・外注費用の相場

発注費用は、ライセンス、導入設計・構築、連携開発、教育、保守運用に分けて考えます。国内の導入支援には、一律の公式価格が公開されていません。

以下に示す日本円のレンジは、業務システムのSI人件費、対象範囲、データ量、運用体制に基づく企画段階の推定です。これは市場の定価ではなく、契約前に個別見積もりで検証する予算枠として使います。

データ量とユーザー種別で分けるライセンス費の試算

公式料金ページでは、次の無料枠が案内されています（出典: New Relic「Transparent Pricing」、2026年8月確認）。

• データ量：月100GBのデータ取り込み
• ユーザー：フルプラットフォームユーザー1人、基本ユーザーは無制限
• 保持期間：標準で少なくとも8日間
• Synthetic checks：500件

100GBを超える取り込みは、通常データが1GBあたり0.40米ドル、Data Plusが1GBあたり0.60米ドルです（出典: New Relic「Transparent Pricing」、2026年8月確認）。

料金はホスト台数だけでなく、ユーザー数やデータ取り込み量などを軸に計算されます。

• 取り込み管理：ログレベル、サンプリング、属性、保持期間、環境別の送信量

日本円での予算は、為替、税、エディション、追加機能、契約期間、ボリュームディスカウントによって変わります。

規模別に見る導入・設計・構築費

検証対象の規模や監視範囲によって、費用と期間の目安は変わります。

• 1サービス検証：無料枠を使い、50万〜200万円程度、2〜6週間
• 小〜中規模：APM、Infrastructure、基本ログ、アラート、画面を含み200万〜800万円程度、1〜3か月程度
• 中〜大規模：複数サービス、分散トレース、SLO、CI/CD・チケット連携、オンプレ併用で800万〜3,000万円程度、3〜9か月程度
• 全社・大規模：ハイブリッド環境、24時間運用、ガバナンス、複数アカウントで2,000万〜1億円超、6〜18か月以上の可能性

小〜中規模の金額と期間は、対象数、既存監視、セキュリティ審査の有無で変わります。これらはリサーチノートに基づく推定で、特定企業が提示する定額ではありません。

ランニングコストの保守範囲とデータ増加

運用費とデータ増加の見積もりは、次の条件をそろえて比べます。

• 運用費の目安：初期SI費の年15〜25%程度で仮置きする考え方がある
• 保守の範囲：24時間監視、一次対応、NRQL改修、設定変更、月次報告、教育、ライセンス管理
• 費用比較：日中の技術相談と深夜の通知・復旧を同じ保守費として扱わない
• データ増加：月間量の基準、増加単価、超過通知、削減支援を確認し、12か月分で比較

導入費と月額の運用費は分けて考えます。無料枠を超えると、データ取り込みへの課金が発生します。

New Relicの委託先選定と見積比較

資格者数だけでなく、自社のシステム構成と導入目的に合う委託先を選びます。たとえば、AWS中心の移行、基幹システム、オンプレミスとの共存、アプリ開発、セキュリティ審査、運用移管のうち、どれが得意かを確かめます。

同じ条件のRFPをもとに、2〜3社から提案を受けます。

自社の環境に近い実績と担当体制

実績の条件と、実作業を担う体制とを照らし合わせて見ます。

• 実績の条件：構成、ユーザー数、データ量、障害、既存監視、担当工程、運用期間
• 実作業の体制：PM、設計、計装、運用を担当する人の役割と経験

2025年9月時点のNew Relic国内パートナー資料には、企業別の有資格者数が掲載されています（出典: New Relic「国内パートナー企業別 有資格者数」、2025年9月）。有資格者数は比較の材料になりますが、集計時点の所属を保証するものではなく、資格をまたいだ重複者を含む可能性もあります。

資格保有者が提案だけを担当し、別チームが実作業を行う場合もあります。そのため、人数だけで順位を付けず、提案担当者が案件に参加するかを確かめます。

同じ費目に並べ替えた見積書の比較

作業項目をそろえると、見積額のどこに差があるかを確認できます。

• 設計・構築：ライセンス、要件定義、監視設計、エージェント・OpenTelemetry導入
• 監視と品質：ログ・トレース、NRQLとダッシュボード、アラート・通知、セキュリティ、テスト
• 運用移管：文書、教育、運用費、PM費

要件定義や運用移管が別料金になっていると、安く見える提案でも総額は変わってきます。提案書には、前提条件や対象外の作業、作業時間、納期、体制を記載してもらいます。さらに、再委託、追加変更の単価、旅費、税、更新、終了時の返却物も書いてもらいます。

比較は、データ量増加、ユーザー追加、保持延長、24時間対応を含む3年程度の総保有コストで行います。ライセンス割引の大きさは、その一部にすぎません。

提案時に確認する運用と引き継ぎ

運用と返却の条件は、担当者や時間まで具体的に質問します。

• 障害対応：「本番障害時、最初の15分で誰が何を確認しますか」
• 監視と情報管理：「誤検知を減らす方法は」「月間量の確認画面は」「個人情報混入時の対応は」
• 設定と終了：「計装方式の選択基準は」「終了時に設定とクエリを何で返しますか」

回答に担当者、時間、成果物が示されるかを確かめます。教育方法も確かめます。SCSKの公開サービスのように、導入、運用、技術サポート、コンサルティング、教育を分けて提供する会社もあります。

必要なのが24時間の運用代行、月数時間の技術相談、担当者向けハンズオンのどれなのかを決め、該当するサービスを見積もりに含めます。

New Relicの発注で起こりやすい失敗と対策

可視化の範囲を広げるほど、費用と運用の負荷が増える可能性があります。

• 一斉導入：全システムへ一度にエージェントを入れる
• データ過多：ログを無制限に送る
• 運用の偏り：アラートを増やし、設定を外注先任せにする

発注側は、小さく始める条件と、運用を内製へ戻す条件をあらかじめ決めておきます。

データ漏えいと予算超過の防止

データ漏えいと予算超過を防ぐため、送信・保管と費用管理のルールを決めます。

• 機微情報の確認：メール、顧客ID、認証・決済情報、リクエスト本文がログに混ざる場合がある
• 送信と保管：フィルタリング、マスキング、難読化、収集対象、保存地域、権限、APIキーを管理し、テストで確認
• 自動難読化の限界：公式料金ページはログの自動難読化やData Plusの追加機能を案内するが、自社固有情報がすべて自動で除去されるとは限らない
• 費用管理：月次量、無料枠アラート、ログレベル、サンプリング、保持期間を見直す

発注側は、想定の何倍でレビューするか、設定変更者や費用増加を止める判断者も決めておきます。

アラート疲れと属人化の防止

アラート疲れと属人化を避けるには、通知の基準と設定の管理者を定めます。

• 通知量と担当：重大度、所有者、営業時間、通知先、抑制、期限を定め、当番が処理できる量かPoCで確認
• 検知条件：しきい値に加え、ユーザー影響、エラー率、レイテンシ、SLO違反を重視
• 設定の属人化：所有者、レビュー、変更履歴、IaC・エクスポートの保管先、研修を決める
• AI機能の利用：人が調査結果を確認してから復旧し、機密情報をプロンプトやログに含めない

New Relicのシステム発注・外注でよくある質問

発注の目的は、データを安全に集め、必要な人が判断できる状態を作ることです。よくある質問に答えます。

New Relicの導入はスクラッチ開発と同じですか？

New RelicはSaaS型のオブザーバビリティプラットフォームで、既存システムへの計装、データ設計、可視化、アラート、運用連携が発注の中心です。そのため、スクラッチ開発とは中心になる作業が異なります。

独自開発は、社内ポータルとの連携、固有のダッシュボード、運用の自動化、申請フローなどに絞るのが基本です。

最初から全システムへ導入したほうがよいですか？

全システムへ一度に導入せず、業務影響が大きく、原因調査に時間がかかる1〜2サービスでPoCを行います。原因特定の時間、アラートの精度、担当者の対応時間、データ量と費用を確かめてから段階展開すると、安全に進められます。また、既存のZabbixなどを補完しながら、移行の必要性を評価できます。

発注費用はどのように予算化すればよいですか？

ライセンス、導入設計・構築、連携、教育、保守運用に分けて、PoCと本番展開は別々に見積もります。

小〜中規模の導入費は200万〜800万円程度、中〜大規模は800万〜3,000万円程度を、企画段階の推定レンジとして使えます。公式の定価ではありません。

対象サービス、データ量、保持期間、運用時間を示したうえで、2〜3社へ同じ条件の見積もりを依頼します。

委託先には何を質問すればよいですか？

質問するのは、自社に近い構成の実績、実作業の担当者、PoCの合格条件です。加えて、ログのマスキング、月間の取り込み量、アラート設計、既存監視との共存についても確かめます。

24時間対応の範囲、教育、契約終了時の設定返却も確かめます。価格だけでなく、運用の知識が自社に残るか、費用の増加を管理できるかも見ます。

まとめ

New Relicの発注では、初期設定にとどまらず、既存システムの可観測性を設計して、障害対応や改善につなげる仕組みを委託します。

発注形態は、販売会社への一括依頼、SI会社への導入・運用委託、PoCや専門領域の外注と内製の組み合わせの中から、自社の体制に合わせて選びます。

発注前に揃える対象範囲・データ量・成果物

RFPには、対象サービスと現行の監視、目的とKPIを記載します。さらに、ログ・トレース量、個人情報、保存リージョン、連携先についても書き入れます。また、PoC合格条件、契約形態、検収条件も添えます。

見積書はライセンス、導入、連携、教育、保守運用に分け、前提条件と対象外をそろえて比較します。

小さな検証と段階展開

1〜2サービスでPoCを行い、原因特定時間、アラート精度、担当者の対応、データ量、請求額を確認してから段階展開します。

公式価格と国内SI費の推定は、分けて考えます。ログ削減、権限管理、教育、月次レビューまで含めて委託先を選ぶことが、発注の失敗を防ぎます。

▼全体ガイドの記事
・New Relicのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。