ユーザーエージェント

ユーザーエージェント（User-Agent）とは、Webにアクセスするソフトがリクエストのたびに名乗る自己申告の名前です。この名前でブラウザ（Chrome等）とボット（GPTBot等）を見分け、robots.txtでもこの名前を指定してルールを書きます。ただし自己申告なので詐称が可能で、本物か確かめるには公式IPレンジとの照合が要ります。

ユーザーエージェントとは（正確な定義）

ユーザーエージェント文字列は、HTTPリクエストのUser-Agentヘッダーに入る、送信元ソフトの名前です。HTTP（＝Webのやり取りの取り決め）では、リクエストに複数のヘッダー（付帯情報）を添えられ、そのひとつがUser-Agentです。もともとは「どのブラウザ向けにページを最適化するか」をサーバーが判断するための情報でしたが、現在はボットの識別や、robots.txtでの取得ルールの宛先指定にも広く使われています。

User-Agentは、AI検索対策における「観測」と「制御」の両方の起点になる、地味だが決定的に重要な要素です。どのAIボットが自社に来ているかを知るのも、どのボットに何を許すかを指定するのも、すべてこの一つの文字列を軸に回ります。裏を返せば、User-Agentの意味と限界を正しく理解していないと、AI検索対策の観測も制御も土台から狂います。とくに「自己申告なので詐称できる」という性質は、セキュリティとアクセス制御の両面で必ず押さえておくべき前提です。

「エージェント（agent）」は英語で「代理人・代行するもの」を意味します。ユーザーエージェントとは文字どおり「ユーザーの代わりにWebへアクセスするソフト」を指す言葉で、ブラウザはその代表例です。人間がURLを開くとき、実際にサーバーへリクエストを送っているのはブラウザというエージェントであり、その正体を名乗るのがUser-Agent文字列です。ボットも同じ仕組みで自分の名前を名乗るため、サーバー側からは「どんなエージェントが来たか」を、この一つの文字列で受け取ることになります。

なぜ重要か（AI検索での位置づけ）

AI検索対策では、「どのAIボットが自社に来ているか」を知ることが出発点で、その判別の鍵がUser-Agentです。サーバーログのUser-Agent列に「GPTBot」「OAI-SearchBot」等が出ていれば、そのボットの訪問を確認できます。さらに、robots.txtでAIボットを許可・拒否する際も、対象をUser-Agent名（正確にはrobots.txt用のトークン＝識別名）で指定します。つまりUser-Agentは、AIクローラーを「観測する」入口であると同時に、「制御する」宛先でもある、二重に重要な概念です。

この二重の役割は、AI検索対策の作業を一本の線でつなぎます。まずサーバーログのUser-Agentで「誰が来ているか」を観測し、その結果を踏まえてrobots.txtのUser-agent行で「誰に何を許すか」を制御し、再びログで「制御が効いたか」を観測する——という往復です。この観測と制御の両方が同じUser-Agentという語彙で回っているため、ここを正確に理解しているかどうかが、AI検索対策を実データに基づいて回せるかの分かれ目になります。逆に、UAの意味を曖昧なまま設定を触ると、意図と違うボットを止めてしまう、あるいは止めたつもりが止まっていない、といった事故が起きます。

もともとUser-Agentは、サーバーが相手のブラウザに合わせて表示を調整するための情報でした。古いブラウザには簡易版を、新しいブラウザには高機能版を返す、といった出し分けです。しかしWebの標準化が進んだ現在では、その用途は薄れ、代わりにアクセス解析でのブラウザ・端末の集計や、ボットの識別といった用途が前面に出ています。AI検索対策の文脈では、後者のボット識別こそがUser-Agentの主役の使い道です。もとの目的から役割が移り変わってきた歴史を知っておくと、UA文字列に古い慣習の名残（Mozilla/5.0など）が残っている理由も腑に落ちます。

仕組み／文字列の読み方

User-Agent文字列は一見複雑ですが、意味のある断片の集まりです。たとえばAIクローラーのUA例を分解すると、構造が見えてきます。

読み解きのコツは、末尾寄りの「ボット名/版数」と「+URL」に注目することです。ここに正体が凝縮されています。前半の Mozilla/5.0 やブラウザ名は歴史的な互換のための飾りで、そこだけ見るとブラウザと見分けがつかないことがあります。なぜMozilla/5.0がほぼすべてのUAに付いているかというと、かつてサーバーが特定ブラウザ向けに機能を出し分けていた時代の名残で、互換のために各ソフトが横並びで名乗るようになったためです。この事情を知らないと「Mozillaというソフトが来た」と誤読しかねません。UAは歴史的な事情の積み重ねでできているため、意味を持つのは末尾の識別部だと割り切って読むのが実務的です。

もう一段深く言えば、User-Agentはリクエストごとに独立して付く情報なので、同じ相手でも取得するリソースによって微妙に異なる文字列を名乗ることがあります。前述のとおりOpenAIはrobots.txtを取得するときだけ末尾に robots.txt の目印を足すことがあり、これはページ本体の取得とrobots.txtの確認をログ上で区別しやすくするための工夫です。実務でUAを扱うときは、完全一致でパターンを組むのではなく、ボット名という「核」の部分を含むかどうかで判定するのが、こうした細かなゆらぎに強い設計になります。

具体例・AIボットの代表的UA文字列

robots.txtには、このUA文字列そのものではなく、各社が定めた「robots.txt用のトークン（識別名）」を書きます。多くの場合ボット名と一致します（例：User-agent: GPTBot）。なお robots.txt を取得する際、OpenAIは末尾に robots.txt という目印を足したUAを使うことがあり、ログでrobots.txt取得だけを見分けやすくしています。これは、ログにパス（どのファイルを取りに来たか）が記録されていない環境でも、「これはrobots.txtの確認アクセスだ」とサイト側が判別しやすいようにという配慮です。細かい点ですが、各社が自社ボットの挙動をこの粒度まで公開していること自体が、UAを手がかりにボットを扱うという運用が成り立つ前提になっています。

なお、Google-Extended（Geminiの学習利用を制御するトークン）のように、HTTPリクエストのUA文字列を持たない制御専用トークンもあります。この場合、実際の取得は既存のGoogleのUA（Googlebot等）で行われ、Google-Extendedはrobots.txtの中でだけ意味を持つ「制御のための名前」として使われます。つまり「ログのUA列に出る名前」と「robots.txtに書く名前」は、必ずしも一対一で対応しません。この非対称を知らないと、robots.txtにGoogle-Extendedと書いたのにログにその名前が出ない、と混乱しかねないため、UAとトークンは別概念だと押さえておきます。

robots.txtで書くトークンとUA文字列の対応も、実務では一覧にして手元に置いておくと便利です。GPTBotはログにGPTBotとして現れ、robots.txtでもGPTBotと書く、というように多くは一致しますが、Google-Extendedのように「robots.txtにだけ存在し、ログのUAには現れない」例外があります。この対応表を持っておけば、robots.txtを更新したあとにサーバーログのどのUAを見て効果を確認すればよいかが、迷わず判断できます。観測（ログのUA）と制御（robots.txtのトークン）を一枚の表でつなぐことが、設定ミスを減らす地道な工夫になります。

よくある誤解・注意点

検証の実際の流れも押さえておきます。もっとも確実なのは、各社が公開するIPレンジのJSON（例：openai.com/gptbot.json）を取得し、ログに記録された接続元IPがその範囲に含まれるかを突き合わせる方法です。Googleの場合はIPレンジに加えて逆引きDNS（＝IPからホスト名を引く仕組み）で末尾が googlebot.com になるかを確認し、さらにそのホスト名を正引きして同じIPに戻るかまで確かめる二段構えが推奨されています。ここまでやって初めて「本物」と言えます。すべてのアクセスに毎回これを行うのは現実的でないため、重要な判断（大量アクセスの遮断、特定ボットの明示許可など）を下すときに限って検証する、という運用が一般的です。

• UAはリクエストごとに任意の文字列を名乗れます。ゆえに「名乗り」であって「証明」ではない
• 前半のMozilla/5.0やブラウザ名は互換のための慣習表記で、識別の本質は末尾のボット名/版数と+URL
• 版数は各社の更新で変わります。設定やフィルタをUA全文の完全一致で組むと壊れやすい（ボット名部分で緩く照合する）
• robots.txtに書くのはUA全文でなく、各社指定のトークン（多くはボット名）である
• UAが空、または見慣れない値のアクセスもあります。ボットが必ず素性を名乗るとは限らない
• 同じ運営元でも、ページ本体の取得とrobots.txtの確認でUAをわずかに変えることがある（末尾にrobots.txtの目印を足す等）

これらの注意点は、いずれも「UAは便利だが過信は禁物」という一点に集約されます。ログの一次的な仕分けや、robots.txtでのルールの宛先指定にはUAが不可欠ですが、アクセスを許すか遮断するかといった重い判断をUAだけに委ねると、詐称や表記ゆれに足をすくわれます。UAで見当をつけ、必要なら公式IPレンジで裏を取ります。この役割分担を守ることが、AI検索対策でUAを安全に活用するコツです。

robots.txtトークンとの関係

User-Agentを理解するうえで避けて通れないのが、robots.txtに書く「トークン（識別名）」との関係です。HTTPリクエストに現れるUA文字列は、Mozilla/5.0から始まる長い文字列ですが、robots.txtのUser-agent行に書くのは、その中の短い識別名（例：GPTBot）だけです。多くのボットではこの二つがほぼ一致するため混同されがちですが、概念としては別物です。前者は「ログに残る名乗り」、後者は「ルールを向ける宛先の名前」です。GoogleのGoogle-Extendedのように、HTTPのUA文字列を一切持たず、robots.txtの中でだけ使われるトークンも存在します。

この違いを押さえておくと、設定と観測がずれる典型的な混乱を避けられます。たとえばrobots.txtにGoogle-Extendedのルールを書いても、サーバーログのUA列にGoogle-Extendedという名前は現れません（実際の取得は通常のGoogleのUAで行われるため）。「robots.txtに書いた名前が必ずログに出るわけではない」という非対称を知らないと、設定が効いているのか確かめようがなくなります。UAは観測の語彙、トークンは制御の語彙、と役割で分けて捉えるのが、混乱を避ける最短路です。

UAだけに頼らない検証の作法

User-Agentが自己申告である以上、重要な判断はUAだけで下してはいけません。とくに「このアクセスは正規のAIボットだから通す」「これは怪しいから遮断する」といったアクセス制御を、UA名の一致だけで自動化すると、なりすましに付け入る隙を与えます。悪意ある側は、正規ボットのUAを名乗って防御をすり抜けたり、逆に無害を装って大量取得したりするからです。UAはあくまで「一次的な仕分けの手がかり」と位置づけ、確証が必要な場面では別の証拠を求める、という二段構えが安全です。

確証の取り方は、運営元が用意した仕組みに従うのが基本です。OpenAIやPerplexityは、自社ボットのアクセス元IPをまとめたJSON（gptbot.json、perplexitybot.json等）を公開しており、ログの接続元IPがそこに含まれるかで本物を判定できます。Googleは逆引きDNSと正引きの二段照合を案内しています。いずれも「名前ではなく、来た経路（IP）で確かめる」という発想です。UAは変わりやすく偽りやすい一方、正規ボットが使うIPレンジは運営元が管理・公開しているため、はるかに信頼できる証拠になります。UAで当たりをつけ、IPで裏を取る——これがなりすましに強い検証の型です。

実務での扱い方

1. サーバーログのUA列から、識別部（ボット名/版数、+URL）でAIボットを抽出する
2. 判別は完全一致でなく、ボット名（例：GPTBot）を含むかで緩く行い、版数変更に強くする
3. アクセス制御（許可/拒否）を厳密にしたい場面では、UA名だけで判断せず公式IPレンジと照合する
4. robots.txtでは各社指定のトークン名で User-agent 行を書く（UA全文を書かない）
5. 定期的に公式ドキュメントを見て、UA名・トークン・IPレンジ公開先の変更に追随する