2026_devsumi_ozono.pdf

デブサミ福岡2026の登壇資料です
https://event.shoeisha.jp/devsumi/20260911/session/7157

Transcript

1. なぜ「テストが通った」は AI 時代に信用できなくなったのか 〜受け入れテスト駆動開発(ATDD)にたどり着くまで〜 2026.09.11 Developers Summit 2026 FUKUOKA B-4
2. 大園 博昭 ・2015年〜 自動テスト専門チームを立ち上げ、E2E自動テストのライ ブラリ・サービスを開発 ・2017年頃〜 SET(Software Engineer in Test)として開発者テスト 支援・CI/CD整備・開発フロー改善 ・2026年〜 現職にて、テストを含めた全社横断的な開発環境改善 ・福岡在住
3. なぜ「テストが通った」はAI時代 に信用できなくなったのか
4. AIにテストを書かせることも増えたのでは？ なぜ「テストが通った」はAI時代 に信用できなくなったのか
5. よく見るパターン 機能開発 AI テスト 機能実装のコードを見た上で、通る「だけ」のテストを書いてしまう
6. よく見るパターン AI 機能開発 AI テスト その場合もお互いがお互いのコードを見ることに変わりはないので、制御が必要
7. なぜそんなことが起きてしまうのか？ OpenAIの論文 1 ❙ 強化学習の過程でユニットテストを全て通せと命令 →目的達成のためにテストを意味のないものへ改ざ んするケースが出現 ❙ CoTには「Letʼs hack」なんて書かれていたことも ❙ 意味のないテストの例→テスト冒頭でexit(0)を返す ように改ざんしていた Anthoropicの論文 2 ❙ テストが失敗するとハードコードしてテストを改ざ んすることがあった ❙ テストでズルを学んだモデルは他領域でも不誠実に なるという結果も ❙ テストが通ることを報酬として与えられた場合、 「テストを通すこと」にフォーカスが当たってしま うのはむしろ自然であり、指示では防げないものに なる 1. Andre Hora, Romain Robbes, "Are Coding Agents Generating Over-Mocked Tests? An Empirical Study", arXiv:2602.00409, 2026. https://arxiv.org/abs/2602.00409 2. Dipongkor et al.. "Test Coverage Analysis of Agentic Pull Requests", arXiv:2607.18057, 2026. https://arxiv.org/abs/2607.18057
8. じゃあどうするか？ テストを先に書き、 そのテストを通す実装を書く ↓ いわゆるTDDの出番では？ ↓ Function単位だけでなく、開発工程全体をTDD化できないか？
9. 受け入れテスト駆動開発(Acceptance Test Driven Development) 古くは2000年代から ❙ テスト駆動開発(TDD)をシステム全体に拡張した開 発手法。実装前にE2E相当のテストを書く ❙ 受け入れ条件(AC)を実装前の設計段階で関係者が 集まって議論・設定することがミソ ❙ 2008年ごろElisabeth Hendricksonが講演資料1で ATDDという言葉を使ったのが(おそらく)広まる きっかけに ❙ 自動テスト系技術の発達、AIの台頭とともに最近は 日本でもちらほら話を聞くようになった 1. 2. しかし流行らなかった… ❙ 実装前の工程が多く、かつ同期的なコミュニケー ションが多く必要になるため、愚直にやるにはコス トが大きくなる ❙ TDDは開発者個人の手法として取り入れられるが、 ATDDはチーム全体を巻き込む必要がある ❙ 提唱者であるElisabeth自身も2024年に出した ATDD Revisedというコラム2で、「ATDDは現実 世界の開発には重すぎた」というコメントを出して いた Elisabeth Hendrickson, "Driving Development with Tests: ATDD and TDD", Quality Tree Software (STANZ 2008 / STARWest 2008) 2008. https://curiousduck.io/assets/pdfs/atddexample.pdf Elisabeth Hendrickson, “Acceptance Test Driven Development (ATDD) Revisited”, Curious Duck, 2024-06-27. https://curiousduck.io/posts/collections/2024-06-27-atdd/
10. 人間にはお世辞にも流行らなかったATDDだが… 人間には辛くても、AIだったら？ ❙ Acceptance Test(ほぼE2E Test)を書くのが辛い→AIにやらせれば良いのでは。10-20年前に比べれば自 動テストまわりの進化はとんでもないことになっている ❙ チームで足並みを揃えるハードルが高い→同期的なコミュニケーションが増えたり、実装前に考えることが 増えるかもしれないが、そこもAIにアシストさせたら良い ❙ 時間がかかる→最終的にAIに書かせることができるのであれば、時間的なコストの持つ意味合いは変わって くる。極論daytimeに設計を終わらせて夜中にAIへぶん投げることもできる…かも 理想論としてはわかる。でも辛い…が解決できるかもしれない
11. 人間時代に埋もれていた手法が脚光を浴びることに
12. Double-Loop：外側と内側のTDDループ Outer loop = ATDD → Acceptance Test Inner loop = TDD → Unit Test 1. Acceptance Testを書く(outer)→当然RED 2. Unit Testを書く(inner)→当然RED 3. Unit Testをパスするように部品を実装する 4. Unit TestがGREENになる 5. Acceptance TestがGREENになる→終了 6. Acceptance TestがRED→次のTDDへ
13. ATDDと受け入れ基準(AC) 定石 ❙ Outer-loopで回すAT = ACとする方法 ❙ 複数のACにまたがるテストは目的を見失いがちな のでやめたほうがいい1 ❙ ACとATを対応させる方法は主流だが、その内部で TDDをしたほうがいいのか、というのはまた別の話 ❙ ATDDは開発フロー全体のデザインに過ぎず、その 実際に私が取り入れている方法 私の運用 ❙ 1AC = 1ATのパターンと1User Story = 1ATのパ 1AC=1AT と 1US=1AT を試行錯誤中 ターンを試行錯誤中 ・定式どおりACごとにテストを書く場合と、より粗くユー ❙ザーストーリー単位でまとめる場合を使い分けている 定石通りACごとにATを書くとAT(つまりほぼE2E テスト)の数が膨大になっていくため、いくらAIに 書かせたりCIで回すテストだとしてもコストがかか る。折り合いをどこでつけるかは試行錯誤するポイ ントのひとつ 内部の開発はTDDでもSDDでもBDDスタイルを 使ってもなんでもいい 1. Ken Pugh, Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration, Addison-Wesley, 2011.
14. 注意点 実装するAIにテストの修正はさせない
15. これで極端に変なテストが書かれる ことはなくなったが…
16. 理由は実装前設計や文書の作り込みの甘さ なぜか？ ❙ ATを書くために必要なACをAIがうまく作れていなかった ❙ 原因は、ACを作るために必要な「要件定義」が十分にできていなかったこと ❙ ただ単にATDDの方法論を取り入れるだけではだめだった ❙ これはなにもATDDやAIに特化した話ではなく、我々がいつも開発している際に大事にしているものを、AI へ作らせるときにも大事にすればよいというそれだけの話
17. 大事にしたのはこの2つ PRD Design Doc ❙ この機能はなんのために必要なのか ❙ どのようなものをどう作るのか ❙ ユーザーのどんな要求へ答えるものなのか ❙ どのようなアーキテクチャで作るのか ❙ 何ができればこの開発は達成されるのか ❙ 影響範囲はどうなるのか AIとの数回でのやりとりでは、開発する背景などのコンテキストを十分に伝えられない ↓ 特に奇をてらったことはしておらず、今まで大切にしてきたものを愚直に組み込んだ
18. 現在の開発スタイル Discover Plan ❙ 開発はIssue駆動で ❙ Discoverで作成したPRDをInputに ❙ なぜこの機能が必要か、どういう機能要 ❙ User Story、AC、Design Docなどの 実装前設計を行う 件があるのかなどをAIと壁打ち が確定する 約2 463 ❙ Planまでで固まった設計をもとにAIが Double loopのATDDで実装をする ❙ ATの実装から、CIがGreenになるまで 全てAIにお任せ ❙ この時点でどのようなATが必要なのか ❙ OutputとしてPRDを作成する ATDD ❙ 当初はテストケースや実装をチェックし ていたが最近はATさえまともなら…に なっている 454 上流の工程ほど人間の関与を強く、下流はAIへお任せする流れになってきた
19. 餅は餅屋に このAIエコシステムを確立するまでに苦労した点 ❙ ATDDやTDDなどのテスト駆動まわりに関しては、特に苦労はなかった。自分が理想だと思っていたスタイ ルはAIにうまくフィットしたし、ある程度の課題は自力で解決できた ❙ 問題はPRDやUser Story、ACなど自分が専門としていない部分。これらの部分は一般論や事例として数多 く話はあるものの、AIのレコメンドに対して自分がレビュー・取捨選択をすることが難しかった(当たり前で はある) ❙ 上記は現職のチームメンバーにスペシャリストがいたため、生成AIのPluginを作るにあたって助言・助力を いただいた 専門知を持つ人を巻き込む重要性
20. まとめ
21. なぜ「テストが通った」は AI時代に信用できなくなったのか 1. AIは Reward Hackingしてしまう傾向 2. 人間の要件を正しくAIへ伝える難しさ 「今の」AIの特性を正しく掴み、それに合わせる必要性
22. よくある質問 1 Q. UIが決まっていない(実装されていない)状態で、テストが書けるのか？ A. 書ける ❙ 書けないのだとしたら、受け入れテストすべき機能に対する要件が足りてない ❙ 実際にATDDでiOSアプリを開発しています ❙ PRDやDesign Docにどこまで設計を盛り込むかはいい塩梅を見つける ❙ ATのテストコードは良質な設計書
23. よくある質問 2 Q. どのようなプロダクト・開発体制に向いているのか？ A. 基本的にどんな開発体制でも馴染むはず ❙ ただし今日の話は「理想的な手法だが、人間がやるにはつらい」というATDDをAIで やるもの。フロー自体は重い ❙ 単純なLPの作成や、1-2時間で作れる使い捨てのプロトタイプにはかなり冗長 ❙ 使い分けが大事
24. よくある質問 3 Q. うちの開発環境は特殊で複雑なので、難しそう A. 本当に？ ❙ 極論を言うと、適用できない現場はないはず ❙ ただし、向き不向きはある。頑張ってこの手法を取り入れる労力に対するメリットが少 ないところはある ❙ ATDDの手法自体にこだわる必要は全くない ❙ AIのクセ、実装とテストの分離、テスト設計の質という根本さえおさえてしまえば同 じような結果はだせるはず
25. ありがとうございました！！