AI駆動の⾃動テスト⽣成 2025-05-15 株式会社IVRy（アイブリー） 町永 隆 @macchiitaka 

⾃⼰紹介 ● @macchiitaka ● 2024年8⽉ IVRy に⼊社 ● 主にWebフロントエンドの機能開発 町永 隆（Takashi Machinaga） 2 ソフトウェアエンジニア 

IVRyとは？ 

電話⾃動応答サービスIVRy 電話AI SaaS IVRy(アイブリー)は、 ⽉額2,980円からカスタム電話をカンタンに作成できるサービス。 全ての電話業務を誰でもすぐにAIを使って効率化できます 

テストを AI に⽣成してほしい ● ⾃社のプロダクト開発の中でのトライ&エラーの話 ● 初期からある Web フロントエンドのリポジトリ ● ビジネス優先で開発してきた ● リファクタリングをしたい ● しかしテストがほぼない ● リファクタリングは、プログラムの動作を 変えずに、内部の構造を整理‧改善する作業 ● つまりテストとセット ● Copilot & Cursor & Devin 

静的解析 

● AI のため…ではなく元々は⾃分たちのコード品質向上のために強化していた ● AI Agent と静的解析の親和性が⾼い ● AI の制御にも活⽤できる ● AI Agent は暴⾛する ● 適切なフィードバックを与えないと明後⽇の⽅向にコードを変更する ● ガードレール（=ルール）が必要 ● 確率で動く AI に対して、従来のルールベースの静的解析ツールで制御 静的解析 

静的解析 1. TypeScript a. tsconfig/bases 2. ESLint a. bulk suppressions (v9.24.0) i. AI に disable コメントを真似させない b. スタイルに関するルールも有効にする i. 特に Auto Fixable なルールは積極的に有効に ii. 表記の統⼀（prd, prod, pro…） 

ルールの変更も AI にやってもらった 

プロンプトを頑張らない ● 最初は Cursor で⼿元で実⾏ ● 簡単なプロンプトで完了すればラッキー🎉🎉🎉 ● だいたいはうまくいかない ● テスト⽣成の「最初」と「最後」に介⼊する ● 「最初」に介⼊するパターン ○ Pull Request やコミット途中まで作成して、続きの作業をしてもらう ○ = リファレンス実装 ○ ⾃然⾔語でプロンプトを書くよりも簡単 & ⾼精度 

プロンプトを頑張らない ● 「最後」に介⼊するパターン ○ ⼈間相⼿のアンチパターンが AI なら許される ○ 「あとは俺がやる」 ○ AI と仕事をしているといままで PR は以下にコード以外に思考を回してい たか気付かされる ○ 癖になって⼈間相⼿にやらないように気をつけよう ● 次回以降は成功した Pull Request を参照させる ○ 精度が上がるまでは Cursor ○ 精度が上がってからは Devin で並列実⾏ 

プロンプトを頑張らないコツ 

無限にお⾦があったら ● なぜプロンプトを頑張りたくなるのか？ ○ 従量課⾦だから成功率を上げたくなる ○ 定額だったら使わないと損 ○ もし5000兆円あったら…？ ● ⽯油王の気持ちで AI を使う ● 同じプロンプトで複数回実⾏する ○ 当たるまで繰り返す（ガチャ） ● ちなみに IVRy 社内でもっとも Devin を使った ○ マージ率ももっとも⾼かった 

「あなたはアラブの⽯油王です」 

ユニットテスト 

テスト環境 ● Vitest ○ jsdom + Testing Library ○ Browser Mode ■ Chromium ■ Firefox ■ WebKit 

悩み①：モックサーバー ● vi.spyOn、vi.mock を使いたがる ○ 関数、モジュールレベルをモックすると、実装に依存したテストになる ○ msw を使ったモックサーバーを利⽤してほしい ○ しかし、このモックサーバーの⽣成精度が低い ● ⾃動⽣成された API クライアントをリポジトリに含めた ○ OpenAPI を利⽤したスキーマ駆動開発を採⽤している ○ ⾃動⽣成ファイルはリポジトリから除外していた ○ これと⽣成元の OpenAPI の定義ファイルを含めた ○ モックサーバーの⽣成精度が向上 🎉🎉 

悩み②：テストケース ● 実装に依存したテストを⽣成しがち ○ 実装に依存すると変更に弱いテストになる ○ ユーザーが操作するようにテストしたい ● it.todo でテストケースだけ作成する ○ テストケース作成と⾃動テスト実装を別ステップにする ○ テストファイルは縦に⻑くなりがち ■ テストケースだけなら出⼒が速い ○ 場合によっては最初の数ケースをエンジニアが定義する（最初に介⼊） 

悩み②：テストケース ● ゼロからテストケースを作成するより圧倒的に楽 ● AI が⾃ら定義したテストケースは⾼精度で書ける ● ただし、エンジニアが介⼊したテストケースのミス率は相対的に⾼い ● ⽣成後、テストカバレッジを渡してテストを網羅的に書かせる ● ただしカバレッジが⾼い=良いテストケースではない ● 品質は⼈間が担保する 

● リファクタリング前に捨てる前提のテストを作成する ● テストがグリーンであればいい ● テスト品質は問わない ○ 実装に依存したテストでもいい ● 既存の機能が変わっていないことを（多少なりとも）保証してもらう AI 特有のテスト 

現在地点 

ジュニアエンジニアとのペアプロ ● ⼈間にとって簡単なタスクは AI にとっても簡単 ● ⼈間にとって難しいタスクは AI にとっても難しい ● 簡単だけど⼿数な必要な作業を AI にやってほしい ● どれだけ構造化されたコードベースにできるか ● どれだけ簡単なタスクに分割できるか ● フロントエンドは⽐較的は細かい作業の連続 ● ジュニアエンジニアとのペアプロしてきたメソッドが役に⽴った ● 副作⽤として Good First Issue が枯渇する 

現時点の付き合い⽅ ● ゴールを定めにそこにどう導くか ● 宣⾔的 UI と同じ ● AI は意思決定をしてくれない ● 考えることまで任せない ● 最終的な完成物の責任は⾃分にある 

https://ivry-jp.notion.site/IVRy-127eea80adae801397a4e4d7ea74e291