「それ、設定ファイルに書いておいたよ」〜AIエージェントCursor/Clineでのテスト生成改善の記録〜 (2025年1月現在)

はじめに

こんにちは、UbieでQAエンジニアをしている ackey です。
昨年の12月よりアプリチーム全体の開発・運用生産性改善を担うチームに所属しています。

本記事では、AIエージェントを使ったテストコード生成におけるちょっとした工夫事例をご紹介します。
2025年初頭時点での試行錯誤の記録として、また、生成AI時代を生き抜こうともがくQAエンジニアの取り組みとして参考になれば幸いです。

AIエージェントとのやりとりで感じた課題

UbieではCursorやClineなど開発AIエージェントのトライアルを一部のプロジェクトで開始しており、もはやAIエージェントなしの開発スタイルには戻れない状態になりつつあります。
https://zenn.dev/ubie_dev/articles/624c9034cc9b43

アプリチームでもAIエージェントの利用は活発で、新機能開発からテストコードの生成まで幅広く活用されています。QAエンジニアの私も主にテスト作成文脈^[1]でAIエージェントを活用し始め、実装効率は確かに向上しました。しかし同時に、プロジェクト固有の文脈を理解させることの難しさも感じていました。

AIエージェントの出力における課題例

「〇〇のテストを書いて。hogehogeのテストを参考にして。」とお願いすると、AIが最初に出してくる提案には以下のような課題がありました。

1. プロジェクト共通設定の理解不足

// 不要なモック定義の例（jest.config.mjsで既に設定済み）
jest.mock('@/assets/icons/example.svg', () => 'SvgMock');

2. テストケース命名のばらつき・期待値が不明瞭

// 期待結果が抽象的で、不明瞭な命名
it('スキップボタンクリック時に正しく処理が実行される', async () => { ... });

3. 要素の検索方法のばらつき

// 要素検索では `getByRole`を優先的に使ってほしいが、TestIdを設定してしまう
screen.getByTestId('login-button');  

上記のようなちょっとしたズレが起きるたびに、「ここが不要なので消して」「期待値を具体的かつ明瞭化して」「条件一致したときのテストだけでなく、条件不一致時のテストも足して」など追加の指示をする必要があり、「一発で一定のクオリティの提案がほしい...」と悩んでいました。

試した工夫：設定ファイルによるコンテキストの共有

チーム内で相談したところ、「各AIエージェントの設定ファイルに記載できるよ」と教えてもらい、試してみることにしました。

slackで相談する様子

（参考）公式ドキュメント

• https://docs.cursor.com/context/rules-for-ai
• https://github.com/cline/cline/tree/main/docs/prompting#clinerules-file-

設定ファイルの作成プロセス

1. AIを使ったたたき台の作成 by QAエンジニア

   • 既存のテストコードと社内の知見資料を入力情報として、パターンの抽出をAIに依頼
   • AIと対話をしながら、カバーしてほしいテスト観点を整理

2. チーム内でAIのたたき台をレビュー

   • アプリ開発エンジニア：React Nativeのお作法、ベストプラクティスの観点
   • QAエンジニア：テストの網羅性、保守性の観点

ポイントとしては、最初から完璧を目指さず、既存の資産を活かして最低限守ってほしいルールを初版として検討したところです。着手からマージまでの期間は約1日ほどでした。

設定ファイルの主なポイント

以下のような項目を記載しました (要約かつ一部抜粋)：

# Testing Rules

## 1. テストファイルの基本構造
- ファイル配置・命名規則（`{ComponentName}.test.tsx`）
- 用途別基本インポート（通常/GraphQL/カスタムフック）
- テストファイルテンプレート（describeブロック、setupPage関数）

## 2. モックパターン
- 自動設定されるモック（SVG）
- よく使うモックパターン（コンポーネント、カスタムフック、ストレージ、GraphQL）
- 状態管理モック（jotai）

## 3. 要素の検索優先順位
1. Role-based → screen.getByRole('button', { name: 'ボタン名' })
2. テキストベース → screen.getByText('表示テキスト')
3. TestID（最終手段）→ screen.getByTestId('test-id')

## 4. テストケースパターン
- 表示・非表示確認（動的な要素、条件による表示変化）
- ユーザーインタラクション
- 非同期処理（ローディング、APIレスポンス）
- ナビゲーション、モーダル
- 状態管理テスト (ストレージ操作)
- エラーハンドリング

## 5. テストケース命名規則
'[条件]のとき、[具体的な期待結果]'
- 例 'プッシュ通知タップ時、通知データを既読に更新し通知詳細画面に遷移する'

## 6. テスト観点ごとに抑えてほしいポイント(必須・推奨別)
- ユーザーインタラクション
- データフェッチ
- 状態による表示確認
- フォーム操作
- データ有無による確認
- コンポーネント間連携
- アクセシビリティ
- 条件分岐による確認パターン (例:条件を満たす場合の挙動/条件を満たさない場合の挙動)

効果と気づき

これらの設定ファイルを追加したことで、AIエージェントへの指示が「hogehogeファイルのテストを書いて」といったシンプルなものでも、プロジェクトのテストポリシーを理解した実装を提案してくれるようになり、レビューや手直しの手間が最小限で済むようになりました。

導入後の主な改善点は以下の2つです。

1. AIエージェントが生成するテストコードの初期品質が向上

   • プロジェクトのルール（モックの設定など）を理解した実装
   • テストの目的が明確な命名への改善
   • テスト観点のポイントを抑えたテスト内容へ

2. テスト作成プロセスの効率化

   • AIへの追加指示が1回程度で済むように（以前は3～5回の追加指示が必要）
   • 形式面での追加指示が減り、人間は「テストケースの妥当性確認」のレビューに注力できるように

アプリ開発エンジニアからも「新しい機能を追加する時も、AIエージェントに頼めば高品質なテストを作ってくれるので、開発の速度と質が上がった」と喜びの声をもらいました。

笑いが止まらないアプリ開発エンジニア

とはいえ、現時点（2025年初頭）だからこそ得られた限定的な成果とも感じています。
特にClineは比較的具体的かつ丁寧めに指示をしないとプロジェクト文脈にそった提案が一発で得られない課題があったので、今回の設定ファイルにより初期品質が改善できました。今後のAIの精度改善により、設定ファイルでここまで細かく指定せずとも気の効いた提案をしてくれる世界はすぐに来そうな予感もします。

おわりに

小さな工夫ではありますが、AIエージェントを活用したテスト生成の効率化により、開発速度とプロダクト品質の向上につながった事例を紹介しました。今後もAIツールは急速な進化を続けていくと思いますが、その時々で「今できる工夫」を素早く見つけ積み重ねていくことを意識していきたいと思います。

皆さんのプロジェクトでも、似たような工夫や異なるアプローチがあれば、ぜひ教えていただけると嬉しいです。

現在、Ubieではさらなる改善をすすめるため、QAエンジニアの採用を強化しています。
LLMを活用したQA活動のアップデートに興味のある方、ぜひ一緒に働きませんか?

下記募集かXのDM でご連絡いただけると嬉しいです。
https://herp.careers/v1/ubiehr/bfPkWMEgZJ7X
カジュアル面談も大歓迎です!!
https://pitta.me/matches/GvKDrGMPMBCN