t-wadaが説く、今あえて“自分の手”でコードを書く理由「バイブコーディングは、エンジニアのためのものではない」
「バイブコーディング（Vibe Coding）」の熱狂は、プロフェッショナルなエンジニアにとって何を意味するのだろうか。その答えの一つが、2025年10月30日に開催された「AI駆動開発カンファレンス 2025」にて明かされた。
答えの主は、テスト駆動開発（TDD）の第一人者・t-wadaこと和田卓人さん。「AI時代のソフトウェア開発を考える」と題した講演の中で、「バイブコーディングはエンジニアのためのものではない」と指摘した。
果たして、その言葉の真意とは。和田さんの考えを聞いていくと、AI全盛の時代にエンジニアが果たすべき役割と、自らの手を動かし続けることの大切さが見えてきた。
プログラマー テスト駆動開発実践者
和田卓人さん（@t_wada）
学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。『SQLアンチパターン第2版』（オライリージャパン、2025）監訳。テストライブラリ power-assert-js 作者
目次
AIの登場は、問題の顕在化を圧倒的に早めたウォーターフォールのプロセスを15分で繰り返す労力は外注できるが、能力は外注できない「ジュニア不要論」はレイオフの方便
AIの登場は、問題の顕在化を圧倒的に早めた
バイブコーディングをはじめとするAIの活用によって「開発生産性」が高まった結果、本来は開発規模が大きくなったり長期化したりしたときに出てくるはずの問題が、ごく短期間で発生するようになりました。
例えば、技術的負債の高速な積み上げによって、かえって開発のスループットが低下するといった問題。AIが膨大な量のコードを吐き出す中で、人間がレビューできない分量のプルリクエストが積み上がり、結果として人間のキャパシティーが限界を迎えています。
またバイブコーディングは、未知の領域を大量に生産する開発スタイルとも言えます。当然アタックサーフェスが増え、セキュリティーリスクの高まりが問題視されています。
一見すると、AIエージェントの登場で新たな問題が数多く発生しているように思えますが、果たして本当にそうなのでしょうか。
技術的負債の高速な積み上げによる開発のスループット低下も、コードレビューがボトルネックになることも、昔からあった問題です。「正しく要件を定義し、きちんとドキュメントを書けばコーディングは自動化できる。だから設計が大事だ」という考え方も、それ自体は別に新しくありません。
つまり、問題の構造自体は変わっておらず、AIという道具があまりにも強大すぎるが故に、問題の顕在化が圧倒的に早まっただけなのです。
バイブコーディングは、あくまでも「ソフトウエアエンジニア以外の人々」に対する革命です。これまで障壁となっていたコーディングという作業が、AIを用いることで簡単に突破できるようになり、ソフトウエア開発の裾野がどんどん世界中に広がっていきました。
当然、裾野が広がれば広がるほど、その頂上は高くなります。プロフェッショナルなソフトウエアに求められる品質やインパクトは、これまで以上に高くなっていくのです。私たちは、その頂上が高くなった世界でどう戦っていくのかを考えなければなりません。
バイブコーディングは、われわれソフトウエアエンジニアのためのものではなかったのです。
ウォーターフォールのプロセスを15分で繰り返す
ソフトウエアエンジニアリングの世界において直面する課題の多くは、過去に類似の問題があり解決されてきているケースがほとんどです。一つ一つの問題を取り巻く状況は違っていても、問題の構造自体は同じであることが多い。
テスト駆動開発やドメイン駆動開発、制約理論、プロダクトマネジメントを通して学んだことは、AI時代のソフトウエア開発で直面する課題に対しても有効です。
そのため私たちは、「AI」と「これまで学んできたエンジニアリングのプロセス」をどうやって融合させていくかを考える必要があります。
今はまだ、人間がAIに手取り足取り指示を与えるマイクロマネジメントの時代ですが、ゆくゆくはもう少し宣言的な形で「自ら考えて、自ら動いてもらう」方向へシフトしていくでしょう。
ここで注意しなくてはならないのは、AIは自走するが、迷走も暴走もするということです。ガードレール設計としてのソフトウエアエンジニアリングが求められるようになり、「バージョン管理」「テスティング」「自動化」といった技術の三本柱の重要性がより増していきます。
ソフトウエア開発では、後の工程に行けば行くほどコードにダメージが残り、ロールバックが効きにくくなる。そのため、設計をきちんと詰め切ることが大切ですが、全部を人間が考えると、どうしても不完全な設計になります。そこで助けになるのが、『Kiro』や『Spec Kit』といったスペックドリブンディベロップメント（SDD）系のツールです。
個人的に、AIとの協業は「ウォーターフォールのプロセスを15分間で繰り返す」みたいな世界だと思っています。
AIとの対話や議論を通して、ソフトウエアの仕様をきっちり詰めていく。その過程で生まれたタスクを分割し、テスト駆動開発のワークフローを回していくといった流れが、現時点でのベストプラクティスだと私は考えています。
労力は外注できるが、能力は外注できない
ここで一つ、自分の胸に手を当てて、考えてみてほしいことがあります。皆さんは、最初から正しい設計ができたことが、これまでの開発経験の中でどれだけありましたか？
正直なところ、私は一度もありません。
「よし、完璧だ」と思ってコードを書き始めたその3秒後に「理解が浅かった」と気付くことは、いくらでもあります。コードを書き進めることで対象領域への理解が深まり、設計への良いフィードバックが返ってくる瞬間というのを、私たちは何度も経験しているはずです。
人間の設計判断能力を上げていくために必要なフィードバックは、自らの手でコードを書くことによって一番多く得られます。AI時代であっても、あえて「オーガニック・コーディング」（人間が自分の手でコーディングする）を行うことは効果的な選択です。
最新の研究によれば、AIは増幅器であり、人や組織の能力を映す鏡です。高度なAIから引き出せる性能は、組織や自分自身の能力に比例します。いくらAIが進化しようとも、人間側の能力を上げていかないと、開発スピードや組織の能力は上がりません。
DORA Research: 2025dora.dev
AIの登場によって、プログラミングスキルはいらなくなるどころか、むしろもっと必要になります。自分に分からないものを、レビューすることはできません。労力は外注できますが、能力は外注できないのです。
AIを使って開発の進捗を高めるだけではなく、AIを駆使して自分の能力を上げていくことも忘れずにやっていくべきでしょう。
「ジュニア不要論」はレイオフの方便
現時点のAIは、物理的な制約のないソフトウエアという巨大で複雑な構築物を、自力で作り続けられるレベルには至っていません。10年後には解決されている問題かも知れませんが、来年や再来年に解決されているかと言われたら、そうではない。
これから先の10年間、誰がソフトウエアを作り、育てていくのか。現在シニアと呼ばれているエンジニアの多くは、10年後には引退しているでしょう。もはやAIに指示を出せば良くなる時代になっていたとしても、その指示は一体誰が出すのでしょうか。
つまり、後進を全く育てずに、機械で単純に置き換え可能な世界ではないのです。
近頃出回っている「ジュニアエンジニア不要論」は、あくまでも「短期的な雇用」の観点での話でしかありません。「AIがこれから仕事を代わりにやってくれるようになるから、人員を減らします」というのは、因果が逆です。
そうではなくて、「人員を減らしたいから、AIを言い訳にします」というのが現状です。「レイオフの方便」としてAIが使われているだけなので、若手の皆さんにはその点を見間違えないようにして欲しいです。
若手社員をAIに置き換えることは「これまで聞いた中で最も愚かなことの一つ」…アマゾンのクラウド責任者が警鐘businessinsider.jp
新しいツールに対する受容性やアンテナの感度は、基本的に若手の方がはるかに高い。フットワークの軽さ、可処分時間の多さ、アンラーニングすべき事柄の少なさは、激変していく時代を生きていく上での確かな武器になります。
先行きの見えない不透明な状況下では、選択肢を狭めるのは危険です。AIにすべてを賭けるのではなく、「AIに半分賭ける」くらいの気持ちで、視野を広く保ち続けた方がいい。
いくつかの可能性を並行して抱えながら、自分の手を動かし、自分の頭で考え、変化そのものを楽しむ。そのメンタルモデルを持つことが、一番大切です。
取材・文・写真／今中康達（編集部）