BrowserStackとは？Playwright連携の設定手順と料金・自前端末との判断

BrowserStackは、実機のスマートフォンと実際のブラウザをクラウド経由で貸し出し、Webサイトやアプリのテストを流せるサービスです。公式の料金ページでは、3,500を超えるブラウザとOSの組み合わせと、35,000台を超える実機が挙げられています。この記事では、製品ごとの役割、既存のPlaywrightテストをNode.js SDKで載せる手順、社内の検証環境を確かめるLocalトンネルとGitHub Actionsの設定、2026年10月29日時点の料金と並列数の決め方を順に扱います。最後に示すのは、契約すべき案件とPlaywright単体で足りる案件を分ける具体的な条件です。

まとめ：BrowserStackを契約する案件と自前のPlaywright実行で足りる案件

契約する価値が出るのは、iPhoneの実機Safariや、Windowsの特定版のEdgeといった「手元に無い環境」での動作を、納品条件や利用規約で保証しなければならない案件です。PlaywrightのWebKitは実機Safariそのものではありません。この差を埋める手段として、BrowserStackは端末を買わずに済む選択肢になります。

反対に、社内利用でChromeとEdgeしか使わない業務システムなら、Playwright単体をCIで回せば足ります。既存のテストはnpx browserstack-node-sdkを前に付けるだけで載せられるため、まずはPlaywrightでテストを書き、保証すべき環境が増えた段階で契約を検討する順番が、費用の無駄を生みません。

BrowserStackの製品構成と実機・実ブラウザで検証できる範囲の整理

BrowserStackは単一の製品ではなく、手動テスト、自動テスト、アプリ向け、見た目の差分検出などに分かれた製品群です。契約の単位も製品ごとなので、何を買うかを先に決めます。

Live・Automate・App Automate・Percyの4製品と用途の切り分け

Webの開発で検討に上がるのは主に次の4製品です。

AutomateではPlaywright・Selenium・Cypressのテストを流し、App AutomateではAppiumやEspressoでネイティブアプリを検証します。Webシステムの受託開発で費用対効果が高いのはAutomateです。Liveは不具合報告の再現確認に便利ですが、毎回の手作業が残ります。Percyが担う見た目の差分検出は、VRT（ビジュアルリグレッションテスト）の仕組みとPlaywright実装で解説した方法でも自前で組めます。

Playwright同梱のWebKitと実機Safariで結果が分かれる理由

BrowserStackを検討する一番の理由がここにあります。Playwrightの公式ドキュメントは、PlaywrightのWebKitはWebKitの最新の開発版から作られ、Appleのブランド版Safariでは動かないと明記しています。つまり手元でwebkitのテストが通っても、利用者のiPhoneのSafariで同じ結果になる保証はありません。

BrowserStackのPlaywright対応表では、iOSは全版が対象に含まれています。ブランド版のChromeとEdgeはchrome・edge、Playwright同梱版はplaywright-webkitなどの値で指定し分けます。入力欄の日本語変換や、iOSのSafari特有の100vhのずれのように、実機でしか出ない不具合を拾えるかどうかが判断の分かれ目です。

PlaywrightをNode.js SDKでBrowserStackへ載せる手順

ここからは、Playwrightのテストが手元で動いている前提で進めます。Playwright自体の仕組みはPlaywrightの仕組みとSeleniumとの違いを参照してください。手順は公式の統合ガイドに沿っています。

認証情報の環境変数とbrowserstack-node-sdkのインストール

前提はNode.js 16.20.1以上です。ユーザー名とアクセスキーは、BrowserStackのアカウント設定で確認できます。npm registryの記録では、2026年10月29日時点のSDKの最新版は10月27日公開の1.76.0でした。

# 認証情報を環境変数に入れる（macOS・Linux）
export BROWSERSTACK_USERNAME="YOUR_USERNAME"
export BROWSERSTACK_ACCESS_KEY="YOUR_ACCESS_KEY"

# SDKを入れて設定ファイルを生成する
npm i -D browserstack-node-sdk@latest
npx setup --username "$BROWSERSTACK_USERNAME" --key "$BROWSERSTACK_ACCESS_KEY"

# 普段のテストコマンドの前にSDKを付けて実行する
npx browserstack-node-sdk playwright test

npx setupを実行すると、プロジェクトの直下にbrowserstack.ymlが作られます。テストのコードそのものは書き換えません。実行先を切り替えるのはSDKの役目です。

WindowsのChromeとmacOSのWebKitを設定ファイルで並列指定

どの環境で流すかはplatformsに並べます。キーの名前と値はCapabilitiesの一覧にある設定例と同じ形式です。認証情報を環境変数に入れていれば、userNameとaccessKeyは省けます。

# browserstack.yml：3環境×各1並列＝同時に3セッション
framework: playwright
projectName: order-system
buildName: e2e-regression
platforms:
  - os: Windows
    osVersion: 11
    browserName: chrome
    browserVersion: latest
  - os: Windows
    osVersion: 11
    browserName: edge
    browserVersion: latest
  - os: OS X
    osVersion: Sequoia
    browserName: playwright-webkit
parallelsPerPlatform: 1
browserstackLocal: false
debug: false
networkLogs: false
consoleLogs: errors

同時に動くセッション数は、環境の数×parallelsPerPlatformです。上の例で同時に動くセッション数は、3環境×1で3本です。契約した並列数を超えた分は待たされるので、ここは料金プランの並列数と揃えます。失敗したテストの動画とログは、何も指定しなくても標準で残ります。

Playwrightのクライアント版と対応表の最上段1.63を合わせる

見落としやすいのが版のずれです。2026年10月29日時点で、npmの@playwright/testの最新は1.64.1でした。一方、BrowserStackの対応表の最上段は1.63です。対応表のページは、ブラウザ版を指定しない場合はクライアントと同じPlaywright版を使うと説明しています。

対応できるのは各2版で、browserstack.playwrightVersionに1.latestか1.latest-1を指定して選びます。手元のPlaywrightを上げた直後にクラウド側だけ失敗し始めたら、まず版の組み合わせを疑ってください。CIではpackage.jsonの版を固定し、対応表に載った版へ上げる運用が安全です。版の確認方法はPlaywrightの最新バージョンと更新方法にまとめています。

社内環境やlocalhostをBrowserStack Localのトンネルで検証する設定

BrowserStackの端末はインターネットの向こう側にあります。開発中のlocalhostや、社内ネットワークにしか無い検証環境には、そのままでは届きません。この問題を解決するのがBrowserStack Localです。

browserstackLocalの有効化と–force-localで外部解決を止める

Localテストのガイドによると、SDKを使う場合はbrowserstack.ymlのbrowserstackLocalをtrueにするだけです。SDKが手元のマシンとBrowserStackの間にトンネルを張り、クラウド側のブラウザからhttp://localhost:4173のようなURLを開けるようになります。

社内規程で外部経由の名前解決を禁じている場合は、Localバイナリのフラグ一覧にある--force-localを使います。この指定では、すべてのURLの解決経路がトンネル経由に固定される仕組みです。プロキシの内側なら--proxy-hostと--proxy-portを加えます。複数のトンネルを同じアクセスキーで同時に張る場合は、--local-identifierで名前を分けないと、テストが別のトンネルに流れて不安定になります。

GitHub ActionsのSecretsから認証情報を渡すワークフロー例

CIでは、認証情報をリポジトリのSecretsに置き、環境変数として渡します。BrowserStack公式のGitHub ActionsもSecretsの名前をBROWSERSTACK_USERNAMEとBROWSERSTACK_ACCESS_KEYにする前提です。次の例は、ランナー上でビルドしたアプリを起動し、browserstackLocal: trueにした設定でテストを流します。

# .github/workflows/e2e-browserstack.yml
name: e2e-browserstack
on: [pull_request]
jobs:
  e2e:
    runs-on: ubuntu-latest
    env:
      BROWSERSTACK_USERNAME: ${{ secrets.BROWSERSTACK_USERNAME }}
      BROWSERSTACK_ACCESS_KEY: ${{ secrets.BROWSERSTACK_ACCESS_KEY }}
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 22
      - run: npm ci
      - run: npm run build
      - run: npx vite preview --port 4173 &
      - run: npx --yes wait-on http://localhost:4173
      - run: npx browserstack-node-sdk playwright test

トンネルの起動と停止はSDKが受け持つため、公式のActionsのsetup-localは使っていません。Seleniumなど、SDKを通さずにトンネルを張る構成ではsetup-localで起動し、テスト後にlocal-testing: stopで止めます。Secretsの置き場所と漏えい経路はGitHub ActionsのSecrets管理で扱っています。

料金プランの実額と並列数の決め方・自前デバイス運用との費用比較

料金は製品と並列数で決まります。以下は2026年10月29日に公式の料金ページで確認した、年払いの月額換算です。

Automate月額99ドルからの価格帯と並列数で増える費用の構造

Automateは1並列ごとの契約で、選択肢は1・2・5並列と、5並列超の営業窓口です。実機のiPhoneを含めて1並列で回すと、下限となる費用は年に2,100ドル（175ドル×12か月）です。並列数を決めるときは、テスト1本の所要時間×本数÷許容できる待ち時間で必要数を出し、そこから1つ引いた数で試すと過剰契約を避けられます。CIの実行時間そのものの費用はGitHub Actionsの料金と無料枠も合わせて見積もります。

端末購入・OS更新・保管を自社で抱える場合の運用コストとの比較

自前で端末を揃える場合、費用は購入代金だけで終わりません。iOSのメジャー更新は年1回あり、旧版のOSを残した端末と新版の端末を並べて持つ必要が出ます。充電、保管、紛失時の管理、Mac上のビルド環境の保守も社内の誰かが担います。

比べるべきは「保証すべき環境の数」です。iPhoneとAndroidの実機を合わせて3〜4台までで、版を固定してよい案件なら自前でも運用できる範囲です。保証範囲が「直近2版のiOSとAndroid、Windowsの3ブラウザ」のように広がった時点で、端末を揃える手間がAutomateの年額を上回ります。モバイルアプリの実機テストならFirebase Test Labの課金単位とCI組み込みも比較の候補になります。

BrowserStackを採用すべき条件と契約を見送るべき開発現場の判断

判断の軸は、保証すべきブラウザと端末の範囲が、手元とPlaywright同梱ブラウザで再現できるかどうかです。

iOS実機Safariや旧版ブラウザの保証が契約に入る案件は採用

BrowserStackを採用するのは、次のいずれかに当たる案件です。一般利用者が使うECサイトや予約サイトで、iPhoneのSafariからの利用が多い。発注者の動作保証表に、Windows版Edgeの特定版や、macOSの複数版が並んでいる。障害の報告が「ある機種でだけ崩れる」形で届き、手元で再現できない。いずれも、PlaywrightのWebKitでは代替できない領域です。

導入するときは、全テストを載せずに、決済や会員登録などの止まると損失の出る導線だけをBrowserStackで流します。テストピラミッドの配分で言えば上層のごく一部です。残りのE2Eは手元のPlaywrightで回し、並列数を抑えます。

Chromium中心の社内システムはPlaywright単体で足りる見送り例

見送るのは、利用者が社員だけで、会社支給のPCのChromeかEdgeしか使わない業務システムです。PlaywrightのChromiumとchannel: 'msedge'の指定で十分に確認でき、月額99ドルからの費用を払う理由がありません。テストがまだ数本しか無い段階での契約も早すぎます。テストが揃わないうちに実行環境だけ増やしても、失敗の原因がテストの不備か環境差かを切り分けられないからです。

CIへのテスト組み込みや、どこまでをクラウドの実機に任せるかの線引きから整えたい場合は、DevOps・CI/CD導入支援で、テスト自動化とGitHub Actionsの構成を含めて相談を受け付けています。

BrowserStackの導入前に確認される無料枠・連携・運用のよくある質問

導入を検討する段階でよく出る質問を5つ取り上げます。

BrowserStackは無料で使えますか？

有料が基本ですが、無料で使える枠が2つあります。1つは新規登録時の無料トライアルです。もう1つはオープンソース向けのプログラムで、公開されているOSSのプロジェクトなら全製品を無期限で無償利用できると案内されています。最も安い有料プランは個人向けのFreelancerで、年払いなら月12.50ドル、月払いなら19ドルです。ただしLiveの100分だけが対象で、自動テストは含まれません。業務で使う場合はAutomateの契約が前提になります。

PlaywrightのテストコードをBrowserStack用に書き換える必要はありますか？

Node.js SDKを使う場合、テストコードの書き換えは要りません。実行コマンドの前にnpx browserstack-node-sdkを付け、実行環境の指定先はbrowserstack.ymlです。手元での実行は従来どおりnpx playwright testで動くため、ローカルとクラウドを同じコードで切り替えられます。注意点はPlaywrightの版で、対応表に載っていない新しい版を使うとクラウド側で失敗することがあります。

SeleniumやCypressのテストも動かせますか？

はい、自動テストの実行が可能です。Automateが対応するのはPlaywrightのほかに、Selenium、Cypress、Puppeteerなどです。SeleniumのテストはE2Eテストのツール選定で比べたような既存資産が多く、リモートのWebDriverとして接続先を切り替える形で載せられます。ただし、Chrome for Testingを指定するchromefortestingはCypressとPuppeteerでは使えないと対応表に記載があります。フレームワークごとに使える指定値が違うため、公式の一覧で確かめてから設定してください。

失敗したテストの原因はあとから確認できますか？

はい、実行後にも原因を確認できる仕組みです。統合ガイドによると、標準でセッションのログ、失敗したコマンドの動画、テスト全体の動画が残ります。設定ファイルでdebug: trueにすると操作ごとのスクリーンショットが、networkLogs: trueにすると通信のHARログが加わります。ブラウザのコンソールログはconsoleLogsで出力の水準を選べ、既定はerrorsです。CIで失敗したときは、ビルド名で絞り込んで該当セッションの動画を見るのが早道です。

BrowserStackとFirebase Test Labはどう使い分けますか？

対象が違います。Firebase Test LabはAndroidとiOSのネイティブアプリをテストするサービスで、Webサイトのクロスブラウザテストは主な用途ではありません。BrowserStackが製品として提供するのは、Webのブラウザテストとアプリのテストの両方です。Webシステムで実機のSafariやEdgeを確かめたいならBrowserStack、Flutterなどのアプリの実機テストだけならFirebase Test Labも候補になります。アプリの自動化そのものはAppium 3でのモバイルテスト自動化が参考になります。

関連記事

• Playwright（プレイライト）とは？仕組み・できること・Seleniumとの違いを解説：BrowserStackに載せる前のテストを書くための基礎です
• Firebase Test Labとは｜実機と仮想端末の課金単位とCI組み込みの設計【2026年8月時点】：アプリの実機テストを別サービスで組むときの比較対象です
• VRT（ビジュアルリグレッションテスト）とは？仕組み・ツールの選び方とPlaywright実装：Percyを契約せずに見た目の差分を検出する方法です
• Cypress E2Eテストの使い方｜インストールからcy.intercept・CI実行まで【Cypress 16対応】：Cypressで書いたテストをCIで回す手順を補えます
• GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準：BrowserStackと合わせたCI全体の費用を見積もるときに使えます