# 生成AI時代のエンジニアの新しい働き方 公開日: 2026-05-01 / 執筆者: 箕輪　旭 / カテゴリ: ITプロジェクトの管理, 実行力 生成AIがコードを書く時代になりました。GitHub CopilotやClaude Codeといったツールを使えば、自然言語で指示するだけで動くコードが手に入ります。開発のスピードは劇的に上がり、エンジニアでなくても簡単なプログラムを作れるようになっています。 しかし、**「動くコードが手に入る」ことと、「品質が担保されている」ことは別の話**です。私自身、ログイン機能をAIで実装したとき、動作はするもののセキュリティ面で確信が持てず、立ち止まった経験があります。AIによる自動化が進むにつれて、誰もその中身を十分に把握していないまま動いている、ということが起きやすくなります。 この問題への対処として、テスト駆動開発（TDD）が改めて注目されています。コードの品質を担保する仕組みとして、いまこそ開発プロセスの見直しが重要なのです。しかし、AIとTDDの組み合わせ方については、見過ごせない落とし穴があります。本記事では、TDDの基本を整理したうえで、生成AI時代のエンジニアに求められることを考えます。 ## テスト駆動開発とは何か TDDは簡単に言うと、「テストを先に書く」開発手法です。 まず、まだ実装していない機能に対してテストを書きます。当然、実装がないのでテストは失敗します。これが「Red」という状態です。次に、そのテストを通すだけの最小限のコードを書きます。これが「Green」です。最後に、コードをきれいに整理します。これが「Refactor」です。 TDDが「テスト手法」ではなく「設計手法」と呼ばれる理由はここにあります。テストを先に書くことで、「このコードをどう使うか」を実装前に考えることになります。結果として、インターフェースがシンプルになり、依存関係が整理された設計が生まれやすくなります。そしてもうひとつ、TDDには重要なメリットがあります。テストケースを先に書くということは、「何を作るか」を言語化することです。それはそのまま、設計書としての機能を持ちます。従来、設計書とコードは別々に管理されていましたが、TDDの枠組みでは、**テストケース自体が仕様の記録になります**。 ## 「テストケースもAIに書かせる」という潮流 コーディングをAIに任せる流れの中で、TDDにおいてもテストケースの生成をAIに委ねるアプローチが検討されるようになっています。「コーディングもテストもAIが担い、開発者はその結果をレビューする」というワークフローは、開発速度の観点からは魅力的に映ります。しかし私は、このアプローチには見過ごせない問題があると考えています。 ## コーディングをAIに任せるからこそ、テストケースは人間が書かなければならない コードをAIが書く、という状況で、テストケースまでAIに書かせてしまうと、「仕様を決める」も「実装する」も「テストする」もすべてAIが担うことになります。人間はその結果を眺めるだけです。コードが「テストを通った」という事実は担保されますが、そのテスト自体が正しい仕様を表現しているかどうかを、誰も確認できません。**完全なブラックボックス**です。 AIが生成するテストケースは、あくまで「一般的に考えられるケース」です。ログイン機能であれば、正しいパスワードでログインできるか、間違ったパスワードで弾かれるか、といった基本的なケースは網羅されるでしょう。しかし、「法人アカウントと個人アカウントで認証フローが異なる」「特定の条件下では二段階認証が必須になる」といったビジネス固有の仕様は、AIには知る術がありません。もしAIにビジネスロジックのテストを書かせようとすれば、その前提となる仕様を人間が別途用意しなければなりません。しかしそれは、テストケースを自分で書くことと実質的に同じ手間です。二度手間になるだけでなく、AIへの伝達過程で意図がずれるリスクや、人間の作った設計書とテストケースの二重管理によって仕様の「正しさ」が分からなくなるリスクも生まれます。 ## TDDの本質は、思考の順序を変えることにある そもそもTDDが品質向上に寄与するのは、バグを発見する能力が高いからではありません。バグが入りにくい思考の順序を、仕組みとして強制するからです。従来の開発では、実装してからテストを書きます。このとき、開発者は無意識に「自分が書いたコード」を前提にテストを考えます。すると、バグを見逃す方向に思考が引っ張られてしまいます。TDDはこの順序を逆にします。テストを先に書くことで、「このコードを使う側」の視点から考え始めることができます。 たとえばログイン機能であれば、「攻撃者はどう使うか」という視点でSQLインジェクションや総当たり攻撃への耐性を、実装前に洗い出せます。**テストケースをAIに委ねるということは、この「思考の順序を変える」という、TDDの最も重要な部分を手放すこと**に他なりません。 ## 生成AI時代のエンジニアに求められること 以上を踏まえ、エンジニアと生成AIは次のような役割分担をすべきだと提案します。 **汎用的なテストケースの記述はAIに任せてよい** セキュリティ検査（SQLインジェクション、セッション管理、総当たり攻撃など）や、一般的なエラーハンドリングのテストは、ある程度パターン化されています。「何をテストするか」の観点を人間が先に示したうえで、その記述をAIに任せることは有効です。 **ビジネスロジックのテストケースは人間が設計・記述する** ビジネスロジックに関わるテストケースは、人間が設計し、記述する必要があります。「何が正しい動作か」を定義できるのは、そのビジネスを理解している人間だけだからです。 **コーディングはAIに任せる** テストケースが決まれば、それを通すコードの実装はAIに任せることができます。人間がテストケースという「答え合わせの基準」を持っているからこそ、AIの実装を評価できます。 ## 人間はレビュー者ではなく設計者 生成AI時代のエンジニアの役割として、「AIが書いたコードを人間がレビューする」というイメージが広まっています。しかし私は、この構図が本質を外していると考えています。 レビューは事後の確認です。AIが出力したものを後から評価する立場では、設計の主導権はAIにあります。確かに開発スピードは上がるかもしれませんが、AIの能力を信じる領域が大きくなり、成果物の品質は低下するでしょう。正しい構図は、「**人間が設計し、AIが開発する**」です。テストケースはその設計言語であり、人間がAIに渡す仕様書です。この順序を守ることが、生成AI時代に品質を担保する唯一の方法だと考えます。コーディングをAIに任せるからこそ、設計は人間が手放してはならない仕事です。 --- 出典: スタディメーター株式会社 — https://studymeter.jp/insights/26y_o2pas 執筆者プロフィール: スタディメーター株式会社　代表取締役。オンライン学習サービス「Udemy」にて、非エンジニア向けの分かりやすく実践的なIT講座がベストセラーとなり、 これまでに25万人以上を指導。さらに活動の幅を広げるため、2020年にスタディメーター株式会社を創業。 「挑戦したくなる世界」の実現を目指して、新しい一歩を踏み出したい人のサポートに取り組んでいます。