こんにちは！長内です。
私が所属するチームでは、インフラ構築の自動化（IaC）を進めながら、開発品質の向上とチームの成長を目指してきました。そんな中で、「TDDのエッセンスを取り入れた開発スタイル」と「生成AIの全面活用」を組み合わせた新しい開発体制への移行を検討しています。
本ブログでは、これから挑戦していくにあたって考えていることを備忘録としてまとめました。まだ検討段階の内容も多いですが、一つの参考として読んでいただければ幸いです。
なお、ここで言う「TDD」は、厳密なRed ➔ Green ➔ Refactorサイクルを全場面で徹底するという意味ではありません。「先にテスト（仕様）を考える」「テストをAIへのインプットとして使う」といったTDDの考え方を、無理なく取り込んでいくイメージです。
1. IaC（Infrastructure as Code）とTDD
「インフラ開発でTDD（テスト駆動開発）って本当にワークするの？」
多くの方が最初に抱く疑問ではないでしょうか。
従来のインフラ開発でTDDを回そうとすると、いくつかの壁があります。テストのたびに実際のクラウド環境にデプロイしていると数分〜数十分かかり、TDDのリズムが崩れてしまいます。また、LocalStack等のローカル環境でのテストは実際のIAMポリシーの挙動などを100%再現できず、メンテナンスコストが膨らみがちです。
チームで採用しているAWS CDKには、実際のデプロイを伴わずにCloudFormationテンプレートの構造を検証する「Fine-grained Assertions」という仕組みがあり、ユニットテストを数秒で実行できます。これを使えば、インフラ開発でもTDDのエッセンスを活かせるのではないかと考えています。
2. 生成AI × IaC × TDD の相乗効果
今回「生成AIの全面活用」へ移行するにあたって、TDDのエッセンスと組み合わせることで相乗効果が生まれるのではないかと考えています。現時点での仮説ですが、以下の3点が特に大きいと思っています。
① テストコードが「AIへの厳密なプロンプト」になる
生成AIにインフラコードを書かせる際、日本語の指示文だけでは解釈のブレやハルシネーション（嘘のコード）が起きがちです。先に「期待するリソースの構造」を定義したテストコードを渡し、「このテストをパスするコードを書いて」と指示すると、AIの出力精度がかなり上がる印象があります。
② AIの弱点（ハルシネーション・巨大な手戻り）を抑えられる
生成AIは、一度に巨大なコードベースを完璧に作り上げるのは得意ではありません。TDDの「小さなテストを書き、小さな実装を通す」サイクルは、AIが扱いやすい「タスクの細分化」と相性が良いように思います。一歩ずつ進めることで、大幅に間違ったコードが量産されるリスクを下げられるのではないでしょうか。
③ 「安全なリファクタリング」でコードを進化させやすくなる
AIはコードを整理するのが得意ですが、テストがない状態での書き換えはデグレのリスクが伴います。テストが先にあることで、「挙動を壊さずにリファクタリングして」とAIに任せやすくなると感じています。
人間がテストという「手綱（ガードレール）」を握りながら、AIを「エンジン」として活用する。これが、生成AI時代の一つの開発スタイルとして考えていることです。
3. 生成AI活用のイメージ：人間とAIの責任の分担
このアプローチで大切にしたいのは、「誰が責任を持つか」を意識することです。
| 責任 | 担当 |
|---|---|
| インフラの要件・セキュリティ要件の整理 | 人間 |
| テストコード（仕様）の作成 | 人間 |
| テストをパスする実装コードの生成 | AI |
| 生成されたコードのレビュー・修正 | 人間 |
| リファクタリング結果の承認 | 人間 |
※要件整理やテスト設計も、AIを活用しながら進めることを想定しています。ただ、最終的に「これで良い」と判断するのは人間であり、その判断の精度がそのままテストの質につながると思っています。
AIに実装を任せながらも、設計の主導権は人間が握る。この構造が、AIを使いこなしながらエンジニアとして成長し続けるための一つのあり方ではないかと考えています。
4. この取り組みで解決したい課題
この体制（生成AI × IaC × TDDエッセンス）で向き合いたい課題は、主に以下の3つです。
① 「なんとなく動いた」からの脱却
「ネットのサンプルをコピペしたらエラーなくデプロイできたからOK」という状態は、不要な設定の残存やセキュリティの考慮漏れにつながりやすいと感じています。「先にテスト（仕様）を考える」というプロセスを挟むことで、リソース構成やセキュリティ設定をより意識した開発文化が育つのではないかと期待しています。
② 生成AI活用における「エンジニアの形骸化」の防止
AIにコードを丸投げし続けると、人間の設計力が衰えていくリスクがあります。「合否を判定するテストは人間が考える」という構造を意識することで、AIを活用しながらもインフラ設計力を維持・向上できると考えています。
③ 手戻りとレビューコストの削減
「開発終盤でセキュリティポリシーを満たしていないことが発覚して作り直し」といった手戻りを、早い段階のローカルテストで発見しやすくなると思っています。テストコードが「動く仕様書」として機能することで、PRレビューの負荷が下がる効果も期待できそうです。
さいごに
現在のチームは「最終的な成果物にテストを書く」アプローチで一定の品質を担保できています。生成AIへの全面移行という大きな変革のタイミングだからこそ、「テスト駆動の考え方」を少しずつ取り入れていくのが良いのではと考えています。
IaCツールやプログラミング言語の選択はチームによって異なりますが、「先にテストで仕様を表現し、AIにそれを満たすコードを書かせる」という考え方は、様々なスタックで応用できるものだと思っています。この記事が、同じような課題を感じているエンジニアの方の参考になれば幸いです。
