はじめに
2026年度に新卒エンジニアとして入社しました、のーらです。
ペパボでは、昨年に引き続き今年も日本の Test-Driven Development（TDD）の第一人者である t_wada さんをお招きして、TDD ワークショップを開催しました。今年の講義タイトルは「AI 時代の TDD」。午前は AI 時代における TDD についての講義、午後は”AI 禁止”のペアプログラミングで TDD を体験する二部構成で、午後のワークショップには10名が参加しました。
研修後、参加者それぞれに感想を書いてもらいました。この記事では、その感想から浮かび上がった3つのテーマに沿って、当日の学びをお届けします。
ペパボの TDD ワークショップは2021年から毎年開催しています。昨年の様子は『t_wada さんによる2025年度版 TDD ワークショップを開催しました』を、これまでの記事は TDD タグの一覧からご覧いただけます。
- はじめに
- 研修概要
- 「思考は外注できるが、理解は外注できない」
- AI 禁止のペアプロ TDD
- 「コードレビューの役割の引っ越し」
- 研修担当者より なぜ2026年に TDD 研修を行うのか
- みんなの感想
- おわりに
研修概要
当日は午前に講義、午後にワークショップの二部構成でした。
- 午前：講義「AI 時代の TDD」＋ 質疑応答
- 午後：ペアプログラミング形式による TDD 実装課題（AI ツールの使用は禁止！）
事前準備や TDD の基本的な流れは昨年と同様なので、詳しくは昨年の記事をご覧ください。ここでは、講義の要点を3つ紹介します。
AI との開発スタイル
AI との向き合い方の整理です。対話しながら一緒に開発するやり方（伴走）は、コントロールしやすい一方で人力なのでスケールしません。自走する AI に任せて並列開発するやり方（委託）は、圧倒的に速くスケールする一方で、人間によるコントロールや状況把握が難しくなります。
認知負債
AI によるコード生成のスピードに人間の理解が追いつかず、その理解の遅れが積み上がっていくことです。動くコードは手元にどんどん増えるのに、それを説明できる人がいない。この「見えない負債」が、講義全体を貫く問題意識でした（詳しくは次の章で！）。
レビューの役割の引っ越し
AI に委託すると、人間のレビューがボトルネックになります。講義では、これまでレビューが一手に担っていた役割を、複数の仕組みに分散させるという考え方が示されました。その引っ越し先の一つが、TDD で作る「第一級の成果物としてのテストスイート」です（詳しくは5章で！）。
これらを念頭に、ここからは参加者の視点で当日を振り返っていきます。
「思考は外注できるが、理解は外注できない」
SUZURI・minne 事業部、iOS エンジニアの satton です。minne の iOS アプリを開発しています！
午前の講義の中で一番刺さったのが、Andrej Karpathy が引用して広まった、kache（@yacineMTB）さんの「思考は外注できるが、理解は外注できない」という言葉でした。
この章では、その言葉の背景にある「認知負債」という考え方と、AI を使う受講生としての実感を通して、講義で示された問題意識を紹介します。
認知負債（Cognitive Debt）とは
認知負債とは、AI によるコード生成のスピードに人間の理解が追いつかず、動いているコードの裏で「書いた本人が中身を分かっていない」状態が積み上がっていくことです。技術的負債はコードを読めば見えるものですが、認知負債は見えません。Ward の Debt Metaphor（＝人間のドメイン理解が先行し、コードがそれに追いつかない状態を”借金”にたとえた、本来の技術的負債の考え方）が「人間の理解が先行し、コードがついてこない」状態を指していたのに対して、認知負債はその逆で、「AI のコード生成が先行し、人間の理解がついてこない」状態を指しています。
AI 活用が進むなかで感じていたモヤモヤ
正直に言うと、私はもうほとんど自分でコードを書いていません。開発は基本 Claude Code 一本で、いまは対話するだけでなく、Agent に一部を任せて実装を進める場面も増えてきました。AI 活用を始めた1年ほど前は、レビューで「セルフレビューが甘い」「なぜこの実装なのか説明できていない」と指摘されたことも何度かあります。動くコードは出せても、自分の中で腹落ちしないまま PR を出してしまっていた、というのが正直なところです。いまは AI レビューを挟むなど、使い方も少しずつアップデートできているのですが、「動いているコードの中身を、自分自身がどこまで理解できているか」というモヤモヤは、形を変えて残り続けています。自分がレビューで指摘されていたのは、まさにこの認知負債がたまっている状態だったのかもしれません。
「なぜ今 TDD なのか」という問いへのヒント
設計を考えるのも、最終的にレビューして判断するのも、いまはまだ人間の担う部分が大きいと感じます。この見えない負債と向き合う仕組みを持っておかないと、いずれ困るなと、講義を聞きながら思っていました。「AI がここまで書いてくれる時代に、なぜ今 TDD を学ぶのか」。事前課題のころからずっと引っかかっていた問いに、この日ひとつヒントが見えた気がしました。TDD は、コードの安全性を担保するいくつかの仕組みのうちのひとつで、Red → Green → Refactor のサイクルは、「理解を先に置く」ための意識づけそのものなのかなと思いました。同じ講義を受けた Keith さんや kimata さんからも、この「理解を守る手段」としての TDD を「テストは動く仕様書」と表現する感想が上がっていましたが、まさにその通りだと感じます。AI に実装を丸投げして理解を置き去りにするのではなく、まず人間がテストで仕様を厳密に定義する。それこそが今、私たちが TDD を学ぶ意味なのかもしれません。
一方で、まだ完全にスッキリしたわけではありません。私自身、普段の iOS 開発では実装のあとにテストを書くことが多く、UI の挙動をテストコードでどこまで見るべきなのか、正直まだ自分の中で答えが出ていません。AI 前提の開発で、このサイクルをどこまで律儀に回すのが良いのか、ここは現場で答えを探していく宿題として持ち帰りたいと思います。
AI 禁止のペアプロ TDD
2026年度に新卒エンジニアとして入社しました、kei です。
午後は、午前とは打って変わって「AI 禁止」のペアプログラミングで TDD を体験しました。お題は「整数の閉区間を表すクラスを作る」。二人一組で、コードを書くドライバーと、指示や提案を出すナビゲーターに分かれ、交代しながら Red → Green → Refactor を回します。今回は Ruby と RSpec を使いました。
なぜ AI を禁止したのか
（3章で触れた）認知負債のちょうど裏返しです。自分の頭だけで考え、自分の手で書く。ランチで t_wada さんが言っていた「AI 時代の研修、人を集めるなら、人が集まらないとできないことに時間を使いたい」という言葉が、この時間の意味をよく表していました。AI なら数十秒で終わる課題をあえて人間の手に取り戻し、手を動かしながら TDD への理解を深める時間でした。
オーガニックコーディング
研修では久しぶりのオーガニックコーディング（AI に頼らず自分の手で書くこと）だと皆で言っていました笑。私は最初「整数の閉区間なんて簡単すぎでは？」と思っていましたが、手を動かすと議論が次々に生まれます。
たとえばクラス名を最初 IntClosedRange にしていましたが、「型で守れない Ruby にこの名前は合わなくない？」という話になり、ClosedRange に落ち着きました。「別の閉区間を完全に含むか」の判定も、演算子オーバーライドを使えば集合の大小として >= で書けるのでは、と思いついて実装しました。こうした設計の相談をその場で交わすのが、思いのほか楽しかったです。テストが通った瞬間の嬉しさも、手を動かしていたからこそでした。
ついでに印象的だったのは Ruby と RSpec の相性の良さです。テストがまるで自然言語のように読めて、テストは仕様書という言葉がぴったりはまりました。
手を動かして見えてきたこと
気づいたことは、仕様を明示することの大切さです。私たちのお題では、下端点と上端点が同じ区間（[5,5]）は作れるはずでした。でもテストで示さないと、後から見た人には「仕様なのか、たまたま弾いていないバグなのか」が分かりません。議論している途中で時間切れでしたが、t_wada さんの「テストは、後から見た人がクラスの振る舞いを分かるように書くべき」という言葉が印象に残りました。>= の包含判定も、境界のテストを固めてはじめて仕様になります。
そして書きながら腑に落ちたのは、テストを書くことと仕様を書くことはほぼ同じ営みだ、ということです。先にテストを書くというより、自然言語で語られる振る舞いをコードに翻訳したものがテストなのだ、という順番のほうがしっくりきます。
AI 禁止は本質ではない
行き着いたのは、「AI 禁止そのものは本質ではなかった」ということです。人間は自分が理解しているものしか出力できません。でも AI は、理解していないものまで出力できてしまう。だからこそ理解と出力を同期させながら進めることが大切で、手を動かしたり話し合いながらのコーディングはその同期に役立ちます。すべてを理解する必要はなく、何を理解すべきかを取捨選択できて、AI への依存度を調整できることが重要なのだと思いました。
AI 禁止は、その感覚を体で覚えるための仕掛けだったのだと思います。
「コードレビューの役割の引っ越し」
2026年度に新卒エンジニアとして入社しました、kimata です。
これまで、コードの品質チェックは人間のレビューで行われてきました。しかし、AI によってレビューの負担が大きく変わってきています。AI は人が読むよりずっと速く大量のコードを生成しますが、それを読んで理解し、承認する人間の速度は変わりません。実際に自分がレビューをする側になってみると、AI が生成した大量のコードを読んで承認する作業は、ここ最近負担が大きくなっています。レビューだけで品質を保証するのは難しくなってきていると実感していました。
講義ではこのような問題に対して、レビューが担ってきた役割を別の仕組みに分けて持たせるという考え方を学びました。具体的には次の5つです。
- 上流での仕様レビュー
- 仕様を表すテストスイート
- 型システムや制約によるガードレール
- ビジネスへの影響度に応じたリスクマッピング
- ペアプロ・モブプロによる理解の共有
この5つのうち、今回の講義では、実際に手を動かして TDD を体験しました。Red→Green→Refactor のサイクルを回してみると、先に書いたテストがそのまま仕様を表す成果物になることが分かりました。また、TDD は小さなサイクルで進めるので、一度に読みきれない量のコードが生成されることも防げると学びました。
今後は、まずテストを AI と一緒に書いて、その内容を自分が理解して仕様として確定させる、次にそのテストを通す実装を AI に任せる、最後にテストが通ったことを確認して次の小さなタスクに進む、というサイクルを回していきたいです。このサイクルなら、自分が理解しているテストが仕様を保証してくれるので、生成されたコードを隅々まで読まなくてもよくなり、レビューの負担を減らせると考えています。
研修担当者より なぜ2026年に TDD 研修を行うのか
EC 事業部事業開発チームエンジニアのどすこいと yukyan です。普段は短期間で顧客に価値を提供するプロジェクトで開発しています。僕たちは、今年度の新卒研修を企画する立場として本ワークショップ実施の提案をしました。同時に、ワークショップ参加者として自らも参加させていただくことになりました。
GMO ペパボでは、毎年 t_wada さんに TDD 研修を行なっていただいており、今年もご依頼をさせていただくことにしました。ペパボでは毎年研修担当が変わるため、慣習的に同じ研修を続けているわけではなく、その都度研修内容の検討が行われます。例えば、去年は「Vibe Coding 研修」を行い、今年は「設計研修」「SRE 研修」が新たに組まれました。TDD 研修も例外ではなく、今年の目的を整理した上であらためて検討しました。その上で、やはり t_wada さんに TDD 研修を行なっていただくべきだと考え、今年もお呼びしたという背景があります。
前提として、今年の研修では、2026年の AI 動向を踏まえ次のような目的で研修企画を進めていました。
- 自分が何を知らないかを知り、自律的に学び続けられる状態になる
- 配属後すぐに事業インパクトを出せる助走をつける
- AI を前提とした技術選定・判断・実装ができ、顧客体験まで考えられるようになる
今年は複数の研修を用意しており、それぞれがこれらの目的の一部を担います。TDD 研修は、このうち特に1つ目と3つ目に寄与すると考えています。
t_wada さんの TDD 研修は、TDD を厳密に実施する体験をするだけではありません。その時々の時流を踏まえて、いまどんな状況でどんな問題が生まれているのか、そしてその中で TDD はどのような立ち位置にあるのかを学ぶことができます。昨今では、直近の AI エージェントの台頭による開発現場の変化についての考え方を学べます。午前の部の講義による理論と、午後の部の AI を使わないワークショップによる具体的な実践、その両面から体験できます。
一昨年や去年と比較して、さらに多くのことが AI エージェントによって可能になりました。そんな昨今における「AI 時代のソフトウェアエンジニア開発」についての考え方や技術の学び方、開発の進め方についてのヒントに気づけるように講義をお願いしました。これにより、3つ目の目的を達成できると考えました。
また、改めて考察すると、目的のうちの1つ目にも寄与すると考えています。t_wada さんは TDD を「不確実性にまみれたソフトウェア開発に少しずつ確実性を持たせていく、一種の陣取り合戦」にたとえ、テストを書いてコードを通すことで「よくわからない領域」を少しずつ切り崩し、「分かった領域」を広げていく感覚だと語っています（レバテック LAB のインタビューより）。いま自分が何をわかっていて何をわかっていないのかを明らかにしながら進めるこの営みは、自律的に学び続けるための方法の一つになります。
毎年ゼロベースで検討して、それでもお願いしたくなる、そういった研修だと感じています。
そんな t_wada さんの AI DevEx2026 の資料も公開されたのでここでも共有しておきます！
改めまして、t_wada さん、今年もありがとうございました！
みんなの感想
Keith
研修の講義を通じて、AI 時代における TDD の重要性を学びました。AI がコードを生成する時代だからこそ、テストで仕様を明確に示すことが人間の重要な役割だと感じました。また、あえて AI を使わずに RSpec で TDD を一通り実践したことで、Red・Green・Refactor のサイクルを体感でき、TDD への印象が一層深まりました。
kimata
研修の講義を通じて、AI が生成したコードの検証を人間のレビューだけに頼るのではなく、複数の仕組みに責任を分散させるという考え方を学びました。TDD はその分散先の一つであり、テストという形でレビューの役割の一部を肩代わりできると知り、とても納得できました。また、午後のハンズオンでは、AI を使わずに TDD の Red・Green・Refactor のサイクルを一通り体験する演習を行いました。テストは通すことだけを目的にせず、後から読む人が仕様を読み取れる「動く仕様書」になるように書き、コードとあわせて整えていくことの大切さと難しさを実感しました。
tateken
今回は AI 時代における TDD 開発の重要性について学びました。AI が大量にコードを実装するからこそ、テストを用いることで品質を保証する重要性を学びました。普段はあまりテストなど書かず、実装することがほとんどだったので、AI に TDD を意識させて行きたいと思いました。また、Rspec を AI を使わずに書いたことは新鮮で、実際のサイクルをきちんと理解することができました！
kei
講義を受ける前までは恥ずかしながら「テストを先に書く」だけが TDD の本質だと思っていました。常に進捗を確認可能にするために、問題を細かく刻んで一歩ずつ理解しながら進むための考え方でもあるというのは新しい視点でした。AI とコーディングをする際にも TDD が役に立つことを知れたのは収穫です。AI が大量のコードをアウトプットできる時代に、理解を追いつかせるために何が必要なのかを少し見出せた気がします。
Shin
普段 Claude Code と Codex に課金しまくっている身なので、「FOMO は行動嗜癖（依存症）の入り口」のくだりで少し胃が痛かったです。一番覚えているのは「ハルシネーションは腐敗と発酵の関係」という喩えと、午後のオーガニックコーディングでテストが通った瞬間が思ったより嬉しかったこと。配属先では AI の自律マージ率を上げることを目標としているので、「コードレビューの役割の引っ越し」の話は他人事ではなく、正直まだ自分の中で答えが出ていません。
maru
講演で一番刺さったのは「思考は外注できるが、理解は外注できない」という言葉でした。AI がコードを書く速度に人間の理解が追いつかなくなる「認知負債」は、技術的負債と違って見えづらい、という指摘に、普段 AI エージェントを使い倒している身として強い危機感を覚えました。午後は、AI を使わず RSpec で Red・Green・Refactor を回しました。テストを先に書くと「何を作るか」の理解が先に固まる感覚があり、仕様書になるテストコードを書く良さについて、実感できました。
のーら
私は普段、AI に翻弄されています。特にこの講義以前は、Claude Code に任せれば実装はぐんぐん進むけれど、自分の理解が追いつかず、「便利だけど、これでいいのかな…？」という状態でした。
講義では「AI と伴走」「AI に委託」という使い分けの整理があり、少し視野が開けたと同時に、「どこまでを人間がやるか」という観点を持つことが大切なのだと思いました。午後のペアプロ TDD では、AI 禁止のルールのもと、「Red → Green → Refactor」のサイクルを回す、真の TDD を体験しました。自分の頭だけで考えるオーガニックコーディングは久しぶりで、新鮮な楽しさがありました。同時に、エージェンティックコーディングにおいても TDD が有用であるということを体感出来た気がします。小さなサイクルで実装を進めていくことで commit が分割されやすくなり、人間にとっての理解のしやすさや、後の整理のしやすさにつながるのだと思います。
TDD のサイクルは、AI と開発する時代でも人間の理解を置き去りにしない、あるいは置き去りになっても後から取り返しがつくようにするための土台になると感じました。これからは翻弄されるのではなく、TDD を味方につけて、AI との使い分けを自分で決められるエンジニアになっていきたいです！
satton
「AI がコードを書いてくれる時代になぜ TDD なのか」という問いへの答えが、この研修で少しヒントが見えた気がしました。AI によるコード生成が先行して人間の理解がついてこない「認知負債」という概念が印象に残り、TDD がその認知負債に効くのかもしれないと感じました。AI をどう使うかだけでなく、自分の理解をどう守るかも考えていきたいと思えた研修でした。
yukyan
去年に続いて今年も研修を行っていただき、大変感謝しています。午後の研修については、直近だと BuriKaigi 2026 のワークショップでも受けさせていただきました。同じ研修を複数回受けても、休憩中に他の方の TDD の進め方を眺められる時間があるおかげで、毎回「こんなやり方があるのか！」という新しい発見につながり、二度目でも変わらず楽しく、学びの多い時間になっています。実際に業務でも、実装を書く前にまずテストを書く（テストファースト）を心がけるようになり、受けて本当に良かったと思っています。ありがとうございました！
どすこい
TDD 研修は Burikaigi2026 でもワークショップをさせていただいたので、今年は二回目の体験となりました。また、自分が1年目で新卒研修を受けたときにも TDD ワークショップを受講させていただきました（t_wada さんによる2024年度版 TDD ワークショップを開催しました）。
ワークショップでは、他の新卒エンジニアの皆さんのチームと比較して、ずっと遅くじっくりとした進行になっていたところが印象的でした。そもそもエラーをどうするのか、テストに何を残すべきなのか、どういった入力や出力にすべきかというところの議論や実施に時間を多く使っていました。逆に、具体的な機能群の実装に関しては、割とサクサク進んでいました。
一番最初の TDD のワークショップから、エンジニアとしてのキャリアを2年間歩んでみて、機能の実装以外にも想いを馳せることができるようになったんだなという気づきを得たワークショップでした！
おわりに
この記事では、参加者の感想から浮かび上がった3つのテーマに沿って、今年のワークショップを振り返ってきました。AI に理解が追いつかない「認知負債」（3章）、AI を止めて手を動かすことで理解を取り戻す体験（4章）、レビューの役割をテストへ引っ越す試み（5章）。切り口はさまざまでも、どれも「AI と開発する時代に、人間の理解をどう守り続けるか」という同じ問いに向き合ったものでした。
私たちも、AI と共に開発する時代のなかで、手を動かして得た「理解」を大切にしていきたいと思います。この記事が、これから講師をお招きする方や、AI 時代の開発に向き合う方の参考になれば幸いです。
