トップ > New Relic > エンジニアの"消耗"を終わらせる——New Relic Advance 2026 の全アップデートを整理する

エンジニアの"消耗"を終わらせる——New Relic Advance 2026 の全アップデートを整理する

New Relic New Relic Advance 2026
記事タイトルとURLをコピーする

みなさんこんにちは。マネージドサービス課の塩野です。

2026年2月24日、New Relic は年次アップデートイベント「New Relic Advance 2026」を開催し、多数の新機能・強化機能を一挙に発表しました。今回の記事はアップデート内容についてとりあげ、具体的にどのようなメリットがあるのかご紹介いたします。

エンジニアの"消耗"を終わらせる——New Relic Advance 2026 の全アップデートを整理する

はじめに

今回のアップデート全体を貫くキーワードは「Observability Beyond Human Scale（人間のスケールを超えた可観測性）」です。生成AIやコーディングアシスタントの普及により、ソフトウェア開発のスピードは急激に加速しています。IDCの予測では、今年だけで5億を超えるアプリケーションが新たに構築されるとされており、これは過去40年分の合計に匹敵する数だといいます。

しかし、この爆発的な開発速度は同時に、システムの急速な複雑化というひずみも生み出しています。New Relicの2026 AI Impact Reportによると、エンジニアは依然として週の33%もの時間を手作業による障害対応やツールの行き来といった「運用上の消耗」に費やしているのが現実です。

このような状況を変えるべく、New Relic Advance 2026では「ビジネスとシステムの接続」「AIによるインシデント対応の自動化」「オープンなAIエコシステムへの対応」「コスト効率の改善」という4つの軸で大規模なアップデートが行われました。本記事では、それぞれのアップデートが何を解決するのか、SREエンジニアの視点から整理して解説します。

1. ビジネスとシステムをつなぐ可観測性

1-1. Intelligent Workloads：ビジネスKPIと技術メトリクスを一体化

SREの日常でよく直面するのが「システムのダッシュボードは全部グリーンなのに、ビジネス側からクレームが来る」という状況ではないでしょうか。CPUやメモリの数値は正常でも、チェックアウトAPIが静かに失敗していれば、ユーザーへの影響は深刻です。

Intelligent Workloads（プレビュー公開中）は、この「技術指標とビジネス成果の乖離」を埋めるための新機能です。マイクロサービス化が進んだ現代のシステムでは、1つのビジネストランザクション（例：購入完了フロー）が数十のサービス、データベース、インフラコンポーネントにまたがっています。Intelligent Workloadsはこの依存関係をAIが自動検出・マッピングし、「このトランザクションに関係するすべてのコンポーネント」を一覧で把握できるようにします。

さらに重要なのが、ビジネスKPIとの連携です。特定のトランザクションを「Focal Transaction（フォーカストランザクション）」として設定すると、そのパフォーマンス低下が「カート離脱数◯件」「毎時◯万円の売上リスク」といった形で数値化されます。エンジニアが「レイテンシが500ms上昇した」と報告するのではなく、「チェックアウトサービスの遅延で、現在15%のユーザーに影響が出ており、時間あたり5万円の収益リスクがある」と話せるようになるわけです。

また、ネストされたワークロードの健全性シグナルが上位レイヤーに「バブルアップ」する仕組みも特徴的です。決済サービスの下位にある小さなマイクロサービスが障害を起こしたとき、その影響がトップレベルの「チェックアウトワークロード」のステータスにも即座に反映されます。今まで深い場所に隠れていた障害が見えにくかった問題を解決するアプローチです。

1-2. Digital Experience Monitoring（DEM）：マイクロフロントエンド対応の強化

ユーザーが最初にシステムと触れるのはフロントエンドです。近年は「マイクロフロントエンド（MFE）」と呼ばれるアーキテクチャが増えており、1つのWebアプリが複数のチームが管理する小さなコンポーネントで構成されています。

このアーキテクチャでは「どのコンポーネントが問題を起こしているか」を特定するのが非常に困難です。New RelicはDEMソリューションを強化し、MFEの各フラグメント（コンポーネント）単位でパフォーマンスタイミング、エラー発生数、レンダリング回数といったメトリクスを収集できるようになりました。あるコンポーネントの小さな不具合が、他のコンポーネントにどう連鎖するかの上流・下流の影響も把握できます。「どのチームの担当コンポーネントが原因か」を素早く特定できるため、解決までの時間を大幅に短縮できるでしょう。

1-3. New Relic Lens：外部データソースとの横断クエリ

「このAPIのレイテンシ上昇が、実際の顧客ロイヤルティにどれくらい影響しているか」——この問いに答えるには、New Relic内のテレメトリデータだけでなく、SnowflakeやPostgreSQL、Google Sheetsなどの外部ビジネスデータが必要です。従来はこうしたデータを別途New Relicに取り込む（再インジェスト）か、手動で別ツールと照合するしかありませんでした。

New Relic Lens（プレビュー公開中）はこの問題を解消します。New RelicのUI上から直接、外部データソースにSQLで接続・クエリが実行でき、テレメトリデータとビジネスデータをクロスデータベースJOINで組み合わせられます。外部データをNew Relicに取り込む必要がないため、インジェストコストも発生しません。

あわせて発表された New Relic Notebooks は、クエリ・グラフ・テキストを1つの共有可能なドキュメントにまとめられる機能です。ポストモーテム（障害後振り返り）の記録や動的なランブックの作成に役立ちます。調査プロセスを複数のタブに散らかすことなく1か所に保存でき、チームへの知識移転がスムーズになるでしょう。

2. AIが主役のインシデント対応

2-1. SRE Agent：インシデントを24時間見守るAIチームメンバー

「アラートが鳴るたびに手作業でメトリクス・ログ・トレースを掘り返す」という消耗感を覚えているSREエンジニアは多いはずです。SRE Agent（プレビュー公開中）はこの状況を変えようとする、今回のアップデートで最も注目すべき機能かもしれません。

SRE Agentは、New RelicプラットフォームにネイティブビルドされたAIエージェントです。単なるチャットボットや質問応答ツールとは異なり、ライブのテレメトリとシステムコンテキストに根ざした上で、インシデント対応の全工程をサポートします。具体的には、システムの動作を継続的に監視し、関連するシグナルやパターンを自動的に浮かび上がらせ、エンジニアが調査すべき場所へ誘導します。

ただし、重要な点として、SRE Agentはあくまでも自動判断ではなく、人間の判断を補助する位置づけで設計されています。本番システムへの変更は行わず、承認フローをバイパスすることもなく、人間の決定を上書きしません。エンジニアの認知負荷を下げながら、コントロールは常にチームが持つ——この設計思想は、SREの現場における信頼性を最優先に考えた結果です。

SlackやZoomとの連携により、トリアージルーム（障害対応の会話）に参加しながら、自動でファクトファインディングや影響範囲の評価を実行します。チームが常に最新の正確なデータに基づいて動けるよう、一元化されたインシデントタイムラインを維持します。

2-2. Intelligent RCA（iRCA）：根本原因を数秒で特定する

従来の根本原因分析（RCA）の問題は、「相関関係」をもとに原因を推測していたことです。あるメトリクスが同時に悪化していたからといって、それが原因とは限りません。エンジニアがログの山を掘り返しながら「これが原因かも？」と試行錯誤する時間が、MTTRを長引かせていました。

Intelligent RCA（iRCA）（プレビュー公開中）は、この課題に「トポロジグラフ」と「確率的因果モデル」を組み合わせることで向き合います。仕組みをシンプルに説明すると、iRCAはシステム全体の構成を「地図」として持っており、アラートが発火したとき、その地図の上に観測された症状を重ね合わせ、パスベースのランキングアルゴリズムで「最も根本原因らしい場所」を数秒で特定します。相関ではなく因果推論を行うため、誤検知（実は症状に過ぎないものを根本原因と誤認する）が大幅に減ります。

Kubernetes Podの設定ミス、データベースのロック、セキュリティ上の脆弱性など、問題の種類を問わず対応できる点も特徴です。SRE Agentと連携して動作し、エージェントが「何を調べるべきか」を素早く絞り込む役割を担います。

2-3. Performance Risks Inbox & Smart Alerts：障害が起きる前に手を打つ

「障害はアラートが鳴ってから対処する」——これが従来の監視の常識でした。しかし、アラートが鳴った時点ではユーザーへの影響がすでに発生しています。

Performance Risks Inbox（プレビュー公開中）は、この常識を変える「予防的なインテリジェンス」機能です。N+1クエリ（1件のリクエストが大量の不要なDBアクセスを引き起こすアンチパターン）、遅いSQLクエリ、過剰なデータベースアクセスといった「サイレントキラー」を、アラートが発火する前の平常時に検出して一覧表示します。深夜の緊急対応ではなく、通常業務の時間帯にコードの品質問題を計画的に解消できるようになるわけです。

対して Smart Alerts（プレビュー公開中）は、アラートそのものの品質を改善します。静的なしきい値に頼る従来のアラートは、トラフィックパターンの変動やシステムの成長とともに「ノイズが多すぎる」「逆に検知漏れが出る」という二律背反の問題を抱えていました。Smart Alertsは過去の動作パターンを学習し、本当に異常な挙動かどうかを判断するため、アラート疲労を軽減しながら検知精度を高めます。また、カバレッジのギャップ（監視されていないエンティティ）を可視化し、「Cover all gaps」ボタン一つで推奨しきい値を一括適用できる機能も含まれています。

機能 役割 主なメリット
Performance Risks Inbox 予防的リスク検出 障害前にコードの問題を発見・計画的に修正できる
Smart Alerts 検知品質の向上 アラート疲労を低減しつつ、重要な検知漏れを防ぐ
iRCA 根本原因の特定 症状と原因を区別し、調査時間をほぼゼロに近づける
SRE Agent 対応支援 認知負荷を下げ、チームの判断を正確なデータで支える

3. オープンなAIエコシステムへの対応

3-1. New Relic Agentic Platform：コードなしでカスタムAIエージェントを構築

New Relic Agentic Platform（プレビュー公開中）は、SREやDevOpsエンジニアがコードを1行も書かずに、ドラッグ＆ドロップのビルダーでカスタムAIエージェントを構築・デプロイ・管理できる仕組みです。

「AIエージェントを作る＝専門的なコーディングスキルが必要」という壁を取り除くことを目指しています。チームが蓄積してきた運用上のノウハウや手順を、そのまま自律的なデジタルワーカーとして再現できます。また、Role-Based Access Control（RBAC）やエージェントのパフォーマンスを評価するための専用エンジンも備わっており、「AIが正しい判断をしているか」をガバナンスの観点から継続的に確認できます。

3-2. MCP（Model Context Protocol）サーバー対応：GitHub CopilotやClaudeとの連携

AIアシスタントを使って開発している際に「New Relicのデータを見たいけどコンテキスト切り替えが面倒」と感じたことはないでしょうか。New Relic MCP Server（パブリックプレビュー公開中）はこの問題を解消します。

MCPはLLMと外部ツールをつなぐオープン標準プロトコルです。New Relic MCP Serverに対応したことで、GitHub Copilot、ChatGPT、Claude、Cursorといった主要なAIアシスタントが、New Relicのオブザーバビリティデータに直接アクセスできるようになります。開発中にCopilotへ「このサービスの直近1時間のエラー率は？」と自然言語で聞くだけで、New Relicのデータを引き出した回答が返ってくる、そんなワークフローが実現します。

3-3. OpenTelemetry ハイブリッドエージェント：既存環境を壊さずに段階移行

OpenTelemetry（OTel）は、テレメトリデータ収集の業界標準として注目が高まっていますが、「既存のNew Relicエージェントで構築したダッシュボードやアラートを作り直すコストが大きい」という移行の障壁がありました。

今回発表された APMハイブリッドエージェントは、既存のNew Relicエージェント内にOTel APIの互換レイヤーを組み込む形で、この問題を解決します。新しく書くコードはOTelの標準仕様で実装しながら、既存のダッシュボードやアラートはそのまま維持できます。一気に移行するのではなく、自分たちのペースで段階的に進められる点が大きなメリットです。

4. コストを抑えながらスケールする

AIが生成するコードやデータ量の増加は、そのままオブザーバビリティのコスト増にもつながります。「データが増えるほど請求が増える」という構造は、観測範囲を広げたいチームにとって悩ましい問題です。

Federated Logs（フェデレーテッドログ）は、Amazon S3などに保存されているログをNew Relicへ再インジェスト（取り込み直し）することなく、直接クエリできる仕組みです。Pipeline Control Gateway（PCG）を経由してローカル環境内にデータを保ったまま、New RelicのUI上で他のテレメトリと横断的に分析できます。データレジデンシー（データ保管場所に関する法的要件）への対応も維持しながら、インジェストコストを削減できるのは実務上かなり嬉しい変化でしょう。

Pipeline Control は、テレメトリのトラフィックコントローラーとして機能します。ノーコードのUIで「安定した本番環境のデバッグレベルログはフィルタリングする」「特定のヘルスチェックメトリクスはサンプリングする」といったルールを設定でき、コストのかかる低価値データを取り込む前に削減できます。監視コストを予測可能な範囲でコントロールし、投資対効果の高いデータだけを保持する運用が実現します。

まとめ

New Relic Advance 2026の発表を改めて振り返ると、各アップデートは「SREがダッシュボードを見ながら手作業で原因を探す」という従来のワークフローからの脱却を強く意識した設計になっています。障害が起きてから対処するのではなく、起きる前に予防し、起きてもAIが即座に根本原因を絞り込み、エンジニアは判断と戦略に集中する——そういうあり方への移行を後押しする内容です。

いずれの機能もプレビュー段階のものが多いため、段階的に試しながら現場の課題に合わせて活用を検討してみると良いでしょう。SREとしての日常をどう変えていくか、ぜひ各機能の詳細情報もあわせてチェックしてみてください。

今回のアップデート早見表

機能名 何が変わるか 主なメリット
Intelligent Workloads ビジネストランザクションの依存関係をAIが自動マッピング 技術障害の売上インパクトを数値で把握できる
DEM（マイクロフロントエンド対応） MFEの各コンポーネント単位でメトリクスを収集 フロントエンド障害の原因コンポーネントを素早く特定できる
New Relic Lens Snowflake・PostgreSQL等の外部データをUI上からSQLで直接クエリ 再インジェスト不要でビジネスデータとテレメトリを横断分析できる
New Relic Notebooks クエリ・グラフ・テキストを1つのドキュメントにまとめて共有 ポストモーテムや調査記録をチームで再利用しやすくなる
SRE Agent インシデント対応をAIがリアルタイムで補助 調査に費やす認知負荷が下がり、MTTRを短縮できる
Intelligent RCA（iRCA） トポロジグラフと因果モデルで根本原因を数秒で特定 「相関があるから原因」という誤判断が減り、誤検知が低下する
Performance Risks Inbox N+1クエリ・遅いSQLなどのアンチパターンを事前に検出 障害が起きる前に平常時の業務として計画的に修正できる
Smart Alerts 過去の動作パターンを学習して異常検知の精度を向上 アラート疲労を抑えつつ、監視カバレッジのギャップも解消できる
New Relic Agentic Platform ノーコードでカスタムAIエージェントを構築・デプロイ コーディングスキルがなくても運用ノウハウをAI化できる
MCP サーバー対応 GitHub Copilot・Claude等のAIツールからNRデータに直接アクセス ツール間のコンテキスト切り替えなしに観測データを活用できる
OpenTelemetry ハイブリッドエージェント 既存のNRエージェントのままOTel標準APIで新規コードを記述可能 ダッシュボードやアラートを作り直さずにOTelへ段階移行できる
Federated Logs S3等のログを再取り込みなしにNRのUIから直接クエリ インジェストコストを増やさずにログ分析の対象範囲を広げられる
Pipeline Control フィルタリング・サンプリングルールをノーコードで設定 低価値なデータを取り込む前に削減し、監視コストを最適化できる

この記事がどなたかのお役に立てれば幸いです。

参考リンク

◆　塩野　正人
◆　マネージドサービス部　所属
◆　X（Twitter）：@shioccii
◆　過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。