Visual Regression Testing (VRT) 導入ガイド｜UIの変更を防ぎ、品質向上させる方法を解説

2026年2月3日

生徒

博士、Webサイトのデザインを修正したら、別のページのレイアウトが崩れてしまいました…。どうすれば防げますか？

ペン博士

よーく聞くんだぞ。それはまさにVisual Regression Testing（VRT）で解決できる問題なんじゃ！今回はVRTについて基本から実践まで詳しく解説するぞい！

生徒

ありがとうございます！よろしくお願いいたします！

Web制作において、コードの変更が意図しない視覚的な影響を及ぼすことは珍しくありません。CSSの修正が思わぬところでレイアウト崩れを引き起こしたり、コンポーネントの更新が他のページの表示に影響を与えたりすることがあります。

本記事では、Visual Regression Testing（VRT）の導入方法から主要ツールの比較、実践的な実装手順までを、実例を交えて詳しく解説します。VRTを導入することで、UIの品質を保ちながら、安心して制作を進められる環境を構築できます。

「学習→案件獲得」につなげた受講生のリアルな体験談も公開中！
働き方を変えたい方にも響くストーリーです。

橋本さん
将来に繋がるスキルを身に付けたいと考え、プログラミングに出会う。在学中の大学ではプログラミングの講義がなかったため、独学で学習していたが、限界を感じWithCodeに入学を決意。短期集中カリキュラムでプログラミング学習に打ち込んだ結果、見事卒業テストに合格し、案件を勝ち取りました。現在は、新たな言語の習得に向けて学習を継続しながら就職活動に向けて準備を行っています。

詳しくはこちらの記事をご覧ください。

橋本さんの主な制作実績はこちら

創業時の新規HP制作

株式会社hado 様

Visual Regression Testing（VRT）とは？

Visual Regression Testing（ビジュアルリグレッションテスト）は、アプリケーションの外観の変化を自動的に検出するテスト手法です。UIオートメーションでアプリケーションを操作し、画面のスクリーンショットを撮影して、ベースライン（基準となる画像）と比較することで、画素レベルの差分を検出します。

従来のテストとVRTの違い

従来のユニットテストやE2Eテストは、主に機能の動作を検証します。例えば、「ボタンをクリックしたら正しいページに遷移するか」「フォームに入力したデータが正しく送信されるか」といったロジックベースのテストです。

一方、VRTは視覚的な変更に焦点を当てます。以下のような問題を検出できます：

CSSの変更によるレイアウト崩れ
フォントサイズや色の意図しない変更
要素の位置ずれやオーバーラップ
レスポンシブデザインの崩れ
画像の表示崩れや欠落
モーダルやツールチップの表示不具合

VRTが必要な理由

現代のWeb制作では、以下のような課題があります：

コンポーネントの再利用性が高い：1つのコンポーネントが複数のページで使われるため、変更の影響範囲が広い
CSSのカスケーディング：CSSの変更が予期しない箇所に影響を及ぼす可能性がある
マニュアルテストの限界：すべてのページとデバイスサイズで目視確認するのは非効率
制作スピードの向上：迅速なデプロイには自動化されたテストが不可欠

VRTを導入することで、制作者が想定していない視覚的な変更を自動的に検出し、リリース前に修正できるようになります。

VRT導入のメリット

1. 安心して制作できる環境の構築

VRTの最大のメリットは、「安心できる」ことです。コードの変更が意図しない視覚的影響を及ぼしていないか、自動的に検証できるため、は安心してリファクタリングや新機能の追加ができます。

ロジックベースのテストだけでは、制作者の想定範囲外の問題をカバーできません。VRTは、人間の目視確認に近い方法でテストできるため、補完的な価値が非常に高いのです。

2. デグレーション（機能退行）の早期発見

コードベースが大きくなるほど、1つの変更が他の部分に与える影響を把握することが困難になります。VRTを導入することで、以下のようなデグレーションを早期に発見できます：

依存関係の更新による表示崩れ
CSSのリファクタリングによる副作用
コンポーネントの修正が他のページに与える影響
ブラウザアップデートによる表示の変化

3. レビュープロセスの効率化

VRTツールの多くは、差分画像を自動生成し、Pull Request（PR）に添付する機能を持っています。これにより、レビュアーは以下のメリットを得られます：

視覚的な変更を一目で確認：コードを読まなくても、UIの変更内容が分かる
デザイナーやPMとの連携：技術者以外のステークホルダーもレビューに参加できる
承認ワークフローの構築：意図的な変更と意図しない変更を明確に区別できる

4. 制作速度の向上

一見、テストを追加することは制作速度を低下させるように思えますが、実際には逆です。VRTを導入することで：

手動での目視確認の時間を削減
リリース後のバグ修正コストを削減
自信を持ってリファクタリングできる
チーム全体の生産性が向上

結果として、長期的には制作速度が大幅に向上します。

5. クロスブラウザ・クロスデバイステストの自動化

VRTツールの多くは、複数のブラウザやデバイスサイズでのテストをサポートしています。これにより、以下のようなテストを自動化できます：

Chrome、Firefox、Safariでの表示確認
モバイル、タブレット、デスクトップでのレスポンシブデザイン確認
異なる画面解像度での表示確認

主要なVRTツール比較

生徒

メリットは分かったんですけど、ツールはどれを選べばいいんでしょうか？

ペン博士

うむ。VRTを実現するツールは複数存在する。ここでは、現在主流となっている4つのツールを詳しく解説するぞ！

1. Playwright

Playwrightは、Microsoftが開発した汎用的なUIオートメーションツールで、VRT機能も備えています。

特徴

ベースラインをリポジトリに含められる：Gitで管理可能
クロスブラウザ対応：Chromium、Firefox、WebKitをサポート
詳細な差分表示：Diff、Actual、Expectedの3つの画像で差分を確認できる
無料で利用可能：オープンソースソフトウェア

実装例

// tests/example.spec.ts
import { test, expect } from '@playwright/test';
test('homepage visual regression test', async ({ page }) => {
  await page.goto('https://example.com');
  // ページ全体のスクリーンショットを撮影し、ベースラインと比較
  await expect(page).toHaveScreenshot('homepage.png');
});
test('button hover state', async ({ page }) => {
  await page.goto('https://example.com');
  // 特定の要素にホバーしてスクリーンショット
  await page.locator('button.primary').hover();
  await expect(page.locator('button.primary')).toHaveScreenshot('button-hover.png');
});

メリット

E2Eテストと統合して使える
外部サービスに依存しない
柔軟なカスタマイズが可能

デメリット

OS間の差分が発生する：開発環境（macOS/Windows）とCI環境（Linux）でフォントレンダリングが異なるため、Dockerでの環境統一が必要
差分レビューのUIが基本的
初期設定にやや手間がかかる

2. Storybook Test Runner

Storybook Test Runnerは、Storybookのストーリーに対してVRTを実行できるツールです。内部的にPlaywrightを使用しています。

特徴

Storybookとの統合が容易：既存のストーリーをそのままテストに使える
コンポーネント単位でテスト：ページ全体ではなく、コンポーネント単位での検証が可能
GitHub Artifactに対応：差分ファイルを自動的にアップロード

実装例

// .storybook/test-runner.ts
import { toMatchImageSnapshot } from 'jest-image-snapshot';
import type { TestRunnerConfig } from '@storybook/test-runner';
const config: TestRunnerConfig = {
  async postRender(page, context) {
    // ストーリーごとにスクリーンショットを撮影
    const image = await page.screenshot();
    expect(image).toMatchImageSnapshot({
      customSnapshotIdentifier: context.id,
    });
  },
};
export default config;

メリット

Storybookを使っていれば導入が簡単
コンポーネントの全バリエーションをテストできる
開発環境とテスト環境が統一される

デメリット

差分表示が見づらい：GitHub Artifactからダウンロードして確認する必要がある
Storybookの構築が前提となる
OS間の差分問題はPlaywrightと同様

3. Chromatic

Chromaticは、Storybookの開発チームが運営するフリーミアム型のSaaSサービスです。VRTツールの中で最も洗練されたUIと機能を提供しています。

特徴

ベースラインをクラウド管理：環境の違いによる差分問題が発生しない
優れたレビューUI：差分を視覚的に確認しやすい
コラボレーション機能：デザイナーやPMとのフィードバックワークフローを構築できる
自動ベースライン更新：承認した変更を新しいベースラインとして自動設定

実装例

# package.json
{
  "scripts": {
    "chromatic": "chromatic --project-token=<your-project-token>"
  }
}
# CI/CD (GitHub Actions)
- name: Run Chromatic
  uses: chromaui/action@v1
  with:
    projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
    token: ${{ secrets.GITHUB_TOKEN }}

料金プラン

Starter（無料）：月5,000スナップショットまで
Essential：月$149〜（より多くのスナップショットと高度な機能）
Professional：カスタム価格（エンタープライズ向け）

メリット

最も優れた操作性：差分の確認、承認、コメントが直感的
Docker構築不要：クラウドベースで環境の違いを吸収
チーム全体で使いやすい：非エンジニアも参加できる
PR統合が優れている：GitHubやGitLabと深く統合

デメリット

有料プランが必要になる可能性：大規模プロジェクトでは無料枠を超える
外部サービス依存：サービス停止のリスクがある
Storybookが前提：Storybookを使っていない場合は導入のハードルが高い

4. reg-viz (reg-suit / reg-actions)

reg-vizは、VRT用のOSSツール群を提供しているプロジェクトです。特にreg-suitとreg-actionsが人気です。

reg-suit

GitHub Actions + S3（またはGCS）を使って、Chromatic同等の機能を無料で実現できるツールです。

特徴：

S3にベースラインと差分レポートを保存
PRコメントで差分を確認できる
HTMLレポート生成

reg-actions

GitHub Artifactを活用したよりシンプルな構成のツールです。

特徴：

外部ストレージ不要（GitHub Artifactを使用）
セットアップが簡単
PRコメントで差分確認可能

実装例（reg-actions）

# .github/workflows/vrt.yml
name: Visual Regression Test
on: [pull_request]
jobs:
  vrt:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run visual regression test
        run: |
          npm run storybook:build
          npm run test:vrt
      - uses: reg-viz/reg-actions@v1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          image-directory-path: '__screenshots__'

メリット

完全無料で使える
外部サービスへの依存が少ない
柔軟なカスタマイズが可能

デメリット

UIがChromaticほど洗練されていない
reg-suitはS3/GCSの設定が必要
コラボレーション機能が限定的

ツール選択のガイドライン

ツール	最適な用途	コスト	難易度
Playwright	E2Eテストと統合したい	無料	中
Storybook Test Runner	Storybook中心の開発	無料	低
Chromatic	チーム全体での活用	無料〜有料	低
reg-viz	予算制約がある	無料	中〜高

VRT導入の実践ステップ

生徒

VRT導入は実際どうやって始めればいいんですか？

ペン博士

良い質問じゃ。ここでは、最も人気のあるChromatic + Storybookの組み合わせを例に、VRT導入の具体的なステップを解説するぞ！

ステップ1：Storybookのセットアップ

まず、プロジェクトにStorybookをインストールします。

インストール

# Storybookの自動セットアップ
npx storybook@latest init
# または手動でインストール
npm install --save-dev @storybook/react @storybook/react-vite

コンポーネントのストーリー作成

// src/components/Button/Button.stories.tsx
import type { Meta, StoryObj } from '@storybook/react';
import { Button } from './Button';
const meta: Meta<typeof Button> = {
  title: 'Components/Button',
  component: Button,
  tags: ['autodocs'],
};
export default meta;
type Story = StoryObj<typeof Button>;
// 基本的なボタン
export const Primary: Story = {
  args: {
    variant: 'primary',
    children: 'ボタン',
  },
};
// セカンダリボタン
export const Secondary: Story = {
  args: {
    variant: 'secondary',
    children: 'ボタン',
  },
};
// 大きいボタン
export const Large: Story = {
  args: {
    variant: 'primary',
    size: 'large',
    children: '大きいボタン',
  },
};

ポイント： テストしたいすべてのバリエーション（状態、サイズ、色など）をストーリーとして作成します。これらのストーリーがVRTのテスト対象になります。

ステップ2：Chromaticアカウントの作成

アカウント作成手順

1. Chromatic公式サイトにアクセスし、「Get started for free」をクリック

2. GitHubアカウントで認証

3. 新しいプロジェクトを作成

4. プロジェクトトークンを取得

Chromaticのインストール

# Chromaticパッケージをインストール
npm install --save-dev chromatic
# プロジェクトトークンを環境変数に設定
# .env.local
CHROMATIC_PROJECT_TOKEN=your_project_token_here

ポイント： プロジェクトトークンは機密情報なので、環境変数として管理し、Gitにコミットしないようにしてください。

ステップ3：初回のビルドとベースライン作成

Chromaticへのアップロード

# Storybookをビルドし、Chromaticにアップロード
npx chromatic --project-token=<your-project-token>
# または、package.jsonにスクリプトを追加
{
  "scripts": {
    "chromatic": "chromatic"
  }
}
# 実行
npm run chromatic

初回実行時には、すべてのストーリーのスクリーンショットが撮影され、ベースラインとして保存されます。これが今後の比較基準となります。

ベースラインの確認

Chromaticのダッシュボードで、撮影されたスクリーンショットを確認し、すべて承認（Accept）します。これにより、現在の状態が正式なベースラインとして設定されます。

ポイント： 初回のベースライン作成では、デザイナーやPMにもレビューしてもらい、意図した通りの表示になっているか確認することが重要です。

ステップ4：CI/CDパイプラインへの統合

Pull Requestごとに自動的にVRTを実行するように、CI/CDパイプラインに統合します。

GitHub Actionsの設定

# .github/workflows/chromatic.yml
name: Chromatic
on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - main
jobs:
  chromatic:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0  # Chromaticが変更履歴を追跡するために必要
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'
      - name: Install dependencies
        run: npm ci
      - name: Run Chromatic
        uses: chromaui/action@v1
        with:
          projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
          token: ${{ secrets.GITHUB_TOKEN }}
          onlyChanged: true  # 変更されたストーリーのみテスト
          exitZeroOnChanges: true  # 差分があってもビルドを失敗させない

GitHubシークレットの設定

1. GitHubリポジトリの「Settings」→「Secrets and variables」→「Actions」に移動

2.「New repository secret」をクリック

3. Name: CHROMATIC_PROJECT_TOKEN

4. Value: Chromaticのプロジェクトトークン

ポイント： onlyChanged: trueオプションを使うことで、変更されたストーリーのみをテストし、スナップショット数を節約できます。

ステップ5：ワークフローの運用

VRTを日常の制作ワークフローに組み込みます。

制作者のワークフロー

コードを変更：コンポーネントやスタイルを修正
ローカルで確認：Storybookで表示を確認（npm run storybook）
Pull Requestを作成：変更をプッシュしてPRを作成
VRTの実行を待つ：GitHub ActionsがChromaticを自動実行
差分を確認：PRに投稿されるChromaticのリンクから差分を確認
承認または修正：
- 意図的な変更の場合：Chromaticで「Accept」
- 意図しない変更の場合：コードを修正

レビュアーのワークフロー

PRを確認：コードレビューを実施
Chromaticリンクをクリック：視覚的な変更を確認
差分を評価：
- 意図的な変更か？
- デザインシステムに沿っているか？
- 他のコンポーネントに悪影響はないか？
フィードバック：Chromaticでコメントを残すか、PRでフィードバック

ベストプラクティス

小さな変更を頻繁にコミット：大きな変更は差分の確認が困難になる
ストーリーを充実させる：すべてのバリエーションをカバーするストーリーを作成
定期的にベースラインを更新：意図的な変更は速やかに承認してベースライン化
チーム全体で活用：デザイナーやPMもレビュープロセスに参加

VRT導入時の注意点とトラブルシューティング

生徒

VRTを導入するにあたってトラブルシューティングのことも知りたいです！

ペン博士

うむ。ここでは、主なトラブルシューティングを4つ紹介するぞい！

1. フォントレンダリングの違い

異なるOS間（macOS、Windows、Linux）でフォントのレンダリングが異なるため、意図しない差分が発生することがあります。

解決策

Chromaticを使用：クラウドベースなので環境の違いを吸収
Dockerを使用：Playwright使用時は、開発環境とCI環境を統一
Webフォントを使用：システムフォントではなく、Webフォントを使用

2. 動的コンテンツの扱い

現在時刻、ランダムなデータ、アニメーションなどの動的コンテンツは、毎回異なる結果になるため、常に差分として検出されてしまいます。

解決策

モックデータを使用：固定のデータでテスト
時刻を固定：テスト時は固定の日時を使用
アニメーションを無効化：テスト時はCSSアニメーションを無効化

// Storybookでアニメーションを無効化
// .storybook/preview.ts
export const parameters = {
  chromatic: {
    // アニメーションの完了を待つ
    delay: 300,
    // アニメーションを無効化するCSS
    disableAnimations: true,
  },
};

3. 外部APIへの依存

外部APIからデータを取得するコンポーネントは、APIの応答が変わるたびに差分が発生します。

解決策

MSW（Mock Service Worker）を使用：APIをモック化
静的なデータを使用：Storybook内では固定データを使用

// MSWでAPIをモック化
// .storybook/preview.ts
import { initialize, mswDecorator } from 'msw-storybook-addon';
initialize();
export const decorators = [mswDecorator];
// ストーリーでモックを定義
export const Default: Story = {
  parameters: {
    msw: {
      handlers: [
        rest.get('/api/users', (req, res, ctx) => {
          return res(
            ctx.json([
              { id: 1, name: '山田太郎' },
              { id: 2, name: '佐藤花子' },
            ])
          );
        }),
      ],
    },
  },
};

4. スナップショット数の管理

Chromaticの無料プランは月5,000スナップショットまでです。大規模プロジェクトでは、すぐに上限に達する可能性があります。

解決策

onlyChanged オプション：変更されたストーリーのみテスト
必要なストーリーに絞る：すべてのストーリーをVRT対象にしない
ブランチ戦略の最適化：mainブランチのみベースラインを保存
代替ツールの検討：予算が限られている場合はreg-vizなど無料ツールを検討

VRTの効果測定と改善

生徒

博士、VRTって導入したら終わりじゃないんですか？

ペン博士

それは大きな間違いじゃ。VRTは運用してこそ価値が出る。
むしろ導入後が本番じゃ！

導入効果の測定指標

VRTの導入効果を定量的に測定するために、以下の指標を追跡しましょう：

デグレーション検出率：VRTで発見されたバグの数
リリース後のUI関連バグ数：本番環境で発見されるUI関連のバグ
レビュー時間の削減：PRレビューにかかる時間の変化
手動テスト時間の削減：目視確認にかかる時間の変化
制作者の満足度：チームアンケートでの評価

継続的な改善

VRTは導入して終わりではありません。以下のポイントで継続的に改善していきましょう：

カバレッジの拡大：新しいコンポーネントやページを追加
テストの最適化：不要なスナップショットを削除
チーム教育：新メンバーへのVRT活用方法の教育
ツールの見直し：プロジェクトの成長に合わせて最適なツールを選択

VRT時代でも人間にしかできないこと

生徒

ここまで聞くと
もう人間のチェックはいらなくなりませんか？

ペン博士

それは極端じゃ。VRTで多くのことが自動化されるが、やはり人間の判断が重要な場面もあるんじゃ！

1. デザイン品質の最終判断

VRTは画素レベルの差分を検出しますが、その変更が良いか悪いかは判断できません。例えば、1pxのズレを検出しても、それがユーザー体験に影響するかどうかは人間が判断する必要があります。

実践のコツ：

デザインシステムの原則に照らし合わせて評価する
ユーザー体験への影響を考慮する
ブランドガイドラインとの整合性を確認する

2. アクセシビリティの評価

VRTは視覚的な変更を検出しますが、アクセシビリティの問題は検出できません。色のコントラスト比、キーボード操作、スクリーンリーダー対応などは、人間が意識的にチェックする必要があります。

実践のコツ：

WCAG（Web Content Accessibility Guidelines）の基準を学ぶ
axe DevToolsなどのアクセシビリティツールを併用する
実際のスクリーンリーダーでテストする

3. ビジネス要件との整合性確認

技術的には正しく実装されていても、ビジネス要件を満たしていなければ意味がありません。UIの変更がビジネスゴールに沿っているかは、人間が評価する必要があります。

実践のコツ：

プロダクトマネージャーやビジネスステークホルダーをレビューに巻き込む
ユーザーストーリーや要件定義に立ち戻って確認する
A/Bテストで実際のユーザー反応を測定する

4. エッジケースの想定

VRTは定義されたストーリーのみをテストします。想定外のエッジケース（非常に長いテキスト、特殊文字、極端なデータなど）は、人間が意識的にテストケースとして追加する必要があります。

実践のコツ：

「もしも〜だったら？」という視点でエッジケースを考える
過去のバグ事例からテストケースを追加する
国際化対応（長い言語、右から左への言語など）を考慮する

生徒

VRTって自動テストだと思ってましたけど、結局人間の判断が重要なんですね！

ペン博士

その通りじゃ！VRTは問題を「検出」してくれるが、その問題を「解決」するのは人間の仕事なんじゃ。VRTと人間の強みを組み合わせることで、最高品質のUIを作れるんじゃぞ！

生徒

はい！VRTを使いこなして、品質の高いWebサイトを作ります！ありがとうございました！

まとめ

本記事では、Visual Regression Testing（VRT）の導入方法について、基本から実践まで詳しく解説しました。

重要なポイントは以下の通りです。

・VRTとは：アプリケーションの外観の変化を画素レベルで自動検出するテスト手法
・主なメリット：安心して制作できる環境、デグレーションの早期発見、レビュープロセスの効率化
・主要ツール：Playwright（E2E統合向け）、Storybook Test Runner（Storybook中心）、Chromatic（チーム協働向け）、reg-viz（無料志向）
・導入ステップ：Storybookセットアップ→Chromatic連携→CI/CD統合→運用ワークフロー確立
・注意点：フォントレンダリング、動的コンテンツ、外部API依存、スナップショット数管理
・人間の役割：デザイン品質の最終判断、アクセシビリティ評価、ビジネス要件との整合性確認

WithCodeで学んだフロントエンドの基礎知識に、VRTを組み合わせれば、どんな大規模なプロジェクトでも自信を持って制作できます。

VRTは最初の導入こそ手間がかかりますが、長期的には制作速度と品質の両方を向上させる強力なツールです。小さなプロジェクトから始めて、徐々にカバレッジを拡大していくことをおすすめします。

WithCodeを体験できる初級コース公開中！

WithCodeでは、Web制作の基礎からVRTのような高度な開発手法まで、実践的なスキルを段階的に学べます。

初級コース（¥49,800）が完全無料に！

期間：1週間
学習内容：ロードマップ/基礎知識/環境構築/HTML/CSS/LP・ポートフォリオ作成
→ 正しい学習方法で「確かな成長」を実感できるカリキュラム

副業・フリーランスが主流になっている今こそ、自らのスキルで稼げる人材を目指してみませんか？

未経験でも心配することはありません。初級コースを受講される方の大多数はプログラミング未経験です。まずは無料カウンセリングで、悩みや不安をお聞かせください！

公式サイトから無料カウンセリングに申し込む →

この記事を書いた人

WithCode 編集部

WithCode（ウィズコード）は「目指すなら稼げる人材」をビジョンに、累計400名以上のフリーランスを輩出してきた超実践型プログラミングスクールです。150社以上の実案件支援を特徴にWeb制作・Webデザインなどの役立つ情報を現場のノウハウに基づいて発信していきます。

Visual Regression Testing (VRT) 導入ガイド｜UIの変更を防ぎ、品質向上させる方法を解説

Visual Regression Testing（VRT）とは？

従来のテストとVRTの違い

VRTが必要な理由

VRT導入のメリット

1. 安心して制作できる環境の構築

2. デグレーション（機能退行）の早期発見

3. レビュープロセスの効率化

4. 制作速度の向上

5. クロスブラウザ・クロスデバイステストの自動化

主要なVRTツール比較

1. Playwright

特徴

実装例

メリット

デメリット

おすすめの使い方

2. Storybook Test Runner

特徴

実装例

メリット

デメリット

おすすめの使い方

3. Chromatic

特徴

実装例

料金プラン

メリット

デメリット

おすすめの使い方

4. reg-viz (reg-suit / reg-actions)

reg-suit

reg-actions

実装例（reg-actions）

メリット

デメリット

おすすめの使い方

ツール選択のガイドライン

VRT導入の実践ステップ

ステップ1：Storybookのセットアップ

インストール

コンポーネントのストーリー作成

ステップ2：Chromaticアカウントの作成

アカウント作成手順

Chromaticのインストール

ステップ3：初回のビルドとベースライン作成

Chromaticへのアップロード

ベースラインの確認

ステップ4：CI/CDパイプラインへの統合

GitHub Actionsの設定

GitHubシークレットの設定

ステップ5：ワークフローの運用

制作者のワークフロー

レビュアーのワークフロー

ベストプラクティス

VRT導入時の注意点とトラブルシューティング

1. フォントレンダリングの違い

解決策

2. 動的コンテンツの扱い

解決策

3. 外部APIへの依存

解決策

4. スナップショット数の管理

解決策

VRTの効果測定と改善

導入効果の測定指標

継続的な改善

VRT時代でも人間にしかできないこと

1. デザイン品質の最終判断

2. アクセシビリティの評価

3. ビジネス要件との整合性確認

4. エッジケースの想定

まとめ

WithCodeを体験できる初級コース公開中！

初級コース（¥49,800）が完全無料に！

この記事を書いた人

関連記事

– service –WithCodeの運営サービス