ユーザーエージェントを設定する方法

Scrapeless Agent Browser は、構成可能なブラウザフィンガープリントを備えた、Web 自動化向けのクラウドブラウザを提供します。

ブラウザ環境で HTTP クライアントの User-Agent リクエストヘッダー、またはサポートされているブラウザのアイデンティティ設定を構成して、ユーザーエージェントを設定します。その後、サーバーが受信した値を検証します。コード内で確認できる設定値だけでは、意図したヘッダーが送信先に到達したという十分な証拠にはなりません。

User-Agent フィールドは、リクエストを行っているソフトウェアを表します。これはサービスがクライアントを識別したり、表現形式を選択したりするのに役立ちますが、クライアントを認証するものではなく、ブラウザ全体を再現するものでもありません。そのため有用な設定とは、意図的に指定された値と、その変更が何に影響しうるかについての明確な理解の両方を含むものです。

ユーザーエージェント文字列とは何を意味するのか？

User-Agent 文字列は、HTTP リクエストフィールドに含まれるクライアントソフトウェアの自己申告による説明です。 HTTP User-Agent フィールドの定義 製品識別子と任意のコメントについて説明します。サーバーは、この値を互換性の処理、分析、または診断のために使用する場合があります。

ブラウザーの文字列には、歴史的な互換性のためのトークンが含まれていることがよくあります。文字列の中に見覚えのある製品名が含まれていても、それによって対応するエンジンが実行されていることが証明されるわけではありません。クライアントは別の文字列を選択することができ、複数のブラウザーが同じ構文の一部を共有している場合もあります。

The User-Agent ヘッダーモデル また、ブラウザーによる詳細な識別情報を減らす取り組みも反映しています。あらゆる細かなオペレーティングシステムやブラウザーのバージョンが、将来にわたって同じ形式で公開され続けることに依存するようなコレクターを設計するのは避けてください。

内部チェッカーで識別しやすくするためには、長いブラウザーのユーザーエージェント文字列をそのままコピーするよりも、簡潔なアプリケーション名とバージョン番号を用いる方が有用な場合があります。許可されているタスクに適合する識別情報を使用してください。その識別情報を使って、その身元に紐づくアクセス権を得る目的で、検索エンジンのクローラーや他組織のアプリケーションであると偽ってはなりません。

例を実行する前に

以下の例では、curl もしくは Requests パッケージを使用した Python、およびパブリックな HTTP ヘッダーエコーエンドポイントへのネットワークアクセスが必要です。これらは単一の GET リクエストを送信し、そのエンドポイントで観測された値を出力します。Scrapeless アカウント、プロキシ、ブラウザーセッションは不要です。

CatalogAudit/1.0 は、このデモンストレーションのために選ばれた例示的なアプリケーション ID です。ご自身のアプリケーションに適した ID に置き換えてください。想定される値は、任意のブラウザーのバージョンについての主張ではなく、あなたが意図的に送信する値です。

エコーサービスは診断用の送信先です。認証ヘッダー、クッキー、またはプライベートなURLを送信しないでください。例では、教えている動作にチェックの焦点を当てるために、デモ用のユーザーエージェントヘッダーだけを送信します。

curl で User Agent を設定する

curl は、--user-agent オプション（-A としても利用可能）を通じて User-Agent フィールドを設定します。 curl コマンドラインオプション その設定をプロキシ構成やその他のリクエストヘッダーとは別に定義します。

echo エンドポイントによって受信された値を検査するために、この単一のリクエストを実行してください。

curl --silent --show-error --fail --max-time 20 \
  --user-agent 'CatalogAudit/1.0' \
  'https://httpbin.org/user-agent'

レスポンスには、curl によって送信された値を持つ user-agent フィールドが含まれます。明示的な時間制限はコマンドの転送時間の有効期限を定める一方で、--fail は HTTP エラー応答をコマンド失敗として可視化します。これは小さなヘッダー確認であり、完全なコレクション・パイプラインのテストではありません。

長いアイデンティティを使用する場合、スペースや句読点が 1 つのシェル引数として保持されるように、文字列を引用してください。文字列内に認証情報を含めないでください。ユーザーエージェントは記述的なリクエストメタデータであり、サーバーログに記録されることがあります。

Python Requests でユーザーエージェントを設定する

Python Requests は、headers 引数を通じてカスタムヘッダーを受け付けます。リクエストでそのフィールドを明示的に設定し、同じ設定をより大きなワークフローに適用する前に、受信側エンドポイントのレスポンスを確認してください。

この完全な例では、1 回のリクエストを行い、エコーされた値が設定された値と一致することを検証します。

import requests

user_agent = "CatalogAudit/1.0"
response = requests.get(
    "https://httpbin.org/user-agent",
    headers={"User-Agent": user_agent},
    timeout=20,
)
response.raise_for_status()
received = response.json()["user-agent"]
assert received == user_agent
print(received)

リクエストのタイムアウトは、クライアントのタイムアウト動作に従ってネットワーク待機を制限するものであり、あらゆる周辺のビジネス処理がその期間内に完了するという主張ではありません。アサーションは、この例が教える特定の動作、すなわちエンドポイントが選択されたヘッダー値を受信したことを確認します。

関連するリクエストに対しては、Requests セッションを使用して共通のヘッダーやクッキーを保持できます。ヘッダーがセッション全体に属するものか、単一のリクエストにのみ属するものかを判断してください。リクエスト単位での上書きは制御された比較には有用ですが、セッション内での誤った変更は結果の解釈を損なう可能性があります。

実際の送信リクエストを検証する

検証では、設定された値をサーバー側での観測値、または送信されるリクエストの信頼できるキャプチャと比較する必要があります。スクリプト内の変数だけを確認しても、その後の上書きや、別のリクエストを構築するラッパー、ヘッダーを変更する仲介処理などは検出できません。

ブラウザでは、ネットワークパネルで個々のリクエストのリクエストヘッダーを表示できます。調査対象となっている実際のドキュメントまたは API リクエストを選択してください。ページのロードには複数の個別リクエストが含まれることがあります。あるリソースで表示された値は、そのページ内のすべてのリクエストで使われたことを示すものではありません。

リダイレクトを念頭に置いてください。元の URL は別の宛先へと進む場合があり、クライアント設定はそのチェーン全体で異なる形で適用されることがあります。最終的な URL を記録し、評価対象のコンテンツを生成したリクエストを確認してください。最初のリクエストのヘッダーが正しいからといって、最終的な表現が意図したテストと一致しているとは限りません。

エコー結果が設定値と異なる場合は、経路を絞り込みます。クライアントの設定と、環境によって提供されるプロキシ設定を確認してください。アプリケーションがラップしたリクエストと単純なリクエストを比較します。観察結果から原因を特定できるよう、1 回に 1 つの要因だけを変更してください。

User-Agent を変えてもデバイスをエミュレートできない理由

User-Agent を変更すると宣言上の識別子は変わりますが、デバイスエミュレーションにはビューポート、入力能力、ブラウザ API、レンダリング動作などが関わります。モバイル風の文字列を送るデスクトップのネットワーキングライブラリは、それでもモバイルブラウザの実行環境を獲得するわけではありません。

User-Agent 検出の 制約 により、機能検出のほうが一般的に Web アプリケーションの挙動を判断するうえで信頼性が高い理由が説明できます。サイトはヘッダー内の製品トークンを信頼するのではなく、実際の能力を検査できます。

モバイルレイアウトのテストでは、宣言上の識別子だけでなく、必要なビューポートとインタラクション条件を定義してください。コンテンツネゴシエーションのテストでは、ヘッダーと返される表現に注目します。これらは別個のテストであり、「実際の電話から来たリクエスト」であるという 1 つの主張にまとめるべきではありません。

TLS の挙動も別物のままです。Python の HTTP クライアントは、ブラウザ名を宣言したとしても、そのブラウザのトランスポート実装を採用するわけではありません。互換性がネットワーキングスタックやページ実行に依存している場合は、関係のないヘッダー文字列を順番に試すのではなく、そのレイヤー自体を直接調べてください。

クライアントヒントが識別チェックに与える影響

User-Agent Client Hints は、その仕組みをサポートするブラウザにおいて、追加の構造化された識別情報を提供します。サイトはこれらのヒントを User-Agent 文字列と合わせて使用する場合があります。1 つのフィールドだけを変更すると、全体として宣言される環境が不整合のままになることがあります。

ブラウザツールや自動化フレームワークは、その識別子コントロールによって更新される値がそれぞれ異なります。実際のブラウザ向けに文書化された設定インターフェイスを使い、必要に応じてネットワークとページから見えるプロパティの両方を確認してください。ヘッダーだけの上書きで、すべての JavaScript プロパティも更新されると決めつけないでください。

テストの範囲を明示的に保ってください。要件が HTTP ヘッダーの検証だけであれば、エコーの例で十分です。要件がブラウザの識別設定の検証であれば、ブラウザ環境と宛先側の挙動を、別々の証拠として確認してください。

ブラウザレベルの作業に Agent Browser を使う

Scrapeless Agent Browser は、HTTP 転送だけでなくクラウドブラウザを必要とするタスクに関連します。その カスタムフィンガープリント設定 には、User-Agent とその他サポートされている識別設定が含まれており、その制限が文書化されています。

これらの設定は、あらゆるデバイス特性を無制限に制御できることを意味しません。文書化された機能は、クラウドセッションを任意の物理ハードウェアに変えるものではありません。サポートされている設定を、互換性や収集のタスクに合わせ、当該タスクにとって重要なプロパティを確認してください。

関連する Python Requests user-agent walkthrough は、この区別の HTTP クライアント側を扱っています。ブラウザベースの作業を評価する際には、単純なローカルヘッダーの確認とは運用モデルが異なるため、 Scrapeless pricing を使用してください。

本記事の例は、ローカルの curl と Requests のヘッダー設定を検証しています。これらは認証された Agent Browser セッションを実演するものではなく、特定のターゲットサイトがカスタマイズしたブラウザ識別にどのように応答するかを証明するものでもありません。

セッションの識別を安定させ、結果を解釈しやすくする

1 つのセッションに属するリクエスト列には、安定した識別設定があるほうが解釈しやすくなります。関連する操作の間で User-Agent をランダムに変えると、テストで意図したユーザージャーニーを表していないのに、サーバ側のコンテンツ選択が変わってしまうことがあります。

仮の互換性比較を行う場合には、意図する 2 つのクライアントプロファイルごとに別々のセッションを定義してください。要求するリソースとその他の条件を一定に保ったうえで、実際の表現を比較します。ヘッダーを変えたことで必ずレスポンスが変わると決めつけるのではなく、レイアウトや項目の違いを記録してください。

サーバがアクセス制限を返した場合は、その境界を尊重してください。User-Agent の設定は互換性と識別の制御であり、認可メカニズムではありません。そのタスクには、サービス側でサポートされているアクセス経路を使用してください。

結論

User-Agent はサポートされたクライアントオプションを通じて設定し、受信側で検証してください。ヘッダーの役割を TLS の挙動、ブラウザレンダリング、デバイス能力とは切り分けておきましょう。ブラウザレベルのタスクでは、文書化されたブラウザ設定を使用し、その結果として得られる環境を直接テストしてください。