ユーザーエージェント

TL;DR — ユーザーエージェントとは、すべてのブラウザとすべてのボットが 各リクエストとともに送信する「私は誰です」という短いテキスト行のことです。 GoogleのクローラーはGooglebot、Bingのクローラーはbingbotと名乗ります。robots.txtでは、 その行全体を書くのではなく、Googlebotのような短い名前（「トークン」）を使います。 そして、ここが重要なポイントです。その行は単なるテキストなので、誰でも偽装できます。 ボットが名乗っている本人であることを本当に確認する唯一の方法は、 そのリクエストが実際にどこから来たのかを確認することです。

ユーザーエージェントとは

ブラウザがページを読み込むたびに、それが何であるかを示す短いテキストラベルが送信されます。「Mac上のChromeです」のようなものです。このラベルがユーザーエージェントであり、すべてのリクエストのHTTPヘッダーに含まれています。サーバーはこれを読み取って、それに応じて対応できます。

最初に重要な注意点があります。クライアントがそのラベルを自分で入力します。それをチェックするものは何もありません。これは主張であり、資格情報ではありません。つまり、「Googlebot」と表示されるユーザーエージェントは、実際にGooglebotとして検証されたリクエストと同じではありません。

クローラーも同じことをします。Googlebotがページを取得するとき、Googlebotを含むユーザーエージェントを送信します。Bingbotが取得するとき、ユーザーエージェントにはbingbotが含まれます。これが、ボットがサーバーログで自分自身を名乗る方法です。

文字列と短い名前

「ユーザーエージェント」と言うとき、実際には2つのものを指しており、混同すると多くの混乱を招きます。

• ユーザーエージェント文字列は、リクエストヘッダー内の完全な行です。Googlebotのものは長く、ブラウザによく似ています。
• ユーザーエージェントトークンは、robots.txtでボットを対象にするために使用する短い名前です。Googlebotやbingbotのようなものです。トークンは完全な文字列の一部にすぎず、全体ではありません。

したがって、robots.txtでルールを書くときは、短いトークンを使用します。

User-agent: Googlebot
Disallow: /private/

そこに巨大なブラウザ風の文字列を貼り付ける必要はありません。

文字列は信頼できない

これだけは覚えておいてください。ユーザーエージェント行はプレーンテキストなので、誰でも偽装できます。 どんなスクリプトでも、1行のコードでGooglebotだと主張できます。そして、ブロックをすり抜けるためにそうするものも少なくありません。Google自身も、Googlebotヘッダーは「しばしば偽装される」と述べています。

つまり、ユーザーエージェントだけに基づいてサイトへのアクセスを許可するかどうかを決定すべきではありません。実際に訪問者が本物のGooglebotであることを確認する必要がある場合（たとえば、ログを読んでいる場合）、リクエストの送信元を確認して検証します。自分が何であると主張しているかではありません。詳細な方法は「詳細」タブで説明しています。

いくつかの注意点

• robots.txtのユーザーエージェント名は大文字と小文字を区別しません。Googlebotとgooglebotは同じです。
• User-agent: *ですべてをブロックしても、Googleのすべてのボットをブロックするわけではありません。広告クローラーとセーフティクローラーはワイルドカードを無視します。
• クローラーに1つのバージョンのページを表示し、実際のユーザーに別のバージョンを表示することはクローキングであり、Googleはこれをスパムとして扱います。

完全な情報（トークンテーブル、すべてのGoogleおよびBingクローラー、正確な検証コマンド、クローキングルール）が必要な場合は、詳細タブに切り替えてください。

TL;DR — ユーザーエージェントとは、あらゆるクライアントが自身を識別するために送信するHTTPリクエストヘッダーです。これは任意であり、クライアントが入力するメタデータであり、認証された身元ではありません。その値がユーザーエージェント文字列です。これとは別に、robots.txtで使用されるユーザーエージェントトークン（プロダクトトークン）があります。RFC 9309によれば、トークンは文字列の部分文字列であるべき（SHOULD）であり、これは強い慣習ですが、文書化された例外があります（Google-Extendedにはリクエスト文字列がまったくありません）。マッチングは大文字と小文字を区別せず、トークン行のバージョン番号やワイルドカードは無視され、最も具体的なグループが優先され、同じトークンのグループはマージされますが、*とはマージされません。文字列は簡単に偽装できます。Google自身も自社のものを「しばしば偽装される」と呼んでいます。そのため、Googleの場合はgooglebot.com/google.com/googleusercontent.com、Bingの場合はsearch.msn.comに対して、逆引きDNSと正引きDNS（プロキシやCDNの背後では実際のクライアントIPを使用）で検証するか、公開されているIPレンジと照合してください。検証済みのリクエストでも、リクエストが到着したことしか証明できず、ページがインデックスされた、取得された、AIトレーニングに使用されたということは証明できません。AdsBotとGoogle-SafetyはUser-agent: *を無視します。ChromeはブラウザのUA文字列から詳細情報を削除しつつあります（User-Agent削減）。Client Hintsは構造化されたがオプトインの代替手段であり、どちらもクローラー検証の代わりにはなりません。ユーザーエージェントの適応は正当な場合もありますが、クローラーに実質的に異なるコンテンツを欺瞞的に表示することはクローキングになり得ます。

ヘッダー、文字列、トークン

3つのものを区別することが、このトピックの大部分です。

• ヘッダー。 User-AgentはHTTP リクエストヘッダーです。ブラウザ、curl、クローラー、ボットなど、あらゆるクライアントが送信します。RFC 9110（中核となるHTTPセマンティクス標準）によれば、これはクライアントが入力する任意のフィールドであり、サーバーが検証した認証済みの身元ではなく、クライアントが提供する説明的なメタデータです。
• 文字列。 ヘッダーの値であり、ソフトウェア、バージョン、レンダリングエンジン、場合によってはOSを説明する自由形式の行です。
• トークン。 robots.txtのUser-agent:行でクローラーを対象にするために使用される短い識別子です。Googlebot、bingbot、Google-Extendedなどです。

人々がつまずくのは、この関係性です。RFC 9309（正式なRobots Exclusion Protocol標準）は、トークンは*「クローラーが送信する識別文字列の部分文字列であるべき（SHOULD）…HTTPの場合、プロダクトトークンはUser-Agentヘッダーの部分文字列であるべき（SHOULD）です。」と述べています。これはMUSTではなくSHOULDであり、標準が推奨する強い慣習ではありますが、すべてのクローラーが機械的に従う厳格な要件ではありません。Google-Extended（後述）は、この文書化された例外の最も明確な例です。Googleが自社のほとんどのトークンでこれに従っているからといって、部分文字列ルールを普遍的なものと読まないでください。プロバイダーがトークンを提供する場合、トークンは文字列の一部*です。robots.txtではトークンを対象にし、ログでは文字列を読み取ります。

Google自身が自社のボットの識別方法について述べていることは、ここで役立ちます。「Googleのクローラーは、HTTP user-agentリクエストヘッダー、リクエストの送信元IPアドレス、送信元IPの逆引きDNSホスト名の3つによって身元を識別します。」 ユーザーエージェントは3つのうちの1つにすぎないことに注意してください。残りの2つが実際の検証方法です。

Google-Extended: 文字列を持たないトークン

トークン ≠ 文字列を最も明確に示すのはGoogle-Extendedです。これは、GoogleがGeminiのトレーニングとグラウンディングにあなたのコンテンツを使用できるかどうかを制御します。そして、専用のHTTPリクエストユーザーエージェント文字列はまったくありません。 クロール自体は既存のGooglebot文字列で行われます。Google-Extendedは、robots.txtの制御トークンとしてのみ存在します。ログのリクエストヘッダーに「Google-Extended」が表示されることは決してありません。

実際的な結果として、Google-Extended をブロックすると、コンテンツの AI トレーニング利用のみに影響します。検索でのクロールやインデックス登録を Googlebot が停止することはありません。これらは別々のトークンで制御される別々の判断です。(サイトを読むボットの全体像については、AI クローラーとクローラーを参照してください。)

Googlebot のユーザーエージェント文字列

Googlebot は「エバーグリーン」です。最近のバージョンの Chrome で動作し、その文字列内の Chrome バージョンは定期的に更新されます(2019 年 12 月以降)。そのため、バージョンは W.X.Y.Z プレースホルダーとして表示されます。

Googlebot スマートフォン(モバイル):

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Googlebot デスクトップ:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

覚えておくべきことが 2 つあります。まず、バージョンをハードコードしないでください。W.X.Y.Z は変更されるため、それに一致させると壊れます。代わりに、安定したトークン Googlebot に一致させてください。次に、robots.txt ではモバイルとデスクトップを分離できません。両方のバリアントが 1 つの Googlebot トークンを共有するため、robots.txt のルールは両方に適用されます。

Google のクローラートークン

Google は、それぞれ独自のトークンを持つクローラーとフェッチャーのファミリー全体を運営しています。最もよく遭遇するものは次のとおりです。

そして、通常のルールを破るもの — User-agent: * を無視する 特別なケースのクローラー:

• AdsBot (AdsBot-Google) と AdsBot Mobile (AdsBot-Google-Mobile) — ワイルドカードに従いません。ブロックするには、明示的に名前を指定する必要があります。
• AdSense (Mediapartners-Google) — 同様。グローバルな * を無視します。
• Google-Safety — マルウェア/不正使用の検出に使用されます。robots.txt を完全に無視します。

その意味するところは、多くの人が見逃す点です。User-agent: * は AdsBot や Google-Safety をブロックしません。 ワイルドカードで「すべてのボットをブロック」して AdsBot がいなくなったと思っても、実際にはいません。(これはまさに、robots.txt でブロックされているのにインデックスされるという領域にページが入り込む種類の驚きです。完全な制御の話については robots.txt を参照してください。)

Bingbot のユーザーエージェント文字列

Bing は 2022 年に Bingbot の文字列を再構築し、Microsoft Edge でレンダリングされることを反映しました。現在の文字列は次のとおりです。

Bingbot デスクトップ:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36

Bingbot モバイル:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

robots.txt トークンは単に bingbot です。注意すべき点: 2022 年以降、Bingbot の文字列は実際の Chrome/Edge ブラウザーとほぼ同じに見えます。唯一の違いは、その中の bingbot/2.0 フラグメントです。UA でボットをフィルタリングまたは検出するロジックがある場合、その変更は重要です。

robots.txt がトークンを実際に照合する方法

クローラーが従うルールのグループを決定するルールがいくつかあります(Google の robots.txt 仕様と RFC 9309 による):

• 最も具体的な一致が優先されます。 Google は “クローラーのユーザーエージェントに一致する最も具体的なユーザーエージェントを持つグループを見つけて…正しいルールのグループを決定します。” Googlebot の Googlebot グループは、* グループよりも優先されます。
• 同じトークンのグループはマージされます — ただし * とは決してマージされません。 同じエージェントを指定する複数のグループは結合されます。特定のエージェントのグループと * グループはマージされません。* は、特定のものが一致しない場合のフォールバックにすぎません。
• 大文字と小文字は区別されません。 フィールド名と値の両方 — Googlebot、googlebot、GOOGLEBOT は同等です。
• トークン行のバージョン番号とワイルドカードは無視されます。 Google によると、“googlebot/1.2 と googlebot* はどちらも googlebot と同等です。” ファミリーに一致させるために User-agent: Googlebot* と書くことはできません。そこでの * は何もしません。

つまり、User-agent: 行はトークンを受け取り、それをクローラーの識別情報のプレーンな（大文字小文字を区別しない）部分文字列として照合します。バージョンの固定も、その中のワイルドカードもありません。

文字列を信頼できない理由と、検証方法

ユーザーエージェント文字列は自由形式のテキストです。何でも設定できます。 curl の1行で Googlebot を名乗ることができ、多くのツールや悪意のあるボットがまさにそれを利用してブロックをすり抜けます。Google 自身も Googlebot のドキュメントで次のように述べています: “the HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (翻訳) 「Googlebot が使用する HTTP ユーザーエージェントリクエストヘッダーは、他のクローラーによって偽装されることがよくあります。」 私が Googlebot ガイド で述べたように、“Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (翻訳) 「多くの SEO ツールや一部の悪意のあるボットは Googlebot を装います。これにより、それらをブロックしようとするウェブサイトにアクセスできる可能性があります。」

したがって、文字列だけでアクセスやコンテンツの判断を下してはいけません。代わりに検証してください。

どちらの方法でも前提条件が1つあります: 実際の 送信元 IP を取得することです。サイトがリバースプロキシ、ロードバランサー、または CDN の背後にある場合、デフォルトのアクセスログに記録されるアドレスはプロキシの IP であり、クローラーの IP ではない可能性があります。元のクライアント IP（通常は X-Forwarded-For などのヘッダーで転送され、プロキシで正しく設定されます）が必要です。そうでなければ、以下のどちらの検証方法も意味をなしません。

方法 1 — 逆引き + 正引き DNS（スポットチェックに最適）。 Google の2つの手順:

1. “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (翻訳) 「ログからアクセス元 IP アドレスに対して、host コマンドを使用して逆引き DNS ルックアップを実行します。ドメイン名が googlebot.com、google.com、または googleusercontent.com のいずれかであることを確認します。」
2. “Run a forward DNS lookup on the domain name retrieved in step 1… Verify that it’s the same as the original accessing IP address from your logs.” (翻訳) 「手順1で取得したドメイン名に対して正引き DNS ルックアップを実行します…それがログの元のアクセス元 IP アドレスと同じであることを確認します。」

Bingbot の場合も同じ2段階の手順ですが、ホスト名は search.msn.com で終わる必要があります（Bing ブランドのドメインではない — よくある驚きです）。コマンドはスクリプトタブにあります。

方法 2 — 公開 IP レンジ（大規模に最適）。 Google はハードコーディング用の静的許可リストを公開していません（“these IP address ranges can change” (翻訳) 「これらの IP アドレスレンジは変更される可能性があります」）が、照合できる機械可読な CIDR JSON ファイルは公開しています（common-crawlers.json およびより広範なクローラーファイル）。Bing も現在はレンジを公開しています。私はまさにこの目的のために Googlebot IP 検証ツール を構築しました — IP を貼り付けると分類されます。Bing Webmaster Tools には組み込みの「Bingbot の確認」ツールもあります。

DNS は一度きりのログチェックに適しており、IP レンジの照合は大量検証に適しています。どちらでも合う方を使いましょう — ただし、どちらかは必ず使ってください。また、期待されるホスト名とレンジファイルの両方を今日時点のものとして扱い、恒久的なものとは見なさないでください。Google と Bing はこれらのパスを以前に変更したことがあります（この記事が最初に書かれて以来、IP レンジ JSON ファイルは移動され、名前が変更されました）。そのため、以前機能していたルックアップが一致しなくなった場合は、ライブの検証ドキュメントを再確認してください。

UA の一致は下流の結果の証明にはならない

完全に検証されたリクエストでさえ — 実際の Googlebot IP、正引きで確認された逆引き DNS、すべてが一致 — 証明できるのは1つのことだけです: そのリクエスト がサーバーに到達したということです。これをより大きな主張に拡大解釈したくなりますが、以下のそれぞれは別個の事実であり、それぞれ別個の証拠が必要です:

• リクエスト受信 — そのユーザーエージェントを持つリクエストがサーバーに到達した。（ログ検証が実際に証明すること。）
• 身元確認 — リクエストが主張するクローラーから実際に来たもの。（逆DNS / IPレンジマッチングが追加で証明すること。）
• コンテンツ取得・レンダリング — クローラーがページを正常にレンダリングした（エラーなし、ブロックされたリソースなし）。リクエストが届いただけでは保証されない。
• インデックス登録 — URLが検索インデックスに入った。取得が成功してもインデックス登録は保証されない。
• 検索・引用・トレーニングに使用 — 特にAIクローラー（Google-Extended、GPTBotなど）の場合、クロールはコンテンツが特定の回答に使用されたり、引用されたり、モデルのトレーニングに使われたことの証明にはならない。これらはクロールの下流にある、別個でほとんど観測不可能なステップである。

ログ内の検証済みGooglebotヒットは実際のシグナルである — ただし、それが実際に示す以上の意味に拡張しないこと。

Web Bot Auth: 検証の今後

2026年、GoogleはWeb Bot Authの実験を開始した — “an experimental cryptographic protocol used to authenticate requests sent by bots.” そのアイデアは、“move beyond easily spoofed headers to a verified identity and decouple agent identity from IP addresses.” ボットはリクエストに暗号署名し、サイトはGoogleが公開する公開鍵に対して署名を検証し、署名付きリクエストにはSignature-Agentヘッダーが含まれる。Google自身の注意書きが重要だ: “We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.” つまり、これは追加的なものであり、置き換えではない — 逆DNSとIPレンジは今日のベースラインのままである。

ブラウザもUA文字列からの解析が難しくなっている

上記はすべてクローラーに関するものだが、同じ「文字列を過信しない」教訓はブラウザにも当てはまり、その傾向は強まっている。ChromeはUser-Agent reductionを展開している: UA文字列の一部（完全なブラウザバージョン、OSバージョン、デバイスモデル）を正確に報告する代わりに、凍結または粗くするもので、文字列が特定ユーザーのフィンガープリントに使われないようにする。Google自身の説明: “The granularity and abundance of detail can lead to user identification. The default availability of this information can lead to covert tracking.” 実際には、正確なブラウザ/OS/デバイスバージョンをUA文字列解析に頼る — アナリティクス、デバイス検出、バグトリアージ — はますます信頼性が低くなり、今後さらに悪化するだろう。

Chromeが推奨する代替手段はUser-Agent Client Hints (UA-CH) である: サーバーが明示的に要求した場合にのみブラウザが送信する構造化データ。低エントロピーヒント（ブラウザブランド、メジャーバージョン、モバイルフラグ）はデフォルトで送信される。高エントロピーヒント（正確なバージョン、プラットフォームバージョン、デバイスモデル）は、サーバーがAccept-CHレスポンスヘッダーでオプトインする必要がある — ブロードキャストではなく、明示的なネゴシエーションである。これに依存する前に2つの注意点: これはChrome/Chromium系のメカニズムであり、すべてのブラウザが送信するわけではない。また、サポートされている場所でも、“the value may be blank, not returned, or populated with a varying value.” Client Hintsはブラウザ文字列の問題を解決する。これはクローラー検証メカニズムではない — GoogleとBingは依然としてDNSとIPレンジで自社のクローラーを検証しており、Client Hintsではない。

ユーザーエージェントターゲティングとクローキング

魅力的な動き — 「UAでGooglebotを検出して特別なものを配信する」 — は、技術的に脆弱であるだけでなく、ポリシー違反でもある。

脆弱な理由は、Googleが単一のUAでクロールしないからだ。Googlebot（モバイルとデスクトップ）、Google-InspectionTool、AdsBot、GoogleOtherなどを、変動するIPから正しく処理する必要がある — クリーンにホワイトリスト化するのは事実上不可能である。

ポリシー違反です。クローラーとユーザーに異なるコンテンツを配信することはクローキングにあたります：「検索ランキングを操作し、ユーザーを誤解させる意図で、ユーザーと検索エンジンに異なるコンテンツを提示すること。」 ペナルティはアルゴリズムによる順位低下から完全なインデックス削除まで及びます。この点に注意してください：正当な適応（レスポンシブレイアウト、コンテンツネゴシエーション）は問題ありませんが、ボットとユーザーの間でコンテンツ自体をすり替えることがクローキングに該当します。

ユーザーエージェントがより大きなパイプラインのどこに位置するかについては、クロール（ハブ）とクローラーを参照してください。それらのボットが取得を許可されているものを制御するには、robots.txtを参照してください。

AIまとめ

Advancedバージョンの簡潔な見解:

• 3つのものを区別する： User-Agentリクエストヘッダー — 任意であり、RFC 9110に基づくクライアント入力のメタデータで、認証されたIDではありません。その値であるユーザーエージェント文字列。そしてrobots.txtで使用されるトークン。RFC 9309によれば、トークンは文字列の部分文字列であるべき（SHOULD）です — 強い慣習であり、普遍的な規則ではありません。
• 文字列を持たないトークンもある。 Google-Extendedは文書化された例外です：これはrobots.txtの制御（Geminiトレーニング）としてのみ存在し、クロールは通常のGooglebot文字列を使用します。これをブロックしてもSearchインデックスには影響しません。
• Googlebot/Bingbotの文字列は常に最新です — ChromeのバージョンはW.X.Y.Zと表示され、変更されます。安定したトークン（Googlebot、bingbot）に一致させ、バージョンには決して一致させないでください。モバイルとデスクトップのGooglebotは1つのトークンを共有します。2022年以降のBingbotは、bingbot/2.0フラグメントを除いて実際のブラウザのように見えます。
• robots.txtのマッチング： 最も具体的なグループが優先されます。同じトークンのグループはマージされますが、*とは決してマージされません。マッチングは大文字と小文字を区別しません。User-agent:行のバージョン番号とワイルドカードは無視されます（Googlebot* = Googlebot）。
• AdsBotとGoogle-SafetyはUser-agent: *を無視します — 名前でブロックするか、まったくブロックしないかのどちらかです。
• 文字列は簡単に偽装されます（Google自身も「しばしば偽装される」と呼んでいます）。まず実際のクライアントIPを取得し（プロキシ/CDNがログでそれを隠す可能性があります）、次に逆引き+正引きDNS（googlebot.com/google.com/googleusercontent.com；Bing → search.msn.com）または公開されたIP範囲で検証します — Googleはこれらのファイルを以前に改名・移動したことがあるため、ルックアップが一致しなくなった場合はライブドキュメントを再確認してください。アクセス制御に文字列を決して信頼しないでください。
• 検証済みのリクエストでも、下流のすべてが証明されるわけではありません。 リクエスト受信、ID確認、コンテンツレンダリング、ページインデックス、コンテンツ取得/引用/トレーニング使用はそれぞれ別の主張であり、別々の証拠が必要です — ログヒットは最初のものだけを証明し、それ以外は自動的には証明しません。
• Web Bot Auth（2026年、実験的）はリクエストに暗号署名を行います — 追加的なもので、DNS/IPが依然としてフォールバックです。
• ブラウザのUA文字列も解析が難しくなっています： ChromeのUser-Agent削減により、正確なバージョン/OS/デバイスの詳細が文字列から除外されます。Client Hintsが構造化されたオプトインの代替手段ですが、Chrome固有であり、クローラー検証の代わりにはなりません。
• UAによって異なるコンテンツを配信することはクローキングです — スパムポリシー違反であり、Googleが多くのUAでクロールするため脆弱です。

公式ドキュメント

検索エンジンと標準規格からの一次情報ドキュメント。

Google

• Overview of Google crawlers and fetchers (user agents) — 3つの識別シグナルと完全なクローラーリスト。
• Google’s common crawlers — トークンとユーザーエージェント文字列の表。
• Google Special-Case Crawlers — AdsBot、Mediapartners-Google、Google-Safety、および*の例外。
• Verify Requests from Google Crawlers and Fetchers — 2段階のDNSメソッドとIPレンジファイル。
• What Is Googlebot — Googlebotの文字列と「しばしば偽装される」という注記。
• How Google Interprets the robots.txt Specification — トークンのマッチング、大文字小文字の区別なし、無視されるワイルドカード。
• Authenticating Requests with Web Bot Auth (Experimental) — 暗号署名プロトコル。
• Updating the user agent of Googlebot (2019) — 文字列がW.X.Y.Zと表示される理由。
• Spam Policies — Cloaking — 定義とペナルティ。

Bing / Microsoft

• Announcing user-agent change for Bingbot (Apr 2022) — 現在のデスクトップおよびモバイルの文字列（Fabrice Canel）。
• How to Verify that Bingbot is Bingbot (Aug 2012) — *.search.msn.comの逆DNSメソッド。
• Bing Webmaster Tools — Verify Bingbot — 組み込みの検証ツール。

標準

• RFC 9110 — HTTP Semantics, §10.1.5 User-Agent — コアHTTP仕様：User-Agentはオプションのクライアント提供フィールドであり、認証されたIDではない。
• RFC 9309: Robots Exclusion Protocol — ユーザーエージェント文字列のサブストリングとしてのプロダクトトークンの正式なSHOULDレベルの定義。
• MDN — User-Agent header — ヘッダー自体のHTTP構文。

ブラウザUA文字列

• Chrome Privacy Sandbox — User-Agent reduction — ChromeのUA文字列で凍結・粗粒度化される内容とその理由。
• Chrome for Developers — User-Agent Client Hints — 低エントロピーと高エントロピーのヒント、およびAccept-CHのオプトイン。

ソースからの引用

Google、Bing、RFCからの公式発言。各リンクは、ソースページの引用箇所にジャンプするディープリンクです。

Google — クローラーの自己識別方法

• “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” (翻訳) 「Googleのクローラーは、HTTPのuser-agentリクエストヘッダー、リクエストの送信元IPアドレス、送信元IPの逆DNSホスト名の3つによって自己識別します。」 — Google Search Centralドキュメント。 引用へジャンプ

Google — 文字列は偽装される

• “The HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (翻訳) 「Googlebotが使用するHTTPのuser-agentリクエストヘッダーは、他のクローラーによってしばしば偽装されます。」 — Google Search Centralドキュメント。 引用へジャンプ

Google — DNSによる検証

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (翻訳) 「ログからアクセス元IPアドレスに対して、host コマンドを使って逆DNSルックアップを実行します。ドメイン名が googlebot.com、google.com、または googleusercontent.com のいずれかであることを確認します。」 引用へジャンプ
• “Google doesn’t post a public list of IP addresses for website owners to allowlist because these IP address ranges can change.” (翻訳) 「Googleは、ウェブサイト所有者が許可リストに追加できるIPアドレスの公開リストを公開していません。これらのIPアドレス範囲は変更される可能性があるためです。」 引用へジャンプ

Google — robots.txtトークンのマッチング

• “All non-matching text is ignored (for example, both googlebot/1.2 and googlebot* are equivalent to googlebot).” (翻訳) 「一致しないテキストはすべて無視されます（たとえば、googlebot/1.2 と googlebot* はどちらも googlebot と同等です）。」 — Googleのrobots.txt仕様。 引用へジャンプ

Google — Web Bot Auth

• “An experimental cryptographic protocol used to authenticate requests sent by bots.” (翻訳) 「ボットによって送信されたリクエストを認証するために使用される実験的な暗号プロトコル。」 引用へジャンプ
• “We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.” (翻訳) 「特定のエージェントのすべてのリクエストに署名するわけではありません。確立されたボット検証方法にフォールバックするようにしてください。」 引用へジャンプ

Google — クローキング

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (翻訳) 「クローキングとは、検索ランキングを操作しユーザーを誤解させる意図で、ユーザーと検索エンジンに異なるコンテンツを提示する行為を指します。」 — Google検索の基本、スパムポリシー。 引用へジャンプ

RFC 9309 — トークンは文字列の部分文字列である

• “The product token SHOULD be a substring of the identification string that the crawler sends to the service. For example, in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” (翻訳) 「プロダクトトークンは、クローラーがサービスに送信する識別文字列の部分文字列であるべきです（SHOULD）。たとえば、HTTPの場合、プロダクトトークンはUser-Agentヘッダーの部分文字列であるべきです（SHOULD）。」 引用へジャンプ

Patrick Stox — スプーフィングについて

• “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (翻訳) 「多くのSEOツールや一部の悪意のあるボットは、Googlebotを装います。これにより、それらをブロックしようとするウェブサイトにアクセスできる可能性があります。」 — Ahrefsの私のGooglebotガイドより。 読む

クローラー → トークン → 文字列 → 検証

参照テーブル。トークンは robots.txt に記述するものです。検証ホスト名は、正規のリクエストが逆引き解決されるものです。

robots.txt のマッチングルール早見表

早わかり

• トークン = UA 文字列の部分文字列（RFC 9309）。文字列全体ではない。
• モバイルとデスクトップの Googlebot は1 つのトークンを共有 — robots.txt で分割することはできない。
• 文字列内の Chrome バージョンは W.X.Y.Z — 変更されるため、ハードコードしないこと。
• UA 文字列は簡単に偽装できる — DNS または IP で検証し、文字列を信頼しないこと。

逆引き + 正引き DNS でボットを検証する

ユーザーエージェント文字列は、curl の 1 行で偽装できます。ボットが本物かどうかは、実際に接続元の IP を確認して判断します。このパターンは Google と Bing で同じです — 期待されるホスト名だけが異なります。

まず正しい IP を取得します。リクエストがサーバーに到達する前にリバースプロキシ、ロードバランサー、または CDN を通過する場合、デフォルトのログにはクローラーのアドレスではなくプロキシのアドレスが表示されることがあります。以下のいずれかのチェックを実行する前に、実際のクライアント IP（正しく設定された転送ヘッダーから）を使用してください。

macOS / Linux

# --- Googlebot ---
# 1) Reverse DNS the IP from your logs — must end in googlebot.com, google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

# --- Bingbot ---
# Reverse DNS must end in search.msn.com, then forward-confirm back to the IP
host 157.55.39.1
host <the-hostname-it-returned>

Windows

:: Googlebot
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

:: Bingbot
nslookup 157.55.39.1
nslookup <the-hostname-it-returned>

逆引き DNS の結果が期待されるドメインで終わらない場合 — Google の場合は googlebot.com / google.com / googleusercontent.com、Bing の場合は search.msn.com — または正引き DNS の結果が元の IP と一致しない場合、ユーザーエージェント文字列が何であれ、それは本物のボットではありません。

公開 IP レンジとの照合（大規模向け）

大量のアクセスを検証するには、リクエストごとの DNS をスキップし、IP をエンジンの公開 CIDR レンジと照合します。Google は機械可読な JSON を公開しています：

https://developers.google.com/static/crawling/ipranges/common-crawlers.json
https://developers.google.com/static/crawling/ipranges/special-crawlers.json
https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.json

ファイルを取得し、CIDR セットを構築し、ログに記録された各 IP がそのセットに含まれるかテストします。（私はこれを実行する Googlebot IP 検証ツール を構築しました。）Bing もレンジを公開しており、Bing Webmaster Tools には組み込みの「Bingbot の検証」チェックがあります。

ユーザーエージェントの健全性チェックリスト

UA ルールを作成したり、ログ内のボットに対してアクションを実行する前に：

• robots.txt 内の トークン（例: Googlebot）をターゲットにしており、完全な UA 文字列を貼り付けていない。
• User-agent: 行にバージョン番号や * が含まれていない（これらは無視されるため、Googlebot* は効果がない）。
• User-agent: * が AdsBot や Google-Safety をブロックすると思い込んでいない（ブロックしないため、必要なら明示的に指定する）。
• Google-Extended をブロックした場合、AI トレーニング用途にのみ影響し、Googlebot は検索用にクロールとインデックスを続けることを理解している。
• アクセス制御やコンテンツを生の UA 文字列でキー設定していない（偽装可能なため）。
• 「これは本当に Googlebot か？」というチェックは、逆引き + 正引き DNS（googlebot.com / google.com / googleusercontent.com）または公開 IP レンジ（Bing は search.msn.com）を経由して行う。
• バージョン固定の UA マッチングをどこでも行っていない（Chrome の W.X.Y.Z 部分は変更されるため）。
• ボット UA にユーザーとは異なるコンテンツを配信していない（それはクローキングである）。

ユーザーエージェントを扱うためのツール

私自身の無料ツールのうち 3 つが、このトピックで人々が実際に求める 3 つのタスクをカバーしています。主張されたボットが本物かどうかの確認、実際にサイトにアクセスしているユーザーエージェントの確認、AI クローラーに何が許可されているかの確認です。

Googlebot Verifier — この記事が繰り返し言及するまさにその問題に対応するツールです。ユーザーエージェント文字列は単なるテキストなので、それだけを信頼することはできません。ログから IP アドレスを貼り付け、それが主張するクローラー（Googlebot、Bingbot など）を選択すると、逆引き + 正引き DNS チェックと公開 IP レンジの一致を実行し、階層化された判定 — 逆引き DNS 確認済み、公開レンジ内、偽装、検証不能、または 既知のクローラーではない — を返します。1 つの IP ではなく 1 日分のヒットを確認する必要がありますか？一括ボックスに最大 500 個の IP または生のログ行を貼り付けます。

Log File Analyzer — 「どのユーザーエージェントが実際に私のサイトをクロールしているか？」という質問に対応します。サーバーアクセスログ（nginx、Apache、IIS/W3C、または JSON）をドロップすると、ブラウザ内で完全に解析し、クロールアクティビティをボット別・セクション別に分類し、ステータスコードの無駄をフラグし、AI クローラーを検索クローラーから分離し、そしてこのトピックで最も重要な部分として、既知のクローラーのユーザーエージェントトークンを主張するリクエストを IP で裏付けずに特定する スプーファーレポート を実行します。

AI-Crawler Access Checker — Googlebot や bingbot のように動作しない新しいトークンファミリー向けです。URL を入力すると、robots.txt をすべての主要な AI クローラーのユーザーエージェントトークン（GPTBot、ClaudeBot、PerplexityBot、Google-Extended など）に対してチェックし、それぞれに勝つ正確なルールを表示し、llms.txt が存在するかどうかをフラグします。Google-Extended のようなトークンが意図したとおりに動作しているかを確認するのに役立ちます。前述のとおり、ログで確認できる独自のリクエスト文字列がないためです。

ユーザーエージェントタスク用のプロンプト

このトピックが仕掛ける特定の罠（偽装と robots.txt トークン構文）に基づいて構築された 2 つのプロンプトです。一般的な「SEO を監査して」という埋め草ではありません。自分のデータをプレースホルダーに貼り付けてください。

プロンプト 1 — ログから取得したユーザーエージェント文字列のバッチを偽装の兆候についてトリアージする

アクセスログから取得した生のユーザーエージェント文字列の列を貼り付けてください（IP ではありません。このプロンプトは ID を検証できず、文字列自体の不整合のみを検出できます）。

Here is a list of raw User-Agent strings from my server access log, one per
line. For each one:
1. Say which crawler token it claims to be (e.g. Googlebot, bingbot,
   GPTBot), or "no recognizable token" if none.
2. Flag anything internally inconsistent for that claimed crawler — e.g. a
   claimed Googlebot string missing "compatible; Googlebot" or the
   "+http://www.google.com/bot.html" URL, a claimed bingbot string missing
   "bingbot/2.0", or a Chrome version that looks hand-typed rather than a
   real evergreen build.
3. Remind me that this is a text-pattern check only — it cannot confirm
   identity. Real verification requires reverse+forward DNS or matching
   against the crawler's published IP ranges.

[paste user-agent strings here]

プロンプト 2 — robots.txt のトークンマッチングの誤りをチェックする

完全な robots.txt ファイルを貼り付けてください。

Review this robots.txt file for user-agent token mistakes:
1. Flag any User-agent line that includes a version number or a wildcard
   inside the token (e.g. "Googlebot/1.2" or "Googlebot*") — these are
   ignored, not matched as a family.
2. Check whether User-agent: * is being relied on to block AdsBot-Google,
   AdsBot-Google-Mobile, Mediapartners-Google, or Google-Safety — these
   ignore the wildcard and need their own named group if I want them
   blocked.
3. Note any duplicate groups for the same token that could be merged, and
   confirm token matching here is case-insensitive so I don't need
   near-duplicate groups for casing variants.
4. List which named groups exist and which of Google's/Bing's common
   crawler tokens (Googlebot, Googlebot-Image, Google-Extended, bingbot)
   have no explicit group at all, so I know they're falling through to *.

[paste robots.txt here]

自分をテストする: ユーザーエージェント

ヘッダー、文字列、トークン、ボットが本物かどうかの検証方法に関する 5 つの簡単な質問です。各質問に回答を選び、確認してください。

時間をかける価値のあるリソース

関連記事

• What Is Googlebot & How Does It Work? — Googlebot の完全な UA 文字列、検証方法、私の IP 検証ツール。
• Indexed, though blocked by robots.txt — UA ベースのブロックと robots.txt のブロックが衝突するケース。
• Robots.txt and SEO: Everything You Need to Know — ユーザーエージェントグループとルールが実際にどのように機能するか。
• Meet the New Web Crawlers: AI Bots Are Closing in on Search Engine Bots — ログに記録されるユーザーエージェントの変化。

公式 / 標準

• RFC 9110 — HTTP Semantics, §10.1.5 User-Agent — 基本定義: 任意指定のクライアント提供メタデータ。
• RFC 9309: Robots Exclusion Protocol — 正式な SHOULD レベルの製品トークン部分文字列定義。
• Google の Overview of crawlers and fetchers と Verify Google crawlers。
• Chrome Privacy Sandbox — User-Agent reduction と User-Agent Client Hints — ブラウザの UA 文字列が解析しにくくなっている理由と、その代替手段。

その他の情報源

• John Mueller — Bots that impersonate Googlebot — スプーフィングと、逆引き DNS が答えである理由について。
• MDN — User-Agent header — HTTP 仕様から見たヘッダー。
• r/TechSEO — クロール/ログデバッグのコミュニティ。
• Web Bot Auth: Google’s new experimental method to validate authentic bots (Search Engine Land, Barry Schwartz, May 2026) — 暗号化ボット署名の仕組みと実際の意味についての最良のニュースデスク要約。
• Google-Agent user agent identifies AI agent traffic in server logs (Search Engine Land) — robots.txt を無視し Web Bot Auth を使用する新しいユーザー起動型フェッチャーについて。
• Google Is Testing New Bot Authorization Standard (Search Engine Journal) — IETF 標準と、それを支持する企業 (Amazon、Cloudflare、Akamai、OpenAI) に関する広範な業界コンテキスト。
• Announcing future user-agents for Bingbot (Bing Webmaster Blog, Fabrice Canel, Dec 2019) — 2022 年の展開前に行われた、Bingbot の Edge ベースレンダリングへの移行に関する当初の発表。
• Microsoft list of Bingbot IP addresses released (Search Engine Land) — 大規模なボット検証のための IP 範囲公開という Bing の決定に関する報道。

変更履歴