Safie Engineers' Blog!

Safieのエンジニアが書くブログです

面倒なテストコードはAIに任せる。セーフィー新卒2年目が実践する「Claude Code」テスト半自動化ワークフロー

2025アドカレ AI 開発プロセス フロントエンド

この記事はSafie Engineers' Blog! Advent Calendar 12日目の記事です。

はじめに

こんにちは！セーフィー株式会社でサーバーサイドエンジニアをしている坂上(@Bobtaroh)です。新卒2年目となり、私を含め同期のエンジニアたちも、それぞれの配属先で一生懸命に業務をこなしています。

本記事では、同じく新卒2年目であるフロントエンド開発を担当している東條さんにインタビューを行い、開発現場で話題の「Claude Code」を活用したテスト半自動化のワークフローについて紹介します。

「AIに全部任せる」のではなく、あえて「半自動化」を選ぶその理由と、具体的な実践手法について深掘りしました。

そのテストコード、まだ全部「手」で書いていますか？

テストコードは、アプリケーションの品質担保に不可欠ですが、その実装は時としてエンジニアの負担になることもあります。セーフィーのフロント開発チームでは、特に以下の課題がありました。

  • 大規模なデザインシステム移行をやっていて、工数見積もり上、テストを後回しにしていた
  • テストを実装する箇所多かった
    • 配属されてから開発したコンポーネントが40~50ほどあり、1コンポーネントあたり1000行ほどのテストが必要だった
  • テストの中には、作業に近い単純な実装が多く存在し、エンジニアのモチベーションがあまり上がりづらい側面も少々あった

これらの課題を抱えていた時に、世間ではCoding Agentが注目を集め始め、弊社でも社内ツールとしてGeminiやClaude Codeの利用環境が整備されました。それを機に、今回のテストの半自動化ワークフローを組むことに至ったとのことでした。

今はどんな生成AIを使っているのか？

昨今、Claude Code以外のさまざまな生成AIが登場していますが、以下の4つの生成AIに関して、どのように使い分けているのか、東條さんに聞いてみました。

  • Gemini
    • 相棒的な存在
    • Gemini単体でタスクをお願いすることはなく、調べるためのツールとして使うことが多い
    • 会議中に出てきた分からないことについても聞くことがよくある
  • Claude Code
    • 部下に近い存在
    • 以下の仕事を投げている
      • テストの実装
      • 新規開発の雛形作成
      • 複雑な実装の解説依頼
  • Github Copilot
    • 以前使っていたが、今は完全に使用していない
  • Bedrock Chat
    • Geminiが導入される前までは主流だったが、今は使用していない

2025年12月現在では、主にGeminiとClaude Codeを使用しているとのことでした。

なぜ「全自動」ではないのか？

現在のテスト半自動化に至るまでには様々な試行錯誤がありました。

弊社でClaude Codeが利用可能になる前までは、Github Copilot Agentを使って、One-shotのプロンプトでテストを生成させる手法を試みました。しかし、プロジェクト固有のルールが守られなかったり、意図しないコードが生成されたりと、結果として出力の6〜7割を人間が書き直すことになっていました。

Claude Codeが利用可能になった当初では、劇的な変化はありませんでした。Github CopilotでSonnet 4モデルを使用することができていたため、Github Copilotで培った仕組みをそのまま流用していたとのことです。hooksやmemoryの分散化の利用を試みましたが、管理が難しく、チーム開発になかなか向かないということがわかりました。

現在では、Subagentsを用いて、設計、実装、スタイルレビューと統合の4つに工程を分けることで、半自動化まで進めることができたとのことです。

実践！Claude Codeを使ったテスト半自動化4ステップ

Claude Codeを使った半自動化の詳細説明をします。

この半自動化では、主にSubagentsの機能を使っています。Subagentsとは、メインの会話に左右されずに特定のコンテキストを保持し、適切な権限のものと、特定の領域に特化して精度を向上させることができる再利用可能なエージェントのことです。公式サイト(https://code.claude.com/docs/ja/sub-agents)では、以下の4つの利点が挙げられています。

  • コンテキストの保持
  • 特化した専門知識
  • 再利用性
  • 柔軟な権限

この機能とClaude Codeのファイル仕様に従って、以下のファイル構成で実現しています。

.claude
├── agents  # Agentの定義が詰まったディレクトリ
│   ├── consolidate-text-fixes.md
│   ├── generate-test-spec.md
│   ├── implement-test.md
│   ├── investigate-test-pattern.md
│   ├── review-test-first.md
│   ├── review-test-second.md
│   ├── review-test-third.md
│   └── search-translation-key.md
└── commands # ワークフロー(コマンド)を実行させる定義が詰まったディレクトリ
    └── test-workflow.md

commandsディレクトリで定義したワークフロー(test-worklow.md)では、以下のような構成になっています。

🔽実際のtest-workflow.mdの中身を見る。(ここをクリック！)

---
name: test-workflow
description: テスト設計・実装・レビューの一連のワークフロー
---

# テスト実装ワークフロー管理エージェント

このエージェントは、テストの設計から実装、レビューまでの一連のワークフローを管理します。**各フェーズで適切なサブエージェントを呼び出し**、高品質なテストコードを作成します。

## ワークフロー概要

1. **テスト設計** → 2. **テスト実装** → 3A. **並列テストレビュー** → 3B. **統合修正・最終調整** → 4. **最終確認**

テスト設計後にユーザーレビューを求め、ユーザーの修正後承認を得てからテスト実装以降のフェーズに進みます。

## 実行手順

### Phase 1: テスト設計 📝

**使用エージェント**: `generate-test-spec`

1. 対象ファイルを分析
2. テスト設計書を作成（`<fileName>テスト設計書.md`）
3. **ユーザーに設計書のレビュー・修正を依頼**
4. 承認を得たら次フェーズへ

### Phase 2: テスト実装 💻

**使用エージェント**: `implement-test`

1. テスト設計書を基にテストコードを実装
2. テストを実行してカバレッジ確認
3. エラーがある場合は修正（最大3回試行）

### Phase 3A: 並列テストレビュー 🔍

3つのテストレビューエージェントを**並列実行**して、その結果を結合した問題の分析と改善方針を1つ作成します：

#### Review 1: 基本修正分析

**使用エージェント**: `review-test-first`

- 動的import、getState、非同期処理などの基本的な問題を分析
- 改善方針と具体的な修正内容を提案
- **ファイル修正やテスト実行は行わない**

#### Review 2: DOM・マッチャー・設定分析

**使用エージェント**: `review-test-second`

- detectChanges、translate関数、MockStoreValueなどの問題を分析
- 改善方針と具体的な修正内容を提案
- **ファイル修正やテスト実行は行わない**

#### Review 3: spyOn・配列・追加ルール分析

**使用エージェント**: `review-test-third`

- 専用マッチャー、spyOn配置、DOM要素取得などの問題を分析
- 改善方針と具体的な修正内容を提案
- **ファイル修正やテスト実行は行わない**

#### レビュー結果ファイル生成

- レビュー結果ファイル名: `<fileName>レビュー結果.md`
- 管理のためレビュー対象ファイルと同ディレクトリに生成
- 加工は行わず各レビューエージェントから返却された結果を結合する

### Phase 3B: 統合修正・最終調整 🛠️

**使用エージェント**: `consolidate-test-fixes`

- **前フェーズで作成したレビュー結果ファイルを渡します**

1. **実際の修正実行**: 統合された修正計画に従ってファイルを修正
2. **テスト実行**: 修正後のテストを実行して動作確認
3. **最終調整**: エラーがあれば原因分析して再修正
4. **最終確認**: もう一度並列テストレビューを行い、修正が完了しているかを確認する
5. **レビューファイルの削除**: 不要になったレビューファイルを削除する

### Phase 4: 実装最終確認 ✅️

実装内容が設計書から乖離した内容になっていないかを確認

## 注意事項

### 各フェーズ共通

- エラーや問題が発生した場合は詳細をユーザーに報告

### テスト実行コマンド

 ```bash
 npm run test <project> --specs=<testFile> --agent
 # e.g. npm run test viewer --specs=hoge.component --agent
 ```

YOU MUST: **テスト実行時は必ず`npm run test <project> --specs=<testFile> --agent`を使用し、他のコマンド実行を試みないこと、特に`--agent`オプションを追加しないとテストが終了しません**

- `<project>`: プロジェクト名（`viewer`, `myportal`, `core`, `sdk`のいずれか）
- `<testFile>`: `.spec.ts`を除くテストファイルパス。例：`example.component`

### 品質基準

- カバレッジ: 95%以上
- すべてのテストケースが成功すること
- コードスタイルがプロジェクトの規約に準拠していること

## トラブルシューティング

### テストが失敗する場合

1. エラーメッセージを確認
2. consolidate-test-fixesエージェントで再修正を試行
3. 3回試行しても解決しない場合は`investigate-test-pattern`エージェントを使用して同様の実装がないか調査してから再修正

### レビューで問題が見つからない場合

1. 該当するレビューエージェント（review-test-\*）を再実行
2. 特定の問題に焦点を当ててレビューを指示
3. 新たなレビュー結果でconsolidate-test-fixesを再実行

全体の流れとしては、以下の4ステップです。

  1. テスト設計
    まず generate-test-spec エージェントが対象コードを分析し、テスト設計書を作成します。ここで重要なのが「人間の承認」を必須にしている点です。設計書がプロジェクトの意図と合致しているかをエンジニアが確認し、修正を経てOKが出て初めて実装フェーズへ進むようにしています。

  2. テスト実装
    承認された設計書を元に、implement-test エージェントがコーディングを行います。ここではテストの実行とカバレッジ確認までを自律的に行い、エラーが出れば自己修正するように指示しています。

    ここで工夫した点は、実装内容に直接関係しない弊社特有のルール（命名規則やスタイル）はあえてこの工程では指示しないことです。ルールを厳格に守らせようとすると、肝心な処理に関わるロジックの精度が落ちてしまう傾向があった経験があったためです。これによって、まずは純粋な処理のみに集中させることで、本来のコーディングスキルを存分に発揮してもらい、Claude Codeが自信を持って実装してもらえるようになったとのことです。

  3. 並列トリプルレビュー
    実装されたコードに対し、3つの異なる専門家エージェントが並列でレビューを行います。

    • Reviewer A: 基本的な構文や非同期処理のチェック
    • Reviewer B: DOM操作やマッチャーの正確性チェック
    • Reviewer C: SpyOnやモック定義など、高度なルールのチェック

    この過程では、2番目のステップの出力結果をもとに、処理内容には関係ない弊社特有のルールに沿っているかの確認のレビューを行い、提案のみを行います。コード編集は行いません。

    これによって、以下の3つのメリットがあったとのことです。

    1. 複数の項目をAgentに投げると、細かい見落としが多くなる傾向にあったが、Subagentsで分けることで、特定の観点に絞ることができ、精度が上がった
    2. 並列実行することで、実行速度が向上した
    3. 処理内容のレビューは考慮せずに、スタイルレビューに限定させたことで、この過程で弊社特有のルールや表現を入れ込むことができた

  4. 統合修正・最終調整
    3匹のレビュアーから上がってきた指摘事項を consolidate-test-fixes エージェントが集約し、実際のコード修正に適用します。最後に改めてテストを回し、設計書との乖離がないかを確認して完了となります。

このワークフローがもたらした、時間以上の「価値」

この「半自動化」を導入した結果、テスト実装にかかる時間は体感で約20%短縮されました。数字だけ見ると劇的な変化ではないように見えるかもしれません。しかし、東條さんは「時間短縮以上の価値がある」と語ります。

  1. 並行処理による生産性向上
    AIがコードを書いている間、人間はSlackの返信やBacklogの整理、あるいは他の複雑な実装の考察など、別のタスクをこなせるようになりました。0から1の面倒な記述をAIが肩代わりしてくれることで、脳のメモリを他の業務に割けるようになったそうです。

  2. 品質の向上
    AIとの対話の中で、「そのエッジケースは考慮しましたか？」と逆に指摘されることもあり、一人で書くよりもテストの網羅性が上がったといいます。

おわりに：AIとの協業が当たり前になる未来へ

今回は、新卒2年目が実践する、生成AIを用いたテスト半自動化ワークフローについて紹介しました。今回紹介したワークフローを導入したことで、2025年6月〜2025年12月までに完了するという目標だった予定が、2ヶ月早く終えることができたとのことです。 今後は、このノウハウをチーム全体から開発部署全体に広げつつ、さらなる精度の向上に取り組んでいきたいとのことです。

また、生成AIをテスト自動化以外のことで使っていきたい分野はあるかを聞いてみました。

「勉強に使いたいなと思っています！10時に出勤して、10時〜12時はエージェントに任せている間に、優雅にコーヒーを飲みながら最新技術のキャッチアップに費やしたいなと思ってます。そして、もっと使うエージェントを増やして、10や20匹のAgentに対して指示を出して、操ってみたいなという野望もあります。」

最後に、これからAIを使いこなしたいと考えている後輩や学生エンジニアへのアドバイスをもらいました。

「使いこなし方こそ、生成AIに聞いたら良いと思います！笑。バイブコーディングが流行っていますが、やはり、読む力は引き続き必要になっていくのではないかと思っています。大切なのは、AIに使われるのではなく、使いこなす側になること。AIが出してきた成果物に対して、自分の頭で考え、疑い、責任を持つ。エンジニアとしての『思考力』が、これからの時代こそ重要になると思います。」

AIはあくまでツールであり、最後に品質を保証するのはエンジニア自身です。この当たり前の原則を忘れずに、AIを「賢い部下」のような立ち位置で活用し、協力していくスタイルこそが、これからの開発のスタンダードになっていくのかもしれません。 いま改めて、AIとの向き合い方を意識的に考えることが最も重要だと気付かされました。

以上、新卒2年目が実践するテスト半自動化に関するご紹介でした。

© Safie Inc.