「Excel設計書の壁」を越え、生成AIでテスト仕様書の作成工数を4割削減した事例：＠IT Techブログ PickUp（TISインテックグループ編）

IPAのデータによると、システム開発の工数の約5割が制作工程と結合テスト工程で占められています。この領域を工数削減できたら、開発がぐっと楽になると思いませんか？　本稿では、制作工程の機能テストに対して生成AIを活用する取り組みの一つを紹介します。システム開発プロジェクトのマネージャー・アーキテクトや、生成AIの実践的な活用方法を探している方の参考にしていただければと思っています。

[Fintan]

注目のテックブログから「現場の知恵」をあなたに――

各社のエンジニアが発信する「テックブログ」。その熱量を＠IT編集部がピックアップ。 生成AI前提時代に向けて環境が激変する中、“隣のエンジニア”は何を感じ、何を考え、どうアクションしているのか？――試行錯誤のプロセス、成功の鍵、変化に立ち向かうマインドなど現場のリアル、ナレッジを凝縮してお届けします。

本稿はTISインテックグループが運営する、開発現場から生まれた技術ノウハウを公開するサイト「Fintan」上で2025年3月17日に掲載した記事を転載するものです。そのため、用字用語の統一ルールなどが、＠ITのものと異なります。ご了承ください。

連載目次

生産性向上にどう切り込むか

　システム開発における生産性向上は、多くの企業が抱える重要な課題です。

　特にプログラミング工程・結合テスト工程は工数が大きく、その効率化による効果は非常に大きいものとなります。

　IPA ソフトウェア開発 分析データ集 2022の工程別工数によると、システム開発の工数の約5割が制作工程と結合テスト工程で占められています。当社で管理している社内プロジェクトの統計情報でも同じ傾向が見られました。

　そこで私たちは、生成AIを活用した生産性向上の最初のターゲットとして制作工程と結合テスト工程に狙いを絞り、複数の取り組みを開始しました。

　本稿では、その取り組みの内の１つである「生成AIを用いたテスト仕様書の自動生成」の内容と成果について紹介します。

背景と課題

今回対象にするテスト、しないテスト

　当社ではシステム開発におけるテストを、Fintanのテスト観点カタログで定義された分類に従って実施しています。本取り組みでは、その中でも「機能テスト（API・バッチ単位）」と「機能テスト（ユースケース単位）」に焦点を当てています。画面に関するテストについては、現段階では対象外としています。

機能テストにおける課題

　当社ではテストコードを作成する前に、設計書からテスト仕様書を作成しています。テスト仕様書の主な目的はテスト観点の定義、テスト内容の明示、合否判定基準の提示、そしてテストケースの網羅性の担保です。開発者はテストコードを実装した後、テスト仕様書に記載されたテストケースがいずれかのテストコードに当てはまるかを確認することで、テストケースの網羅性を担保しています。

　テスト仕様書の品質を一定に保つため、当社ではFintanで公開しているテスト観点カタログを活用しています。このカタログには、以下のような特徴があります。

1. 網羅的なテスト観点
   • 入力値チェック
   • 業務ロジック検証
   • エラー処理確認など、必要な観点を体系的に整理
2. 品質の標準化
   • 開発者のスキルによらず同じ基準でテスト設計が可能
   • テスト品質の均一化に貢献

　しかし、人手でテスト仕様書を作成する場合、以下のような課題がありました。

• テスト観点が非常に多く、すべての観点を漏れなく適用するのに時間がかかる
• 複数人で作成する場合、観点の解釈にばらつきが生じる可能性がある
• 大規模な機能の場合、確認すべき組み合わせが膨大になる

生成AIによる解決アプローチ

　前述の通り、人手によるテスト仕様書作成は、観点の多さや解釈のばらつき、組み合わせの膨大さなどにより、漏れなく網羅し効率的に作成することが難しいという課題があります。これらの課題に対して、生成AIを活用した解決を試みることにしました。

　具体的には、以下の2つのドキュメントを入力として、テスト仕様書を自動生成する取り組みを開始しました。

1. Fintanで公開されているテスト観点カタログ
2. プロジェクトの設計書

生成AI活用の前提条件

　生成AIは柔軟にタスクをこなす一方で、品質を保証することはできません。同じ入力でも実行の都度結果は変わります。この取り組みでも自動生成とは言いつつ完全な人手の代替を目指してはいません。目指しているのは工数の削減です。そのため本取り組みでは生成AIが作成したテスト仕様を開発者がレビューすることを前提としています。

使用するLLM

　本取り組みでは、当社の標準的な開発環境で利用可能としている、Amazon BedrockのClaude Sonnet、Haikuを採用しています。Amazon Bedrockが提供するLLMの中で、システム開発に関するタスクに最も適しているClaude Sonnet、Haikuを採用しました。

テスト仕様書生成プロセスの概要

　テスト仕様書の自動生成は、以下の5つのステップを実施します。

1. 設計書をMarkdownのテキストに変換
2. 設計書の解析と収集（対象の機能および、関連する設計書を解析し、テストケース生成に必要な設計情報を収集します）
3. 個々のテスト観点についてテストすべきか判断
4. テストすべきと判定されたテスト観点に対して、テストケースを網羅する要素の抽出
5. 抽出された要素ごとにテストケースを生成

生成されたテスト仕様書の評価

　spring-sample-projectに公開されている設計書をインプットとして実際に生成されたテスト仕様書とその評価について記載します。

テスト仕様書の例

　以下は、期間内プロジェクト一覧出力バッチに対して生成されたテスト仕様の一部です。

　生成AIは設計書を読み込み、テスト観点カタログに基づいて以下のようなテスト仕様をCSV形式で生成します。

　CSVに含まれる項目は以下の通りです。

項目	説明	具体例
テストケースID	テストケースを一意に識別するIDです	1-1-2-1-1
大項目	テスト観点カタログの「大項目」に相当します。	バリデーション
中項目	テスト観点カタログの「中項目」に相当します。	単項目バリデーション
小項目	テスト観点カタログの「小項目」に相当します。	文字列長バリデーション
詳細	テスト観点カタログの「詳細」に相当します。	-
観点の内容	テスト観点カタログの「観点の内容」に相当します。	文字列項目に最大長が入力された場合、エラーとならないこと。
判断	対象の機能に対して、このテスト観点のテストを実施すべきかAIが判断した結果です。必要と判断した場合は「○」、不要と判断した場合は「-」を出力します。	○
判断理由	対象の機能に対して、このテスト観点のテストを実施すべきかAIが判断した理由を出力します。	ドメイン定義でプロジェクト名が全角文字最大128文字と定義されており、文字列長バリデーションのテストが必要。
対応設計書	このテストに関連する設計書をAIが選出し、関連する設計書のファイル名を出力します。	システム機能設計書(バッチ)_BA10601／期間内プロジェクト一覧出力バッチ
対応箇所	対応設計書内のテストに関連する部分をAIが選出し、出力します。	3.2 プロジェクトデータ取得・CSV出力処理
テスト対象の要素	AIが選出したこのテストケースのテスト対象です。右記の例だと、このケースは文字列長バリデーションを観点とし、かつプロジェクト名項目に焦点を当てたテストケースとなります。	プロジェクト名（全角文字128文字） 補足：このケースは文字列長バリデーションを観点とし、かつプロジェクト名項目に焦点を当てたテストケースとなります。
テスト内容	AIが作成したテストケースのテスト内容です。	1.プロジェクトテーブルに以下のデータを事前登録する： 　・プロジェクト名：全角文字128文字（記号「！＃＄％＆’（）＝〜｜」を含む） 　・プロジェクト開始日付：業務日付以前の日付 　・プロジェクト終了日付：業務日付以降の日付 　・その他の項目：有効な値 2.期間内プロジェクト一覧出力バッチ（BA10601）を実行する 3.出力されたCSVファイル（N21AA002）の内容を確認する
想定結果	AIが作成したテストケースの想定結果です。	1.バッチ処理が正常終了すること（終了コード：0） 2.CSVファイルが以下の仕様で正しく出力されていること： 　・文字コード：UTF8 　・区切り文字：カンマ 　・レコード長：3523バイト 3.プロジェクト名が128文字すべて正しく出力されており、文字化けや途中での切れ目がないこと 4.プロジェクト名に含まれる記号文字が正しく出力されていること 5.ログに処理開始・終了時刻、処理件数が出力されていること

テスト観点の要否判断精度の評価

　「生成プロセスの概要」の「ステップ3:個々のテスト観点についてテストすべきか判断」、こちらのAIの判断結果の評価を行いました。spring-sample-project の3つの機能を対象に精度を評価しました。評価は、熟練したエンジニアの判断を正として、AIの判断が正しかったかどうかで行っています。

機能	テスト観点総数	正答数	誤答（False-positive）数	誤答（False-negative）数	正答率
顧客検索API	278	247	29	2	89%
プロジェクト一括登録バッチ	301	266	35	0	88%
プロジェクト一覧出力バッチ	301	275	23	3	91%

テスト仕様の品質評価

　「生成プロセスの概要」の「ステップ5:抽出された要素ごとにテストケースを生成」、こちらのAIが生成したテストケースに対する評価を行いました。同じ機能を対象に、熟練したエンジニアが高品質なテストケース内容となっているかを評価しました。

機能	評価対象のテスト観点総数	高品質テストケース*が生成されたテスト観点数	高品質率
顧客検索API	38	24	63%
プロジェクト一括登録バッチ	59	30	51%
プロジェクト一覧出力バッチ	39	26	67%
*… 設計書に記載のない記述や当てはまらない記述を含まず、ケース網羅も十分なもの

工数削減効果

　従来の作業と、今回作成したAIを用いた場合の工数削減効果を計測しました。

• 従来の作業
  1. 若手の開発者が設計書とテスト観点カタログを参考にテスト仕様を作成する
  2. 中堅の開発者がレビューする
  3. レビューの対応をする
• AIを用いた作業
  1. AIが作成したテスト仕様に対して若手の開発者が設計書を参考に、不要なものを削除し、また設計書に合ってない部分を修正する
  2. 中堅の開発者がレビューする
  3. レビューの対応をする

　学習効果による作業効率の向上が比較結果に影響しないよう、「従来の作業」と「AIを用いた作業」では、同規模の異なる機能を対象にテスト仕様を作成しました。

　各作業の工数は以下の通りでした。

	テスト仕様作成工数/AIが生成したテスト仕様修正工数	レビュー工数	レビュー指摘対応工数	全体の工数
従来の作業	9.50h	1.25h	4.00h	14.75h
AIを用いた作業	7.00h	1.00h	0.50h	8.50h

　全体で約4割の工数を削減できた結果となりました。またレビューの対応時間が減っていることからもわかる通り、初版のテスト仕様の品質も上がっています。

生成AI実行費用

　１つの機能のテスト仕様生成にかかった費用は以下の通りです。

顧客検索API	$11.45
プロジェクト一括登録バッチ ワークテーブル登録機能	$20.45

　費用はテストケース数に比例します。テストケース数が増える主な要素は入力項目数、出力項目数、処理の分岐数です。プロジェクト一括登録バッチは顧客検索APIよりも入出力項目が多いためテストケース数が嵩み、結果費用も高くなりました。

　また、これらはPrompt Cachingを使用しない場合の費用です。テスト生成時のインプットの大部分は同じ設計書のためPrompt Cachingを使用することで費用を削減できると見込んでいます。

取り組み中に明らかになった課題と解決策

　取り組みの開始時点および実際の開発過程で、以下のような課題が明らかになりました。課題の内容とその対策について記載します。

入力データの形式に関する課題

• 内容：当社では長年にわたりExcelとWordで設計書を作成してきた文化があり、これらの文書形式はAIへの直接入力には適していませんでした。Markdownなどのテキストベースのドキュメント形式への移行を検討しつつも、移行期間中や既存のプロジェクトに対応するためにはExcelやWordの設計書に対応することは必須です。
• 解決策：AWS Converse APIを活用してExcelやWordの文書をMarkdown形式のテキストに変換する処理を実装しました。

テスト観点の処理

• 内容：Fintanのテスト観点カタログには100個以上のテスト観点が含まれており、これらを一括で処理しようとした際に、中間のテストケースが無視される、特定の観点に対するテストケースが理由なく生成されない、という問題が発生しました。
• 解決策：1つのプロンプトで1つのテスト観点を処理するように変更し、テスト観点の数だけプロンプトを実行する方式を採用しました。

レスポンスの制限

• 内容：１つのプロンプトで複数のテスト観点のテストケースを生成しようとすると、出力コンテキスト制限を超えてしまい後半のテキストが「…」と省略される問題が発生しました。
• 解決策：上記同様、1つのプロンプトで処理する量を制限することで対応しました。

設計情報の取り扱いに関する課題

• 内容：システム開発では多様な設計書（テーブル定義書、ドメイン定義書、メッセージ定義書、インタフェース定義書など）が存在し、これらを一度にAIに入力すると、入力コンテキスト制限を超過する、関連性の低い設計情報からの誤ったテストケースが生成される、といった問題が発生しました。
• 解決策：テストケース生成前に設計書を解析し、テスト対象の機能に必要な設計情報のみを抽出する処理を追加しました。

テストケースの網羅性

• 内容：単純なケースでも網羅性が低い問題が発生しました。例えば必須項目全てに対して「設定されない場合はエラーとなる」というテストケースが必要だった場合、必須項目のうち前半に記述された項目に対するケースしか生成されない、といったことが散見されました。
• 解決策：テストケース生成前にテストケースを網羅する要素（必須項目リストやDB検索条件の組み合わせなど）を抽出する処理を追加しました。

不要なテストケースの生成

• 内容：テスト観点に対して必要以上のテストケースが生成され、その判断理由も不明確でした。
• 解決策：テストの必要性を判断するプロンプトとテストケースを生成するプロンプトを分離することで改善が見られました。また、判断理由も生成させることで人間によるレビュー容易性を向上させました。

出力フォーマットの統一性

• 内容：テスト内容および想定結果の記載粒度にばらつきがあり、具体的な値を含む詳細な記述と、条件のみを示す抽象的な記述が同一のテスト仕様書内に混在していました。例えば、「顧客IDに『a』、顧客名に『TIS』を設定して顧客検索APIを呼び出す」のように具体的な入力値まで記載されたテストケースがある一方で、「顧客IDに無効な値を設定し、その他の項目には有効な値を設定して顧客検索APIを呼び出す」のように、具体的な入力値を記載せず、テストの主眼ではない項目を抽象化したテストケースも出力されていました。
• 解決策：人間によるレビューの容易性と保守性を考えて後者に統一することにしました。解決策として、Fewshotプロンプトで例を提示し、必要な場合のみ具体的な値を出力するようプロンプトを調整しました。

パフォーマンスの課題

• 内容：これらの品質改善の取り組みにより、1つのテスト仕様の生成に3〜4時間を要する状況となり、工数削減という当初の目的が達成できない状況に陥りました。
• 解決策：以下の対策を実施しました。

• Langchainのキャッシュ機能を使用し、同じプロンプトの再利用を可能にしました。
• テスト観点の大項目〜小項目レベルで適用可否を判断し、不要な観点の処理をまとめてスキップする最適化を行いました。

今後の課題

　本取り組みは一定の成果を上げることができましたが、さらなる改善の余地も見えてきました。

　ここでは、今後取り組むべき主要な課題について説明します。

1.長大な機能の設計書への対応

　大規模な機能の設計書に対するテスト仕様については上記に記載した品質に到達していません。今後は大規模な機能についても同等の品質のテスト仕様が生成できるよう取り組んでいきます。

2.テスト仕様の評価とリグレッションテスト

　チューニングを効果的に行うためにも、生成されるテスト仕様の品質を継続的に担保する必要があります。変更を加えたことにより、テスト仕様の質が落ちていないか自動的に検知する仕組みが必要です。現在は人手で評価を行っていますが、今後は自動化に取り組んでいきます。

3.レビュー容易性の向上

　AIが生成した成果物に対して人間によるレビューは必要不可欠です。そのためどれだけツールの精度を高めても、人間によるレビューが生産性向上のボトルネックとなります。特に時間がかかるのが、ケースが設計を網羅しているか、条件分岐を網羅するケースが生成されているかの確認です。この確認がより効率的になるよう取り組んでいきます。

まとめ

　生成AIを活用したテスト仕様書の自動生成により、以下の課題を解決しました。

• テスト観点が非常に多く、すべての観点を漏れなく適用するのに時間がかかる
  AIに生成させることにより、約4割の工数削減効果が観測できた。
• 複数人で作成する場合、観点の解釈にばらつきが生じる可能性がある
  AIに生成させることにより、知識や経験による解釈のばらつきが抑えられた。
• 大規模な機能の場合、確認すべき組み合わせが膨大になる
  AIに生成させることにより、組み合わせの洗い出しが簡便になった。また個人のスキルに依存しなくなった。

　一方で、いくつかの課題も明らかになっています。

• 長大な機能の設計書への対応
• テスト仕様の評価とリグレッションテスト
• レビュー容易性の向上

　これらの課題に取り組みながら、今後も生成AIの活用範囲を広げ、システム開発の生産性向上に取り組んでいきます。

元ブログもチェック！

元記事はコチラ。ぜひチェックしてみてください！