Selenium運用崩壊した話7選｜QAエンジニアが実務で経験した失敗と立て直し策

SeleniumでE2Eテスト自動化を運用しているQAエンジニアが実際に経験した「運用崩壊」の失敗談を7選で解説します。ChromeDriverバージョン管理・Wait混在・xpathセレクタ依存・属人化など、Selenium固有の「動いていたのに壊れていく」パターンと立て直し策を実務経験をもとに紹介します。なお「保守負債」とは修正コストが雪だるま式に増えていく状態のことを指します。

「最初は動いていたのに、いつのまにか誰も触れないコードになっていた」——Seleniumの運用崩壊は、突然起きるのではなく、じわじわと進行します。

「最初の半年は順調だった。でも1年後、誰もそのテストコードに触れなくなっていた」——複数のプロジェクトで繰り返し目撃してきた光景です。

Seleniumの運用悪化に共通するのは、「突然壊れる」のではなく「じわじわと壊れていく」ことです。この記事では、保守負債の7つのパターンと、それぞれの立て直し策を実体験をもとに解説します。

Selenium運用崩壊した話7選とは？早見表

① ChromeDriverバージョン管理地獄でCIが毎週壊れたとは？

何が起きたか

月曜の朝、CIが突然落ちています。ログを見ると SessionNotCreatedException: This version of ChromeDriver only supports Chrome version XX。金曜から週末の間にChromeが自動更新され、ChromeDriverとバージョンが合わなくなっているのです。

最初は「ChromeDriverをダウンロードして差し替えれば直る」と思っていました。しかしこれが毎週繰り返されます。ダウンロードページを探す→バージョンを確認する→差し替える→CIを再実行する——この作業に毎週月曜の午前が消えていきました。

崩壊の予兆

• ChromeDriverのパスをハードコードしている
• requirements.txt にChromeDriverのバージョンが記載されていない
• CI環境のChromeバージョン管理が「なんとなく最新」になっている
• ChromeDriverのダウンロードが手動作業になっている

# ❌ 崩壊パターン：ChromeDriverのパスをハードコード
from selenium import webdriver
from selenium.webdriver.chrome.service import Service

driver = webdriver.Chrome(service=Service("/usr/local/bin/chromedriver"))
# バージョンが合わないと毎回ここでエラーになる

# ✅ 選択肢①：Selenium 4.6+ の Selenium Manager（標準搭載）
# Selenium 4.6以降はChromeDriver自動管理が標準機能として搭載
# ただしCI・Docker環境ではOS依存や権限設定により追加調整が必要な場合もある
from selenium import webdriver
driver = webdriver.Chrome()
# 追加ライブラリ不要（ただし環境依存の調整が必要なケースあり）

# ✅ 選択肢②：webdriver-manager（既存プロジェクト・CI環境で広く利用）
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager

driver = webdriver.Chrome(
    service=Service(ChromeDriverManager().install())
)
# 既存環境やSelenium 4.6未満では引き続き有効

② implicitWaitとexplicitWaitを混在させてFlaky地獄になったとは？

※ Flakyテストとは「成功したり失敗したりが不安定で再現性のないテスト」のことです。CIを走らせるたびに結果が変わるため、「実際のバグなのか不安定なのか」の判断が困難になります。

何が起きたか

「待機処理をしっかりやろう」とドキュメントを読んだ結果、implicitly_wait と WebDriverWait の両方をコード内に混在させてしまいました。動く日もあれば落ちる日もある——再現性のないFlakyテストが大量発生し、「テストが落ちても本当のバグかどうかわからない」状態になりました。

# ❌ 崩壊パターン：implicitWaitとexplicitWaitの混在
driver.implicitly_wait(10)  # グローバル設定

# 別の場所で
wait = WebDriverWait(driver, 5)
element = wait.until(EC.presence_of_element_located((By.ID, "submit")))
# タイムアウト計算が干渉し、Flakyの原因になる

# ✅ 立て直し策：explicitWaitに統一する
# implicitly_wait は使用しない
# すべてWebDriverWaitで明示的に待機

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

wait = WebDriverWait(driver, 10)
element = wait.until(
    EC.element_to_be_clickable((By.ID, "submit"))
)
element.click()

③ xpathセレクタ依存でUIリニューアルのたびに全壊したとは？

何が起きたか

「とにかく要素を指定できればいい」という方針で、xpathをフルパスで指定したテストコードが蓄積されていきました。半年後、フロントエンドのリニューアルでHTMLの構造が変わったとき、300件のテストのうち280件が同時に落ちました。xpathのパスが軒並み無効になったのです。

# ❌ 崩壊パターン：フルパスxpathへの依存
driver.find_element(
    By.XPATH,
    "/html/body/div[2]/main/section[1]/form/div[3]/button"
)
# HTMLの構造が少し変わるだけで全壊する

# ⚠️ 相対xpathでも脆弱な場合がある
driver.find_element(By.XPATH, "//div[@class='btn-wrapper']/button[1]")
# classが変わると壊れる

# ✅ 推奨：data-testidを使ったCSS Selectorが最も安定
driver.find_element(By.CSS_SELECTOR, "[data-testid='submit-btn']")
# data-testidはテスト専用の属性 → UIリニューアルでも変えないルールを作れる

# ✅ 次点：IDやname属性
driver.find_element(By.ID, "submit-btn")
driver.find_element(By.NAME, "submit")

セレクタ安定性の比較

④ Page Object化せず1000行のスクリプトが誕生したとは？

何が起きたか

「まず動かすことが優先」という方針でテストを追加し続けた結果、1つのテストファイルが1000行を超えていました。ログインの処理が5箇所にコピー&ペーストされていて、ログイン画面のセレクタが変わると5箇所すべてを修正しなければなりません。修正漏れでバグが埋まるようになりました。

# ❌ 崩壊パターン：同じ操作がコード内に散在
def test_purchase():
    driver.find_element(By.ID, "email").send_keys("user@example.com")
    driver.find_element(By.ID, "password").send_keys("pass")
    driver.find_element(By.ID, "login-btn").click()
    # ...購入処理...

def test_profile():
    driver.find_element(By.ID, "email").send_keys("user@example.com")  # 重複
    driver.find_element(By.ID, "password").send_keys("pass")           # 重複
    driver.find_element(By.ID, "login-btn").click()                    # 重複
    # ...プロフィール処理...

# ✅ 立て直し策：Page Object Model で操作を集約
class LoginPage:
    def __init__(self, driver):
        self.driver = driver

    def login(self, email: str, password: str):
        self.driver.find_element(By.ID, "email").send_keys(email)
        self.driver.find_element(By.ID, "password").send_keys(password)
        self.driver.find_element(By.ID, "login-btn").click()

# テストコードは意図だけを書く
def test_purchase(driver):
    LoginPage(driver).login("user@example.com", "pass")
    # ...購入処理のみ...

⑤ 担当者が退職して誰も触れないコードになったとは？

何が起きたか

「このSeleniumのテストはAさんしかわからない」——Aさんが退職した翌月、テストが落ちても誰も直せない状態になりました。コードにコメントはなく、ローカル環境の構築手順もドキュメント化されていませんでした。「テストが落ちても放置する」という文化が生まれ、自動化が形骸化していきました。

属人化の具体的な症状チェックリスト

※ Yes/Noだけでなく「チームの何割が対応できるか」という視点でも確認してみてください。1人しか対応できない状態が属人化の本質です。

⑥ ヘッドレス化できずCIに組み込めなかったとは？

何が起きたか

「ローカルでは動く」ものの、CIサーバー（ヘッドレス環境）で動かすと軒並みエラーになりました。調査すると、ブラウザのウィンドウサイズや画面描画に依存した操作がテスト内に散在していることが判明。具体的には次のような問題が絡み合っていました。

# ❌ 崩壊パターン：ヘッドレスで動かない実装
# 画面サイズを前提にしたスクロール操作
driver.execute_script("window.scrollTo(0, 500)")
driver.find_element(By.ID, "submit").click()
# ヘッドレスでは500px先に要素がない場合がある

# ❌ viewport外の要素をクリック（ヘッドレスで失敗）
element = driver.find_element(By.ID, "footer-btn")
element.click()  # 画面外の場合エラー

# ✅ 立て直し策①：スクロールしてから操作（ActionChains不要）
element = driver.find_element(By.ID, "submit")
driver.execute_script("arguments[0].scrollIntoView(true);", element)
element.click()

# ✅ 立て直し策②：ウィンドウサイズを明示的に設定
from selenium import webdriver

options = webdriver.ChromeOptions()
options.add_argument("--headless")
options.add_argument("--window-size=1920,1080")  # CI環境でサイズを固定
driver = webdriver.Chrome(options=options)

⑦ Selenium 4アップグレードで全テストが動かなくなったとは？

何が起きたか

「セキュリティパッチがあるからSeleniumをアップグレードしよう」——pip install selenium --upgrade でSelenium 3からSelenium 4に上げた直後、200件のテストのうち150件以上が一斉に落ちました。Selenium 4では廃止されたAPIが複数あり、移行計画なしのアップグレードが大惨事を引き起こしました。

Selenium 3→4で廃止・変更された主なAPI

# ❌ 崩壊パターン：Selenium 3の廃止APIを使い続けていた
driver.find_element_by_id("submit")           # Selenium 4で削除
driver.find_element_by_xpath("//button")      # Selenium 4で削除
driver.find_element_by_class_name("btn")      # Selenium 4で削除

# ✅ Selenium 4対応の書き方（By.XXX を使う）
from selenium.webdriver.common.by import By

driver.find_element(By.ID, "submit")
driver.find_element(By.XPATH, "//button")
driver.find_element(By.CLASS_NAME, "btn")

FAQ

まず補足として：Selenium 4.6以降では Selenium Manager によりChromeDriver管理問題の多くは改善されています。「ChromeDriverが毎週壊れる」問題は、Selenium Manager または webdriver-manager への移行で解消できるケースもあります。

移行を検討すべき本質的な判断基準は「現在の保守負債の解消コスト」と「移行コスト」のどちらが大きいかです。「Flakyが多すぎてCIへの信頼が失われた」「テストを追加するたびに保守負債が増え続ける」「E2EとAPIテストを同一スイートで管理したい」という課題に対して、Seleniumのまま設計改善する方が低コストなケースもあります。移行前にテスト設計の問題を整理しないと、同じ問題がPlaywrightでも再発します。