はじめに
プロジェクトでの開発において、テスト仕様書の作成は品質保証の要となる重要な工程です。しかし、多くの開発現場では以下のような課題に直面しています。
- 膨大な工数: 一つのプロジェクトで数百〜数千のテストケース作成に数週間を要する
- 品質のばらつき: 担当者のスキルや経験により、テスト網羅性に差が生じる
- メンテナンスの負担: 仕様変更のたびに大量のテスト仕様書を手動で更新する必要がある
こうした課題について生成AIチームでは生成AIを用いて設計書等の情報からテスト仕様書を作成しました。今回はその手法についてご紹介したいと思います。
従来のテスト仕様書作成の課題
工数の問題
従来のテスト仕様書作成では1機能のテスト仕様書作成で、以下のような工数が発生していました。
- 要件分析: 2-3日
- テストケース設計: 5-10日
- テスト仕様書記述: 3-5日
- レビュー・修正: 2-3日
合計: 12～21日（約3-4週間）
品質のばらつき
担当者のスキルやそのプロジェクトの継続年数による仕様理解などの差によって品質がばらつきがある。
特に境界値テスト、異常系テスト、パフォーマンステスト等は若手は見落としやすい傾向にある。
メンテナンスの困難さ
- 仕様変更の度にテストケースに影響
- 変更漏れによるバグの見逃しリスク
- 古いテスト仕様書の放置による技術的負債の蓄積
生成AIを活用したテスト仕様書作成ソリューション
技術概要
生成AIを活用したテスト仕様書作成では、以下の技術を組み合わせました。
- 大規模言語モデル（LLM）: Amazon Bedrock（Claude Sonnet 4）
- プロンプトエンジニアリング: 専門的なテスト設計知識を組み込んだ指示文
- RAG（Retrieval-Augmented Generation）: 要件定義や画面設計書等を参照
- AIエージェントフレームワーク: Strands Agents（マルチエージェント）
プロセス図
前処理
設計書の抱える２つの課題
- Excel形式の設計書
設計書をExcelで管理していました。人で確認するなどであれば問題ないのですが、これをAIで読み取った際に以下の問題が生じました。
- 画像や図形が多数含まれていて読み取れない（図形内の文字など）
- セル形式のため詳細な流れが読み取れない
これらの課題を解決するため以下のアプローチを行いました。
解決アプローチ
3段階の変換プロセス📊 Excel形式（元データ）
↓ 手動またはツールで変換
📄 PDF形式（中間フォーマット）
↓ Claude Sonnet 4 のPDFサポート機能による AI OCR
📝 マークダウン形式（AI可読形式）
↓
🤖 マルチエージェントシステムで処理
ポイント
- PDFサポート機能による AI OCR: PDFの各ページを画像化し画像内のテキスト、表、図を理解
- 構造化: 見出し、表、リストなどの論理構造を復元
- 最適化: AI が理解しやすい形式に変換
具体例：画面定義書の変換
【Excel】
複雑なセル結合、画像埋め込み、複数シート
↓
【PDF】
見た目は保持されるが構造情報なし
↓
【マークダウン】
## 画面定義：ログイン画面
### 入力項目
| 項目名 | 入力形式 | 必須 | 備考 |
|--------|----------|------|------|
| ユーザーID | 半角英数字 | ○ | 8-20文字 |
| パスワード | 半角英数字 | ○ | 8文字以上 |
→ AIが理解しやすい構造化データ
これにより作成したマークダウン形式での設計書はS3にアップロードし、Amazon Bedrock KnowledgeBaseのデータソースとして利用します。
エージェントシステム
前処理でストア層の作成は完了したので、実際にAIエージェントを用いてテスト仕様書を作成していきます。
まずは以下のエージェントをStrands Agentsを用いて作成しました。Strands Agentsに関しては以下公式ドキュメントを参照してください。
https://strandsagents.com/latest/
エージェント構成
調査・分析
各研究者エージェントにはAmazon Bedrock KnowledgeBaseにretrieveで情報を取得してくるツールを与えています。
| エージェント | 役割 | 担当する設計書 | 抽出する情報 |
| 要件定義研究者 | 要件の理解 | 要件定義 | 機能概要、業務フロー、制約事項、非機能要件 |
| 業務フロー研究者 | プロセスの把握 | 業務フロー図 | 業務の流れ、判断分岐、アクター間の関係 |
| 画面遷移図研究者 | 遷移の理解 | 画面遷移図 | 画面間の関連性、遷移条件、ユーザー導線 |
| 画面定義書研究者 | 詳細仕様の把握 | 画面定義書 | 画面項目、入力検証ルール、ボタン動作、エラーメッセージ |
構造化
| エージェント | 役割 | 主な責任 |
| テスト仕様書作成者 |
仕様書の作成 |
|
レビュー
| エージェント | 役割 | 主な責任 |
| レビュワー | 品質チェック |
|
作成した複数のエージェントたちをStrands AgentsのSwarmで連携させます。
Swarmとは複数のエージェントが連携して複雑な問題を解決するための仕組みです。
エージェント協調の例
画面定義書研究者:
「ログイン画面には、ユーザーID・パスワードの入力項目があり、
それぞれ必須チェック、文字数制限の検証が必要です」
↓ ハンドオフ
テスト仕様書作成者:
「了解しました。以下のテストケースを作成します：
- 必須チェック（未入力時のエラー）
- 文字数制限（上限・下限のバリデーション）
- 正常系（適切な入力での認証成功）」
実際に作成したテスト仕様書サンプル
実際に作成したものはお見せすることはできませんが、以下の画像のようなテスト仕様書を作成することができました。
※縦横幅やフィルターなどは手で修正しています。
さいごに
成果と今後の展望
既存の Excel 設計書を活用してテスト仕様書をAI自動生成するという、現実的な課題に対するソリューションです。
Excel → PDF → マークダウンという変換プロセスを経ることで、「レガシーな設計書フォーマット」の問題を少なからず解決できたと思います。
実現できたこと
- ✅ 手作業で数日かかっていた作業を数分に短縮
- ✅ テスト仕様書の品質の統一化
- ✅ マルチエージェントによる網羅的なテスト設計
AI ネイティブな開発プロセスへ
しかし、今回のアプローチは過渡期の解決策であると考えています。
AI駆動開発が進んでいく中、開発プロセスも見直していく必要があるかもしれません。
要件定義からリリースまで、AI が伴走する開発プロセス
【要件定義フェーズ】
顧客ヒアリング → AIが要件定義書を生成（マークダウン）
↓
【設計フェーズ】
要件定義書 → AIが設計書を生成（マークダウン）
↓
【テストフェーズ】
設計書 → AIがテスト仕様書を生成（マークダウン）
↓
【報告フェーズ】
各種ドキュメント → AIが報告資料を生成（PowerPoint等）
おわりに
AI 技術の進化により、ソフトウェア開発のあり方は大きく変わろうとしています。
Excel や PDF といった「人間が見るため」のフォーマットから、マークダウンという「AIが見るため」のフォーマットにすることがこれからの時代重要になってくるかもしれません。
今回作成したテスト仕様書を基にブラウザ操作系（Chrome DevTools MCPなど）のMCPを使ってテスト自動化も検証していきたいと思います。