New Relic Browserで「もう一段深い分析」をしたいけれど、フロントエンドの改修は避けたい。SSR環境なら、APMで設定したカスタム属性をコード変更なしでBrowserに伝搬できます。今回はその仕組みと注意点を解説します。
この記事は、次のような方を対象にしています。
- New Relic Browser を使い始めたが、分析が標準データの範囲にとどまっている
- カスタム属性に興味はあるが、フロントエンド改修は避けたい
- SSR(Spring / Django / Rails 等)環境を使っている
最新のアップデートの詳細はこちら
New Relic アップデート一覧
無料のアカウントで試してみよう!
New Relic フリープランで始めるオブザーバビリティ!
なぜ「カスタム属性」なのか
New Relic を導入すると多くの情報が自動で可視化されますが、使い続けていくと必ず「システム固有のコンテキスト」で分析したくなります。
カスタム属性は、新しい指標を増やすものではなく、「既に取れているデータを、違う角度から見るためのレンズ」 です。
- まずは、付けられるところ(APM側)から付けてみる
- SSRの特性を活かして、ノーコードで Browser に流してみる
- 見てみて、足りなければフロントエンドの実装を検討する
最初からフロントエンド・バックエンド横断の完璧な設計をする必要はありません。今回紹介する「APM → Browser 伝搬」は、その最初の一歩をコード変更なしで踏み出せる強力な選択肢です。
※ 本記事でいう「コードを変えずに」とは、フロントエンド(Browser)のコードを変更せずに、という意味です。
APM 側の設定変更や、必要に応じた最小限の API 呼び出しは行います。
カスタム属性=コード変更 だと思っていませんか?
New Relic を導入して分析を進めていく中で、「もう少し踏み込んだ分析をしたい」と感じる場面は多いと思います。
- 「どのユーザー(会員ランクなど)で遅いのか知りたい」
- 「特定の条件(キャンペーン中など)のときだけ問題が起きていそう」
- 「全体平均ではなく、属性ごとにもう一段深く見たい」
そう考えたときに出てくる解決策が 「カスタム属性」 です。
一方で、カスタム属性と聞くと次のような不安も浮かびがちではないでしょうか。
- ❌ フロントエンドのコードを変更しないといけないのでは?
- ❌ バックエンドとフロントエンドの両方に手を入れて連携させる必要があるのでは?
- ❌ どこまでやれば正解なのか分からず、設計が難しい
特に Browser(フロントエンド)領域まで含めて考え始めると、「ちゃんと設計してからやろう」と後回しになりやすいテーマでもあります。
この記事では、SSR(Server Side Rendering)環境において、APM(サーバーサイド)で設定したカスタム属性をフロントエンドのコードを一切変更せずに Browser の分析に持ち込む方法と、その挙動・注意点を紹介します。
Browser を高度に使いこなすことが目的ではありません。カスタム属性に踏み出すための「最初の一歩」を、最も低コストに踏み出すための選択肢です。
カスタム属性はどこで「設定」するのか
Webアプリケーションにおいて、分析に必要な重要なコンテキストの多くは、リクエスト処理(サーバーサイド)の段階で確定します。
- 誰がアクセスしているか(会員ランク、企業ID)
- どのビジネス条件か(キャンペーン適用中、決済金額)
- どの機能が有効か(A/Bテストのグループ、機能フラグ)
これらは「バックエンドの処理状況」を示すだけでなく、「ユーザーがどのような体験をしているか」 を定義する情報そのものです。
なぜ APM で設定するのか
通常、これらの情報をブラウザ分析(Browser)で使うには、フロントエンドのコードで変数を取得し、APIにセットする実装が必要です。
しかし、SSR(Server Side Rendering)環境では、「サーバーですでに設定している情報」 を、HTML 生成時にそのままブラウザへ引き渡す(伝搬させる)ことができます。
つまり、
「フロントエンド分析で欲しい情報を、コードを変更することなく、APM(サーバー)経由で注入する」
というのが、この手法のメリットです。
Browser に「伝搬する」とはどういうことか
SSR 環境では、APM Agent によって Browser Agent(の JavaScript スニペット)が HTML レスポンスに自動注入されます。
このとき Browser Agent は、以下の挙動をとります。
- サーバー側で確定している情報の一部をHTML生成時の初期ロード時のコンテキストとして受け取る
重要なのは、「Browser(クライアント)側のコードで新しく属性を設定しているわけではない」 という点です。
APM で設定したカスタム属性が、SSR の初期ロードのコンテキストとして Browser にそのまま引き渡される。これがこの記事で扱う「伝搬」です。
重要:自動注入(Auto Instrumentation)の対応状況
この記事で紹介している「HTML への自動注入」機能は、利用している APM エージェント(言語)によって対応状況が異なります。
1. 自動注入に対応している言語
以下の言語エージェントは、デフォルトで HTML レスポンスへのスクリプト自動注入に対応しています。基本的には設定ファイルを有効にするだけで導入可能です。
- Java
- .NET
- PHP
- Python
- Ruby
※ ただし、これらの言語であっても、特殊な Web フレームワークや非同期処理を多用する構成では自動注入が機能しない場合があります。
2. 自動注入に対応していない言語(Go / Node.js)
以下の言語エージェントは、アーキテクチャの特性上、自動注入(HTMLの書き換え)には対応していません。
- Go
- Node.js
これらの言語で SSR 環境のカスタム属性伝搬を行いたい場合は、APM Agent の API を使用した手動挿入 が必要になります。
解決策:APM API を使って手動挿入する
「コードを変えずに」という本記事の趣旨からは少し外れますが、対応していないフレームワークや Go や Node.js の場合は、HTML テンプレートのレンダリング処理の中で Agent API を呼び出し、生成されたスクリプト文字列を <head> タグ内に埋め込む実装を行ってください。
この実装を行えば、他言語と同様に APM 側の Transaction と Browser 側の Session が紐付き、この記事で解説するカスタム属性の伝搬が可能になります。
参考ドキュメント:APM エージェント経由での手動挿入
各言語ごとの実装方法は、以下の公式ドキュメント(APM エージェントを使用したブラウザ監視のインストール)を参照してください。
Install the browser agent | New Relic Documentation
※ 各言語エージェントの "Compatibility and requirements" ページも併せてご確認ください。
実践1:APM 側にカスタム属性をセットする
Browser にデータを渡すためには、まず APM Agent 自体がそのデータを持っている必要があります。
方法は「設定ファイルで収集する」か「コードで明示的に渡す」かの 2 通りです。
方法A:設定ファイルを使う
〜URLパラメータを自動で取り込む〜
URL のクエリパラメータ(例: ?store_id=123)を収集対象に追加します。
1. newrelic.yml の場合 (Java, Ruby, Node.js, Go 等)
attributes セクションの include にパラメータ名を追記します。
attributes:
include:
- request.parameters.store_id
- request.parameters.campaign
2. newrelic.ini の場合 (Python, PHP 等)
newrelic.attributes.include にスペース区切りで指定します。
newrelic.attributes.include = request.parameters.store_id request.parameters.campaign
方法B:Agent の API を使う
〜バックエンド処理の中で明示的にセットする〜
会員情報や処理結果など、URL には現れない情報を付与したい場合は、バックエンドのコード内で 1 行だけ API を呼び出します。
Java / Node.js / Ruby 等の実装例
// ログインユーザーのランク情報をセット
NewRelic.addCustomParameter("user_rank", user.getRank());
Python / PHP 等の実装例
# ログインユーザーのランク情報をセット
newrelic.agent.add_custom_parameter('user_rank', user.rank)
これで 「APM (Transaction) にカスタム属性が入った」 状態になります。
しかし、これだけではセキュリティの観点から Browser には送信されません。
次のステップで解説する 「Browser への伝搬設定(有効化・Allow List)」 を行うことで、初めてフロントエンドでの分析が可能になります。
実践2:APMの属性をBrowserに渡すための「設定」と「仕組み」
「APM でカスタム属性を付けたのに、Browser 側に表示されない」
これは最初によくあるトラブルです。
実は、APM 側で属性を取得しただけでは、自動的に Browser には送られません。不要なデータや機密情報(PII)が不用意にフロントエンドに露出するのを防ぐため、New Relic Agent には 「フィルタリング」 の機能があるからです。
ここでは、「設定方法」とその「仕組み」を解説します。
1. 必要な設定:browser_monitoring の許可リスト
この「書き出し」を行わせるためには、APM Agent の設定ファイル(newrelic.yml, newrelic.ini など)で、明示的に許可を与える必要があります。
多くの言語Agentでは、デフォルトでカスタム属性の Browser への転送が無効、または制限されています。以下の2段階の設定を確認してください。
① Browser Monitoring への属性転送を有効にする
まずは機能自体を ON にします。
② 送りたい属性を「許可リスト(include)」に追加する
これが最も重要です。セキュリティの観点から、「指定したキー名の属性だけを通す」 という設定にします。
設定例(newrelic.yml の場合):
browser_monitoring:
attributes:
enabled: true # 転送機能自体をON
include:
- user_rank # 転送したい属性キー名を明記
- purchase_status
設定例(newrelic.ini の場合):
[newrelic]
; Browser Monitoring への属性転送を有効化
browser_monitoring.attributes.enabled = true
; 転送したい属性キー名をスペース区切りで指定
browser_monitoring.attributes.include = user_rank purchase_status
フロントエンドのコードを変える必要はありませんが、サーバーサイドの設定ファイルで「通すデータ」を指定する 必要がある点を覚えておいてください。
2. データ伝搬の仕組み:HTMLへの注入
SSR 環境において、APM Agent は HTML レスポンスの <head> 付近に JavaScript のスニペットを自動注入します。これが Browser Agent の実体です。
APM で取得したカスタム属性は、この JavaScript 内の 設定オブジェクト(JSON) の一部として書き込まれます。
<script type="text/javascript">
window.NREUM = {
info: {
"beacon":"bam.nr-data.net",
"errorBeacon":"bam.nr-data.net",
"licenseKey":"NRJS-xxxxxx",
"applicationID":"1403747557",
"transactionName":"NVJX... (暗号化/エンコードされたAPMのトランザクション名)",
// ここにAPMから渡された属性が入る
atts: "SVRB... (暗号化/エンコードされた属性データ)"
},
...
}
</script>
つまり、APM から Browser への伝搬とは、「HTML 生成時に、APM Agent が特定の属性値を JavaScript 変数として書き出す処理」 のことを指します。
検証結果:実際の見え方
では実際にどのようにデータが設定されてどのように確認できるのかをPythonで作成したアプリケーションを使って確かめてみましょう。
APM でのカスタム属性の設定
紹介した2つの方法でバックエンドのアプリケーションのリクエストパラメータをカスタム属性として取得します。今回は設定方法による動作の違いを見るために同じパラメータを取得しています。
下記が&mode=early と &category=CAT008 という2つのパラメータを取得した場合の例です。
caseMode, categoryCodeという属性名になっているのがAPIを利用して登録したカスタム属性でrequest.parameters.で始まる属性名になっているのが設定ファイルで登録したカスタム属性です。
値やクエリの方法に違いはありませんが、属性名(key)を自由に設定できるというのがAPIでカスタム属性を設定する際の利点です。
Browserへの伝搬を確認
カスタム属性の伝搬を確認していきましょう。
下記では Browser Agent が収集する PageView Event で APM と同じカスタム属性を確認しています。
同じ属性名でAPMのデータと同じようにカスタム属性が設定されていることが確認できました。

一方で Core Web Vitals 等のデータを収集している PageViewTiming Event では伝搬させたカスタム属性が設定されないこともわかります。動作比較のために比較対象としてフロントエンド側でコード修正を行って追加したカスタム属性frontendKey は、PageViewTimingのカスタム属性として設定されています。

APMから伝搬させたカスタム属性が Browser Agent が生成するすべての Event データに適用されるわけではないということがわかります。
Browser Agent の Event 種別ごとの伝搬状況
APM から伝搬させたカスタム属性には設定される Event と設定されない Event があるため、その違いを認識してデータを活用する必要があります。
✅ カスタム属性が含まれる Event
下記の Event は APM のカスタム属性が伝搬できる Event データです。
PageViewBrowserInteractionPageActionUserActionCustomEvent
⚠️ カスタム属性が含まれない Event
一方で、次の Event では APM のカスタム属性の伝搬は確認できませんでした。
AjaxRequestJavaScriptErrorPageViewTiming
伝搬されない Event をどう扱うか
「自動で付与されない Event があるなら、分析に使えないのでは?」と思われるかもしれませんが、そうではありません。New Relic には New Relic Query Language(NRQL)という強い武器が存在します。
共通情報で関連付ける(NRQL活用)
多くの Browser イベントには、次のような共通情報が含まれます。
sessionIdpageUrltimestamp
これらをキーにすることで、「PageView で確認したカスタム属性」と「同一ページ、同一セッション内で発生した Ajax や Error」を関連付けて分析できます。
例えば、以下のような NRQL をイメージしてください。
-- 例: 特定の会員ランク(customAttr_Rank)を持つユーザーのセッションで起きたJSエラーを探す
SELECT * FROM JavaScriptError
WHERE session IN (
SELECT session FROM PageView WHERE user_rank = 'GoldMember' LIMIT MAX
)
このように、「すべての Event に属性が付いていなくても、PageView にさえ付いていれば紐付けが可能」 です。「自動で付かない=使えない」ではありません。
まとめ
- SSR 環境のメリット: APM で設定したカスタム属性を、フロントエンドのコードを変更せずに Browser の分析へ持ち込める
-
挙動の理解:
PageView等の Event には自動で伝搬するが、AjaxやJavaScriptErrorには自動付与されない -
運用でのカバー:
sessionId等を使って紐付けることで、十分に実用的な分析が可能
カスタム属性は、完璧な設計を完成させるためのものではありません。
システムの解像度を上げるための入口として、まずは今の環境のままで、軽く触ってみることから始めてみてはいかがでしょうか。
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています!
無料でアカウント作成も可能なのでぜひお試しください!
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう!
New Relic フリープランで始めるオブザーバビリティ!

