Developer / Tools

Dev Dashboard で admin の Web Vitals を監視
パフォーマンス計測が「開発の本拠地」に集約

アプリの管理画面パフォーマンスデータが Partner Dashboard から Dev Dashboard へ移動。タブを行き来せず、既存のモニタリングツールと並べて Core Web Vitals を確認できるようになった。コード変更は不要。

このページの構成
  1. そもそも何が変わるのか（30秒で理解）
  2. 移動の全体像 ： データはどこへ行ったか
  3. 見られる 3 つの Core Web Vitals
  4. FID の引退と INP への置き換え
  5. マーチャント／開発者がやること
  6. 確認手順（3ステップ）
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

アプリの admin（管理画面）パフォーマンスデータが、Partner Dashboard から Dev Dashboard へ移動した。
これまで Web Vitals を見るために Partner Dashboard のタブを切り替えていた手間が無くなり、既存のモニタリングツールと同じ場所で確認できる。

これまで ： Partner Dashboard

パフォーマンスを見るために Partner Dashboard 側のタブへ移動。他の開発作業と画面が分断されていた。

これから ： Dev Dashboard

既存のモニタリングツールと同じ Dev Dashboard 上に統合。Web Vitals 確認のためのタブ移動が不要に。

2移動の全体像 ： データはどこへ行ったか

Partner Dashboard 旧 ： admin パフォーマンス画面 ブックマーク URL は 自動リダイレクト 移動 Dev Dashboard 既存モニタリングツール ＋ admin Web Vitals 日次 / 28日間 P75 同じ場所で完結 合否判定 Built for Shopify と同じしきい値 pass / fail App Store 適合性評価 同一データ
ダッシュボードに表示されるのは App Store がアプリの適合性を評価する際に使うのと同じデータ。つまり「自分が見ている数値」と「審査側が見ている数値」が一致するため、ズレなく Built for Shopify 基準を追える。

3見られる 3 つの Core Web Vitals

日次（daily）と 28 日間（28-day）の P75 ロールアップ（上位 75 パーセンタイル集計）を、次の 3 指標について確認できる。

LCP

Largest Contentful Paint
最大要素の描画完了までの時間。読み込みパフォーマンスを測る。

INP

Interaction to Next Paint
操作してから次の描画までの応答性。インタラクティブ性を評価する。

CLS

Cumulative Layout Shift
レイアウトの予期せぬズレの累積。視覚的な安定性を評価する。

各指標には、Built for Shopify 評価で使われるしきい値に基づいた明快な pass / fail ステータスが付く。数値の良し悪しを自分で判断せずとも、合否で一目で分かる。

4FID の引退と INP への置き換え

FID は引退（retired）

First Input Delay（最初の入力遅延）は廃止された。ダッシュボードからも姿を消している。

INP が後継の Core Web Vital に

FID の代わりに INP が Core Web Vital として採用され、ダッシュボードもこの更新を反映している。

FID は「最初の入力に対する遅延だけ」を測っていたのに対し、INP はセッション全体の操作応答性を捉える。インタラクティブ性の実態をより正確に反映する指標へ移行した、と理解すればよい。

5マーチャント／開発者がやること

項目内容
コード変更 不要 アプリの Web Vitals テレメトリはこれまで通り機能し続ける。
旧ブックマーク 自動 Partner Dashboard の admin パフォーマンスページの URL は、自動的に Dev Dashboard へリダイレクトされる。
Distribution ページのリンク 更新済み アプリの「Distribution（配布）」ページのリンクは、新しい場所を指すようになった。
実質的に開発者側の作業は ゼロ。テレメトリの送信は変わらず、見る場所が変わっただけ。古いリンクも壊れずに新しい場所へ案内される。

6確認手順（3ステップ）

1

Dev Dashboard を開く

既存のモニタリングツールがある Dev Dashboard へアクセスする。

2

admin パフォーマンスを開く

LCP / INP / CLS の日次・28 日間 P75 ロールアップを表示。

3
PASS FAIL

pass / fail を確認

Built for Shopify しきい値に基づく合否で、対応の要否を判断。

7技術者が押さえるべき5つのポイント

1. 見る場所が一本化された

パフォーマンスデータが Dev Dashboard に集約され、既存のモニタリングと同じ画面で確認できる。Partner Dashboard とのタブ往復が消えた。

P75

2. 指標は P75 ロールアップ

日次と 28 日間の P75（上位 75 パーセンタイル）集計。単発の外れ値ではなく「大半のユーザー体験」を見る前提で改善を判断する。

3. 合否は Built for Shopify 基準

各指標の pass/fail は Built for Shopify 評価のしきい値準拠。BFS バッジ維持・取得を狙うなら、ここが直接の管理指標になる。

4. FID → INP への移行を反映

FID は廃止、INP が Core Web Vital に。応答性の監視対象とアラート閾値を INP ベースへ切り替える前提でダッシュボードを読む。

5. テレメトリと旧 URL は無改修で生き続ける

アプリ側の Web Vitals テレメトリ送信は従来通りで、コード変更は不要。Partner Dashboard の旧ブックマーク URL は自動リダイレクトされ、Distribution ページのリンクも新しい場所に更新済み。移行作業を組む必要はない。

8業務に活かせる3つのユースケース

USE CASE 1

BFS バッジの維持を「合否ダッシュボード」で定常監視

課題
Built for Shopify を取得済みのアプリで、LCP/INP/CLS が基準を割っていないかの監視が属人化していた。
打ち手
Dev Dashboard の pass/fail と 28 日間 P75 を週次でチェックし、fail に転じた指標を即トリアージするフローを作る。
効果
審査側と同一データを見るためズレが無く、バッジ剥落リスクを早期に察知できる。
技術メモ
合否しきい値は BFS 評価準拠。日次で兆候、28 日間で確定傾向、と粒度を使い分ける。
応答性 = INP
USE CASE 2

FID 廃止に合わせた社内モニタリングの INP 移行

課題
自前の計測ダッシュボードやアラートが FID ベースのままで、Shopify の評価基準とズレ始めていた。
打ち手
監視対象とアラート閾値を INP に置き換え、Dev Dashboard の INP 合否と社内指標を突き合わせる。
効果
「最初の入力遅延」ではなくセッション全体の応答性を捉え、実ユーザー体験に沿った改善優先度がつけられる。
技術メモ
FID はダッシュボードから消えているため、FID 依存のレポートは作り直しが必要。
Partner Dev
USE CASE 3

チーム手順書・ブックマークの「移動先」棚卸し

課題
運用手順書や共有ブックマークが Partner Dashboard のパフォーマンス画面を指しており、メンバーが迷う。
打ち手
自動リダイレクトに頼りつつ、手順書・社内 Wiki のリンクを Dev Dashboard へ正式に張り替える。
効果
新メンバーのオンボーディングが迷わず完結。リンク切れ・古い導線による問い合わせを削減。
技術メモ
旧 URL は自動リダイレクトされるため移行猶予はあるが、アプリの Distribution ページは既に新しい場所を指している。

9提案で使える1行サマリ

「アプリの admin パフォーマンス（LCP / INP / CLS の P75・合否）が Dev Dashboard に集約。
コード変更ゼロ・旧 URL は自動リダイレクト・FID は INP へ置き換え。
審査側と同じデータで Built for Shopify 基準を一画面で追える。」