QA自動化にClaude Codeを使う方法

QA ワークフローで Claude Code ができること

• プロジェクトの既存のスタイルとフレームワークに合わせて、モジュールのユニットテストを生成する。
• バグ報告を失敗する回帰テストに変換し、テストが通るまでコードを修正する。
• 既存のテストスイートに不足しているエッジケースを追加する（空の入力、Unicode、タイムアウト、同時実行）。
• Playwright または Cypress のエンドツーエンドテストを作成し、ブラウザー MCP サーバーを使って稼働中のアプリに対して実行する。
• 失敗した CI 実行を調査する：ログを読み、原因を特定し、修正を提案または適用する。
• プルリクエストをレビューして、テストされていない実行経路を見つけ、結果を投稿する。

できないのは、何が重要かを判断することです。有用な検証を何も行わないテストでも、ためらわずに行カバレッジ 100% を達成します。出力の品質は指示の品質に左右されます。そのため、以下の設定はプロンプトではなくメモリファイルから始めます。

設定：テストの実行方法を伝える

# CLAUDE.md
## Testing
- Unit tests: `npm test` (vitest). Files live next to the source as `*.test.ts`.
- E2E: `npx playwright test`, specs in `e2e/`. Needs the dev server: `npm run dev`.
- Always run the relevant test file after editing it. Do not mark a test `.skip` to make the suite pass.
- Prefer table-driven tests; one behaviour per `it()`; no snapshot tests for logic.

このブロックによって、推測で動くエージェントが、コントリビューションガイドを読んだ同僚のように振る舞うエージェントに変わります。希望するアサーションのスタイルと、絶対にしてほしくないこと（データベースのモック化、テストのスキップ、誤った出力に合わせたフィクスチャの編集）を追加してください。

仕様やバグ報告からテストを生成する

> Read src/billing/prorate.ts. Write vitest tests covering the documented behaviour in
  docs/billing.md, including month boundaries, leap years and a zero-day period.
  Run them; if any fail, tell me whether the code or the doc is wrong before changing code.

> Bug #412: uploading a 0-byte file returns 500 instead of 400. Write a failing test that
  reproduces it, then fix the handler so the test passes. Do not touch other tests.

各プロンプトの最後の文が重要です。「コードとドキュメントのどちらが間違っているか教えてください」と伝えると、自分が作ったばかりのテストに合わせて、黙って動作を変更するのを防げます。「ほかのテストには手を加えないでください」と伝えると、テストを通すために無関係なアサーションを編集するという典型的な失敗を防げます。

実行と修正のループ

テストを書いた後に実行するよう依頼してください。失敗時の出力を読み、調整し、再実行します。通常は二〜三回の反復で済みます。許可を求めるプロンプトに注意し、 Bash(npm test*) と Bash(npx playwright test*) を一度、次の設定で許可してください： /permissions 。これによりループが中断されなくなります。破壊的なコマンドは、その都度確認する設定にしておいてください。同じテストで四〜五回以上ループする場合は停止してください。テストが誤った内容を検証している可能性が高いため、人間が確認する必要があります。

CI でのヘッドレス実行

# generate regression tests for whatever changed, non-interactively
git diff --name-only origin/main...HEAD | grep -E 'src/.*\.ts$' > changed.txt
claude -p "For each file in changed.txt, add or extend tests for the changed behaviour. Run them." \
  --allowedTools "Read,Edit,Write,Bash(npm test*),Bash(git diff*)" \
  --max-turns 25 --output-format json > claude-qa.json

プリントモードでは質問が一切行われないため、実行する可能性のあるすべての操作を、次の設定で事前に許可する必要があります： --allowedTools、および --max-turns でループの上限を設定します。ANTHROPIC_BASE_URL=https://aiprimetech.io とゲートウェイのキーを CI シークレットとして設定すると、実行料金はゲートウェイの残高または無制限プランに計上されます。結果をブランチにコミットし、人間がレビューするようにしてください。生成されたテストを自動マージしないでください。

すべてのプルリクエストで実行：GitHub Action

Claude Code GitHub Action は、誰かがコメントすると同じループを実行します @claude プルリクエスト上で、または作成時に自動で実行できます。ワークフローに「このPRでテストされていない分岐を確認し、そのテストを追加してください」というQA向けの指示を入れると、レビュアーが確認する前にすべてのPRを一通りチェックできます。GitHubガイドでは、Appのインストール、ワークフローファイル、費用を説明しています。

Playwrightによるエンドツーエンドテスト

利用方法は二段階あります。ブラウザーなしでは、ページ構造と説明からPlaywrightのテスト仕様を作成し、それをユーザーが実行します。Playwright MCPサーバーを接続すると（/mcp）、アプリを開き、クリックしてフローをたどり、DOMを読み取り、実際に確認した内容に合ったテストを作成できます。セレクターの信頼性は大幅に高まりますが、セッションは長くなります。ブラウザーセッションごとに扱うフローは一つに絞り、セッションの合間に /clear してください。スクリーンショットやDOMダンプはサイズが大きく、ターンごとに再送信されます。

QA実行の費用を抑える

• Sonnetのティアを使いましょう。テスト生成でOpusが必要になることはほとんどありません。ログのトリアージにはHaikuのティアで十分です。
• 一度に対象とするのは、一つのモジュールか一つのバグにしましょう。「リポジトリ全体のテストを追加してください」は、最も費用がかかるプロンプトです。
• /compact を、各テストファイルの追加後に実行してください。読み込んだ失敗ログは、その時点ではもう役に立ちません。
• CIでは、上限を設定するために --max-turns を使い、変更されたファイルのみを対象に実行してください。
• 毎日利用するチームなら、定額の無制限プランを使うことで、トークン単位の費用を気にする必要がなくなります。

すべての使い放題プラン →

export ANTHROPIC_BASE_URL=https://aiprimetech.io
export ANTHROPIC_API_KEY=your_key

よくある質問

AI Prime Techは独立したAPIゲートウェイであり、Anthropicとの提携関係はなく、同社の推奨や支援も受けていません。「Claude」と「Claude Code」はAnthropicの商標です。ここで説明するClaude Codeの機能は、執筆時点のAnthropicの公開ドキュメントに基づいており、頻繁に変更されます。このページの料金とモデル一覧は、このゲートウェイの現在の設定から取得しています。