--- title: "Selenium Gridとは｜Grid 4の構成・環境構築とSelenium Serverとの違い" url: "https://www.issoh.co.jp/tech/details/5231/" published: 2025-02-07 updated: 2026-10-26 categories: ["テスト"] publisher: "株式会社一創" --- # Selenium Gridとは｜Grid 4の構成・環境構築とSelenium Serverとの違い Selenium Gridは、複数のマシンやブラウザにテストを振り分け、並列・クロスブラウザでWebテストを実行する仕組みです。Selenium 4以降は「Selenium Server」と「Selenium Grid」が同一の `selenium-server` JARへ統合され、単体で動かすか分散で動かすかは起動モードの違いになりました。最新は**4.41.0（2026年2月22日リリース）**で、`-role hub` や `selenium-server-standalone.jar` といった旧構文はすでに廃止されています。本記事では、Grid 4の構成、standalone/hub-nodeでの環境構築、Serverとの違い、Docker・Kubernetesでの分散実行、リモート接続までを、旧バージョンからの移行点を含めて解説します。 ## まとめ：Selenium Grid 4の要点 - Selenium 4では `selenium-server-.jar` 1本を **standalone / hub / node** のサブコマンドで起動する。旧 `-role hub`・`selenium-server-standalone.jar` は使えない。 - 「Selenium Server（単体）」と「Selenium Grid（分散）」という製品的区別は消え、同じJARの起動モードの差になった。単体運用＝standaloneモード。 - 分散構成はHub＋Nodeで組み、HubのEvent Busポート（4442・4443）とNodeのポート（5555）の疎通が登録の前提。 - テスト側の接続先は `http://localhost:4444`。Selenium 3までの `/wd/hub` 付与は不要になった（後方互換で残るのみ）。 - DockerイメージとGrid UI（`http://localhost:4444/ui`）で構築・監視でき、4.41.0ではDynamic GridがKubernetesクラスタ上でネイティブ動作する。 ## Selenium Gridの役割とGrid 4の構成 1台のマシンで直列にテストを回すと、ブラウザ数×テスト数だけ実行時間が積み上がります。Selenium Gridは、テスト要求を受け取るHubと、実際にブラウザを動かすNodeに処理を分け、複数環境へ同時に振り分けることでこの時間を圧縮します。CI/CDでのクロスブラウザ検証や、WindowsのChrome・macOSのSafari・LinuxのFirefoxを同時に確認したいケースが主な用途です。 ### 並列テストとクロスブラウザ実行の仕組み Gridはクライアント（テストスクリプト）とブラウザ実行環境をネットワークで分離します。テストは `RemoteWebDriver` でHubへセッションを要求し、Hubは空いているNodeへ割り当てます。これにより、ローカルにブラウザを入れずに別マシンのブラウザを操作でき、Nodeを増やすほど並列度が上がります。1つのNodeが同時に受けられるセッション数は `--max-sessions` で制御します。 ### Grid 4のコンポーネント（Router・Distributor・Session Map・New Session Queue・Event Bus） Selenium 4のGridは、Selenium 3の単純なHub–Node構造から内部を分割し、5つのコンポーネントで動きます。**Router**が入口として要求を振り分け、**New Session Queue**が新規セッション要求を貯め、**Distributor**が要求を適切なNodeへ割り当て、**Session Map**がセッションIDとNodeの対応を保持し、**Event Bus**がコンポーネント間の通信を担います。standaloneモードではこれら全部が1プロセスに同居し、フル分散（distributed）モードでは各コンポーネントを個別プロセスとして起動して大規模にスケールできます。 ### Selenium Serverとの違い（standaloneモードとhub-nodeモード） 「Selenium ServerとGridは何が違うのか」という疑問は、Selenium 4では起動モードの違いに置き換わります。同じ `selenium-server` JARを、単体で使うか分散で使うかの選択です。 | 観点 | standaloneモード（旧Server相当） | hub-nodeモード（Grid） | | ---- | ------------------------ | ---------------------- | | 構成 | 1プロセスで完結 | Hub＋複数Nodeに分散 | | 並列実行 | 同一マシン内で可 | 複数マシンへスケール可 | | 用途 | ローカル開発・小規模CI | 大規模クロスブラウザ・分散 | | 起動 | `... standalone` | `... hub` ＋ `... node` | | 接続先 | localhost:4444 | Hubのアドレス:4444 | つまり、小さく始めるならstandalone、実行環境を増やして並列度を上げたくなったらhub-nodeへ移す、という連続した選択肢です。別製品を導入し直す必要はありません。Selenium自体でのテストスクリプトの書き方は[Seleniumを活用したWebアプリケーションテストの実施方法](/tech/details/4241/)で、Seleniumと近年比較されることの多いツールとの違いは[Playwrightとは｜Seleniumとの違い](/tech/details/3167/)で整理しています。 ## Selenium Grid（Server）の入手とインストール Gridの本体は単一のJARファイルです。実行にはJavaと、操作対象ブラウザのドライバ（Selenium Manager導入後は多くの場合自動取得）が必要です。 ### selenium-server JARの入手先とJava要件 JARは[Selenium公式のダウンロードページ](https://www.selenium.dev/downloads/)またはGitHubのReleasesから `selenium-server-4.41.0.jar` を取得します。「selenium server jar download」「selenium grid download」で探しているファイルはこれ1つで、Server用とGrid用は分かれていません。Javaは**JDK 17以上**を用意するのが確実です（Selenium 4系はJava 11以上で始まり、近年のビルドでJava 17が最小要件へ引き上げられました。厳密な要件はリリースノートで確認してください）。 ``` java -version java -jar selenium-server-4.41.0.jar standalone ``` 上記でstandaloneモードのGridがポート4444で起動します。起動確認は次項のとおりです。 ### 旧 selenium-server-standalone.jar からの移行 ネット上に残る `selenium-server-standalone.jar` や `-role hub` / `-role node` はSelenium 2/3時代の記法で、Selenium 4では動作しません。移行時の主な読み替えは次のとおりです。 | 旧（Selenium 3） | 新（Selenium 4） | | --------------------- | --------------------- | | `-role hub` | `hub`（サブコマンド） | | `-role node -hub ...` | `node --hub ...` | | `-port 5555` | `--port 5555`（ハイフン2つ） | | JSON設定ファイル | TOML設定ファイル | | `/grid/console` | `/ui`（Grid UI） | オプションはすべてハイフン2つ（`--port`・`--max-sessions` など）に変わり、設定ファイルの形式もJSONからTOMLになりました。旧記事のコマンドをそのまま貼ると「Unknown option」で起動しないため、まずこの対応表で置き換えてください。 ## 3つの起動モードで環境構築する Grid 4はstandalone・hub-node・distributedの3モードを持ちます。distributedは各コンポーネントを個別起動する大規模向けなので、まずstandaloneとhub-nodeを押さえれば実務は足ります。 ### standaloneモードで単一マシンに構築する 開発機やCIランナー1台で完結させるなら、標準はstandaloneです。1コマンドでRouterからNodeまで揃います。 ``` java -jar selenium-server-4.41.0.jar standalone --port 4444 ``` 設定を毎回オプション指定する代わりに、TOMLファイルへ切り出すこともできます。 ``` java -jar selenium-server-4.41.0.jar standalone --config config.toml ``` ### HubとNodeで分散構成を組む 実行環境を複数マシンへ広げるときは、Hubを1つ立て、各マシンでNodeを起動してHubへ登録します。 ``` # Hubマシンで java -jar selenium-server-4.41.0.jar hub # Nodeマシンで（HubのIPを指定して登録） java -jar selenium-server-4.41.0.jar node --hub http://192.168.1.10:4444 ``` 登録が成立しないときの典型原因は、Event BusとNodeのポートがファイアウォールで塞がれていることです。Hub側でEvent Busの**4442・4443**、Node側で待ち受けポートの**5555**を相互に開放する必要があります（フル分散構成ではEvent Busが5557も使います）。Hubと同一マシンにNodeを置く場合はサブコマンドを `node` にするだけで、`--hub` は省略できます。 ### 起動確認とGrid UIでの監視 起動後は次の3点で状態を確認します。ステータスは `/status` エンドポイントがJSONで返し、Nodeの接続状況はGrid UIで視覚的に確認できます。 ``` curl http://localhost:4444/status ``` ブラウザで `http://localhost:4444/ui` を開くと、登録済みNodeと実行中セッションのダッシュボードが表示されます。`ready` が `true` であれば、テスト要求を受け付けられる状態です。 ## DockerとKubernetesでGridを分散実行する JARを各マシンへ配る代わりに、公式のDockerイメージを使えばHub・Nodeをコンテナとして即座に立ち上げられます。実行環境の増減がコンテナ数の増減になるため、スケールと再現性の面で分散Gridの主流になっています。 ### docker composeでHubとNodeを立てる Hubに `selenium/hub`、ブラウザNodeに `selenium/node-chrome` などを割り当て、Event Busの接続先を環境変数で渡します。 ``` services: selenium-hub: image: selenium/hub:4.41.0 ports: - "4442:4442" - "4443:4443" - "4444:4444" chrome: image: selenium/node-chrome:4.41.0 depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOST=selenium-hub - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443 firefox: image: selenium/node-firefox:4.41.0 depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOST=selenium-hub - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443 ``` `docker compose up -d` で起動し、Node数を増やしたいブラウザは `--scale chrome=3` のようにスケールできます。単体で試すだけなら、Hub・Nodeを分けず `selenium/standalone-chrome` 1つを `docker run -d -p 4444:4444 --shm-size=2g selenium/standalone-chrome` で動かす方が手早く済みます（`--shm-size=2g` はChromeが共有メモリ不足でクラッシュするのを防ぐため公式も推奨）。 ### Dynamic GridとKubernetesネイティブ実行（4.41.0の新機能） 固定台数のNodeを常時起動する代わりに、Dynamic Gridはセッション要求のたびにブラウザコンテナを起動し、終了後に破棄します。アイドル時のリソースを抑えられるのが利点です。従来はDocker上での動作が中心でしたが、**Grid 4.41.0ではDynamic GridがKubernetesクラスタ内でネイティブに動作する**ようになり、Podとしてのオンデマンド起動・自動スケールに対応しました。Kubernetes前提の大規模テスト基盤では、公式Helmチャートでの導入とあわせて検討する価値があります。 ## リモートWebDriverで接続しクロスブラウザ並列テストを実行する Gridを立てたら、テスト側は `RemoteWebDriver` でHubに接続します。ローカルドライバを直接使うコードとの違いは接続先URLの指定だけです。 ### RemoteWebDriverの接続設定 Selenium 4では接続先を `http://localhost:4444` と指定します。Selenium 3まで必要だった `/wd/hub` の付与は不要で、後方互換のため残ってはいるものの、新規コードでは付けないのが標準です。 ``` from selenium import webdriver options = webdriver.ChromeOptions() driver = webdriver.Remote( command_executor="http://localhost:4444", options=options, ) driver.get("https://example.com") print(driver.title) driver.quit() ``` リモートマシンのGridに接続する場合は、`localhost` をHubのIPアドレスやホスト名へ置き換えます。 ### クロスブラウザ・並列実行の実装 Gridの価値は、同じテストを複数ブラウザへ同時に流せる点にあります。ブラウザごとにOptionsを切り替え、スレッドで並列にセッションを張れば、実行時間をブラウザ数で割った時間に近づけられます。 ``` from concurrent.futures import ThreadPoolExecutor from selenium import webdriver GRID = "http://localhost:4444" OPTIONS = { "chrome": webdriver.ChromeOptions, "firefox": webdriver.FirefoxOptions, "edge": webdriver.EdgeOptions, } def run(browser): driver = webdriver.Remote(command_executor=GRID, options=OPTIONS[browser]()) driver.get("https://example.com") print(browser, driver.title) driver.quit() with ThreadPoolExecutor(max_workers=3) as pool: pool.map(run, ["chrome", "firefox", "edge"]) ``` 並列度はNode側の `--max-sessions` と、クライアント側のスレッド数の小さい方で頭打ちになります。片方だけ増やしても速くならないため、両者を揃えて調整します。テストの構造化やページ操作の共通化には、[Page Object Model (POM)](/tech/details/10677/)の設計を併用すると保守性が上がります。 ## Grid運用のトラブルシューティングとセキュリティ Grid特有のつまずきは、単体WebDriverでは起きない「Nodeが登録されない」「外部から接続できない」に集中します。原因の大半はネットワークとバージョン整合です。 ### Nodeが登録されない・接続できない時の確認点 - **Event Bus・Nodeのポート**：Hubの4442・4443、Nodeの5555が双方向で開いているか。Docker/クラウドでは特に塞がれやすい。 - **Hubアドレスの解決**：`node --hub` に指定したIP/ホスト名にNodeから到達できるか（`curl http://:4444/status` で確認）。 - **バージョン不一致**：HubとNode、およびブラウザとドライバのメジャーバージョンを揃える。`session not created` はブラウザとドライバのズレが典型。 - **ポート競合**：`Address already in use` は4444が使用中。`--port` で別ポートに逃がす。 ### 公開時のセキュリティとアクセス制限 Gridはネットワーク越しにブラウザを操作できるため、無防備に公開すると第三者に任意サイトを開かせる踏み台になり得ます。インターネットに直接さらさないことが原則です。具体策は、ファイアウォールやクラウドのセキュリティグループで接続元IPを限定する、リバースプロキシ（Nginx等）で認証とHTTPSを挟む、外部公開せずSSHトンネル（`ssh -L 4444:localhost:4444 user@remote`）で経由接続する、のいずれかを状況に応じて組み合わせます。CI専用ネットワーク内に閉じるのが最も安全です。 ## よくある質問 ### Selenium ServerとSelenium Gridは何が違いますか？ Selenium 4では別物ではなく、同じ `selenium-server` JARの起動モードの違いです。1プロセスで動かすstandaloneモードが従来の「Selenium Server（単体）」に相当し、Hub＋Nodeで分散させるのがGridです。単体で始めて後から分散へ広げられます。 ### selenium-server-standalone.jar はもう使えませんか？ Selenium 4では使えません。ファイル名は `selenium-server-.jar`（例：`selenium-server-4.41.0.jar`）になり、`-role hub` のような旧オプションも廃止されました。`standalone` / `hub` / `node` のサブコマンドで起動してください。 ### Selenium Gridはどこからダウンロードしますか？ Selenium公式のダウンロードページ、またはGitHubのReleasesから `selenium-server-4.41.0.jar` を取得します。ServerとGridで別ファイルは存在せず、この1つのJARが両方の役割を担います。 ### リモート接続のURLに /wd/hub は必要ですか？ Selenium 4では不要です。`http://localhost:4444` を `command_executor` に指定します。`/wd/hub` は後方互換で残っていますが、新しいコードでは付けないのが標準です。 ### Selenium Gridで何台まで並列実行できますか？ 固定の上限はなく、Node数と各Nodeの `--max-sessions`、マシンのCPU・メモリで決まります。ブラウザ1セッションが相応のメモリを消費するため、実機のリソースを見ながら `--max-sessions` を調整します。オンデマンドに増減させたい場合はDynamic Grid（Docker/Kubernetes）が向きます。 ## 関連記事 - [Seleniumを活用したWebアプリケーションテストの実施方法](/tech/details/4241/) - [Page Object Model (POM)とは？テスト自動化における有名な設計パターンの概要とメリット](/tech/details/10677/) - [Playwrightとは｜仕組み・できること・Seleniumとの違いを解説](/tech/details/3167/) - [Robot Frameworkとは？Pythonのテスト自動化フレームワークの使い方・主要ライブラリを解説](/tech/details/9045/) - [Appium Desktopは終了｜Appium 3時代のInspector移行とモバイルテスト自動化](/tech/details/10729/) - [Seleniumとは？WebDriverの仕組みと4系の実行手順・ツール選定を解説](/tech/details/4241/) --- 出典: [Selenium Gridとは｜Grid 4の構成・環境構築とSelenium Serverとの違い]()（株式会社一創）