テストが CI（継続的インテグレーション環境）で失敗したとき、真っ先に疑われるのはセレクタの書き方やタイムアウト設定だ。しかし現代の業務システムにおいて、その診断は多くの場合、問題の表層しか捉えていない。
「ヘッドレス環境だけ落ちる」の正体
ヘッドレスブラウザとは、画面描画を省略してバックグラウンドで動作するブラウザのことで、CI サーバでの自動テストによく使われる。「ローカルでは通るが headless Chrome だと落ちる」というパターンは、多くの現場で経験される。原因を「ヘッドレスの不安定さ」と一括りにしがちだが、実際は複数の独立した要因が混在している。
ビューポートサイズ（ブラウザの描画領域の大きさ）が異なるためにボタンが画面外に配置される場合、アニメーションのタイミングが GUI 環境と異なる場合、フォントのフォールバックが変わってレイアウトがずれる場合、などが代表的だ。これらはすべて「タイミング問題」という同じラベルで括られやすいが、それぞれ必要な修正が全く違う。要素が画面外にいるなら scroll-into-view の処理を追加する。ネットワーク応答の遅れなら API スタブを使う。タイムアウトを延ばすだけでは、どちらの問題も隠蔽されるだけで根治しない。
リトライが「信頼の幻想」を生み出す
リトライ（テスト失敗時に自動で再実行する仕組み）は CI のエラー件数を減らす最も手軽な手段だ。しかしこれが大きな落とし穴になる。3 回目の再実行で通ったテストは、CI ダッシュボード上では「成功」として記録される。しかし実際には CI ランナーの時間を余分に消費し、フィードバックを遅らせ、「本当にリリースして安全か」という判断材料としての信頼性を失っている。
数百回のビルドを通じてこのコストを積算すると、計算機リソースだけでなく、開発者の調査時間、マージの遅延、そして最終的には「失敗しても誰かが手動で再実行する」という文化の定着につながる。テストスイートがリリース判断の根拠として機能しなくなった時点で、テスト自動化の目的は実質的に失われている。
実行環境そのものが「テストの一部」である
業務システムの E2E テスト（エンドツーエンドテスト：ユーザー操作を模倣して画面から API まで一貫して検証するテスト）では、実行環境の差異が再現性に直結する。Linux、macOS、Windows の CI ランナーはフォントレンダリング、ブラウザビルド、ファイルパスの区切り文字、グラフィックス処理の権限がそれぞれ異なる。テストのロジックが正しくても、環境によってアプリケーションの挙動が変わる場合がある。
たとえば日本語フォントを含む帳票系画面や、Canvas を使った可視化コンポーネントは、フォントのフォールバック設定が OS ごとに違うため、スクリーンショット比較テストが Linux CI では常に差分を検出してしまうケースがある。この問題を「たまたまの失敗」として処理し続けると、環境依存の不具合を本番リリース後に発見することになる。
解決策の一つは、Docker コンテナで実行環境を固定し、ローカルと CI の差をなくすことだ。たとえば Playwright の公式 Docker イメージを使えば、ブラウザバージョンとシステムフォントを揃えられる。
docker run --rm -v $(pwd):/work -w /work \\
mcr.microsoft.com/playwright:v1.45.0-jammy \\
npx playwright testこのように環境を明示的にコード管理することで、「自分の手元では再現しない」という報告が減る。
認証フローがスクリプトの限界を露わにする
業務システムで特に複雑になるのが認証テストだ。チュートリアルでは「メールとパスワードを入力してログインボタンを押す」という単純なシナリオが紹介される。しかし実際の業務システムの認証フローは次のような複数ステップを含む。
- 外部 IdP（Identity Provider：認証情報を一元管理するサービス、Azure AD や Okta など）へのリダイレクト
- TOTP（時刻同期式ワンタイムパスワード）や SMS による MFA チャレンジ
- セッション期限切れとリフレッシュトークンの処理
- アカウント状態に応じた条件分岐（初回ログイン・パスワード変更強制など）
これらを Playwright や Cypress で自動化する場合、MFA の TOTP コードをテスト時に動的生成する仕組みや、外部 IdP をモックする API インターセプトの実装が必要になる。テストコードが増えるほど「誰がそのテストを保守するか」という所有権の問題も浮上する。QA チームが書いたテストをアプリ開発者が読めない、あるいは逆に開発者が書いたテストを QA がデバッグできない、という分断は規模が大きくなるほど顕在化する。
ブラウザテストの信頼性は、フレームワークの選択だけで決まるものではない。実行環境の標準化、リトライ戦略の見直し、認証フローの設計、そしてテストの所有権の明確化が組み合わさって初めて、リリース判断に使える証拠として機能する。テストスイートを「通過するもの」ではなく「信頼できる情報源」として設計し直すことが、大規模システムの保守運用では特に求められる。