PageSpeed Insights APIとLighthouseで、表示速度の改善メニューを作る──Claude Codeで計測を定点化し、点数ではなく「直した項目と再計測の記録」を売る
この記事は、PageSpeed Insights APIとLighthouse、Claude Codeを使って、表示速度の改善を月額や単発のメニューにする方法を扱います。
「スコアを90点にしてほしい」と頼まれる
顧客が自分でPageSpeed Insightsを開き、赤い数字を見て連絡してきます。
「この点数を上げてほしい。いくらでできますか」。
点数で受けると、測るたびに数字が動き、終わりが決まりません。
直した手間に関係なく、点数が届かなければ不満が残ります。
点数の約束で赤字になる理由と、Core Web Vitalsの見方は、別の記事で扱いました。
▶ Core Web Vitals改善の受託は「点数の約束」で赤字になる──LCP・INP・CLSの公式しきい値と、28日集計を前提にした契約
この記事は、その上で、計測と改善を「作業の記録」として売る組み方です。
表示速度の改善メニューとは、同じ条件で定点計測し、直す項目を選んで手を入れ、再計測の記録で結果を示すサービスである
黒字化の外科医です。PageSpeed Insights APIとLighthouseを使った改善メニューを、計測の仕組みから解剖します。
この形で売るべき理由は、三つあります。
第一に、点数は、制作会社の作業以外の理由でも揺れるから。
Lighthouseの公式ドキュメントは、点数の揺れの多くはLighthouse自体が原因ではないとし、広告やA/Bテスト、通信経路、端末、ブラウザ拡張、ウイルス対策ソフトなどを挙げています。
第二に、計測の条件をそろえないと、改善したかどうかを示せないから。
端末の種類、計測する時期、回数を決めておかなければ、前後の比較になりません。
第三に、計測は、人がやるより機械にやらせる方がそろうから。
APIとスクリプトで同じ条件の計測を繰り返し、AIには結果の読み込みと直す候補の整理を任せます。
PageSpeed Insights APIとLighthouseで確認できたこと
2026年10月29日に、公式ドキュメント（developers.google.com の PageSpeed Insights API の Get Started と runPagespeed のリファレンス、developer.chrome.com の Lighthouse の概要と Performance スコアの説明）で確認した内容です。
【PageSpeed Insights API】
・GET https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=〔URL〕
・APIキーなしでも使えるが、頻繁な自動の計測にはキーが推奨されている
・strategy は DESKTOP か MOBILE。指定しないとデスクトップで計測される
・category を指定しないと、Performance だけが計測される
・lighthouseResult：Lighthouseによる、その場の計測（ラボデータ）
・loadingExperience：Chromeの実際の利用者のデータ（フィールドデータ）
・公式は、このAPIでの実利用者データの提供をやめる予定とし、CrUX API などを勧めている
【Lighthouse】
・ChromeのDevTools、コマンド（npm install -g lighthouse）、Nodeのモジュール、PageSpeed Insightsで実行できる
・lighthouse 〔URL〕 --output json --output-path 〔保存先〕 でJSONに保存できる
・Lighthouse 10の Performance の重み：FCP 10％、Speed Index 10％、LCP 25％、TBT 30％、CLS 25％
・点数の色：0〜49 赤、50〜89 橙、90〜100 緑モバイルで見たいなら、strategy=MOBILE を必ず付けます。付け忘れると、デスクトップの数字を顧客に見せることになります。
Claude Codeに任せる部分、人が決める部分
【スクリプト】決めたURLを、決めた条件（MOBILE、回数）で計測し、JSONを日付つきで保存
【Claude Code】JSONの audits から、時間の大きい項目を拾い、対象のファイルや画像を特定する下調べ
【人】直す項目を選び、見た目や機能への影響を確かめ、顧客に説明するClaude Codeは、テーマのコードや画像の一覧を読んで「どのファイルが重いか」を調べるのが得意です。
一方で、画像を圧縮してよいか、スクリプトを遅らせて計測タグが動くかは、人が画面で確かめます。
今すぐ試せる：計測結果から直す候補を整理するプロンプト
私はWeb制作会社のエンジニアです。PageSpeed Insights API（strategy=MOBILE）の lighthouseResult のJSONを、同じURLで〔回数〕回分渡します。
（顧客名は伏せています）
1. 回ごとの Performance の点数と、LCP・TBT・CLS の値を表にし、中央値を出す。計算式を添える。
2. audits のうち、改善の余地が大きいと示されている項目を5つ以内で挙げ、対象のファイルや要素を書く。
3. 各項目について「直したときに見た目・機能で確かめること」を1つ添える。
4. 点数がいくつになるかは予測しない。速度改善工場：メニューの形と時間の計算
3つのメニュー
診断（単発）：定点計測の設定、直す候補の一覧、優先順位の説明
改善（単発）：選んだ項目の修正、修正前後の再計測、変更の記録
定点観測（月額）：月1回の計測、前月との比較、悪化した項目の報告約束するのは「直した項目」と「同じ条件での再計測の記録」です。点数は約束しません。
計算例：診断の作業時間（数字はすべて例）
計測の設定（初回のみ）：1.5時間
Claude Codeの下調べの確認：1時間
候補の選定と説明資料：1.5時間
合計：1.5 ＋ 1 ＋ 1.5 ＝ 4時間 × 7,645円 ＝ 30,580円（原価）この原価に、自社の目標の粗利を乗せて診断の価格を決めます。
構造的なリスク
逆説を指摘しておきます。
計測を自動にすると、点数が毎月届くようになります。
届くほど、顧客は点数の上下だけを見て一喜一憂します。
だから、報告は点数ではなく、LCPなどの指標と、直した項目の一覧から書きます。点数の揺れの理由も、最初の契約の時点で説明しておきます。
よくあるQ&A
Q. 実際の利用者のデータは、これからどう見るか？
PageSpeed Insights APIでの提供はやめる予定と公式にあるため、CrUX API など公式が勧める方法を、計測の設計に入れておきます。
Q. 計測は何回すればよいか？
公式に決まった回数はありません。社内で回数と時間帯を決め、毎回同じ条件で測ります。
Q. 保守契約に入れるべきか？
月1回の定点観測なら、保守の項目に入れやすい作業です。修正の作業は別に見積もります。
▶ 保守にClaude Codeを入れたら、月額はどう見直すか──値下げだけで返さず「範囲・速さ・一部還元」の3つから選ぶ、1サイトの原価の計算例
最後に
表示速度の改善は、点数を売るほど赤字に近づきます。
同じ条件で測り、直した項目と再計測の記録を渡すと決めた会社だけが、終わりのある速度改善を、利益の出るメニューにできるのです。
計測スクリプトの雛形と、報告書の型は、計測・改善の自動化レシピ集にまとめました。
これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。
#Web制作会社 #ClaudeCode #PageSpeedInsights #Lighthouse #表示速度 #CoreWebVitals #制作会社経営 #中小企業 #保守 #AI駆動開発
