5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

New Relic Browser Monitoring × コーディング Agent でシステム活用度の可視化を自動化した話

5
Last updated at Posted at 2026-08-05

はじめに

SPA(Single Page Application)形式で構築されたアプリケーションに対して、カスタムイベント差し込みを実際のプロダクトで進めた経験をもとに、手作業 → Prompt → Agent と段階的に自動化していった流れをまとめました。

Browser Monitoring とカスタムイベント

New Relic の Browser Monitoring は、ブラウザ上で動作する Web アプリケーションのパフォーマンスやユーザー行動をリアルタイムに計測・可視化する機能です。ページロード、Ajax、JS エラーなどは自動収集されます。

一方 カスタムイベント は、アプリケーション固有の操作を自分たちで定義して記録する仕組みです。「どの画面で」「どのボタンが」「どれだけ押されたか」を自由な粒度で取得できます。

参考:https://newrelic.com/jp/platform/browser-monitoring

課題:SPA ではサーバーログだけで利用状況を追えない

SPA はページ遷移が発生しないため、サーバーサイドのアクセスログでは「ユーザーがどの画面でどんな操作をしたか」を把握できません。システムの活用度を可視化するには、クライアントサイドで操作を捕捉する必要があります。

ただし、カスタムイベントの差し込みは画面ごとに手作業が必要で、画面数が多いとスケールしません。ここでは 3 つの Step で段階的に自動化した方法を紹介します。

Step 1:カスタムイベントを差し込む

設計方針

すべてのボタンに一律で仕込むのではなく、ビジネス上意味のある操作(登録・更新・検索など)に絞ります。

差し込み方法はいくつか考えられますが、自分たちのプロジェクトでは 既存の onClick などのアクションを薄いラッパー関数で包み、カスタムイベント送信を差し込む方式 を採りました。

ポイントは以下のとおりです:

  • 元の処理ロジックには手を入れない
  • ラッパーが「イベント送信 → 元の処理を実行」の順で呼ぶだけ
  • 呼び出し側で対象を選べるので、全ボタンに一律で仕込む必要がない

共通コンポーネント自体に計測コードを埋め込む方法もありますが、全ボタンに差し込みたいわけではなかったため、呼び出し側で必要な箇所だけを選んでラップする方が制御しやすい、という判断でこの方式を採っています。


Step 2:AI Prompt で差し込み作業を自動化する

画面数が増えてくると、手作業の繰り返しがボトルネックになります。差し込み作業にはパターンがあるので、画面を指定すればカスタムイベントの差し込み箇所を提案してくれる AI Prompt を作成しました。

Prompt のフロー

Phase 1: 対象画面の特定
  │  画面ファイルと対象範囲を指定
  ▼
Phase 2: 差し込み候補の提案(コード未修正)
  │  画面コードを解析し、候補を一覧で提示
  ▼
Phase 3: 人による採否判断
  │  採用 / 除外 / 修正を指示
  ▼
Phase 4: 採用分をコードに反映
  │  マッピング定義 → ドキュメント → 画面コンポーネント
  ▼
Phase 5: 結果サマリの表示

Phase 2 まではコードを一切編集しない設計です。提案内容を人間が確認してからコードに触るので、安全に運用できます。

効果

Prompt さえ渡せば、New Relic の実装に関わっていなかったメンバーでも差し込み作業ができるようになります。推進担当に依存しない体制が作れるのがポイントです。

Step 3:コーディング Agent(実装オーケストレーター)に組み込む

Step2がチームに展開された後、開発チームで実装からプルリクエスト発行まで一気通貫で行う 自動実装エージェント基盤 を構築していました。
そこで Step 2 の Prompt を自動実装エージェントに組み込みました。

Step 2 では人が確認していたのに、なぜ省略できるのか

Step 2 の運用を重ねると、既に差し込み済みの実装コードや差し込み箇所をまとめたドキュメントがリポジトリに蓄積されていきます。Prompt はこれらをコンテキストとして参照するため、画面数が増えるほど提案精度が上がります。

精度が十分に高くなれば、都度の確認は不要になり、プルリクエストのレビュー時にまとめて確認すれば済むようになります。

オーケストレーター組み込み後のフロー

オーケストレーターが Prompt を呼び出し
→ 差し込み箇所を自動判定・実装
→ プルリクエストの説明に差し込み内容を記載
→ 人間はレビューするだけ

まとめ:段階的に自動化するアプローチ

Step やること 仕組み 誰がやるか
Step 1 カスタムイベントの差し込み Wrapper 関数 推進担当が手動
Step 2 差し込み箇所の提案と反映 AI Prompt 誰でも(人が最終確認)
Step 3 実装〜プルリク発行 実装オーケストレーター Agent(人はレビューのみ)

カスタムイベントの差し込みは定型作業なので、Prompt や Skill として切り出せば段階的に自動化できます。地道な手作業から始めて、パターンが見えたら Prompt 化、精度が上がったタイミングで Agent に組み込んだ——という話でした。

本ブログに掲載している内容は、私個人の見解であり、​
所属する組織の立場や戦略、意見を代表するものではありません。​
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。

5
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?