こんにちは！saimyonです👶
Social Databank Advent Calendar 2025 15日目です🎄
最近、PlaywrightのE2Eテストですこしハマったので、備忘録も兼ねてまとめます。
弊社E2Eテストの現状
弊社ではCircleCI上でPlaywrightによるE2Eテストを実施しています。
構成としては以下のようになっており、 Playwright Runnerコンテナから Webアプリケーションコンテナへ Dockerのコンテナ間通信でアクセスする形になっています。
最近開発でやっていたこと
最近、E2Eテスト対象になっている画面の内部実装を一部変更しました。
弊社プロダクトのLinyは、フレームワークはVueを利用しており、見た目や仕様に大きな変更はありません。
この変更後、手元での動作確認は問題なく完了していました。
そんな中
この実装変更後から、CI上でのみ E2Eテストが失敗するようになりました。
原因を突き止めます。
まずは手元で試してみる
まずは開発環境に対して、手元のPCのターミナルからPlaywrightを起動してテストしてみました。
テストは問題なく通ってしまい、ローカルでは再現しませんでした。
これは環境差だろうと思い、CircleCIの構成に近づけるため、Docker Desktopを使ってコンテナ間通信で Playwright を実行してみます。
テストは通りませんでした。再現しました。
スクリーンショットを確認すると、本来表示されるはずの入力ボックスが表示されていませんでした。
原因
結論からいうと、Dockerのコンテナ間通信の影響でした。
Dockerのコンテナ間通信はHTTP通信になります。
その結果、対象のVueコンポーネント内で使用していたcrypto.randomUUID()が実行されず、そのコンポーネント自体が描画されていませんでした。
なお、原因特定と解決にはClaude Codeにかなり助けてもらいました。
正直、自分だけだったら気づけなかったと思います…
なぜ crypto.randomUUID() が実行されなかったのか
単に「HTTP 通信だから」というより、HTTP通信はSecure Contextではないため、というのがより正確な理由です。
Web Crypto API（crypto.randomUUID() など）は、Secure Contextsでのみ利用可能な API です。
Secure Contextsとは、HTTPSなど通信の安全性が保証された環境を指します。
HTTP通信では中間者攻撃が可能なため、
- 通信内容の盗聴・改ざん
- 暗号化や署名といった強力な API の誤用
といったリスクがあります。
そのため、Web Crypto APIはSecure Contextではない環境（HTTP 通信など）では意図的に利用できないようになっています。
今回のCI構成では、
- ローカル開発環境：HTTPS（Secure Context）
- Docker コンテナ間通信：HTTP（非 Secure Context）
という差分があり、その結果crypto.randomUUID()がundefinedになり、それに依存していたVueコンポーネントが描画されませんでした。
どう解決した？
最終的には、crypto.randomUUID()を直接呼ばないようにしました。
Secure Contextsに依存するAPIをそのまま使うと、今回のように環境差によってUIが壊れる可能性があるためです。
そこで、UUID生成用のラッパー関数を用意し、
- Secure Context の場合は
crypto.randomUUID() - それ以外の場合はフォールバック処理
を行うように修正しました。
export const randomUUID = (): string => {
try {
return crypto.randomUUID();
} catch {
// Secure Context でない場合などのフォールバック
return Math.random().toString(36).substring(2, 15);
}
};
これにより、HTTPなコンテナ間通信でもコンポーネントが正しく描画されるようになり、E2Eテストも無事に通るようになりました。
おわりに
今振り返ると、PlaywrightというよりDocker のコンテナ間通信と Secure Contexts の落とし穴にハマった話だったなと思います。
Web Crypto APIやSecure Contextsについてちゃんと調べる良い機会になりました。
同じような構成でE2Eテストをしている方の参考になれば幸いです。
Discussion