TTFB中央値：最も引用されているドメイン vs 最も引用されていないドメイン 。804 vs 910 ms。
最も引用されているドメインはサーバーの応答が速い：10回以上引用されたページのTTFB中央値は804ms、一方で1〜2回しか引用されていないページは910ms。サーバーの応答が遅いことは引用数の減少と関連しているが、その差は緩やかなものである。
サーバー応答時間（TTFB）と引用頻度
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エンジンの引用ソースに加われるわけではない。これを参加条件（テーブルステークス）と捉え、その上で関連性で競争しよう。
TTFBがAI引用において最も重要な速度指標である理由
分析したすべてのパフォーマンス指標の中で、Time to First Byteは最も引用されているドメインと最も引用されていないドメインの間で最大の絶対差を示している：106ミリ秒（804ms vs 910ms）。これは偶然ではない。TTFBはサーバーサイドのパフォーマンスに最も直接的に結びつく指標であり——AIクローラーがあなたのページを取得する際にまさに対話する要素なのだ。
GPTBotのようなAIクローラーがページをリクエストするとき、ヒーローイメージ、CSSアニメーション、JavaScriptバンドルには関心がない。関心があるのはただ一つ：テキストを抽出して関連性を判断するために必要なHTML コンテンツをどれだけ早く取得できるかである。TTFBが遅いということは、クローラーが待機していることを意味し——待ち時間が長すぎると、タイムアウトしたり、部分的な応答しか取得できなかったり、将来のクロールでドメインの優先順位が下がったりする可能性がある。
106msの差は絶対値としては緩やかである——まばたきするくらいの時間だ——しかし、数千のドメインにわたって一貫しており、予想される方向に沿っている。最も妥当なメカニズムはクロール効率の効果である：サーバーが高速であれば、より完全に、より頻繁にクロールされるため、そのコンテンツはAIエンジンが参照する検索インデックスにより十分に反映される。これは因果関係が証明されたわけではないが、TTFBが最も強いパフォーマンスシグナルを示す理由として最も首尾一貫した説明である。
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
TTFBと他のパフォーマンス指標の比較
LCP 、FCP、CLS のようなフロントエンド指標とは異なり、TTFBはほぼ完全にサイト運営者のコントロール下にある。TTFBは以下に依存する：
- サーバーインフラストラクチャ： ホスティングの品質と場所
- CDNの設定： CDNを使用しているかどうか、およびその設定方法
- キャッシュ戦略： ページがキャッシュから配信されるか、動的に生成されるか
- バックエンドの効率性： CMSやアプリケーションサーバーがHTMLを生成する速度
このため、TTFBはAI可視性のためのパフォーマンス改善において最も実用的な指標である。LCPの改善にはページレイアウトの再設計が必要かもしれないが、TTFBの改善は設定変更のみで達成できることが多い。910msから804msへの差は、ほとんどのサイトにとってCDNと基本的なサーバーサイドキャッシュで実現可能であり——我々のデータは、この差を埋めることがAI可視性 のために行える最も影響力のあるパフォーマンス最適化であることを示唆している。
AI可視性にとって「良好な」TTFBの目安
GoogleはTTFBが800ms未満であることを「良好」と見なしている。我々のデータセットで最も引用されているドメインは、まさにその閾値（中央値804ms）に位置している。これは、AI可視性のための実用的な目標が、200ms未満のような高度なTTFBではなく、単に「良好」な範囲——800ms未満——にあることを示唆している。
現在のTTFBが1,000msを超えている場合、何らかのクロールの摩擦が生じている可能性が高い。AIクローラーは時間制限の下で動作しており、応答に1秒以上かかるサーバーは、クロール試行の一部がタイムアウトによって失われることになる。1,000ms未満を最初のマイルストーンとし、800ms未満を達成すれば、最も引用されているドメインと同水準に達したことになる。
実用的な推奨事項
複数の地理的な場所からTTFBを測定する。 TTFBはリクエストの発信元によって異なる。AIクローラーは人間の訪問者とは異なる地域のデータセンターからフェッチする可能性がある。KeyCDNのパフォーマンステストやWebPageTestなどのツールを使用して、複数の場所から測定しよう。
フルページキャッシュを有効にする。 ページがリクエストのたびに動的に生成されている場合、TTFBは高くなる。キャッシュ層（Redis、Varnish、またはCMSの組み込みキャッシュ）により、キャッシュされたページのTTFBを500ms以上から50ms未満に削減できる。
エッジキャッシュ付きのCDNを使用する。 CDNはリクエスト元の近くからコンテンツを配信し、ネットワークレイテンシを削減する。基本的なCDN設定（Cloudflare、Fastly、CloudFront）でもTTFBを100〜300ms削減できる。
必要に応じてホスティングをアップグレードする。 共有ホスティングプランではTTFBが1,000〜2,000msの範囲になることが多い。VPSや専用サーバー、またはマネージドホスティングプラットフォームに移行することで、段階的な改善が期待できる。
方法論
これは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コマース、およびサポート関連のトピックに偏っているため、これらの数値はその種のクエリに対して引用されたサイトを説明している。この関係は実際に存在するが緩やかであり、相関関係である——高速なページがより多くの引用を引き起こすと主張しているわけではない。
