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-<version>.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、実行環境を増やして並列度を上げたくなったらhub-nodeへ移す、という連続した選択肢です。別製品を導入し直す必要はありません。Selenium自体でのテストスクリプトの書き方はSeleniumを活用したWebアプリケーションテストの実施方法で、Seleniumと近年比較されることの多いツールとの違いはPlaywrightとは｜Seleniumとの違いで整理しています。

Selenium Grid（Server）の入手とインストール

Gridの本体は単一のJARファイルです。実行にはJavaと、操作対象ブラウザのドライバ（Selenium Manager導入後は多くの場合自動取得）が必要です。

selenium-server JARの入手先とJava要件

JARはSelenium公式のダウンロードページまたは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では動作しません。移行時の主な読み替えは次のとおりです。

オプションはすべてハイフン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)の設計を併用すると保守性が上がります。

Grid運用のトラブルシューティングとセキュリティ

Grid特有のつまずきは、単体WebDriverでは起きない「Nodeが登録されない」「外部から接続できない」に集中します。原因の大半はネットワークとバージョン整合です。

Nodeが登録されない・接続できない時の確認点

• Event Bus・Nodeのポート：Hubの4442・4443、Nodeの5555が双方向で開いているか。Docker/クラウドでは特に塞がれやすい。
• Hubアドレスの解決：node --hub に指定したIP/ホスト名にNodeから到達できるか（curl http://<hub>: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-<version>.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アプリケーションテストの実施方法
• Page Object Model (POM)とは？テスト自動化における有名な設計パターンの概要とメリット
• Playwrightとは｜仕組み・できること・Seleniumとの違いを解説
• Robot Frameworkとは？Pythonのテスト自動化フレームワークの使い方・主要ライブラリを解説
• Appium Desktopは終了｜Appium 3時代のInspector移行とモバイルテスト自動化