Tutorials

コード品質の自動化:Claude Skillsでテストの作成・修正・レビューを行う

Claude Skillsを使用してテスト作成、テスト修正、コードレビューを自動化する方法を学びましょう。2025年にClaude Codeを使用するチームのための実践的なガイドと例。

Claude Skills TeamMarch 10, 202610 min read
#testing#code-review#automation#code-quality#tdd
コード品質の自動化:Claude Skillsでテストの作成・修正・レビューを行う

手動でのコード品質作業の隠れたコスト

すべてのエンジニアリングチームは、各スプリントの相当な部分を、必要だが完了しない作業に費やしています:新しいコードのテスト作成、リファクタリング後に壊れたテストの修正、マージ前のプルリクエストのレビュー。これらは任意の活動ではなく、チームがコードベースへの信頼を維持する方法です。しかし手動で行うと、遅く、一貫性がなく、締め切りが迫ると最初に省かれるものです。

Claude Skillsはこれに直接対処します。目的に特化した小さなスキルセット — write-testsfix-testsreview-prreview-local-changes — が、ローカルマシン上のClaude Code内で動作する完全なコード品質自動化レイヤーを形成します。品質ループの中で最も時間のかかる部分を処理し、本当に人間の判断が必要な決定にチームが集中できるようにします。

このガイドでは、各スキルの動作、それらがどのように組み合わさるか、そしてより高品質なコードをより速く出荷する開発ワークフローに統合する方法を説明します。


write-tests:大規模な自動テスト生成

write-testsスキルは、あらゆるコードベースで最も一般的なギャップを解決します:テスト作成に機能実装とほぼ同じ時間がかかるため、十分なテストカバレッジなしで出荷されるコードです。

/write-testsを実行すると、スキルはまずテストインフラストラクチャを検出します。既存のテスト設定ファイル(jest.config.jspytest.inigo.modなど)を読み取り、使用中のテストパターンを特定し、カバーしたいファイルをマッピングします。この検出フェーズにより、生成されたテストはチームがすでに確立した規約に一致します — 同じファイル命名、同じアサーションスタイル、同じモックパターンです。

検出後、write-testsはスコープ内の各モジュールまたは関数のテストを書くために並列サブエージェントを派遣します。エージェントが並列に実行されるため、10ファイルのモジュールのカバーは1ファイルのカバーとほぼ同じ時間で完了します。各エージェントはテスト対象関数の完全なコンテキスト、スタイル参照としての既存テスト、エッジケース、エラーパス、境界条件のテストに関する明示的な指示を受け取ります — ハッピーパスだけではありません。

出力は、レビュー、実行、コミットできるテストファイルのセットです。スキルは動作を発明しません。コード内の実際の関数シグネチャとdocstringからテストを導出します。

# 例:特定のモジュールでwrite-testsを実行
# スキルをインストールした後、Claude Code内で:
/write-tests src/payments/processor.ts

# スキルは以下を行います:
# 1. プロジェクト設定からJest + TypeScriptを自動検出
# 2. processor.tsを分析:関数、型、エラーハンドリング
# 3. ユニットテスト + 統合テスト用の並列エージェントを派遣
# 4. src/payments/processor.test.tsを作成
# 5. テストスイートを実行してすべての新しいテストがパスすることを確認

レガシーコードベースを持つチームにとって、write-testsはカバレッジ改善スプリント中に特定のディレクトリを指定して使用するのが特に便利です。


fix-tests:失敗するテストスイートの体系的な修復

リファクタリングはテストを壊します。依存関係のアップグレードはテストを壊します。単純なリネームでさえ、数十の失敗するスペックにカスケードする可能性があります。fix-testsスキルはまさにこの状況のために存在します。

スキルは自動検出から始まります:テストスイートを実行し、すべての失敗するテストを収集し、失敗タイプごとにグループ化します — アサーションの不一致、欠落したモック、型エラー、変更されたAPIシグネチャ。グループ化が重要なのは、ほとんどの壊れたテストスイートには少数の根本原因があり、1つのタイプの失敗を修正すると一連のテストが解決されることが多いからです。

# 例:リファクタリング後のすべての失敗するテストを修正
/fix-tests

# 出力サマリー(例):
# 8ファイルにわたる23の失敗するテストを検出
# 3つの失敗タイプにグループ化:
#   - APIシグネチャの変更(14テスト)
#   - 欠落したモックセットアップ(6テスト)
#   - 型アサーションエラー(3テスト)
# 3つの並列修復エージェントを派遣中...
# スイートの再実行:0失敗
# すべてのテストがパス。コミット前に変更をレビューしてください。

重要な設計上の選択:fix-testsはスイートをパスさせるためにテストの削除やアサーションの弱体化を拒否します。アサーションを変更しなければテストを修正できない場合、スキルはカバレッジを静かにダウングレードするのではなく、人間のレビュー用にフラグを立てます。


playwright-skillによるブラウザテスト

Webアプリケーションを構築するチームにとって、テストカバレッジはユニットテストを超えて実際のブラウザ動作にまで拡張する必要があります。playwright-skillは、Claude Codeワークフローにブラウザ自動化を直接追加します。

Playwright Skillは実行中の開発サーバーを自動検出し、E2Eテストセットアップの最もフラストレーションな部分を排除します。ユーザーフロー(ログイン、設定に移動、設定を更新、変更が永続化されていることを確認)を説明すると、適切なセレクター、アサーション、リトライロジックを備えた構造化されたPlaywrightテストを生成します。


review-local-changesとreview-pr:マルチエージェントコードレビュー

テストの作成と保守は品質ストーリーの半分にすぎません。もう半分は、本番環境に到達するコードが徹底的にレビューされていることを確認することです。

review-local-changesreview-prは、構造化されたマルチエージェントのコードレビューをClaude Codeに持ち込みます。

両スキルとも、6つの専門レビュアーエージェントを並列に派遣し、それぞれが異なる品質の次元に焦点を当てます:

  • セキュリティレビュアー:OWASP Top 10の脆弱性、コード内のシークレット、インジェクションリスクを確認
  • バグレビュアー:ロジックエラー、オフバイワン条件、null参照を特定
  • 品質レビュアー:命名、構造、DRYコンプライアンス、複雑さを評価
  • コントラクトレビュアー:APIコントラクトがドキュメントと呼び出し元に一致するか検証
  • テストレビュアー:カバレッジギャップと間違った理由でパスするテストを特定
  • 履歴レビュアー:以前修正された問題に対するリグレッションを確認
# 例:review-prの出力構造
review:
  pr_number: 142
  summary: "Payment processorリファクタリング — 3件のクリティカル、7件の中程度、12件の低い発見"
  findings:
    - severity: critical
      agent: security
      file: src/payments/processor.ts
      line: 87
      message: "ユーザー制御の入力がSQLクエリに直接使用されています。パラメータ化してください。"
    - severity: moderate
      agent: testing
      file: src/payments/processor.test.ts
      line: 34
      message: "テストはステータスコードをアサートしていますがレスポンスボディはアサートしていません。部分的なカバレッジです。"
    - severity: low
      agent: quality
      file: src/payments/utils.ts
      line: 12
      message: "関数`buildPayload`は45行目の`formatRequest`のロジックを重複しています。"

完全な品質ワークフローの構築

これらの4つのスキルは、パイプラインとして一緒に使用すると最も効果的です:

  1. 新しいコードを書いた後、/write-testsを実行して初期カバレッジを生成。
  2. リファクタリングの後、/fix-testsを実行して壊れたスペックを修復。
  3. コミット前に、/review-local-changesを実行して問題を早期にキャッチ。
  4. マージ前に、/review-prを実行して構造化されたインラインコメントを投稿。

このパイプラインは外部のCI設定、追加サービス、エディタ外へのコンテキストスイッチを必要としません。


はじめに

これらのスキルのいずれかを、Claude Skills Hubから.mdファイルをダウンロードし、プロジェクトの.claude/skills/ディレクトリ(またはすべてのプロジェクトで使用するグローバルな~/.claude/skills/ディレクトリ)に配置してインストールしてください。ほとんどのプロジェクトで追加設定は不要です。スキルがテストフレームワークとコード構造を自動的に検出します。

コード品質は開発の最後にあるチェックポイントではなく、作業の継続的な特性です。これらのスキルにより、その特性をより維持しやすくなります。

Skills in This Post

Related Posts