導入のきっかけ

こんにちは、津島です。
私は普段の業務では、プロジェクトの進行管理から設計、実装依頼、テスト仕様書の作成、テスト結果の確認、リリース作業、そして成果物の納品まで、実装以外の幅広い業務を担当しています。

その中で、私がいつも苦手としているのが「内部テスト仕様書の作成」です。 テストケース自体が思いつかないというよりも、類似するケースを項目ごとに少しずつ変更していく過程で、コピー＆ペースト等によるケアレスミスが発生しやすいことが課題でした。 また、並行して進む設計フェーズや実装方針の相談など、他のメンバーにも関わる業務の優先度をどうしても高く設定してしまうため、テストケースの作成は後回しになりがちで、常に時間に追われながら対応していました。

そこで今回、「AIを活用して、完璧とまではいかなくとも、テスト項目をある程度自動で作成できないか」と考え、試験的な導入に挑戦してみました。

AI導入に向けた準備と環境構築

まず、AI導入に向けて実施した環境構築についてご紹介します。

現在のプロジェクトでは、エンドユーザー様向けの「ユーザー画面」と、パートナー様向けの「管理画面」を実装しており、画面設計書はGoogleスライドで管理しています。
そのため、AIがGoogleスライドの設計書を直接参照できるように環境を整え、同時にAIエージェントツール「Antigravity」の導入も行いました。

環境構築の手順

  1. Antigravity CLIのインストール
  2. ターミナルで agy を起動し、指定のアカウントでログイン
  3. Antigravityアプリをインストールし、ログイン
  4. 設定ファイルを修正し、Google Slides（Google Workspace）のMCPサーバー定義を追加

大まかな流れは上記の通りです。権限反映のタイムラグがあることを知らずに少し手こずった部分もありましたが、無事に環境を構築することができました。

作成したファイルのディレクトリ構造

一部、省略していますが、作成したディレクトリ構造をここに記載しておきます。

gemini/
├── README.md
├── output/ 
│   ├── yyyymmddhhmmss/
│   └── yyyymmddhhmmss/ # AIが作成したテスト仕様書を出力する先のディレクトリ。
├── scripts/
│   ├── generate_prompt.py
│   └── 以下、省略。その他、テスト仕様書を自動生成するためのスクリプトファイルを格納している。
├── skills/
│   ├── glossary.md
│   ├── prompt_template_and_guide.md
│   ├── reference_links.md
│   └── test_samples/
│       ├── test_case_prompt_user_create.md
│       ├── test_case_prompt_user_update.md
│       ├── test_case_prompt_user_view.md
│       ├── test_case_prompt_admin_create.md
│       ├── test_case_prompt_admin_update.md
│       ├── test_case_prompt_admin_view.md
│       ├── test_case_prompt_api.md
│       └── test_case_prompt_batch.md
└── wiki/
    ├── setup_knowledge_base.md
    └── 以下、省略。# その他、対応をしている中でのナレッジを記載したファイルを格納している。

実践した5つの工夫

AIから精度の高いテスト仕様書を引き出すため、主に以下の5つの対応を行いました。

既存テスト仕様書のサンプルデータの格納

test_samplesというディレクトリを作成し、既存のテスト仕様書を「ユーザー画面」「管理画面」「API」「バッチ」の4種類に分類してサンプルとして格納しました。

例えば、ユーザー画面のサンプルとして、
「正常系（画面設計書通りに項目が配置されているか / 各入力項目は想定通りの動作になっているかなど）と
異常系（想定外のパラメーターの場合、エラー画面を表示できるかなど）のテストケース」などを読み込ませています。

このサンプルデータを用意したことで、AIが出力するテスト項目の「粒度」が大きく安定しました。

プロジェクト固有の用語集の作成

glossary.md という用語集ファイルを作成しました。

詳細な説明は省略しますが、
本会員と仮会員といった会員制度の違いや、データの各ステータスの定義などを記載したファイルです。
この用語集は、主にユーザー画面と管理画面の画面設計書をAIに読み込ませて原案を作成させました。
最初は廃止された機能が含まれていたり、AIの推測による不正確な解説が混じっていたりしましたが、対話を通じて修正を重ねることで精度が向上しました。

まだ修正の余地はあるものの、プロジェクト固有の知識をAIに理解させる上で、効果的なアプローチだったと感じています。

テスト観点シートの作成

テストケースを作成する上で、AIに考慮してほしい「テスト観点」をまとめたファイルを作成しました。こちらも「ユーザー画面」「管理画面」「API」「バッチ」の4種類に分けて記載しています。

例えば、
ユーザー画面や管理画面の入力フォームについてはnullチェックや境界値チェックを、
バッチ処理については正常系に加えて「連携元のファイルが規定外のフォーマットになっていないか」「ファイルの中身がフォーマット通りになっているか」といった異常系の観点を記載しました。

観点を明文化しておくことは考慮漏れを防ぐ役割も果たしており、新しい実装を行うたびにこのファイルを更新し、テストの網羅性を高めていく運用を想定しています。

AIへの依頼用プロンプトテンプレートの作成

実際にAIへテスト仕様書の作成を依頼する際、出力の質を安定させるための「プロンプト（依頼文）のテンプレート」を作成しました。
追加・修正の実装内容や、参照すべき関連資料のリンクなどを穴埋め形式で記載できるフォーマットにしています。

関連資料のリンク集の作成

AIがコンテキストを把握しやすくするため、参照すべき仕様書や、ソースコードファイルなどをまとめたリンク集を用意しました。

導入の成果

これまで手作業で1つ1つ作成していた時に比べ、基本的で単純なテスト項目はAIで自動生成できるようになったため、作業的にも精神的にも非常に楽になりました。

体感としては、これまでの作業量を「10」とすると「6.5」程度まで削減できた感覚です。
現状はAIに出力させるための微調整にまだ時間がかかっていますが、プロンプトや各種ファイルの精度が上がってくれば、最終的には従来の半分の工数での対応も可能ではないかと見込んでいます。

特に、テスト仕様書の作成メンバーとのやり取り（レビューや修正依頼など）のコストを格段に減らすことができた点が、個人的には最大のメリットだと感じています。

今後の課題

一方で、運用していく中で以下のような課題も見えてきました。

課題1：複数画面にまたがるテストケースの精度

テスト実施メンバーから「テスト項目の期待結果が誤っているのではないか」という指摘を受けました。
確認したところ、1つの画面内で完結するテスト項目に関してはブレが少ないものの、画面遷移を伴う「流れのあるテスト項目」については、まだ品質が低いことが分かりました。
画面遷移のインプットがうまく行えていない可能性があるため、AIがより理解しやすいインプット資料の構成を検討したいと考えています。

課題2：些細な修正に対するテスト項目の過剰生成

AIが生成するテスト項目が、修正内容に対して多すぎるケースが発生しています。
例えば「ボタン名を修正しただけ」であっても、ボタンの連打制御や不正リクエストを想定した過剰なテスト項目が生成されてしまいます。
とはいえ、項目を絞りすぎて網羅性が下がってしまう方がリスクが高いため、AIへの指示の塩梅（チューニング）が難しいと感じています。
この点については、今後どのように対応していくべきか引き続き検討中です。

最後に

まだまだ改善の余地がある発展途上の状態ではありますが、AIを活用したテスト仕様書の自動生成にチャレンジしてみた経験をご紹介しました。今回の知見が、似たような課題を抱えている方の参考になれば幸いです。

機密情報の関係上、本ブログでは実際のプロンプトの中身や具体的なプロジェクトの詳細など、お見せしきれなかった部分も多くあります。 もし「もっと詳しい話を聞いてみたい」「AIによるテスト仕様書の自動生成を検討しているが、どう進めればいいか迷っている」といった方がいらっしゃいましたら、ぜひお気軽にお問い合わせください。課題に合わせたアプローチをご提案させていただきます。

今後も試行錯誤を重ね、より実用的な仕組みへとアップデートしていきたいと思います!