--- title: "Lighthouseスコアの見方と改善方法｜Best Practices・SEOの配点と5カテゴリ" url: "https://www.issoh.co.jp/column/details/2354/" published: 2024-06-06 updated: 2026-10-12 categories: ["SEO"] publisher: "株式会社一創" --- # Lighthouseスコアの見方と改善方法｜Best Practices・SEOの配点と5カテゴリ 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年版】](/column/details/3761/)で確認できます。 ### 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による継続的なパフォーマンス監視の重要性](/tech/details/7542/)で扱っています。 ## 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）の違いを徹底比較する](/tech/details/7543/)で整理しています。 TTIは重み0の非表示グループに残り、レポートUIには出ませんがJSON出力には含まれます。「TTIが消えた」も「TTIが採点されている」も不正確です。各指標の定義は[Webパフォーマンス指標の一覧と使い分け｜TTFB・FCP・TBT・Speed Indexの基準](/column/details/3761/)にまとめています。 ### 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割はスコアに寄与しません。 ### スコアの55.6%を占めるis-on-https・deprecations・third-party-cookies 重み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規格の概要](/column/details/6984/)で解説しています。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 lighthouse@13.4.1`のように固定してください。レポート同士を比較するときも、DevToolsとCLIを混ぜず一方に揃えるのが確実です。 ## 関連記事 - [コアウェブバイタルとは？3指標（LCP・INP・CLS）の基準と改善方法【2026年版】](/column/details/3761/) - [Webパフォーマンス指標の一覧と使い分け｜TTFB・FCP・TBT・Speed Indexの基準](/column/details/3761/) - [CI/CD環境におけるLighthouse CIによる継続的なパフォーマンス監視の重要性](/tech/details/7542/) - [llms.txtとは何か？AIクローラー対応の新たなrobots規格の概要](/column/details/6984/) - [INPとFID（First Input Delay）の違いを徹底比較する](/tech/details/7543/) --- 出典: [Lighthouseスコアの見方と改善方法｜Best Practices・SEOの配点と5カテゴリ]()（株式会社一創）