アカデミー · 監査

AmICitedでCore Web Vitalsを確認する方法

AmICitedのWeb Vitals監査を使用して、Chrome UXレポートから取得したホームページのCore Web Vitals(LCP、INP、CLS、FCP、TTFB)を競合他社と比較しながら確認する方法をご紹介します。

1 min read · Medium priority

AmICitedでCore Web Vitalsを確認する方法 — video walkthrough

高速で安定したページはAI可視性にとっても重要です。回答エンジンは読み込みの速い情報源を好みます。AmICitedの監査を詳しく見る前に、Core Web Vitalsが実際に何を測定しているのか、そしてページ速度の問題がなぜ静かにAI引用の問題へと変わりうるのかを理解しておくと役立ちます。

Core Web Vitalsとは何か

Core Web Vitals は、実際のページエクスペリエンス を定量化するためにGoogleが策定した標準化された指標群です。ページのメインコンテンツがどれだけ速く表示されるか、入力に対してどれだけ速く応答するか、読み込み中に視覚的にどれだけ安定しているかを測定します。これらの指標は、「サイトが遅く感じる」という曖昧な感覚を、追跡・比較でき、エンジニアリングチームに責任を持たせられる数値に置き換えることを目的として設計されました。Googleは数年前からこれらを検索ランキングシグナルに組み込んでおり、実際のChromeユーザーからChrome UXレポート(CrUX)を通じて収集される同じ基礎データが、AI回答エンジンがどの情報源を取得・レンダリング・引用するかにますます影響を与えるようになっています。

3つの中核指標は、Largest Contentful Paint(LCP)、Interaction to Next Paint(INP)、Cumulative Layout Shift(CLS)で、それぞれにGoogleが公開・定期的に更新する合否のしきい値が設定されています。補助的な2つの指標、First Contentful Paint(FCP)とTime to First Byte(TTFB)は、サーバーがどれだけ速く応答するか、メインコンテンツの準備が整う前でも何かがどれだけ速く表示されるかを切り分けることで、ページ速度 の全体像を補完します。CrUXは匿名化されたフィールドデータ——実際のChromeユーザーによる実際の訪問——から構築されているため、その数値は高速なオフィス回線での単発のラボテストではなく、実際の条件(デバイスの内訳、ネットワーク品質、地理的分布)を反映しています。

これが生成エンジン最適化(GEO) にとってなぜ重要なのでしょうか。AIクローラーや、AI Overviews、ChatGPT検索、Perplexityの背後にある検索システムは、あなたのページを引用する前に取得・解析する必要があります。タイムアウトする、読み込みが遅い、読み込み中にコンテンツがずれるといったページは、大規模にクロールするコストが高く、クリーンなコンテンツを抽出する信頼性も低くなります。特にTTFBが遅いと、メインコンテンツが到達する前にクローラーが取得を諦めてしまうことがあります。これは引用されるかどうかを決める支配的な要因ではありません——コンテンツの関連性、権威性、構造の方が遥かに重要です——しかし、慢性的に遅く不安定なホームページは、より高速な競合が同じ情報を提供している以上、回答エンジンがあえて許容する理由のない摩擦要因なのです。

これはまた、テクニカルSEO と回答エンジン最適化がほぼ完全に重なるケースでもあります。Googleのランキングを改善するのと同じエンジニアリング上の修正——画像サイズの最適化、サーバー応答時間、レイアウトの安定性——が、あなたのページをAIシステムにとってもアクセス可能かつ引用可能な状態に保つのです。この重なりこそが、AmICitedがCore Web Vitalsを単体のSEOツールとしてではなく、より広範なAI可視性 監査の中に組み込んで表示している理由です。これは、AIエンジンがあなたのサイトを信頼でき扱いやすいと判断するかどうかを左右する一つの要素なのです。

確認場所

左側のナビゲーションからAudit → Web Vitalsを開きます。ページには次のように説明されています。*「ドメインのホームページのCore Web Vitals…ページ速度はGoogleのランキング要素であり、AI回答エンジンは読み込みの速いページを好みます。」*AmICitedは、追跡中のドメインと監視中の各競合について、このデータを自動的に取得するため、別のツールを実行したりURLを手動で貼り付けたりする必要はありません。プラットフォーム内の他の場所でシェア・オブ・ボイス や引用ランクの追跡に使っているのと同じ競合セットが使われます。

競合比較表付きのWeb Vitals監査画面

Note
これらはChrome UXレポート(実際の訪問者データ)に基づいています。新しいドメインやトラフィックが少ないドメインでは、フィールドデータがまだ十分に蓄積されていないため、単純に空欄()が表示される場合があります。

CrUXは、あるURLについて安定した数値を公開する前に一定量の実際のChromeトラフィックを必要とするため、トラフィックの少ないドメイン——多くのB2Bサイトやニッチなサイトを含む——では、一定期間空欄が表示されることがあります。これは想定内の挙動であり、バグではありません。Googleが信頼できる数値を報告するのに十分なフィールドデータをまだ蓄積していないことを意味しており、トラフィック(または時間)が積み重なれば表示されるようになります。

各指標の意味

競合比較表には、各ドメインについて以下が表示されます。

  • スコア — Core Web Vitalsの合否を示す総合サマリーで、ドメインがGoogleのしきい値を全体的にクリアしているかどうかを一目で把握できます。
  • LCPLargest Contentful Paint)— メインコンテンツ、通常はビューポート内で最も大きな画像やテキストブロックがどれだけ速く読み込まれるかを示します。訪問者——あるいはクローラー——が「このページはもう準備できているか」を判断する上で、最も直接的に結びつく指標です。
  • INP(Interaction to Next Paint)— ユーザーが実際にページを操作した(クリック、タップ、入力)ときに、ページがどれだけ応答性良く感じられるかを示します。最初の操作だけでなく、ページ訪問全体を通じた応答性を捉えるため、旧来のFirst Input Delay指標に代わって導入されました。
  • CLS(Cumulative Layout Shift)— ページが読み込み中にどれだけ視覚的に安定しているかを示します。CLSが高いと、画像・広告・フォントが読み込まれる際に要素が飛び跳ねるように動き、訪問者にとって煩わしいだけでなく、自動化システムがコンテンツを一貫して解析することも難しくなります。
  • FCP(First Contentful Paint)— メインコンテンツの準備が整う前でも、画面に何かが最初に表示されるまでの速さを示します。空白の画面のままではなく、そもそもページが読み込まれつつあることを示す早期のシグナルです。
  • TTFB(Time to First Byte)— サーバーの応答速度です。ページをリクエストしてから最初の1バイトを受け取るまでの時間を指します。これはほぼ完全にバックエンド・インフラ側の指標であり、多くの場合、ホスティング、キャッシュ、CDNの変更で最も修正しやすい指標です。

自身のドメインはYouとして表示され、その下に追跡中の競合他社のホームページが並びます。そのため、すべての指標が単独ではなく、常に比較可能な形で確認できます。

活用方法

  1. 競合とベンチマークする。 競合のページの方が速い場合、それは検索とAI回答の両方において競合が持つもう一つの優位性であり、コンテンツや権威性に関する取り組みに比べれば安価に埋められる差でもあります。
  2. 赤色の項目を修正する。 LCPやCLSの不合格は、具体的なエンジニアリング作業が必要であることを示しています。よくある原因は、サイズの大きすぎるヒーロー画像、width/height属性の欠落、レンダリングをブロックするスクリプト、最適化されていないWebフォントなどです。
  3. TTFBが遅い場合は優先的に対処する。 TTFBは他のすべての指標より上流に位置するため、TTFBが遅いとLCPも引きずられて悪化します。また、コンテンツの書き直しよりも、キャッシュ、CDN、ホスティングのアップグレードによって最も速く改善できることが多い指標でもあります。
  4. 変更後に再確認する。 フィールドデータが更新されたら、改善が反映されているかを確認しに戻りましょう。CrUXのデータは過去28日間のローリングウィンドウで集計されるため、変更が反映されるまでには時間がかかります。デプロイの翌日に数値が動くことは期待しない方がよいでしょう。
  5. TTFBを早期警告シグナルとして扱う。 最初の1バイトを返すのに1秒以上かかることが常態化しているサーバーは、この監査だけにとどまらない、クロールやレンダリングの問題を抱えている可能性が高い候補です。クローラーエンジニアたちが、高速なTTFBを信頼できるAIクローラー成功のためのしきい値 として、あれば望ましい程度のものではなく必須要件とみなすようになりつつある理由を読んでおく価値があります。

これら4つの指標は、技術的な取り組み全体から切り離されて単独で機能するものではありません。Core Web Vitalsのスコアが良好でも、robots.txtでAIクローラーをブロックしていたり、JavaScriptを実行しないクライアントにほぼ空のページを配信していたりするホームページは、それでも引用されません。速度が役立つのは、クローラーが実際にアクセスを許可され、そこにあるものを解析できて初めてのことです。だからこそ、この監査は一度きりの修正としてではなく、より広範なルーティンの中の一つのチェックポイントとして扱う価値があります。クロール可能性、構造化データ、コンテンツの抽出可能性を網羅する、より広範な技術監査チェックリストを定期的に見直すのと同じように、この監査もAmICitedの他の監査と並行して定期的に実行しましょう。

Web Vitals単体で引用を勝ち取れるわけではありませんが、遅く不安定なページはあなたの足を引っ張りかねません。この監査は、AIエンジンが選択肢として比較しているサイトと比べて、あなたが今どの位置にいるかを教えてくれます。この推奨事項の背後にあるより深い調査を知りたい場合は、ページ速度が実際にAI検索の可視性に影響するかどうか を読み、クロール可能性の側面をカバーするために、より広範なAIアクセシビリティ監査 とこのチェックを組み合わせて実施してください。そこから自然な次のステップとして、Web VitalsをAmICitedのAIランクトラッカー や引用トラッキングと並ぶ定期的なモニタリングサイクルに組み込みましょう。そうすることで、言及数の低下に気づくのと同じタイミングでパフォーマンスの低下も検知でき、数週間後にすでに可視性を失った状態で別々に発見することを防げます。

← すべてのアカデミーチュートリアル

実践する準備はできましたか?

無料チェック · 7日間お試し · クレジットカード不要