AI時代のTDD / TDD in AI Era 202604 Edition

株式会社リクルート新人研修
2026年4月20日

Transcript

1. AI時代のTDD Apr 20, 2026 @ リクルート新人研修 Takuto WADA id:t-wada 📷🙆 🙆 @t̲wada @twada @twada rev.22
2. 2025年
3. 2025年に起こったこと • Vibe Coding（Andrej Karpathy） • The 70% problem（Addy Osmani） • The End of Programming as We Know It （Tim O'Reilly） • AI Slop: もっともらしい出力による、他者へのレビュー負担押しつけ • FOMO: Fear of Missing Out、乗り遅れる恐怖感にさいなまれる • November 2025 in ection: • コーディングエージェントの能力が11月に大きく向上 • The 80% Problem（Addy Osmani） • コーディングエージェントは使うか使わないかではなく、どう使うかの段階 fl に既に入った
4. Vibe Coding から Agentic Coding へ https://arxiv.org/pdf/2505.19443
5. AI との協業の2つのモード • AI と伴走 • AI と対話しながら直列開発 • コードを書くスピードは（「AI に委託」に比べて）遅い • コントロールや状況把握の度合いが高い • traditional: "決定論的ではあるものの、人力であるためスケールしない" • AI に委託 • 自走する AI たちに任せて並列開発 • コードが生成されるスピードは圧倒的に速い • コントロールや状況把握の度合いが低く、レビューが課題となる • emerging: "非決定論的で結果が確率的ではあるものの、非常によくスケールする" https://buildersbox.corp-sansan.com/entry/2025/07/03/142500
6. どの領域にどう AI を使うか 製品購入や 外部サービス利用 AI と伴走 外部委託や AI に委託 AI活用 https://www.oreilly.co.jp/books/9784814400737/
7. 典型的な「AI と伴走」のパターン • 対話: LLMとの議論、LLMからの質問から設計を生む • 生まれた設計をプレーンテキストのドキュメント（Design Doc, ADR）に保存 • 設計書のレビューを行い、必要であれば議論に戻る • 設計書からタスクリスト（markdown）を生成し保存 • タスクのレビューを行い、必要であれば議論に戻る • タスクリストからタスクを1つ選び、サブタスクに分割 • サブタスクの順番を TDD のワークフローにあわせて調整 • タスク毎にコーディングエージェントのセッションを立ち上げて（あるいは /compact して）実装 • タスク毎に Git のブランチを作成（ダメだったらブランチを廃棄する） • TDD のワークフローを指定し、レビュー不能な量のコードが一度に生成されることを防ぐ • TDD のステップ毎に Conventional Commits のルールでコミットさせる • マージ前に全体レビュー。必要であれば人間が手直しし、ブランチをマージ • 学びを反映させるために再び LLM と議論する
8. 典型的な「AI と伴走」のパターンと SDD（Spec Kit を例に） • 対話: LLMとの議論、LLMからの質問から設計を生む /speckit.constitution /speckit.specify プロンプト • 生まれた設計をプレーンテキストのドキュメント（Design Doc, ADR）に保存 • 設計書のレビューを行い、必要であれば議論に戻る /speckit.clarify /speckit.plan プロンプト • 設計書からタスクリスト（markdown）を生成し保存 • タスクのレビューを行い、必要であれば議論に戻る • タスクリストからタスクを1つ選び、サブタスクに分割 /speckit.tasks /speckit.analyze • サブタスクの順番を TDD のワークフローにあわせて調整 • タスク毎にコーディングエージェントのセッションを立ち上げて（あるいは /compact して）実装 • タスク毎に Git のブランチを作成（ダメだったらブランチを廃棄する） • TDD のワークフローを指定し、レビュー不能な量のコードが一度に生成されることを防ぐ • TDD のステップ毎に Conventional Commits のルールでコミットさせる • マージ前に全体レビュー。必要であれば人間が手直しし、ブランチをマージ • 学びを反映させるために再び LLM と議論する /speckit.implement
9. DORAレポート2025: AIは増幅器であり、組織の能力を映す鏡 https://dora.dev/research/2025/
10. AI / LLM と 2026年の ソフトウェアエンジニアリング
11. 爆発的な物的生産性 非決定性 • LLM（大規模言語モデル）の登場は、アセンブラから最初の高水準プログラミ ング言語への移行と同じくらい、ソフトウェア開発を大きく変える • 私たちは抽象化のレベルを上げているだけでなく、同時に非決定性という横方向 にも進んでいる • こうした非決定性の進化は、私たちの職業の歴史において前例のないもの https://bliki-ja.github.io/LLMsBringNewNatureOfAbstraction
12. LLMの「解呪」 • LLMがどれほど不思議で、直感的で、人間らしく見えることがあっても、その核 心部分では単にテキストの次の単語を予測するモデルに過ぎない • ハルシネーションは「バグ」ではなく機能。模倣エンジンの必然的帰結 • 役立つものを「発酵」役立たないものを「腐敗」と呼ぶのと同じ https://www.oreilly.co.jp/books/9784814401130/
13. 非決定性とどう付き合うか • 非決定性が LLM の機能であり必然的帰結ならば、いろいろな手段でコーディン グエージェントに言うことを聞かせようとするアプローチには限界がある • コーディングエージェントが少しくらい言うことを聞かなくとも問題がないよう にするアプローチの方が工学的にも精神衛生的にも良い • ソフトウェア開発を「部分的に確率的に間違っても仕組みで気づけるプロセス」 として再考できるか • 「人間が頑張る」ではなく、「AI に任せる」でもなく、 「仕組みで気づける」にしないとつらい
14. AI/LLM とソフトウェア開発ライフサイクル • 〜2024年: SDLC（ソフトウェア開発ライフサイクル） の実装工程に AI を活用 • 2025年: 実装の委譲、SDLC 全体への AI の参加 • 2026年: AI 前提の SDLC への組み替え（NEW）
15. AI/LLM とソフトウェアエンジニアリング • 〜2024年: プロンプトエンジニアリング • 2025年: コンテクストエンジニアリング • 人間はコードを書くのをやめた • 2026年: ハーネスエンジニアリング（NEW） • 人間はコードレビューをやめようとしている • "The Middle Loop" はどうなっていくか https://annievella.com/posts/the-middle-loop/
16. 委託モードの拡大: ハーネスエンジニアリングとオーケストレーション • AI と伴走 • AI と対話しながら直列開発 • コードを書くスピードは（「AI に委託」に比べて）遅い • コントロールや状況把握の度合いが高い • traditional: "決定論的ではあるものの、人力であるためスケールしない" • AI に委託 • 自走する AI たちに任せて並列開発 • コードが生成されるスピードは圧倒的に速い • コントロールや状況把握の度合いが低く、レビューが課題となる • emerging: "非決定論的で結果が確率的ではあるものの、非常によくスケールする"
17. レビューが担っていた厳密さ（Rigor）はどこへ移るのか • 上流の仕様レビュー (EARS、デシジョンテーブル) • 第一級の成果物としてのテストスイート (TDD) • 型システムと制約によるガードレール • ビジネスの影響度に基づくリスクマッピング • 継続的な理解 (ペアプロ、モブプロ) https://martinfowler.com/bliki/FutureOfSoftwareDevelopment.html
18. レビューが担っていた厳密さ（Rigor）はどこへ移るのか • 上流の仕様レビュー (EARS、デシジョンテーブル) • 第一級の成果物としてのテストスイート (TDD) • 型システムと制約によるガードレール • ビジネスの影響度に基づくリスクマッピング • 継続的な理解 (ペアプロ、モブプロ) https://martinfowler.com/bliki/FutureOfSoftwareDevelopment.html
19. AI 時代の TDD
20. https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck
21. テスト駆動開発の手順 1. 押さえておきたいテストシナリオを洗い出し、リスト（テストリスト）にまとめる 2. テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可能なテスト コードに翻訳し、テストが失敗することを確認する 3. プロダクトコードを変更し、いま書いたテスト（および、それまでに書いたすべてのテ スト）を成功させる（その過程で気づいたことはテストリストに追加する） 4. 必要に応じてリファクタリングを行い、実装の設計を改善する 5. テストリストが空になるまでステップ2に戻って繰り返す https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck
22. TDD と Git と Conventional Commits 1. 押さえておきたいテストシナリオを洗い出し、リスト（テストリスト）にまとめる 2. テストリストの中から「ひとつだけ」選び出し、実際に、具体的で、実行可能なテスト コードに翻訳し、テストが失敗することを確認する • ここで test: プレフィクスをつけてコミット 3. プロダクトコードを変更し、いま書いたテスト（および、それまでに書いたすべてのテ スト）を成功させる（その過程で気づいたことはテストリストに追加する） • ここで feat: プレフィクスをつけてコミット 4. 必要に応じてリファクタリングを行い、実装の設計を改善する • ここで refactor: プレフィクスをつけて何回かコミット 5. テストリストが空になるまでステップ2に戻って繰り返す https://www.conventionalcommits.org/ja/v1.0.0/
23. 伴走モードにおける TDD: 監督ループと流量制御 • AI と伴走 • AI と対話しながら直列開発 • コードを書くスピードは（「AI に委託」に比べて）遅い • コントロールや状況把握の度合いが高い • traditional: "決定論的ではあるものの、人力であるためスケールしない" • AI に委託 • 自走する AI たちに任せて並列開発 • コードが生成されるスピードは圧倒的に速い • コントロールや状況把握の度合いが低く、レビューが課題となる • emerging: "非決定論的で結果が確率的ではあるものの、非常によくスケールする"
24. 委託モードにおける TDD: 自律ループと監査 • AI と伴走 • AI と対話しながら直列開発 • コードを書くスピードは（「AI に委託」に比べて）遅い • コントロールや状況把握の度合いが高い • traditional: "決定論的ではあるものの、人力であるためスケールしない" • AI に委託 • 自走する AI たちに任せて並列開発 • コードが生成されるスピードは圧倒的に速い • コントロールや状況把握の度合いが低く、レビューが課題となる • emerging: "非決定論的で結果が確率的ではあるものの、非常によくスケールする"
25. どの領域にどう AI x TDD を使うか 監督ループと 流量制御 買ってくる 使わない 自律ループと 外部委託や AI活用 監査 https://www.oreilly.co.jp/books/9784814400737/
26. ご清聴 ありがとうございました