はじめに

TIS テクノロジー＆イノベーション本部 開発基盤センターの長岡です。生成AI活用促進チームのエンジニアとして参画しています。
最近は生成AIを活用したシステム開発の効率化に取り組んでおり、その成果を本記事で共有させていただきます。

本記事の目的

システム開発における生産性向上は、多くの企業が抱える重要な課題です。
特にプログラミング工程・結合テスト工程は工数が大きく、その効率化による効果は非常に大きいものとなります。
IPA ソフトウェア開発 分析データ集 2022の工程別工数によると、システム開発の工数の約5割が制作工程と結合テスト工程で占められています。当社で管理している社内プロジェクトの統計情報でも同じ傾向が見られました。
そこで私たちは、生成AIを活用した生産性向上の最初のターゲットとして制作工程と結合テスト工程に狙いを絞り、複数の取り組みを開始しました。
本記事では、その取り組みの内の１つである「生成AIを用いたテスト仕様書の自動生成」の内容と成果について紹介します。

 

想定読者

本記事は、以下のような方々に向けて書かれています。
  • 生成AIの実践的な活用方法を探している方
  • システム開発プロジェクトのマネージャー、アーキテクト
  • テスト工程の効率化に興味がある方
特に、生成AIの実践的な活用方法を探している方に参考にしていただければ幸いです。

 

背景と課題

スコープ

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

機能テストにおける課題

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

テスト仕様書の品質を一定に保つため、当社ではFintanで公開しているテスト観点カタログを活用しています。このカタログには、以下のような特徴があります。
  1. 網羅的なテスト観点
    •    入力値チェック
    •    業務ロジック検証
    •    エラー処理確認
      など、必要な観点を体系的に整理
  2. 品質の標準化
    • 開発者のスキルによらず同じ基準でテスト設計が可能
    • テスト品質の均一化に貢献
しかし、人手でテスト仕様書を作成する場合、以下のような課題がありました。
  • テスト観点が非常に多く、すべての観点を漏れなく適用するのに時間がかかる
  • 複数人で作成する場合、観点の解釈にばらつきが生じる可能性がある
  • 大規模な機能の場合、確認すべき組み合わせが膨大になる

 

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

これらの課題に対して、生成AIを活用した解決を試みることにしました。
具体的には、以下の2つのドキュメントを入力として、テスト仕様書を自動生成する取り組みを開始しました。
1. Fintanで公開されているテスト観点カタログ
2. プロジェクトの設計書

前提

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

使用するLLM

本施策では、AWS BedrockのClaude Sonnet、Haikuを採用しています。AWSは当社で調達・利用しやすい環境であるため採用しています。そして、AWS Bedrockが提供するLLMの中で、システム開発に関するタスクに最も適しているのがClaude Sonnet、Haikuであるためこれらを採用しました。

生成プロセスの概要

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

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

 

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

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

テスト仕様書の例

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

生成AIは設計書を読み込み、テスト観点カタログに基づいて以下のようなテスト仕様を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割の工数を削減できた結果となりました。またレビューの対応時間が減っていることからもわかる通り、初版のテスト仕様の品質も上がっています。

費用

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

顧客検索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の活用範囲を広げ、システム開発の生産性向上に取り組んでいきます。