単体テスト × 生成AI ― Claude Code で試験工程を回してみた実践レポート

なぜ試験工程でAIを活用するのか？

試験工程は、実装と仕様の両方をしっかり理解しないといけないうえに、テスト観点の整理・仕様書作成・手順の文章化のようなドキュメント作成の負荷が大きい工程です。私自身、観点整理と実装の把握、そしてテストそのものにいちばん時間を取られていました。

対象の画面数・件数も多いので、「なんとか工数と確実性を両立できないか？」というのがClaude Codeを触り始めた動機です。

実際にやったこと（作業フロー）

普段の作業の流れをざっくり紹介すると、以下のような感じです。

1. git fetchなどで実装ファイルを最新化する
2. Claude Codeでテスト仕様書の叩き台を作る
3. 出力を確認する（全体、そして個々のテストケース単位）
4. Claude Codeで修正する

「出力確認」と「修正」は、セルフレビューと他者レビューを通るまで、繰り返します。

設計書はあくまで参考程度にとどめて、実装の方を「正」としています。Claude Codeは実装内容をずっと覚えていてくれるわけではないので、実装コードはその都度読み込ませるようにしています。

最初にお手本として使うテスト仕様書は、自分で一通り書いてレビュー・修正まで終えたものを選びました。Claude Code経由で作ったテスト仕様書がある程度たまってからは、「AとBというテスト仕様書を参考に、この機能のテスト仕様書を作って」くらいのシンプルな指示だけで、横展開できるようになりました。凝ったプロンプトを組まなくても、完成済みのサンプルを2〜3件見せるだけで十分応用が効く ― これは自分でやってみて意外な発見でした。

ファイル形式はCSVを選んでいます。スプレッドシートは認証を挟む必要があり、ExcelだとPythonでの読み書きが入る分、余計な不確定要素が増えそうだったので、どちらも見送りました。CSVならPythonやBashで確認するときも不確定要素が少なく、プロジェクトのgitリポジトリでそのまま管理できるところも決め手になっています。

AIに任せる範囲、任せない範囲

Claude Code（Sonnet）を使ってみると、「テスト観点の整理」と「手順の文章化」はかなり精度が高いと感じます。一方で「テストケースの草案」「仕様書の下書き」は、正直まだ精度がいまいちだと感じることが多いです。

原因をたどっていくと、その多くは 「テスト観点の整理」の段階で認識がずれていたことに行き着きます。できるだけ序盤で観点をすり合わせておくことがいちばん効果的です。

明確に「ここはAIに任せない」と決めている作業はありませんが、Claude Codeが実装を理解できていないと感じたときは、目視の確認に切り替えるようにしています。特にテストケースを修正するときに、実装との食い違いに気づくケースが多かったです。

またCSVで渡した内容をスプレッドシートに転記するときに、列がずれたり値が抜け落ちたりすることがあり、これはClaude自身が気づくこともあれば、気づかないこともあります。結局のところ人の目でチェックすることが欠かせない、というのが実感です。

精度の課題とどう向き合うか

体感としては、だいたい10件中2件ほどの頻度で誤りが出ます。多くは実装との食い違いが原因で、要因はおおむね次の2つです。

• 仕様変更にテスト仕様書側が追いつけていなかった
• 実装差分（diff）で最新状態を把握させる際、直前の実装理解が甘くなっていた

誤りはレビュアーの指摘で気づくことが多いですが、共通実装や横展開した実装では、数をこなすうちに 生成段階である程度気づけるようになってきました。

精度を上げるための指示出しは、たとえばこんな感じです。

No.hogeのfugaという記述が実装と異なっているように思います。実装を確認し、認識相違がないか確認してください。

このように、疑わしい箇所を ピンポイントで指摘して、実装との突き合わせを再依頼する方法を繰り返しています。断定的な言い方を避けているのは、断定するとClaudeが先入観を持って強引に解釈する可能性があるからで、あくまで判断そのものはClaude側に委ねるようにしています。

実際、取り組みの序盤ではこの手の食い違いが何度も起きました。Claudeが「実装はこうなっているはずだけど、テスト仕様書の記述と食い違いがある」と指摘してきたときに、有識者に確認すると「実装の方が正しい」という結果が続き、そのたびに判断を仰いでいました。最終的に 「実装を正とする」という方針をはっきりさせてからは、目立った混乱はなくなっています。

モデルと設定 ― Sonnet か Opus か

モデルはSonnet（Claudeの中位モデル）を使っています。Opus（最上位モデル）も試してみたのですが、精度は上がるもののトークン消費が大幅に増える一方、壁打ちの回数はせいぜい1回減るくらいで、正直コストには見合わないと判断しました。

壁打ちを重ねながら精度を上げていくスタイルなら、Sonnetで十分 というのが今の実感です。もちろん案件の性質や、扱う仕様書の複雑さによって最適解は変わると思うので、ここは「Sonnetで走らせる/要所でOpusに切り替える」といったハイブリッド運用も選択肢だと感じています。

これからと、他のメンバーへの展開

今のところ、この取り組みは私一人でやっており、チームへの展開はまだできていません。もし他のメンバーが同じことをやる場合、最低限Claude Codeの基本的な使い方がわかっていることと、実装をいつでも共有できる環境さえあれば始められると思います。

つまずきやすいのは、プロンプトのちょっとしたニュアンスの違いで、生成物の精度に差が出るところです。プロンプトの幅を絞っておかないとClaudeが自由に解釈するので、「誤解させない」指示の出し方が大事だと痛感しています。

運用面でのちょっとした工夫として、Claudeに読み込ませるパスに「これは実装です」「これはテスト仕様書です」と、あらかじめコンテキストを読み込ませ、対応する変数名を定めておくようにしています。同じセッションの中であればClaudeがその役割をローカルメモリに覚えて、実装やテスト仕様書を取り違えるリスクを防げます。

まとめ ― 「工数削減」よりも「網羅性の資産化」

正直に言うと、これは 「自動でできる」というより「たたき台を作ってもらう」 くらいの感覚です。仕上がったものの手直しやレビューにはまだまだ人の手がかかっていて、トータル工数で見ると、最初に見積もっていたよりも むしろ増えている、というのが実感です。「AIを使えば工数が減りました」という分かりやすい成功談ではありませんでした。

それでも「やってよかった」と思えるのは、一人では見落としがちなテスト観点まで拾い出せること、そしてその観点を他に横展開することで、全体のテストの抜け漏れを防ぎ網羅性を高められる部分です。特にリグレッションテストとして積み上がっていくことが資産になる感覚があり、そのあたりの効果はもう少し具体的に見せられるようにしていきたいと思っています。

設計書か実装、どちらかにテストのベースとなるものさえあれば、始めるハードルはそれほど高くないはずです。まだまだ手探りなので、試験工程でAIを活用している方がいれば、ぜひ使い方を共有できると嬉しいです。