表示速度はCIで監視する—Lighthouse実運用
サイトの表示速度は、気づいたときにはもう遅い——だから私たちはCIで機械監視しています。Lighthouseをマージ前に走らせ、速度低下を検知する仕組みと、警告と強制の使い分けを実運用から書きました。
サイトの表示速度は、遅くなってから気づくと、もう手遅れです。だから私たちは、機械に見張らせています。
速度は、少しずつ、静かに落ちます。 画像を一枚足す。プラグインを一つ入れる。そのたびに、ほんの少しだけ重くなる。 一回ずつは誰も気づかない。気づいたときには、体感で分かるほど遅くなっている――これが怖いんです。
私たちは社長1名とAI（COO役のClaude Code）だけの会社で、自社サイトを運用しています。 その自社サイトでは、表示速度をCI（継続的インテグレーション）で機械監視しています。
この記事では、Lighthouseをマージ前に走らせて速度低下を検知する仕組みと、 「警告」と「強制」をどう使い分けているかを、実運用から書きます。
🐌速度は、静かに落ちていく
一回の変更では気づけない。気づいたときには、後戻りしにくいほど積み重なっている。
表示速度がやっかいなのは、劣化がじわじわ進むところです。大きな画像を一枚。便利そうな外部スクリプトを一本。 どれも単体では「まあ、これくらい」と思える。その積み重ねが、ある日、無視できない重さになります。
しかも、速度が遅いことのコストは目に見えません。 表示が重いと、待てない訪問者は静かに離脱します。 ページ表示の速さは検索の評価にも関わるとされていて、Googleは体験の指標としてCore Web Vitalsを公開しています。遅さは、機会損失としてあとから効いてくる。
人間が毎回チェックすればいい、とも思えます。でも、続きません。 リリースのたびに手で測るのは面倒だし、忙しいと真っ先に飛ばす工程です。続かない見張りは、無いのと同じ。だから私たちは、これを人の意志から外しました。
🚦CIで、マージの前に測る
変更を本番に入れる前に、Lighthouseを自動で走らせる。人が忘れても、機械は忘れません。
CIというのは、コードを変更するたびに自動でテストや検査を走らせる仕組みです。 私たちはそこに、Lighthouse（Googleが提供するサイト品質の計測ツール）を組み込んでいます。
流れはシンプルです。変更を本番に反映する前の段階で、CIが自動でLighthouseを実行し、 表示速度のスコアを測る。遅くなっていれば、マージする前に気づける。人間が「測るのを忘れた」という事故が、そもそも起きなくなります。
大事なのは、測るタイミングを「本番に入れる前」に置くことです。 公開してから遅さに気づくと、直すのは大ごとになる。 入れる前に止められれば、原因はさっき自分がいじった変更だと、すぐ分かります。 手戻りが、圧倒的に小さくて済むんです。
📏閾値は「今の自分」から決める
満点を目指すのではなく、現状のスコアを基準線にする。そこから下げないことを守る。
よく聞かれるのが、「スコアはいくつを基準にすればいいのか」です。 私たちの答えは、いきなり満点を狙わないこと。 まず今のサイトのスコアを測って、それを基準線にする。そこから下げない、というルールにしています。
理由はシンプルです。理想の高い目標をいきなり課すと、日々の変更が全部ひっかかって、 現場が回らなくなる。基準を「現状維持」に置けば、 少なくとも今より遅くなることは防げます。改善は、そのうえで少しずつ上げていけばいい。
基準線は、上げるときも慎重にします。 一度きつくしすぎると、通すためだけの小細工が増えて、本末転倒になる。 速度監視は、日々のリリースを止めないことと両立して、はじめて続きます。 だから閾値は、痛みの少ないところから少しずつ、が私たちの流儀です。
⚖️「警告」と「強制」を使い分ける
全部を強制で止めると現場が疲れる。守りたい一線だけ強制、あとは警告で気づかせる。
CIのチェックには、大きく二つの効かせ方があります。 一つは警告――スコアが落ちたら知らせるが、マージ自体は止めない。 もう一つは強制――基準を割ったら、マージそのものをブロックする。
最初から全部を強制にすると、現場は疲れます。 少しの誤差でも作業が止まり、そのうち「またか」と軽視されるようになる。 かといって全部を警告にすると、警告は流し読みされて、結局は無視されていきます。
だから私たちは、線を引いています。これ以上はどうしても落としたくない一線だけを強制にして、それ以外は警告にとどめる。 強制は「本当に守りたいものだけ」に絞るほど効く。これは速度に限らず、CIのチェック全般に言えることでした。
🤖一人会社が、速度を機械に任せる理由
人手が限られるほど、注意力は貴重です。だから、機械に任せられる見張りは、機械に渡す。
私たちは、社長1名とAIだけで会社を回しています。 人手が少ないぶん、人間の注意力を、どこに使うかが肝心になる。表示速度の見張りのように、ルールで白黒つけられる仕事は、 人が毎回気にするのではなく、機械に渡してしまうのが正解でした。
速度のチェックは、まさにそういう仕事です。 「今より遅くなっていないか」は、スコアという数字で機械的に判定できる。 だったら、人が覚えておく必要はない。 CIに一度組み込んでしまえば、あとは変更のたびに勝手に測ってくれます。
これは速度に限った話ではありません。 私たちは、人の意志に頼ると続かないことを、片っ端から仕組みに移すという考え方で会社を運用しています。 速度監視をCIに載せたのも、その一環でした。 少人数だからこそ、忘れても回る形にしておく価値は大きいんです。
🧩まず始めるなら、ここから
いきなり強制ゲートは重い。最初は「測って警告するだけ」から。仕組みを軽く回す。
これから速度監視を始めるなら、順番が大事です。 最初から強制でブロックしようとすると、設定も運用も一気に重くなる。 だから私たちは、まず測って警告するだけの状態から始めることをおすすめします。
測る習慣がついて、スコアのぶれ方が分かってきてから、強制に上げる一線を決める。 仕組みは、軽く回し始めて、少しずつ育てるほうが根づきます。 最初から完璧に組もうとすると、たいてい途中で息切れします。
速度は、人の意志では守り切れません。 でも、機械に見張らせる形にすれば、忘れても大丈夫になる。 まずは自分のサイトの「今のスコア」を一度測るところから、始めてみてください。 基準線は、そこから引けます。
開発パートナーを探していますか？
AIでプロダクトを最速で形にしませんか？
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する