Lighthouseのスコアは、監査項目ごとに固定された重みの加重平均で決まります。その重みは公開されている設定ファイルに数値で書かれており、「直しても1点も動かない項目」と「1つで2割動く項目」は事前に判別できるものです。この記事では最新版 lighthouse 13.4.1（2026年7月20日リリース）の既定設定を一次情報として、5カテゴリの実配点とスコアの限界を整理します。
まとめ
- v13.4.1のカテゴリは5つ。performance / accessibility / best-practices / seo / agentic-browsing です。PWAカテゴリはv12.0.0で削除されました。
- Performanceの採点はTBT 30%・LCP 25%・CLS 25%・FCP 10%・Speed Index 10%の5指標のみ。INPは重み0でレポートに出るだけです。
- Best Practicesは21監査・重み合計27。is-on-https、deprecations、third-party-cookiesの3つで55.6%を占めます。CSPやHSTSなどのセキュリティ監査は重み0で、直しても点は動きません。
- SEOカテゴリはis-crawlableだけで31.00%。noindexやrobots.txtでブロックしていれば、他を全部通してもカテゴリは合格しません。
- SEOスコア100は検索順位を保証しません。Lighthouse自身がカテゴリ説明で「ここで採点しない要因が検索順位に影響する」と明言しています。
- v13.3.0でAIエージェント向けのAgentic Browsingカテゴリが既定設定に入りました。llms.txtとWebMCPを監査しますが、0〜100のスコアではなく達成数の分数表示です。
Lighthouseの5カテゴリと計測方式（v13.4.1時点の構成）
Lighthouseは、Chromeを制御して対象ページを1回読み込み、その過程のトレースとDOMの状態を監査項目に照らして採点します。計測は実行した端末と回線の条件下で行われるため、得られるのはラボデータです。実ユーザーの体験を集計したフィールドデータとは別物で、この区別がスコアの解釈をほぼ決めます。
採点対象は、v13.4.1の既定設定ではperformance、accessibility、best-practices、seo、そして2026年に追加されたagentic-browsingの5カテゴリです。2024年4月のv12.0.0でPWAカテゴリが削除され、Chromeのインストール要件更新がその理由として公式に示されています。「Lighthouseは4カテゴリ」「PWAを含む5カテゴリ」と説明する記事は、いずれもv13の構成と一致しません。
手元のレポートと説明が食い違う原因は、ほぼDevToolsに載っているLighthouseの版差です。
| Lighthouse | Chrome（stable） | 主な変更 |
|---|---|---|
| 13.0.0 | 143 | 旧監査8件を削除、Insightsへ移行 |
| 13.2.0 | 150 | Agentic Browsingを試験追加 |
| 13.3.0 | 150 | Agentic Browsingを既定設定に追加 |
| 13.4.0 | 151 | — |
| 13.4.1 | 152 | WebMCP監査の判定を整理 |
Chrome 143のDevToolsにAgentic Browsingカテゴリは存在しません。確認にはChrome 150以降が必要です。
Lighthouseの実行手段と結果の読み分け（DevTools・PageSpeed Insights・CLI）
Chrome DevToolsのLighthouseパネルで測る手順
対象ページでDevToolsを開き、Lighthouseパネルでモード（Navigation / Timespan / Snapshot）、デバイス、対象カテゴリを指定して実行します。注意点は測定環境です。通常のプロファイルではインストール済み拡張のスクリプト実行時間が混ざり、Performanceスコアが下振れします。シークレットウィンドウでの計測が最も再現性が高くなります。
PageSpeed Insightsが返すラボデータとフィールドデータの違い
PageSpeed InsightsはLighthouseによるラボデータと、Chrome UXレポート由来のフィールドデータを併記します。数値がずれるのは異常ではありません。ラボは1回の計測、フィールドは28日間の実ユーザー集計だからです。Googleがページ体験の評価に用いるのはフィールド側のCore Web Vitalsで、判断はしきい値で決まります。指標ごとの合格ラインはコアウェブバイタルとは？3指標（LCP・INP・CLS）の基準と改善方法【2026年版】で確認できます。
npx lighthouseによるCLI実行とNode 22.19以上の要件
反復計測やレポート保存にはCLIが向きます。lighthouse 13.4.1のpackage.jsonはengines.nodeを>=22.19と宣言しており、これより古いNode.jsでは警告または失敗します。
npx lighthouse https://example.com \
--only-categories=best-practices,seo \
--form-factor=mobile --output=json --output-path=./report.json--only-categoriesに存在しないカテゴリ名を渡した場合、v13.0.0以降は黙って無視されずエラーになります。CI上でしきい値を継続監視する構成はCI/CD環境におけるLighthouse CIによる継続的なパフォーマンス監視の重要性で扱っています。
Performanceカテゴリの配点｜TBT30%・LCP25%・CLS25%の重み
採点対象の5指標と重み、採点されないINP・TTIの扱い
Performanceスコアは監査項目ではなく指標から計算されます。v13.4.1の重みは次の通りです。
| 指標 | 略称 | 重み | 採点 |
|---|---|---|---|
| Total Blocking Time | TBT | 30 | 対象 |
| Largest Contentful Paint | LCP | 25 | 対象 |
| Cumulative Layout Shift | CLS | 25 | 対象 |
| First Contentful Paint | FCP | 10 | 対象 |
| Speed Index | SI | 10 | 対象 |
| Interaction to Next Paint | INP | 0 | 対象外 |
| Time to Interactive | TTI | 0 | 非表示 |
TBTとLCPとCLSで80%です。JavaScriptの実行時間、最大要素の描画、レイアウト移動の3点以外はスコアをほとんど動かしません。INPは指標として存在するのに重み0で、これはユーザーの実操作を必要とするINPの代表値が1回のページ読み込みでは取れないためです。ラボ側の近似として機能するのがTBTで、重み30が割かれている理由もそこにあります。両指標の関係はINPとFID（First Input Delay）の違いを徹底比較するで整理しています。
TTIは重み0の非表示グループに残り、レポートUIには出ませんがJSON出力には含まれます。「TTIが消えた」も「TTIが採点されている」も不正確です。各指標の定義はWebパフォーマンス指標の一覧と使い分け｜TTFB・FCP・TBT・Speed Indexの基準にまとめています。
v13で削除された8監査とInsightsへの置き換え
v13.0.0（2025年10月10日）は旧監査を8つ削除しました。ただし全部がPerformanceにあったわけではありません。直前のv12.8.2の既定設定で確認すると、Performanceに載っていたのは5つ（first-meaningful-paint、no-document-write、offscreen-images、third-party-facades、uses-passive-event-listeners）です。font-sizeはBest Practicesの監査、preload-fontsとuses-rel-preloadは既定設定に入っていない実験的監査でした。公式の説明は「Lighthouse 12でレポートの既定表示をInsightsに切り替え、Lighthouse 13でレポートと基礎となるJSONの両方から旧監査を削除する」というものです。
削除理由は実務判断に直結します。offscreen-imagesは「オフスクリーン画像はブラウザが既に優先度を下げている」ため計測結果に影響しにくい、third-party-facadesは「一部の開発者が無関係なサードパーティ製ファサードの使用に懸念を示した」ため。preload-fontsとuses-rel-preloadは「過剰に推奨してしまうリスク」から無効化されたままで、v12.8.2の実験的設定にも「preloadの助言はissue #11960が解決するまで保留」と注記されています。つまりpreloadを機械的に足す最適化は、v13でも推奨されていません。
置き換えとして前面に出たのがcache-insight、lcp-discovery-insight、render-blocking-insightなど17のInsight監査です。これらはv12.8.2の時点で既に存在していましたが非表示グループに置かれており、v13でinsightsグループへ移されて表示されるようになりました。いずれも重み0で、スコアではなく原因特定に使う診断情報という位置づけです。Speed Index（重み10）を改善する場合も、ファーストビューの描画完了を遅らせている要因はrender-blocking-insightとimage-delivery-insightで特定します。
Best Practicesカテゴリの21監査と配点｜スコアを動かす3項目
4グループの構成と重み合計27の内訳
Best Practicesは21監査で、Trust and Safety（9監査）、User Experience（3監査）、Browser Compatibility（3監査）、General（6監査）の4グループに分かれます。重みの合計は27、うち8監査が重み0です。表示される項目数の約4割はスコアに寄与しません。
重み5の監査は3つあり、それぞれ27分の5＝18.5%です。合計55.6%で、Best Practicesスコアの過半をこの3監査が決めています。
| 監査ID | グループ | 重み | 占有率 |
|---|---|---|---|
| is-on-https | Trust and Safety | 5 | 18.5% |
| deprecations | General | 5 | 18.5% |
| third-party-cookies | General | 5 | 18.5% |
| paste-preventing-inputs | User Experience | 3 | 11.1% |
| errors-in-console 他8監査 | 各グループ | 1 | 3.7% |
着手順はこの表から一意に決まります。全リソースをHTTPSで配信し、非推奨APIの呼び出しを消し、サードパーティCookieへの依存を洗い出す。次に効くのはpaste-preventing-inputsで、パスワードやクーポン欄で貼り付けを禁止するスクリプトを外すだけの作業に11.1%が割かれています。重み1の監査を9個直しても合計33%どまりで、労力対効果は逆転します。
重み0で採点されないセキュリティ監査の実務上の扱い
誤解が多いのはここです。csp-xss、has-hsts、origin-isolation、clickjacking-mitigation、trusted-types-xssの5監査は、いずれも重み0です。Content Security PolicyやHSTSを完璧に設定してもBest Practicesのスコアは1点も上がらず、未設定でも減点されません。baseline、js-libraries、valid-source-mapsも同じ情報提供枠です。
したがって、スコアを上げる目的でCSP導入を計画するのは投資判断として誤りです。CSPやTrusted Typesは実際の攻撃を防ぐために入れるものです。逆に「Best Practices 100点だからセキュリティは問題ない」という報告が上がってきたら、重み0の5監査を個別に開いて確認してください。100点はこれらが未設定でも成立します。
SEOカテゴリの10監査とスコアの限界｜is-crawlableが31%
is-crawlableに31.00%を割り当てた設計意図
SEOカテゴリは採点対象10監査と、手動確認扱いのstructured-data（重み0）で構成されます。特異なのはis-crawlableの重みで、設定ファイルには93 / 23という分数がそのまま書かれています。値は約4.043、他9監査の合計が9なので占有率は4.043÷13.043＝31.00%です。
これは偶然の値ではありません。設定ファイルのコメントには、この監査が落ちたときにSEOカテゴリ自体が不合格になるよう31%以上を確保する、という計算式が明記されています。robots.txtでのブロックやnoindexが残っていれば、document-title、meta-description、canonical、hreflangを全部通しても合格ラインには届きません。SEOスコアが伸びないときに最初に見るのはこの1項目です。
SEOスコア100でも検索順位が上がらない理由
SEOカテゴリが検査するのは、タイトルタグの有無、メタディスクリプションの有無、リンクテキスト、alt属性、canonical、hreflang、HTTPステータス、robots.txtの妥当性といった技術的な最低条件です。コンテンツの品質、被リンク、検索意図との一致は評価対象に入っていません。
Lighthouse自身がSEOカテゴリの説明でこう書いています。「Lighthouseがここで採点しない多くの追加要因が、Core Web Vitalsのパフォーマンスを含め、検索順位に影響しうる」。10監査が満点でも、それは減点要因が無いことの確認に過ぎません。SEOスコアは順位の予測値ではなく技術的な足切りのチェックリストです。90点を100点にする工数は、フィールドデータのCore Web Vitalsと本文の検索意図適合に回したほうが効きます。
v13でfont-size監査が削除された理由
font-size監査（本文が12px未満だと警告）は、v11系ではSEOカテゴリのseo-mobileグループにありました。v12.0.0でBest Practicesへ移され、v13.0.0で完全に削除されています。公式の理由は「小さいフォントは可読性の問題ではあるが、これが今日もSEOの懸念であるという兆候は無い」、加えて「この監査は実行と保守の負荷が非常に高かった」というものです。plugins監査もv12.0.0で、SEOの優先事項ではないとして削除されました。Lighthouseのために文字サイズを調整する必要はもうありません。
この移動と削除は配点にも表れています。Best Practicesの監査数はv12.8.2の22からv13.4.1で21に減っており、差分がfont-sizeの削除そのものです。
Accessibilityカテゴリの重み付け（axe-core準拠）と自動検出の限界
Impact×Tagsで決まる76監査の重み
Accessibilityは76監査で、うち18が重み0です。重みはDequeのaxe-coreが各ルールに付けるImpact（深刻度）とTags（分類）の組み合わせで決まり、v13.0.0でこの方式が調整され設定ファイルに明文化されました。
| Impact | wcag A+AA | best-practice（wcagタグ無） | experimental |
|---|---|---|---|
| Critical | 10 | 10 | 0 |
| Serious | 7 | 7 | 0 |
| Moderate | 3 | 3 | 0 |
| Minor | 1 | 0 | 0 |
experimentalのルールは常に重み0です。CriticalとSeriousの是正がスコアに直結するため、コントラスト不足や名前の無いボタンといったCritical級の指摘から潰すのが最短経路になります。
自動検出が保証しない範囲と手動確認が必要な項目
Lighthouseはカテゴリ説明で「自動検出は問題の一部しか検出できず、ウェブアプリのアクセシビリティを保証しない」と明記しています。キーボードのみでの操作完遂、スクリーンリーダーでの読み上げ順序、代替テキストが画像の内容を正しく説明しているか、色以外の手段で情報が伝わるかは、いずれも自動判定できません。alt属性が空文字でもimage-alt監査は通ります。
Accessibility 100点の意味は「機械が検出できる範囲に問題が無い」ことです。WCAG 2.1 AA準拠を要件に掲げるなら、スコアを根拠に据えるのは不十分で、手動確認の記録を別途残す必要があります。
Agentic Browsingカテゴリ｜AIエージェント向け監査の新設（v13.3.0）
llms.txt・WebMCPを含む6監査の内容
v13.2.0で試験的に追加され、v13.3.0（2026年5月7日）で既定設定に入ったのがagentic-browsingカテゴリです。v13.4.0でPageSpeed Insights API呼び出しから一度外され、v13.4.1でLighthouse ViewerがPSI API経由でこのカテゴリを取得するよう再度有効化されました。AIエージェントがページを読んで操作できるかを検査する6監査で構成されます。
| 監査ID | グループ | 検査対象 |
|---|---|---|
| llms-txt | agent-accessibility | llms.txtが推奨形式に沿うか |
| agent-accessibility-tree | agent-accessibility | アクセシビリティツリーの妥当性 |
| webmcp-registered-tools | webmcp | 登録済みWebMCPツールの一覧 |
| webmcp-form-coverage | webmcp | フォームのWebMCP被覆率 |
| webmcp-schema-validity | webmcp | ツールスキーマの妥当性 |
| cumulative-layout-shift | （共用） | CLS（Performanceと同一監査） |
WebMCP関連の3監査はnavigator.modelContextまたはdocument.modelContextの有無を見てページが登録したツールを検出し、v13.4.1でスナップショットモードが外されました。llms.txtというコミュニティ規格が、Googleが配布するツールの監査項目に入った点も見逃せません。規格の内容と書き方はllms.txtとは何か？AIクローラー対応の新たなrobots規格の概要で解説しています。CLSがこのカテゴリにも重み1で入っているのは、レイアウトが動くページではエージェントのクリック対象がずれるためです。
fraction表示の意味と、現時点で対応を優先すべきでない条件
このカテゴリはcategoryScoreDisplayModeがfractionで、0〜100のスコアではなく「6項目中いくつ達成」の分数表示です。他の4カテゴリと同じ土俵で比較する数値ではありません。
公式の説明には「このカテゴリは開発中であり、変更される可能性がある」と書かれています。判断は明確です。一般的なコーポレートサイトやメディアサイトが、いまWebMCP対応に工数を割くべきではありません。ツール登録の仕様が固まっておらず、v13.2.0からv13.3.0までの2バージョンで既に監査の追加と構成変更が起きています。予約や検索のフローをエージェント経由で提供する計画が具体化している場合にのみ、実装検討に進んでください。
一方で、着手して無駄にならないものが2つあります。llms.txtの設置と、アクセシビリティツリーの整備です。前者は静的ファイル1つで済み、後者はagent-accessibility-treeがaxe-coreと同じツリーを参照するため、AccessibilityのCritical級の是正がそのままエージェント対応を兼ねます。
よくある質問
LighthouseのSEOスコアが100なら検索順位は上がりますか？
上がるとは限りません。加えて注意したいのは、SEOスコア100が「インデックスされている」ことの証明にもならない点です。is-crawlableが検査するのはそのURLのrobots.txtとrobotsメタタグだけで、実際にインデックスされたか、canonicalの指定先が意図通りかは判定しません。構造化データのstructured-data監査も重み0の手動確認枠で、内容の妥当性は検証されません。インデックス状況はSearch ConsoleのURL検査で個別に確認してください。
LighthouseにTTIやSpeed Indexは残っていますか？
Speed Indexは重み10で採点対象、TTIは重み0の非表示グループです。TTIはJSON出力には含まれるものの、改善してもPerformanceスコアは動きません。v13ではSpeed Indexも「旧監査の削除」の対象外で、指標としては維持されています。削除されたのは監査項目のほうで、指標の構成は変わっていません。
Best Practicesのスコアを最短で上げる方法は？
重み5のis-on-https、deprecations、third-party-cookiesの3監査から着手してください。各18.5%、合計55.6%です。次がpaste-preventing-inputsで11.1%。逆にCSPやHSTSは重み0なので、スコア目的の作業では成果が出ません。監査名はレポートの英語表記そのままなので、CLIのJSON出力でauditsのキー名を突き合わせると対象を特定しやすくなります。
PageSpeed Insightsの数値がLighthouseと違うのはなぜですか？
ラボ計測の実行環境が違うためです。PageSpeed InsightsはGoogle側のサーバーで実行し、既定のモバイル設定（画面412×823・デバイスピクセル比1.75のMoto G Power相当、mobileSlow4Gの回線制限をsimulate方式で適用）に固定されます。一方DevToolsは手元のマシンのCPUとネットワークが土台になるため、同じページでもスコアはずれます。数値を比較するなら、どちらか一方の環境に揃えて計測してください。
Lighthouseのカテゴリが記事の説明と違うのですが？
DevToolsに載っているLighthouseの版差です（対応は本文の表を参照）。DevTools側の版は差し替えられないため、特定バージョンで検証したい場合はCLIでnpx [email protected]のように固定してください。レポート同士を比較するときも、DevToolsとCLIを混ぜず一方に揃えるのが確実です。
