表示速度はAI検索に関係ある？Googleの公式説明と応答速度の測り方

「サイトが遅いと、ChatGPTやGoogleのAI Overviewsに引用されにくくなるのでしょうか」。そう気になっている方は多いはずです。

制作会社から「表示速度を改善しないと、AI検索で不利になります」と提案されて、大がかりな改修をすべきか迷っている方もいるでしょう。

この記事は、中小企業のWeb担当者に向けて、表示速度とサーバーの応答速度がAI検索にどの程度関係するのかを、Googleの公式説明をもとに整理します。応答速度の測り方、PageSpeed InsightsとSearch Consoleの見方、原因ごとの対策までをまとめました。

公式文書は、2026年10月17日に開いて確かめた内容です。測り方や優先順位の付け方は、筆者の提案です。

先に結論 速さは足を引っ張らない程度で足りる

結論を、公式に言えることと、筆者の判断に分けて並べます。

論点	公式に言えること	筆者の判断
ランキングへの影響	Core Web Vitalsはランキングシステムが使うが、良い結果でも上位表示は保証されない	決め手にはならず、内容が近いときの差になりうる
GoogleのAI機能	追加の技術要件はない。インデックスされ、スニペット付きで表示できればよい	速度のために特別な対応は要らない
クロール	応答が速く安定していれば、クロール容量の上限が上がる	問題になるのは主に大規模なサイト
AIクローラーの打ち切り時間	OpenAI、Anthropic、Perplexityの公式文書に、秒数の記載は見当たらない	極端に遅くないかを確かめれば足りる

公式の説明は「関連性が先」

Googleは、速さなどのページの使いやすさを見る仕組みがあると説明しています。同時に、関連性の高い内容を表示することを優先するとも書いています。

速度は無関係ではありませんが、内容の代わりにはなりません。

AIクローラーの扱いは公開されていない

ChatGPT、Claude、Perplexityのクローラーが、どれくらい遅いと取得をあきらめるのかは、各社の公式文書で確認できませんでした。

「何秒でタイムアウトする」という情報を見かけても、公式の裏付けがなければ参考程度にとどめます。

実務で確かめること

確かめるのは、次の3つに絞れます。応答速度が極端に遅くないか、エラーやタイムアウトが出ていないか、画像やキャッシュといった明らかな原因がないかです。

この3つを取り除いたら、速度の話はいったん終わりにして、内容づくりに時間を回します。

「速さ」には2種類ある

「サイトが遅い」という言葉には、別の話が2つ混ざっています。

種類	何を測るか	主に影響する相手	代表的な指標
表示速度（体感速度）	ブラウザで画面が表示され、操作できるようになるまでの時間	人間の訪問者	Core Web Vitals（LCP・INP・CLS）
サーバーの応答速度	サーバーがHTMLを返し始めるまでの時間	人間とクローラーの両方	TTFB

表示速度は人の体験の指標

Core Web Vitalsは、利用者のブラウザで測る、人の体験の指標です。画像の表示やボタンへの反応の速さを見ます。

応答速度はクローラーにも関わる

クローラーの多くは、画像を表示したり、ボタンを押したりしません。クローラーにとっての速さは、主にサーバーがHTMLをどれだけ早く、安定して返すかです。

これは筆者の整理です。AIクローラーの実際の動きは、各社の公式文書に詳しい記載がありません。

2つを混ぜて議論しない

制作会社から速度の改善を提案されたときは、どちらの速さの話かを聞き返します。

体感速度の改善は、人の訪問者のための施策です。応答速度の改善は、人とクローラーの両方に関わる施策です。

測定と改善の全体像

この記事では、応答速度を測り、原因を切り分けて、手間の少ないものから直し、改善の前後を記録します。

Googleの公式説明で分かること

ページエクスペリエンスに単一の信号はない

Googleの公式文書には、ページエクスペリエンスという単一の信号はなく、ランキングシステムが、ページの使いやすさに関わるさまざまな信号を見ていると書かれています。

信号の中でも、Core Web Vitalsはランキングシステムが使っています。Googleは、良い数値を目指すことを勧めています。

良い数値でも上位表示は保証されない

同じ文書に、Search ConsoleのCore Web Vitalsレポートや外部ツールで良い結果が出ても、上位に表示されることは保証されないと書かれています。

また、Googleは、ページの使いやすさが十分でなくても、最も関連性の高い内容を表示しようとすると説明しています。

内容が近いときに差になる

同じ文書には、役に立つ内容が多く存在する検索では、良いページエクスペリエンスが成功に貢献しうるとあります。

つまり速度は、内容がほぼ同程度のときの差になりうるもの、という位置づけです。

Core Web Vitalsの基準値

Core Web Vitalsの3つの指標と、良好とされる基準を、次の表に載せます。基準は、GoogleのWeb向けの解説サイトweb.devの説明によります。

指標	何を測るか	良好の基準
LCP（Largest Contentful Paint）	画面内で最も大きな要素が表示されるまでの時間	2.5秒以内
INP（Interaction to Next Paint）	クリックやタップへの反応の速さ	200ミリ秒以下
CLS（Cumulative Layout Shift）	表示中にレイアウトがどれだけずれるか	0.1以下

判定は、ページの読み込みの75パーセンタイルで行います。すべての訪問を速い順に並べたとき、75%の位置にあたる値で見る、という意味です。

古い記事の指標に注意

INPは2024年に安定した指標になり、以前の指標FIDは置き換わりました。古い記事でFIDの話が出てきたら、情報が古い可能性を考えます。

クロールの容量とサーバーの応答

応答の速さがはっきり関係する場面

サーバーの応答速度がはっきり関係するのは、クロールです。クロールとは、クローラーがページを取りに来ることです。

Googleのクロールバジェットの文書には、サイトごとにクロール容量の上限があり、その上限が上下する仕組みが書かれています。

上限が上がる場合と下がる場合

サイトの状態	クロール容量の上限
応答が一貫して安定している。応答時間（遅延とTTFBを含む）が安定しているか、改善している	上がる。より多くの接続を使える
遅くなっている。5xxのエラーや、429などの制限の合図を返す	下がる。Googleのクロールが減る

この上限は、Googleのすべてのクローラーで共有されると書かれています。

速くすれば必ず増えるわけではない

Googleの文書には、サーバーの応答が速ければ、より多くのページをクロールできるかもしれないとあります。続けて、Googleは質の高い内容だけをクロールしたいので、質の低いページを速くしただけではクロールは増えないと書いています。

大規模サイト向けのガイド

クロールバジェットのガイドは、主に次のようなサイトを対象とすると書かれています。数字は大まかな目安とされています。

対象のサイト	目安
大規模で、内容が中程度に更新される	100万ページ以上で、週1回ほど更新
中規模以上で、内容が非常に速く更新される	1万ページ以上で、毎日更新
検出されたもののインデックスされていないURLが多い	Search Consoleの分類による

数十ページから数百ページの中小企業のサイトで、新しいページが公開後すぐにクロールされているなら、クロールバジェットを心配する必要はほとんどありません。

AI OverviewsとAI Modeの条件

追加の技術要件はない

GoogleのAI機能の文書には、AI OverviewsとAI Modeに表示されるための追加の要件はなく、特別な最適化も要らないと書かれています。

補足リンクとして表示される条件は、インデックスされていて、Google検索でスニペット付きで表示できることです。

速度の基準は設けられていない

つまり、GoogleのAI機能のために、特別な速度の基準を満たす必要はありません。通常の検索と同じく、クロールされ、インデックスされることが前提です。

AI検索対策の全体の順番は、AI検索対策の実行順序と優先順位で説明しています。

AIクローラーは遅いサイトをどう扱うのか

公式説明で確認できたこと

ChatGPT（OpenAI）、Claude（Anthropic）、Perplexityの公式文書を、2026年10月17日に確認しました。クローラーの打ち切り時間や応答速度の扱いは、どの文書にも見当たりませんでした。

提供元	主なクローラー	公式説明で確認できたこと	打ち切り時間・応答速度
OpenAI	OAI-SearchBot、GPTBot	検索用と学習用の役割の違い。robots.txtの更新が反映されるまで約24時間かかることがある	見当たらない
Anthropic	Claude-SearchBot、ClaudeBot	役割の違い。クロールを制限するための、Crawl-delayへの対応	見当たらない
Perplexity	PerplexityBot	検索結果に表示するためのクローラー。変更の反映まで最大24時間かかることがある	見当たらない

秒数の情報は参考程度に

どの会社も、「何秒で打ち切る」という数値を公開していません。ブログなどで見かける秒数は、公式の裏付けがなければ参考程度にとどめます。

robots.txtの制御の考え方は、robots.txtでAIクローラーを制御する方法で説明しています。

ここからは推測です

公式説明がないため、以下は一般的な仕組みからの推測です。

AI検索が質問に答えるために、その場でページを取りに行くなら、待てる時間には限りがあると考えられます。極端に応答が遅いページは、取得をあきらめられる可能性があります。

反対に、応答が1秒か0.5秒かという小さな差が、引用を左右するとは考えにくいです。内容の関連性や、検索の対象になっているかの影響のほうが、はるかに大きいはずです。

確実に言えること

確実なのは、ページが返らなければ、どのクローラーも内容を読めないことです。速さよりも先に、確実に返る状態を保ちます。

Perplexityの文書には、WAF（不正なアクセスを防ぐ仕組み）を使っている場合、同社のクローラーを明示的に許可する必要があるかもしれないと書かれています。セキュリティの設定が、クローラーを止めていないかを確かめてください。

自分のサイトの応答速度を測る

curlでTTFBを測る

TTFBは、最初の1バイトが返るまでの時間です。ターミナル（Macの「ターミナル」、Windowsの「PowerShell」など）でcurlコマンドを使うと測れます。

最近のWindows 10と11には、標準でcurlが入っています。PowerShellでは「curl.exe」と書いてください。

curl -s -o /dev/null -w "HTTP %{http_code} / DNS %{time_namelookup}s / 接続 %{time_connect}s / TLS %{time_appconnect}s / 最初の1バイト %{time_starttransfer}s / 合計 %{time_total}s\n" https://example.com/

「https://example.com/」を自分のページのURLに変えて実行します。WindowsのPowerShellでは、「-o /dev/null」を「-o NUL」に変えてください。

表示の意味

表示	意味
HTTP	ステータスコード。200なら正常
DNS	ドメイン名からIPアドレスを調べ終わるまでの時間
接続	サーバーとの接続が確立するまでの時間
TLS	HTTPSの暗号化の準備が終わるまでの時間
最初の1バイト	サーバーが返事を返し始めるまでの時間（TTFB）
合計	HTMLをすべて受け取り終わるまでの時間

どの数値も、実行した時点からの累計です。たとえば「接続0.05秒、最初の1バイト1.2秒」なら、接続の後でサーバーがHTMLを作るのに1秒以上かかっています。

その場合は、回線よりサーバー側（データベースやプラグインの処理）に原因がある可能性が高いと読めます。

1回だけで判断しない

応答時間は、毎回ぶれます。1回目はキャッシュ（作り置きのページ）がなくて遅く、2回目から速くなることもあります。

数回続けて測ります。

for i in 1 2 3 4 5; do
  curl -s -o /dev/null -w "%{http_code} %{time_starttransfer}\n" https://example.com/
  sleep 2
done

これはMacとLinux向けの書き方です。「sleep 2」は2秒待つ指示で、自分のサーバーに負荷をかけないよう、間隔を空けています。

クローラーを名乗ったときの応答も見る

サーバーやセキュリティの設定によっては、クローラーからのアクセスにだけ、別の対応をしていることがあります。「-A」でUser-Agent（アクセス元の名乗り）を変えて比べると、違いに気づけます。

curl -s -o /dev/null -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot" -w "%{http_code} %{time_starttransfer}\n" https://example.com/

ここで403（拒否）や503が返る、あるいは極端に遅いときは、ファイアウォールやセキュリティのプラグインが、クローラーを止めていないかを確認します。

名乗りの文字列は、OpenAIの公式ページに載っている2026年10月17日時点の一例です。バージョン番号は変わるので、最新の文字列は公式ページで確認してください。

本物のクローラーはIPアドレスでも判定されうるため、完全な再現にはなりません。

遅すぎるページを探す

「–max-time」で上限の秒数を決めると、それを超えたときに打ち切られます。

curl -s -o /dev/null --max-time 5 -w "%{http_code} %{time_total}\n" https://example.com/

上限を超えると、ステータスコードは000と表示され、curlは終了コード28で終わります。

5秒という数字は、AIクローラーの基準ではありません。さすがに遅すぎるページを見つけるための、仮の線です。

目安と注意点

web.devの解説では、TTFBは0.8秒以下が良好、1.8秒を超えると不良という目安が示されています。ただし、これは訪問者の75パーセンタイルで見る前提です。

TTFBはCore Web Vitalsの指標ではありません。LCPの妨げにならなければ、この基準を満たすことが絶対に必要なわけではないとも、書かれています。

curlで測るときは、次の点にも注意してください。

• 自分のパソコンや回線の状態に左右されます
• ログイン中はキャッシュが使われないことが多く、結果が変わります
• CDN（配信を速くする仕組み）を使っていると、配信拠点のキャッシュの有無で大きく変わります

curlの数値は、サーバーが極端に遅くないかを見る簡易チェックと考えてください。

PageSpeed InsightsとSearch Consoleの見方

PageSpeed Insights

PageSpeed Insightsにページを入れると、2種類のデータが表示されます。

データ	中身	使い方
実際のユーザーのデータ（フィールドデータ）	Chromeの利用者から集めたCrUXのデータ。過去28日間の実績	Core Web Vitalsの合否は、こちらで判断する
診断（ラボデータ）	Lighthouseという仕組みで、決まった条件を想定して測ったもの	改善のヒントを見る。点数は測るたびに上下する

データが出ないページがある

アクセスが少ないページでは、フィールドデータが十分に集まらず、表示されないことがあります。公式の説明にも、データが十分にあるページだけが対象になると書かれています。

その場合は、ラボデータの改善提案を参考にします。点数そのものより、何が重いと指摘されているかを見ます。

Search ConsoleのCore Web Vitalsレポート

Search Consoleの日本語の画面では、Core Web Vitalsレポートは「ウェブに関する主な指標」とも表記されます。サイト全体の状況を確認するためのレポートです。

公式のヘルプには、特定のURLの状態を調べる用途には向かず、サイトの全体的なパフォーマンスを確認するためのレポートだと書かれています。

レポートの読み方

項目	内容
データの元	実際のユーザーのデータ
表示の単位	似たページをまとめたURLグループ
状態の分類	低速、改善が必要、良好
対象のURL	インデックスに登録されているURL。すべてを網羅したものではない

データが少ないURLグループは、レポートから除外されます。レポートが出ないのは、サイトの異常とは限りません。

クロールの統計情報で応答を見る

クローラーから見た応答は、Search Consoleのクロールの統計情報レポートで確認できます。プロパティの設定から開きます。

このレポートは、ドメインプロパティか、ルートレベルのURLプレフィックスプロパティでのみ使えます。ヘルプには、ページ数が1,000未満のサイトでは、使う必要はないと書かれています。

見る項目

項目	見方
平均レスポンス時間	期間中に取得したすべてのリソースの平均。急に伸びていないかを見る
ホストのステータス	可用性の問題が起きたかどうか。過去90日間のステータスが表示される

ホストのステータスに問題が出ているなら、速度以前に、ページが返らない時間があるということです。最優先で対処してください。

重くなる主な原因と対策

中小企業のサイトでよくある原因を、筆者の経験から、効果が出やすい順に並べます。

原因	よくある症状	対策
大きすぎる画像	LCPが遅い。スマートフォンで特に遅い	表示サイズに合わせて縮小し、WebPなどに変換する。画面の外の画像は遅延読み込みにする
ページキャッシュがない	TTFBが毎回遅い	WordPressならキャッシュ機能を有効にする。サーバー会社のキャッシュ機能を使う
プラグインの入れすぎ	管理画面も表示も遅い	使っていないものを停止し、削除する。1つずつ外して影響を確認する
JavaScriptの多さ	INPが悪い。表示が遅れる	不要なスクリプトを削る。読み込みを後回しにする
外部タグの多さ（広告・解析・チャット）	表示が遅れる。操作が重い	使っていないタグを、タグ管理のツールから削除する
サーバーの性能不足	アクセスが多い時間だけ遅い	プランの見直し、PHPのバージョンを上げる、CDNの利用

画像から手を付ける

効果が出やすいのは画像です。大きな写真をそのまま使っているなら、縮小とWebPなどへの変換だけで、大きく改善することがあります。

ただし、ページ最上部の主役の画像（LCPの対象になりやすい）には、遅延読み込みをかけないでください。かえって表示が遅れることがあります。

キャッシュを確認する

WordPressでは、ページキャッシュが効いていないと、アクセスのたびにページを組み立てます。そのため、TTFBが遅くなりがちです。

プラグインを増やす前に、まずキャッシュの有無を確認します。

JavaScriptとプラグイン

JavaScriptの削減は、主に人の体験（特にINP）に効きます。クローラーにとっては、重さよりも、本文が最初のHTMLに入っているかのほうが、確実に読まれやすいと筆者は考えます。

プラグインを外すときは、問い合わせフォームなど必要な機能が止まらないかを、テスト環境で確かめてから本番に反映します。

過度な期待をしないために

速度の改善は、やって損はない施策です。ただし、期待しすぎると、予算と時間の使い方を誤ります。

速くしても、引用されるとは限らない

AI検索でも、質問に合った内容があるかどうかが先です。速度は、その土台を支える要素の1つにすぎません。

点数を100点にする必要はない

PageSpeed Insightsの点数を満点にするために、大規模な作り直しをする必要はありません。内容の充実と正確さに時間を使うほうが、効きやすいと筆者は考えます。

速度で有利になるという提案は根拠を確かめる

2026年10月17日時点で、OpenAI、Anthropic、Perplexityの公式文書に、速度の基準は見当たりませんでした。「速度を上げればAI検索で有利」という提案を受けたら、根拠の出どころを聞いてください。

明らかな遅さは直す価値がある

訪問者は離れますし、タイムアウトはクロールそのものを妨げます。目指すのは、Core Web Vitalsが良好かそれに近い状態で、サーバーが安定して返事をすることです。満点は目指しません。

よくある失敗

点数だけを追いかける

実ユーザーのデータと、指摘されている具体的な原因を見ます。点数の上下に一喜一憂しないでください。

トップページだけ測る

引用されやすいのは、サービス紹介や解説記事などの下層ページです。主要なページを複数測ります。

負荷対策でクローラーを止めてしまう

サーバーの負荷を下げようとして、検索用のクローラーまで止めていないかを確認します。止めると、AIの検索結果に載る機会を失います。

改善前の数値を記録していない

作業の前に、PageSpeed Insightsとcurlの結果を保存しておきます。記録がないと、改善したかどうかを確かめられません。

チェックリスト

現状の確認

• 主要なページ（トップ、サービス紹介、よく読まれる記事など）を5件から10件選んだ
• curlで各ページのTTFBを数回測り、記録した
• 極端に遅いページや、タイムアウトするページがないか確認した
• クローラーを名乗ったときに、403や503が返らないか確認した
• PageSpeed Insightsで、実ユーザーのデータを確認した
• Search ConsoleのCore Web Vitalsレポートで、モバイルとパソコンの状況を確認した
• クロールの統計情報で、平均レスポンス時間とホストのステータスを確認した

原因の切り分けと対策

• 大きすぎる画像を縮小し、軽い形式に変換した
• ページ最上部の主役の画像に、遅延読み込みをかけていない
• ページキャッシュが効いていることを確認した
• 使っていないプラグインと外部タグを整理した
• 本文が最初のHTMLに入っているか確認した

運用

• 改善の前後の数値を記録して、比較した
• 速度改善の提案を受けたときに、費用と効果の根拠を確認した

AI検索対策の全体を点検したいときは、AI検索対策の自己診断チェックリスト46項目も参考にしてください。

よくある質問

Q. 表示速度が遅いと、AI Overviewsに表示されなくなりますか？

Googleの公式説明では、AI OverviewsとAI Modeに表示されるための追加の技術要件はありません。インデックスされていて、スニペット付きで表示できることが条件です。

速度だけで表示対象から外れるという説明は、見当たりません。ただし、ページが返らない状態や、極端に遅い状態では、クロールやインデックスに影響しうるため、最低限の安定性は必要です。

Q. ChatGPTやPerplexityは、何秒以内に表示されないと読んでくれませんか？

2026年10月17日時点で、OpenAI、Anthropic、Perplexityの公式文書に、クローラーのタイムアウトの秒数は見当たりません。

実務では、TTFBが極端に遅くないか、エラーが出ていないかを確認しておけば足りると筆者は考えます。

Q. PageSpeed Insightsの点数が低いのですが、すぐに直すべきですか？

まず、実ユーザーのデータでCore Web Vitalsが良好かどうかを見てください。良好なら、点数が低くても急ぐ必要はありません。

不良の場合は、診断に出ている原因のうち、画像やキャッシュなど手間の少ないものから対応します。

Q. サーバーを上位のプランに変えれば、AI検索に強くなりますか？

サーバーが原因でTTFBが遅い、混む時間に落ちるといった状態なら、改善する価値があります。すでに安定して速いサイトで性能を上げても、引用が増えるとは考えにくいです。

先にcurlとクロールの統計情報で、本当にサーバーが原因かを確かめてください。

Q. 小さな会社のサイトでも、クロールバジェットを気にする必要はありますか？

Googleのクロールバジェットのガイドは、100万ページ以上のサイトや、1万ページ以上で毎日更新されるサイトなどを、主な対象としています。数字は目安です。

ページ数が少なく、公開したページがすぐにクロールされているなら、気にする必要はほとんどありません。

まとめ

• 表示速度と応答速度は、AI検索にとって大きな決め手ではありません
• GoogleはCore Web Vitalsをランキングに使うとしつつ、関連性を優先すると説明しています
• AI OverviewsとAI Modeに、速度の追加要件はありません
• AIクローラーのタイムアウトは、公式には示されていません

一方で、応答の遅さやエラー、タイムアウトは、クロールを減らし、読んでもらう機会を失う原因になります。まずはcurlでTTFBを測り、PageSpeed InsightsとSearch Consoleで状況を確認してください。

画像、キャッシュ、プラグインといった明らかな原因を取り除いたら、速度は足を引っ張らない程度で止めます。浮いた時間と予算は、引用される価値のある内容づくりに回すのが現実的です。

今日できる点検

まずは、主要なページを3件選んで、curlのコマンドを3回ずつ実行してください。最初の1バイトが1秒を超えるページがあれば、キャッシュの有無から確認します。

参照した公式文書

• Google検索セントラル、ページエクスペリエンスのページ（developers.google.com/search/docs/appearance/page-experience）
• Google検索セントラル、クロールバジェットの管理のページ（developers.google.com/crawling/docs/crawl-budget）
• Google検索セントラル、クロールエラーのトラブルシューティングのページ（developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors）
• Google検索セントラル、AI機能と自社サイトのページ（developers.google.com/search/docs/appearance/ai-features）
• Google PageSpeed Insightsの概要のページ（developers.google.com/speed/docs/insights/v5/about）
• web.dev、Core Web Vitalsの記事（web.dev/articles/vitals）とTTFBの記事（web.dev/articles/ttfb）
• Search Consoleヘルプ、Core Web Vitalsレポート（support.google.com/webmasters/answer/9205520）、クロールの統計情報レポート（answer/9679690）
• OpenAIの開発者向け文書、クローラー（bots）のページ（developers.openai.com/api/docs/bots）
• Anthropicのヘルプ、ウェブのクロールとサイト所有者のブロック方法の記事（support.claude.com/en/articles/8896518）
• Perplexityの開発者文書、クローラーのページ（docs.perplexity.ai/docs/resources/perplexity-crawlers）

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。