平均パフォーマンススコア：最も引用されたもの vs 最も引用されなかったもの。76.5 vs 74.9。
高速でパフォーマンスの高いサイトはやや多く引用される：最も引用されたドメイン の平均パフォーマンススコアは76.5であるのに対し、最も引用されなかったドメインは74.9である。サイト速度は期待される方向で引用頻度と相関するが、その効果は小さい。
サイトパフォーマンススコア vs 引用頻度
引用されたすべてのドメインを、AmICitedの追跡プロンプト応答で引用された回数でグループ化し、Googleの実ユーザーCore Web Vitals データを結合すると、一貫したパターンが各階層に現れる。10回以上引用されたもの（データのある659ドメイン）が一方の端に位置し、1〜2回引用されたもの（4,313ドメイン）がもう一方の端に位置する。方向性は測定可能なすべての健全性指標（合格率、サーバー応答時間、パフォーマンススコア）で同じであり、これが（控えめではあるが）ノイズではなく信頼できるシグナルである理由である。
基礎となる数値
| 引用頻度 | CrUXデータのあるドメイン数 | Core Web Vitals合格率 | TTFB中央値 | 平均パフォーマンススコア |
|---|---|---|---|---|
| 10回以上引用 | 659 | 60% | 804 ms | 76.5 |
| 3〜9回引用 | 1,584 | 58% | 893 ms | 74.9 |
| 1〜2回引用 | 4,313 | 57% | 910 ms | 74.9 |
AI検索の可視性にとっての意味
技術的に健全なページはやや多く引用される傾向にあるが、その効果は小さい。サイトの健全性は、AIエンジンがあなたを引用するかどうかの主要な要因ではなく、補助的な要因のように見える。コンテンツの関連性の方がほぼ間違いなく重要である（ソース別およびトピック別のレポートを参照）。実用的な解釈：Core Web Vitalsとサーバー応答時間の修正は行う価値がある——軽度の逆風を取り除き、ユーザーにも役立つ——しかし、それだけでAIエンジンの引用ソースに加われるわけではない。これを参加条件（テーブルステークス）と捉え、その上で関連性で競争しよう。
PageSpeedスコアが実際に測定するもの（そしてAIエンジンが気にすること）
GoogleのPageSpeedパフォーマンススコアは合成指標である——制限された接続でページ読み込みをシミュレートし、ページが視覚的に完全になりインタラクティブになるまでの速さを測定する。実世界のパフォーマンスの有用なプロキシではあるが、AIクローラーが体験するものとは同じではない。
GPTBot（OpenAI）、PerplexityBot、Google-ExtendedのようなAIクローラーはページを視覚的にレンダリングしない。彼らはHTML を取得し、テキストコンテンツを抽出し、自然言語パイプラインで処理する。PageSpeedのうち彼らにとって最も重要な側面は以下の通りである：
サーバー応答時間（TTFB ）： サーバーが最初のHTMLバイトを配信する速さ。サーバーが遅いと、クローラーはコンテンツを待つ時間が長くなり、タイムアウトや不完全な取得を引き起こす可能性がある。
HTMLのサイズと複雑さ： 肥大化したHTML（過剰なインラインスタイル、大きなDOM）は、レンダリングを行わないクローラーでも解析に時間がかかる。
可用性と信頼性： 5xxエラーを返したり、負荷でタイムアウトするページは、コンテンツの質に関わらず正常にクロールされない。
AIクローラーにとって最も重要でないPageSpeedの側面は、画像最適化、JavaScript実行時間、レイアウトシフト指標、インタラクティブ性の測定である。これらは人間の訪問者にとっては重要だが、テキスト抽出クローラーには無関係である。
つまり、特にAI可視性 のために最適化する場合、フロントエンドの最適化（画像圧縮、遅延読み込み、CSSの最小化）よりも、サーバーサイドのパフォーマンス（TTFB、HTML配信、エラー率）を優先すべきである。両者は相関している——適切に最適化されたサイトは両方とも優れている傾向がある——しかし、限られたエンジニアリング時間しかない場合は、サーバーサイドに集中しよう。
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
1.6ポイントの差のコンテキスト
PageSpeedスコアの1.6ポイントの差（76.5 vs 74.9）は非常に小さい。参考までに、共有ホスティングプランから専用VPSに切り替えると、PageSpeedスコアは10〜15ポイント変動する可能性がある。CDNを有効にすると5〜8ポイント追加できる。最も引用されたドメインと最も引用されなかったドメインの差がわずか1.6ポイントであるという事実は、引用されたセットの中ではパフォーマンスが意味のある差別化要因ではないことを意味する。
これは、Core Web Vitals分析全体にわたるより広範な発見と一致している：AIエンジンはパフォーマンスではなく、主にコンテンツに基づいてソースを選択している。遅いがトピックに関して独自の権威があるページは、速いが一般的なページよりも引用される。実用的な意味は、70+の範囲に入ったらPageSpeedスコアに過度にこだわるべきではないということだ。AI可視性のためのパフォーマンス改善のROIは、その時点で急激に低下する。
実用的な推奨事項
まずPageSpeedスコアを50以上にする。 「poor」の範囲（モバイルで0〜49）にいる場合、人間の訪問者とAIクローラーの両方に影響を与えるサーバーサイドの問題がほぼ確実に存在する。これが最もROIの高いパフォーマンス作業である。
「十分良い」の閾値として70+を目標にする。 スコアが70台になれば、AIに引用されるページが存在する範囲に入る。それ以上の改善はAI引用に対して限界的な効果しかない。
PageSpeed内のサーバーサイド指標に焦点を当てる。 TTFB、サーバー応答時間、「初期サーバー応答時間の削減」監査に注意を払う。これらはPageSpeedのうちAIクローラーの体験に最も直接的に影響する側面である。
AI可視性のために90+を追い求めない。 90+のスコアは印象的で人間の訪問者には利益をもたらすが、我々のデータは70+で得られる以上の追加の引用メリットがあるという証拠を示していない。
方法論
これはAIがすでに引用しているページ間の関連性であり、因果関係の証明ではない：Google CrUX / PageSpeedのフィールドデータを、各ドメインがAmICitedの1,905の追跡プロンプト全体で引用された頻度と結合して計算される。CrUXデータは8,845の引用ドメイン中6,556（74%）で利用可能であった。ドメインは引用した応答数でグループ化され、各グループ内でサイト健全性指標の平均が取られる。ドメインが「Core Web Vitalsに合格」するのは、その監査対象URLの過半数が実ユーザー（CrUX）データでGoogleのLCP /INP /CLSの閾値を通過した場合である。TTFBとパフォーマンススコアも同様に平均化される。十分なCrUXデータがないページは除外される。AmICitedのプロンプトはSaaS、Eコマース、サポートトピックに偏っているため、これらの数値はその種のクエリで引用されるサイトを説明している。この関係は実際に存在するが控えめであり、相関関係である——高速なページが原因で引用が増えると主張しているわけではない。
