2026-07-24 E: 会計/ファイナンス・コスト効率 | サマーセールLP パフォーマンスバジェット逸脱 Bad→Good（ラボ vs フィールドデータ乖離 × Hero画像最適化 × JSコード分割 × Cache-Control/SWR × CLS対策 × Lighthouse CI × CVR売上インパクト試算）（MOps 月間追加GMV約459万円 ROI約5,402%）

概要

🧪

ラボデータとフィールドデータは別物

Lighthouseのローカル実行はハイエンド端末・良好回線でのシミュレーション。実ユーザーの分布を反映する CrUX（フィールドデータ, p75）で確認しない限り「スコアが良い＝問題ない」は誤りうる。今回はラボ95点の裏でLCP/CLS/INPすべてPoor域。

🖼️

LCPは最大要因（Hero画像）から着手する

2.4MBの未最適化JPEGがLCPを支配的に悪化させていた。WebP変換＋next/imageのレスポンシブ配信で180KBまで削減し、ページ重量を80.3%削減した。

⚡

Cache-Control設計はUXとインフラコストの両方に効く

オリジンフェッチ率を80%→15%に下げる Cache-Control + stale-while-revalidate は、リピート訪問の高速化とCDN/オリジンコスト削減を同時に実現する投資対効果の高い改善。

💰

パフォーマンス改善は財務言語に翻訳して初めて伝わる

「LCPが2.3秒速くなった」ではなく「月間約459万円の売上インパクト、投資回収は約7日」と語る。確実な便益（インフラコスト削減）と推定値（CVR改善）は区別して誠実に報告する。

問題

ECサイト MOps チームのシニアエンジニアとして、新しく公開した「サマーセールLP（Next.js製ランディングページ）」のフロントエンドパフォーマンスレビューを任された。フロントエンド担当の後輩が作成した Bad チェック結果メモをレビューし、7つの問題点を洗い出して Good レポートへ再設計せよ。

シナリオ

対象: サマーセールLP（Next.js, App Router, Cloud CDN配信）
目的: LPのパフォーマンス劣化がチェックアウトCVRに悪影響を与えていないか検証し、改善優先度をCFO/PMに説明する
後輩はローカル環境でLighthouseを1回実行しスコア95点だったことのみを根拠に「問題なし」と結論し、メモを提出した

前提数値（正）

項目	値
月間LPセッション数	400,000セッション/月
現状CVR / AOV / 粗利率	2.1% / 9,500円 / 35%
フィールドデータ（CrUX, モバイルp75）	LCP 4.8秒 / CLS 0.28 / INP 310ms
Lighthouseラボスコア	95点（ローカルWi-Fi・ハイエンド端末）
Core Web Vitals 良好閾値	LCP≤2.5秒 / CLS≤0.1 / INP≤200ms
ページ重量内訳（Before）	Hero画像2.4MB + JS 0.83MB + その他0.17MB = 3.4MB
社内経験則（過去3回のLP改善施策実測平均）	LCP 1秒改善 → CVR相対+2.5%
静的アセット平均リクエスト数	12件/セッション
オリジンフェッチ率（Before）	80%（Cache-Control未設定/短命）
Cloud CDN転送量単価 / GetObject単価（仮定）	$0.08/GB / $0.004/1,000件
為替レート（仮定） / エンジニア単価	$1=150円 / 80万円/月（4万円/人日）

期待する回答形式: 問題点の列挙（番号付き）+ Core Web Vitals改善試算（LCP/CLS/INP Before→After）+ CDN転送量コスト削減試算 + オリジンフェッチコスト削減試算 + CVR改善による月間売上・粗利インパクト試算 + 開発コストとROI/ペイバック期間 + CI performance budget導入による再発防止提言

Bad チェック結果メモ (Before)

このメモには 7つの問題 が隠れています。見つけてみてください。

Bad メモ — ラボスコアのみ・要因未特定・ビジネス接続なし

件名: サマーセールLP パフォーマンスチェック結果

Lighthouse（ローカル実行）でパフォーマンススコア95点
だったので、パフォーマンス面は問題ないと判断しました。
  ← 問題①: ラボデータのみ、フィールドデータ未確認

画像サイズやJSバンドルサイズについては特に
手を入れていません。
  ← 問題②: Hero画像2.4MB未最適化（LCP主要因未対処）
  ← 問題③: JSバンドル850KB未分割（INP悪化要因未対処）
  ← 問題④: Cache-Control未設定（オリジンフェッチ率80%）
  ← 問題⑤: CLS未計測（広告バナーのレイアウトシフト）

最近CVRが下がっているのは広告クリエイティブ側の
問題だと思うので、フロントエンド側の追加対応は
不要と考えます。
  ← 問題⑥: CI performance budget未導入（再発防止なし）
  ← 問題⑦: パフォーマンス指標とCVR・売上が未接続

問題点サマリー（7点）

1ラボデータのみで判断、フィールドデータ未確認 — CrUX実測ではLCP/CLS/INPすべてPoor域

2Hero画像が未最適化（LCP主要因） — 2.4MB JPEG、next/image・WebP未使用

3JSバンドルが未分割 — 850KB（gzip後）が同期ロードでINPを悪化

4Cache-Control/SWR未設定 — オリジンフェッチ率80%でCDNの恩恵を活かせていない

5CLSが未計測・未対策 — 広告バナー動的挿入によるレイアウトシフト0.28

6CI予防ゲートがない — Lighthouse CI等のperformance budgetが未導入

7パフォーマンスとビジネス指標が未接続 — CVR・売上インパクトが未試算、推測のみで結論

ヒント（段階的開示）

ヒント1 — 方向性

Bad メモの罠は3系統。(1) ラボデータのみで判断し、フィールドデータ（実ユーザー）を見ていない — Lighthouseのローカル実行はハイエンド端末・良好なネットワーク条件でのシミュレーションであり、実際のユーザー分布（中位スペックAndroid・4G回線が多い）とは乖離する。(2) LCP/CLS/INPそれぞれの主要因子を特定せず「スコアが良いから終わり」で止まっている — 巨大なHero画像、未分割のJSバンドル、レイアウト予約のない広告枠など、具体的なボトルネックの特定と改善提案がない。(3) パフォーマンスとビジネス指標（CVR・売上）を接続していない — 「広告クリエイティブの問題だと思う」という推測のみで、フロントエンド側の影響を定量的に否定も肯定もできていない。CIでの予防的ガードもない。

ヒント2 — アプローチ

問題①: ラボ環境とフィールド環境の条件差（端末スペック・回線速度・キャッシュ状態）を明記し、CrUX p75データで実際のCore Web Vitalsを確認する
問題②: LCPの最大要因（Hero画像）のフォーマット・圧縮・レスポンシブ配信（next/image, WebP, sizes属性）を確認する
問題③: メインバンドルに含まれる非クリティカルなコード（トラッキングタグ等）を動的importに切り出せないか検討する
問題④: 静的アセットのCache-Controlヘッダーとstale-while-revalidateの設定有無を確認し、CDNのキャッシュヒット率を試算する
問題⑤: CLSの原因（広告バナー等の動的挿入によるレイアウトシフト）を特定し、領域予約（aspect-ratio, min-height）で対策する
問題⑥: CI/CDにLighthouse CI等のパフォーマンスバジェットチェックを組み込み、劣化を本番投入前に検知する
問題⑦: LCP改善秒数×社内経験則（1秒あたりCVR+2.5%）でCVR・売上・粗利インパクトを試算し、開発工数に基づくROI・ペイバック期間を算出する

ヒント3 — 誘導

【ページ重量削減】
Before = Hero 2.4MB + JS 0.83MB + Other 0.17MB = 3.4MB
After  = Hero 0.18MB(WebP+next/image) + JS 0.32MB(コード分割) + Other 0.17MB = ?
削減率 = (Before - After) / Before = ?

【CDN転送量コスト】
月間転送量 = 400,000セッション × ページ重量(MB) ÷ 1024 = ?GB
コスト = 転送量(GB) × $0.08/GB = ?

【オリジンフェッチコスト（Cache-Control + SWR導入）】
月間アセットリクエスト数 = 400,000 × 12件/セッション = 4,800,000件
Before(80%) = ?件、After(15%) = ?件
コスト = リクエスト数 ÷ 1,000 × $0.004 = ?

【CVR改善インパクト】
LCP改善量 = 4.8秒 - 2.5秒 = 2.3秒
相対CVR改善率 = 2.3 × 2.5% = ?
新CVR = 2.1% × (1 + 相対CVR改善率) = ?
追加購入件数/月 = 400,000 × (新CVR - 2.1%) = ?
追加GMV/月 = 追加購入件数 × 9,500円 = ?

【ROI・ペイバック】
開発コスト = 合計人日 × 4万円
月間便益合計 = 追加粗利 + インフラコスト削減額
ROI(年間) = (月間便益合計×12) ÷ 開発コスト
ペイバック期間(日) = 開発コスト ÷ 月間便益合計 × 30

問題点分析（7点）

#	問題点	分類	改善方法
1	ラボデータのみで判断、フィールドデータ未確認	計測	CrUX（p75フィールドデータ）で実態を確認
2	Hero画像が未最適化（LCP主要因）	LCP	WebP変換 + next/image レスポンシブ配信
3	JSバンドルが未分割（INP悪化要因）	INP	コード分割・動的import・Tree Shaking
4	Cache-Control/SWR未設定	コスト	適切なmax-age + stale-while-revalidate
5	CLSが未計測・未対策	CLS	広告枠の領域予約（aspect-ratio）
6	CI予防ゲートがない	運用	Lighthouse CI + Performance Budget導入
7	パフォーマンスとビジネス指標が未接続	意思決定	CVR・売上インパクト・ROIを定量試算

ページ重量削減とCore Web Vitals改善（SVG）

模範解答

## 問題点の列挙（7点）

### 問題①: ラボデータのみで判断し、フィールドデータ未確認
Bad:  ローカルLighthouseスコア95点のみを根拠に「問題なし」と判断
Fix:  CrUX（p75, 実ユーザー）データを確認。LCP 4.8秒/CLS 0.28/
      INP 310ms、いずれもCore Web Vitals「Poor」域だった

### 問題②: Hero画像が未最適化（LCP主要因）
Bad:  2.4MBのJPEGをnext/image・WebP変換なしで配信
Fix:  WebP変換 + next/imageのレスポンシブ配信（sizes指定）で
      180KBまで削減（-92.5%）

### 問題③: JSバンドルが未分割（INP悪化要因）
Bad:  メインバンドル850KB（gzip後）が同期ロード、トラッキング
      タグ等の非クリティカルコードも含まれる
Fix:  コード分割・動的import・Tree Shakingで320KBまで削減

### 問題④: Cache-Control/stale-while-revalidate未設定
Bad:  静的アセットのキャッシュ設定がなく、オリジンフェッチ率80%
Fix:  適切なmax-age + SWRでオリジンフェッチ率を15%に低減

### 問題⑤: CLSが未計測・未対策
Bad:  広告バナーが動的挿入され、領域が予約されていない
Fix:  aspect-ratio / min-heightで領域を事前予約しCLS 0.1未満へ

### 問題⑥: CI/CDにパフォーマンスバジェットの自動チェックがない
Bad:  劣化が本番投入後にしか発覚しない
Fix:  Lighthouse CI + budgets.jsonでPRをブロックするゲートを導入

### 問題⑦: パフォーマンス指標とビジネス指標が未接続
Bad:  「広告クリエイティブの問題だと思う」という推測のみで結論
Fix:  LCP改善秒数×社内経験則でCVR・売上・粗利インパクトを試算し
      ROI/ペイバックを算出する

指標	Before（フィールド実測）	目標（Good閾値）	主な改善策
LCP	4.8秒（Poor）	2.5秒以下	Hero画像のWebP化・next/image最適化
CLS	0.28（Poor）	0.1以下	広告バナーの領域予約（aspect-ratio）
INP	310ms（Poor）	200ms以下	JSコード分割・非クリティカルスクリプト遅延

いずれもBeforeはCore Web Vitals「Poor」判定域にあり、Lighthouseラボスコア95点という結果とは正反対の実態だった。

【ページ重量内訳】
Before = Hero画像 2.4MB + JSバンドル 0.83MB + その他 0.17MB = 3.4MB
After  = Hero画像 0.18MB（WebP+next/image） + JSバンドル 0.32MB（コード分割） + その他 0.17MB = 0.67MB
削減率 = (3.4 - 0.67) / 3.4 ≈ 80.3%

【CDN転送量コスト】
Before: 400,000セッション × 3.4MB = 1,360,000MB ÷ 1024 ≈ 1,328.13GB
        コスト = 1,328.13GB × $0.08/GB ≈ $106.25/月
After:  400,000セッション × 0.67MB = 268,000MB ÷ 1024 ≈ 261.72GB
        コスト = 261.72GB × $0.08/GB ≈ $20.94/月
削減額 = $106.25 - $20.94 = $85.31/月（約12,797円/月）

【オリジンフェッチコスト（Cache-Control + SWR導入）】
月間アセットリクエスト数 = 400,000 × 12件/セッション = 4,800,000件
Before(オリジンフェッチ率80%): 3,840,000件 × $0.004/1,000 ≈ $15.36/月
After (オリジンフェッチ率15%):   720,000件 × $0.004/1,000 ≈ $2.88/月
削減額 = $15.36 - $2.88 = $12.48/月（約1,872円/月）

インフラコスト削減合計 = $85.31 + $12.48 = $97.79/月（約14,669円/月）

この規模のLPでは転送量コストの絶対額自体は小さく、コスト削減の主眼はCDN費用ではなくCVR経由の売上インパクトにある。

LCP改善量 = 4.8秒 - 2.5秒 = 2.3秒
相対CVR改善率 = 2.3秒 × 2.5%/秒（社内経験則） = 5.75%

新CVR = 2.1% × (1 + 0.0575) = 2.1% × 1.0575 = 2.22075%
CVR改善幅 = 2.22075% - 2.1% = 0.12075pt

追加購入件数/月 = 400,000セッション × 0.0012075 = 483件
追加GMV/月   = 483件 × 9,500円 = 4,588,500円（約459万円）
追加粗利/月  = 4,588,500円 × 35% = 1,605,975円（約161万円）

この試算は社内経験則（LCP1秒改善→CVR相対+2.5%）を外挿した点推定であり、因果を証明するものではない。実装後は必ずA/Bテストまたは介入前後比較で効果を検証すべき。

【開発工数】
画像最適化（next/image導入・WebP変換パイプライン）        : 2人日
JSコード分割・不要ライブラリ削除・Tree Shaking            : 3人日
Cache-Control/stale-while-revalidate設計・CDN設定         : 1.5人日
広告枠レイアウト予約（CLS対策）                            : 1人日
Lighthouse CI + Performance Budget導入（CI/CDゲート化）    : 1.5人日
合計                                                       : 9人日

開発コスト = 9人日 × 4万円/人日 = 360,000円

【月間便益】
月間便益合計 = 追加粗利(1,605,975円) + インフラコスト削減(14,669円) = 1,620,644円

【ROI（年間ベース）】
年間便益 = 1,620,644円 × 12 ≈ 19,447,728円
ROI = 19,447,728円 ÷ 360,000円 ≈ 54.0倍（5,402%）

【ペイバック期間】
ペイバック = 360,000円 ÷ 1,620,644円/月 ≈ 0.222ヶ月 ≈ 約6.7日（約7日）

投資規模（36万円・9人日）に対して月次便益が大きく、ペイバック期間は1週間程度と極めて短い。ただしCVR改善分の妥当性はA/Bテストで検証すべき点推定であり、確実な便益はインフラコスト削減分（月14,669円）にとどまる点をCFO報告時に明示する。

【CI/CDに組み込むべきパフォーマンスバジェット（budgets.json + Lighthouse CI）】
- LCP: 2.5秒以下（超過でPRをブロック）
- CLS: 0.1以下
- INP: 200ms以下（ラボ計測困難な場合はTBT 200ms以下で代替）
- JSバンドルサイズ（メインチャンク）: 350KB以下（gzip後）
- 画像1枚あたりの転送量: 200KB以下

【運用フロー】
1. PR作成時にLighthouse CIを自動実行し、閾値を1つでも超過したら
   CI失敗としてマージをブロック
2. 本番デプロイ後はCrUX（フィールドデータ）を週次でモニタリングし、
   ラボ計測との乖離を継続監視
3. ラボスコアのみでの「問題なし」判断を禁止し、Good/Needs
   Improvement/Poorの判定は必ずフィールドデータ基準で行う

今回の結論: フロントエンド改善は実施すべき。ラボスコア95点はローカル計測条件に起因する見かけ上の数値であり、実ユーザーのCore Web VitalsはPoor域にある。9人日・36万円の投資でLCP/CLS/INPをGood域に改善でき、確度の高いインフラコスト削減（月14,669円）に加え、CVR改善による売上インパクト（点推定で月約459万円・粗利約161万円）が見込める。

ポイント解説

1 ラボデータとフィールドデータは別物
Lighthouseのようなラボ計測は再現性が高い反面、実ユーザーの端末・回線分布を反映しない。CrUXやRUM（Real User Monitoring）のフィールドデータで実態を確認しない限り、「スコアが良い＝問題ない」という判断は誤りうる。

2 LCP改善はまず最大の要因から着手する
今回はHero画像が支配的要因。画像最適化（フォーマット変換・レスポンシブ配信）はコストパフォーマンスの高い改善策になりやすい。

3 JSバンドルの肥大化はLCPだけでなくINP（応答性）も悪化させる
メインスレッドをブロックする同期的なJS実行は、描画完了だけでなくユーザー操作への応答性も悪化させる。コード分割・動的importで初期表示に不要なコードを遅延させる。

4 Cache-Control設計はユーザー体験とインフラコストの両方に効く
適切なmax-age・stale-while-revalidateはリピート訪問の高速化とオリジンフェッチ削減を同時に実現する、投資対効果の高い改善。

5 パフォーマンス改善はCVR・売上という財務言語に翻訳して初めて経営に伝わる
「LCPが1秒速くなりました」ではなく「月間約459万円の売上インパクトが見込め、投資回収は1週間」と語ることで優先度判断が可能になる。ただし推定値と確実な便益（インフラコスト削減）を区別して誠実に報告する。

実務への応用

公開前チェックリストの標準化: MOpsチームでは季節キャンペーンLPを頻繁に公開するため、Lighthouse CI + Performance Budgetを標準化しておくことで、今回のような「ラボスコアだけを見て問題を見逃す」事態を防止できる。
next/imageの横展開: レスポンシブ画像配信・動的importによる初期バンドル縮小・Cloud CDNのCache-Control設計は、他のプロモーションLP・商品詳細ページにもそのまま適用できるパターン。
CFOへの報告フォーマット: 「確実なコスト削減額（インフラコスト月14,669円）」と「CVR改善による推定売上インパクト（月約459万円、要A/Bテスト検証）」を分けて提示することで、証券会社時代に培った「保守的な数値と楽観的な参考値を区別する」誠実さをそのまま活かせる。

今日のまとめ

パフォーマンス改善の可否は「Lighthouseスコアが良いかどうか」ではなく「実ユーザーのフィールドデータがCore Web Vitalsの閾値を満たしているか」で判断すべきである。今回のケースではラボスコア95点の裏で、実ユーザーのLCP/CLS/INPはすべてPoor域にあり、Hero画像・JSバンドル・レイアウトシフト・キャッシュ設定という具体的なボトルネックが未対策のまま放置されていた。9人日・36万円の投資でこれらを改善でき、確実なインフラコスト削減（月14,669円）に加え、CVR改善による推定売上インパクト（月約459万円）が見込まれる。

次のステップ

発展問題: 今回の施策実施後、実際のLCP改善効果とCVR改善効果を検証するA/Bテスト（または段階的ロールアウト）を設計せよ。検出力分析（必要サンプルサイズ）・SRMチェック・ガードレール指標（直帰率・広告収益等）を含めること。
参考: Core Web Vitals（LCP/CLS/INP）/ CrUX（Chrome User Experience Report）/ Lighthouse CI / next/image / Code Splitting・Dynamic Import / Cache-Control・stale-while-revalidate / Cloud CDN 料金体系

自己評価（あとで記入）

理解度: 完全理解おおむね理解要復習

自分の回答:

気づき・メモ: