AIエージェント時代のテスト駆動開発（TDD）

AIエージェント時代に、テスト駆動開発（TDD）は「ガードレール」になる【t_wada×やっとむ対談】

生成AIを巡る状況は、わずか1年ほどで劇的に変化しました。Claude Codeなど実用的なコード生成エージェントが普及し、開発現場に大きなインパクトを与えつつあります。

とはいえ、「どのような場面で活用できるのか」「実際の開発で本当に役立つのか」といった疑問を抱えるチームも少なくありません。

そこで本稿では「生成AIによるコーディングとテスト駆動開発（TDD）」をメインテーマに、TDDの第一人者・和田卓人さん（@t_wada）と、アジャイルコーチのやっとむさん、こと安井力さん（@yattom）が対談。TDDの意義や、チームでAIを活用するための現実的な視点を掘り下げます。

AIをどう導入し、どう使いこなすか──実践的なヒントが詰まった対談です。

2025年7月時点のコード生成エージェントの現場感

── 生成AIを扱った記事として今日の対談を残すに当たり、まずは対談時点（2025年7月上旬）における関連技術の状況をある程度はっきりさせておければと思います。

和田　生成AIを巡る状況は変化が激しいですからね。実はやっとむさんとは、ちょうど1年前、2024年7月の「Developers Summit 2024 Summer」でも、生成AIに関する講演でご一緒していますが、この1年だけでもかなり大きな変化がありました。

やっとむ　はい。そのときは名古屋大学の森崎先生を交えて、当時の研究成果を踏まえてソフトウェア開発の現場で生成AIに何ができるかを考えるという主旨の鼎談でした。

和田　当時もGitHub Copilotのような補完ツールは普及していましたが、AIによるコード生成というと、まだ「ChatGPTと対話して出力されたコードをコピペして使う」といった使い方が想定されていた頃です。

それが2024年11～12月にかけてコード生成エージェントの進化が急激に加速し、2025年2～3月にもなると、各社から実用的なツールが一気に登場してきました。日本ではAnthropic社によるClaude Codeの登場と、5月からそれが定額で使えるようになったことが決定的だったと思います。

── それから半年もたっていませんが、すでにコード生成エージェントをまったく使っていないソフトウェアエンジニアの方が少ないような印象さえ受けます。

和田　アーリーアダプターが多いX（旧Twitter）などではそういう印象を受けますよね。しかし、少なくとも現時点では、エンタープライズ環境における普及はそこまでは進んでいないと見ています。

大きな理由はサービスの提供形態です。まだエンタープライズ向けと言えるプランが少ないので、スッと導入しにくい。現時点で導入している企業の多くは、個人向けのプランを従業員に配るという形を取っているはずです。

この対談が公開される頃には、Anthropic社の日本法人設立などにより、まったく状況が変わっている可能性もありますが……。*1

── 企業によっては情報セキュリティ的な懸念もありそうですね。

和田　はい。やはり現状の提供形態では、GitHub Copilotなどに比べて業務への導入には慎重になる企業が多いと思います。

── つまり現状は、「コード生成エージェントの性能面での進化がありつつも、提供形態や情報セキュリティへの懸念といった制約から、エンタープライズへの普及はまだ緩やか」という感じでしょうか？

和田　そう言ってよいと思います。加えて、そもそもコード生成エージェントを本格的に導入するための準備がまだ整っていない現場も多いと感じています。

── 具体的には何が足りていないのでしょう？

和田　AIにコードを「うまく」生成させるには、開発ドキュメントやリポジトリ、CI/CDの整備がある程度できている必要があります。その下準備ができていない状態でコード生成エージェントを導入しても、「それほどでもないね」で終わってしまう可能性がある。

── 今日のお話は、そうした現状を踏まえつつ、これからコード生成エージェントを導入しようと考えている人たちに向けたものになりそうですね。

やっとむ　アジャイル開発で例えるなら、「今からアジャイルを始めたい」「うまく導入できていない」といった現場にアジャイルコーチとして呼ばれたときのように、「ツールとしてAIを導入しようという意思はあるものの、そのための下準備が見えていなかったり、見えていても苦労している企業やチーム」に向けた話ができればと思っています。

すでに使いこなしている人向けの高度な話ではなく、まだあまり使っていない方に向けた導入的な内容です。

例えば、「生成AIで新しいサービスを作ってローンチするぞ」という人たちではなく、「既存のコードがいっぱいあって、テストもろくにない環境で日々戦っています」といった現場の方々をイメージしています。

AIが広げるテスト導入の可能性

生成AIが自動テスト導入のハードルを下げた

── やっとむさんから、「テストもろくにない環境」という言葉が出ました。今日のテーマとして「テスト駆動開発（TDD）」がありますが、「テストがない」から「原則としてまずテストを書く」というTDDまでは、だいぶ距離がありそうです。

やっとむ　そうですね。実情として、「そもそもテストを知らない」あるいは「TDDをやっていない」という人がまだまだ多いと思います。生成AIは、そうしたテストがない環境でも「何とかしてテストを整備したい」、さらには「TDDのような手法を導入してみたい」というときに、とても強力なサポートツールになりうると考えています。

── 生成AIにテストを書かせる、という使い方でしょうか？

やっとむ　テストを書くのはしんどいですよね。人間がしんどいことは、生成AIに助けてもらえる可能性があります。

もちろん生成AIに書かせたテストには、モックだらけで何をテストしているのか分からないとか、設定やフィクスチャーがやたらに長大だとか、いろいろ不備もあります。しかし、生成AIはとにかく“テストらしいもの”を書いてくれるので、人間が最初の一歩を踏み出せます。

── TDDの前に、まず自動テストを導入するハードルを生成AIで下げられるだろう、と。

やっとむ　一方で、「生成AIを使ってコードを書けるのだから、テストがなくても何とかなるだろう」という考え方にはリスクがあります。

生成AIで動くコードはすぐに手に入るけれど、使っていくうちにだんだん逸脱しておかしくなるという話は、すでによく耳にしますよね。そうした問題を見抜いたり対処したりするには人間側に一定のスキルが求められます。

まったくスキルがない状態では、生成AIのミスに気付けず、結果として問題を放置してしまう危険があります。だからこそ、「テストを書いたことがないから対応できない」という状況にならなければいいなと考えています。

和田　それで言うと、生成AIが登場したことで自動テストを書くようになった人は、明らかに増えています。というのも、私はかれこれ20年くらい日本でTDDを広めるべく頑張ってきて、さまざまな企業やコミュニティで話をしてきたのですが、まず自動テストを書くこと自体に大きなハードルがあるんですよ。

そのハードルを生成AIが下げました。具体的には「学習コスト」と「実装コスト」という二つのハードルがあるのですが、生成AIによって両方とも下がりました。

── 実装コストは、開発する際の労力が下がるという意味ですよね。学習コストは、テストの書き方を勉強する手間を指しているのでしょうか？

和田　自分が書いているコードを自動で検証するには、発想の転換が必要です。「自分が書いているプログラムを、まったく別のプログラムから検証できるようにする」という作業だからです。

これをゼロから書けない人はかなりたくさんいます。「既存のコードに手を加えて機能を追加し、自分の手と目で動作を確認する」ことはできて、自動テストを書きたいと思っていても、別のスキルなので手が動かない。

── その学習コストが、すでに生成AIによって下げられているというわけですね。

和田　必ずしも質が高いテストコードが出てくるわけではありませんが、それでも何かしらのコードが得られるので、最初の一歩が踏み出せる。「テストコードを書くというのは、こういうことなのかな」というのが分かるようになれば、「ここをいじると失敗するので、テストをこう書き直して」といった具合にフィードバックサイクルを回し始められます。

「As-Is」のテストで力を発揮する生成AI

── 今、「テストコードの質」という観点が出ました。生成AIは、「個別のアプリケーションに対して、どういうテストを書けばいいか」を、どこまで理解してくれるでしょうか？

和田　特にTDDという文脈で自動テストに必要なのは「To-Be」のテスト、つまり「プログラムやシステムがどうあるべきか」を検証するテストです。

しかし、そもそもシステムがどう動くべきかは、レガシーなコードでは失われていることも少なくありません。仕様書すらないとか、あってもコードとの乖離が激しいとか。そういうコードでテストがない場合、いきなり無の状態から「To-Be」のテストを書くのは道のりが遠過ぎます。

そこでどうするかというと、ゴールをもっと手前に設定し、まずは「現在のコードがどう動くか」を写し取ったテストを書きましょう、と。つまり、「To-Be」ではなく「As-Is」のテストから始める。これは「仕様化テスト（キャラクタライゼーションテスト）」と呼ばれます。

── 既存のコードを見て「As-Is」のテストを書くのは、いかにも生成AIが得意そうです。

和田　めちゃくちゃ力を発揮してくれます。理想は「To-Be」のテストがあることですが、「どうあるべきか」は、人間がスキルを高めて書くしかない。もしくは、過去の意思決定を掘り起こしてソフトウェア考古学をやるしかない。

それに対し、「既存のコードの挙動を別の角度で動的に写し取り、それを自動テストに落とし込んでください」という、いわば「後出し」のお願いであれば、コンテキストを絞れば生成AIが対応可能です。「As-Is」のテストがあるだけでも、機能追加による不具合の発生や動作の変化を検知できるので、何もテストがない状態に比べたら大きな前進です。

t_wadaさん

── まさに、学習コストと実装コストというハードルが下がる。

和田　馬力がなかった企業にとっては、テストカバレッジを上げるツールとしてだけでも、だいぶ効果があります。

やっとむ　開発が一通り終わって運用保守に入った後の局面で「今の動きをキャプチャーして壊れたら分かる」ような自動テストが必要になることもよくあります。

この場面で欲しいのはまさにキャラクタライゼーションテストなので、生成AIが力を発揮します。運用保守を任されるチームは開発に比べてぐっと人数が少なく、保守開発が得意な人はテストコードを書き慣れているわけでもないので、とても価値が高い。

── テストがないまま開発を終えて運用に入ってしまったコードを救える可能性があるんですね。

やっとむ　それから、TDDの文脈では、ケント・ベックが言う「テストリスト」にも生成AIの力を借りられます。

── テストリストは、「これから書くべきテストの一覧」のことですね。

やっとむ　そうです。大きな「やりたいこと」を細かく、しかもプログラムで検証できる形に分解しないといけないので、テストリストを書くのは実は結構難しいものです。それが生成AIに「テストリストを書いて」と指示すると、ある程度は「そういうもの」が出てきます。

── TDDではテストリストを思考のガイドとしているので、自分で書かないといけないのでは、とも感じてしまいますが。

やっとむ　はい。それ自体の良し悪しはあります。しかし、「こういうふうに課題を分解すればいいのか」とか「最初はここからやればいいのか」というのが見えることでTDDに入っていくハードルを下げる効果はあります。一つ書いたものを増やして網羅していくのも得意なので、そういう使い方もできます。

── 実装レベルでの手伝いをさせればいいのですね。

やっとむ　もちろん、「どういうテストを増やしていくべきか」はまた別の話で、これは「テスト設計」を通して人間が考えていくことになります。

「テスト設計」をAIで支援する

── 今挙がった「テスト設計」という言葉は、具体的には何を指しているのでしょうか？

和田　要するに、「どういうテストを実施すべきかをあらかじめ考える」という話で、どちらかというとソフトウェアテスト技法の世界でよく使われる言葉です。

やっとむ　例えば、副題がまさに「テスト設計の考え方と実際」という、秋山浩一さんの『ソフトウェアテスト技法ドリル』の目次を見ると、テスト設計の手法として「同値分割」「境界値分析」「ドメイン分析」「デシジョンテーブル」「HAYST法」「ペアワイズ」といったものが紹介されています。

ソフトウェアテスト技法ドリル

著者: 秋山浩一
発行: 2022年10月

日科技連出版社

和田　特に日本では、自動か手動かを問わず、品質保証の観点から「対象のシステムや仕様に対してどのような検証が必要か」を考える研究が盛んです。QAエンジニアやテストエンジニアと呼ばれる人たちは、そうしたソフトウェアテスト技法を通して「何をどうテストするか」を考えていて、これを「テスト設計」と呼んでいる。

── TDDの文脈だと、あまり使われない言葉ですよね。

和田　そういう名前で形式化されていないだけで、本当はやっているんですよ。TDDはもともとプログラマー視点なので、実際にキーボードでコードを書き始める前に頭の中で考えるのはアーキテクチャやデータ構造です。それらの設計として「これから何をテストしていこう」を考えています。

テストエンジニアも、手動テストで実際に手を動かす工程になってから「何をテストしよう」と考えているわけではなく、あらかじめ「どの機能群に対するテストをすれば効果的か」とか「より不具合を発見しやすいかどうか」とか「少ない手数で検証すべき項目を網羅するには」といったことを考えます。それがソフトウェアテスト技法におけるテスト設計です。

── テスト設計が何を指しているのか、よく分かりました。「どういうテストを増やしていくかは人間が考えていく」という話に戻すと、テスト設計では生成AIはまだそれほど役に立たないのでしょうか？

やっとむ　私が試している範囲だと、単にやりたいことを伝えて「テストを書いてください」と生成AIに言うだけでは、あまり論理的に考えてくれない面があります。

そこで、「境界値分析を使ってください」とか、「このようなデシジョンテーブルを作ってください」とか、「同値クラスを抽出してください」といった指示をすると、それなりの結果が出てくるんです。人間が論理的にテスト設計を考えるための道具を使わせると、生成AIも論理的に考えられるようになる。

やっとむさん

── ある意味ではプロンプトエンジニアリングのような話ですね。

やっとむ　人間が作ったテスト設計をレビューしてもらう場面でも、生成AIは役立ちます。また、生成AIが作ったテスト設計を人間がレビューするのではなく、その役割を生成AIに肩代わりさせることも不可能ではありません。ただし、「人間には何も分からないけどテストを考えて」と丸投げするだけでは、うまくいかないでしょう。

生成AIに徹底的に聞くという冴えた使い方

── 現状の生成AIは、何もテストがない状態から「As-Is」のテストがある状態にすることは得意だし、うまくプロンプトで指示する知識が人間にあれば「To-Be」のテストを設計するのにも役立てられる、と言えそうです。

やっとむ　現状における利点はまさにその二つです。今のシステムをテストで捉えて自動化するハードルが生成AIで下がり、もう少しちゃんとテストをしようというテスト設計でも別の形で生成AIが活用できる。

和田　そういう意味では、テストを巡る構造は今までと変わらず、そのままコストが大幅に下がります。

── 人間が勉強しないといけないことは同じということですね。

和田　基本的にはそうです。生成AIは短期的には動くものができるという意味で破壊的な技術ですが、その先の持続や成長には人間の関与がどうしても必要になります。

生成AIは「打ち出の小槌」ではないので、人間がいろいろ好奇心をもって勉強した方が結局うまくいくのは今も昔も変わりません。

やっとむ　その勉強にも生成AIが役に立つというのが、和田さんが先ほど「生成AIで下がった二つのハードル」とおっしゃっていたうちの学習コストの話かもしれませんね。

先日の「開発生産性カンファレンス2025」におけるケント・ベックの基調講演の言葉を借りると、生成AIはランプの魔人のように願いを叶えてくれる存在ですが、「何をお願いすればいいか教えて」という願いも聞いてくれる。

和田　その通りです。

やっとむ　これまでは本を3冊ぐらい読んで「何となくこんな感じかな」と勘を掴んでいたものが、AIと1時間くらいやり取りするとだいたい分かるようになる。

それで身に付くわけではないですが、少なくとも世の中の知見を単なるキーワードで終わらせずに、質問と説明を繰り返しながら深堀りしていける。これは実のところ、アジャイルチームのやり方にすごく合っていますよね。

プロダクトが成長していく途上で何か分からないことや困ったことが発生したとき、そのまま突っ走らずに立ち止まって戦略や方針を立て直そうとする。従来なら「この問題の解決が得意な人を探そう」となっていたわけですが、そこに「AIに徹底的に聞いてみよう」という選択肢が増えた。

和田　そうですね、いわゆる仮説検証を回すとか、アイデアをいくつも出すとか、短期間でいくつも作って試すとか、そういった側面に対する生成AIのインパクトはすさまじいものがあります。これは本当に冴えた、正しい使い方だとも思います。

AI時代におけるTDDの意義

劣化するAIエージェントの出力を自動テストで防ぐ

和田　一方で、従来のソフトウェアエンジニアリングの観点では、開発の速度に対してコードの内部品質をどう維持するかという課題もあります。

寓話の「ウサギとカメ」ではありませんが、ウサギのように「とにかく作って、とにかく壊す」でガッと進める開発と、カメのようにリファクタリングや自動テストをコツコツやっていく開発とでは、どこかで後者の生産性の方が高くなります。AIより前の時代には、業界の経験則として、この転換点はおよそ1カ月で訪れると言われていました。

ところが2025年7月現在では、おそらくそれが数日になっています。保守性の限界を迎えるのが、AIによるコード生成で随分手前になりました。

── 数日という値の根拠は何かあるでしょうか？

和田　はっきりしたデータがあるわけではなく、感覚値ですね。カンファレンスの廊下や講演中などに聴衆の皆さんに「AIエージェントを使ってワーッと作っていたものが失敗を繰り返すようになり、うまくいかなくなるまでの期間」を尋ねると、だいたい3日とか1週間という答えが返ってきます。

── AIエージェントがだんだん指示に関係ない書き換えをするようになるといった話は、本当によく耳にします。

和田　はい。結局のところ、それまでに書いたコードに対する変更がうまくいくか、それともダメージを与えるかが問題です。変更にかかる時間が短くなった分、保守性の限界が訪れるのが手前になったということだと思います。

── AIがコードにダメージを与えるのを防ぐにも、きっとテストは有効ですよね。

和田　2025年に入ってから、よく「AIエージェントがコードを書く時代において、TDDの重要性はこれまでよりはるかに高まっている」と言われるようになりました。Anthropic社が公開している記事にも、「TDDがさらに強化される」といったことが書かれています。

言及されているのが本当にTDDの話なのかというと、それはそれで疑問もある*2のですが、少なくとも自動テストについては、AIエージェントと一緒に開発をしていく上で重要性が明らかに増しています。

── ここまでの話は「AIを使って自動テストを書く」という方向の話が中心でしたが、ここからは「AIが自動テストを使う」という方向の話になりそうですね。

和田　AIエージェントは、目的のコードを得ようといろいろ動かして、よくコードを壊します。試行錯誤の過程でコードが壊れること自体は悪いことではなく、そもそも「目的を達成するために、既存のコードをいじりながら試す」能力を持っていること自体が結構驚きです。しかし、近視眼的に突っ走って別の箇所を壊すことも少なくありません。

なので、「これまで動いていたコードは変わらず動き、かつ、新しいコードも動いている」状態を目指すよう、AIにはっきり伝える必要がある。成功/失敗で判定できる自動テストは、それに適した道具だと言えます。

── 人間にとって自動テストが大事である理由と同じですね。

和田　AIは判断と実行が人間よりもずっと速いので、エージェントとして自律的にアクセルもブレーキも踏んでもらうには、さらに大事と言えるでしょう。

「テスト駆動開発で」という指示でAIに文脈が伝わる

和田　もっとも、既存の挙動を壊さずに指示した目的を達成するだけでは、品質保証の観点では全然足りません。

── 具体的にはどういう点でしょうか？

和田　要するに「動くだけでは全然足りない」という話です。AI以前から例えば『A Philosophy of Software Design』（John Ousterhout著）のような本でも議論されているように、ソフトウェアには機能適合性だけでなく、保守性などさまざまな品質、特性が求められますからね。

── それらに関してAIエージェントは弱い？

和田　弱いというよりは、放っておいても保守性が高くならないので、そこは人間が別途ナビゲートしましょう、と。書き散らかして重複が多いコードに対して「共通化して」といった指示出しは人間がやる必要があります。

── 自動テストだけだと、壊さずに動くものは作れても、保守性は置き去りになる。

和田　はい。先行している海外の企業においても、やはり保守性の低下が問題になっています。動くけど汚いコードがとにかく増えていき、結果として開発速度に悪影響を与えるケースが少なくありません。

── 「コードを整理して」といった指示は、人間がコードを見てプロンプトで与えることになるのでしょうか。

和田　そこで登場するのが、「テスト駆動開発（TDD）」というワードです。TDDは、自動テストで思った通り動くことを確認することと、動いているままで保守性を高めていくことの両方が備わった開発ワークフローだからです。

やっとむ　動作するきれいなコードは価値がある。これがケント・ベックの『テスト駆動開発』の最初に書いてある、一番大事なゴールですからね。一発で書き終わるのではなく、動作するきれいなコードを維持し続けることに価値が置かれているのです。

テスト駆動開発

著者: Kent Beck
訳　: 和田卓人
発行: 2017年10月

オーム社

和田　AIエージェントの裏にある各種のモデルもテスト駆動開発の思想を知っています。だからこそ、「機能適合性だけでなく保守性もスコープに入れる」といった文脈をAIエージェントに伝えるのに「テスト駆動開発」というフレーズが使える。

── 和田さんのアカウント名（t-wada）がAIに対する指示として有効という話題もありましたね。

和田　はい。「テスト駆動開発」というワードはたくさんの人が使っているので、どうしても解釈にブレが生じています。実際のところ、例えばClaude Codeに対して「TDDで進めて」と言うだけだと、単に「先にテストをたくさん書く」といった振る舞いになりがちでした。

でも、そうじゃないんですよね。「一つテストを書いて、わざと失敗させてから、それをクリアにするコードを書く」という、より古典的で厳格なTDDをやってほしい。そのことを伝えるのに、自分やケント・ベックのような人名を使うのが便利であるという現象が報告されています。

パタン・ランゲージが目指していた世界が突如実現

── ある種のプロンプトエンジニアリングなのかもしれませんが、短いワードで意図が伝わるのは面白いですね。

和田　そうですね。AIを使うときは、モデルに対していかに効率的に文脈を伝えるかを、日々工夫しながら頑張っていますよね。1回のやり取りで渡せるコンテキストにも限りがありますし、絞り出すように使っているトークンを「テスト駆動開発の手順」を手取り足取り教えることに使って、無駄にはしたくない。

── 確かに、モデルが知っていることなら短いワードで伝える方が効率的です。

和田　その発想自体が、実はソフトウェア開発の世界で「デザインパターン」や「パタン・ランゲージ」と呼んでやりたかったことそのものなんですよ。

作っているシステムは多様でも、そこで現れる諸問題には共通点があり、解決策も似通っている。だから問題に名前を与えて、解決策を逆引きできるようにし、情報伝達の効率を上げるというのが、1990年代後半のデザインパターンでした。

しかし、当時はその文化がそこまで広まらず、「名前だけで全部が伝わる」世の中が実現されたとは言いにくい。

── それが生成AIで突然実現されるようになった。

和田　実際、AIとのペアプロ時にデザインパターンの言葉を使うと、伝わりやすいことが多いです。例えば「同じ分岐がすごく繰り返されているから、Stateパターンでリファクターしよう」と言えばいい。かつて理想としていた世界が実現している。ある意味では新鮮な体験であり、面白いなと思っています。

テスト駆動開発はAIの暴走を防ぐガードレールになる

やっとむ　少し違う観点として、「AIエージェントが生成したコードを人間は読むのか」という話もあると思っています。

ウォード・カニンガム*3が「技術的負債」という言葉で指していたことに、書かれているコードと人間の理解が乖離している状態があります*4。生成AIによるコーディングでは、この乖離があっという間に広がりますが、それをコントロールする手段としてもTDDは役立つかもしれません。

── AIエージェントにTDDでやらせることで、人間にとっても読みやすいコードができる？

やっとむ　前提として、動作するきれいなコードであっても人間がそれを全部追うのは難しくなります。しかし、AIエージェントにTDDでやらせることで「人間がコードを読まなくても分かる」状況を作り出せる可能性があると考えています。

これは人間のチームで仕事をするときも同じです。理想的なのは、例えば壁に貼ってある設計図やクラスダイアグラムを囲んで、「あそことあそこを直せばいいね」「じゃあ、ここは僕がやるね」といった具合に、毎回ソースまで入っていかなくても設計や見積もりができる状態だと思います。内部品質が高いコードは、実際にそうなっている。

── 急速に技術的負債がたまってくると、それができなくなるわけですね。

やっとむ　生成AI以前にはコードを触るのはみんな人間でしたが、今はチームに生成AIも加わっている。そこにTDDを取り入れれば、コードとそれをメンテナンスする人間との距離、つまり技術的負債をある程度までコントロールできるようになります。

特にAIに委託するのではなく、AIと伴走する形で生成AIを利用するときには、そういうメリットがあるだろうと私は考えています。

── 「AIに委託する」使い方と「AIと伴走する」使い方というのは、和田さんが「開発生産性カンファレンス2025」の講演で提起されたAIとの協業のモードのことですね。自走するAIに任せて圧倒的な開発スピードを実現する前者に対し、後者では人間がAIと対話しながら開発を進めるとお話されています。

▲ 和田さんの「開発生産性 Conference 2025」発表資料「AI時代のソフトウェア開発を考える（2025/07版） / Agentic Software Engineering Findy 2025-07 Edition」より

やっとむ　AIと伴走してTDDをやると、AIで生成されたコードやテストを人間が見る機会が増えます。その上で、「見なくていい」という判断もできるかもしれない。

同じような変更を5カ所するときに、一つか二つは人間がしっかり見たり、最初は書いたりするかもしれない。それがうまくできたら、あとは今までと同じだからAIに任せておけば大丈夫、という状況になることもあるでしょう。

「きれいなコードを書いてください」ではなく「先ほど書いたコードをまねしてください」という指示は非常にうまくいきます。これも一種のコンテキストエンジニアリング*5ですね。

── AIと伴走してのTDDは、ある意味でベストプラクティスのようなものかもしれない？

やっとむ　常にこれがベストではないです。知っておくべき手法という意味では、「グッドプラクティス」ではあるかもしれません。

和田　TDDとの関連で言っても、「AIと伴走するからTDD」「AIに委託するからTDDじゃない」という話ではないと考えています。人間もコードを深く認識している状況を維持したければAIと対話しながら開発を進めるし、そうじゃなければAIに任せるという話なので、これはTDDを使うか使わないかの話とは直交しています。

むしろ、AIに委託する使い方こそTDDでやらせた方がいいとさえ言えます。なぜなら、自走するAIは、動くかもしれないけど汚いコードを大量に生産するからです。基本的にはどんどん保守性が悪いものになっていくので、「保守性を維持する」という目的を指令に含めたい。それには「テスト駆動開発で」という指示がAIの暴走を防ぐガードレールとして有効になります。

t_wadaさん

こんな形でTDDが重視されるとは──t_wadaさんも想定外

── コード生成に特化したモデルが、TDDを最初から意識して開発をするようになるかもしれませんね。

和田　TDDが織り込み済みの事項になって、使う側では意識しないものになっていく可能性はあると思います。さながら、現代のプログラマーがCコンパイラーの中の仕組みをあまり意識しないのと同じような状況になっていくかもしれません。

── 逆説的ですが、現在のソフトウェア開発にとって重要なあまりCコンパイラーが「意識しなくて済むもの」になっているように、現状の生成AIによるコーディングにとってTDDもそれくらい重要かもしれないということですね。

和田　そうですね、事実上、そうなりつつあると思います。予想もしていなかったのですが……。

── 「和田さんにとって意外だった」というのが意外です。

和田　本当に予想していませんでした。TDDは、これまで「やりたい人がやる」ようなところがあったんです。20年前からずっと「好きな人がやっています」ぐらいの温度感でした。自動テストの方は大いに広がって、今では必須とまでみなされていますが、テスト駆動開発はというと「できそうならやってみましょう」くらいの位置付けでした。人間には好き嫌いや得意不得意もあるから、自分としてはそれでよいと思っていたんです。

── それがAIエージェントによるコーディングの登場で状況が変わってきた。

和田　コードを書くのが本人ではなく、しかも自走するAI相手なので、人間の側でガードレールや手順の追跡手段が欲しくなったのだと思います。

さらに、その都度人間が介入して指示するとAIのスピードを殺してしまうので、事前の指示と事後の監査でそれをやりたい。そのニーズに対し、割と厳格めのテスト駆動開発というワークフローが一致したのだと思います。

── 静的型付けがAIによるコーディングでガードレールになるという話を思い出しました。

和田　人間が好みに応じて使うかどうかでなく、AIに使わせるときのガードレールになるかという観点では、似た状況にありますね。

自律して突っ走るAIエージェントたちに眼を与えてやり、そのフィードバックを使わせることで人間が望む方向に向かいやすくする。それがTDDによる動的検査だったり、型による静的検査だったりする。

AIで変わるアジャイル開発の現場

スクラムの役割をAIで代替できるか

── 少し脱線してきたので、アジャイル開発の話に戻したいと思います。ここまでは主に、テストにおけるAIの利用ということで、コーディングエージェントを使う話を伺いました。一方で、アジャイルチームにはほかにもさまざまな役割があります。例えばスクラムマスターやプロダクトオーナーの役割は、AIによってどう変わりそうですか。

やっとむ　前提として、スクラムで定義している役割は「責任を誰が持つか」なので、作業の分担ではありません。生成AIでコーディングが高速になっても、責任の分解そのものは残るでしょう。プロダクトオーナーはプロダクトの成功に責任を持つし、開発者はインクリメンタルなデリバリーに責任を持つし、スクラムマスターはプロセス全体、あるいは文化に責任を持つ。

── 個々の役割が変わることは、少なくともAIによっては起きない、と。

やっとむ　構造は変わらないと思いますが、どの役割のどの作業でもAIが役に立つのは間違いないので、やり方は大きく変わっていくだろうと思います。

具体的には、2025年6月に『Scrum Guide Expansion Pack』が発表されました。そこでは、スクラムにおける経験的プロセス制御をAIによって支援できるし、人間の認知力強化やデータに基づいたシステムの改善にもAIは使えるし、さまざまな面でAIが役に立つということが書かれています。

やっとむさん

── チームにおける個々のやり方は、当然ながらAIで変わるだろうと。

やっとむ　一方で、2024年3月の「Agile in the Age of AI」という記事で書かれていることですが、人間の労働力でまかなう部分をAIがやってくれるようになれば、チームが小さくても同じぐらいの成果が出せるようになるでしょう。

人数が少なくなると、主にコミュニケーションのオーバーヘッドが減るという利点があります。10人の人たちが同じことを考えて共通のゴールを目指して協調するのは、もうそれだけで大仕事ですが、それがプロダクトオーナー1人、開発者1人、スクラムマスター1人で済むなら話が早い。

「今日はこれをやりますね」「はい」で、朝のミーティングが3秒で終わってしまうかもしれない。時間が余分に取れるし、作業は早く進むし、すごく生産性の高い少人数のチームという方向に変わっていくのではないでしょうか。

── 極端な話、それが1人になることはありえるでしょうか？

やっとむ　例えばプロダクトオーナーが1人でスクラムを全部できるかというと、たぶんまだ厳しいと思います。ソフトウェアエンジニアリングの知見を持ったメンバーが最低でも1人は必要でしょう。

ただ、その作業がAIで変わる可能性はあります。もしかしたら、プロダクトオーナーがAIエージェントに指示してどんどん機能を作り、それをエンジニアもAIエージェントを裏で使いながらレビューしたり、リファクタリングしたり、テストを改善したり。まだ見たことはないですが、そういうチームが出てきてもおかしくないだろうな、という気はします。

── それでもスクラムというフレームワークの考え方は一緒ということですね。

やっとむ　スクラム自体は、もともと世の中にあるさまざまなツールを使って生産性を高めていきましょう、ユーザーインパクトをよりよくデリバーしていきましょう、という考え方ですから、AIを利用するツールを採用することにも無限の可能性があると思います。

ただし不用意にAIを導入するだけだと危険もいっぱいあるので気を付けよう、人間もチェックしようといった基本的な話もたくさんあって、それらも『Scrum Guide Expansion Pack』には記されています。

ドキュメントの整備にAI活用は必須に

やっとむ　チームが小さくなってコミュニケーションのオーバーヘッドが減るという話をしましたが、ドキュメントについても同じことが言えます。利用するサービスのドキュメントであれ、自分たちが作っているアプリの仕様であれ、NotebookLMに全部入れてしまえば、開発メンバー各自が質問をして理解を深められる。これはかなり便利です。

── 自分たちがドキュメントを書く場面でもAIは活用できそうですね。

やっとむ　はい。Markdownのドキュメントがコード本体と一致しているか、常に最新の仕様に沿った内容であるか、そういった面倒な確認をAIに代替してもらえます。ドキュメントを書く、読む、説明するという作業にAIが入っていくのは、これからは必須になってくるかもしれません。

── 人間が読むためにNotebookLMなどを活用するのは想像ができるのですが、自分たちが作っているサービスなどのドキュメントを整備するのに生成AIを使っていくとなると、例えば「本当にコードと一致しているか」の確認にはどのようにAIを使われているのでしょうか？

やっとむ　AIが「仕様が変わったので、コードとドキュメントを直しますね」と言ってくれるので、「コードは直したけど、ドキュメントはどこを直せばいいんだっけ？」といった確認作業を省力化できるのが大きいです。

その上で、確認はやはり人間がある程度は目で見ています。同じリポジトリにあるコードとドキュメントの差分をそれぞれ見ることもあるし、AIが「このように変えました」と言ってくるのをさっと見て承認するだけのこともあります。

和田　ソフトウェアエンジニアリングの歴史では、ドキュメントとソースコードの乖離がずっと問題だったんです。「ドキュメントさえきちんとしていれば、ソースコードはそこから生成できる」といった考え方もあるのですが、実際、最初に考えた設計がそのまま正しいことはほとんどありません。

ソースコードを書き始めると分かることがいろいろあって、設計を見直す必要が生じる。しかし、そのたびにドキュメントを更新する時間も予算もなく、結果として「ソースコードが仕様です」となりがちです。

── ドキュメントを誰も信じていない状態ですね……。

和田　そうなるともう、ドキュメントを書くことに動機を見出せなくなります。そういう状況が、AIに「ソースコードを変えたので、ドキュメントをそれに合わせて更新してください」とお願いするだけで済むようになった。みんなが一番嫌だった仕事をやってくれるので、これは本当に革命的だと思います。

── ドキュメントとソースコードが同期していると、今度はそれを使うAIにとってもうれしいでしょうね。

和田　間違いないです。AIもうれしいし、人間もうれしい。本当の意味でソースコードとドキュメントが互いにフィードバックし合う構造を、ようやくまともに作れるようになったんですよ。

コーディングエージェントには、これまで構造上うまくいっていなかったものが機能し始める起爆剤になるという面もあるんです。

── つまり、AIが補うのはコードそのものより、むしろコードを取り巻く周辺環境だと？

和田　結局、これまでのソフトウェアエンジニアリングの歴史の中で、コードを書くのがボトルネックだったことって一回もないんですよ。どちらかというと、中長期的にドキュメントとコードが乖離するとか、コードのどこを直せばいいか調べるのに時間がかかるとか、テストを書かなければならないとか、そういったことの方がずっと問題でした。

コードは、書くのにかかる時間よりも、使ったり、読んだり、調べたりする時間の方が長いので、それらに投資する方がはるかに効果があります。

── そこをAIがサポートしてくれる。

和田　AIによるコーディングエージェントは、ここにインパクトがあります。最近のAIエージェントは非同期で仕事をしてくれるので、「これからこういう機能を追加しようと思っているので、どこをどう変えればいいか調べておいて」とお願いすれば、人間が作業している裏で非同期に調べてくれる。結果が出たら、それを人間がレビューして返せばよい。

この意味でコーディングエージェントは、「高いソフトウェアエンジニアリングの能力を備えた本当にすごい相棒が出てきたな」と思っています。コードを書くというのは、その高度な能力の中のごく一部に過ぎませんし、そもそも人間にとってボトルネックだった部分でもない。むしろ、ネックとなっていたのは、ドキュメントを正しく読み解き、その整合性を維持するような能力の方です。そうした本質的な難しさを支援してくれる存在だと、あらためて強く感じています。

ソフトウェアエンジニアの生存戦略

AIでソフトウェアエンジニアは不要になる？

── やや極端な仮定として、例えばTDDで「動作するきれいなコード」の生成と維持がAIだけで可能になったとき、コードを書けるソフトウェアエンジニアはいつまで必要なのか、という不安があるように思います。そういう世界は来るのでしょうか？

和田　2025年7月現在の正直な回答は「分からない」です。そういう未来が顕現するかもしれないし、来ないかもしれない。ここ数年のAIの進化の度合いを考えると十分にありえる未来ですが、そうすると産業構造が変わるので、まだ来ないでほしいという思いも当然あるはずです。どうなるか分からないので、両方の可能性に備えましょう。

── ドメインに一番詳しい非プログラマーが自然言語による指示で欲しいものを作れる、くらいの世界はもう来ていると言えそうです。

和田　システム開発に関しては、それが一番インパクトがあるのは間違いなく、本来はそれが理想としていた世界でもあります。すでにVibe Coding*6という形で、欲しい人・ドメインに詳しい人が作るという世界は、短期的なコーディングにおいては実現し始めました。

── 「短期的」というのは、お話にあった「せいぜい作って1週間で終わり」であるようなコードの生成ですよね。

和田　もうそれだけで十分破壊的ではありますが、やはり今のソフトウェア開発の難しさは、それを維持するところにあります。少なくとも2025年7月時点のAIには、まだそれ以上のスパンでシステム開発を維持するための能力は備わっていないのではないでしょうか。

── それは「テスト駆動開発でやって」といったガードレールがあっても、ということですね。

和田　ガードレールがあればシステムが破滅するまでの期間をもうちょっと先送りにできそう、という肌感覚です。いつまでもコードに対してノータッチ、ノーレビューでいられるかというと、現時点のAIにはそこまでの能力はなさそうに思えます。

これはAIの進化という意味だけでなく、そもそもソフトウェアエンジニアでない多くの人は「やりたいことを整理して、破綻や誤解なくAIに伝える」という能力をまだ持っていないかもしれない、という話でもあります。

── 自然言語で指示ができるようになったけれど、プロンプトエンジニアリングを駆使するだけでシステム開発を誰もができるわけではない、という意味でしょうか。

和田　伝統的なソフトウェア開発の用語で言うと、要望を要件まで落とす力が必要ですよね。ソフトウェアエンジニアは、そのためにロジカルかつ漏れなく構造的に考えるスキルを日々鍛えています。それを誰もがいきなりできるかというと、たぶん限界はありますよね。

AIエージェントは、要件を与えれば結構うまいことやってくれるけれど、要望を要件まで落とさなければ「博打」になってしまうことが多くて、その博打のリターンが、現状はせいぜい1週間、長くても2週間くらいしかもたないという感じです。

やっとむ　できる、できないというよりは、「何ができるのか」という話だと思います。

コーディングエージェントは、いわゆる「エンドユーザーコンピューティング」の正解とみなすこともできて、自分の個人的な業務を少し改善する程度のツールであれば、現在でもほとんどの人が開発可能です。

とりわけ、ソフトウェアのことを全然知らない、それこそ何をインストールするかも分からない人でも、環境構築から手助けしてくれるんです。

和田　プログラミングの民主化というか、欲しいものはあるけど作れなかった人は世の中にたくさんいて、そういう人がAIエージェントの助力を得て動くものを作れる段階には来ている。これだけでもう革命的です。ロングテールのプログラミングに対する要望が実現されるようになりました。

── 自分で使うツールであれば、壊れたらまた作り直してもらうので十分かもしれませんしね。

やっとむ　もちろん対象によりますけれど、そういう気はします。それが、大規模なプロダクトやスケーラビリティが求められるケースになると、いわゆるソフトウェアエンジニアリングが必要になる。

和田　私も同じ肌感覚です。

AI時代にソフトウェアエンジニアはどう成長し、どう生き残るか

やっとむ　ここまで話してきたように、確かにコーディングエージェントはすごい相棒で、チームのコミュニケーションにかかるボトルネックも減らせるのは間違いありません。

一方で組織としては「若手をどうやって育てるか」という点に悩むこともあります。できるシニアエンジニアがAIを使うと成果は大きいですが、ジュニアエンジニアにも同様の力をどうつけてもらうかは、多くの組織が悩んでいるでしょう。

和田　そうした懸念も理解できますが、シニアエンジニアが有利でジュニアエンジニアが不利かというと、そういうものでもないと考えています。どちらかというと、不確実な状況に対する姿勢や好奇心、柔軟性といった「ネガティブ・ケイパビリティ」の問題なんですよね。

不確実な状況に対して、それを楽しむとか、あるいは新しいものを学ぶことを好むとか、そういった可能性を開く方向に自分の考えを寄せていくのが大事だろうなと思っています。そういう意味では、可処分時間が多いジュニアエンジニアの方が有利かもしれません。

やっとむ　なるほど。そういった意味では、勉強や創作に使う時間をどう確保するかが課題ですね。AIがアウトプットをどんどん出してくるため、人間が心を無にしてコードを書く時間すら奪われてしまった。ひたすら何か考え続けなければならず、それが厳しいという話もよく耳にします。

生産性が上がっても「仕事が増える」だけだと、暇にはならず、楽にもなりません。早く仕事ができるようになった分、もうちょっとゆとりを持って、勉強や創造に時間を使う方向に世の中が進んでいったらいいのになと思います。

和田　学習支援という意味でもAIの力は凄まじいので、これについてもAIを活用できるかもしれないという話は一つあり得ると思います。これまで人に聞かなければ分からなかったことが、AIに聞いて最初のハードルを越えやすくなりました。

やっとむ　逆に、AIによって生産性が上がったことで、自分とは違うレベルに手が届きにくくなった面もあると思っています。例えば、生産性が上がって3人だけのメンバーがそれぞれ神様のような仕事をしているチームに入り、「このチームで今の自分にないスキルを磨こう」と思っても、たぶん難しい。メンバーの多様性を大事にしてリスペクトするスクラムで、「できる人がどんどんやるだけ」のチームだと、まったく勉強にならない可能性があります。

── 最後に、お二方の生存戦略を伺ってもよろしいでしょうか？

和田　先ほど話題に出たように、今の自分の知識はAIモデルの中に入ってしまっています。つまり、コンサルタントとしては完全に競合。「和田さんと契約しなくてもClaudeに聞けばよくない？」となりかねない。

「それでも生身の和田さんと仕事がしたい」という付加価値を作らないと生きていけない状況です。もはや、この状況をどれだけ好奇心を持って楽しめるか、というところでやっていくしかありません。

── 和田さん自身も、それ以上の具体的な戦略はない、と。

和田　そのとおりです。まいっちゃいますよね。なので、私自身は可能性を閉じず、コーディング能力が引き続き競争力になる未来と、競争力にならない未来のどちらもあり得ると想定して、その両にらみでやっていきます。

── やっとむさんが考える生存戦略も教えてください。

やっとむ　6年前、チームや組織のコミュニケーションをよくするきっかけ作りのために『心理的安全性ゲーム』というカードゲームを制作しました。ゲーム作りには、価値をユーザーにデリバリーするアジャイルの体験が全部詰まっています。アナログでもデジタルでもいいです。この「自分でゲームを作る」という体験を全ての人におすすめしたいですね。

── AIが当たり前の世界でソフトウェアエンジニアとして生き抜くためのスキルセットを手に入れるのに、それらの体験が効果的だということでしょうか。

やっとむ　まさにその通りです。ゲーム作りには、ユーザーを意識して楽しんでもらえるものを作る、というプロダクト思考の経験やスキルが詰まっています。完成したものを人と遊び、喜んでもらったり、フィードバックをもらったりする経験は、コードさえ書ければいいという姿勢では生き残りが厳しくなった時代に、自分が気付いていない強みを見つける機会になると思います。その全工程で生成AIを活用できますし、その上でこうした主体的な活動は、まだ人間しかできないと感じます。

和田　抽象と具象を行ったり来たりする作業は、やっぱり人間ならではの思考があるような気がしますよね。

やっとむ　はい、きっとそうだと思います。

── 生成AIと自動テストの話から始まって、最後はソフトウェアエンジニアの生存戦略まで、たくさんの観点でポジティブかつ楽しいお話をお伺いできました。今日は本当にありがとうございました。