「なぜスマホでWebサイトを見るとスマホ用の画面が表示されるの?」「ログにUser-Agentって書いてあったけど何のこと?」「ボットとブラウザってどうやって区別しているの?」——Webの世界でよく登場する概念のひとつが「ユーザーエージェント(User-Agent)」です。
ユーザーエージェント(User-Agent)とは、WebブラウザやアプリがWebサーバーにアクセスするとき、自分が「何者か」を伝えるための情報です。一般的には「どのOS・どのブラウザ・どのバージョンを使っているか」などの情報が文字列として含まれ、HTTPリクエストヘッダーの一部として送信されます。
Webサーバーはこの情報を参考にして、「スマートフォン向けのページを返す」「クローラーに対応する」「アクセスログを分析する」といった処理を行うことがあります。ただし、User-Agentは簡単に偽装できるため、セキュリティ判断ではUser-Agentだけに頼らないことが重要です。
ユーザーエージェントとは?
ユーザーエージェント(User-Agent)とは、ブラウザやアプリが「私はこういう種類のソフトウェアです」とWebサーバーに自己紹介するための情報です。HTTPリクエストヘッダーのひとつとして送信されます。

ユーザーエージェントが送られる仕組み
ブラウザのアドレスバーにURLを入力してEnterを押すと、裏側では次のような通信が行われています。
- ブラウザがWebサーバーにHTTPリクエストを送る
- そのリクエストのヘッダー部分にUser-Agent情報が含まれる
- WebサーバーがUser-Agent情報を読み取る
- サーバーがブラウザの種類や環境に応じたWebページを返す
近年のブラウザでは、プライバシー保護のため、User-Agent文字列に含まれるOSバージョン、端末名、ブラウザの細かいバージョンなどの情報を減らす動きがあります。詳細な情報が必要な場合は、User-Agent Client Hintsという仕組みで、必要な情報だけを取得する方式が使われることがあります。
ユーザーエージェント文字列の読み方
実際のユーザーエージェントは、複数の情報が並んだ長い文字列になっています。代表的な例を見てみましょう。
Google Chrome(Windows)の例
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36
一見複雑に見えますが、分解するとこのようになります。
| 部分 | 意味 |
|---|---|
| Mozilla/5.0 | 歴史的な互換性のための表記。現在でも多くのブラウザが含めています |
| Windows NT 10.0; Win64; x64 | Windows系の64ビット環境を示します。Windows 11でも互換性のためWindows NT 10.0と表示されることがあります |
| AppleWebKit/537.36 | WebKit系の互換性を示す表記です。現在のChromeはBlinkベースですが、互換性のためにこの表記が含まれます |
| Chrome/125.0.0.0 | Google Chromeのバージョン情報です。ただし、最近はプライバシー保護のため細かいバージョン情報が簡略化される場合があります |
| Safari/537.36 | 互換性のための表記です。ChromeがSafariそのものという意味ではありません |
主なブラウザ・環境別の例
| 環境 | User-Agentの例(抜粋) |
|---|---|
| Chrome(Windows) | Windows NT 10.0、Chrome/125.0.0.0 など |
| Safari(iPhone) | iPhone、CPU iPhone OS、Safari など |
| Firefox(Mac) | Macintosh、Mac OS X、Firefox など |
| Googlebot(検索クローラー) | Googlebot/2.1 など |
| curl(コマンドラインツール) | curl/8.4.0 など |
ユーザーエージェントはどんな用途に使われているか
スマホ・PC向けの画面切り替え
User-Agentは、スマートフォン・タブレット・PCなどの表示切り替えに使われることがあります。サーバーがUser-Agentを見て「iPhoneからのアクセスだからスマホ用ページを返す」「PCブラウザだからデスクトップ用ページを返す」と判断する仕組みです。
ただし、最近はCSSのレスポンシブデザインが主流になっており、User-Agentではなく画面サイズやCSSのメディアクエリで表示を切り替えるケースが増えています。そのため、User-Agentによる画面切り替えは、古いサイトや一部のシステムで使われる方法と考えるとよいでしょう。
クローラーの識別
GoogleやBingなどの検索エンジンは、クローラーと呼ばれるプログラムを使ってWebページを自動的に巡回しています。これらのクローラーは、User-Agentに「Googlebot」「bingbot」などの名前を含めてアクセスすることがあります。
Webサイトの管理者は、この情報を参考にして、検索エンジンのクローラーからのアクセスかどうかを判断します。ただし、User-Agentは簡単に偽装できるため、本物のクローラーかどうかをUser-Agentだけで判断するのは危険です。
アクセスログの分析
Webサーバーのアクセスログには、User-Agentが記録されることがあります。これにより、「どのブラウザのユーザーが多いか」「スマートフォンとPCのどちらからのアクセスが多いか」「クローラーからのアクセスがどれくらいあるか」などを分析できます。
アクセスログの調査では、User-Agentだけでなく、IPアドレス、アクセス頻度、アクセス先URL、レスポンスコード、リファラーなども合わせて確認することが重要です。
ブラウザ別の表示の最適化
ブラウザによってCSSやJavaScriptの動作が異なる場合、User-Agentを参考にして「このブラウザには別のコードを返す」といった対応を行うことがあります。特に古いブラウザへの対応で使われてきました。
ただし、現在はブラウザの機能そのものを判定する「機能検出」の方が推奨されることが多く、User-Agentだけで分岐する方法は誤判定のリスクがあります。
クローラーとユーザーエージェント:検索エンジンとの関係
検索エンジンのクローラーは、User-Agentを使って自分がロボットであることを示すことがあります。
主な検索エンジンのクローラーとUser-Agent
| 検索エンジン | クローラー名 | User-Agentの例 |
|---|---|---|
| Googlebot | Googlebot/2.1 など | |
| Bing(Microsoft) | bingbot | Mozilla/5.0 … bingbot/2.0 … など |
Webサイトのルートディレクトリに置く「robots.txt」というファイルでは、「どのクローラーに、どのページをクロールしてほしくないか」を指定できます。たとえば「User-agent: Googlebot」に続けて「Disallow: /admin/」と書くと、Googlebotに対して「/admin/ 以下をクロールしないでほしい」と伝える形になります。ただし、robots.txtは善意のクローラーに向けたルールであり、アクセス制御やセキュリティ対策ではありません。悪意あるボットはrobots.txtを無視できます。管理画面や機密情報を守るには、認証、IP制限、WAFなど別の対策が必要です。
セキュリティとユーザーエージェントの関係

不正アクセスの検知・ブロック
Webサーバーへの不正アクセスを試みるツールやスクリプトには、特徴的なUser-Agent文字列を使うものがあります。WAF(Webアプリケーションファイアウォール)やログ監視では、既知の不審なUser-Agentを検知・ブロックの参考にすることがあります。
ただし、User-Agentは簡単に変更できるため、User-Agentだけで不正アクセスを判断するのは危険です。IPアドレス、アクセス頻度、リクエスト内容、ログイン試行回数、ふるまいなどを組み合わせて判断する必要があります。
ユーザーエージェントの偽装(なりすまし)
ユーザーエージェントは簡単に書き換えることができます。本来はChromeからのアクセスであっても、User-Agent文字列だけを「Googlebot」や別のブラウザに見せかけることが可能です。これをユーザーエージェントの偽装、またはスプーフィングと呼びます。
偽装が使われる主な場面
- スクレイピング対策の回避:人間のブラウザのUser-Agentを名乗って、自動収集プログラムであることを隠す
- ボット攻撃:攻撃ツールが正規ブラウザに見せかけてWebサイトへの攻撃を試みる
- Googlebotなりすまし:Googlebotを装って、クローラー向けの扱いを受けようとする
- 不正なコンテンツ配信:特定のUser-Agentのときだけ悪意あるコンテンツを表示する
User-Agentだけに頼らないセキュリティ
User-Agentは簡単に書き換えられるため、セキュリティ対策の主役にはなれません。「このUser-Agentだから安全」「このUser-Agentだから危険」という判断だけに頼ることは危険です。
特にGooglebotなどのクローラーを名乗るアクセスについては、User-Agentだけで本物と判断せず、アクセス元IPアドレスやDNS情報なども確認する必要があります。また、不正ボット対策では、アクセス頻度、リクエストパターン、Cookieの有無、JavaScript実行の有無、ログイン後の行動パターンなど、複数の情報を組み合わせた総合的な判断が重要です。
自分のユーザーエージェントを確認する方法
今使っているブラウザのUser-Agentを確認したい場合は、以下の方法で確認できます。
- ブラウザの開発者ツール:ChromeやFirefoxで開発者ツールを開き、コンソールで「navigator.userAgent」と入力すると確認できます。ただし、近年はUser-Agentの情報が簡略化されている場合があります
- 確認サイトを使う:「User-Agent 確認」などで検索すると、アクセスするだけでUser-Agentを表示してくれるサイトがあります
- アクセスログを見る:Webサーバーを管理している場合は、ApacheやNginxのアクセスログからUser-Agentを確認できます
ユーザーエージェントに関連する注意事例2選
事例1:Googlebotになりすましたスクレイピングによる負荷リスク
Webサイトでは、Googlebotなどの検索エンジンクローラーを名乗る大量アクセスが発生することがあります。しかし、User-Agentに「Googlebot」と書かれていても、本物のGooglebotとは限りません。不正な自動プログラムがGooglebotになりすまし、商品情報、価格情報、記事データなどを大量に収集しようとするケースがあります。
このようなアクセスが大量に発生すると、サーバー負荷が上がり、ページ表示が遅くなったり、正規ユーザーの利用に影響が出たりする可能性があります。また、クローラー向けの制限を緩くしている場合、なりすましボットに悪用されるおそれもあります。
対策としては、User-AgentだけでGooglebotと判断せず、アクセス元IPアドレスやDNS情報を確認することが重要です。また、WAF、レート制限、ボット対策サービス、ログ監視などを組み合わせて、異常なアクセスを検知・制御する必要があります。
事例2:特定のUser-Agentだけに表示を変える不正サイトのリスク
不正サイトやマルウェア配布サイトの中には、アクセスしてきたブラウザや端末のUser-Agentを見て、表示する内容を変えるものがあります。たとえば、スマートフォンからアクセスした場合だけフィッシングページを表示し、PCブラウザやセキュリティ企業の調査用クローラーには無害なページを見せる、といった手口です。
このような手口は、セキュリティ検査や自動クローラーによる検知をすり抜ける目的で使われることがあります。User-Agentによって表示内容が変わるため、1つの環境で確認しただけでは不正サイトの実態を見逃す可能性があります。
対策としては、複数の端末・ブラウザ・User-Agentで挙動を確認すること、URL検査、サンドボックス解析、脅威インテリジェンス、アクセス先のレピュテーション確認などを組み合わせることが重要です。
よくある質問(FAQ)
Q. ユーザーエージェントはプライバシーに影響しますか?
影響する場合があります。ユーザーエージェントには、OS、ブラウザ、バージョンなどの情報が含まれることがあり、これらを組み合わせると「ブラウザのフィンガープリント」と呼ばれる識別情報の一部になる場合があります。
完全に個人を特定する情報とは限りませんが、他の情報と組み合わせることで、サイトをまたいだトラッキングに使われる可能性があります。そのため、近年のブラウザではUser-Agentの情報を簡略化する動きが進んでいます。
Q. User-Agentを自分で変更できますか?
技術的には可能です。Chromeなどのブラウザでは、開発者ツールの設定やブラウザ拡張機能を使ってUser-Agentを変更できます。また、curlなどのコマンドラインツールでも任意のUser-Agentを指定できます。
ただし、User-Agentの変更はサービスの利用規約に抵触する場合があります。特に、アクセス制限の回避、スクレイピング対策の回避、クローラーのなりすましなどを目的とした変更は問題になる可能性があるため、注意が必要です。
Q. 「Mozilla/5.0」がどのブラウザにも入っているのはなぜ?
歴史的な互換性のためです。インターネット黎明期に、Webサーバー側で「Mozillaと書いてあるブラウザには高機能なコンテンツを返す」という処理が広まりました。その後、他のブラウザも互換性のために「Mozilla/5.0」をUser-Agentの先頭に含めるようになり、現在でも慣習として残っています。
実際のブラウザ名は、Chrome、Safari、Firefox、Edgeなどの部分で判断します。ただし、User-Agentは偽装できるため、正確な判定が必要な場合は注意が必要です。
Q. サーバーのアクセスログでUser-Agentを確認するには?
ApacheやNginxなどのWebサーバーでは、アクセスログにUser-Agentが記録される設定になっていることがあります。ログの形式はサーバー設定によって異なりますが、多くの場合、ログの後半にUser-Agent文字列が含まれます。
不審なアクセスの調査では、User-Agentだけでなく、IPアドレス、アクセス時刻、アクセス頻度、リクエストURL、レスポンスコード、リファラーなども合わせて確認することが重要です。
Q. スマホとPCで同じサイトにアクセスしても画面が違うのはなぜ?
理由はサイトによって異なります。古いサイトや一部のシステムでは、User-Agentを見てスマートフォン用ページとPC用ページを振り分けている場合があります。
一方、最近のWebサイトの多くはレスポンシブデザインを採用しており、User-Agentではなく画面サイズやCSSのメディアクエリによって表示を切り替えています。「m.example.com」のようなスマホ専用URLがあるサイトでは、User-Agentによる振り分けが使われている場合もあります。
まとめ
ユーザーエージェント(User-Agent)とは、ブラウザやアプリがWebサーバーへのアクセス時に送る「自己紹介情報」です。OS、ブラウザ名、バージョンなどが文字列として含まれ、HTTPリクエストヘッダーの一部として送信されます。
Webサーバーはこの情報を参考にして、スマートフォン向けページの表示、クローラー対応、アクセスログ分析、ブラウザ別の表示最適化などを行うことがあります。ただし、現在はレスポンシブデザインやUser-Agent Client Hintsの利用が広がっており、User-Agentだけに依存しない設計が重要になっています。
セキュリティの面では、User-Agentは簡単に書き換えられるため、偽装(スプーフィング)が可能です。正規ブラウザに見せかけたボット攻撃、Googlebotになりすましたスクレイピング、特定のUser-Agentだけに悪意あるコンテンツを表示する手口などに注意が必要です。
User-Agentは便利な情報ですが、信頼できる本人確認情報ではありません。セキュリティ対策では、User-Agentだけに頼らず、IPアドレス、DNS情報、アクセス頻度、リクエスト内容、行動パターンなど複数の情報を組み合わせて判断することが重要です。























![中小企業の情報瀬キィリティ相談窓口[30分無料]](/wp-content/uploads/2023/07/bnr_footer04.png)



ユーザーエージェントは「来客カードへの記入」のようなものです。会社に訪問する際に「お名前・会社名・ご用件」を来客カードに書くように、ブラウザもWebサーバーへアクセスするときに「Chromeを使っています」「Windows系の環境です」「スマートフォンからのアクセスです」といった情報を送ります。受付(Webサーバー)はその情報を参考にして、どのような案内(レスポンス)を返すかを判断します。