AI駆動の自動テスト生成

AI ×フロントエンド開発のリアル（2025-05-15）

Transcript

1. AI駆動の⾃動テスト⽣成 2025-05-15 株式会社IVRy（アイブリー） 町永 隆 @macchiitaka
2. ⾃⼰紹介 • @macchiitaka • 2024年8⽉ IVRy に⼊社 • 主にWebフロントエンドの機能開発 町永 隆（Takashi Machinaga） 2 ソフトウェアエンジニア
3. IVRyとは？
4. 電話⾃動応答サービスIVRy 電話AI SaaS IVRy(アイブリー)は、 ⽉額2,980円からカスタム電話をカンタンに作成できるサービス。 全ての電話業務を誰でもすぐにAIを使って効率化できます
5. テストを AI に⽣成してほしい • ⾃社のプロダクト開発の中でのトライ&エラーの話 • 初期からある Web フロントエンドのリポジトリ • ビジネス優先で開発してきた • リファクタリングをしたい • しかしテストがほぼない • リファクタリングは、プログラムの動作を 変えずに、内部の構造を整理‧改善する作業 • つまりテストとセット • Copilot & Cursor & Devin
6. 静的解析
7. • AI のため…ではなく元々は⾃分たちのコード品質向上のために強化していた • AI Agent と静的解析の親和性が⾼い • AI の制御にも活⽤できる • AI Agent は暴⾛する • 適切なフィードバックを与えないと明後⽇の⽅向にコードを変更する • ガードレール（=ルール）が必要 • 確率で動く AI に対して、従来のルールベースの静的解析ツールで制御 静的解析
8. 静的解析 1. TypeScript a. tsconfig/bases 2. ESLint a. bulk suppressions (v9.24.0) i. AI に disable コメントを真似させない b. スタイルに関するルールも有効にする i. 特に Auto Fixable なルールは積極的に有効に ii. 表記の統⼀（prd, prod, pro…）
9. ルールの変更も AI にやってもらった
10. プロンプトを頑張らない • 最初は Cursor で⼿元で実⾏ • 簡単なプロンプトで完了すればラッキー🎉🎉🎉 • だいたいはうまくいかない • テスト⽣成の「最初」と「最後」に介⼊する • 「最初」に介⼊するパターン ◦ Pull Request やコミット途中まで作成して、続きの作業をしてもらう ◦ = リファレンス実装 ◦ ⾃然⾔語でプロンプトを書くよりも簡単 & ⾼精度
11. プロンプトを頑張らない • 「最後」に介⼊するパターン ◦ ⼈間相⼿のアンチパターンが AI なら許される ◦ 「あとは俺がやる」 ◦ AI と仕事をしているといままで PR は以下にコード以外に思考を回してい たか気付かされる ◦ 癖になって⼈間相⼿にやらないように気をつけよう • 次回以降は成功した Pull Request を参照させる ◦ 精度が上がるまでは Cursor ◦ 精度が上がってからは Devin で並列実⾏
12. プロンプトを頑張らないコツ
13. 無限にお⾦があったら • なぜプロンプトを頑張りたくなるのか？ ◦ 従量課⾦だから成功率を上げたくなる ◦ 定額だったら使わないと損 ◦ もし5000兆円あったら…？ • ⽯油王の気持ちで AI を使う • 同じプロンプトで複数回実⾏する ◦ 当たるまで繰り返す（ガチャ） • ちなみに IVRy 社内でもっとも Devin を使った ◦ マージ率ももっとも⾼かった
14. 「あなたはアラブの⽯油王です」
15. ユニットテスト
16. テスト環境 • Vitest ◦ jsdom + Testing Library ◦ Browser Mode ▪ Chromium ▪ Firefox ▪ WebKit
17. 悩み①：モックサーバー • vi.spyOn、vi.mock を使いたがる ◦ 関数、モジュールレベルをモックすると、実装に依存したテストになる ◦ msw を使ったモックサーバーを利⽤してほしい ◦ しかし、このモックサーバーの⽣成精度が低い • ⾃動⽣成された API クライアントをリポジトリに含めた ◦ OpenAPI を利⽤したスキーマ駆動開発を採⽤している ◦ ⾃動⽣成ファイルはリポジトリから除外していた ◦ これと⽣成元の OpenAPI の定義ファイルを含めた ◦ モックサーバーの⽣成精度が向上 🎉🎉
18. 悩み②：テストケース • 実装に依存したテストを⽣成しがち ◦ 実装に依存すると変更に弱いテストになる ◦ ユーザーが操作するようにテストしたい • it.todo でテストケースだけ作成する ◦ テストケース作成と⾃動テスト実装を別ステップにする ◦ テストファイルは縦に⻑くなりがち ▪ テストケースだけなら出⼒が速い ◦ 場合によっては最初の数ケースをエンジニアが定義する（最初に介⼊）
19. 悩み②：テストケース • ゼロからテストケースを作成するより圧倒的に楽 • AI が⾃ら定義したテストケースは⾼精度で書ける • ただし、エンジニアが介⼊したテストケースのミス率は相対的に⾼い • ⽣成後、テストカバレッジを渡してテストを網羅的に書かせる • ただしカバレッジが⾼い=良いテストケースではない • 品質は⼈間が担保する
20. • リファクタリング前に捨てる前提のテストを作成する • テストがグリーンであればいい • テスト品質は問わない ◦ 実装に依存したテストでもいい • 既存の機能が変わっていないことを（多少なりとも）保証してもらう AI 特有のテスト
21. 現在地点
22. ジュニアエンジニアとのペアプロ • ⼈間にとって簡単なタスクは AI にとっても簡単 • ⼈間にとって難しいタスクは AI にとっても難しい • 簡単だけど⼿数な必要な作業を AI にやってほしい • どれだけ構造化されたコードベースにできるか • どれだけ簡単なタスクに分割できるか • フロントエンドは⽐較的は細かい作業の連続 • ジュニアエンジニアとのペアプロしてきたメソッドが役に⽴った • 副作⽤として Good First Issue が枯渇する
23. 現時点の付き合い⽅ • ゴールを定めにそこにどう導くか • 宣⾔的 UI と同じ • AI は意思決定をしてくれない • 考えることまで任せない • 最終的な完成物の責任は⾃分にある
24. https://ivry-jp.notion.site/IVRy-127eea80adae801397a4e4d7ea74e291