QAエンジニアがClaude Codeを半年間使って気づいたこと〜テスト自動化74%高速化を実現した3つの技術アプローチ〜

TL;DR
背景と課題
- なぜClaude Codeを選んだのか
課題1: テスト実行時間の長さ
課題2: ワークフロー自動化の余地
課題3: テストの保守性と安定性
実績サマリー
- 半年間のコード貢献
学んだこと・Tips
今後の展望
まとめ
参考リンク

【QAチームブログリレー3日目】Claude Code、MCP、Playwrightを活用したE2Eテスト自動化の半年間の実践から得た気づきを共有します。技術的なアプローチだけでなく、「AI活用に不安があったけど、実はこれまでのドキュメント整備が土台になっていた」という発見についてもお伝えします。

こんにちは、エムスリー QAチームの今井です。最近話題の「テストプレイをサボりすぎたRPG」をご存知でしょうか？テストをサボりすぎてバグだらけになったRPGを、プレイヤーが「ミス」を探しながら進めるというフリーゲームです。私たちQAはそうならないよう、いかに効率よくテストを回すかが課題でした。

TL;DR

エムスリーではClaude Code使い放題: QAエンジニアも最新AIツールをフル活用
テスト実行時間74%短縮（既存ツール 105分 → Playwright 27分）、年間約68時間分のCI/CD待ち時間を削減
67件のMR/PRをマージ（E2Eテスト、リリース作業自動化、Agent開発など）
MCP（Model Context Protocol）で外部ツールと連携し、テスト〜ドキュメント更新を一気通貫で自動化

背景と課題

私たちのチームでは、製薬企業向けWebサービスのQAを担当しています。

なぜClaude Codeを選んだのか

エージェント型の特徴（「テストを実行して、結果をConfluenceに書いて」と指示すれば自律実行）、MCP（Model Context Protocol）による既存ツールとの連携、Co-Authored-ByでのGit履歴への明示的な記録といった点が、QA業務の効率化に適していると判断しました。

Pragmatic Engineerの調査（2026年2月）によると、Claude Codeは2025年5月のローンチからわずか8ヶ月で開発者人気1位（46%）を獲得しており、テスト自動化での50-80%の時間短縮が業界で報告されています。

以下、3つの主要課題とその解決アプローチを紹介します。

課題1: テスト実行時間の長さ

何が問題だったのか

週次で実行する定期リリースチェックは約30種類、実行に毎回1時間45分以上。既にかなり自動化・システム化されており、テスト内容から考えると効率的に運用できていました。しかし、AIで開発チームのリリーススピードが加速する中、さらなる効率化の余地があると考えました。

主な原因: - 既存ローコードツールでは操作ごとに固定のwait時間（例：3秒）が設定され、それが積み重なって実行時間が長期化 - SaaS型ツールのプラン制約で並列実行数に制限 - より柔軟なPlaywrightへの移行が必要だったが、手作業での移行は現実的でなかった

解決アプローチ

Claude Codeと協力してPlaywrightへの移行を進めました。

1. 待機処理の最適化

固定wait時間から、条件ベースの待機に変更：

// 動的な待機処理
await this.page.waitForResponse(resp =>
  resp.url().includes('/api/items') && resp.status() === 200
);

waitForResponseやwaitForLoadStateで「完了したら次へ進む」という条件ベースの待機ができるため、無駄な待ち時間がなくなりました。

2. Page Objectパターンの徹底

保守性の高いテストコードを設計：

// pages/SamplePage.ts
export class SamplePage {
  constructor(private page: Page) {}

  async createItem(options: ItemOptions) {
    // role-basedセレクターで安定性向上
    await this.page.getByRole('button', { name: '新規作成' }).click();
    await this.page.getByRole('textbox', { name: 'タイトル' }).fill(options.title);

    // 動的な待機処理
    await this.page.waitForResponse(resp =>
      resp.url().includes('/api/items') && resp.status() === 200
    );
  }

  async verifyCreated(expectedTitle: string) {
    await expect(this.page.getByText(expectedTitle)).toBeVisible();
  }
}

ポイント: - getByRoleなどのrole-basedセレクターでUI変更に強いテストに - Page Objectにビジネスロジックをカプセル化し、テストコードはシンプルに

3. 並列実行の自由度向上

SaaS型ツールはプランによって同時実行数に制限がありましたが、Playwrightではworker数を自由に設定できます。

結果

指標	Before	After（Playwright）	効果
1回あたりの実行時間	約105分	約27分	74%短縮
週次実行（月4回）	420分/月	108分/月	312分/月短縮
年間	約91時間	約23時間	約68時間短縮

課題2: ワークフロー自動化の余地

何が問題だったのか

テスト実行後、結果をConfluenceに転記し、失敗があればJIRAでチケット起票という一連の作業フローが確立されていました。このルーチンワークをさらに効率化できないかと考えました。

既存の運用フロー: 1. テスト実行 2. 結果を確認 3. Confluenceページを開いて結果を更新 4. 失敗があればJIRAチケット作成 5. Slackでチームに共有

解決アプローチ

MCP（Model Context Protocol）による外部ツール連携

MCPはAIエージェントと外部ツールを接続するためのオープンな標準プロトコルです。Claude Code、Cursor、VS Code Copilotなど多くのツールで利用できます。私たちは次のMCPサーバーを活用しました：

プロジェクト管理:   atlassian-mcp（Confluence/JIRA連携）
ソースコード管理:   github-mcp, mcp-gitlab（PR/MR連携）
ブラウザテスト:    playwright（E2Eテスト実行）

実際のワークフロー例：

ユーザー: 「定期リリースチェックを実行して、結果をConfluenceに更新して」

Claude Code:
1. Playwright でテスト実行
2. 結果を解析
3. atlassian-mcp でConfluenceページを更新
4. 失敗があればatlassian-mcp でJIRAチケット作成

これにより、「テスト実行→結果確認→ドキュメント更新→チケット起票」という一連の作業が1コマンドで完了します。

カスタムスキルによるワークフロー定義

繰り返し行うワークフローは「スキル」として定義しました：

# SKILL.md の例（ticket-investigation）

## トリガー
「チケット調査」「○○について調べて」

## 実行フロー
1. Redmine/JIRAからチケット情報を取得
2. 関連するConfluenceページを検索
3. GitLabのMR履歴を確認
4. 結果を統合してレポート生成

これにより、「チケット#12345について調べて」と言うだけで、複数システムを横断した調査が自動で行われます。

結果

確立された5ステップの作業フローを1コマンドに集約できました。

課題3: テストの保守性と安定性

何が問題だったのか

CI/ローカル環境の認証の違い: ローカルでは手動ログイン、CIでは環境変数からの認証が必要で、同じテストコードが動作しないケースがありました。

環境依存テストの扱い: 動的コンテンツ（機械学習モデルの予測結果など）はテスト環境のデータ状態に依存するため、より柔軟な評価方法が求められていました。

解決アプローチ

1. CI/CD認証パターン

ローカル開発とCI環境の両方で動作する認証処理を実装しました：

// utils/auth.ts
export async function createAuthenticatedContext(browser: Browser) {
  // CI環境では環境変数から認証
  if (process.env.CI) {
    const context = await browser.newContext();
    const page = await context.newPage();

    await page.goto(process.env.LOGIN_URL!);
    await page.getByRole('textbox', { name: 'ユーザー名' })
      .fill(process.env.TEST_USERNAME!);
    await page.getByRole('textbox', { name: 'パスワード' })
      .fill(process.env.TEST_PASSWORD!);
    await page.getByRole('button', { name: 'ログイン' }).click();

    return { context, page };
  }

  // ローカルでは保存済みの認証状態を使用
  return await browser.newContext({
    storageState: '.auth/test-user.json'
  });
}

メリット: - ローカルでは認証をスキップして高速に実行 - CIでは環境変数で認証情報を管理（セキュア） - 同じテストコードが両環境で動作

2. 環境依存テストの「警告扱い」パターン

テストデータに依存する機能は、失敗ではなく警告として記録する仕組みを導入しました：

test('動的コンテンツ表示確認', async ({ page }) => {
  const MAX_RETRIES = 12;

  for (let i = 0; i < MAX_RETRIES; i++) {
    const targetElement = page.locator('[data-testid="dynamic-content"]');

    if (await targetElement.isVisible({ timeout: 5000 }).catch(() => false)) {
      await expect(targetElement).toContainText('期待するテキスト');
      return; // 成功
    }

    // リトライ
    await page.reload();
    await page.waitForLoadState('networkidle');
  }

  // 環境依存として警告記録（テスト失敗にはしない）
  console.warn('コンテンツ表示なし - 環境データに依存する可能性あり');
  test.info().annotations.push({ type: 'warning', description: 'Content not displayed' });
});

なぜ「警告扱い」にするのか: - 動的コンテンツは機械学習モデルの予測結果に依存することがある - テスト環境のデータ状態により表示されないことがある - 本番バグではないのにテストが失敗するのを防ぐ

結果

CI/CDパイプラインの安定性を確保し、不安定テストの影響を最小化できました。

実績サマリー

半年間のコード貢献

プラットフォーム	前半（9〜11月）	後半（12〜3月）	合計
GitLab MR	0件	32件	32件（29件マージ）
GitHub PR	16件	19件	35件（33件マージ）
合計	16件	51件	67件（62件マージ）

前半はセットアップと試行錯誤の時期でしたが、後半は約3.2倍のペースでMR/PRを出せるようになりました。MCPプラグインの整備とカスタムスキルの蓄積により、開発速度が加速した形です。

学んだこと・Tips

意外だった発見

正直なところ、導入前は「自分に生成AIを使いこなせるだろうか」という不安がありました。

しかし振り返ってみると、これまでチーム内でドキュメントを整備してきたことが、AI活用の大きな土台になっていました。Confluenceの仕様書、Redmineのチケット履歴、GitLabのMR説明文——これらがあったからこそ、AIに「このドキュメントを読んで処理して」と依頼できたのです。

AI時代の準備は、実は「ドキュメントを書く」という地道な習慣の中にあったのかもしれません。

うまくいったこと

AIとの分業を明確に
- コード生成・リファクタリング → Claude Code
- レビュー・ビジネスロジック確認 → 人間
- 両者の得意分野を活かす
MCP活用で「点」を「線」に
- テスト実行だけでなく、前後の作業も含めて自動化
- 「テスト→ドキュメント更新→Slack通知」が1コマンドに
Co-Authored-Byで透明性確保
- AIが書いたコードが明確になり、後からのレビューが容易
- チームメンバーへの説明もしやすい

課題と対策

課題	対策
認証トークンの期限切れ	セッション開始時にトークン有効性を確認するスキルを追加
環境依存テストの不安定さ	「警告扱い」パターンとリトライロジックの導入
MCPプラグイン初期設定の手間	設定手順のドキュメント化とチーム共有（CLAUDE.md）

これから始める方へのTips

小さく始める: まずは1つのテストファイルをClaude Codeで作成してみる
MCPは段階的に: 最初はatlassian-mcpだけ、慣れたら追加
CLAUDE.mdを育てる: プロジェクト固有の知識を蓄積し、AIの精度を上げる

今後の展望

並列実行: 複数環境での同時テスト実行
自己修復テスト: セレクター変更の自動検知と修正（AIネイティブテスト）
ドキュメント自動同期: コード変更に連動したドキュメント自動更新

まとめ

Claude Codeを活用したテスト自動化により、テスト実行時間を年間68時間分短縮しました。

振り返ると、AI活用がうまくいった理由の1つは、チーム内のドキュメントが充実していたことでした。AIは「すでに言語化されたナレッジ」を活用するのが得意です。日々のドキュメント整備が、いつの間にかAI活用の土台になっていたのです。

2026年は「AIエージェント実行フェーズ」です。AIコーディングアシスタントは「コードを書いてもらう」だけでなく、「ワークフロー全体を自動化するパートナー」として活用できます。

ぜひ皆さんも試してみてください。

参考リンク

We are hiring!

エムスリーでは、QAエンジニアを募集しています。テスト自動化やAI活用に興味のある方、ぜひご応募ください。

https://jobs.m3.com/engineer/

エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

QAエンジニアがClaude Codeを半年間使って気づいたこと〜テスト自動化74%高速化を実現した3つの技術アプローチ〜

TL;DR

背景と課題

なぜClaude Codeを選んだのか

課題1: テスト実行時間の長さ

何が問題だったのか

解決アプローチ

1. 待機処理の最適化

2. Page Objectパターンの徹底

3. 並列実行の自由度向上

結果

課題2: ワークフロー自動化の余地

何が問題だったのか

解決アプローチ

MCP（Model Context Protocol）による外部ツール連携

カスタムスキルによるワークフロー定義

結果

課題3: テストの保守性と安定性

何が問題だったのか

解決アプローチ

1. CI/CD認証パターン

2. 環境依存テストの「警告扱い」パターン

結果

実績サマリー

半年間のコード貢献

学んだこと・Tips

意外だった発見

うまくいったこと

課題と対策

これから始める方へのTips

今後の展望

まとめ

参考リンク