こんにちは。支出管理領域のQA Tech Leadと、AI駆動QAチームを兼務しているrenです。freee QA Advent Calendar 2025の22日目です。
今回は、生成AIにテストプロセスを行わせるための社内基盤「AI駆動QA基盤」について紹介します。
freee QAのAI活用のこれまで
freeeのQA組織*1のAI活用探索は、
- 「AI駆動QAチーム」という専門部隊が、集中的にAI技術のQA領域への活用を探索する
- 各プロダクトのQAチームも、日々のQA業務の中でより良いAI活用のプラクティスを探索する
- 「AI4QA委員会」というファンクションカットの寄合で、専任部隊↔︎現場の知見共有, 課題検討を行い、組織全体でAI活用の練度を高めていく
という形で歩みを進めてきました。このような取り組みを通じて、QAの業務プロセスを根本から「AIネイティブ」に変革することを目指しています。 QA組織内の機会設計についてはfreee技術の日でもお話しさせていただいたので、こちらもご参照ください。
AI活用の前提となる標準テストプロセス
freeeではメンバーの立ち上がりや流動性を確保するために、異なるプロダクト間でもテストプロセスの進め方が同じになるように「標準テストプロセス」を導入しています。*2
標準テストプロセスによってテスト活動の大まかな流れが共通化されており、またテスト活動関連のアウトプットもほとんど統一されています。導入時の意図通り、異なるプロダクト間でも同じ用語、フォーマットを使ってテスト活動について会話することができるようになっています。
この標準テストプロセスがAI駆動QAの礎となっており、後述するAIのためのワークフロー定義やタスク定義の一貫性を支えるものとなっています。
AI駆動QAとは
AI駆動QAとは、AIエージェントにQAプロセスを行わせることを指しています。
従来のプロセスとの大きな違いは、従来spreadsheetやテスト管理ツール上で直接作っていた成果物を全てプレーンテキスト(markdownテキスト)に置き換えていく点であり、これはAIの力を最大限活かすための変化です。
主体となるツールとしてRoo CodeやClaude CodeといったAIコーディングエージェントをサポートしており、これらのツールに再現性を持ってテスト活動を遂行してもらうための基盤をAI駆動QA基盤と称して構築しています。
AI駆動QA基盤の仕組み
AI駆動QA基盤はAIコーディングエージェントにテスト活動を行わせるためのコンテキスト基盤であり、ナレッジの置き場所や扱い方、AIがタスク遂行する上でのフロー定義などを備えています。
AIコーディングエージェントのワークスペースとして使うためにリポジトリで管理しており、以下のようなディレクトリ構成になってます。
root/
│
├── .claude, .roo（AI・自動化設定）
│ └─ セキュリティポリシー、ワークフロー定義、スラッシュコマンド
│
├── knowledge（AIを動かすためのナレッジ）
│ ├─ QAプロセス全体のガイドライン
│ ├─ ドキュメントのテンプレート
│ ├─ 各テスト活動の詳細ルール
│ └─ プロダクトごとの業務特化プロンプト
│
├── tools（ユーティリティ）
│ └─ 作業効率化のためのスクリプト類
│
└── products（プロダクトごと・案件ワークスペース）
└─ [プロダクト名]
├─ 全体のマスター情報（仕様、既知のバグ）
└─ [案件・プロジェクト]
└─ 標準テストプロセスに沿った成果物の格納
.claude / .roo ディレクトリ
.claudeや.rooディレクトリには、機微情報を読み込まないようにするためのセキュリティポリシーや、各ツールで利用可能なmode定義やスラッシュコマンド定義を置いています。
現状は複数のAIコーディングエージェントを組織で利用しており、「ツールのためのコマンド定義」と「AIに行わせたい業務ドメインの知識」の繋がりをなるべく薄くすることを意識しています。これは、新しいツールが出てきてもすぐ使えるようにしたいというモチベーションがあるためです。
そのため、mode定義やスラッシュコマンド定義は、別途定義しているタスク定義文書のラッパーとして、あるいはそれらタスク群のワークフローを表現するものとして定義しています。
人の介在はテスト工程ごとに発生するようになっており、人が特定のプロジェクトのテスト計画やテスト分析の開始を命令したら、それ以降は自律的にタスクを遂行するようになっています。
knowledge ディレクトリ
knowledgeディレクトリには、このリポジトリで行わせたいテスト業務の知識、テスト業務を行わせるためのAIへの命令セット（タスク定義文書）を置いています。
「テスト分析」のようなコンテキストが膨大かつ複雑なタスクを、単一のプロンプトでAIに実行させようとしても、情報の欠落やハルシネーションが発生しやすく、質の高い成果物は期待できません。
そこで重要になるのが、「複雑な問題を解決する際の思考プロセスを分解し、巨大なタスクを「インプット→処理→アウトプット」の連鎖からなる、具体的なサブタスクのワークフローへと再定義する」アプローチです。
例えばテスト分析は「テスト対象の大枠を理解する行為」のあとに「フィーチャーを特定する行為」があり、「フィーチャーを構成する要素に分解する行為」や「入力や内部状態、出力の取り得る値を洗い出す行為」…と続いていくタスクの連鎖として捉え直すことができます。(ここでのタスク分割とそのフローは、あくまで一例です)
このようなアプローチを通して各タスクでAIが必要とするコンテキストを意図的に絞り込むことで、AIの認知的な負荷を低減させられるため、AIの能力を毀損することなく業務に活かすことが可能になります。
また、サブタスクに分割することで「AI成果物の精度向上」を細かい単位で実施しやすいようになるため、with AIの業務改善も行いやすくなっているのもポイントです。
タスク定義はyamlファイルとして記載しており、全てのタスク定義で以下の「input, function, output構成」を守っています。
--- description: この文書がどのようなタスクについての文書かを端的に書く version: 1.0 globs: ["**/*.md", "**/*.png"] tags: ["qa_process", "test_plan"] --- ## 入力 (Input) input: prd: # PRD（プロダクト要求仕様書） description: "PRD（プロダクト要求仕様書）" content: "何が書いてあるかの説明" dd: # DesignDocs（設計書） description: "DesignDocs（設計書）" content: "何が書いてあるかの説明" ## 機能 (Function) function: # タスクで行うことの定義 # タスク遂行で押さえて欲しい業務上重要なポイント（テスト活動に関するナレッジ） # inputファイルの扱い方の定義 ## 出力 (Output) output: # (Output内容の概要定義) template: # どのタスクのテンプレートかについての説明 template_path: "knowledge/shared/outputs/04_test_plan/sample_template.md" # アウトプットのテンプレートは別ファイルとして定義している
このようなアプローチで現在AI駆動QA基盤上で実現しているワークフローが、以下になります。（個々のタスク定義はもう少し細かく分割されていますが、おおよそこのようなフローになっています）
現状は、リスク分析→テスト計画→テスト分析→テスト設計までのワークフローを組むことができており、テスト設計をもとにAIに自動テスト実装させることも実現できています。（自動テスト実装は厳密にはAI駆動QA基盤に組み込めておらず、現在はフローの分断があります）
toolsディレクトリ
toolsディレクトリには、テスト成果物の管理を便利にするツールを置いています。
例えば、freeeはテスト管理ツールにZephyr Scaleを利用しています*3。
AI駆動QA基盤の上で作るテストチャーターはmarkdownテキストでありそのままではZephyrScaleで扱えないため、ZephyrScale向けにデータ構造を整え、データをZephyrScaleにアップロードするようなツールを置いています。
productsディレクトリ
productsディレクトリは、プロダクトごとプロジェクトごとのテスト成果物を置く場所となっています。
ディレクトリ配下の構成は以下のようになっており、テスト成果物の置き場所を厳密に定めることで、AIがタスク実行ごとに迷う可能性を低減しています。
└── products/ # プロダクト別ディレクトリ
├── productA/ # プロダクト名
│ ├── README.md
│ ├── bug_information/ # プロダクト全体のバグ情報
│ ├── specifications/ # プロダクト全体の仕様書
│ ├── test_case_information/ # プロダクト全体のテストケース情報（マスター）
│ ├── golden_test_case/ # モデルケースとなるテストケース（Few-shotプロンプティング用）
│ └── projects/ # 各プロジェクトのQA成果物
│ ├── YYYYMMDD_project_name/ # プロジェクトディレクトリ（日付_プロジェクト名形式）
│ │ ├── 00_bug_information/ # プロジェクト固有のバグ情報
│ │ ├── 00_specifications/ # プロジェクト固有の仕様書
│ │ ├── 00_traceability_matrix/ # トレーサビリティマトリクス
│ │ ├── 01_spec_analysis_catch/ # 開発情報キャッチ
│ │ ├── 02_spec_analysis_understanding/ # 開発内容理解
│ │ ├── 03_risk_analysis/ # リスク洗い出し
│ │ ├── 04_test_plan/ # テスト計画
│ │ ├── 05_test_analysis/ # テスト分析
│ │ ├── 06_test_design/ # テスト設計
│ │ ├── 07_test_preparation/ # テスト準備
│ │ ├── 08_test_execution/ # テスト実行
│ │ └── 09_test_completion/ # テスト完了
│ └── _archive/ # 完了したプロジェクトのアーカイブ
またディレクトリ構成が明確になっているため、複数のメンバーが違うプロジェクトの違うテスト活動を進めても、お互いに影響が出ないようになっています。
プロジェクトのテスト活動を始める際は、PRDやDDなどのinput情報をプロジェクトフォルダの中に入れさえすれば、あとはAIに依頼すれば良いだけという感じになっています。
AIの出力の精度は、現在はまだミドルレベルのQAエンジニアが作る成果物の水準に至っていないです。そのため、工程ごとの最終成果物は人によるレビューを必須としています。
業務の効率が上がる場面も勿論ありますが、これを使えばすぐに必ず業務効率化できるという状況ではまだないです。
しかし、試行を繰り返してAIへの命令セットや与える知識を少しずつ改善していけば、組織としてAIから引き出せる力をもっと大きくしていけると考えています。
おわりに
今回は、AI駆動QA基盤の紹介をさせていただきました。
input情報の与え方や個別タスクの言語化、ワークフローの組み方などまだまだ改善しなきゃいけないことが沢山ありますが、freee QAの知識と知恵を結集して、一歩ずつ進んでいければと思います。
明日は、人事労務のQAエンジニアをされてるakari-san が「QAエンジニアのフィリピン出張記」という記事を書いてくれます。お楽しみに！
よい品質を〜
*1:freeeのQA組織は現在、プロダクト組織ごとにQAチームが存在する形を取っています。詳しくは12/25のアドベントカレンダー、もしくは freeeのQA組織の現在地とこれから-freee技術の日2025 - Speaker Deckをご参照ください。
*2:テスト活動の標準化については、QAのスキルアセスメントシートを作って適用してみた - freee Developers Hubをご参照ください。
*3:およそ1年前にZephyrScaleに移行しました。移行記事はこちら: テスト管理ツールを移行してみた 〜ツール転生させてQA無双〜 - freee Developers Hub
