Claude Codeでテストコードを自動生成する方法

Claude Codeを使うと、既存コードの仕様確認、テスト観点の洗い出し、単体テストの作成、異常系テストの追加、モック整理、テスト実行、失敗原因の調査までを効率化できます。この記事では、Claude Codeでテストコードを自動生成する基本手順、プロンプト例、CLAUDE.mdの設定、GitHub Actionsとの連携、注意点まで実務向けにまとめます。

Claude Codeとは

Claude Codeは、コードベース全体を読み取り、ファイル編集、コマンド実行、Git操作、テスト実行などを支援できるAI開発ツールです。

テストコード作成では、次のような作業に向いています。

・既存コードの仕様確認
・テスト対象ファイルの把握
・正常系テストの作成
・異常系テストの作成
・境界値テストの作成
・モックやスタブの作成
・テスト不足の洗い出し
・既存テストの整理
・失敗しているテストの原因調査
・テスト実行コマンドの確認
・Pull Request用の説明文作成

テストコードをゼロから手作業で書くよりも、Claude Codeにたたき台を作らせ、人間が確認・修正する流れにすると効率が上がります。

テストコード自動生成で大事な考え方

テストコードは、ただ数を増やせばよいものではありません。

重要なのは、現在の仕様を守れるテストになっていることです。

Claude Codeに依頼するときは、次の方針を明確にします。

この作業はテストコードの追加です。
実装コードはまだ変更しないでください。
既存の動作を確認し、現在の仕様を守るためのテストを作成してください。

テスト自動生成で特に大事なのは、次の3つです。

・先に仕様を読み取らせる
・テスト観点を出させる
・実装コードを勝手に変更させない

いきなり「テストを書いて」と依頼するより、先に仕様確認とテスト方針を出させる方が安全です。

まずはテスト対象を限定する

Claude Codeにテストコードを作らせるときは、対象範囲を限定します。

悪い依頼例です。

このプロジェクトのテストを全部書いてください。

この依頼では、範囲が広すぎて差分が大きくなります。

良い依頼例です。

src/services/orderService.tsを対象にテストコードを作成してください。
まずはこのファイルの仕様とテスト観点を整理してください。
まだテストコードは作成しないでください。

最初は、1ファイル、1関数、1コンポーネント、1APIなど、小さな単位で始めるのがおすすめです。

既存のテスト環境を確認する

テストコードを作る前に、プロジェクトで使われているテスト環境を確認します。

このプロジェクトのテスト環境を確認してください。
package.json、composer.json、README、Makefile、CI設定を見て、以下を整理してください。

確認すること:
– 使用しているテストフレームワーク
– テストファイルの配置場所
– テストファイルの命名規則
– モックの書き方
– 実行コマンド
– 既存テストの書き方
– 注意すべきルール

まだファイルは変更しないでください。

JavaScriptやTypeScriptなら、Jest、Vitest、Testing Library、Playwrightなどが使われていることがあります。

PHPなら、PHPUnit、Pest、Laravelのphp artisan testなどが使われることがあります。

既存のテストスタイルに合わせることで、チームに馴染むテストコードになります。

テスト対象の仕様を読み取らせる

テストコードを書く前に、Claude Codeに対象コードの仕様を整理させます。

src/services/orderService.tsの仕様を読み取ってください。
まだテストコードは作成しないでください。

出力してほしい内容:
– このファイルの役割
– 公開されている関数
– 各関数の入力
– 各関数の戻り値
– 正常系の動作
– 異常系の動作
– 境界値
– 外部依存
– テスト時にモックすべきもの

仕様を先に整理しておくと、テストの抜け漏れを減らせます。

また、Claude Codeが仕様を誤解していないか、人間が先に確認できます。

テスト観点を洗い出す

仕様確認が終わったら、テスト観点を出させます。

このファイルに対して追加すべきテスト観点を洗い出してください。
まだテストコードは作成しないでください。

観点:
– 正常系
– 異常系
– 境界値
– nullまたはundefined
– 空文字
– 配列が空の場合
– 権限がない場合
– 外部APIが失敗した場合
– DB保存に失敗した場合
– 例外が発生した場合

出力形式:
– テスト名
– 目的
– 入力値
– 期待結果
– 優先度

Claude Codeにテスト観点を出させると、「何をテストするのか」が明確になります。

コードを書かせる前に観点を確認することで、不要なテストや意味の薄いテストを減らせます。

正常系テストを自動生成する

最初は、正常系テストから作成します。

先ほどのテスト観点のうち、正常系テストを作成してください。

条件:
– 既存のテストスタイルに合わせる
– テスト名は動作がわかる名前にする
– 実装コードは変更しない
– 必要なモックは最小限にする
– テスト追加後に変更内容を要約する

正常系テストでは、代表的な成功パターンを押さえます。

たとえば、注文金額を計算する関数なら、次のような観点があります。

・商品が1つの場合
・商品が複数ある場合
・割引がある場合
・送料がある場合
・税込価格を計算する場合

テスト名は、あとで読んでも意味がわかる名前にします。

calculateTotal returns total price when order has multiple items

日本語のテスト名を使っているプロジェクトなら、既存の書き方に合わせます。

注文商品が複数ある場合、合計金額を返すこと

異常系テストを自動生成する

正常系だけでは、実務で起きる不具合を防ぎきれません。

異常系テストも追加します。

この関数に対して異常系テストを追加してください。

確認したいケース:
– 必須項目がない
– 不正な値が渡される
– nullが渡される
– 空配列が渡される
– 外部APIが失敗する
– DB保存に失敗する
– 権限がない
– 例外が発生する

条件:
– 既存のエラーハンドリング仕様に合わせる
– 実装コードは変更しない
– 期待するエラー内容を明確にする

異常系テストでは、次の点を確認します。

・例外を投げるのか
・falseを返すのか
・エラーオブジェクトを返すのか
・ログだけ出すのか
・画面にエラー表示するのか

既存仕様を変えずに、その仕様をテストすることが重要です。

境界値テストを自動生成する

バグは境界値で起きやすいです。

Claude Codeには、境界値を洗い出してテスト化させます。

この処理の境界値を洗い出し、必要なテストを追加してください。

確認する境界値:
– 0
– 1
– 最大値
– 最小値
– 空文字
– 文字数上限
– 日付の開始日
– 日付の終了日
– 税率や割合の端数
– 小数点
– 丸め処理

条件:
– 仕様を変更しない
– 既存の丸め処理に合わせる
– テスト名で境界条件がわかるようにする

金額計算、日付計算、在庫数、数量、文字数制限などは、境界値テストが特に重要です。

モックとスタブを整理する

外部API、DB、メール送信、ファイル操作などに依存する処理は、モックが必要になります。

このテストで必要なモックを整理してください。
まだテストコードは作成しないでください。

確認すること:
– モックすべき外部依存
– モックしない方がよい処理
– 既存テストで使われているモック方法
– テストごとの初期化方法
– テスト間で状態が漏れないようにする方法

モックを作成させる場合です。

既存テストの書き方に合わせて、必要最小限のモックを作成してください。

条件:
– 外部APIは実際に呼び出さない
– メールは実際に送信しない
– DB更新はテスト用の仕組みに合わせる
– テスト間でモック状態をリセットする

モックしすぎると、実際の動作と離れたテストになります。

Claude Codeには「必要最小限」と明記しておくと安全です。

Reactコンポーネントのテストを作る

Reactコンポーネントでは、表示、クリック、入力、エラー表示などをテストします。

UserProfileコンポーネントのテストを作成してください。

確認すること:
– ユーザー名が表示される
– ローディング中の表示
– ユーザー情報がない場合の表示
– エラー時の表示
– ボタンクリック時の動作

条件:
– Testing Libraryの既存スタイルに合わせる
– 実装コードは変更しない
– ユーザー操作はuserEventを使う
– 実装詳細ではなく画面上の振る舞いをテストする

JSXを記事やWordPressに貼る場合、HTMLとして展開されないように、コード内のタグはエスケープします。

render(<UserProfile user={mockUser} />)

expect(screen.getByText(“山田太郎”)).toBeInTheDocument()

POST /api/orders のテストを作成してください。

確認すること:
– 正しいリクエストで注文を作成できる
– 必須項目がない場合は400を返す
– 未ログインの場合は401を返す
– 権限がない場合は403を返す
– 存在しない商品IDの場合は404を返す
– DB保存に失敗した場合は500を返す

条件:
– 既存のAPIテストの書き方に合わせる
– レスポンス形式を既存仕様に合わせる
– 実装コードは変更しない

APIテストでは、次のような観点が重要です。

・ステータスコード
・レスポンスJSON
・エラーメッセージ
・DBに保存された値
・権限チェック
・バリデーション
・副作用

特に認証・認可は、テスト不足が事故につながりやすい箇所です。

テスト生成用プロンプト集

仕様確認用です。

このファイルの仕様を読み取ってください。
まだテストコードは作成しないでください。
入力、出力、正常系、異常系、境界値、外部依存を整理してください。

テスト観点洗い出し用です。

この処理に必要なテスト観点を洗い出してください。
正常系、異常系、境界値、権限、外部依存の失敗を含めてください。

単体テスト作成用です。

この関数の単体テストを作成してください。
既存のテストスタイルに合わせ、正常系、異常系、境界値を含めてください。
実装コードは変更しないでください。

Reactテスト作成用です。

このReactコンポーネントのテストを作成してください。
表示、クリック、入力、エラー表示を確認してください。
Testing Libraryの思想に合わせ、実装詳細ではなくユーザーから見える振る舞いをテストしてください。

APIテスト作成用です。

このAPIエンドポイントのテストを作成してください。
正常リクエスト、バリデーションエラー、未認証、権限不足、存在しないデータ、サーバーエラーを確認してください。

失敗原因調査用です。

テストが失敗しています。
まだ修正しないでください。
失敗原因がテストコード側にあるのか、実装コード側にあるのかを分けて整理してください。

差分レビュー用です。

今回追加したテストコードをレビューしてください。
意味のあるテストになっているか、実装詳細に依存しすぎていないか、不要なモックがないか確認してください。

自動生成されたテストで注意すること

Claude Codeが生成したテストは、必ず人間が確認します。

特に注意する点です。

・テストが実装に合わせすぎていないか
・本当に仕様を守るテストになっているか
・モックしすぎて意味が薄くなっていないか
・期待値が間違っていないか
・テスト名と内容が一致しているか
・正常系だけに偏っていないか
・異常系が不足していないか
・境界値が抜けていないか
・外部APIを実際に呼んでいないか
・本番データに接続していないか
・テストを通すためだけの不自然な実装変更がないか

AIが作ったテストは、一見それらしく見えることがあります。

しかし、期待値が間違っていると、間違った仕様を固定してしまいます。

テストコードは「正しさを保証するもの」なので、実装コード以上に慎重に確認します。

テストコード生成後のチェックリスト

Claude Codeでテストを作成した後は、次の項目を確認します。

・テスト対象は明確か
・テスト名はわかりやすいか
・正常系があるか
・異常系があるか
・境界値があるか
・認証や権限の確認があるか
・外部依存を適切にモックしているか
・モックしすぎていないか
・テスト間で状態が漏れていないか
・実装コードを不要に変更していないか
・テストは実行済みか
・失敗時の原因を確認したか
・PR説明文にテスト内容を書いたか

Claude Codeに確認させる場合です。

今回追加したテストコードをチェックしてください。

確認項目:
– テストの目的が明確か
– 正常系、異常系、境界値が含まれているか
– モックが適切か
– 実装詳細に依存しすぎていないか
– 実装コードを不要に変更していないか
– 人間が確認すべき点は何か

まとめ

Claude Codeを使うと、テストコード作成の作業を大きく効率化できます。

特に、既存コードの仕様確認、テスト観点の洗い出し、正常系・異常系・境界値テストの作成、モック整理、失敗原因の調査に向いています。

安全に使うには、いきなりテストを書かせるのではなく、まず仕様確認、次にテスト観点の整理、その後に小さな単位でテストコードを作成する流れが有効です。

CLAUDE.mdにテスト作成ルールを書き、実装コードを勝手に変更しないように指示し、生成されたテストは必ず人間が確認します。

Claude Codeは、テスト作成を丸投げする道具ではなく、テスト設計と実装の手間を減らす補助ツールとして使うのが現実的です。】