あなたのAIエージェントがCore Web Vitalsのスーパーパワーを手に入れました
Claude CodeをCoreDashのフィールドデータに接続します。数百万のページロードから最悪のボトルネックを見つけ出し、Chromeで根本原因を追跡して修正コードを記述します。エージェントによるWebパフォーマンスの最適化は、レポートではなく、変更すべき実際のコード行を提示します。
2分でインストール CoreDashの無料トライアルを開始 »Trusted by market leaders · Client results
AIパフォーマンスツールにはデータの問題がある
ほとんどのAIエージェントはLighthouseに最適化されています。これはGoogleがランキングに使用しない、シミュレートされたデバイス上での合成スコアです。役立つWebパフォーマンスAIエージェントは、Googleと同じデータ、つまり安価なスマートフォン、不安定な接続、そしてあなたの開発マシンが決して見たことのない大陸にいるリアルユーザーのデータから始まります。
Lighthouseはランキングシグナルではない
Googleは、28日間にわたる実際のChromeユーザーからのCrUXフィールドデータに基づいてランク付けします。完璧なLighthouseスコアと不合格のフィールドスコアが同時に存在することはよくあります。モバイルサイトの52%が、フィールドデータにおいて少なくとも1つのCore Web Vitalsで不合格になっています。
盲目的なエージェントは盲目的な修正を行う
リアルユーザーデータがなければ、AIエージェントはどのページが遅いのか、どの要素がボトルネックなのか、あるいはその修正が役立ったのかを知ることができません。シミュレーションを最適化して終わらせてしまいますが、実際のユーザーの意見は異なります。
手動での調査には何時間もかかる
データをセグメント化する。仮説を立てる。トレースを実行する。確認する。修正案を作成する。シニアパフォーマンスエンジニアは、1つの問題につき2〜4時間を費やします。これをサイト内の遅いすべてのページに掛けてみてください。
INPはラボ環境では全くシミュレートできません Interaction to Next Paintは、リアルユーザーがページとどのように対話するかを測定します。合成ツールでは、どこをタップするか、どれくらい速くスクロールするか、どのデバイスを持っているかなど、リアルユーザーの行動を再現することはできません。LighthouseはINPを報告すらしていません。もしAIエージェントがLighthouseを実行しているなら、それは最悪のインタラクティビティ問題に対して盲目です。フィールドデータだけが唯一の情報源なのです。
2つの信頼できる情報源: フィールドデータとブラウザの証拠の融合
CWV Superpowersは、CoreDashのリアルユーザーデータとターゲットを絞ったChromeトレースを組み合わせます。フィールドデータは何が遅いのかを伝え、Chromeはなぜ遅いのかを伝えます。
CoreDashはエージェントに何が遅いかを伝える
CoreDashは、すべてのリアルユーザーからのすべてのページロードを追跡します。すべての指標は、問題を引き起こしている正確な要素に帰属します。サンプリングや制限はありません。
CoreDashが、div.hero > img.main上でLoad Delayが合計時間の52%を消費する4.2秒のLCPを報告した場合、エージェントは正確にどこを見るべきかを知っています。推測ではなく、数百万の実際のセッションからの測定値です。
このスキルは、LCP要素、要素タイプ、優先度状態、フェーズの内訳、INP対話ターゲット、LOAFスクリプト、CLSのシフト要素、デバイスタイプ、訪問者タイプ、ネットワーク速度、7日間の傾向など、25以上のCoreDashディメンションをクエリします。
Chromeはエージェントになぜ遅いかを伝える
CWV Superpowersは、モバイルエミュレーション（Fast 3G、4倍のCPUスロットリング）を使用してページにアクセスします。CoreDashが特定したボトルネックのフェーズのみをトレースします。
Load Delayがボトルネックですか？エージェントはネットワークウォーターフォールを調べて、検出のギャップを探します。Render Delayですか？ブロッキングスクリプトやフォントの読み込み遅延を探します。
その結果、フィルムストリップのスクリーンショット、ネットワークウォーターフォール、そしてフィールドデータが明らかにした根本原因を説明するターゲットを絞った証拠が得られます。
絶対的なしきい値ではなく、比例的な推論
Lighthouseは「Render Delayは350ミリ秒です」と伝えます。それが問題なのでしょうか？わかりません。CWV Superpowersは、合計時間の最大の割合を消費しているフェーズをボトルネックとして特定します。
INPは350ミリ秒です。Input Delay 70ミリ秒（20%）、Processing 80ミリ秒（23%）、Presentation 200ミリ秒（57%）。200ミリ秒単独では問題ないように見えても、Presentationがボトルネックです。それを修正すれば効果が現れます。Input Delayを最適化してもほとんど影響はありません。
これにより、パフォーマンス改善作業で最もよくある間違い、つまり「間違ったものを修正する」ことを防ぐことができます。
5つのステップ: 「何かが遅い」からコード修正まで
質問してみてください。5つのステップを経て、リアルユーザーの証拠に裏付けられた修正案が得られます。
1. 検出
最悪のページと指標をCoreDashのデータからスキャンします。低評価、モバイル、トラフィックの多いページ、そして長い下位グループを隠してしまうp75のスコアを優先します。
2. 診断
指標をフェーズに分解します。LCP: TTFB、Load Delay、Load Time、Render Delay。INP: Input Delay、Processing、Presentation。割合によってボトルネックを特定します。
3. Chromeトレース
モバイルエミュレーションでページにアクセスします。ステップ2で特定されたボトルネックのフェーズのみをトレースします。ネットワークウォーターフォール、フィルムストリップ、そしてブロッキングリソースの証拠をキャプチャします。
4. 根本原因
両方の証拠源を1つのステートメントにまとめます。要素、原因、CoreDashの指標、そしてChromeが確認したことです。曖昧さはありません。
5. 修正またはレポート
選択はあなた次第です。ファイル、行、要素、ビフォー/アフターとともにコード修正を適用します。チャートや証拠を含む自己完結型のHTMLレポートを生成します。あるいはその両方を行うこともできます。
25以上のディメンション: フィールドデータがカバーするあらゆる角度
これらはエージェントがクエリする実際のCoreDashのディメンションです。要約ではなく、全貌です。
LCP (Largest Contentful Paint)
LCP要素 要素タイプ 優先度状態 TTFBフェーズ Load Delay Load Time Render DelayINP (Interaction to Next Paint)
INPターゲット Input Delay Processing Presentation LOAFスクリプト ロード状態CLS (Cumulative Layout Shift)
シフト要素 シフト原因 シフトのタイミングセグメント
デバイスタイプ 国 ブラウザ OS 接続 訪問者タイプ ページパス傾向
7日間の変化 28日間のベースライン リグレッションの検出診断: すべてのCore Web Vitalsのフェーズごとの内訳
スコアだけではありません。CoreDashからのリアルユーザーの帰属情報を使用して、すべての指標をフェーズに分解します。
AIでLCPを修正: Largest Contentful Paintの診断
4フェーズの内訳: TTFB、Load Delay、Load Time、Render Delay。合計時間の中で最大の割合を消費しているフェーズを特定します。
要素の帰属: 正確なLCP要素、そのタイプ（画像、テキスト、背景画像、動画）、および優先度の状態（fetchpriority、遅延読み込み）。
典型的な修正: preloadヒントの追加、ヒーロー要素からの遅延読み込みの削除、画像フォーマットの最適化、レンダリングブロック・スクリプトの修正。
AIでINPを修正: Interaction to Next Paintの診断
3フェーズの内訳: Input Delay、Processing、Presentation。ラボ環境ではシミュレートできない唯一の指標です。フィールドデータのみが情報源となります。
スクリプトの帰属: Long Animation Frames（LOAF）により、正確なJavaScriptファイルとその継続時間が特定されます。さらに、対話が発生したときのページロード状態もわかります。
典型的な修正: メインスレッドへのyield、評価の遅延、イベントハンドラーの分割、大規模なDOMに対するcontent-visibility。
CLS: Cumulative Layout Shift
5つの原因パターン: サイズ指定のない画像、フォントの切り替え、動的に挿入されたコンテンツ、遅延読み込みされるリソース、レイアウトプロパティのCSSアニメーション。
クロスディメンション: モバイル対デスクトップ、新規訪問者対リピーター、高速ネットワーク対低速ネットワークを比較して原因を絞り込みます。
典型的な修正: width/heightの追加、font-display: optionalの指定、min-heightの確保、top/leftの代わりにtransformを使用。
根本原因のステートメントはどのように見えるか
「画像の最適化を検討してください」といったものではありません。これが実際の出力です。レビューしてマージするのに十分なほど具体的です。
根本原因:
/product/running-shoes-42上のLCP画像 div.hero-banner > img.product-main は、preloadヒントがなくfetchpriority="high"が設定されていないため、検出が1,980ms遅れています。
CoreDashの証拠:
LCPはモバイルのp75で3,820ms（不良）です。Load Delayがボトルネックで1,980ms（全体の52%）です。優先度状態: 3（プリロードなし）。傾向: 7日間で+340msの悪化。
Chromeの証拠:
ネットワークウォーターフォールは、HTMLの最初のバイトと画像リクエストの間に1,940msのギャップがあることを示しています。画像はCSSでのみ参照されており、プリロードスキャナーからは見えません。
修正:
templates/product.htmlの12行目に <link rel="preload" href="/images/hero.jpg" as="image" fetchpriority="high"> を追加します。47行目のimg要素にfetchpriority="high"を設定します。
一般的なAIのアドバイス:
「LCP画像にfetchpriorityを追加し、重要なリソースが適切にプリロードされるようにすることを検討してください。」
CWV Superpowers:
要素: div.hero-banner > img.product-main
ファイル: templates/product.html, 47行目
証拠: LCP時間の52%がLoad Delay（CoreDash p75）。1,940msの検出ギャップ（Chromeウォーターフォール）。
修正: ビフォー/アフターの差分を含む2行のコード変更。
比較: CWV Superpowersの優位性
異なるツールは異なる問題を解決します。それぞれのツールが実際に何を行うかを以下に示します。
| 機能 | CoreDash + CWV Superpowers | Chrome DevTools MCP | PSI / Lighthouse MCP |
|---|---|---|---|
| データソース | リアルユーザー（28日間のフィールドデータ） | 単一のラボセッション | シミュレートされた単一の読み込み |
| INP測定 | ✓ 実際の対話 | ✗ リアルユーザーなし | ✗ 測定されない |
| フェーズ内訳 | ✓ LCP、INP、CLSのフェーズ | ~ 手動分析 | ✗ スコアのみ |
| 要素の帰属 | ✓ 正確な要素 + 優先度 | ~ どこを見るべきか知っていれば可能 | ~ 一般的な提案 |
| 比例的な推論 | ✓ 割合によるボトルネック | ✗ 絶対値 | ✗ 絶対値 |
| セグメント比較 | ✓ デバイス、国、ブラウザ | ✗ 単一の設定 | ✗ 単一の設定 |
| 傾向の検出 | ✓ 7日間の変化 | ✗ 特定の時点のみ | ✗ 特定の時点のみ |
| Chromeトレース | ✓ フェーズごとのターゲット | ✓ フルアクセス | ✗ ブラウザなし |
| コード修正 | ✓ ファイル + 行 + 差分 | ~ エージェントに依存 | ~ 一般的なアドバイス |
注意: Chrome DevTools MCPは補完的な役割を果たします。CWV Superpowersは、フィールドデータがボトルネックを特定した後に、ターゲットを絞ったトレースのためにこれを使用します。これらを組み合わせて使用するのが最適です。
レポート: Slackにドロップ、Jiraに添付
自己完結型のHTML。依存関係なし。ビルドステップなし。すべてがインライン化された1つのファイルです。
フルレポート（Chromeあり）
色分けされた指標カード、フェーズ内訳チャート、重要な瞬間（first paint、LCP、ロード完了）のフィルムストリップのスクリーンショット、ネットワークウォーターフォールのSVG、根本原因分析、そしてビフォー/アフターのコードを含む推奨される修正。
RUMのみのレポート
同じ指標カードとフェーズ内訳に加えて、要素の帰属と根本原因分析が含まれます。フィルムストリップやウォーターフォールはありませんが、フィールドデータが信頼できる情報源であるため、診断の品質は同じです。
任意のMCPクライアントで動作
Claude Code: 自動化されたワークフローを備えた完全なスキル。検出、診断、Chromeトレース、コード修正、そしてレポートが含まれます。推奨。
Cursor: CoreDash MCPを利用したプラグインのインストール。エディタ内で完全な診断とコード修正を行います。
VS Code、Windsurf、Gemini CLI: HTTP MCPサーバーをサポートする任意のクライアントがCoreDashに接続します。同じフィールドデータ、同じ帰属情報が得られます。
Client Success
Don't just take my word for it
VP Engineering, Loop
"Mobile load time down 800ms. 7% lift in checkout conversion. The ROI justified the investment immediately."
Head of Engineering, Swift
"Layout shift on checkout eliminated entirely. Went from 0.4 to 0.02 CLS across mobile and desktop."
Engineering Manager, Zalando
"Every other audit we've had gave us a list of problems. This one told us exactly what to fix first and why."
Head of Platform, Adevinta
45% reduction in blocking time across 15 marketplaces. INP from 440ms to 64ms on Fotocasa alone. Google wrote up the results on web.dev.
VP Engineering, People Inc
"Seven brands, seven different stacks. Every single one got faster. No compromises on what makes each property unique."
Head of Digital, Rituals
"We used to break performance every other sprint. He set up budgets in our pipeline. Haven't had a regression since."
VP Product, Expedia Group
"We had 80+ third-party scripts and were failing CWV on every major property. Arjen got us passing without touching our ad revenue."
Product Lead, Miro
"Our dashboards were choking on main-thread work. 25% reduction in CPU usage. Users noticed immediately."
CTO, DPG Media
"He found bottlenecks in our component library that we'd missed for two years. Performance gains were visible within days."
Lead Developer, Alza
"Transferred knowledge to our engineering team. We can now diagnose and resolve performance issues independently."
2分で実行可能
ターミナルでの自動化されたCore Web Vitals診断。データが流れているCoreDashアカウントが必要です。無料枠でも動作します。
Claude Code
claude mcp add --transport http coredash \
https://app.coredash.app/api/mcp \
--header "Authorization: Bearer cdk_YOUR_API_KEY"
/plugin marketplace add corewebvitals/cwv-superpowers
/plugin install cwv-superpowers@cwv-superpowers
claude --chrome
私の最大のCWVの問題を見つけて修正してください。 CoreDashの Project Settings → API Keys (MCP) からAPIキーを取得します。一度だけ表示されます。SHA-256ハッシュとして保存され、読み取り専用です。
Cursor
/plugin-add cwv-superpowers
CoreDashを.cursor/mcp.jsonに追加します:
{
"mcpServers": {
"coredash": {
"url": "https://app.coredash.app/api/mcp",
"headers": {
"Authorization": "Bearer cdk_YOUR_API_KEY"
}
}
}
} その他のMCPクライアント
エンドポイント: https://app.coredash.app/api/mcp
ヘッダー: Authorization: Bearer cdk_YOUR_API_KEY
VS Code（Copilotエージェントモード）、Windsurf、Gemini CLI、Claude Desktop、および任意のHTTP MCPクライアントで動作します。1つのMCP Webパフォーマンスエンドポイントで、すべてのエージェントに対応します。
よくある質問
CWV Superpowersを使用するにはChromeを実行する必要がありますか？
いいえ。Chromeトレースはオプションです。これなしでも、CoreDashデータのみに基づいて、完全なフィールドデータの診断、フェーズの内訳、要素の帰属、およびコード修正の提案を取得できます。Chromeを使用すると、フィルムストリップのスクリーンショット、ネットワークウォーターフォール、および根本原因の視覚的な確認が追加されます。どちらのモードでもレポートは生成されます。
AIエージェントでLighthouseを実行するのとどう違いますか？
Lighthouseは、あなたのマシン上で単一の合成ロードを実行します。CWV Superpowersは、CoreDashからの28日間のリアルユーザーデータ（実際のデバイス、実際のネットワーク、実際の対話）を使用します。実際のユーザーのタップからINPを測定します（Lighthouseにはできません）。セグメント（モバイル対デスクトップ、インド対米国など）を比較します。また、絶対的なスコアだけでなく、比例的な推論を使用してボトルネックのフェーズを見つけ出します。
どのAIコーディングエージェントがサポートされていますか？
MCP（Model Context Protocol）サーバーをサポートする、Webパフォーマンスのための任意のAIコーディングエージェントです。Claude Codeには、自動化された5ステップのワークフローを備えた専用のスキルがあります。Cursor、VS Code（Copilotエージェントモード）、Windsurf、Gemini CLI、およびClaude Desktopは、CoreDash HTTP MCPエンドポイントを介して接続します。フィールドデータと帰属情報は、すべてのクライアントで同一です。
CoreDashは無料ですか？
CoreDashには、CWV Superpowersで動作する無料枠があります。サイトからデータが流れている必要があります（CoreDashのスクリプトタグを追加してください）。無料枠にはサンプリングやページビューの制限はありません。MCPアクセスのためのAPIキーは、すべてのプランで利用可能です。
これをクライアントのサイトに使用できますか？
はい。各CoreDashプロジェクトに対して、無制限の 専用MVP APIキー を作成できます。各クライアントサイトにCoreDashを追加し、読み取り専用のAPIキーを生成してMCPクライアントを設定します。エージェントは、そのプロジェクトのデータのみを参照します。CWV SuperpowersはMITライセンスであるため、商用利用に制限はありません。
オープンソース。ロックインなし。
調査や拡張が可能なCore Web Vitalsの自動化。オーケストレーター、診断モジュール、Chromeトレースロジック、およびレポートテンプレートはすべてGitHubにあります。仕組みを読んでください。フォークしてください。拡張してください。貢献してください。
無料トライアルを開始 GitHubで見る