AIクローラーが403になる。WAFと配信経路の調べ方
AIクローラーがWAF周辺で403になるとき、robots、CDN、WAF、オリジンを分けて記録し、検証済みBotへの最小変更につなげる調べ方と依頼条件を具体的に解説します。
この記事の目次を開く
AIクローラーへの許可をrobots.txtで確認しても403が続くなら、CDN、WAF、オリジンを別々に調べます。例外設定を先に広げず、どの層が拒否したかを記録し、送信元を検証できたBotに限って最小限の変更を依頼するのが安全です。
robots.txtは調査の入口であって、配信経路全体の通行証ではありません。Google検索のAI機能についても、Googleはrobots.txtだけでなくCDNやホスティング基盤でクロールを許可することを推奨例に挙げています。ただし、この説明はGoogle検索のAI機能に関するもので、他社のAIクローラーへそのまま一般化できません。
厄介なのは、利用者側で見える「403」だけでは拒否した層が決まらないことです。とくにAWS WAFとCloudFrontの構成では、CloudFrontから見てWAFが返した403とオリジンが返した403を区別できません。robotsの記述を直すべきか、WAFのルールを狭く調整すべきか。それを決めるには、各層の記録を同じリクエスト単位で突き合わせる必要があります。
AIクローラーとWAFの間を層ごとに分ける
最初に「AIクローラーが拒否された」という一つの事象を、次の四つに分解します。
- robots：対象のクローラーとURLに対する許可・拒否の判定
- CDN：対象リクエストが到達し、どの応答として処理されたか
- WAF：該当リクエストがルールでブロックされた記録があるか
- オリジン：CDNを介さない確認でも403が再現するか
この分け方は、原因と変更先の混同を防ぐための運用上の提案です。製品共通の公式仕様を示すものではありません。各欄には、確認できた事実、未確認、対象外のいずれかを記し、次に誰が何を確認するかを決められる状態にします。
Google検索のAI機能については、2026年9月21日時点の公式資料が、robots.txtに加えてCDNまたはホスティング基盤でもクロールを許可することをSEOの推奨例として示しています。したがって、robotsで許可されているという一点だけで「Google側の問題」と判断するのは早計です。Google「AI Features and Your Website」
robotsの確認方法自体を整理したい場合は、先にAIクローラー向けrobots.txtの確認手順を使い、対象Bot、対象パス、判定結果を切り出しておくと、インフラ担当者への依頼が曖昧になりません。
403の発生層を決めるための決定表
次の表は運用上の提案です。調査担当とインフラ担当が同じ条件を見られるよう、行ごとに一つの検証リクエストを記録します。「許可したはず」という設定の説明で止めず、実際に観測した結果まで残します。
| robots判定 | CDNでの到達・応答 | WAFのブロック記録 | オリジン直接確認 | 判断 | 次の依頼 |
|---|---|---|---|---|---|
| 拒否 | 未確認 | 未確認 | 未確認 | robotsで停止する条件がある | 対象Botと対象パスを限定してrobotsの意図を確認する |
| 許可 | 403を確認 | あり | 未確認 | WAFで拒否された記録がある | 送信元を検証後、該当ルールと対象範囲だけを見直す |
| 許可 | 403を確認 | なし | 403を再現 | オリジン側で拒否が再現する | オリジンログとアクセス制御を確認する |
| 許可 | 403を確認 | なし | 403を再現しない | CDN側を含む経路上の条件を再確認する | 同じ条件でCDNとWAFの記録を突き合わせる |
| 許可 | 記録なし | 記録なし | 未確認 | 対象リクエストを特定できていない | 時刻、URL、送信元、Bot識別情報をそろえて再確認する |
「WAFのブロック記録なし」だけでWAF以外と断定してはいけません。記録を探した対象や条件が一致していなければ、単に照合できていない可能性が残ります。表の最終行を置くのは、原因不明と記録不足を分けるためです。
AWS WAFがクライアントとCloudFrontの間にある構成では、2026年9月21日時点のAWS公式資料によると、CloudFrontはWAFがブロックした403とオリジンが返した403を区別できません。AWSは、発生源を確かめるためにWAFのWeb ACLルールでブロックされたリクエストを調べるよう案内しています。これはAWS WAFとCloudFrontを組み合わせた場合の説明であり、すべてのCDNやWAFに共通する仕様ではありません。AWS「HTTP 403 status code (Permission Denied)」
同じ資料では、CloudFrontのカスタムオリジンを使う構成について、CloudFrontを介さずオリジンへ直接リクエストして403を再現できれば、オリジンが発生元であり、オリジンログを調べるよう案内しています。直接確認は公開範囲を変える作業ではありません。既存の接続条件と運用手順に従い、インフラ担当者が実施可否を判断します。
Botを検証してから例外を最小化する
WAFの例外を検討する前に、Google由来を名乗るリクエストの送信元を検証します。User-Agentの名称だけでは検証になりません。2026年9月21日時点でGoogleは、送信元IPを逆引きして指定のGoogle管理ドメインであることを確かめ、そのホスト名を正引きして元のIPと一致させる方法を案内しています。別の方法として、Google公開のIP範囲リストとの照合も示しています。Google「Verify Requests from Google Crawlers and Fetchers」
この検証方法はGoogleのリクエスト専用です。他社Botへ転用せず、他社Botの許可条件とは分けて扱います。
Googleの公式資料は、リクエストを共通クローラー、特殊ケースのクローラー、ユーザー起動フェッチャーに分類し、robots.txtの扱いが異なると説明しています。共通クローラーは自動クロールで常に従いますが、特殊ケースは従う場合と従わない場合があり、ユーザー起動フェッチャーは従いません。2026年9月21日時点で、この違いは「Googleを名乗るアクセス」を一括りにせず、対象リクエストの種類まで確認する必要があることを示します。
送信元を検証できたら、変更依頼には次の条件を添えます。
- 対象：検証済みのBotまたは検証済み送信元に限定する
- 経路：決定表で403の発生を確認した層に限定する
- 範囲：取得させる必要があるホストとパスに限定する
- ルール：ブロックに一致した条件だけを確認対象にする
- 再確認：変更前と同じURL、経路、Bot条件で結果を記録する
ここに挙げた条件は運用上の提案であり、公式資料が定める一律の設定値ではありません。「AIクローラーを全部許可する」という依頼は避けます。検証した主体、必要な取得範囲、403を生んだ層がそろって初めて、変更対象を狭くできます。
インフラ担当者へ渡す記録
調査メモは、robots、CDN、WAF、オリジンの欄を保ったまま渡します。アクセスログの読み方やBot別の観測項目は、AIクローラーのログを分析する手順と組み合わせると整理しやすくなります。
依頼文には、対象URL、確認した時点、robots判定、CDNで見た応答、WAFのブロック記録の有無、オリジン直接確認の結果、送信元の検証方法、変更してほしい層を含めます。値が取れない欄は推測で埋めず、「未確認」として確認担当を決めます。
たとえば、robotsは許可、CDN経由では403、WAFに該当ブロック記録があり、Google公式の方法で送信元を検証済みなら、WAF担当へ該当ルールの確認を依頼します。WAFに該当記録がなく、カスタムオリジンへの直接確認でも403が再現する場合は、AWSの案内に沿ってオリジンログとアクセス制御を確認します。「403を解消する」という依頼でも、観測結果によって触る層は変わります。
取得できても表示や引用は保証されない
403の解消は、取得を妨げる条件を取り除く作業です。Google検索のAI OverviewsまたはAI Modeで補助リンクとして表示されるには、2026年9月21日時点で、ページがインデックス登録され、スニペット付きでGoogle検索に表示可能であることが必要です。ただしGoogleは、要件を満たしてもクロール、インデックス登録、配信を保証しないと明記しています。Google「AI Features and Your Website」
したがって、WAFの調整依頼では「AI回答への引用」や「表示」を成果条件にできません。完了条件は、対象の検証済みBotについて、同じ条件で再試行した結果を各層の欄へ記録し、想定外の403がどこで解消したかを確定することです。
決定表に「未確認」が残る間は、設定変更の依頼に進まず、同じリクエストを示す時刻、URL、送信元、Bot識別情報をそろえます。robots、CDN、WAF、オリジンの記録から403の発生層を確定し、Botの送信元も検証できた時点で、その層の担当者へホスト、パス、該当ルールを絞って依頼します。この二つの条件が、広すぎる例外を避けるための判断線になります。