はじめに
こんにちは。Bill OneでQAエンジニアをしている林樹坤です。
2026年3月20日、JaSST Tokyo 2026に登壇しました。部長の佐藤と共同登壇で、Sansan QA組織のAI戦略と、私が設計したAIテスト支援システム「AITAS」の実践事例を話しました。
この記事は、AITASについて書いてきたシリーズの第3弾です。
- 第1弾：テスト設計の属人化からの脱却─AIで工数半減と品質標準化を実現したQAチームの挑戦 - Sansan Tech Blog ─ AIに丸投げの失敗から始まり、4ステッププロセスを構築して属人化と工数を解消した話
- 第2弾：Vol.17 AI駆動開発を加速させるQAフローの最適化 - Sansan Tech Blog ─ 「レビュー地獄」とドメイン知識の空洞化という副作用を乗り越えるためにAITAS 2.0を再設計した話
本記事は、その先です。AITASを作り続ける中でずっと向き合ってきた「AIの出力を信頼に変えるとはどういうことか」という問いを、JaSST Tokyo 2026という場で言語化する機会を得ました。「信頼」に向けた工夫と、発表後に気づいたことを書きます。
当日の発表資料
発表で使用したスライドを公開しています。以降の本文に出てくる「AITAS」「Step 0〜3」「精度測定の仕組み」などの全体像はスライドで確認いただくと、より理解しやすくなります。
改めて、問いの核心
第2弾の締めで「次の課題はナレッジDB」と書きました。その課題に取り組みながら、AITASは現在v2.1まで進化しています。
JaSST Tokyo 2026の発表冒頭では、聴衆にこう問いかけました。
AIを使い始めたけど、その出力、本当に信頼できていますか？
この問いは、freeeさんとの合同イベント（2026年2月）でSlidoに寄せられた42件の質問から来ています。最もUpvoteを集めたのは「AIでのテスト実行時の結果の信頼性はどのように確保していますか？」でした。
これは他の誰かの問いではなく、私自身がずっと向き合ってきた問いです。工数を削減したことは第1弾で書きました。精度を数値で追う仕組みを作ったことは第2弾で書きました。それでも「信頼できるか」という問いへの答えは、発表の場に立つまで自分の中でも整理しきれていませんでした。
「信頼」に向けた工夫
ここでいう「信頼」をまず整理します。AIの出力精度が高いこと。その精度が、誰がいつ実行しても安定して再現され、根拠を持って説明できること。そして実務レベルでは、AITASを使ったテスト設計でCriticalなインシデントが出ず、品質を下げないこと。この3点が、私にとっての「信頼」の定義です。精度はその一要素に過ぎません。
その信頼を実現するために、AITASはPBI仕様書・Figmaデザイン・ナレッジDBをインプットし、テスト分析・観点・ケースを生成する4ステップのパイプラインとして設計しています。スライドで全体像を確認してもらえると理解しやすいですが、本記事では特に「なぜこう設計したか」という判断の部分を3つに絞って掘り下げます。
どのくらい生成させるか、先に決める
AIにPBIを渡す前に、まずQA視点でテストの重さを判定するステップを設けています（Step 0：QAサイジング）。
※第2弾ではStep 1と表記していましたが、現在のバージョンでは0始まりの番号に統一しています。
このステップが必要だと気づいたきっかけは失敗でした。AIに「テスト観点を出して」と丸投げしたとき、XS規模のPBIに100件超の観点が返ってきた。問題は「AIに何を出力させるか」だけを考えて、「どのくらい出力させるか」を人間が決めていなかったことでした。インプットが多ければ出力も多くなる。当たり前のことを見落としていたのです。
ここで重要なのが「開発サイズ ≠ QAサイズ」という考え方です。コード変更は数行でも、影響範囲の広さ・機能の複雑さ・テスト準備の複雑さでQAのサイズが大きく変わります。開発サイズXSでも、QAサイズはM・Lの場合は十分あります。Step 0はこの判断を、生成前に確定させる仕組みです。
AIにドメイン知識を持たせる
AIにPBIをそのまま渡すだけでは、Bill Oneの業務ルールを知らない状態でテスト設計させることになります。そこでStep 1（テスト分析サマリー）では、ナレッジDBに蓄積した機能仕様・業務ルール・過去バグのパターンをインプットし、AIを「よそのQAエンジニア」から「Bill One専属のQAエンジニア」に変えることを目指しています。
こうしてステップごとに「AIに何をさせるか」を設計した上で、AITAS全体には3つのガードレールを組み込んでいます。
- ガードレール1：根拠の明示（不確実な情報には [要確認] タグを付けさせる）
- ガードレール2：リスクベースの優先順位設計（影響度×発生確率で判定）
- ガードレール3：約3000文字の出力制御プロンプト（誰が実行しても同じフォーマット・粒度になるよう統一）
また、各ステップでAIのロールを切り替えています。Step 0はプロダクトマネジャー兼アジャイルコーチ、Step 1はテストアナリスト、Step 2/3はQAエンジニア。ロールを変えることで、各ステップで求めている思考の粒度が変わります。
数値で可視化する
重みの根拠は、精度ツールの最適化ではなく「見落としたときの影響度」から逆算しています。重大な見落としと軽微な表現ミスを同列に扱うのは意味がない。QA組織として何を守るかという設計思想から来ている数字です。
精度 = 1 − （重大×3 + 中程度×2 + 軽微×1）/ （観点総数×3）
このスコアリングはエンジニアとQAのレビューコメントをAIが自動分析して行っています。精度ランクは80%以上が優秀（3カ月に1回分析）、60〜80%が許容（月1回分析）、60%未満が即改善です。
この仕組みがあるから改善サイクルが回ります。「なんとなく精度が上がった気がする」では、組織への信頼を築けません。
AITASが目指してきたこと
半年以上運用してきましたが、AITASを使ったテスト設計でCriticalなインシデントは発生していません。AIを使い始めたことでプロダクト品質が下がったという実感もありません。さらに、誰が実行しても、複数回のバージョンアップ後も、精度は平均85%以上を維持しています。冒頭で定義した「信頼」の3点は、現時点で成立しています。
AIとQAエンジニアの役割分担：85%と15%
AITASでは、テスト観点の生成・分析・ケース作成といった作業をAIが担い、判断と意思決定を人間が担うという役割分担を設計の前提にしています。現時点の比率でいうと、AIが約85%、人間が約15%です。
AIが担う85%は、構造化された観点の生成とパターンベースのケース作成です。残り15%はスコープを引く判断・リスクの最終評価・仕様の曖昧さの解釈・AIが出した量から「本当に必要なもの」を見極めること、これは人間にしかできません。
100%を目指さないのは意図的な設計です。残り15%こそ、QAエンジニアの価値がある場所だと考えているからです。
発表後に気づいたこと
セッション終了後のDiscordには「ナレッジがプロダクトの成長に応じて陳腐化するのを防ぐ仕組みは？」という質問が来ました。発表では十分に話せなかった部分です。
現状の対策は3つあります。Notionに期限フィールドを設けて「いつ見直すか」を明記すること、仕様書への直リンクで変更を検知できるようにすること、PBIや仕様書が更新されたときにSlack通知を飛ばすこと。ただ、現状、これらはすべて「人が都度対応する」前提の仕組みです。
最終的に目指しているのは、PBIの変更をトリガーにナレッジが自動更新される仕組みです。開発高速化が進む中で、手動更新には限界があります。ここはAITASの次の課題です。
シリーズを振り返って
振り返ると、AITASは最初から「信頼できるテスト設計をAIで実現する」という同じ問いに向き合ってきました。第1弾では属人化を解消し、誰が実行しても同じ品質を出すことを目指しました。第2弾では過剰生成とドメイン知識の空洞化という副作用と戦い、生成をコントロールする仕組みを作りました。本記事では、その「信頼」とは何かを改めて言語化しました。
問いは変わっていません。ただ、向き合い方が深くなってきた感覚があります。
AITASはまだ完成していません。現在はプロンプト集として動いていますが、アプリ化を進めています。ナレッジの自動更新、他プロダクトへの展開、精度測定の継続改善──やることは積み上がっています。
本記事を読んで何か気になることがあれば、気軽に声をかけてください。
We are hiring
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
open.talentio.com
