AI開発アンチパターン 2025年5月21日

テスト省略の代償:AI開発でもテストが必須な理由

vibe codingで最も多い誤解の一つがこれです。 「AIが生成したコードは、動作確認したからテスト不要」 この考えは、**致命的な誤り** です。 vibe coderがテストを省略する理由があります。

川西智也

合同会社ロイヤルピース 代表

アンチパターン⑥「テスト省略」

AI開発の落とし穴:「動いたからテスト不要」

vibe codingで最も多い誤解の一つがこれです。

「AIが生成したコードは、動作確認したからテスト不要」

この考えは、致命的な誤り です。


なぜテストを省略するのか

vibe coderがテストを省略する理由があります。

理由1: 時間の節約

  • テストを書く時間がもったいない
  • その時間で新機能を作れる

理由2: AIへの過信

  • 「AIが正しいコードを書いたはず」
  • 「エラーが出なかったから大丈夫」

理由3: テストの書き方が分からない

  • vibe coderの多くは非技術者
  • テストの概念自体を知らない

理由4: 目の前の動作確認で満足

  • ブラウザで動いた
  • それで十分だと思う

AI開発でテストがない世界の危険性

テストがないコードベースで何が起きるか見てみましょう。

シナリオ:

Day 1: 機能Aを実装、動作確認OK
Day 3: 機能Bを追加、動作確認OK
Day 7: 機能Cを追加、動作確認OK
Day 10: 機能Dを追加、動作確認OK
Day 14: 機能Aが動かなくなっている
       → いつから?なぜ?
Day 15-30: デバッグ地獄

テストがあれば、機能BやCを追加した時点で、機能Aの破壊に気づけたはずです。


AI生成コードのリグレッションの恐怖

リグレッション とは、以前動いていた機能が動かなくなることです。

vibe codingでは、リグレッションが頻発します。

理由:

  1. AIは既存コードを理解していない
  2. 変更の影響範囲を把握していない
  3. 「新しい機能」に集中し、既存機能を壊す

テストがなければ、リグレッションに気づくのは ユーザーからの報告 になります。


AIにテストを書かせる

「テストを書く時間がない」なら、AIにテストを書かせましょう

プロンプト例:

以下の関数のユニットテストを書いてください:
- 正常系のテスト
- 異常系のテスト(null入力、空配列など)
- 境界値のテスト

AIはテストを書くのも得意です。機能と一緒にテストを生成させましょう。


テストファーストのアプローチ

さらに効果的なのは、テストファースト のアプローチです。

手順:

  1. まずテストを書く(AIに書かせる)
  2. テストが失敗することを確認
  3. 機能を実装(AIに書かせる)
  4. テストが通ることを確認

このアプローチには複数のメリットがあります。

メリット:

  • 仕様が明確になる
  • テスト漏れがない
  • リグレッションに即座に気づける
  • AIへの指示が具体的になる

最低限のテストカバレッジ

すべてをテストする必要はありません。最低限のテストカバレッジ を目指しましょう。

優先度の高いテスト:

優先度対象理由
認証・認可セキュリティに直結
決済処理金銭に直結
データ保存・更新データ損失に直結
バリデーション不正入力の防止
ビジネスロジック正確性の担保
UI表示視覚的に確認可能

すべてを100%カバーする必要はありませんが、重要な部分は必ずテスト しましょう。


テストの種類

テストにはいくつかの種類があります。

ユニットテスト:

  • 個別の関数をテスト
  • 最も書きやすい
  • 最も高速

統合テスト:

  • 複数のコンポーネントをテスト
  • APIエンドポイントのテスト
  • データベースとの連携テスト

E2Eテスト:

  • ユーザー操作をシミュレート
  • 実際のブラウザでテスト
  • 最も現実に近い

vibe codingでは、最低限 ユニットテスト は書きましょう。


CIでの自動実行

テストは 自動で実行 されるべきです。

GitHub Actions の例:

name: Test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm install
      - run: npm test

これにより、変更をプッシュするたびにテストが実行されます。テストが失敗すれば、マージを止められます。


「テストがないコードは、壊れていないことを証明できない」

ソフトウェア工学の格言があります。

「テストがないコードは、壊れていないことを証明できない」

「動いた」という確認は、その瞬間の、そのケースで 動いたことしか証明しません。

テストがあれば、継続的に 動いていることを証明できます。


この事例から学ぶべき教訓

「テスト省略」から学ぶべきことは以下の通りです。

  1. 「動いた」はテストの代替にならない

    • その瞬間、そのケースでしか証明できない
  2. リグレッションは頻発する

    • テストなしでは気づけない
  3. AIにテストを書かせる

    • 時間がないなら、テストもAIに
  4. テストファーストを検討

    • 仕様が明確になる
  5. CIで自動実行

    • 人間が忘れてもシステムが実行

まとめ:重要ポイントの振り返り

  • 「動いたからテスト不要」は 致命的な誤り
  • テストなしでは リグレッション に気づけない
  • AIにテストを書かせる ことで時間を節約
  • テストファースト で仕様を明確に
  • CIで自動実行 、人間が忘れてもシステムが実行
  • 教訓:テストがないコードは、壊れていないことを証明できない

実践的なスキルを習得しませんか?

ブログで学んだ知識を、研修で実践に変えましょう。