生成AI時代に重要なテスト基盤の整え方(ATDD/BDD)

ATDD・BDDをスターターキットに入れておく理由

新しい機能を追加したのに、以前は問題なく動いていた処理が壊れてしまう。開発担当の方なら、一度は経験があるのではないでしょうか。

機能が増えるほど、どこかで思わぬ影響が出やすくなります。

そこで私たちが重視しているのが、最初からテスト基盤を整えることです。

特に生成AIを活用した開発では、実装のスピードが上がる一方で、変更の影響範囲を見落としやすくなる場面もあります。

だからこそ、ATDDやBDDのような考え方を、開発の初期段階から仕組みとして組み込むことが大切です。

テストを先に考えると、開発は安定しやすい

TDD、つまりテスト駆動開発は、先にテストを書き、失敗を確認してから実装を進める方法です。

いきなり完成形を作るのではなく、「まず壊れている状態」を明確にしてから進めていきます。

この流れには、レッド・グリーン・リファクタリングがあります。

最初に失敗を確認し、次に動く状態へ持っていき、最後にコードを整理して保守しやすく整えます。

単に動けばよいのではなく、後から見直せる形にする点が重要です。

私たちが特に意識しているのは、回帰です。

新機能の追加や修正のたびに、既存機能が動かなくなると、開発全体の信頼性が下がってしまいます。

テストは、その不安を早い段階で見つけるための土台になります。

ATDDは「ユーザーの使い方」から設計する考え方

ATDDのAはAcceptance、受け入れを意味します。

これは、実際の利用者がどう操作するかを前提にしたテストです。

たとえばログイン機能なら、メールアドレスを入力し、パスワードを入れて、ボタンを押す。

その結果としてログインできることを確認します。

この考え方の良いところは、画面や処理がユーザー目線で整理されることです。

仕様書のためのテストではなく、「この操作なら、この結果になるはず」という形で確認できます。

結果として、実装の目的もぶれにくくなります。

また、ATDDのテストが先にあると、後から機能を追加しても既存の受け入れ条件を守りやすくなります。

どこまでが正常で、どこからが異常なのかが明確になるため、品質確認の基準としても機能します。

BDDは、振る舞いを文章で残せるのが強みです

BDDのBはBehaviour、振る舞いです。

こちらは、システムがどう動くべきかを文章で表現し、そのままテストへ落とし込んでいく考え方です。

実装者だけでなく、関係者が見ても意図を追いやすいのが特徴です。

たとえば、前提条件、操作、期待結果を順番に書いていくと、テストの内容がかなり読みやすくなります。

`describe` で前提を示し、`when` で操作を表し、`then` で結果を確認する形は、その代表例です。

何を検証しているのかが見えやすいのは大きな利点です。

場合によっては、GIVEN・WHEN・THENのようなGherkin記法を使う選択肢もあります。

非エンジニアにも理解しやすい一方で、設定や運用が少し複雑になることもあります。

スターターキットでは、まずシンプルさを優先する判断も有効です。

Claude Codeでテスト基盤を整えるときのポイント

生成AIを使った開発では、テスト作成そのものもAIに支援してもらえるようになりました。

これは、以前と比べて大きな変化です。

テストを書く負担が軽くなったことで、「最初から仕組みに入れる」判断がしやすくなっています。

私たちがスターターキットに入れたいのは、ATDD・BDDのワークフローを前提にした開発環境です。

Claude Codeにベストプラクティスを調べさせ、実際に使える形へ落とし込む。

さらに、CLAUDE.mdなどの設定にも反映し、別エージェントでも同じルールで扱えるようにします。

加えて、テストランナーやサブエージェント、Playwrightを使ったE2Eテストの基盤も整えておくと安心です。

フロント側の単体・結合・画面遷移まで含めて確認できれば、開発後半での不具合発見にもつながります。

サンプルテストや型定義、ヘルパーの準備も、後の運用を助けます。

プランファイルの保存場所も、実は大事です

開発を進める中で見落とされやすいのが、計画ファイルや設定ファイルの置き場所です。

たとえば `.claude/settings.local.json` に`plansDirectory` を指定しておくと、プロジェクトごとにプランを分けて管理できます。

一見すると小さな話ですが、複数プロジェクトを扱う環境ではかなり重要です。

どの計画がどの案件のものか分からなくなると、後から見返すときに混乱しやすくなります。

設定を整理しておくことは、開発の再現性にもつながります。

こうした周辺整備は、派手ではありません。

ただ、実際の現場ではこうした細部が品質を支えます。

テスト基盤、設定管理、エージェント間のルール共有。

この3つが揃うと、開発の安定感は大きく変わります。

テイルウインドが支援できること

テイルウインド株式会社では、生成AIを活用した開発環境の整備や、中小企業向けのシステム開発支援を行っています。

単にツールを導入するだけでなく、業務に合わせて運用できる形に落とし込むことを大切にしています。

たとえば、次のようなご支援が可能です。

生成AI導入支援

Webコンサルティング

クリエイティブ制作

システム開発

IT人材育成

また、弊社は熊本発・生成AI×ITで、中小企業のデジタル化を伴走支援しています。

Udemyでは10万人超の受講実績もあり、実務に役立つ形で知見をお届けしています。

まとめ

ATDDは、ユーザーの受け入れ基準から考えるテスト手法です

BDDは、システムの振る舞いを文章化しやすい考え方です

TDDの基本は、レッド・グリーン・リファクタリングの流れです

生成AIを使うことで、テスト整備の負担は以前より軽くなっています

テスト基盤と設定管理を最初に整えると、回帰対策に強くなります

開発が進むほど、品質を保つための仕組みは重要になります。

私たちも、生成AI時代の開発では「動くこと」だけでなく、「壊れにくく、続けやすいこと」が大切だと考えています。

お問い合わせ

生成AIを活用した開発体制の整備や、テスト基盤の構築、業務に合わせたシステム開発をご検討の方は、ぜひ一度テイルウインド株式会社へご相談ください。