AIにE2E-TDDを委ねる Webアプリ開発

・claudecodeで自律的にwebアプリの開発・テスト・デバッグができるか
（E2EレイヤーでのTDDを目標に）
・Webアプリケーションにおいて、もはや人間の手でコーディングとテストをしてる場合ではない。
　実装から結合テストまではAIの仕事になる…はず（なれば嬉しい）

対象：「TDDって何？」　という人向けの記事

Transcript

1. AIにE2E-TDDを委ねる Webアプリ開発 （N番煎じ）
2. この資料の目的 ・claudecodeで自律的にwebアプリの開発・テスト・デバッグができるか （理想はTDD開発） ・社内への説明資料。claude月200＄プランが審議なしでサクッと経費で落ちるようにな れば嬉しい。 ・人間の手でコーディングとテストをしてる場合ではない。 　実装から結合テストまではAIの仕事になる…はず（なれば嬉しい）
3. 自己紹介　 識別名：ナガノ キャリア：プログラマー５年目くらい スキル：typescriptのバッチ系。型とlinterと自動テストとCICDに奉仕する仕事。 フロントエンドはvue.js,react.jsを、バックエンドはjava+springbootを…触ったことがある。（ほ ぼ忘れた） atcoder水色
4. 開発者 動作確認 AIが実装 AIが修正 AIが修正 エラー、修正依頼 ソースコード提出 従来のＡＩ開発フロー 人間がチェックする工程が 減らない（むしろ増える？） （開発全体として、そこまで工数 削減は期待できない） 開発者 チャットで開発依頼 開発者 動作確認 ソースコード提出 エラー、修正依頼 開発者 動作確認 ソースコード提出
5. とりあえず導入してみた　一般的なAI自立駆動開発フロー（非TDD) AI(claudecode) 開発者 画面開発依頼 Web画面実装 ・Playwright(ブラウザmcp) ・puppeteer(ブラウザmcp) ・スクレイピングツールを自作 自動テスト作成 ・Playwright (E2Eテスト自動化 フレームワーク) 　ブラウザで 動作確認（AIが） 開発者 完了報告 AIに開発→デバッグのルーチンをやらせる 一応ちゃんと動く画面が作成される。 …が、精度としては物足りない。TDDが役立ちそう (作らない場合も) 修正
6. TDD（テスト駆動開発）とは 実装開発をする前にテストを作る手法 厳密には 実装前に自動テストを事前に作り、 そのテストがパスするよう実装し、 その後 リファクタリングを繰り返す手法
7. 要件定義& 基本設計 実装 動作確認&テスト 一般的な開発 自動テスト作成 （リグレッションテスト） 不具合が出たら修正 何回もテストを繰り返すのはしんどい … 作らない場合も結構ある
8. 要件定義& 基本設計 自動テスト作成 (開発のためのテスト） 実装 結論から：AI駆動開発とTDDはすごく相性がいい 動作確認&テスト 自動テスト実行 すべての自動テストが 通るまで実装修正 自動テスト作成 （リグレッションテスト） 実装完了後はリファクタして リグレッションテストとして 転用できる テスト実行のコマンドを叩くだけで テストができる TDD（テスト駆動開発）
9. AIが実装 AIが修正 レビューＯＫ、マージ AIが修正 テスト実行 開発者 動作確認 テストが通るまで繰り返し 実装修正をするため 精度の高いものが 提出される エラー検知 テスト実行 エラー検知 テスト実行 TDD用自動テスト AI・TDDフロー テストグリーン AIがTDD用テスト作成 開発者 開発依頼 ここまでAIが 自律的にタスク を行う
10. 複数の検証手法をAIに与え、 問題解決能力を向上させ 実装タスクを完遂させる 開発者 開発依頼 AI AI-TDD開発 ・TDD ・ブラウザから操作 ・アプリのログを解析 開発者 完了報告 実装→デバッグのループ 事前に実装の完了状態を定義できるTDDは (AIの）検証手段の中でもかなり効果的な開発道具
11. 開発者 AI 開発者 ソースから実装確認 テストから仕様確認 AI-TDD開発 要件定義 タスクの確認 開発の 依頼 できあがるまで 放置 完了報告 AI-TDD自動開発フロー 開発者 AIが変な手順で開発していないか監視 想定外の手順を踏んでいる場合は、 中断させ手順書を更新 タスク開始 フィードバック
12. 開発者 GeminiCLI 開発者 ソースから実装確認 テストから仕様確認 AI-TDD開 発 要件定義 親タスクの確認 開発の 依頼 AI-TDD自動開発フロー(geminiタスク管理型） claudecode AI同士の話し合い GeminiCLI 親タスク管理 claudecode 小タスク レビュー依頼 親タスクから 小タスクを切り出し、 claudeに依頼 完了報告 コンテキスト量がでかいgeminiに タスク管理とレビューを行わせる手法 横展開が多いタスク、 リファクタタスクと 相性がよかった。 寝る前に依頼して６時間自走して完了。 逆に、技術的難易度の高いタスクは geminiを挟まず claudeと1on1がよい
13. 今回作ったもの 国からの支払通知書を OCR画像解析して トランザクションを作成 支払予定日と金額を 支払予定口座でサマリーし データグリッドで表示 使う人：私の家族
14. 今回作ったもの 口座機能 請求書機能 支払通知書機能 （一覧・新規・編集・詳細） 支払スケジュール画面の ４機能１３画面 技術スタック react next.js postgres s3
15. ・ルール整備が大変 　AIはよく暴走して無茶苦茶な作業を行うので、 　厳密に開発手順を定める必要があり。 　先行者の記事を探すのもよいが、自分でAIを触って感触を掴んでいく　のが 一番早い。 　序盤は自動化のためのルール作りにリソースを投資するべき ・AI側の工数が多い 　厳密な手順書に沿ってあらゆる角度からデバッグを何度も行わせる手　法な ので、場合によってはAI側の時間が掛かり、人間とclaudecodeが 　密に1on1で実装していくほうが早い場合もある。 　↓ 　開発者はアイデア出しに専念してその間にAIに自走させる運用を想定 　速度を上げたい場合はAI駆動の並列化で技術的には解決可能...…？ AI駆動自動開発の欠点
16. 以下、開発者向けの自動テストの資料
17. TDD 生きた 仕様書 バグが 拾える 実装工数 保守工数 自動テストの利益　＝ 自動テストが生むメリット　ー　負債（保守コスト） 自動テスト価値戦略の話 自動テストのメリット 自動テストの負債
18. TDD 生きた 仕様書 バグが 拾える 実装工数 保守工数 自動テストの利益　＝ 自動テストが生むメリット　ー　負債（保守コスト） この価値収支の天秤は、関数ごと機能ごとで大きく揺れる 自動テストが多大な利益となるモジュール (※1)もあれば メリットを得られず書くだけ負債が増えるようなモジュール (※2)も存在する ※1：外部依存のない閉じたアルゴリズム ※2：API疎通処理（外部依存が多すぎる） 結合・統合テスト以降で巻き取るべき課題を 単体テストコードで巻き取ろうとするとしんどいという意味 自動テスト価値戦略の話
19. TDD 生きた 仕様書 バグが 拾える 実装工数 保守工数 自動テスト戦略 割と拮抗しがち… 手動テストの工数を1としたとき 自動テストの工数は (体感)3~10 (４回以上、手動テストをやり直すだろうという見積もりがあれば、 先に自動テスト化するべきという方法論も存在する） 自動テストの作成自体が割に合 わず作られないことも多い
20. TDD 生きた仕 様書 バグが 拾える 実装 工数 保守 工数 AI自動テスト戦略 AIの場合 自動テストのメリット　＞＞　負債
21. 自動テストとは 右の処理をひと目見て ・何をする処理なのか ・バグはないのか …わかりません 答えは、 xの平方根を ２分探索アルゴリズムで 求めるjsスクリプト（不具合付き）
22. 自動テストとは 自動テストのメリット ・実際の値の入力・結果を書くことで、 ソースコードを確認せずとも 具体的な生きた仕様が明確に ・エッジケースで不具合があるかどうか確認できる （0.5の場合は正しい値にならず不具合。 1未満のケースを検討していないから） ・TDD開発ができる （生きた仕様：その場で動くことを確認できる仕様）
23. TDDとは 実装を書く前に先に入出力パターンを定義して自動テストを実装する。 そのテストがすべてパスするまで実装とテストを繰り返す手法 （テストパターンから実装を起こす手法）
24. ＞実装を書く前に先に入出力パターンを定義して自動テストを実装する。 それができれば苦労はしない。 TDD実践の現実的な課題 ・その言語に精通した知識が必要 ・テストフレームワークの習得コスト ・要件から適切な入出力パターンを洗い出せない ・何をどこまでテストすべきか判断できない ・テスト書く時間がない（に見える） ・チーム全体でTDDの合意が取れない 人間がやるにはそこそこ難しい手法
25. TDD実践の現実的な課題： ・その言語に精通した知識が必要　　→AIが解決 ・テストフレームワークの習得コスト　→AIが解決 ・要件から適切な入出力パターンを洗い出せない 　→AIが解決 ・何をどこまでテストすべきか判断できない　 ・テスト書く時間がない（に見える）　→AIが解決 ・チーム全体でTDDの合意が取れない　
26. 余談：平方根はx**.5で求められるので 複雑なスクリプトを組む必要性は皆無 そもそも実装がこれぐらいシンプルであれば テストを書く必要はない （内部的にはjs側が二分探索、ニュートン法、ハッシュ法のいずれかを使ってるはずだが、 ブラックスボックス的要素を気にするべきではなく、我々がテストを書く義理も存在しない） AIに裏付けを依頼したらjs側ではなくCPU回路レベルで 平方根処理のためのニュートン法を行う回路があるようです。へぇー あと、Math.sqrtを使わずx**.5で記述した場合は e^(.5 * ln(x))が返るそうな
27. E2E自動テストの作り方 (1/2) ブラウザで対象画面を開き、テスト対象の入力フォーム、ボタン のCSSセレクタをすべて特定する
28. E2E自動テストの作り方 (2/2) 特定したCSSセレクタを使って、そのフォームに入力操作を行う テストを書き、画面上に現れた期待結果を記述する
29. E2E自動テストの TDD UIの実装前に、完成形のCSSセレクタを予測してテストを先行記 述し、その後画面を実装する
30. ＞UIの実装前に、完成形のCSSセレクタを予測してテストを先行記述し、その後画面 を実装する それができれば苦労はしない。 ・コンポーネント設計が固まってない段階でのテスト記述は困難 ・画面を見ずに画面のCSSセレクタを書くのは不可能（に感じる） ・E2Eテストは粒度が大きすぎて、TDDの 「小さなステップで進む」原則に合わない。 単純な関数に対するテストは入出力の型から期待結果の類推は そこまで難しくないが、E2Eは複雑なユーザーフローと 画面状態変化で、事前にテストケースを予測するのが困難。（人間には）無理。 のように感じる
31. まあその辺の事前知識がなくとも claudecodeがよしなに E2ETDDを書いてしまうのだが 一見、E2EのTDDはすごく難しいように感じる ところがチャレンジしてみたら実はそうでもなく ・data-testidタグを駆使すればcssに依存しないテストが書けるはず ・事前に作成するコンポーネントの設計、入出力を定義し、E2Eテストの前にコンポー ネントテストを書かせる （今回、playwrightの導入にはしゃぎすぎて、jestやコンポーネントテストフレーム ワークの導入は見送っている。というより存在を忘れている！が、本来は書くべき） というふうに、難易度は高いが人間が仕様変更に強いE2Eテストを書くのは不可能 ではないように思う。
32. E2E自動テストで AIにTDDを回させるコツ ・要件定義と完了状態をAIと議論し、事前に要件を詰めたうえで着手してもらう 　→質のよいタスク定義があれば質のよいテストが作れるため。 ・t-wadaさんのTDDを意識させる。 このあたりの条件を満たせれば、あとはclaudecodeが大抵うまくやってくれる（すごい）
33. E2E自動テストで壊れにくいテストを作るコツ 仕様変更、リファクタに強いテストを書かせる →CSSに依存せずdata-testidタグを使う。 →メッセージ等は定数化してリファクタリングに強くする 指示がない場合、claudecodeはリファクタリング耐性のない壊れやすいテス トを書きがちなので、しっかり手順化しよう。 リファクタリング耐性がない E2Eテスト：デザインを変えただけでテストが動かなくなる
34. 以下、雑談
35. 一切コーディングしていない。 そもそもフロントエンド実装は一切見ていない。その代わり AIが生成し たplaywrightテストコードに関しては以下の観点から注意深く観察した。 良いテストを構成する４本の柱理論 (単体テストの考え方-使い方:第４章96ページ） ・バグが拾えるか ・リファクタリング耐性はあるか ・フィードバックは迅速か（E2Eテストのフィードバックが迅速なわけがないのだが、一応 ） ・保守はしやすいか フロントエンドがjsだろうがpythonだろうがphpだろうが、E2Eテストコードの書き方はそこまで変化し ないと思うので、E2E自動テストの学習は今後腐ることはないのではと考えた。 リファクタリングされたE2Eテストコードはブラウザの操作手順書を見る感覚と同じなので、保守に関 してもそこまで難易度は高くないように思える。 （というより、何やってるかわからない E2Eテストを残す価値はない） どれくらい人間がコーディングした？
36. AIの書くE2Eテストの品質について AIはTDDのためのE2Eテストを作ることはでき、ちゃんとTDDを回せるが、 その後のテストのリファクタリングがあまりうまくないように思う。 具体的に言うと、明確に指示しなければdata-testidタグを使わない。 タイトルやメッセージの定数ファイルを作成せず、直接文字列をハードコーディングし てテストする傾向にある。 ただ、この辺の綺麗なテストを書く知識に関しては人間側も知っていなければ指摘 することもできないので、 我々、自称AI駆動開発者はソフトウェアテスト、自動テストの方法論について今後は より深い知識と理解が必要になる。 （逆にフロントエンドの学習はせず実装側はすべてAIに押し付ける）
37. フロントエンドは技術がころころ更新されてとても人間の手には追いつけるものではな い。実装とデバッグはAIにやらせ、開発者は自動テストの方法論の研究に注力する。技 術は変わっても、自動テストの基礎は不変。 開発者の役割： TDD・自動テストの方法論・方針の策定に集中 テスト戦略をAIに伝えて横展開させる AIの役割： フロントエンドの開発を自由に実行 TDDに基づき、人間側の期待結果誘導と確立されたテスト方針に従ってコードを生成 目標： フロントエンドの技術的更新（フレームワーク変更、ライブラリアップデート等）があっても、画 面上の挙動が変化しない品質を保証し、 AIの長期に自律した開発を可能にする。
38. ・テストのフィードバックは迅速か 遅い。E2Eテストが遅い。遅い。遅い。 今回の場合は４機能１３画面にテストケースが１１０個ほどあるのだが、 １件当たり平均６秒かかる。 つまり、このプロダクト全体の１回のリグレッションには１０分も掛かる。 （これはテストが正常に終わった場合の話。テストが壊れてタイムアウトとリトライが頻発した場合は 目も当てられない） 作成するプロダクトが２０機能６０画面だったとして、 その場合対応するテストケースが 1000件ほどと仮定する。 全体リグレッションテストは1000件*６秒（１時間４０分）も掛かる。 仕様変更ごとに1時間40分のリグレッションテストは非効率。 日次自動実行またはリリース前のみ実行する戦略に検討すべし
39. 今回、開発速度でボトルネックになったのはAI出力速度でもなく人間の思考速度でもなくE2E 自動テスト実行の一点に尽きる。 このボトルネック解消にあたってはテストのテストデータ独立性を徹底的に担保して並列化実 行を可能にした上でハイスペックマシンで並列でテストする方針を検討した。 そして、現状この目論見はうまく行っていない。 ・今回の検証ではテストケースの独立性を担保するのに失敗した。 （テストを実行する前に DBをリセットしシードデータに流し込む。テストが途中でコケてもリセットしてシードデータ を流し込む。このテスト運用だと並列性を担保できない） ・E2Eテストの並列化自体が不安定。私のハイスペックマシンでもplaywrightがchromeを５ つ立ち上げて同時に操作すると１個あたりの速度が落ち、タイムアウトが出るようになったた め、１つのマシンでの並列実行は限度がある。
40. 自動テスト、サーバー並列化のアプローチ GitHubの特定のブランチにpushした際に、テストファイル数に応じてインスタンスを動的に生成する仕組 みを構築する。テストファイルが100個存在する場合、100個のサーバーを瞬時に起動し、並列でテストを 実行する。（という記事をどこかで見たことがある） 全てのテストが正常に完了した場合のみ、developブランチへのマージを許可する。この並列実行アプ ローチにより、従来の逐次実行と比較してテスト実行時間を大幅に短縮できる 。 AI+TDD自立駆動開発で最もコストが掛かるのはAIでも人件費でもなく自動テスト実行 のための並列サーバー費用ではないだろうか。（即時並列リグレッションテストが本当に 必要かどうかはともかく）
41. FIN この記事は人間が6割、AIが4割書いてます