🆑

E2Eテスト自動化！Playwright Test Agents + MCPで実現する次世代テスト開発

タン

2025/11/18に公開

テーマ「2025年の最も大きなチャレンジ」

Playwright

E2E

Model Context Protocol

MCP サーバー

tech

この記事について

PlaywrightがAIで革命的に進化！もう手動でテスト書く時代は終了（の可能性あり）

従来のPlaywright開発は、テストケース作成に膨大な時間がかかり、エラー修正も手作業でした。
しかし、AIエージェント（Playwright Test Agents） を活用することで、もうテストを手動で書く必要はありません。AIが自動で理解・生成・修正してくれます。

記事の内容

3つの専門AI（戦略・実装・修正）による自動テスト生成
CSVファイル→Playwrightテストの実際の作業プロセス
MCP統合によるワンストップ開発環境
ゼロから始める導入ガイドと注意点

こんな方におすすめ

E2Eテスト作成に時間を取られている開発者
Playwrightを効率化したいチーム
AI開発ツールの実践事例を知りたい方

読了時間：約15分で、テスト自動化の新しい可能性を体験できます

0. はじめに

E2Eテストの自動化は開発プロセスにおいて重要な要素ですが、テスト作成やメンテナンスには多くの時間と専門知識が必要です。最近、AIエージェントを活用してPlaywrightテストの作成・デバッグを効率化する手法に取り組んでみました。

特に注目すべきは、MCP（Model Context Protocol） を活用したツール統合により、従来のAIアシスタントの限界を超えた、より強力で実用的なテスト自動化環境の構築が可能になったことです。本記事では、Playwright Test Agentsの概念と、MCPを活用した実際の活用事例について詳しく紹介します。

1. Playwright Test Agentsとは？

従来のPlaywright開発との根本的な違い

従来のアプローチ

開発者が手動で → テストコード記述 → エラー発生 → 手動デバッグ → 修正
                                              ↑
                                    時間がかかり、専門知識が必要

Playwright Test Agentsのアプローチ

要件・CSV仕様 → AI Agent → 自動生成 → 自動デバッグ → 修正・最適化
     ↓             ↓      　 ↓          ↓            ↓
  自然言語     コード生成    実行検証    エラー分析    持続的改善

Agentシステムの詳細アーキテクチャ

Playwright Test Agentsは、AI技術を活用してPlaywrightテストの作成・デバッグ・メンテナンスを自動化する革新的なシステムです。従来の「人間がすべて書く」アプローチから、「AIが理解し、AIが実装し、AIが修正する」パラダイムシフトを実現します。

3つの専門エージェントによる完全自動化:

📋 Planner Agent（戦略設計エージェント）

役割: テスト全体の戦略設計と実行計画の立案

要件分析・戦略立案:

// Plannerによる分析例
入力: CSVファイル + 発送登録機能の要件
↓
戦略: 
1. デスクトップ基本フロー（seed.spec.ts）
2. 確認画面特化テスト（confirm.spec.ts）  
3. モバイル環境対応（mobile.spec.ts）
4. データドリブンパターン適用

テスト設計の智能化:
- 複雑な業務フロー（メガネプロセス）の理解
- テストケース優先度付け（Critical/High/Medium）
- 環境別戦略（Desktop/Mobile/API）の自動判断

実行プラン生成:

# Planner生成の実行計画例
## Phase 1: 基本テスト群
- [x] 認証フローの確立
- [x] 主要画面の表示検証
- [x] 基本操作フローの実装

## Phase 2: エラーハンドリング
- [ ] 異常系パターンの網羅
- [ ] バリデーション検証
- [ ] エラーメッセージ確認

Planner vs Generator の使い分け:

Planner: 「どのテストを作るか？」戦略レベル
Generator: 「どう実装するか？」コードレベル

実際の体験:
- Planner → 全体設計・ファイル構成・優先順位
- Generator → 具体的なテストコード生成
- 両方ともコード生成するが、抽象度が違う

🎭 Generator Agent（テスト生成エージェント）

従来との違い: 手動でのテストケース記述→自然言語仕様からの自動生成

高度な理解能力:
- CSV形式、Excel、自然言語の要件を解析
- 複雑なビジネスロジック（メガネプロセス等）の理解
- 多画面フロー（登録→確認→完了）の自動設計

コード生成の智能化:

// 従来: 開発者が手動で記述
await page.click('#submit');

// Agent生成: より堅牢で実践的
const submitButton = page.locator('button')
  .filter({ hasText: '確認に進む' })
  .first();
await expect(submitButton).toBeEnabled({ timeout: 5000 });
await submitButton.click();
await page.waitForLoadState('networkidle');

ベストプラクティス自動適用:
- Page Object Modelパターン
- 適切な待機戦略（networkidle, domcontentloaded）
- エラーハンドリングパターンの内蔵

🩺 Healer Agent（診断・修復エージェント）

従来との違い: エラーログを見て手動分析→自動診断・修復提案

多層エラー分析:
- 構文層: TypeScript型エラー、インポート問題
- 実行層: タイムアウト、セレクター、ネットワークエラー
- ビジネス層: データ不整合、フロー不具合

学習機能:

// 初回エラー: セレクター問題
page.locator('[data-testid="reception-no"]') // 失敗

// Agent学習後の改善案
page.locator('input[placeholder*="受付票"]')
  .or(page.locator('input').first())
  .or(page.locator('[id*="reception"]'))

予防的修正:
- フレーキーテスト(不安定テスト)の事前検出
- セレクター耐性の自動向上
- タイミング問題の自動調整

# エージェント定義例（healer.chatmode.md）
---
description: Use this agent when you need to debug and fix failing Playwright tests.
tools: ['edit/createFile', 'edit/editFiles', 'search/fileSearch', 'search/textSearch']
---

You are the Playwright Test Healer, an expert test automation engineer...

MCPによるツール統合の威力

MCP（Model Context Protocol） を活用することで、従来のAIアシスタントでは実現困難だった高度なツール統合を実現しました。

MCPとは：

AIエージェントが外部ツールやサービスにアクセスするための標準プロトコル
セキュアで拡張可能なツール統合を提供
Figma、GitHub、データベース等への統一されたアクセス

// MCP活用例：Figma連携による開発フロー
interface DesignToTestFlow {
  // Figmaからデザイン情報取得
  'figma/getFile': (fileKey: string) => Promise<FigmaFile>;
  'figma/getComponents': (fileKey: string) => Promise<Component[]>;
  
  // デザインからテスト生成
  'playwright/generateFromDesign': (design: Component) => Promise<TestCode>;
  
  // GitHub連携
  'github/createPR': (branch: string, files: File[]) => Promise<PullRequest>;
}

実際の活用例：Figma MCP

// 1. Figmaデザインファイルを取得
const figmaFile = await mcp.call('figma/get_file', {
  fileKey: 'abc123',
  depth: 2
});

// 2. コンポーネント情報を抽出
const components = await mcp.call('figma/get_file_components', {
  fileKey: 'abc123'
});

// 3. デザインに基づいたテスト生成
// "ボタンの配置"や"カラースキーム"などをFigmaから取得し
// 実際のUIテストに反映

MCPの実際の効果：

デザイン→実装の一貫性: Figmaの最新デザインを自動取得してテスト更新
クロスツール連携: Figma + GitHub + Slackなど複数ツールの統合
拡張性: 新しいツールやサービスの追加が容易

2. セットアップガイド

前提条件

# 必要な環境
Node.js: 18+ (推奨20+)
Git: 最新版
エディタ: VS Code (推奨) or Cursor
AI Assistant: Claude/Copilot (必須)

よくある勘違い:

❌「Playwright Agentは特別なソフトウェア」
✅「既存のAI AssistantとPlaywrightの組み合わせ」

❌「高度な知識が必要」  
✅「対話形式で段階的に学習」

Step 1: 基本プロジェクト作成

# 1. 新規プロジェクト作成（既存プロジェクトに入れるならスキップ）
mkdir my-playwright-agents
cd my-playwright-agents

# 2. package.json 初期化（既存プロジェクトに入れるならスキップ）
npm init -y

# 3. Playwright インストール
npm init playwright@latest
# ↳ TypeScript? Yes
# ↳ Add GitHub Actions? No  
# ↳ Install browsers? Yes

# 4. agents導入
npx playwright init-agents --loop=vscode

Step 2: よく使うPlaywrightコマンド

# ブラウザ可視化（開発時の基本）
npx playwright test --headed

# UIモード（インタラクティブデバッグ）
npx playwright test --ui

# デバッグモード（ステップ実行）
npx playwright test --debug

# 特定のテストケース実行
npx playwright test shipping-registration.spec.ts
npx playwright test --grep "ログイン"

# ブラウザ指定
npx playwright test --project=chromium
npx playwright test --project=mobile

# 並列実行制御
npx playwright test --workers=4
npx playwright test --workers=1  # シーケンシャル実行

# レポート表示
npx playwright show-report

# トレース表示（失敗時の詳細分析）
npx playwright show-trace trace.zip

📋 Planner Agent設定 (.github/chatmodes/📋 planner.chatmode.md):

---
description: Use this agent when you need to plan and design comprehensive Playwright test strategies from requirements.
tools: ['edit', 'search/fileSearch', 'search/textSearch', 'terminal']
model: claude-sonnet-4
---

あなたは Playwright Test Planner です。テスト戦略の設計専門家として以下を実行します：

## 専門領域
1. **要件分析**: CSV、仕様書、ユーザーストーリーから包括的テスト戦略を立案
2. **設計思想**: テスト分割、優先度付け、実行順序の最適化
3. **アーキテクチャ**: ファイル構成、Page Object設計、データ管理戦略

## 設計ガイドライン
- **戦略的思考**: ビジネス価値の高いテストケース優先
- **保守性重視**: 長期運用を考慮した設計
- **段階的実装**: Phase分けによる段階的展開
- **リスク分析**: 失敗しやすい箇所の事前特定

## 出力形式
- テスト戦略書（Markdown）
- ファイル構成案
- 実行計画（Phase別）
- リスク評価とコンティンジェンシープラン

🎭 Generator Agent設定 (.github/chatmodes/🎭 generator.chatmode.md):

---
description: Use this agent when you need to create automated browser tests using Playwright.
tools: ['edit', 'search/fileSearch', 'search/textSearch', 'terminal']
model: claude-sonnet-4
---

あなたは Playwright Test Generator です。E2Eテスト自動化の専門家として以下の能力を持ちます：

## 専門領域
1. **仕様解析**: CSV、Excel、自然言語から詳細なテストケース抽出
2. **コード生成**: Page Object Model、データドリブンテストの実装
3. **品質保証**: ベストプラクティス、アクセシビリティ、パフォーマンスの考慮

## 生成ガイドライン
- **堅牢性優先**: フォールバック戦略付きセレクター
- **保守性重視**: 再利用可能なコンポーネント設計
- **デバッグ支援**: 詳細なエラー情報とスクリーンショット
- **実行効率**: 並列実行対応、適切な待機戦略

## 出力形式
- TypeScript + Playwright Test形式
- Page Object Model パターン採用
- データ分離設計（fixtures活用）

🩺 Healer Agent設定 (.github/chatmodes/🩺 healer.chatmode.md):

---
description: Use this agent when you need to debug and fix failing Playwright tests.
tools: ['edit/createFile', 'edit/editFiles', 'search/fileSearch', 'search/textSearch', 'terminal']
model: claude-sonnet-4  
---

あなたは Playwright Test Healer です。テスト自動化のデバッグ・修復専門家として以下を実行します：

## 診断能力
1. **多層エラー分析**: 構文・実行・ビジネスロジック層の問題特定
2. **根本原因調査**: ログ解析、ネットワーク問題、タイミング問題
3. **パターン認識**: 類似エラーの学習・予防策提案

## 修復戦略
- **段階的修正**: 最小限の変更で最大効果
- **耐性向上**: フレーキーテスト対策、セレクター強化
- **パフォーマンス改善**: 実行時間短縮、リソース効率化

## 予防機能
- **ベストプラクティス適用**: コード品質向上提案
- **将来問題の早期発見**: 潜在的問題の指摘

Step 3: 設定ファイル最適化

// playwright.config.ts - Agent対応版
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './e2e-test',
  timeout: 60000,
  retries: 2,
  
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure'
  },
  
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'mobile', use: { ...devices['iPhone 13'] } }
  ],
  
  reporter: [
    ['html'],
    ['json', { outputFile: 'test-results/results.json' }]
  ]
});

3. 実際の作業事例

CSVテストケース分析からE2Eテスト作成まで

メガネ加工管理システムの発送登録機能について、実際のテストケースCSVファイルからPlaywrightテストを作成しました。

作業フロー

要件分析: CSVファイル（試しテストケース.csv）から41のテストケースを解析
戦略設計: Planner Agent による全体設計とファイル構成計画
テスト設計: デスクトップ・モバイル環境での画面表示・機能動作テストを計画
コード生成: Generator Agent による3つの専門テストファイル作成
エラー修正: Healer Agent による実行時エラーの診断・修復

実際のAgent連携フロー

Phase 1: 戦略立案（Planner Agent）

# Planner Agentによる分析結果

## テスト戦略概要
- **対象機能**: メガネ加工管理 / 発送登録
- **要件ソース**: CSV 41テストケース + 業務要件
- **優先度**: Critical(認証) > High(基本フロー) > Medium(エラーハンドリング)

## ファイル構成設計
1. `seed.spec.ts` - デスクトップ基本フロー（Priority: Critical）
2. `shipping-registration-confirm.spec.ts` - 確認画面特化（Priority: High）
3. `shipping-registration-mobile.spec.ts` - モバイル環境（Priority: Medium）

## 実行計画
Phase 1: 認証・基本表示の確立 (15分)
Phase 2: フロー操作・データ処理 (30分)  
Phase 3: エラーハンドリング・エッジケース (30分)

Phase 2: 実装（Generator Agent）

// Generator Agentによる生成例
// Plannerの設計を参照しながらコード生成

test.describe('発送登録画面 - デスクトップ基本フロー', () => {
  // Plannerの指示: "認証フローを最優先で確立"
  test.beforeEach(async ({ page }) => {
    await page.goto('http://localhost:3000/login');
    // ... 認証処理
  });

  // Plannerの指示: "画面表示検証をPhase1で完了"
  test('ヘッダー部の表示が仕様通りか確認', async ({ page }) => {
    const jinsIcon = page.locator('[data-testid="jins-icon"], [alt*="JINS"]');
    await expect(jinsIcon).toBeVisible();
    // ...
  });
});

Phase 3: デバッグ・修正（Healer Agent）

Generator生成コード → テスト実行 → エラー発生 → Healer分析・修正

実際の3Agent連携の効果

従来の単一Agent vs 3Agent連携:

単一Agent（Generator のみ）:
要件 → コード生成 → エラー → 手動修正 → 完成
  ↑                ↑
設計不足          原因分析困難
   
3Agent連携:
要件 → Planner(戦略) → Generator(実装) → Healer(修正) → 完成
        ↓                ↓               ↓
      包括的設計        最適実装         自動修復

効果:

設計品質: Planner導入で設計漏れ削減
実装速度: Generator単体より高速化
エラー解決: Healerにより手動デバッグ削減

Agent使い分けの実践ポイント

どのAgentを使うべきか？

「どんなテストを作ればいい？」→ 📋 Planner

User: CSVファイルから発送機能のテストを作りたいが、
      何から始めればいい？
      
Planner: 以下の順序で進めることを提案します：
         1. 認証フロー確立
         2. 基本画面表示検証  
         3. データ入力・フロー操作
         4. エラーハンドリング

「具体的なコードを書いて」→ 🎭 Generator

User: Plannerの設計に基づいて、seed.spec.tsを実装して

Generator: 実装を開始します。Planner設計を参照しながら...
          [具体的なTypeScriptコード生成]

「テストが失敗する、修正して」→ 🩺 Healer

User: Error: locator.click: Timeout 30000ms exceeded

Healer: エラー分析結果：
        原因: ボタン有効化待機不足
        修正: waitForSelector追加
        [修正されたコード提示]

「既存テストを改善したい」→ 📋 Planner + 🎭 Generator

User: 今のテストが不安定で改善したい

Planner: 現状分析と改善戦略を提案...
Generator: Plannerの戦略に基づいてリファクタリング...

作成したテストファイル

1. デスクトップ版基本機能テスト (seed.spec.ts)

test.describe('発送登録画面', () => {
  test.beforeEach(async ({ page }) => {
    // ログイン処理
    await page.goto('http://localhost:3000/login');
    await page.fill('#employeeCode', testData.validUser.employeeCode);
    // ...
  });

  test('ヘッダー部の表示が仕様通りか確認', async ({ page }) => {
    // JINSアイコンの表示確認
    const jinsIcon = page.locator('[data-testid="jins-icon"], [alt*="JINS"]');
    await expect(jinsIcon).toBeVisible();
    // ...
  });
});

2. 確認画面テスト (shipping-registration-confirm.spec.ts)

発送登録確認画面の表示検証
登録完了処理の動作確認
ナビゲーション機能テスト

3. モバイル環境テスト (shipping-registration-mobile.spec.ts)

スマートフォン向け画面レイアウト検証
AsReaderモード（QRスキャナー）機能テスト
タッチインターフェース動作確認

Healer Agentによる実践的デバッグ作業

今回の作業で遭遇したエラーは、Playwright開発でよく遭遇する典型的な問題です。Healer Agentがこれらをどう解決したかを詳しく解説します。

エラー1: 認証プロセス問題（Critical Level）

Error: page.goto: net::ERR_ABORTED at http://localhost:3000/shipping-registration
  at [Browser] › shipping-registration:15

従来のデバッグアプローチ:

エラーログを見る → 手動でURLの問題かセッション問題か推測
複数回テスト実行して再現性確認
Networkタブで通信確認
手動でセッション管理コードを修正

Healer Agentの分析プロセス:

// Agent診断結果: ログイン完了前のページ遷移が原因
// 問題パターン: 認証レスポンス待機不足

// 修正前（危険なパターン）
await page.click('button[type="submit"]');
await page.goto('/shipping-registration');  // ここで認証が切れる

// Agent修正案（堅牢なパターン）
await loginButton.click();
await page.waitForFunction(() => !window.location.pathname.includes('/login'), {
  timeout: 10000
});
await page.waitForLoadState('networkidle');  // すべてのリクエスト完了を待機

今後の対策:

すべての認証フローでwaitForFunctionによる状態確認
ページ遷移後は必ずwaitForLoadState実行
Cookie-based認証の場合はcontext.storageState()でセッション保存

エラー2: 要素セレクター問題（High Frequency）

Error: locator.fill: Test timeout of 30000ms exceeded.
Call log: waiting for locator('input[data-testid="reception-no-input"]')

従来の対応:

// 1. 開発者ツールで要素確認
// 2. セレクターを手動修正
// 3. 複数回テスト実行で確認

Healer Agentの改善戦略:

// Agent診断: テストID属性が実装と乖離
// 解決案: フォールバック戦略で耐性向上

// 修正前（脆弱なセレクター）
const receptionNoInput = page.locator('input[data-testid="reception-no-input"]');

// Agent修正後（耐性のあるセレクター）
const receptionNoInput = page.locator('input[data-testid="reception-no-input"]')
  .or(page.locator('input[placeholder*="受付票"]'))
  .or(page.locator('input[id*="reception"]'))
  .or(page.locator('input').first());
  
await expect(receptionNoInput).toBeVisible({ timeout: 10000 });

推奨されるセレクター戦略:

// 1. 優先順位付きフォールバック
const element = page.locator('[data-testid="primary-id"]')
  .or(page.locator('[data-cy="fallback-id"]'))
  .or(page.locator('text=visible-text'))
  .or(page.locator('css-selector'));

// 2. 動的待機条件
await expect(element).toBeVisible();
await expect(element).toBeEnabled();

// 3. アクション前の状態確認
if (await element.isVisible()) {
  await element.click();
}

エラー3: テストデータ問題（Data Layer）

問題: モックデータと実データの不整合

// 修正前（存在しないデータ）
const testData = {
  receptionNo: 'MOCK_123456789'  // DBに存在しない
};

// Healer Agent調査結果: 実際のCSVデータ確認
const realData = {
  processedReceptionNo: 'UH35072668105',    // 実データ: 発送登録待ち
  unprocessedReceptionNo: 'UH35072668101',  // 実データ: 入庫待ち  
  completedReceptionNo: 'UH35072668106'     // 実データ: 発送登録完了
};

データ管理ベストプラクティス:

// 1. 環境別データ設定
const getTestData = () => {
  const env = process.env.NODE_ENV;
  return env === 'test' ? mockData : realData;
};

// 2. データベースシード機能
test.beforeAll(async () => {
  await setupTestData();
});

// 3. テスト実行後のクリーンアップ
test.afterAll(async () => {
  await cleanupTestData();
});

エラー4: タイミング問題（Advanced）

今回は遭遇しませんでしたが、おそらくよく発生する問題です。

// 危険パターン: 即座にアクション実行
await page.click('#submit');
await page.click('#confirm');  // まだボタンが無効の可能性

// 安全パターン: 状態待機
await page.click('#submit');
await page.waitForSelector('#confirm:not([disabled])');
await page.click('#confirm');

今後気をつけるべき重要ポイント

1. セレクター設計思想

// ❌ 避けるべきパターン
page.locator('div > div > input')  // 構造依存
page.locator('#dynamic-id-123')    // 動的ID依存

// ✅ 推奨パターン
page.locator('[data-testid="stable-id"]')  // テスト専用ID
page.locator('text=確認に進む')             // ユーザー視点
page.getByRole('button', { name: '送信' })  // セマンティック

2. 待機戦略の統一

// 標準的な待機パターン（今回確立）
class BasePage {
  async waitForStableState() {
    await this.page.waitForLoadState('networkidle');
    await this.page.waitForSelector('[data-loading="false"]');
  }
  
  async safeClick(selector: string) {
    await this.page.waitForSelector(`${selector}:not([disabled])`);
    await this.page.click(selector);
    await this.waitForStableState();
  }
}

3. エラー予防パターン

// 1. 堅牢な認証フロー
class AuthHelper {
  async loginAndWaitForReady() {
    await this.performLogin();
    await this.page.waitForURL(/dashboard|shipping/);
    await this.waitForAuthComplete();
  }
}

// 2. デバッグ情報の充実
test.afterEach(async ({ page }, testInfo) => {
  if (testInfo.status === 'failed') {
    await page.screenshot({ path: `error-${testInfo.title}.png` });
    console.log('Page URL:', page.url());
    console.log('Console errors:', await page.evaluate(() => 
      window.console.errors || []
    ));
  }
});

4. 感想・考察

劇的に効果的だった点

1. 開発速度の革命的向上

従来のPlaywright開発:

要件理解(1日) → 設計(0.5日) → 実装(2-3日) → デバッグ(1-2日) = 合計5-7日

Agents活用後:

要件提示(15分) → Agent生成(30分) → 検証・調整(30分) = 合計1.25時間

効率化率: 約95%の時間短縮（41テストケース対応）

2. コード品質の大幅向上

// 従来の手動実装（よくあるパターン）
test('基本テスト', async ({ page }) => {
  await page.goto('/shipping-registration');
  await page.click('#submit');  // 脆弱なセレクター
  // 待機処理なし → フレーキーテスト
});

// Agent生成コード（自動的にベストプラクティス適用）
test('発送登録 - 基本フロー', async ({ page }) => {
  const shippingPage = new ShippingRegistrationPage(page);
  await shippingPage.navigateToShipping();
  
  const submitButton = page.locator('button[type="submit"]')
    .or(page.locator('text=確認に進む'))
    .first();
  await expect(submitButton).toBeEnabled({ timeout: 10000 });
  await submitButton.click();
  await page.waitForLoadState('networkidle');
  
  await expect(page).toHaveURL(/shipping-registration-confirm/);
});

3. 包括的なテストカバレッジの自動実現

デスクトップ + モバイル: 両環境対応が標準装備
正常 + 異常系: エラーケースまで自動生成
アクセシビリティ: WAI-ARIAパターン自動検証
パフォーマンス: ページ読み込み時間の自動計測

4. 学習機能による持続的改善

// 初回生成時のエラー（学習前）
await page.click('input[data-testid="reception-input"]'); // 属性名誤り

// Agent学習後の改善（2回目以降）
const receptionInput = page.locator('input[placeholder*="受付票"]')
  .or(page.locator('input[id*="reception"]'))
  .or(page.locator('input').first());
await expect(receptionInput).toBeVisible();

改善が必要な領域と対策

1. セレクター戦略の限界

現在の課題: 動的コンテンツへの対応が困難

// 問題のあるパターン
page.locator('#dynamic-id-' + timestamp)  // 予測困難

// Agent改善案 + 人間の設計改善
// フロントエンド側での対応
<button data-testid="submit-button" data-test-context="shipping">
  確認に進む
</button>

// Agent最適化セレクター
page.locator('[data-testid="submit-button"][data-test-context="shipping"]')

2. 複雑なビジネスロジックの理解度

限界例: メガネ製造特有のワークフロー

入庫 → 加工 → 品質検査 → 在庫管理 → 発送登録 → 出荷

改善アプローチ: ドメイン知識の段階的学習

// 業務フロー定義ファイル
export const GlassesWorkflow = {
  steps: ['warehousing', 'processing', 'quality', 'inventory', 'shipping'],
  transitions: {
    'warehousing': ['processing'],
    'processing': ['quality', 'rework'],
    // ...
  }
};

3. テストデータ管理の複雑化

// 課題: 実データと同期困難
const realData = await csv.parse('./orders_202511141549.csv');
const processedData = realData.filter(item => item.status === '発送登録待ち');

// 解決案: 動的データ生成
class TestDataManager {
  async getValidReceptionNumbers(count: number) {
    return await this.dbQuery(`
      SELECT reception_no FROM orders 
      WHERE status = '発送登録待ち' 
      LIMIT ${count}
    `);
  }
}

個人的な感想と気付き

1. AI開発の新しいパラダイム
今回の体験で、「AI with Human」から「AI for Human」へのシフトを実感しました。従来は「AIが補助する開発」でしたが、Agentシステム + MCPでは「AIが主体的に理解・実装・修正する開発」に変わっています。

2. 品質と速度の両立
これまで「速く書くか、丁寧に書くか」のトレードオフがありましたが、Agentsではベストプラクティスが自動適用されるため、両方を同時に実現できる革命的変化です。

3. MCPによる統合の威力
特に印象的だったのは、MCPによるツール統合の滑らかさです。ブラウザ操作、ファイル操作、テスト実行、結果通知までが一つの対話で完結する体験は、まさに「未来の開発環境」を感じさせるものでした。

4. 開発者の役割進化

従来: コードライター（実装者）
↓
現在: アーキテクト（設計者 + Agent指揮官）
↓  
将来: ビジネス価値創造者（要件定義 + MCP環境設計者）

5. 学習コストの劇的削減
新しいフレームワーク習得に通常2-3ヶ月かかるところ、Agentとの対話で数時間でPlaywrightの高度な活用ができるようになりました。MCPによるツール統合で、さらに学習範囲が拡大しているにも関わらず、習得時間は短縮されています。

注意すべき罠と対策

1. Agent過信の危険性

// ❌ 危険: 生成コードを無検証で使用
const generatedCode = await generatorAgent.createTest(spec);
await deployToProduction(generatedCode);  // これはNG

// ✅ 安全: 段階的検証
const generatedCode = await generatorAgent.createTest(spec);
await runLocalTests(generatedCode);
await codeReview(generatedCode);
await deployToStaging(generatedCode);

2. ビジネスロジック理解の限界
複雑なドメイン知識（メガネのワークフロー等）は人間の監修が必須。Agentは技術的実装の専門家であり、業務の専門家ではありません。

3. メンテナンス性の考慮
Agent生成コードも保守が必要。適切なコメント、構造化、バージョン管理が重要です。

5. MCPでFigmaと連携する

Playwright Test Agentsは、Figma MCPと組み合わせることで、デザインからテストまでのワークフローを劇的に効率化できます。

Figma MCPとは

Figma-Context-MCPは、Figmaのデザイン情報をAIに伝える橋渡しツールです。これにより：

Figmaのレイアウト、スタイル、テキスト情報をAIが理解
「このFigmaデザインをReactにして」という指示だけで高精度なコード生成
デザインとテストの一貫性を自動維持

セットアップ手順

Step 1: Figma Personal Access Tokenの取得

Figma設定画面 (Settings) を開く
「Personal access tokens」 セクションへ移動
「Generate new token」 をクリック
トークン名を入力（例: Figma_MCP_Token）
権限は 「File content: Read-only」 を確認
トークンをコピーし、安全な場所に保管

⚠️ トークンは絶対に公開・共有しないでください

Step 2: MCPサーバーの起動

方法A: npxでクイック起動（推奨）

npx figma-developer-mcp --figma-api-key=【Figmaトークン】

方法B: リポジトリからセットアップ

# 1. クローン
git clone https://github.com/GLips/Figma-Context-MCP.git
cd Figma-Context-MCP

# 2. インストール
pnpm install

# 3. .envファイル作成
# .env.exampleを.envにコピーし、トークンを設定
FIGMA_API_KEY=your_token_here

# 4. 起動
pnpm run dev

HTTP server listening on port 3333と表示されれば成功です。

Step 3: CursorやClineへの登録

Cursorの場合:

Settings > MCP セクションを開く
「Add New MCP Server」 をクリック
設定を入力：
- Server Name: Figma Server
- Connection Type: SSE (Server-Sent Events)
- Server URL: http://localhost:5348
保存

緑色のドットが表示されれば接続成功です。

実際の使い方

1. Figmaでデザインリンクをコピー

コード化したい要素を選択
→ 右クリック > Copy/Paste as > Copy link to selection
→ URLをコピー（例: https://www.figma.com/file/...node-id=...）

2. AIに指示

User: [Figmaリンクを貼り付け]
      このデザインのPlaywrightテストを生成して。
      ボタンの配置、色、テキストを検証する内容で。

Agent: [Figmaから情報取得]
       → [テストコード生成]
       
test('ボタンコンポーネントの検証', async ({ page }) => {
  const button = page.locator('button.primary');
  
  // Figmaデザインから取得した情報を基に検証
  await expect(button).toHaveCSS('background-color', 'rgb(0, 123, 255)');
  await expect(button).toContainText('送信する');
  // ...
});

活用例

デザイン変更の自動テスト更新

User: Figmaの最新デザインと現在のテストを比較して、
      差分があれば更新して

Agent: [デザイン取得 → 比較 → テスト更新]

デザインシステムとの連携

User: Figmaのカラーパレットを取得して、
      CSS変数として出力して

Agent: [Figmaスタイル取得 → CSS生成]

まとめ

Figma MCP連携により：

デザイン→実装の一貫性が自動維持される
手作業でのスタイル確認が不要に
デザイン変更への追従が容易に
プロトタイピング速度が向上
デザインレビューも効率化

Figma-Context-MCPは、デザインと開発の垣根を下げる画期的なツールです。AIがFigmaのレイアウト、スタイル、テキスト情報を直接理解することで、より高品質な開発が可能になります。

始め方は簡単：

Figmaトークン取得（数分）
MCPサーバー起動（1コマンド）
AIツールに登録（数クリック）

これだけで、デザインからテスト生成までのワークフローが劇的に変わります。ぜひ試してみてください！

JINSテックブログ

アイウエアや服飾雑貨の企画・製造・販売のほか、ウェアラブル端末の企画、開発、製造をしています。