Selenium Manager (ベータ版)

動機

要約: Selenium Manager は Selenium プロジェクトの公式ドライバマネージャであり、すべての Selenium リリースに標準搭載されています。

Selenium は、自動化プロセスを実行するために、各ブラウザによって実装されたネイティブサポートを使用します。このため、Selenium ユーザーは、Selenium API を使用するスクリプトとブラウザの間に、ドライバ（chromedriver、geckodriver、msedgedriverなど）と呼ばれるコンポーネントを配置する必要があります。長年にわたり、これらのドライバの管理は Selenium ユーザーにとって手動のプロセスでした。この方法では、ブラウザに必要なドライバ（Chrome 用の chromedriver、Firefox 用の geckodriver など）をダウンロードし、PATH に配置するか、ドライバパスをシステムプロパティ（Java、JavaScript など）としてエクスポートする必要がありました。しかし、このプロセスは煩雑で、保守性の問題につながりました。

例を考えてみましょう。Selenium で Chrome を駆動するために必要な chromedriver を手動でダウンロードしたと想像してください。このプロセスを実行したとき、Chrome の安定バージョンは 113 だったため、chromedriver 113 をダウンロードして PATH に配置しました。その時点では、Selenium スクリプトは正しく実行されました。しかし、問題は Chrome が「エバーグリーン」であることです。この名前は、Chrome が利用可能な場合、次の安定バージョンに自動的かつサイレントにアップグレードする機能を指します。この機能はエンドユーザーにとっては優れていますが、ブラウザの自動化にとっては潜在的に危険です。例に戻って調べてみましょう。ローカルの Chrome は最終的にバージョン 115 にアップデートされます。その瞬間、手動でダウンロードしたドライバ（113）と Chrome バージョン（115）の互換性がないため、Selenium スクリプトは壊れます。したがって、Selenium スクリプトは次のエラーメッセージで失敗します。「session not created: This version of ChromeDriver only supports Chrome version 113」。

この問題は、いわゆるドライバマネージャ（Java 用の WebDriverManager、Python 用の webdriver-manager、JavaScript 用の webdriver-manager、C# 用の WebDriverManager.Net、Ruby 用の webdrivers など）が存在する主な理由です。これらのプロジェクトはすべて、Selenium にこの機能を組み込む必要性がコミュニティにあることを示すインスピレーションと明確な兆候でした。したがって、Selenium プロジェクトは、バージョン 4.6 以降、各 Selenium リリースに標準搭載される Selenium の公式ドライバマネージャである Selenium Manager を作成しました。

使用方法

要約: Selenium Manager は、ドライバ（chromedriver、geckodriverなど）が利用できない場合に Selenium バインディングによって使用されます。

Selenium Manager を介したドライバ管理は、Selenium バインディングではオプトインです。したがって、ユーザーはドライバを手動で管理し続ける（ドライバを PATH に配置するか、システムプロパティを使用する）か、サードパーティのドライバマネージャに自動的に実行させることを選択できます。Selenium Manager はフォールバックとしてのみ動作します。ドライバが提供されていない場合、Selenium Manager が救済策として機能します。

Selenium Manager は、クロスプラットフォーム実行を可能にするために Rust で実装され、Windows、Linux、macOS 用にコンパイルされた CLI（コマンドラインインターフェース）ツールです。Selenium Manager バイナリは、各 Selenium リリースに同梱されています。これにより、各 Selenium バインディング言語は Selenium Manager を呼び出して、以下のセクションで説明するドライバとブラウザの自動管理を実行します。

ドライバの自動管理

要約: Selenium Manager は、Selenium が必要とするドライバが利用できない場合、自動的に検出、ダウンロード、およびキャッシュします。

Selenium Manager の主要な機能は、自動ドライバ管理と呼ばれます。理解するために例を考えてみましょう。Selenium で Chrome を駆動したいとします（Selenium での セッションの開始方法に関するドキュメントを参照してください）。セッションが開始される前、およびドライバが利用できない場合、Selenium Manager が chromedriver を管理します。この機能には「管理」という用語を使用します（単に「ダウンロード」だけでなく）。これは、このプロセスがより広範囲であり、さまざまなステップが含まれるためです。

1. ブラウザバージョンの検出。Selenium Manager は、Selenium を実行するマシンにインストールされているブラウザバージョン（例：Chrome、Firefox、Edge）を検出します。このステップでは、シェルコマンド（例：google-chrome --version）を使用します。
2. ドライババージョンの検出。検出されたブラウザバージョンを使用して、適切なドライババージョンが解決されます。このステップでは、ブラウザベンダーによって維持されているオンラインメタデータ/エンドポイント（例：chromedriver、geckodriver、または msedgedriver）が使用されます。
3. ドライバのダウンロード。ドライバの URL は、解決されたドライババージョンで取得されます。その URL を使用して、ドライバアーティファクトがダウンロード、解凍、およびローカルに保存されます。
4. ドライバキャッシュ。解凍されたドライババイナリは、ローカルキャッシュフォルダ（~/.cache/selenium）に保存されます。次回同じドライバが必要な場合、ドライバがすでにキャッシュにある場合は、そこから使用されます。

ブラウザの自動管理

要約: Selenium Manager は、これらのブラウザがローカルシステムにインストールされていない場合、Selenium で駆動されるブラウザ（Chrome、Firefox、Edge）を自動的に検出、ダウンロード、およびキャッシュします。

Selenium 4.11.0 以降、Selenium Manager はブラウザの自動管理も実装しています。この機能により、Selenium Manager はさまざまなブラウザリリースを検出、ダウンロード、およびキャッシュし、Selenium でシームレスに利用できるようにします。内部的には、Selenium Manager は前のセクションで説明した同等の管理手順を使用しますが、今回はブラウザリリース用です。

Selenium Manager によって自動的に管理されるブラウザは次のとおりです。

• Chrome。Selenium 4.11.0 以降、Chrome for Testing (CfT) に基づいています。
• Firefox。Selenium 4.12.0 以降、公開されている Firefox リリースに基づいています。
• Edge。Selenium 4.14.0 以降、Edge ダウンロードに基づいています。

Selenium で Chrome を駆動する典型的な例をもう一度考えてみましょう。そして今回、新しいセッションを開始するときに Chrome がローカルマシンにインストールされていないと仮定します。その場合、現在の安定版 CfT リリースが Selenium Manager によって検出、ダウンロード、およびキャッシュされます（~/.cache/selenium/chrome 内）。

しかし、それだけではありません。安定版ブラウザバージョンに加えて、Selenium Manager では、古いブラウザバージョン（CfT の場合、CfT として最初に公開されたバージョンであるバージョン 113 以降）のダウンロードも可能です。Selenium でブラウザバージョンを設定するには、browserVersion というブラウザオプションを使用します。

別の簡単な例を考えてみましょう。Chrome オプションを使用して browserVersion を 114 に設定すると仮定します。この場合、Selenium Manager は Chrome 114 がすでにインストールされているかどうかを確認します。インストールされている場合は、それが使用されます。インストールされていない場合は、Selenium Manager が CfT 114 を管理（つまり、検出、ダウンロード、およびキャッシュ）します。どちらの場合でも、chromedriver も管理されます。最後に、Selenium は通常どおり、プログラムで駆動される Chrome を起動します。

しかし、さらにあります。固定ブラウザバージョン（例：113、114、115など）に加えて、browserVersion に次のラベルを使用できます。

• stable: 現在の CfT バージョン。
• beta: 安定版の次のバージョン。
• dev: 現時点で開発中のバージョン。
• canary: 開発者向けのナイトリービルド。
• esr: 延長サポートリリース（Firefox のみ）。

これらのラベルが指定されると、Selenium Manager は最初に、指定されたブラウザ（beta、dev など）がすでにインストールされているかどうかを確認し、検出されない場合は、ブラウザが自動的に管理されます。

Windows での Edge

Windows での Selenium Manager による Edge の自動管理は、他のブラウザとは異なります。Chrome と Firefox（および macOS および Linux の Edge）は、Selenium Manager によってローカルキャッシュ（~/.cache/selenium）に自動的にダウンロードされます。ただし、Windows の Edge では同じことはできません。その理由は、Windows 用 Edge インストーラーが、管理者権限で実行するように設計された Microsoft インストーラー（MSI）ファイルとして配布されているためです。このため、Windows で管理者以外のセッションで Selenium Manager を使用して Edge をインストールしようとすると、Selenium Manager によって次の警告メッセージが表示されます。

edge can only be installed in Windows with administrator permissions

したがって、Selenium Manager を介して Windows に Edge を自動的にインストールするには管理者権限が必要であり、Edge は最終的に通常のプログラムファイルフォルダ（例：C:\Program Files (x86)\Microsoft\Edge）にインストールされます。

データ収集

Selenium Manager は、匿名化された使用状況 統計情報 を Plausible にレポートします。これにより、Selenium チームは Selenium がどのように使用されているかをより深く理解し、開発努力をより適切に集中できるようになります。収集されるデータは次のとおりです。

Selenium Manager は、これらのデータを 1 日に 1 回 Plausible に送信します。この期間は、TTL 値（設定を参照）に基づいています。

データ収集のオプトアウト

データ収集はデフォルトでオンになっています。 無効にするには、SE_AVOID_STATS 環境変数を true に設定します。設定ファイル（下記参照）で avoid-stats = true を設定してデータ収集を無効にすることもできます。

設定

要約: Selenium Manager は、ほとんどのユーザーにとってサイレントかつ透過的に動作するはずです。ただし、（カスタムキャッシュパスの指定やプロキシのグローバルなセットアップなど）カスタム設定が必要になるシナリオもあります。

Selenium Manager は CLI ツールです。したがって、内部的には、Selenium バインディングはシェルコマンドを呼び出すことによって Selenium Manager を呼び出します。他の CLI ツールと同様に、引数を使用して Selenium Manager の特定の機能を指定できます。Selenium Manager でサポートされているさまざまな引数は、次のコマンドを実行することで確認できます。

$ ./selenium-manager --help

CLI 引数に加えて、Selenium Manager では設定のための 2 つの追加メカニズムが許可されています。

• 設定ファイル。Selenium Manager は、カスタム設定値のために、Selenium キャッシュ（デフォルトでは ~/.cache/selenium）にある se-config.toml というファイルを使用します。この TOML ファイルには、カスタム設定に使用されるキーと値のコレクションが含まれています。
• 環境変数。各設定キーには、各キー名を大文字に変換し、ダッシュ記号（-）をアンダースコア（_）に置き換え、プレフィックス SE_ を追加することにより、環境変数と同等のものが存在します。

設定ファイルは、存在する場合、および対応する CLI パラメータが指定されていない場合に、Selenium Manager によって優先されます。さらに、環境変数は、以前のオプション（CLI 引数と設定ファイル）のいずれも指定されていない場合に使用されます。言い換えれば、Selenium Manager のカスタム設定の優先順位は次のとおりです。

1. CLI 引数。
2. 設定ファイル。
3. 環境変数。

Selenium バインディングは CLI 引数を使用して設定値を指定することに注意してください。これらの設定値は、各バインディングで ブラウザオプション を使用して定義されます。

次の表は、Selenium Manager でサポートされているすべての引数と、設定ファイルおよび環境変数での対応するキーをまとめたものです。

前の表で指定された設定キーに加えて、いくつかの特別なケースがあります。

• ブラウザバージョン。browser-version に加えて、特定の構成キーを使用して、サポートされているブラウザごとにカスタムバージョンを指定できます。このように、chrome-version、firefox-version、edge-version などのキーがサポートされています。環境変数（つまり、SE_CHROME_VERSION、SE_FIREFOX_VERSION、SE_EDGE_VERSION など）にも同じことが当てはまります。
• ドライババージョン。同じパターンに従って、chromedriver-version、geckodriver-version、msedgedriver-version など（設定ファイル内）、および SE_CHROMEDRIVER_VERSION、SE_GECKODRIVER_VERSION、SE_MSEDGEDRIVER_VERSION など（環境変数として）を使用できます。
• ブラウザパス。同じパターンに従って、chrome-path、firefox-path、edge-path など（設定ファイル内）、および SE_CHROME_PATH、SE_FIREFOX_PATH、SE_EDGE_PATH など（環境変数として）を使用できます。Selenium バインディングでは、オプションを使用してブラウザパスのカスタムロケーションを指定することもできます。 Chrome)、Edge、または Firefox。
• ドライバミラー。同じパターンに従って、chromedriver-mirror-url、geckodriver-mirror-url、msedgedriver-mirror-url など（設定ファイル内）、および SE_CHROMEDRIVER_MIRROR_URL、SE_GECKODRIVER_MIRROR_URL、SE_MSEDGEDRIVER_MIRROR_URL など（環境変数として）を使用できます。
• ブラウザミラー。同じパターンに従って、chrome-mirror-url、firefox-mirror-url、edge-mirror-url など（設定ファイル内）、および SE_CHROME_MIRROR_URL、SE_FIREFOX_MIRROR_URL、SE_EDGE_MIRROR_URL など（環境変数として）を使用できます。

se-config.toml の例

• se-config.toml

browser = "chrome"                 # --browser BROWSER
driver = "chromedriver"             # --driver DRIVER
browser-version = "106"             # --browser-version BROWSER_VERSION
driver-version = "106.0.5249.61"    # --driver-version DRIVER_VERSION
browser-path = "/usr/bin/google-chrome"  # --browser-path BROWSER_PATH
driver-mirror-url = "https://custom-driver-mirror.com"  # --driver-mirror-url DRIVER_MIRROR_URL
browser-mirror-url = "https://custom-browser-mirror.com"  # --browser-mirror-url BROWSER_MIRROR_URL
output = "LOGGER"                   # --output OUTPUT
os = "linux"                        # --os OS
arch = "x64"                        # --arch ARCH
proxy = "myproxy:8080"              # --proxy PROXY
timeout = 300                       # --timeout TIMEOUT
offline = true                      # --offline
force-browser-download = true       # --force-browser-download
avoid-browser-download = false      # --avoid-browser-download
debug = true                        # --debug
trace = true                        # --trace
cache-path = "/custom/cache/path"    # --cache-path CACHE_PATH
ttl = 3600                          # --ttl TTL
language-binding = "Python"         # --language-binding LANGUAGE
avoid-stats = true                  # --avoid-stats

キャッシュ

要約: Selenium Manager によって管理されるドライバとブラウザは、ローカルフォルダ（~/.cache/selenium）に保存されます。

Selenium Manager のキャッシュは、ダウンロードされたアセット（ドライバとブラウザ）が保存されるローカルフォルダ（デフォルトでは ~/.cache/selenium）です。パフォーマンスを向上させるために、ドライバまたはブラウザがすでにキャッシュにある場合（つまり、キャッシュヒントがある場合）、Selenium Manager はそこから使用します。

ダウンロードされたドライバとブラウザに加えて、キャッシュのルートにはさらに 2 つのファイルが存在します。

• 設定ファイル (se-config.toml)。このファイルはオプションであり、前のセクションで説明したように、Selenium Manager のカスタム設定値を保存できます。このファイルはエンドユーザーによって管理され、Selenium Manager によって読み取られます。
• メタデータファイル (se-metadata.json)。このファイルには、Selenium Manager がネットワークリクエスト（例：CfT JSON エンドポイント の使用）を行って検出したバージョンと、それらが有効であるタイムトゥリブ（TTL）が含まれています。Selenium Manager はこのファイルを自動的に管理します。

Selenium Manager の TTL は、DNS の TTL に触発されたもので、これは、自動的にリフレッシュされる前に、一部の値がどのくらいの期間キャッシュされるかを示す既知のメカニズムです。Selenium Manager の場合、これらの値は、ドライバとブラウザのバージョン検出のためにネットワークリクエストを行うことによって見つかったバージョンです。デフォルトでは、TTL は 3600 秒（つまり、1 時間）であり、構成値を使用して調整したり、この構成値を 0 に設定して無効にしたりできます。

TTL メカニズムは、Selenium の全体的なパフォーマンスを向上させるための方法です。これは、検出されたドライバとブラウザのバージョン（例：Chrome 115 の適切な chromedriver バージョンは 115.0.5790.170）が短期的には同じままである可能性が高いという事実に基づいています。したがって、検出されたバージョンはメタデータファイルに書き込まれ、同じ連続したネットワークリクエストを行う代わりにそこから読み取られます。このようにして、ドライババージョン検出中（前に導入した自動ドライバ管理プロセスのステップ 2）、Selenium Manager は最初にファイルメタデータを読み取ります。新しい解決策（つまり、TTL 中に有効なドライバ/ブラウザバージョン）が見つかった場合、そのバージョンが使用されます（新しいネットワークリクエストを行う時間を節約します）。見つからない場合、または TTL が期限切れになった場合は、ネットワークリクエストが行われ、結果がメタデータファイルに保存されます。

例を考えてみましょう。Selenium バインディングは、Selenium Manager に chromedriver を解決するように要求します。Selenium Manager は Chrome 115 がインストールされていることを検出するため、適切な chromedriver バージョン（その時点では 115.0.5790.170）を検出するために CfT エンドポイントにネットワークリクエストを行います。このバージョンはメタデータファイルに保存され、次の 1 時間（TTL）の間有効と見なされます。Selenium Manager がその時間内に chromedriver を解決するように要求された場合（これはテストスイートの実行で発生する可能性があります）、chromedriver バージョンは CfT エンドポイントに新しいリクエストを行う代わりに、メタデータファイルを読み取ることで検出されます。1 時間後、キャッシュに保存されている chromedriver バージョンは古いと見なされ、Selenium Manager は対応するエンドポイントに新しいネットワークリクエストを行うことでリフレッシュします。

Selenium Manager には、キャッシュを処理するための 2 つの追加引数が含まれています。

• --clear-cache: キャッシュフォルダを削除します（環境変数 SE_CLEAR_CACHE=true と同等）。
• --clear-metadata: メタデータファイルを削除します（環境変数 SE_CLEAR_METADATA=true と同等）。

バージョニング

Selenium Manager は、Selenium と同じバージョニングスキーマに従います。ただし、Selenium Manager のリリースにはメジャーバージョン 0 を使用します。これはまだベータ版であるためです。たとえば、Selenium 4.12.0 に同梱されている Selenium Manager バイナリは、バージョン 0.4.12 に対応します。

Selenium Manager の取得

ほとんどのユーザーにとって、Selenium Manager と直接対話する必要はありません。Selenium バインディングが内部的に使用しているためです。ただし、Selenium Manager を試してみたい場合や、ドライバまたはブラウザ管理を含むユースケースで使用したい場合は、さまざまな方法で Selenium Manager バイナリを取得できます。

• Selenium リポジトリから。Selenium Manager のソースコードは、メインの Selenium リポジトリの rust フォルダに保存されています。さらに、Windows、Linux、macOS 用にコンパイルされたバージョンは、Selenium Manager Artifacts リポジトリにあります。安定版 Selenium Manager バイナリ（つまり、最新の安定版 Selenium バージョンで配布されているもの）は、この ファイル にリンクされています。
• ビルドワークフローから。Selenium Manager は、GitHub Actions ワークフロー を使用してコンパイルされます。このワークフローは、Windows、Linux、macOS 用のバイナリを作成します。これらのバイナリは、これらのワークフローの実行からダウンロードできます。
• キャッシュから。Selenium Java バインディングのバージョン 4.15.0 以降では、Selenium Manager バイナリが抽出され、キャッシュフォルダにコピーされます。たとえば、Selenium 4.15.0 に同梱されている Selenium Manager バイナリは、フォルダ ~/.cache/selenium/manager/0.4.15) に保存されています。

例

典型的な例を考えてみましょう。chromedriver を自動的に管理したいとします。そのためには、Selenium Manager を次のように呼び出します（--debug フラグはオプションですが、Selenium Manager が何をしているかを理解するのに役立ちます）。

$ ./selenium-manager --browser chrome --debug
DEBUG   chromedriver not found in PATH
DEBUG   chrome detected at C:\Program Files\Google\Chrome\Application\chrome.exe
DEBUG   Running command: wmic datafile where name='C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe' get Version /value
DEBUG   Output: "\r\r\n\r\r\nVersion=116.0.5845.111\r\r\n\r\r\n\r\r\n\r"
DEBUG   Detected browser: chrome 116.0.5845.111
DEBUG   Discovering versions from https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json
DEBUG   Required driver: chromedriver 116.0.5845.96
DEBUG   Downloading chromedriver 116.0.5845.96 from https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/116.0.5845.96/win64/chromedriver-win64.zip
INFO    Driver path: C:\Users\boni\.cache\selenium\chromedriver\win64\116.0.5845.96\chromedriver.exe
INFO    Browser path: C:\Program Files\Google\Chrome\Application\chrome.exe

この場合、ローカルの Chrome（Windows 内）が Selenium Manager によって検出されます。次に、そのバージョンと CfT エンドポイントを使用して、適切な chromedriver バージョン（この例では 115）がローカルキャッシュにダウンロードされます。最後に、Selenium Manager は 2 つの結果を提供します。i) ドライバパス（ダウンロード済み）、ii) ブラウザパス（ローカル）。

別の例を考えてみましょう。今度は Chrome ベータ版を使用したいとします。したがって、Selenium Manager を呼び出して、次のようにそのバージョンラベルを指定します（CfT ベータ版が検出、ダウンロード、およびローカルキャッシュに保存されることに注意してください）。

$ ./selenium-manager --browser chrome --browser-version beta --debug
DEBUG   chromedriver not found in PATH
DEBUG   chrome not found in PATH
DEBUG   chrome beta not found in the system
DEBUG   Discovering versions from https://googlechromelabs.github.io/chrome-for-testing/last-known-good-versions-with-downloads.json
DEBUG   Required browser: chrome 117.0.5938.22
DEBUG   Downloading chrome 117.0.5938.22 from https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/117.0.5938.22/win64/chrome-win64.zip
DEBUG   chrome 117.0.5938.22 has been downloaded at C:\Users\boni\.cache\selenium\chrome\win64\117.0.5938.22\chrome.exe
DEBUG   Discovering versions from https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json
DEBUG   Required driver: chromedriver 117.0.5938.22
DEBUG   Downloading chromedriver 117.0.5938.22 from https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/117.0.5938.22/win64/chromedriver-win64.zip
INFO    Driver path: C:\Users\boni\.cache\selenium\chromedriver\win64\117.0.5938.22\chromedriver.exe
INFO    Browser path: C:\Users\boni\.cache\selenium\chrome\win64\117.0.5938.22\chrome.exe

スクリプトへの Selenium Manager の実装

• Java
• Python
• CSharp
• Ruby
• JavaScript
• Kotlin

def setup_without_selenium_manager():
    chrome_service = Service(executable_path='path/to/chrome.exe')
    driver = webdriver.Chrome(chrome_service)
    return driver

def setup_with_selenium_manager():
    driver = webdriver.Chrome()
    return driver

Selenium Grid

Selenium Manager を使用すると、Selenium Grid を設定するときにドライバを自動的に構成できます。そのためには、Selenium Grid を起動するコマンドに引数 --selenium-manager true を含める必要があります。詳細については、Selenium Grid の開始ページ をご覧ください。

さらに、Selenium Manager では Selenium Grid リリースを自動的に管理することもできます。そのためには、引数 --grid が次のように使用されます。

$ ./selenium-manager --grid

このコマンドの後、Selenium Manager は Selenium Grid の最新バージョンを検出し、selenium-server.jar をローカルキャッシュに保存します。

オプションで、引数 --grid を使用すると、Selenium Grid バージョン（--grid <GRID_VERSION>）を指定できます。

既知の制限事項

接続の問題

Selenium Manager は、オンラインリポジトリからドライバとブラウザを検出およびダウンロードするために、リモートエンドポイント（Chrome for Testing (CfT) など）を要求します。この操作がプロキシまたはファイアウォールのある企業環境で実行される場合、次のような接続の問題が発生する可能性があります。

error sending request for url (https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json)

error trying to connect: dns error: failed to lookup address information

error trying to connect: An existing connection was forcibly closed by the remote host. (os error 10054)

その場合は、次の解決策を検討してください。

• Selenium のプロキシ機能を使用します（ドキュメント を参照）。または、環境変数 SE_PROXY を使用してプロキシ URL を設定するか、設定ファイルを使用します（設定 を参照）。
• Selenium Manager が必要とするリモートリクエストとダウンロードを有効にするために、ネットワーク設定を確認してください。

カスタムパッケージマネージャ

ブラウザに特定のドライバを使用する必要がある Linux パッケージマネージャ（Anaconda、snap など）を使用している場合は、要件に応じて、ドライバの場所、ブラウザの場所、またはその両方を指定する必要があります。

代替アーキテクチャ

Selenium は、Google の Chrome for Testing によって管理される 5 つのアーキテクチャすべてと、Microsoft Edge 用に提供される 6 つのドライバすべてをサポートしています。

Selenium バインディングの各リリースには、Linux、Windows、Mac 用の 3 つの個別の Selenium Manager バイナリが付属しています。

• Mac バージョンは、x64 と aarch64 (Intel および Apple) の両方をサポートしています。
• Windows バージョンは、x86 と x64 (32 ビットおよび 64 ビット OS) の両方で動作するはずです。
• Linux バージョンは、x64 でのみ動作することが確認されています。

より多くのアーキテクチャをサポートしない理由

1. Chrome for TestingもMicrosoft Edgeも追加のアーキテクチャをサポートしていないため、Selenium Managerが動作するためには、非公式な何かを管理する必要があるでしょう。
2. 現在、バイナリは既存のGitHub Actionsランナーからビルドしていますが、これらのランナーはこれらのアーキテクチャをサポートしていません。
3. 追加のアーキテクチャはすべてSeleniumのリリースとともに配布されるため、全体のビルドサイズが増加します。

arm64/aarch64、32ビットアーキテクチャ、またはRaspberry PiでLinuxを実行している場合、Selenium Managerは動作しません。ユーザーにとっての最大の問題は、以前はカスタムビルドのドライバーを入手してPATHに配置することで動作していたことです。Selenium ManagerがPATH上のドライバーを特定する役割を担うようになったため、このアプローチはもはや機能しません。ユーザーはServiceクラスを使用し、場所を直接設定する必要があります。Selenium Managerが各バインディングでロジックを管理する代わりにPATH上のドライバーを探すことには多くの利点があり、これは現在私たちが受け入れているトレードオフです。

ただし、Selenium 4.13.0以降、Seleniumバインディングでは、SE_MANAGER_PATHという環境変数を使用してSelenium Managerバイナリの場所を特定できます。この変数が設定されている場合、バインディングはその値をローカルファイルシステム内のSelenium Managerのパスとして使用します。この機能により、ユーザーはSelenium Managerのカスタムコンパイルを提供できます。たとえば、デフォルトのバイナリ（Windows、Linux、macOS用にコンパイルされたもの）が特定のシステム（LinuxのARM64など）と互換性がない場合などです。

ブラウザの依存関係

Linuxでブラウザを自動的に管理する場合、Selenium Managerはブラウザベンダー（つまり、Chrome、Firefox、Edge）によって公開されたリリースに依存します。これらのリリースはほとんどの場合、移植可能です。それにもかかわらず、既存のライブラリが必要になる場合があります。Linuxでは、この問題はFirefoxを実行しようとしたときに発生する可能性があります。例：

libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

そのような場合は、そのライブラリをインストールすることが解決策です。例：

sudo apt-get install libdbus-glib-1-2

同様の問題は、LinuxでChrome for Testingを実行しようとした場合にも発生する可能性があります。

error while loading shared libraries: libatk-1.0.so.0: cannot open shared object file: No such file or directory

この場合、インストールするライブラリは次のとおりです。

sudo apt-get install libatk-bridge2.0-0

ドライバパスに環境変数を使用する

Selenium Managerを使用せずに、環境変数を使用してドライバーのパスを指定することも可能です。次の環境変数がサポートされています。

• SE_CHROMEDRIVER
• SE_EDGEDRIVER
• SE_GECKODRIVER
• SE_IEDRIVER
• SE_SAFARIDRIVER

たとえば、chromedriverへのパスを指定するには、SE_CHROMEDRIVER環境変数をchromedriver実行可能ファイルのパスに設定します。次のバインディングを使用すると、環境変数を使用してドライバーのパスを指定できます。

• Ruby
• Java
• Python

この機能は、Selenium Rubyバインディングのバージョン4.25.0以降、およびPythonバインディングのバージョン4.26.0以降で利用可能です。

カスタム Selenium Manager の構築

現在サポートされていないアーキテクチャで動作する独自のカスタムSelenium Managerを構築するには、次の手順を利用できます。

1. Rust開発環境をインストールする
2. Seleniumをローカルマシンにクローンする git clone https://github.com/SeleniumHQ/selenium.git --depth 1
3. クローンしたディレクトリに移動する cd selenium/rust
4. Seleniumをビルドする cargo build --release
5. ドライバーのパスに次の環境変数を設定する SE_MANAGER_PATH=~/selenium/rust/target/release/selenium-manager
6. 使用したいドライバーをシステムのPATH上の場所に配置する
7. Seleniumは、ビルドされたSelenium Managerを使用して、PATH上にある手動でダウンロードされたドライバーを特定するようになります。

ロードマップ

進行中の作業は、Selenium Managerプロジェクトダッシュボードで追跡できます。さらに、各Selenium Managerリリースで出荷された新機能は、changelogファイルで確認できます。