CoreDash vs Request Metrics

Request Metricsの開発元

Request Metricsは、TrackJSを手がけるチームによって開発されています。Todd GardnerとEric Brandesは、長年にわたり監視ツールを作り続けてきました。プロダクトはシンプルで扱いやすく、サポートにメールを送れば、開発したエンジニア本人が対応してくれます。これは顧客からもよく評価されている点であり、実際にプロダクトを触ってみても納得がいきます。

あらかじめ断っておくと、私はCoreDashの開発者です。Request MetricsにはCoreDashより優れている点もあり、それらについても率直に取り上げます。導入から数ヶ月が経てばCoreDashのほうが優れた選択肢だと今でも確信していますが、チームによってはRequest Metricsこそが最適なツールになります。

Request Metricsが優れている点

最大の強みはLong Animation Framesです。専用のLoAFダッシュボードがあり、インタラクション起因のフレームとスクリプト評価起因のフレームを切り分けることができます。ページ単位やスクリプト単位で内訳を確認でき、実行されたイベントリスナーやsetTimeoutのコールバックまで特定可能です。また、LoAFはページロードのウォーターフォール上にも描画されます。ウォーターフォールでの可視化は非常に合理的です。さらに、DevToolsを開かずにインラインスクリプトを確認できる「Show Code」ボタンまで備わっています（現在のライブスクリプトを取得するため、デプロイ直後などは実際に実行されたコードと異なる場合があります）。LoAFとは何か、なぜINPにおいて重要なのかについては、corewebvitals.ioのLong Animation Frames APIについての記事で解説しています。

requestmetrics.com、2026年10月。

RUMにとどまらない機能も備えています。2025年1月以降、アクセスの多いページを対象に、デスクトップとモバイルで週1回のLighthouseスキャンが実行されます。また、任意の競合サイトの公開オリジンを追加できるCrUXダッシュボードも用意されています。スキャンは何もインストールしなくても開始されるため、初日から確認できるデータがあります。さらにProfessionalプランでは、JavaScriptエラー監視、API監視、トラフィック分析、ファネル、セッションタイムラインも、すべて同じスクリプト1つで利用できます。

要因特定（アトリビューション）も優れています。LCPとCLSの対象要素はCSSセレクターとして取得できるため、DevToolsにそのまま貼り付けられます。また、計測エージェントはTTFBと並んで、LCPの内訳（リソース読み込み遅延、読み込み時間、レンダリング遅延）も収集します。

プライバシーへの配慮も行き届いています。Cookieは使わず、IPアドレスはソルト付きでハッシュ化された後に破棄され、データはカナダに保存されます。Enterpriseプランならセルフホストや専用インスタンスも利用可能です。導入も簡単で、CDNスニペットやNPMモジュールが用意されており、サーバーサイドレンダリングにも安全に対応します。また、コレクターの通信を独自ドメイン経由にルーティングできるため、広告ブロッカーによってビーコンが欠落するのを防げます。ここまで対応してくれるツールは少なく、ビーコンの欠落は現場で実際に頭を悩ませる問題です。

料金体系も明快です。無料プランが用意されているほか、Essentialsプランは年払いで月額34ドルから（ユーザー数無制限）利用でき、超過料金が発生することも一切ありません。

すでにRequest Metricsを導入している場合

その場合、すでに実際の訪問者のデータを計測できていることになります。私が診断するサイトのほとんどは、それすらできていません。そうしたサイトはLighthouseのスコアや、URLグループ単位でしか表示されないSearch Consoleのレポート頼みです。どのような形であれ、RUMを導入しないより導入するほうが確実に良く、Request Metricsは優れた選択肢です。

現状知りたい疑問に答えられているなら、乗り換える必要はありません。RUMツールを移行すると過去の履歴データが失われ、丸一週間ほど移行作業に取られます。そのため、現在のツールで答えが出せなくなって初めて乗り換える価値があります。多くのチームにとって、それは簡単な改善を一通りやり尽くし、より難しい課題に直面するようになってからの話です。

CoreDash vs Request Metrics 一覧比較

料金と機能は2026年9月時点のものです。

運用が進むにつれてCoreDashが優位になる点

データの保持期間

Request Metricsのデータ保持期間は、Essentialsで30日、Professionalで90日です。先週のデプロイによるリグレッションに気づくには十分ですが、ブラックフライデーの後に必ず誰かが尋ねる「去年の11月より速くなったか？」という疑問には答えられません。CoreDashの保持期間は、Starterで6ヶ月、Standardで1年、Studioで3年、Enterpriseで8年です。

トラフィック制限の仕組みも異なります。Request Metricsは分単位でキャパシティを計測し、上限を超えたページビューを破棄します。この仕様はオープンに公開されており、予想外の超過請求が発生しないと保証できる理由でもあります。公式ドキュメントでも、想定トラフィックの1.5〜2倍を契約することが推奨されています。普段は気にならないはずです。しかし大型セールの日にピークトラフィックが破棄されてしまうと、まさに一番確認したかった時間帯のデータが失われます。

トラフィック制限に関するRequest Metricsのドキュメント（2026年10月）。

また、トラフィックが増えるほど価格差は広がります。月間約50万ページビューの場合、Request MetricsのProfessionalは年払いで月額88ドル、データ保持期間は90日です。対するCoreDashのStandardは月額31ドルで、1年分の履歴を保持できます。公平に言えば、ProfessionalにはCoreDashにはないエラー監視、ファネル、アクセス解析が含まれ、Standardが上限10ユーザーであるのに対し無制限です。CoreDashではページビュー数とデータ保持期間に対して料金を支払う形であり、どのプランでもすべてのダッシュボードを利用できます。

INPの各フェーズ

Request Metricsでは、どの要素がINPの対象だったか、キーボード操作かポインター操作か、ページがまだロード中だったかがわかります。便利ですが、わかるのはそこまでです。CoreDashはすべてのINPを入力遅延、処理時間、表示遅延に分解し、LoAFスクリプトURL、入力タイプ、ロード状態と紐付けます。各フェーズを確認すれば、どこを改善すべきかがわかります。入力遅延が長い場合は、訪問者がクリックした際に別の処理（多くはタグマネージャーや同意管理スクリプト）がmain threadをブロックしていたことを意味します。処理時間が長い場合は、自作のハンドラーが遅いことを意味します。表示遅延が長い場合は、その後のレンダリング処理が大きすぎることを意味します。同じINP値のページであっても、必要な改善内容はまったく異なり、対応すべきチームすら分かれることが珍しくありません。

Request Metricsのドキュメントを見る限り、INPのフェーズ分解に関する記述は見当たりませんでした（INPガイドはまだ用意されていません）。INPが最大の課題であるなら、無料トライアル期間中に確認してください。

LCPに関しては、Request Metricsも各サブパートを収集しているため差は小さくなります。ただしCoreDashは、要素タイプに加え、LCP画像がpreloadされていたか、あるいはlazy loadingされていたかも取得します。これはLCPが遅いときに私が真っ先に確認する項目の一つです。さらにDiagnosisダッシュボードが、使用している技術スタックに応じた改善策を提示します。

AIエージェントがfield dataを読み込める

個人的には、これこそが最大の相違点です。Request Metricsには、パフォーマンスデータを外部から読み取るための公開APIが見当たりませんでした。ドキュメントに記載されているAPIはデータ送信用のブラウザエージェントAPIであり、データの取り出しはCSVエクスポートに限られます。もっとも、AIへの対応は早く、2023年にはダッシュボード内で動作するChatGPTベースのアシスタント「Professor Sloth」をリリースしています。

CoreDashには読み取り専用APIがあり、同一のエンドポイントでMCPサーバーも提供しています。MCPサーバーはStarterを含む全プランで利用可能です。Claudeのカスタムコネクターとして追加したり、Claude Code、Cursor、Windsurf、VS Code、Gemini CLIに設定すれば、エージェント自身がfield dataに直接問い合わせを行えます。たとえば「先週と比較して、チェックアウトページのモバイルにおけるp75 LCPをLCP要素ごとにグループ化して提示して」といった指示が可能です。

さらに、MITライセンスの無料エージェントCWV Superpowersも自作しました。このエージェントはCoreDashのデータから最悪のボトルネックを特定し、該当ページでChrome traceを実行した上で、コードの修正内容（ファイル、行番号、diff）やHTMLレポートを提示します。Lighthouseスコアは一切参照しません。その仕組みについては、AIエージェントによるINP改善についての記事で解説しています。

私自身のデバッグ作業の多くは、エージェントがfield dataに問い合わせることから始まります。データがCSVでしか取り出せない場合、どれほどダッシュボードが優れていても、エージェントは何も問い合わせることができません。

エージェンシー向け機能

Request Metricsは、Professionalプランでエージェンシー向けのホワイトラベルレポートを提供しています。自社名義でクライアントにレポートを送りたい場合には便利です。CoreDashはホワイトラベルには対応していません。その代わり、Agency APIを通じてマスターキーを提供し、クライアントプロジェクトの作成・更新・削除や、全プロジェクトにまたがるデータの読み取りを可能にしています。ページビュー枠はクライアント間でプール共有され、請求も1本化されます。レポートは自社で構築し、CoreDashはそのデータを提供する形をとります。詳細はエージェンシー向け料金を確認してください。

Request Metricsを選ぶべきケース

• RUM、JavaScriptエラー、API監視、ファネルを1つのツール、単一のスクリプトでまとめたい場合。エラー監視は長年の実績を持つTrackJSのチームが手がけています。
• 調査の大半をLong Animation Framesに費やしており、専用のLoAFダッシュボードを活用したい場合。
• クライアント向けのホワイトラベルレポートが必要な場合。
• データをカナダ国内に保持する必要がある場合、あるいはセルフホストや専用インスタンスが必要な場合。
• サイト規模が無料プランの範囲内に収まる場合、またはエントリープランでユーザー数を無制限にしたい場合。
• 何もインストールしない段階から、初日でLighthouseスキャンや競合サイトのCrUXデータを確認したい場合。

自社サイトで試す

最も簡単な比較方法は、両方を2週間並行して動かしてみることです。どちらのスクリプトも非同期で読み込まれ、互いに干渉しません。CoreDashの無料トライアルは14日間でクレジットカードは不要、scriptタグ1行またはWordPressプラグインで導入できます。料金プランを確認するか、20分間のデモを予約していただければ、実際のデータを見ながら解説します。

他のツールとの比較については、CoreDashの比較一覧を参照してください。

情報元：Request Metricsの料金、料金ドキュメント、トラフィック制限、LoAFガイド、LCPガイド、CrUXガイド、ブラウザエージェントAPIリファレンス、エンドユーザーデータ、Unified Web Performanceの発表、Professor Slothの発表。エージェントサイズはrm.js v2.4.1で計測。