Seleniumとは
Seleniumとは、Webブラウザの操作をプログラムで制御するためのオープンソースフレームワーク
読み: セレニウム
Webブラウザの操作をプログラムで制御するためのオープンソースフレームワーク。Chrome、Firefox、Edge、Safariなど主要ブラウザに対応し、テスト自動化やWebスクレイピングに広く使われている
かんたんに言うと
人間がブラウザ上でクリックや入力をする動作を、プログラムに代行させる仕組みである。テストの繰り返し作業やWeb上のデータ収集を人手でやる必要がなくなる。
WebDriverを介してブラウザを制御するSeleniumの基本的な仕組み
SeleniumはWebDriverという仕組みを通じてブラウザを操作する。WebDriverはブラウザごとに用意されたドライバープログラムで、ChromeならChromeDriver、FirefoxならGeckoDriverが対応する。
テストコードが「このボタンをクリックしろ」という命令を出すと、WebDriverがブラウザに対してHTTPリクエストを送り、ブラウザが実際にその操作を実行する。人間が操作するのと同じように、JavaScriptも動き、ページ遷移も発生する。
この仕組みのおかげで、サーバーサイドのAPIだけではテストできない「画面上の見た目」や「ユーザーの操作フロー」を検証できる。
ただし、ブラウザを丸ごと起動するため動作は遅い。数十件のテストなら問題にならないが、数千件を回すとなると実行時間がボトルネックになる。
テスト自動化における役割
Seleniumが最も多く使われているのはE2Eテスト、つまりエンドツーエンドテストの領域である。ユーザーがログインしてフォームに入力し、送信ボタンを押して確認画面が表示される。この一連の操作をスクリプトで再現し、期待通りの画面が出るかを自動で検証する。
リグレッションテストとの相性がいい。新機能を追加するたびに過去の機能が壊れていないかを確認する作業は、人手では限界がある。Seleniumで書いたテストスイートをCI/CDパイプラインに組み込めば、コードをプッシュするたびに自動で確認が走る。
とはいえ、Seleniumのテストは壊れやすい。画面のHTML構造が少し変わっただけで要素を見つけられなくなり、テストが失敗する。このメンテナンスコストを嫌って、後述するPuppeteerやPlaywrightに移行するチームも増えている。
WebスクレイピングとAIデータ収集
Seleniumのもう1つの用途がWebスクレイピングである。JavaScriptで動的にコンテンツを読み込むWebサイトは、単純なHTTPリクエストではデータを取得できない。ブラウザを実際に動かしてレンダリング後のHTMLを取得する必要があり、ここでSeleniumが使われる。
機械学習の学習データを集める場面でも、求人サイトやニュースサイトからSeleniumで情報を抽出し、前処理してデータセットに変換するパイプラインは珍しくない。
ただし、スクレイピングは法的なグレーゾーンが広い。利用規約で禁止しているサイトも多く、アクセス頻度が高すぎれば不正アクセスとみなされるリスクもある。技術的にできることと、やっていいことは別の話である。
Puppeteerとの使い分け
Seleniumと比較されることが多いのがGoogleのPuppeteerである。PuppeteerはChromium系ブラウザに特化しており、Chrome DevTools Protocolを直接叩くため、Seleniumより動作が速い。
Seleniumの強みはマルチブラウザ対応と言語の選択肢にある。企業のQAチームがJavaで統一されている場合、PuppeteerのJavaScript縛りは採用しづらい。逆に、Chromeだけでよくて速度を重視するなら、Puppeteerのほうが合理的である。
Microsoftが開発したPlaywrightは両者のいいとこ取りを狙っており、マルチブラウザ対応と高速な動作を両立している。新規プロジェクトではPlaywrightを選ぶチームが増えているが、既存のSeleniumテスト資産を一気に移行するのは現実的ではない。
当社の見解
当社はOpenAI APIを完全廃止し、EmbeddingもLLMも全てローカルで稼働させている（2026年4月時点）。これにより月額のAPI費用がゼロになっただけでなく、機密情報や顧客データを外部に送信せずにAI処理できるようになった。クライアントのログデータをマスキングなしでそのまま分析に回せるのは、ローカルLLMだからこそ実現できる。2026年4月にはOllama常駐実行（CPU 25%、GPU 30%を常時占有）を廃止し、FastEmbed（ONNX Runtime）による非常駐型推論に移行。処理が必要な瞬間だけプロセスを起動し、完了後に即座に終了する設計で、アイドル時のリソース消費をゼロにした。あえて一般的なデスクトップPC環境で複数のローカルLLMを実機検証した経験から言えることは、ベンチマークスコアと実務での使い勝手、そして常駐時のリソース消費は全て別の指標だということだ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。