こんにちは。虎の穴ラボの awamo です。
最近はAI コーディング支援ツール「Claude Code」を開発の隙間時間に活用し、自動テストの拡充を進めています。
本記事では、Claude Code を使ってテストファイルの叩き台を生成し、その過程で得られたメリットや現状の課題について共有します。

Claude Code とは

ご存知の方も多いとは思いますが、Anthropic 社が開発した、ターミナル上で動作する AI コーディング支援ツールです。
自然言語での指示を理解し、コードベース全体を横断したコードの生成、バグ修正、テスト作成、Git 操作の自動化など、開発者の作業を強力にサポートしてくれます。

公式サイト:

docs.anthropic.com

活用方法：隙間時間でのテストコード生成

コーディングエージェントは、自分が動けない時にもコードを書いてくれる点で、マルチタスクを行えて便利ですよね。
最近は日々の開発タスクとは別に、ミーティング間の 10 分やデプロイの待ち時間といった短い時間を利用して、テストコードの追加に取り組んでいます。

具体的な手順は以下の通りです。

Claude Code へ依頼: テスト未実装のクラスやモジュールのソースコードを Claude Code に渡し、「このコードに対するユニットテストを生成してください」といった指示を出します。
生成コードのレビューと修正: Claude Code はテストファイルの叩き台を生成しますが、そのままではプロジェクトの規約や検証したい箇所を検証していない場合があります。この叩き台をベースに、必要なアサーションの追加や、テストケースの具体化など、手動で修正を加えます。
テストの実行と確定: 修正したテストが正常に動作することを確認し、社内の開発フローに沿ってマージしていきます。

これを繰り返すことで、これまで後回しになりがちだったテストカバレッジを少しずつ向上させています。

メリット：テスト追加のハードル低下とシステムの堅牢性向上

このアプローチの最大のメリットは、自動テスト追加の心理的・時間的ハードルが大幅に下がることです。

これまでは、どうしても新機能の実装が優先され、テストコードの作成は後回しにされがちでした。
しかし、Claude Code に叩き台を作ってもらうことで、「ゼロから書く」という最も手間のかかる工程を省略できます。
これにより、ほんの数分の隙間時間でも「このメソッドのテストだけ追加しておこう」と気軽に着手できるようになりました。

このようにしてテストコードが着実に増えていくことで、CI によるリグレッションテストの効果が向上します。
新たな変更が既存の機能に予期せぬ影響を与えていないかを自動で検証できる範囲が広がり、結果としてシステム全体の堅牢性が増すことに繋がります。

現時点での評価と課題

この方法は、まとまった開発時間を確保せずとも、継続的にコードベースの改善を進められる点で有効だと感じています。

一方で、いくつかの課題もあります。

ツールの評価: あくまで隙間時間での利用に留まっており、本格的な開発タスクにおける Claude Code の有効性が評価できる使い方ではないと感じています。
プロンプトやユーザー側の習熟度: 意図したテストコードが生成されない原因は、ツール側だけでなくこちら側にもあるかもしれません。私自身がツールを手探りで使用していることも、生成精度が上がらない一因ではないかと考えています。
既存の技術的負債: 責務過多で複雑化したクラスなど、技術的負債を抱えるコードに対して一括でテストコードの生成を試みると、AI の出力精度は著しく低下する傾向があります。これも、精度の高いテストコード作成の障壁となっています。
規約への準拠: 生成されたコードが、プロジェクトで導入している RuboCop のルールに違反するケースが多く、結局手動での修正コストが発生しています。

ただ、これらの課題を考慮しても、テスト拡充が手軽になることとシステムの堅牢性が向上するというメリットは大きいのではないかと考えています。

まとめ

Claude Code のような AI コーディング支援ツールを隙間時間で活用し、テストコードの生成を補助させることで、以下の 2 つの目的を達成できました。

テスト追加のハードルを下げ、継続的なカバレッジ向上を実現
CI によるリグレッションテストを強化し、システムの堅牢性を向上

AI によるコード生成はまだ完璧ではなく、ツールの能力、こちらの習熟度、そして対象コードの品質といった複数の要因に影響を受けます。
しかし、その出力結果を叩き台として利用することで、テストを追加することが面倒な作業ではななくなるという点が、このアプローチの最大の利点なのかな、と考えています。
システム内にテストコードを増やせる箇所もまだまだありそうなので、これからもこのアプローチは続けていくことになりそうです。