フロントエンド開発において、コンポーネントの品質を保つことは非常に重要です。しかし、パフォーマンス、アクセシビリティ、そしてビジュアルの一貫性を手動でチェックするのは時間がかかり、見落としも発生しやすいですよね。

Storybook を活用すれば、これらの品質チェックを自動化し、PR（プルリクエスト）の段階で自動的に検証・承認できる仕組みを構築できます。本記事では、Lighthouse によるパフォーマンス測定、axe によるアクセシビリティテスト、そしてビジュアル差分検出を組み合わせた品質ゲート運用の実践方法をご紹介します。

この仕組みを導入すれば、チームメンバー全員が安心してコードレビューに集中でき、品質の高いコンポーネントを継続的にデリバリーできるようになるでしょう。

背景

Storybook と品質管理の関係

Storybook は、UI コンポーネントを独立した環境で開発・テストできるツールです。各コンポーネントをストーリーとして定義することで、さまざまな状態やプロパティのバリエーションを視覚的に確認できますね。

しかし、Storybook を導入しただけでは品質保証として十分ではありません。以下の 3 つの観点からコンポーネントを評価する必要があります。

#	品質観点	評価内容	主要ツール
1	パフォーマンス	ページの読み込み速度、レンダリング時間、バンドルサイズなど	Lighthouse
2	アクセシビリティ	WCAG 準拠、スクリーンリーダー対応、キーボード操作など	axe-core
3	ビジュアル整合性	デザインの意図しない変更、レイアウト崩れ、スタイルの退行など	Chromatic, Percy, reg-suit

品質ゲートとは

品質ゲートとは、ソフトウェア開発プロセスにおいて、一定の品質基準を満たさないコードが次の段階に進むことを防ぐ仕組みです。CI/CD パイプラインに組み込むことで、自動的に品質チェックを実行し、基準を満たさない場合はマージをブロックできます。

以下の図は、Storybook を中心とした品質ゲートの全体像を示しています。

mermaidCopy codeflowchart TB
  dev["開発者"] -->|コード push| pr["Pull Request"]
  pr -->|トリガー| ci["CI/CD<br/>(GitHub Actions)"]

  ci -->|ビルド| sb["Storybook<br/>静的ビルド"]

  sb --> lh["Lighthouse CI"]
  sb --> a11y["axe A11y テスト"]
  sb --> vrt["ビジュアル差分<br/>テスト"]

  lh -->|スコア評価| gate["品質ゲート"]
  a11y -->|違反チェック| gate
  vrt -->|差分検出| gate

  gate -->|合格| approve["自動承認"]
  gate -->|不合格| block["マージブロック"]

  approve --> merge["マージ"]
  block -->|修正| dev

この図が示すように、PR をトリガーとして 3 つのテストが並行実行され、すべてが品質基準を満たした場合のみマージが許可される仕組みです。

モダンフロントエンド開発の要求

近年のフロントエンド開発では、以下のような要求が高まっています。

デザインシステムの導入が進み、コンポーネントの再利用性が重視されるようになりました。同時に、Web アクセシビリティへの対応が法的要件となるケースも増えています。また、Core Web Vitals のような新しいパフォーマンス指標が SEO に影響するようになり、ビジネス上の重要性も増しているのです。

こうした背景から、コンポーネント単位での品質保証が必要不可欠になっています。

課題

手動チェックの限界

従来の手動による品質チェックには、いくつかの深刻な課題があります。

まず、パフォーマンステストを毎回手動で実施するのは現実的ではありません。Lighthouse を手動で実行し、スコアを記録して比較する作業は、時間がかかるだけでなく、測定環境の違いによって結果がブレやすいという問題もあります。

アクセシビリティチェックも同様です。WCAG のガイドラインは数百項目に及び、すべてを人間が確認するのは不可能に近いでしょう。スクリーンリーダーでの動作確認も重要ですが、すべてのコンポーネントで実施するには膨大な工数が必要です。

ビジュアル差分の検出も人の目だけでは限界があります。微細なスタイルの変更や、特定の画面サイズでのみ発生するレイアウト崩れを見逃してしまう可能性が高いのです。

チーム規模拡大による品質のバラツキ

チームが大きくなると、各メンバーの品質意識や経験値にバラツキが生じます。

新しいメンバーがアクセシビリティのベストプラクティスを知らないまま実装してしまったり、パフォーマンスへの影響を考慮せずに大きなライブラリを追加してしまったりするケースが発生しやすくなります。

コードレビューで指摘することもできますが、レビュアーの負担が大きく、見落としも避けられません。

以下の図は、手動チェックと自動チェックの課題構造を示しています。

mermaidCopy codeflowchart TD
  manual["手動チェック"] --> time["時間・工数<br/>の問題"]
  manual --> inconsist["チェック基準<br/>の不統一"]
  manual --> miss["見落としリスク"]

  time --> delay["リリース遅延"]
  inconsist --> quality["品質のバラツキ"]
  miss --> bug["本番バグ"]

  auto["自動チェック"] --> fast["高速・並列実行"]
  auto --> standard["統一基準"]
  auto --> reliable["確実な検出"]

  fast --> speed["開発速度向上"]
  standard --> stable["安定した品質"]
  reliable --> trust["信頼性向上"]

  style manual fill:#ffcccc
  style auto fill:#ccffcc

この図から明らかなように、手動チェックでは避けられない課題が、自動化によって解決できることがわかります。

品質基準の明文化不足

多くのプロジェクトでは、「パフォーマンスが良い」「アクセシブルである」といった抽象的な目標はあっても、具体的な数値基準が定義されていません。

Lighthouse のスコアは何点以上であるべきか、A11y の違反は何件まで許容するか、ビジュアル差分はどの程度なら問題ないのか。こうした基準が明確でないと、品質の判断が属人化してしまいます。

解決策

Storybook を品質ゲートの中核に

Storybook は単なるコンポーネントカタログではなく、品質ゲートの中核として活用できます。各ストーリーに対して、Lighthouse、A11y テスト、ビジュアル差分テストを実行することで、コンポーネント単位での品質保証が実現できるのです。

この仕組みの最大のメリットは、コンポーネントを本番アプリケーションに統合する前に品質を保証できる点です。問題が見つかった場合の修正コストも大幅に削減できますね。

3 つの品質チェックの組み合わせ

品質ゲートは、以下の 3 つのチェックを組み合わせることで機能します。

Lighthouse によるパフォーマンス測定

Lighthouse CI を使用して、Storybook の各ストーリーに対してパフォーマンス測定を実行します。Performance、Accessibility、Best Practices、SEO の 4 つのカテゴリでスコアを取得し、基準値との比較を行います。

axe-core によるアクセシビリティテスト

Storybook の test-runner と @axe-core/playwright を組み合わせることで、すべてのストーリーに対して自動的に A11y テストを実行できます。WCAG 2.1 の AA レベルに準拠しているかを機械的にチェックできるのです。

Chromatic によるビジュアル差分検出

Chromatic を使用すると、UI の視覚的な変更を自動検出し、意図しないデザインの退行を防げます。複数のブラウザやビューポートサイズでのスナップショットを比較することで、クロスブラウザ対応も確実になります。

以下の図は、3 つのチェックがどのように連携するかを示しています。

mermaidCopy codeflowchart LR
  story["Storybook<br/>ストーリー"] --> build["静的ビルド"]

  build --> lhci["Lighthouse CI"]
  build --> axe["axe-core<br/>テストランナー"]
  build --> chromatic["Chromatic"]

  lhci -->|Performance: 90+| lhpass["合格"]
  lhci -->|Performance: 90未満| lhfail["不合格"]

  axe -->|違反: 0件| axepass["合格"]
  axe -->|違反: 1件以上| axefail["不合格"]

  chromatic -->|差分なし/承認済み| chromaticpass["合格"]
  chromatic -->|未承認の差分| chromaticfail["不合格"]

  lhpass --> gate["品質ゲート"]
  axepass --> gate
  chromaticpass --> gate

  lhfail --> reject["マージ<br/>ブロック"]
  axefail --> reject
  chromaticfail --> reject

  gate --> merge["マージ許可"]

  style lhpass fill:#90EE90
  style axepass fill:#90EE90
  style chromaticpass fill:#90EE90
  style lhfail fill:#FFB6C1
  style axefail fill:#FFB6C1
  style chromaticfail fill:#FFB6C1

この図が示すとおり、3 つすべてのチェックが合格基準を満たして初めてマージが許可される仕組みです。

自動承認の仕組み

品質基準を満たした場合、GitHub Actions から自動的に PR を承認し、マージ可能な状態にします。これにより、開発者は品質チェックの結果を待つだけで、手動での承認作業が不要になります。

一方、基準を満たさない場合は、詳細なレポートとともにチェックが失敗し、マージがブロックされます。開発者は具体的な改善点を確認し、修正してから再度 PR を更新する流れです。

具体例

プロジェクトセットアップ

まず、必要なパッケージをインストールします。

typescriptCopy code// package.json の devDependencies に追加
{
  "devDependencies": {
    "@storybook/react": "^7.6.0",
    "@storybook/test-runner": "^0.16.0",
    "@axe-core/playwright": "^4.8.0",
    "@lhci/cli": "^0.13.0",
    "chromatic": "^10.0.0",
    "playwright": "^1.40.0"
  }
}

パッケージのインストールを実行します。

bashCopy codeyarn add -D @storybook/react @storybook/test-runner
yarn add -D @axe-core/playwright @lhci/cli chromatic playwright

次に、Playwright をセットアップします。

bashCopy code# Playwright のブラウザをインストール
yarn playwright install

Storybook の設定

Storybook の設定ファイルを作成し、テストランナーと統合します。

typescriptCopy code// .storybook/main.ts
import type { StorybookConfig } from '@storybook/react-vite';

const config: StorybookConfig = {
  stories: ['../src/**/*.stories.@(js|jsx|ts|tsx)'],
  addons: [
    '@storybook/addon-links',
    '@storybook/addon-essentials',
    '@storybook/addon-interactions',
    '@storybook/addon-a11y', // A11y アドオンを追加
  ],
  framework: {
    name: '@storybook/react-vite',
    options: {},
  },
};

export default config;

A11y アドオンを追加することで、Storybook の UI 上でもアクセシビリティの問題を確認できるようになります。

axe-core によるアクセシビリティテスト設定

test-runner の設定ファイルを作成し、axe-core を統合します。

typescriptCopy code// .storybook/test-runner.ts
import type { TestRunnerConfig } from '@storybook/test-runner';
import { injectAxe, checkA11y } from 'axe-playwright';

const config: TestRunnerConfig = {
  async preVisit(page) {
    // 各ストーリー訪問前に axe をインジェクト
    await injectAxe(page);
  },
  async postVisit(page) {
    // ストーリー表示後に A11y チェックを実行
    await checkA11y(page, '#storybook-root', {
      detailedReport: true,
      detailedReportOptions: {
        html: true,
      },
    });
  },
};

export default config;

この設定により、すべてのストーリーに対して自動的にアクセシビリティチェックが実行されます。#storybook-root は Storybook のルート要素を指定しており、ストーリーのコンテンツのみをテスト対象にしています。

テスト実行用のスクリプトを package.json に追加します。

jsonCopy code{
  "scripts": {
    "storybook": "storybook dev -p 6006",
    "build-storybook": "storybook build",
    "test-storybook": "test-storybook"
  }
}

Lighthouse CI の設定

Lighthouse CI の設定ファイルを作成します。

javascriptCopy code// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      // Storybook の静的ビルドを対象にする
      staticDistDir: './storybook-static',
      // テストする URL のパターン
      url: [
        'http://localhost/iframe.html?id=components-button--primary',
        'http://localhost/iframe.html?id=components-button--secondary',
        'http://localhost/iframe.html?id=components-card--default',
      ],
      numberOfRuns: 3, // 3回実行して中央値を取得
    },
    assert: {
      assertions: {
        // パフォーマンススコアの基準
        'categories:performance': [
          'error',
          { minScore: 0.9 },
        ],
        // アクセシビリティスコアの基準
        'categories:accessibility': [
          'error',
          { minScore: 0.9 },
        ],
        // ベストプラクティススコアの基準
        'categories:best-practices': [
          'error',
          { minScore: 0.9 },
        ],
      },
    },
    upload: {
      // 結果を Lighthouse CI サーバーにアップロード
      target: 'temporary-public-storage',
    },
  },
};

各カテゴリで 90 点以上を基準としています。この基準値はプロジェクトの要件に応じて調整できます。

Lighthouse CI を実行するスクリプトを追加します。

jsonCopy code{
  "scripts": {
    "lhci": "lhci autorun"
  }
}

Chromatic の設定

Chromatic のプロジェクトを作成し、プロジェクトトークンを取得します。

bashCopy code# Chromatic にログインしてプロジェクトを作成
yarn chromatic --project-token=<your-project-token>

.env ファイルにトークンを保存します（このファイルは .gitignore に追加してください）。

bashCopy code# .env
CHROMATIC_PROJECT_TOKEN=your-project-token-here

package.json にスクリプトを追加します。

jsonCopy code{
  "scripts": {
    "chromatic": "chromatic --exit-zero-on-changes"
  }
}

--exit-zero-on-changes オプションを指定することで、差分が検出されてもコマンドは正常終了します。これにより、CI での処理を柔軟に制御できます。

GitHub Actions ワークフロー設定

すべての品質チェックを統合した GitHub Actions ワークフローを作成します。

yamlCopy code# .github/workflows/quality-gate.yml
name: Quality Gate

on:
  pull_request:
    branches: [main, develop]

jobs:
  quality-check:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

依存関係のインストールとキャッシュの設定を行います。

yamlCopy code- name: Setup Node.js
  uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'yarn'

- name: Install dependencies
  run: yarn install --frozen-lockfile

Storybook をビルドします。

yamlCopy code- name: Build Storybook
  run: yarn build-storybook

ここから 3 つの品質チェックを並行実行します。

yamlCopy code- name: Install Playwright browsers
  run: yarn playwright install --with-deps

- name: Run A11y tests
  run: |
    yarn storybook --ci &
    yarn test-storybook

A11y テストは、Storybook を CI モードで起動し、test-runner を実行することで全ストーリーをチェックします。

Lighthouse CI を実行します。

yamlCopy code- name: Run Lighthouse CI
  run: yarn lhci
  env:
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Chromatic でビジュアル差分を検出します。

yamlCopy code- name: Run Chromatic
  uses: chromaui/action@v1
  with:
    projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
    exitZeroOnChanges: true
    exitOnceUploaded: true

すべてのチェックが成功した場合、PR を自動承認します。

yamlCopy code- name: Auto approve PR
  if: success()
  uses: hmarr/auto-approve-action@v3
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}

- name: Add success label
  if: success()
  uses: actions/github-script@v7
  with:
    script: |
      github.rest.issues.addLabels({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        labels: ['quality-check-passed']
      })

チェックが失敗した場合の処理も追加します。

yamlCopy code- name: Add failure label
  if: failure()
  uses: actions/github-script@v7
  with:
    script: |
      github.rest.issues.addLabels({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        labels: ['quality-check-failed']
      })

      github.rest.issues.createComment({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        body: '品質チェックが失敗しました。詳細はワークフローの実行結果を確認してください。'
      })

失敗時には、PR にラベルを追加し、コメントで開発者に通知します。

サンプルコンポーネントとストーリー

実際のコンポーネントとストーリーの例を見てみましょう。

typescriptCopy code// src/components/Button/Button.tsx
import React from 'react';
import './Button.css';

export interface ButtonProps {
  /** ボタンのラベル */
  label: string;
  /** ボタンの種類 */
  variant?: 'primary' | 'secondary' | 'danger';
  /** クリックハンドラー */
  onClick?: () => void;
  /** 無効化フラグ */
  disabled?: boolean;
}

コンポーネントの実装部分です。アクセシビリティを考慮して、適切な属性を設定します。

typescriptCopy codeexport const Button: React.FC<ButtonProps> = ({
  label,
  variant = 'primary',
  onClick,
  disabled = false,
}) => {
  return (
    <button
      type='button'
      className={`button button--${variant}`}
      onClick={onClick}
      disabled={disabled}
      aria-label={label}
    >
      {label}
    </button>
  );
};

aria-label を設定することで、スクリーンリーダーでも適切に読み上げられるようにしています。

ストーリーを作成します。

typescriptCopy code// 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,
  parameters: {
    // Chromatic でこのストーリーをキャプチャ
    chromatic: { viewports: [320, 768, 1200] },
  },
  tags: ['autodocs'],
};

export default meta;
type Story = StoryObj<typeof Button>;

各バリエーションのストーリーを定義します。

typescriptCopy codeexport const Primary: Story = {
  args: {
    label: '送信する',
    variant: 'primary',
  },
};

export const Secondary: Story = {
  args: {
    label: 'キャンセル',
    variant: 'secondary',
  },
};

export const Danger: Story = {
  args: {
    label: '削除する',
    variant: 'danger',
  },
};

export const Disabled: Story = {
  args: {
    label: '無効なボタン',
    disabled: true,
  },
};

Chromatic は、これらすべてのストーリーを複数のビューポートでキャプチャし、前回のビルドと比較します。

実行結果の確認方法

品質チェックの実行結果は、それぞれのツールで確認できます。

A11y テスト結果

test-runner の実行結果は、ターミナルに出力されます。

bashCopy code$ yarn test-storybook

Running tests in Storybook...
✓ Components/Button: Primary
✓ Components/Button: Secondary
✓ Components/Button: Danger
✗ Components/Button: Disabled

  A11y violations found:
  - button-name: Buttons must have discernible text
    Impact: critical
    Elements:
      - button.button--primary[disabled]

Tests: 3 passed, 1 failed

このように、具体的な違反内容と影響度、該当する要素が表示されます。

Lighthouse CI 結果

Lighthouse CI の結果は、GitHub の PR チェックとして表示されます。

textCopy codeLighthouse CI Report:

Performance: 92 ✓
Accessibility: 95 ✓
Best Practices: 88 ✗
SEO: 100 ✓

Details: https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/...

Best Practices が基準の 90 点未満のため、チェックが失敗しています。

Chromatic 結果

Chromatic の結果は、PR にコメントとして投稿されます。

markdownCopy code## Chromatic Results

📸 **3 changes detected**

| Story                        | Status        |
| ---------------------------- | ------------- |
| Components/Button: Primary   | 🟡 Changed    |
| Components/Button: Secondary | ✅ No changes |
| Components/Button: Danger    | 🟡 Changed    |

[Review changes in Chromatic →](https://www.chromatic.com/build?appId=...)

変更があったストーリーは、Chromatic の UI で差分を確認し、意図した変更であれば承認します。

トラブルシューティング

品質チェックで問題が発生した場合の対処方法を見ていきます。

A11y テストが失敗する場合（Error: WCAG 2.1 AA violations detected）

最も一般的なエラーは、color-contrast（色のコントラスト不足）と button-name（ボタンのラベル欠如）です。

typescriptCopy code// 悪い例：コントラストが不十分
const badStyle = {
  color: '#999', // 薄いグレー
  backgroundColor: '#ccc', // 明るいグレー
};

// 良い例：十分なコントラスト比（4.5:1 以上）
const goodStyle = {
  color: '#333', // 濃いグレー
  backgroundColor: '#fff', // 白
};

ボタンにはアクセシブルな名前を必ず付けましょう。

typescriptCopy code// 悪い例：アイコンのみで説明なし
<button onClick={handleClose}>
  <CloseIcon />
</button>

// 良い例：aria-label で説明を追加
<button onClick={handleClose} aria-label="閉じる">
  <CloseIcon />
</button>

Lighthouse スコアが低い場合（Error: Performance score below threshold）

パフォーマンススコアが低い主な原因は、バンドルサイズの肥大化です。

typescriptCopy code// 悪い例：ライブラリ全体をインポート
import _ from 'lodash';
import { Button } from '@mui/material';

// 良い例：必要な部分のみインポート
import debounce from 'lodash/debounce';
import Button from '@mui/material/Button';

画像の最適化も重要です。

typescriptCopy code// 悪い例：最適化されていない画像
<img src="/hero-image.png" alt="ヒーロー画像" />

// 良い例：WebP 形式 + 遅延読み込み
<img
  src="/hero-image.webp"
  alt="ヒーロー画像"
  loading="lazy"
  width="800"
  height="600"
/>

Chromatic で意図しない差分が検出される場合

フォントの読み込みタイミングやアニメーションが原因で、誤検知が発生することがあります。

typescriptCopy code// アニメーションを無効化する設定
export const AnimatedButton: Story = {
  args: {
    label: 'アニメーション付きボタン',
  },
  parameters: {
    // Chromatic でアニメーションを無効化
    chromatic: {
      disableSnapshot: false,
      pauseAnimationAtEnd: true,
    },
  },
};

動的なコンテンツ（日時など）をモックします。

typescriptCopy code// 日時をモックする
export const DateDisplay: Story = {
  play: async ({ canvasElement }) => {
    // Date をモックして一定の値にする
    const mockDate = new Date('2024-01-01T00:00:00Z');
    jest
      .spyOn(global, 'Date')
      .mockImplementation(() => mockDate);
  },
};

品質基準のカスタマイズ

プロジェクトの性質に応じて、品質基準を調整できます。

javascriptCopy code// lighthouserc.js - より厳格な基準
module.exports = {
  ci: {
    assert: {
      assertions: {
        // パフォーマンスは 95 点以上
        'categories:performance': [
          'error',
          { minScore: 0.95 },
        ],
        // FCP（First Contentful Paint）は 1.5 秒以内
        'first-contentful-paint': [
          'error',
          { maxNumericValue: 1500 },
        ],
        // LCP（Largest Contentful Paint）は 2.5 秒以内
        'largest-contentful-paint': [
          'error',
          { maxNumericValue: 2500 },
        ],
        // CLS（Cumulative Layout Shift）は 0.1 以下
        'cumulative-layout-shift': [
          'error',
          { maxNumericValue: 0.1 },
        ],
      },
    },
  },
};

A11y テストでも特定のルールを無効化できます。

typescriptCopy code// .storybook/test-runner.ts
const config: TestRunnerConfig = {
  async postVisit(page) {
    await checkA11y(page, '#storybook-root', {
      // 特定のルールを無効化（慎重に使用すること）
      rules: {
        'color-contrast': { enabled: false }, // 例：ブランドカラーの都合で一時的に無効化
      },
    });
  },
};

ただし、A11y ルールの無効化は最小限にとどめ、可能な限り準拠することが推奨されます。

運用フローの全体像

以下の図は、日常的な開発フローと品質ゲートの関係を示しています。

mermaidCopy codesequenceDiagram
    participant Dev as 開発者
    participant Git as Git/GitHub
    participant CI as GitHub Actions
    participant LH as Lighthouse CI
    participant Axe as axe テスト
    participant Chr as Chromatic
    participant PR as Pull Request

    Dev->>Git: コミット & プッシュ
    Git->>PR: PR 作成
    PR->>CI: ワークフロー起動

    CI->>CI: Storybook ビルド

    par 並列実行
        CI->>LH: パフォーマンス測定
        CI->>Axe: A11y テスト
        CI->>Chr: ビジュアル差分検出
    end

    LH-->>CI: スコア結果
    Axe-->>CI: 違反チェック結果
    Chr-->>CI: 差分検出結果

    alt すべて合格
        CI->>PR: 自動承認
        CI->>PR: ラベル追加 (quality-check-passed)
        PR->>Dev: マージ可能通知
    else いずれか不合格
        CI->>PR: チェック失敗
        CI->>PR: ラベル追加 (quality-check-failed)
        PR->>Dev: 修正依頼コメント
        Dev->>Git: 修正コミット
    end

この図が示すように、開発者は PR を作成するだけで、自動的にすべての品質チェックが実行され、結果に応じて適切なフィードバックを受け取れます。

まとめ

Storybook を中心とした品質ゲート運用により、Lighthouse によるパフォーマンス測定、axe-core によるアクセシビリティテスト、Chromatic によるビジュアル差分検出を自動化できました。

この仕組みを導入することで得られる主なメリットは以下のとおりです。

まず、品質チェックの自動化により、開発者はコードの品質を気にせず実装に集中できるようになります。PR の段階で問題が自動検出されるため、本番環境への品質問題の混入を未然に防げます。

また、明確な品質基準（Lighthouse スコア 90 点以上、A11y 違反 0 件など）を設定することで、チーム全体で一貫した品質を維持できるようになりました。新しいメンバーが参加しても、同じ基準で開発を進められるのは大きな利点です。

さらに、コードレビューの負担も大幅に軽減されます。機械的にチェックできる部分は自動化されているため、レビュアーはビジネスロジックやアーキテクチャに集中できるようになるのです。

品質ゲートの導入は、最初の設定には少し手間がかかりますが、一度構築してしまえば継続的に価値を生み出し続けます。チームの開発速度と品質の両立を実現する強力な仕組みと言えるでしょう。

ぜひ、あなたのプロジェクトでも Storybook 品質ゲート運用を導入して、より高品質なコンポーネント開発を実現してください。

関連リンク

• Storybook 公式ドキュメント
• Lighthouse CI
• axe-core
• Chromatic
• Storybook Test Runner
• Web Content Accessibility Guidelines (WCAG) 2.1
• Core Web Vitals
• GitHub Actions