ユニットテストは不要なのか?

Last updated at 2026-10-02Posted at 2026-10-02

「ユニットテスト不要論」は、AI時代にはユニットテストの価値が低くなる、という意見です。
英語圏のXでの投稿が日本語圏にも広まり、XやZennで議論されています。
テスト全体をなくすというより、AIが作る意味のないテストを減らし、E2Eで利用者から見た動作を確かめようという主張です。

私は、AIを使う開発でもユニットテストは絶対に必要だと考えています。

AIへの期待が高すぎる

AIがバグのあるコードや質の低いテストを書くと、失敗が目につきます。でも、ミスの割合と件数は分けて考える必要があります。

ミス率が低くても、書く量が多ければミスの数は増えます。人間とAIのミス率は仕事の内容によって変わるので、一律には比較できません。短時間に大量のコードを書くAIを、失敗の件数だけで評価するべきではないと思います。

AIは人間のように振る舞います。私は、人間の開発で使ってきた仕組みやノウハウ、品質管理の方法は、AIにもすべて適用できるはずだと考えています。

ユニットテストも、その一つです。人間がソフトウェアを開発するうえで重要な仕組みなのだから、AIが開発する現場でも使うのは自然です。

人間の同僚を信頼して仕事を任せるように、AIにもコーディング、テスト、レビューを任せたいです。 人間のための仕組みを活かしながら、AIに全部任せられる世界にしたいと思っています。

テストを残せば、コードを変更した後も既存の機能を確認できます。リグレッションを防ぎ、大胆なリファクタリングを進める助けになります。この価値は、コードを書くのが人間でもAIでも変わりません。

TDDやBDDでも、期待する動作を明確にし、確認しながら開発することが大切にされています。

私も、AIにロジックを実装させた後でテストを書かせ、AI自身がバグを見つけたケースを何度も経験しています。

ただし、実装とテストの期待値が同じように間違っていることもあります。テストでは、仕様どおりの結果になることを確認する必要があります。

AIが、バグのある処理を通らないテストや、結果を確認せずに通るだけのテストを書くこともあります。それでも、テストを書くのをやめる必要はありません。

足りないケースの追加や不備の修正、過剰なテストの削除はAIに任せます。素早く修正してもらい、テストが意図した結果を検証していることも確認します。

MetaのACHでも、AIが生成したテストで対象の不具合を検出できることを確認しています。

E2Eで全体の動作を確かめることには賛成です。そのうえで、個々のロジックや連携も、それぞれに合ったテストで確認します。

たとえば、料金計算の境界値はユニットテスト、購入から注文完了までの流れはE2Eで確かめます。細かな条件をすべてE2Eで確認すると負担が大きいので、役割を分けます。

こうしたテストの役割分担は、The Practical Test Pyramidでも紹介されています。

lint、型チェック、静的解析で、ロジックとテストの両方をチェックします。人間は、ケースの抜けや期待値の間違いを確認します。

rules、skills、CLAUDE.mdなどに、テストを書くルールを残します。

書けば必ず守られるわけではなく、私の感覚では努力義務くらいです。それでも、何も伝えないよりはよいと思います。

最近、AIが作ったPRのレビューでは、私はロジックを見ていません。既存のテストを変えずにロジックを修正したPRは、テストが通ればノールックでapproveしています。

テストが変更・追加されるPRでは、テストを読みます。細部までは追わず、ケースの過不足や期待する結果を中心に見ています。ケースがよさそうならOKとし、不足や不備、過剰なテストが見つかればAIに修正を依頼します。

既存のテストで確認していない動作や、テスト自体の誤りを見落とす可能性はあります。それを踏まえても、必要なテストを揃えながら、実装を任せる範囲を広げたいと思っています。

守りたい動作をテストに残し、次の変更でも使います。こうしてテストを積み上げ、人間が毎回コードを全部読む負担を減らしたいです。