３行まとめ
- 仕様書を渡すとリスク分析からテストケース生成までやってくれるよ
- ステップ単位で人が軌道修正して精度をあげて（維持して）いるよ
- 指摘内容や成果物からナレッジを抽出してPRを出すので賢くなる仕組みだよ
はじめに
こんにちは、クオリティアーキテクトグループでQAエンジニアをしている星野です。
この記事はLIFULL Advent Calendar 2025の記事になります。
QA活動でLLM、活用してますか？
今回はテスト分析からテスト実装（テストケースの作成）までを効率化するためにつくったAIエージェントの話をします。
ただ単に「テストケースを作って」「テスト観点を出して」とお願いするだけではなく、 人間が軌道修正しながら精度を上げていく仕組みと、 その修正内容から学習して次に活かす仕組みも入れてみたので、その話をします。
残念ながらプロンプト群は公開できませんが、アプローチや設計思想は参考になるかもしれません。
つくったもの
仕様書を渡すと、以下のステップでテストプロセスを進めます。
- 仕様書の理解 - 曖昧な表現の確認や不足・矛盾を指摘、プロダクトリスクを洗い出す
- テスト観点の抽出 - ドメイン知識やテスト知識を活用してテスト観点を生成
- ユーザーレビュー - 人間が確認して修正指示（最大5回まで）
- テストケース生成 - JSON形式でテストケースを出力
- 知識の抽出・保存 - ここまでの指摘・修正内容からナレッジを抽出してPRを出して蓄積
ポイントは3つあります。
ポイント① 仕様書の理解から始める
いきなりテスト観点を抽出させたりテストケースをつくらせません。まず仕様書を理解させるところから始めます。
まず大前提として、完璧な仕様書は存在しません。少なからず間違いや曖昧な表現、後々変更される内容を含んでいます。 また、仕様書には書かれていない暗黙の前提、ドメイン特有の重要な項目や不安、課題だとかリスクがありますよね。
それらをどう認識されているかわからないままスタートをすると、そのズレは徐々に影響が大きくなって成果物がトンチンカンな内容になりがちです。
なので、それらを先に確認し、あわよくば後続のプロセスに活かします。
たとえば、
- システム的にケアされていてテストの必要がないもの
- 仕様以前の要求、サービスそのものの目的や理念
- 非機能要件として求めるレベル感
- 仕様書に書かれていない制約や前提
こういったものを最初に確認しておくと、後のテスト観点抽出がブレにくくなります。
なので、このステップでは以下のようなことをやっています。
- 機能概要・対象範囲の要約
- 不足・矛盾・曖昧な点の確認
- プロダクトリスクの特定
ユーザーにはLLMの解釈が正しいか確認を促して指摘を（必要なら仕様書を修正して）もらってから次に進みます。
ポイント② 人間が軌道修正する
LLMも人間同様に誤りを生みますし、コンテクストが大きいと過去の指示や内容と矛盾したりもします。
なので、ステップごとにレビューポイントを設けています。 さきほどの仕様理解の最後に入れていた確認と同様のものを他ステップでも行います。 ユーザーからの承認を得なければ次のステップに進まないようにLLMに指示をしています。
また、修正は最大5回までにしています。 修正回数が多い時には中断を促すメッセージを出すんですが、これは仕様書側に矛盾や不足が多かったり、必要な情報があまりにも足らなくて精度が出ないおそれがあるからです。
精度が悪いと最終成果物も誤りだらけでレビューが大変に（そもそも使えないものに）なりますし、それ以前にインプットの品質に懸念があるということは、コードベースなど他の成果物も少し不安がありますよね。
そのため、ドキュメント自体の見直しを促すようにしています。
ポイント③ 使うほど賢くなるように
仕様書に書かれない暗黙的な情報が多いって話を前述しました。狙いはそこです。 毎回初手で同じような補足を入れるのは面倒ですし、人によって差がでます。
また、テストにとってドメイン知識はかなり重要で、しかしそれはアウトプットされない限りは各人の記憶に隠れてしまいます。
だからこのシステムでは、レビューを挟んだとき、そこで得た指摘をベースにナレッジ化、PRを作成し本体へフィードバックしてくれる仕組みにしました。
具体的には、
- 人間が指摘・修正した内容を記録
- 「なぜ修正が必要だったか」「どう修正したか」を抽出
- ナレッジとして蓄積（「ドメイン知識」と「テスト技術」に分類）
- 次回のテスト分析で活用
という流れです。
ナレッジを含むこのエージェントのプロンプト群はリポジトリで管理されているので、CLIで動くLLMはPRも出してくれます。 脳内のドメイン知識を書き出す負担をユーザーから取り除き、かつ他のユーザーもそのナレッジを利用できるようになります。
こういう情報はわざわざ書き出すのは大変ですし変更を追うのも難しかったものですが、 これなら使う人が多ければ多いほど、使えば使うほど蓄積されてメリットがスケールしていくんです。
仮に指摘がないなら、それは人間に納得のいく精度の出力を出すために今のナレッジで足りているということなので、余計なものを蓄えずに済むようになっています。
「ドメイン知識」と「テスト技術」に分けた理由
「ドメイン知識」と「テスト技術」にわけたのは、汎用的に使える考え・知識なのか、特定のシステムや体制によるものなのかを区分するためです。
利用するのは様々なチームで、その中にもいくつものテストベースがあります。すべてをひとつにまとめてしまうと「あっちではこれが必要だけどこっちでは重要視していない」みたいな衝突が起きてしまいます。 似ている目的や名前のページが存在していても、ドメイン知識として仕様書にあるリポジトリ名やサービス名からテストベースを判断でき、必要な情報だけを参照できるようにしています。
実際どうなの？
現時点ではいい感じに使えています。
私自身はもう基本的にこのエージェントを使用しており、成果物に少し手直しを加える程度で運用できています。 使いながら気になったらプロンプト自体をその場で直してしまえるので、改善のサイクルも早くて快適ですね。
テストケースのフォーマット
社内で使ってもらう・自分が使うにあたって、テストケースは標準化されたフォーマットから離れると定着しにくい・使いにくいため、JSONで出力するようにしました。
今のフォーマットは以前の記事に書いたようにスプレッドシートベースなので、GASでJSONからインポートできる機能をつけました。 ついでに最終成果物からナレッジを得て学習できるようにエクスポート機能も実装し、具体的なテストデータとかpath、手順などの仕様書に書かれない前提が輸入しやすくする狙いがあります。
また、JSONフォーマットと各カラムの目的と記載内容を言語化したドキュメントも配布することで、私がつくったプロンプトではなく独自に改善を行っている方にも利用しやすくしました。 囲い込んでユーザーを増やすよりも自由度を大事にしています。
課題：プロンプトやナレッジの管理・改善
今は自動的に飛んでくるPRをレビューして、問題（偏った判断基準や誤った省略など）がなさそうかを見ています。
ユーザーが少ないうちはこれでいけるんですけど、全ものづくりメンバーが使い出したらこれをどうするかは悩んでいます。 たぶんCLIにAIレビュアーを入れて重複削除や一貫性の担保をすることになると思います。
また、ナレッジが肥大化してきたときに正しく扱えるのか、制御できるのかが少し懸念です。 システムが昔よりもメモリ不足を気にしなくなったように、LLM側が進化してコンテクストウィンドウのオーバーフローを気にしなくてもよくなればいいんですけどね。
おわりに
LLMを使ったテストプロセスの改善について、アプローチや設計思想を紹介しました。 「人間が軌道修正する仕組み」と「使うほど賢くなる仕組み」を入れることで、実用的なツールになったかなと思っています。
LLM活用のアプローチとして、何か参考になれば幸いです。
以上です。 お読みいただきありがとうございました。
最後に、LIFULLでは一緒に働いていただける仲間を募集しています。
カジュアル面談も実施しておりますので、もし興味があればそちらもご覧いただければと思います。
