なぜ「体感速度」を可視化できないエンジニアは淘汰されるのか：Datadog RUMでUXのボトルネックを外科手術する
フロントエンドのパフォーマンス最適化において、ローカルでのLighthouseスコアを眺めて満足しているなら、それは「砂上の楼閣」を磨いているに過ぎない。現実のユーザーは、劣悪な回線、型落ちの端末、そして複雑な広告スクリプトが跋扈するカオスな環境であなたのアプリを叩いているからだ。
真のテックリードなら、「ユーザーのブラウザ」というブラックボックスを、Datadog RUM（Real User Monitoring）で透視しなければならない。
本稿では、単なる導入手順の解説は捨て、現場で「即座にボトルネックを特定し、チームの共通言語にする」ための実戦的テクニックを叩き込む。
—
1. RUM導入：単なるタグ埋め込みに終わらせない「属性の汚染」を避ける設計
RUMのSDK導入は `npm install @datadog/browser-rum` で終わるが、真の使い手は「初期化のプロパティ」で差をつける。
// datadog-rum-init.js
import { datadogRum } from ‘@datadog/browser-rum’;
datadogRum.init({
applicationId: ‘YOUR_APPLICATION_ID’,
clientToken: ‘YOUR_CLIENT_TOKEN’,
site: ‘datadoghq.com’,
service: ‘my-web-app’,
env: ‘production’,
version: ‘1.2.3’, // ここをCI/CDと連動させるのが鉄則
sessionSampleRate: 100, // 初期は全量採取。ボトルネック特定後に調整する
sessionReplaySampleRate: 20, // セッションリプレイは重い。だがデバッグには神
trackUserInteractions: true, // これを忘れるな。クリックや入力の遅延が全て見える
trackResources: true, // サードパーティAPIの遅延を炙り出す
trackLongTasks: true, // メインスレッドを占有するJS実行時間を可視化
});
【鉄則】: `version` を空にするな。リリース直後の「あれ、遅くなった？」という感覚値を、バージョン間の比較で即座に定量データへ変換できるかどうかが、DevOpsの分かれ目だ。
—
2. Core Web Vitals（CWV）を「ただ見る」から「制御する」へ
Googleの指標をダッシュボードに並べるだけなら誰でもできる。重要なのは、「LCP/CLSが劣化している原因の特定の速さ」だ。
- LCP（Largest Contentful Paint）の真犯人: RUMでLCPの要素を特定し、「それが画像なのか、JSによるレンダリングなのか」を切り分ける。画像なら `fetchpriority=”high”` が効いているか、Datadogの「Resource Waterfall」で検証せよ。
- CLS（Cumulative Layout Shift）の撲滅: RUMの「Long Tasks」と「CLS」を重ね合わせろ。レイアウトシフトが起きる瞬間に、どの非同期処理がDOMを破壊しているか。これを見れば、CSSの `min-height` 欠如なのか、広告枠のロード順なのかが一発でわかる。
—
3. プロの隠しコマンドと設定の「神」プラクティス
① チーム開発で必須の「設定共有ルール」
Datadogの設定は「誰がやっても同じ結果が出る」状態にすべきだ。DashboardのJSON定義をGit管理し、`datadog-api-client` を使ってCIでデプロイする。
// dashboard-config.json (一部抜粋)
{
“title”: “Frontend Performance Overview”,
“widgets”: [
{
“definition”: {
“type”: “timeseries”,
“requests”: [{
“q”: “avg:rum.web.core_web_vitals.lcp{env:production} by {version}”,
“display_type”: “line”
}],
“title”: “LCP by Version (Release Impact)”
}
}
]
}
② 開発スピードを劇的に上げる「神プラグイン・設定」
- Datadog Browser SDK の `proxy` 設定: 社内プロキシや特定のセキュリティ要件でデータが飛ばない場合、自前のエンドポイントを経由させる設定を最初から仕込んでおく。
- Keyboard Shortcut: Datadogの画面で `g` + `d` (Dashboard), `g` + `s` (Service Map) を指に覚え込ませろ。GUIのクリックはエンジニアの敗北だ。
—
4. 現場で震えるほど役立つ「ボトルネック特定」のルーチン
1. 「Long Task」をアラート化せよ: メインスレッドで50ms以上のブロッキングが発生したらSlackに通知を飛ばす。これにより、「ユーザーから報告が来る前に」UX低下を検知できる。
2. Resource Waterfallを「降順」でソート: 読み込み時間が長い順に並べ、一番上のリソースを叩く。大抵の場合、CDNの不調か、巨大すぎるサードパーティスクリプトだ。
3. セッションリプレイを武器にする: 「なぜか特定のユーザーだけでエラーが起きる」という再現性の低いバグに対し、ログだけを追うのは時間の無駄だ。RUMのセッションリプレイで、ユーザーの操作（再現手順）を動画で見て、その瞬間のJSエラーコンソールを重ねれば解決までの時間は1/10になる。
—
最後に：オブザーバビリティは文化だ
Datadog RUMは、ただの「監視ツール」ではない。「ユーザーが体験している現実を、エンジニアが共有するための共有基盤」だ。
「パフォーマンスが悪い」と抽象的な議論をするチームを卒業しよう。「バージョン1.2.3の、特定のAPI呼び出しとメインスレッドの競合が、LCPを800ms押し上げている」と語れるチームへ。
この視点さえあれば、あなたの開発チームは市場で最も高速で、最も堅牢なプロダクトを出し続けることができるはずだ。さあ、今すぐコンソールを開き、RUMのデータを深掘りしてほしい。そこには、まだ誰も気づいていない「成長の余地」が埋まっている。