この記事は、Bill One開発Unit ブログリレー2025の第17弾になります。
はじめに
こんにちは。Bill OneでQAエンジニアをしている林樹坤です。
現在、社内のあらゆるプロダクトでAI駆動開発が進んでいます。Bill Oneも同じです。AI駆動開発そのものの背景やBill Oneの取り組みについては、こちらのブログBill One開発マネージャーと挑む！ AI駆動開発合宿で掴んだ、AIを"思考の相棒"にする3つの勘所 - Sansan Tech Blogをぜひご覧ください。
その大きな流れの中で、私たちBill One QAは、AI駆動開発を見据えたQAプロセスの整備に早期から着手することになりました。AITAS（AI-driven Test Assistance System）プロジェクトもその一環ですが、この最適化自体もまだ試行錯誤の真っ最中です。
💡AITASとは？
AIを活用してテスト観点やテストケースの作成を支援する、独自のQAシステムです。「QA工数の削減とテスト品質の平準化」を目的に誕生しました。初期の取り組みについては、テスト設計の属人化からの脱却─AIで工数半減と品質標準化を実現したQAチームの挑戦 - Sansan Tech Blogで紹介しましたが、AI駆動開発の急激な進化に伴い、QAフローも新たなフェーズへと進化させる必要が出てきました。
本記事では、この加速する開発スピードを損なわず、かつQAが大量の情報をただ「さばく」のではなく、より能動的・戦略的に判断するためのプロセスとしてアップデートした「AITAS 2.0」の再設計について紹介します。
なぜ再設計が必要だったのか
私たちが直面したのは、「AIによって開発が劇的に加速すればするほど、従来のQAフローでは相対的に確認コストが増大し、QAが全体のボトルネックになりかねない」という切実な課題でした。
Bill One QAでは、開発スピードを停滞させないようAI施策をいち早く導入してきました。しかし、インプットの質が向上しアウトプットが詳細になるほど、人間はその膨大な情報を「さばく」だけで精一杯になってしまうという壁にぶつかったのです。
ここで言う「さばく」とは、開発サイズXS（軽微な修正）のPBIに対してAIが生成した100件以上の観点を、一つひとつ「有効か、ノイズか」と目検で仕分け、矛盾の有無を確認する作業を指します。
AITAS 1.0で顕在化した副作用
AITAS 1.0では、QAの専門性において2つの副作用がありました。
- AIとQAの役割の逆転（レビュー地獄）: AIが出した「フラットな100個の観点」を人間が後から解釈・修正していたため、自分でゼロから設計するより時間がかかるという本末転倒な事象が発生しました。
- 思考の停止とドメイン知識の空洞化: あまりの物量に、レビューが「内容を吟味する」ことから「機械的にリストを減らす」作業に変質してしまいました。これにより、QAが本来向き合うべき仕様の背景や、請求書業務としてのクリティカルな制約を深く思考しなくなるという、ドメイン知識の空洞化のリスクが顕在化したのです。
網羅性より、波及の見立てと優先度付け
さらにBill Oneの請求書ドメインでは、影響が単一画面や単一機能の「点」で止まらず、会計・税務・支払といった異なる業務プロセスへ「線」で連鎖します。つまりQAは、AIが出した観点の"数"をさばく以前に、変更の波及範囲を見立て、テストの優先度（重み）を付ける必要があります。
たとえば、「請求明細の端数処理ロジック」のわずかな変更は、一見すると表示上の小さな修正に見えます。しかしQAは、次のような連鎖的リスクをセットで想起しなければなりません。
- 関連機能への波及: 会計システムでは、生成される仕訳金額のズレが決算数値へ影響を及ぼす恐れがあり、税務システムにおいては、消費税額の根拠が変わることで税区分判断の整合性が崩れる懸念があります。さらに支払システムでも、支払締めの合計金額が不一致となることで、誤送金や支払遅延に繋がるリスクが考えられます。
- Bill Oneを使用するユーザーへの波及: 月次締め作業の真っ只中にいる経理担当者が、システム上の不整合により修正不能な状態に陥り、決算スケジュールそのものを止めてしまうような致命的な事態を招く可能性があります。
再設計で目指したこと（QAによるAIの能動的コントロール）
この「最先端の開発スピードゆえのボトルネック」を解消する取り組みは、他のQAグループでもまだ事例が少ない未知の領域です。今回の再設計は、単にAIを使って網羅性を高めるフェーズから一歩進み、AI駆動開発をさらに加速させるための「QAによるAIの能動的なコントロール」を実現するために必要不可欠なステップでした。
何をどのように変えたのか
フローの比較：AITAS 1.0 vs AITAS 2.0
最大の変更点は、「生成する前に、人間（QA）がリスクに基づいた枠組みを固定する」ステップを追加したことです。
AITAS 2.0のコア設計
1) QA視点による「リスクベース・サイジング」（Step 1）
AITAS 1.0にはなかった、2.0における最も大きな変更点がこの「サイジング」の導入です。
開発のPBIサイズ（実装難易度）と、QAから見たテストの重さは必ずしも一致しません。開発サイズS（小規模開発）でも影響範囲が大きくなる場合、テストが重いパターンもあります。
そもそも、なぜAITAS 1.0ではこの工程がなかったのか。当時はインプットがPBIやデザインのみに限定されることも多く、何よりQAとして「テスト観点の抜け漏れ」を最も恐れていました。そのため、まずはAIに網羅的に出力させ、後から人間が不要なものを削るという「引き算」の運用が前提となっていました。
しかし、AI駆動開発によって開発スピードが極限まで高まった現在、大量の出力を後から選別するコストそのものがボトルネックとなりました。
そこで2.0では、生成の「前」にQA視点での複雑さを再計算し、適切なボリュームを定義するステップを置きました。たとえば、実装自体は簡単でも「操作ログ」や「詳細検索」など複数機能に波及する場合、QA観点では高リスク判定となります。あらかじめ「どの程度のサイズ感で出すべきか」の枠組みをサイジングで定義することで、スピード感と精度の両立を狙っています。
2) 「濃淡のあるテスト設計」＝“テスト目的”から始めるテスト分析サマリー（Step 2）
ここが再設計の肝です。単なる観点のリストアップではなく、テストの目的と前提を先に言語化します。
- リスクの振り分け: 要件・UI・技術の3視点から、重点的に見るべき「High」と、薄く見る「Low」を先に決めます。
- 生成の暴走阻止:「なぜこの分量なのか」という根拠をAIに出させることで、無限生成や幻覚を抑制します。
- ドメイン知識（当たり前品質）の組み込み: Bill Oneでは、PBIに明記されていなくても考慮すべき「権限」や「処理フロー」などの「当たり前品質」が数多く存在します。小さな改修でも広範囲に及ぶ影響を正しくテスト設計することに苦労しました。現在は、プロンプトの中に**ステークホルダー（権限）や共通フロー**をあらかじめ定義して取り込むことで、分析の精度を高めています。
- ドメイン知識の継承: Bill Oneは経理・会計・税務・法規制などが複雑に絡み合うドメインを扱っています。変更が単一の機能に留まらず、広範な業務プロセスへ連鎖するため、AIを活用しながらもドメインナレッジを組織的に学習し続ける必要があります。そのために「ビジネス目的」「主要機能」「制約条件」の明文化を必須とし、QAが必ずこれを確認・レビューするフローを埋め込みました。
3) レビュー可能な“型”での出力（Step 3/4）
どんなに賢い生成物でも、読みにくければレビューは滞ります。
- 表形式の徹底: 情報をエンジニアが馴染みのある「表形式」に統一
- 制約の明示: 観点数やケース数の上限、優先度（Critical/High優先）などの制約をプロンプトで制御し、レビューの負荷を一定に保ちます。
導入後の効果
1. リリースを停滞させないレビュースピード（1/3に短縮）
生成前にQAが「枠組み」を決めているため、レビューは「AIが出した大量の候補から不要なものを削る作業」から、「あらかじめ定義した戦略に沿っているかを判断する作業」へと変わりました。
- 平均レビュー時間: 60分以上 → 20分以内に短縮
劇的に加速するAI駆動開発のサイクルをQAが止めることなく、スムーズに同期できるようになりました。
2. 高い品質（正確度・精度）の維持
AI生成において懸念されるのが品質のバラツキですが、リスク制御とプロンプトの最適化により、安定した品質を維持しています。
- 成果物の正確度・精度: 85%以上の品質を継続して維持 ※前回の記事でも触れた評価基準に基づき、QAエンジニアの目検評価でも高い信頼性を得ています。
3. テスト観点の適正化と合意形成
以前は小規模な改修でも100件以上の観点が出る「爆発」が起きていましたが、2.0ではあらかじめ設定したリスクの濃淡に応じ、適切な数へと収束する仕組みになりました。
特に、お客様の支払業務の停止に直結するような重大なリスクを優先度高く抑え込み、「なぜこの部分テストを厚くし、あちらを薄くするのか」の根拠（戦略）が言語化されているため、開発チームとの品質に関する合意形成が非常にスムーズかつ建設的になりました。
4. ドメイン知識の蓄積
「ビジネス目的・主要機能・制約条件」をAIテスト分析の際に改めて明文化し、人のレビューを必須としたことで、AIが便利になっても“背景理解”が置き去りにされにくい設計になりました。
単にアウトプットを処理するのではなく、QAがプロダクト理解を積み上げる導線として機能し始めています。
おわりに
AI駆動開発のスピードに追いつくためには、AIに「任せる」のではなく、QAがAIを「乗りこなす」ためのプロセス設計が不可欠です。AITAS 2.0は、まさに「リスクの濃淡」という人間の戦略をAIに注入し、開発を加速させながら品質を守り抜くための挑戦でした。
会計といった間違いが許されない領域を扱うBill Oneだからこそ、この「制御」の仕組みはプロダクトの信頼性を支える生命線となります。AIをただの効率化ツールで終わらせず、人間の戦略的な判断を具体化するパートナーとしてどう位置づけるか。
AI時代のQAのあり方は、これからもアップデートし続ける必要があります。このBill One QAでのリアルな試行錯誤が、同じ壁にぶつかっている皆さんのインスピレーションになれば嬉しいです。
We are hiring
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
