【ITニュース解説】I replaced Selenium screenshots with a 3-line API call

システム開発の現場では、Webアプリケーションが意図した通りに表示されているかを確認するため、定期的にスクリーンショットを撮ることがよくある。特に、プログラムの変更が加えられるたびに自動的にテストを実行する「継続的インテグレーション（CI）パイプライン」と呼ばれる仕組みの中で、このスクリーンショット取得が行われる場合が多い。CIパイプラインは、開発者が書いたコードが問題なく動作するかを自動で検証する重要な工程だ。

しかし、このスクリーンショットの自動取得には、これまで多くの課題が伴っていた。典型的なのが「Selenium（セレニウム）」というツールを使う方法である。Seleniumは、Webブラウザを自動で操作するためのオープンソースのツールだ。例えば、Webページを開き、特定のボタンをクリックし、その結果表示される画面のスクリーンショットを撮るといった一連の操作を、プログラムで記述して実行できる。開発者は、Webアプリケーションが様々な環境でどのように表示されるかを確認するために、このSeleniumをCIパイプラインに組み込んでいた。

だが、このSeleniumを使ったスクリーンショット取得には、いくつか深刻な問題があった。まず、Seleniumを動作させるためには、実際のWebブラウザ（例えばGoogle Chrome）とそのブラウザを制御するための「ChromeDriver」といった専用のドライバソフトウェアが必要になる。これらのソフトウェアは非常に容量が大きく、CIパイプラインの環境を構築する際に使われる「Dockerイメージ」という仮想的な実行環境のサイズを膨大にしていた。記事によれば、スクリーンショット取得のためだけにDockerイメージが800MBにも達していたという。Dockerイメージが大きいと、CIパイプラインのビルド時間が長くなる原因となる。実際に、スクリーンショット取得のステップだけで4分もの時間を要していたそうだ。

さらに厄介だったのは、これらのソフトウェアのメンテナンスだ。Webブラウザは頻繁にバージョンアップされるが、それに対応してChromeDriverも更新されなければならない。もしバージョンが一致しないと、Seleniumが正常に動作しないといった問題が頻繁に発生した。また、Chromeブラウザ自体の設定や挙動が更新によって変わり、それまで正しく撮れていたスクリーンショットが突然おかしくなることもあった。さらに、CIパイプラインが動作するサーバー（「CIランナー」と呼ばれる）ごとにフォントの描画が異なり、同じコードでも環境によってスクリーンショットの見え方が変わってしまう、といった細かい問題にも悩まされていた。結果として、開発者はスクリーンショットを本来の目的で活用するよりも、Selenium環境の維持やトラブルシューティングに多くの時間を費やすことになっていたのである。

このような状況を解決するため、今回の記事では思い切った改善策が実行された。それは、既存のSeleniumを使った複雑な設定をすべて廃止し、外部の専門サービスが提供する「API」を利用したシンプルな方法に置き換えるというものだ。API（Application Programming Interface）とは、あるソフトウェアの機能やデータを別のソフトウェアから利用するための窓口のようなものだ。このケースでは、スクリーンショットの撮影を専門に行うWebサービスに、インターネット経由で「このURLのスクリーンショットを撮ってほしい」とリクエストを送り、その結果を受け取る形となる。

具体的には、たった3行のプログラムコードでこの処理が実現された。まず、WebサービスのURLと、スクリーンショットを撮りたいターゲットのURL、画像サイズ、フォーマットなどの情報をHTTPという通信プロトコルを使って送信する。このとき、APIを利用するための認証情報（APIキー）も一緒に送る。すると、Webサービス側でスクリーンショットが生成され、その画像データが返ってくる。開発者は、そのデータを受け取って、ローカルファイルとして保存するだけだ。

この変更によって、いくつか劇的な改善が見られた。まず、Webブラウザのバイナリファイルやドライバが一切不要になったため、Dockerイメージのサイズは800MBからわずか120MBへと大幅に削減された。これに伴い、CIパイプラインのビルド時間も、スクリーンショット取得のステップだけで4分かかっていたものが、たった12秒にまで短縮された。これは開発サイクル全体の高速化に大きく貢献する。

最も大きなメリットの一つは、メンテナンスの手間がゼロになったことだ。ブラウザのバージョンアップやドライバの互換性問題、フォントのレンダリング差異といった、これまで開発者を悩ませてきた問題は、すべて外部サービスの責任となり、開発者はその解決に時間を費やす必要がなくなった。サービス側が常に最新の環境でスクリーンショットを提供してくれるため、開発者は本質的な開発業務に集中できるようになったのだ。さらに、スクリーンショットの一貫性も向上した。どのCIランナーで実行されても、常に同じレンダリング環境で撮影されるため、「ある環境では問題ないのに、別の環境では表示が崩れている」といった、環境依存のデバッグ作業が不要になった。

もちろん、この新しい方法にもいくつかの「トレードオフ」、つまりメリットと引き換えに発生するデメリットが存在する。最も明白なのはコストだ。外部の専門サービスを利用するためには、通常、利用料を支払う必要がある。記事の筆者のケースでは、1日あたり約200枚のスクリーンショットを撮影するとしても、月々わずか数ドル程度の費用で済んだという。これは、これまでエンジニアがSeleniumのメンテナンスに費やしていた時間（エンジニアの人件費）と比較すれば、はるかに安価な投資だと判断できる。

もう一つのトレードオフは、外部サービスへの依存だ。もし利用しているスクリーンショットAPIのサービスが一時的に停止した場合、CIパイプラインのビルドが失敗してしまう可能性がある。このリスクに対しては、APIへのリクエストが失敗した場合に、数秒の間隔を置いて数回再試行する、といった対策を講じることで、実運用上は大きな問題になっていないとのことだ。

結論として、もしWebブラウザのバージョンアップやドライバの互換性問題に頻繁に悩まされており、スクリーンショット取得のためのCIパイプラインのメンテナンスに多くの時間を費やしている開発者であれば、このようなAPIベースのサービスへの切り替えは非常に有効な選択肢となる。一方、1日のスクリーンショット取得数が50枚未満と少なく、現在のSelenium環境が安定して動作しているのであれば、無理に切り替える必要はないだろう。重要なのは、開発者の時間と労力を、トラブルシューティングではなく、より価値のある開発作業に集中させることにある。この事例は、既存の複雑なシステムをシンプルで効率的な外部サービスに置き換えることで、いかに多くのメリットが得られるかを示す好例と言える。