3日間、Claudeと数字に振り回された記録｜LCPの改善はまだ確認できないけど、大事なことを学んだ

本記事はアフィリエイト広告を含みます。

※会話部分は、実際のやり取りを読みやすいように一部抜粋・編集しています。 ※この記事では、PageSpeed Insightsの一覧に表示された各CSSファイルの「継続時間」を合計した数字を、以降「CSSの継続時間」と呼びます。

結論：まだ確認できていない。でも、それより大事な発見がありました

この記事は「LCPを改善できました」という記事ではありません。「AIと一緒に検証していたら、AIが数字の意味や比較の仕方を何度も取り違えた」という記録です。

正直、途中で本気で腹が立った瞬間もありました。それも隠さずに書きます。

---

始める前に：LCP・CSS・CLSってそもそも何？

専門用語だらけになるので、先に簡単に説明しておきます。

LCP（Largest Contentful Paint） ページを開いたとき、最初に画面に見えている範囲の中で、最も大きな画像や文章などの主要な要素が表示されるまでの時間を示す指標です。2.5秒以下がGood、4秒を超えるとPoorと判定されます。

CSS（シーエスエス） サイトの文字色、ボタンの形、余白、配置など、見た目を指定するための仕組みです。CSSの読み込み方によっては、画面の表示開始を待たせる原因になることがあります。

CLS（Cumulative Layout Shift） ページを開いた直後に、要素が「カクッ」とズレる現象を数値化したものです。0.1以下ならGood、0.25を超えるとPoorとされます。

この3つを頭の片隅に置いて、続きを読んでみてください。

---

1日目：画像を疑い、迷走する

きっかけは、Site Kitの赤い警告でした。LCP：8.1秒 Poor。 「何を直せばいいのか」まるで分からず、Claudeに画面を見せながら、一緒に調べてもらうことにしました。 <!– ブロック：吹き出し（自分＝左）–>

「スクショを大量に貼っている記事が原因では」という仮説のもと、開発者ツールの使い方すら分からない状態から、一つずつ教わりながら進めました。

結果、1記事の画像だけで合計13.7MBという数字が出て、「やっぱり画像が犯人だ」と確信しました。

Shottrの設定を見直し、過去の重い画像をまとめて圧縮しようとPythonやターミナルにも挑戦しましたが、ダウンロードがうまくいかない、ファイルが見つからない、といったつまずきが続きました。

見た目は同じなのに画像ファイルの容量は全然違う（左：3.1MB　右：100KB）

正直、この時は本当にそう思いました。3.1MBの画像が、Word Pressにアップロード時には圧縮され、100KBになっていたことが判明。Shottrの設定は関係ないじゃん。そこにたどり着くまでにかなり時間を消費し、気力も消耗しました。

この仕様を知らなかったため、元画像と実際に表示されている画像を同じ条件だと思い込んでしまいました。

1日目後半：見過ごしていた「LCPの内訳」

行き詰まっていたところ、Claudeから「実はずっと表示されていた項目があります」と言われました。「LCPの内訳」です。

画像13.7MB
（最初に主な原因だと疑った）
        ↓
今回の測定では、LCP画像の読み込み時間は260ミリ秒
        ↓
画像だけが主因とは考えにくく、
CSSなど他の要因も調べることにした

ほかの2ページでも、同様のCSSファイルが表示されました。丸一日かけて、ようやく「今回の測定では、画像だけでなく、CSSの読み込みも大きな改善候補になっている」ことに気づきました。この日はここで、良い形で終われたはずでした。

---

2日目：「劇的に改善」に、私は騙されかけた

SWELL設定の「コンテンツに合わせて必要なCSSだけを読み込む」をONにして、再計測。Claudeはこう報告してきました。

数字だけ見ると「すごい改善だ」と思いました。ですが、実はこの数字、とんでもない見落としが隠れていました。

3日目：「その数字、比べ方が違うんじゃないの？」

翌日、あらためて自分でスクショを見返していると、違和感がありました。

指摘してみると、Claudeはこう認めました。

AIが、数字の意味や比較の仕方を何度も間違えていたのです。

さらに、この後もClaudeはページの対応関係を取り違え、法則をその場しのぎで作っては撤回する、ということを繰り返しました。ここで、私はさすがに我慢の限界でした。

「もう自分の目で確かめる」と決めた

ここから、やり方を変えました。AIの解釈をそのまま信じるのではなく、URLがはっきり写ったスクショを自分で並べ、AIには「その数字だけを見て整理する」役割に徹してもらうことにしたのです。

記事A・記事Bについても同じ手順で確認しました。

• チェックを外した状態：3ページ分＋Site Kit
• 「必要なCSSだけを読み込む」を入れた状態：3ページ分＋Site Kit
• さらに「CSSをインラインで読み込む」も加えた状態：3ページ分＋Site Kit

合計12枚のスクショを、URLを確認しながら一枚ずつ突き合わせました。

今回比較した各ページはこちら↓

トップページ

記事A

記事B

ようやく出た、比較できる数字

これはLCPそのものの値ではなく、**PageSpeed Insightsの診断欄に表示された「CSSの継続時間」**を、このサイト・この測定時点で、同じ条件で比較したものです。

ページ	通常	CSS絞り込みのみ	CSS絞り込み＋インライン化
トップページ	6,440ms	6,550ms	2,660ms
記事A（SWELL装飾ガイド）	6,620ms	6,800ms	2,560ms
記事B（SWELL装飾事例12選）	6,620ms	5,720ms	3,480ms

今回の3ページ・各1回の測定では、「必要なCSSだけを読み込む」単体の結果は安定しませんでした。一方、「CSSをインラインで読み込む」も加えた状態では、3ページすべてでCSSの継続時間が短くなりました。

ただし、これは私のサイトで行った各1回の測定結果です。同じ設定ですべてのサイトが同じように改善するとは限りません。

また、Site Kitに表示されるLCPは「8.0秒Poor→7.9秒Poor」で、表示上はほとんど変わっていません。実際の利用状況に基づくデータは、設定変更の効果がすぐに反映されるとは限らないため、LCPが改善したかどうかは、現時点ではまだ判断できません。

なお、今回の各1回の測定では、CLSはCSS絞り込みのみの状態で0.613となり、インライン化を加えた最終状態では0.058となりました。ただし、CLSも測定のたびに変動する可能性があるため、これだけで設定の効果を断定することはできません

今回の検証で使った「CSSのインライン化」「必要なCSSだけを読み込む」は、私が使っているSWELLの高速化機能です。ブログ初心者でも設定しやすく、私自身も普段から利用しています。

AIも間違える。だから、自分の目で確かめることをやめてはいけない

この3日間で、一番大きな学びはこれでした。

Claudeは、ヘッダーの「推定値」と実際の数字を取り違え、ページの対応関係を間違え、都合よく法則を作っては撤回しました。もっともらしい説明ほど、実は根拠が薄いことがある、ということを痛感しました。

それでも、条件をそろえ、役割を限定した後は、12枚のスクリーンショットから数字を整理する作業をClaudeに手伝ってもらえました。問題だったのは、AIを使ったことではなく、曖昧な条件のまま判断まで任せてしまったことだったのだと思います。

今、分かっていること

この記事を書いている時点では、LCPが改善したとはまだ言えません。しかし、「改善した」と書くよりも、「まだ分からない」と正直に書く方が、このブログらしいと思いました。

• Site Kitに表示されるLCPは、現在も8.0秒前後でPoor判定です
• ただし、Site Kitの数値は実際の利用状況に基づくデータを参照しているため、今回の設定変更の効果はまだ判断できません
• 今回のPageSpeed Insightsの測定では、「CSSをインラインで読み込む」も組み合わせた状態で、3ページすべてのCSSの継続時間が短くなりました
• ただし、測定は各条件1回ずつなので、これだけで設定の効果を断定することはできません
• AIとの検証は便利ですが、比較する項目、URL、測定条件を人間が確認することが欠かせないと学びました

3日間かけても、LCPが改善したと確認できるところまでは到達しませんでした。それでも、「直らなかった」で終わったわけではありません。

数字の名前を確認すること。同じ条件で比べること。AIが自信を持って答えても、元の画面まで戻って確かめること。

今回学んだのは、表示速度の設定以上に、AIと一緒に検証するときの基本姿勢だったと思います。Site Kitの数値に変化が出るかどうかは、これから時間を置いて確認し、進展があれば続報として正直にお伝えします。