Applitoolsとは？Playwrightへの組み込み手順と料金・差分検知の閾値運用

Applitoolsは、テスト中に撮った画面をAIで基準画像と比べ、人の目で見て違うと分かる差分だけを不具合候補として挙げるビジュアルテストの基盤です。中心の製品はEyesで、PlaywrightやCypress、Selenium、Storybookのテストに数行を足して使う仕組みです。この記事では、Playwrightへの組み込み手順とeyes.checkのコード例、差分検知の閾値を決めるマッチレベルの使い分け、Ultrafast GridとGitHub Actionsの設定、2026年11月2日時点の料金を順に扱います。最後に、Playwright標準の画面比較やChromaticで足りる案件との分かれ目を示します。

まとめ：Applitoolsを選ぶ案件とPlaywrightの画面比較で足りる案件

Applitoolsが向くのは、検証する画面が数百枚あり、ブラウザや画面幅の組み合わせごとに表示崩れを見張る必要がある業務システムやECサイトです。Playwright標準のtoHaveScreenshotはピクセル単位で比べるため、OSやフォントの描画差で誤検知が増えます。Applitoolsは比較の厳しさをマッチレベルで段階的に選べるので、誤検知を抑えたまま回帰を拾えます。

一方、対象が数十枚の画面でブラウザがChromeだけなら、年払いで月667ドルからの費用に見合いません。Playwright単体の画面比較で始め、誤検知の手間が増えてから移る順番で十分です。Storybookのコンポーネントだけを見張るならChromaticも比較候補に入ります。

ApplitoolsのVisual AIとピクセル比較の違い・製品構成と対応SDK

Applitoolsを評価するときは、何を比べる製品なのかを先に押さえます。ブラウザや実機を貸し出すSauce LabsやBrowserStackとは役割が違います。

Eyes・Ultrafast Grid・Autonomousで分かれる製品の役割と範囲

実装者が触るのは主にEyesとUltrafast Gridの2つです。

Eyesは差分を判定する側で、テストの実行はPlaywrightなど既存のフレームワークに任せます。SDKはJavaScript、Java、Python、Ruby、.NETで提供されています。npm registryの記録では、Playwright用の@applitools/eyes-playwrightは2026年11月1日公開の1.51.6が最新です。ライセンス欄はSEE LICENSE IN LICENSEで、OSSのライセンスではありません。SDKは無償で入りますが、比較を実行するにはApplitoolsのアカウントとAPIキーが必要です。

ピクセル一致のtoHaveScreenshotと人の目基準のVisual AIの判定差

Playwrightの画面比較は、比較にpixelmatchを使います。色の許容差thresholdの既定は0.2で、基準画像のファイル名に含まれるのはブラウザとOSです。公式ドキュメントは、描画がホストのOSやハードウェアで変わるため、基準画像を作った環境と同じ環境で流すよう求めています。macOSで作った基準をLinuxのCIで比べると、フォントのにじみだけで失敗します。

Applitoolsは比較をクラウド側で行い、人の目で見て分かる違いかどうかで判定します。描画のわずかな揺れは無視し、ボタンの欠落や文字の重なりは差分として残す設計です。ピクセルを数える方式と、見た目の意味を比べる方式の差が、導入を検討する理由になります。VRTの仕組み全体はVRT（ビジュアルリグレッションテスト）の仕組みとPlaywright実装で整理しています。

Playwrightの既存テストにEyesのSDKを組み込む設定と実行手順

ここからは、Playwrightのテストが手元で動いている前提で、@applitools/eyes-playwrightを組み込む手順を進めます。Playwright自体の仕組みはPlaywrightの仕組みとSeleniumとの違いを参照してください。

npx eyes-setupによるSDKの導入とAPIキーを環境変数で渡す設定

PlaywrightのQuick Startは、フィクスチャ方式を@applitools/eyes-playwright1.32.0以上向けとしています。APIキーは設定ファイルに書かず、環境変数で渡す形が推奨されています。

# SDKを入れる
npm install -D @applitools/eyes-playwright

# 設定とimportの書き換えを自動で行う
npx eyes-setup

# APIキーは環境変数で渡す（macOS・Linux）
export APPLITOOLS_API_KEY="YOUR_API_KEY"

# 実行とレポート表示
npx playwright test
npx playwright show-report

公式のサンプルはGitHubのexample-eyes-playwright-fixtureで公開されています。手元で一度通してから自社のテストへ移すと、設定の抜けを切り分けやすくなります。

eyes.checkで全画面と要素単位のチェックポイントを書くコード例

テストファイルでは、testの読み込み元をApplitoolsのフィクスチャに変えます。Integration with Playwrightのページに沿った設定とテストの例です。

// playwright.config.ts
import { defineConfig } from '@playwright/test';
import { EyesFixture } from '@applitools/eyes-playwright/fixture';

export default defineConfig<EyesFixture>({
  reporter: '@applitools/eyes-playwright/reporter',
  use: {
    eyesConfig: {
      appName: 'order-system',
      failTestsOnDiff: 'afterAll',
    },
  },
});

// tests/order.spec.ts
import { test } from '@applitools/eyes-playwright/fixture';

test('order list layout', async ({ page, eyes }) => {
  await page.goto('https://staging.example.com/orders');
  // 画面全体を比較し、更新日時の列だけ比較から外す
  await eyes.check('Order list', {
    fully: true,
    matchLevel: 'Strict',
    ignoreRegions: [page.locator('.updated-at')],
  });
  // ヘッダーだけを要素単位で比較する
  await eyes.check('Header', {
    region: page.locator('header'),
    matchLevel: 'Layout',
  });
});

failTestsOnDiffには'afterEach'・'afterAll'・falseを指定できます。'afterEach'はテストごとに失敗させ、'afterAll'は全テストの比較を終えてからまとめて失敗させます。差分が1つ出ただけで残りの画面を撮り損ねないよう、回帰テストでは'afterAll'から始めるのが扱いやすい設定です。

初回実行でのベースライン作成と画面差分の承認・却下を回す運用の流れ

初回の実行で撮った画面がベースラインになり、2回目以降はその画面と比べます。差分が出たときにApplitoolsのダッシュボードで選ぶのは、差分ごとの承認か却下です。承認した画面が新しいベースラインになり、却下した差分は不具合として残ります。

運用で決めておくのは承認者です。デザイン変更のたびに開発者が独断で承認すると、崩れた画面がそのまま基準になります。画面の仕様を持つ人を承認者に決め、プルリクエストのレビューと同じ扱いにします。

マッチレベルと領域指定で画面ごとの差分検知の閾値を調整する運用設計

Applitoolsの誤検知と見逃しは、マッチレベルの選び方でほぼ決まります。Match Levels and Regionsのページに沿って整理します。

画面全体と動的な領域に指定するマッチレベル5段階の判定基準と使い分け

5段階はStrict・Layout・Ignore Colors・Exact・Dynamicです。実務でまず決めるのは、ページ全体をStrictにすることです。公式も、動的な要素を含むダッシュボードでは全体をStrictにし、変わる部分だけをLayoutの領域にする形を推奨しています。Exactは人の目に見えない描画差まで拾うため、ピクセル比較の誤検知をそのまま持ち込みます。

既定がDynamicに変わったSDK版と古い版で結果が揃わない落とし穴

見落としやすいのが既定値の変更です。同じページには、Webテストの既定のマッチレベルが、対応するSDK版以降でDynamicになると書かれています。JavaScriptのSDKでは、eyes-playwrightが1.47.5、eyes-cypressが3.60.3、eyes-storybookが3.65.5からです。

マッチレベルを書かずにeyes.checkを呼んでいると、SDKを上げた時点で判定の基準が変わります。複数のリポジトリで版が揃っていないと、同じ画面でも結果が食い違います。eyesConfigかeyes.checkでmatchLevelを必ず明示し、SDKの更新を判定基準の変更として扱ってください。Playwright本体の版を確かめる手順はPlaywrightの最新バージョンと更新方法にまとめています。

Ignore領域を最終手段にしてLayout領域で日付や広告枠を逃がす設定

誤検知が出たとき、該当箇所をIgnore領域にして済ませたくなります。公式はIgnore領域を最終手段と位置づけ、多くはLayout領域かIgnore Colors領域で対処できるとしています。Ignoreにした範囲は、要素が消えても検知されないためです。

領域は座標ではなく、page.locator()で要素を指定します。要素で指定すれば、位置がずれてもEyesが同じ要素を追えます。日付や件数のように文字だけが変わる箇所はDynamic、カルーセルや広告枠のように中身が入れ替わる箇所はLayout、と分けるのが基本の型です。動く要素にはfloatingRegionsも使えます。

Ultrafast GridとGitHub Actionsで複数ブラウザを検証する構成

Ultrafast Gridを使うと、手元のブラウザで1回撮った画面を、クラウド側で複数のブラウザと画面幅に描画し直して比べられます。

browsersInfoでデスクトップとiPad・Pixelの描画を一度に取る設定

Advanced Usageのページでは、type: 'ufg'とbrowsersInfoで描画先を並べます。API Overviewによると、typeは'ufg'か'classic'のどちらかです。

// playwright.config.ts（Ultrafast Grid）
export default defineConfig<EyesFixture>({
  use: {
    eyesConfig: {
      type: 'ufg',
      testConcurrency: 5,
      matchLevel: 'Strict',
      browsersInfo: [
        { name: 'chrome', width: 1440, height: 900 },
        { name: 'firefox', width: 1440, height: 900 },
        { iosDeviceInfo: { deviceName: 'iPad (7th generation)' } },
        { chromeEmulationInfo: { deviceName: 'Pixel 4 XL' } },
      ],
    },
  },
});

同じページは、Ultrafast Gridではブラウザのプロジェクトを1つにし、playwright.configの余分なプロジェクトを消すよう推奨しています。Playwright側でChromeとFirefoxのプロジェクトを並べたままだと、同じ画面を二重に送ることになります。描画の画面幅はbrowsersInfoで決まるので、viewportの設定は手元の実行にしか効きません。iosDeviceInfoはiPadの描画を再現するもので、実機での動作確認とは別物です。実機が要る案件はBrowserStackのPlaywright連携やSauce Labsのsaucectlの設定と組み合わせます。

APPLITOOLS_BATCH_IDで並列ジョブの結果を1バッチにまとめる設定

GitHub Actions連携の公式ページは、APIキーをSecretsから渡し、APPLITOOLS_BATCH_IDにコミットのSHAを入れる形を示しています。プルリクエストでは、ソースブランチの最後のコミットのSHAを使います。

# .github/workflows/visual.yml
name: visual
on: [pull_request]
env:
  APPLITOOLS_API_KEY: ${{ secrets.APPLITOOLS_API_KEY }}
  APPLITOOLS_BATCH_ID: ${{ github.event.pull_request.head.sha || github.sha }}
jobs:
  visual:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 24
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test

既定では、ビルドが終わるとGitHub連携がバッチを自動で閉じます。テストを複数のジョブに分けて並列で流す場合は、自動クローズを止め、全ジョブをneedsで待つ後続ジョブからバッチの完了を通知する構成が公式に示されています。通知の書き方は公式ページの例に合わせてください。Secretsの置き場所はGitHub ActionsのSecrets管理で扱っています。

料金プランの課金単位とChromatic・自前VRTとの費用の比較

以下は2026年11月2日に公式の料金ページで確認した内容です。

Starter月額667ドルのチェックポイント上限と上位プランの違い

表の判定回数はチェックポイント、有効ページはactive pages、部品はcomponentsを指します。3プランともユーザー数は無制限で、費用はチェックポイントか対象ページの数で決まります。Starterの上限は、画面全体ならページのチェックポイント1,000、部品単位ならコンポーネントのチェックポイント100,000のどちらかです。eyes.checkの呼び出し回数とブラウザの組み合わせ数が消費に効くため、Ultrafast Gridで描画先を4つ並べると消費も増えると見て見積もります。チェックポイントの数え方と、上限を超えた場合の扱いは料金ページに書かれていません。契約前に営業窓口で確かめてください。無料トライアルの入口はありますが、期間と上限の記載もありません。

Storybook中心ならChromatic、少数画面ならPlaywright単体の判断

Storybookのコンポーネントだけを見張るなら、Storybookの開発元が提供するChromaticが先に候補になります。料金の数え方とTurboSnapで消費を抑える方法はChromaticの料金と課金スナップショットの計算で解説しています。Storybook自体の導入はStorybookの使い方と導入手順を参照してください。

画面数が少なく、CIのOSとブラウザを1つに固定できるなら、PlaywrightのtoHaveScreenshotで費用はかかりません。Sauce Labsのように、テスト実行のプランにビジュアルテストの枠が含まれるサービスもあります。Applitoolsの月667ドルは、誤検知の確認にかかる人の時間がそれを上回ってから払う費用です。

Applitoolsを採用する案件の条件と導入を見送る場面の判断基準

判断の軸は、見張る画面とブラウザの組み合わせの数と、表示崩れが漏れたときの損失の大きさの2つです。

画面数が多く表示崩れの見落としが損失に直結する業務システムは採用

採用するのは、数百画面の業務システムやECサイトで、ChromeとSafari、PCとタブレットの組み合わせごとに表示を保証する案件です。共通のCSSやデザインシステムを1か所変えると多数の画面に波及するため、人の目視では追い切れません。Ultrafast Gridなら、1回のテスト実行で複数の描画先を比べられます。

載せる画面は、注文確定や請求書の出力など、崩れると業務が止まる画面から始めます。テストピラミッドの配分で言えば上層の一部です。どの画面をどのブラウザで見張るか、CIのどの段階で流すかの線引きから整えたい場合は、DevOps・CI/CD導入支援で、テスト自動化とGitHub Actionsの構成を含めて相談を受け付けています。

対象画面が数十枚で利用するブラウザが1種類だけの社内ツールは導入を見送る

見送るのは、利用者が社員だけでChromeしか使わない、画面数が数十枚の社内ツールです。CIをLinuxのコンテナに固定すれば、Playwrightの画面比較でも描画差による誤検知は抑えられます。もう1つは、画面の大半が毎回変わるデータで埋まり、Layout領域だらけになる画面です。構造しか比べないなら、DOMの構造を比べるテストのほうが安く済みます。この場合はスナップショットテストの実装と更新運用を先に検討してください。

Applitoolsの導入前に確認される無料枠・連携・設定のよくある質問

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

Applitoolsは無料で使えますか？

料金ページにあるのは有料の3プランと無料トライアルの入口で、常時無料のプランは載っていません。トライアルの期間や上限もページに書かれていないため、登録時の画面で条件を確かめてください。SDK自体はnpmなどから無償で入りますが、比較の実行にはApplitoolsのアカウントとAPIキーが要ります。継続して使う場合の入口は、年払いで月667ドルのStarterです。

Playwright以外のテストツールでも使えますか？

Playwright以外のテストツールでも利用可能です。JavaScriptではSelenium、Cypress、WebdriverIO、Puppeteer、Nightwatch、TestCafe、Storybook向けのSDKが、マッチレベルの公式ページに版番号つきで並んでいます。JavaやPython、Ruby、.NETのSDKもあります。どのSDKも、既存のテストの途中に画面の比較処理を足す形は共通です。テストツール自体を選ぶ段階なら、まずPlaywrightかCypressかを決め、そのあとでApplitoolsを足すかを判断します。

差分が出たときはどこで確認して承認しますか？

Applitoolsのダッシュボードで、ベースラインと今回の画面を並べて確認します。選択する操作は、意図した変更なら承認、不具合なら却下です。Playwrightではreporterに@applitools/eyes-playwright/reporterを指定すると、npx playwright show-reportのレポートにも結果が載ります。承認した画面が次回以降の基準になるため、事前に決めておく必要があるのは承認者です。

Ultrafast Gridを使えば実機テストは不要になりますか？

不要にはなりません。Ultrafast Gridは、撮影した画面をクラウドのブラウザやiPadなどの設定で描画し直して見た目を比べる仕組みです。タップの反応や実機固有の挙動は確かめられません。実機の確認は、料金ページによるとEnterpriseのオプションか、BrowserStackやSauce Labsの実機クラウドで行います。見た目の差分はApplitools、動作は実機クラウド、と役割を分けて組みます。

Playwrightの版を上げてもApplitoolsのSDKは動きますか？

npm registryの記録では、@applitools/eyes-playwright1.51.6は@playwright/test1.0.0以上を相手に取る設定です。2026年11月2日時点のPlaywright最新版1.64.1も範囲に入ります。注意したいのはApplitools側のSDKの更新です。1.47.5を境に既定のマッチレベルがDynamicに変わっているため、SDKを上げる前にmatchLevelが明示されているかを確かめてください。

関連記事

• VRT（ビジュアルリグレッションテスト）とは？仕組み・ツールの選び方とPlaywright実装：Applitoolsを含むVRTの仕組みとツール選びの全体像です
• Chromaticとは？料金と課金スナップショットの計算・Storybook導入とTurboSnap設定：Storybook中心のビジュアルテストで比べるべき製品です
• Sauce Labsとは？saucectlの設定手順と料金・BrowserStackとの選び分け：WindowsとmacOSのブラウザでテストを流す実行基盤です
• BrowserStackとは？Playwright連携の設定手順と料金・自前端末との判断：見た目の比較と組み合わせる実機テストの基盤です
• スナップショットテストとは？JestとVitestの実装と更新運用を実装者向けに解説：画面でなくDOMや値を比べる安価な代替手段です