GoogleクローラーのIPレンジJSONファイルが新しい場所へ ── 自社の設定で確認する13項目（2026年9月時点）

01 何が起きたか — GoogleクローラーのIPレンジJSONファイルが引っ越した

2026年3月31日、Googleが公式ブログで短い告知を出した

Google Search Central Blogに、Googleのクローラー・フェッチャーが使うIPアドレス範囲を示すJSONファイルの置き場所が変わったという短い告知が掲載されました。同記事は「今回は短い連絡です」という一文から始まっており、内容自体はシンプルです。従来、これらのJSONファイルはdevelopers.google.comの/search/apis/ipranges/というディレクトリに置かれていましたが、これらのIPレンジはGoogle検索のクローラーだけでなく、複数のGoogleプロダクトに共通して使われているため、より汎用的な場所である/crawling/ipranges/へ移動した、という内容です。

公式ブログの原文には、次のように書かれています。

"Currently, you find the JSON files listing Google's IP ranges under the /search/apis/ipranges/ directory on developers.google.com. Since these ranges apply to more than just Google Search crawlers, we're moving them to a more general Location: developers.google.com/crawling/ipranges/."

（訳: 現在、Googleが公開しているIPレンジの一覧を示すJSONファイルは、developers.google.com上の/search/apis/ipranges/ディレクトリにあります。このIPレンジはGoogle検索のクローラーだけでなく、それ以上の範囲に適用されるため、より汎用的な場所であるdevelopers.google.com/crawling/ipranges/へ移動します。）

旧パスはいつまで使えるのか

公式ブログは、旧ディレクトリについて次のように説明しています。

"For the time being, the files will continue to be available at the old /search/ path as well to give everyone time to update their systems. However, we encourage you to switch to the new /crawling/ipranges/ path as soon as possible. We will eventually phase out the old locations and redirect them to the new ones within 6 months."

（訳: 当面の間、システムを更新する時間を確保できるよう、旧/search/パスでもファイルは引き続き利用可能です。ただし、できるだけ早く新しい/crawling/ipranges/パスに切り替えることを推奨します。旧パスは最終的に廃止し、6か月以内に新パスへリダイレクトする予定です。）

つまり、猶予はあるが無期限ではありません。「6か月以内」という期限が明記されている以上、旧パスをファイアウォールやWAFの設定に直接書き込んだままにしておくと、いずれリダイレクトされる側に頼り続けることになります。

02 なぜ・背景 — なぜこのファイルが存在し、なぜ場所を変えたのか

なぜGoogleはIPレンジをJSONで公開しているのか

Googleのクローラーやフェッチャーは、性能とスケールを確保するため、世界中の複数のデータセンターから、多数のマシンで同時に動いています。そのため、アクセスログには複数のIPアドレスからのアクセスが記録されます。サイト側がファイアウォールやWAFで、正規のGoogleクローラーだけを通し、それ以外を拒否したいと考えたとき、User-Agent文字列だけでは偽装を見破れません。そこでGoogleは、実際に使用しているIPアドレスの範囲をJSON形式で公開し、サイト側がそれと照合できるようにしています。

今回の移動が示す変化 — 「検索」から「クロール全般」への括り直し

今回の移動で注目したいのは、単にURLのパスが変わったという表面的な話ではなく、Googleがこれらの情報を「Search」の枠から「Crawling infrastructure（クロール基盤）」というより上位の枠に括り直したという点です。移動先のディレクトリ名が/crawling/であることからも、この情報がGoogle検索専用ではなく、AdsBotのような広告関連のクローラーや、ユーザーの操作をきっかけに動くフェッチャーなど、複数のGoogleプロダクトに共通する情報として再整理されたことがうかがえます。

なぜサイト側の対応が必要なのか

ファイアウォールやセキュリティ製品の設定は、一度組んだ後は放置されがちです。旧パスの参照が残ったままでも、当面は301リダイレクトによって新パスの内容が届くため、すぐに壊れるわけではありません。しかし、いずれ迎える廃止のタイミングで、リダイレクトそのものが無くなれば、旧パスへの直接参照は失敗するようになります。そうなってから気づくのと、公式ブログが出た時点で自社の設定を洗い出しておくのとでは、対応にかかる緊急度が大きく違います。

03 この記事で出てくる用語

IPレンジ（CIDR形式）とは

リバースDNS（逆引き）とは

ユーザートリガーフェッチャーとは

04 型別 — この変更の適用範囲・測っていないこと・手順

🅰 適用範囲 — この記事が関係するサイト

今回の変更が実際に関係してくるのは、ファイアウォールやWAF、あるいは自社のクローラー検証ロジックの中で、GoogleのIPレンジを参照して許可・拒否を判定しているサイトです。逆に言えば、IPアドレスによる制御を一切行わず、User-Agentの文字列だけで判定している、あるいはbot対策を外部サービス（Cloudflareなど）に完全に任せている場合は、自社のシステムを直接修正する必要はないかもしれません。ただし、その場合でも、利用している外部サービス側が旧パスを参照していないかは別途 確認が必要です。

🅱 この記事が測っていないこと

この記事が測っていないことも明確にしておきます。第一に、自社のファイアウォールやWAFの設定が、実際にどちらのパスを参照しているかは、そのサイト固有の設定情報であり、当サイトの外からは分かりません。第二に、5つのJSONファイルに実際にどのIPレンジが記載されているかという中身の数値は、日々更新されうる情報であり、この記事内に列挙しても公開から時間が経てば古くなります。確認したい場合は、必ずその時点のファイルを直接開いて確認してください。第三に、旧パスが実際に何ヶ月後に廃止されるかという正確な期限日は、公式ブログの時点では「6か月以内」としか書かれておらず、確定した日付は公開されていません。

🅲 手順 — 自社の設定を新しいパスへ切り替える4段階

実際の切り替え作業は、次の順番で進めます。第一に、自社のファイアウォール・WAF・独自の検証スクリプトなど、Googleのクローラーを判定している設定を全部 洗い出します。第二に、それぞれの設定の中に、旧URL（/search/apis/ipranges/）が直接書き込まれていないかを探します。設定ファイルの中に、コピー&ペーストされた古いURLがそのまま残っているケースは珍しくありません。第三に、旧URLが見つかった箇所を新URL（/crawling/ipranges/）に書き換えます。第四に、定期的にJSONファイルを再取得する仕組みを用意し、確認した日付を記録に残します。IPレンジの中身は将来的にも更新されうるため、一度切り替えて終わりにせず、継続的に参照する体制を整えておくことが望ましいと考えられます。

05 自分のサイトで確認するチェックリスト

チェックリストの4つの観点

ここまでの内容を、今日から手を動かせる作業に翻訳しました。観点は、自社設定の洗い出し、旧URLの検出と切り替え、正規クローラーの検証、記録の保存の4つに分かれます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• 自社のファイアウォール・WAF・セキュリティ製品の設定一覧を書き出す
• それぞれの設定が、IPアドレスによるGoogleクローラーの判定を行っているか確認する
• 行っている設定の中身を開き、「ipranges」という文字列を検索して該当箇所を探す
• 見つかった箇所が旧URL（/search/apis/ipranges/）を参照していないか確認する
• 旧URLを参照している箇所があれば、新URL（/crawling/ipranges/）に書き換える
• 書き換えた設定をテスト環境で適用し、構文エラーが無いことを確認する
• アクセスログから直近のGooglebotと思われるIPアドレスを1件抜き出す
• そのIPアドレスに対してhostコマンドで逆引きを実行し、Googlebot.comで終わるホスト名が返るか確認する
• 返ってきたホスト名を再度hostコマンドで正引きし、元のIPアドレスと一致するか確認する
• 新パス配下の5つのJSONファイルのうち、自社が参照すべきものはどれかを特定する
• 特定したJSONファイルを実際に1回ダウンロードし、中身が取得できることを確認する
• 定期的にJSONファイルを再取得する運用（手動確認の頻度、または自動化の要否）を決める
• 今回確認した内容（確認日・使用パス・切り替えの要否）を記録に残す

13項目の内訳と、かかる時間の目安

最初の2項目は自社設定の棚卸し、3番目から6番目は旧URLの検出と切り替え、7番目から9番目は正規クローラーであることの逆引き検証、10番目から12番目はJSONファイルの実際の取得確認、13番目は記録の保存に対応しています。すべてに目を通す時間の目安は1サイトあたり20分程度です。IPアドレスによる制御を行っていないサイトでは、3番目以降を「該当なし」として飛ばしても構いません。

06 Googleのクローラーを検証する手段を比較する

手動での検証と、自動での検証

公式ドキュメント（Verify requests from Google crawlers and fetchers（訳: Googleのクローラー・フェッチャーからのリクエストを検証する））は、Googleのクローラーを検証する方法を「手動」と「自動」の2つに分けて説明しています。以下は、それぞれの向き不向きを整理した表です。

手段	確認できること	確認できないこと・注意点
手動での逆引き/正引き (host コマンド)	1件ずつ、そのアクセスが本物かを厳密に確認できる	大量のアクセスを1件ずつ調べるのは現実的でない。単発の確認向き
JSONファイルとの 自動照合	大量のアクセスログを、IPレンジと機械的に突き合わせられる	ファイルの中身は更新されるため、定期的な再取得が前提になる
User-Agentのみでの 判定	実装が最も簡単	User-Agentは偽装が容易なため、単独では正規クローラーの証明にならない
当サイトの (🔧 セキュリティ対策監査ツール・要ログイン)	外から到達できる自社サイトの状態を、まとめて点検できる	クローラー検証の専用ツールではない。総合的な外形チェック用

User-Agentだけに頼ると、なぜ危ないか

User-Agent文字列は、リクエストを送る側が自由に書き換えられる値です。「Googlebot」と名乗るリクエストを送ること自体は、誰にでもできます。だからこそ公式ドキュメントは、User-Agentに加えて送信元のIPアドレスと、そのIPの逆引きホスト名という、書き換えがより難しい2つの情報を組み合わせて検証することを推奨しています。自社サイトへのクロールを、正規のGooglebotとして扱ってよいかどうかを判断する際は、この3点セットで確認するのが安全です。自社のセキュリティ設定全般に不安がある場合は、当サイトの🔧 セキュリティ対策監査ツールで、外から到達できる状態をまとめて点検することもできます。

自動照合を実装するときに気をつけたい2点

JSONファイルとの自動照合をこれから実装する場合、2点だけ補足しておきます。第一に、JSON内のIPレンジはCIDR形式で表現されているため、単純な文字列の一致では判定できません。「あるIPアドレスが、あるレンジに含まれるか」を正しく判定するには、IPアドレスをネットワーク計算として扱えるライブラリやモジュールを使う必要があります。第二に、IPv4だけでなくIPv6のレンジが含まれるファイルもあるため、実装時にはIPv6形式のアドレスも想定しておくべきです。どちらも、実装してから気づくと手戻りが大きくなりやすい点なので、着手前に確認しておくことをおすすめします。

07 当サイトで確かめたこと

旧パスが実際にどうなっているかを、今日 直接 確認した

公式ブログには「当面は旧パスでもファイルは利用できる」と書かれていますが、その「当面」が今どの状態にあるのかは、実際にアクセスしてみないと分かりません。そこで、公開から半年近くが経過した現時点で、旧パスの代表的な1ファイル（Googlebot.json）に対して、実際にHTTPリクエストを送って確認しました。

その結果、旧パス（/search/apis/ipranges/googlebot.json）へのリクエストは、HTTP 301（恒久的リダイレクト）で新パスの共通クローラー用ファイル（/static/crawling/ipranges/common-crawlers.json）へ転送されることを確認しました。つまり、少なくとも今日の時点では、旧パスを直接参照している設定があっても、リダイレクトによって正しい内容が届く状態になっています。

04章の手順を、当サイト自身に当ててみた

05章のチェックリストは、読者に向けて「自社の設定を洗い出してほしい」と書いています。同じ手順を、当サイト自身のクローラー許可設定に当ててみました。当サイトの仕組みでは、正規の検索・AIクローラーだけを通しており、そこで使うIPレンジは、Googleを含む各社が公開しているJSONファイルを、定期的な更新の仕組みで取得しています。

その定期更新の設定を開いて確認したところ、Googleのクローラー用IPレンジを取得する参照先が、今もなお旧パス（/search/apis/ipranges/）のままになっていました。現時点では旧パスが新パスへ301リダイレクトされるため、取得される中身そのものは正しいものが届いています。しかし、これは04章のチェックリストの4番目「旧URLを参照している箇所があれば、新URLに書き換える」に、当サイト自身がまだ対応できていないという状態です。

「今は動いているから大丈夫」と、この記事の中で読者に向けて何度も書いておきながら、当サイト自身の設定を確認するまで、この状態に気づいていませんでした。チェックリストを書くことと、そのチェックリストを自分自身に当てることは、別の作業です。この記事の公開後、当サイトの設定も新パスへ切り替える対応を進める予定です。

「重ならなかった」ことも、そのまま記録する

当サイトの正規クローラー許可の仕組みは、Google以外にもBing・OpenAI・Anthropic・Perplexity・Apple・Amazonといった複数社のIPレンジを同じ方式で取り込んでいます。今回、そのうち旧パスの参照が残っていたのはGoogle関連の設定のみで、他社の設定には同種の古いURLは見つかりませんでした。archives/130で扱ったとおり、「見つからなかった」という結果も、次に同じ確認をするときの比較材料として、そのまま記録に残しています。

08 このテーマの、これまで

Googleのクロールがファイルサイズで止まる仕組みを検証した回

Googleのクローラーが、既定でファイルの先頭何MBまでしか読み込まないかを、公式ドキュメントと自社の設定で確認した回があります（Googleのクロールは2MBで止まる ── 最新の公式解説と、自分のサイトで確認する13項目）。本記事の02章で扱った「Googleのクローラーとフェッチャーの概要」ドキュメントは、この回で参照した情報と同じ体系に属しています。

Cloudflareのbot対策のデフォルト設定が、自社の見え方に影響していた回

正規のクローラーと、それを装った偽装アクセスを見分ける難しさを扱った回もあります（archives/86）。本記事の06章で扱った「User-Agentだけでは偽装を見破れない」という論点は、この回で扱った「robots.txt無関係のインフラ層ブロック」というテーマと地続きです。

Googleの無料SEOツールを整理した回

Search Consoleをはじめとする、Googleが無料で公開しているSEOツール群を整理した記事もあります（【2026年8月時点】Googleの無料SEOツール完全ガイド）。本記事で扱ったIPレンジのJSONファイルも、Googleが無料で公開している公式情報の1つという位置づけで共通しています。

ログを行全体で探すと、クローラーの数字を見誤る回

アクセスログをUser-Agent文字列だけで検索すると、無関係な文脈まで拾ってしまう落とし穴を扱った回もあります（archives/136）。本記事の06章で「User-Agentだけに頼ると危ない」と述べた理由は、偽装のしやすさに加えて、集計する側の検索方法によっても数字が揺れるという、この回で扱った論点とも重なります。