QA組織のAI戦略とAIテスト 設計システムAITASの実践 Sansan株式会社 技術本部 Quality Assurance Engineering Unit 佐藤 ⽔哉・林 樹坤 Sansan 技術本部 

写真が入ります 佐藤 ⽔哉 技術本部 Quality Assurance Engineering Unit 部⻑ 2003年、マイクロソフトに新卒⼊社。約20年間、⽇本語⼊⼒シ ステム（IME）のテストエンジニアとしてキャリアをスタートし、 テスト⾃動化基盤の構築、パフォーマンステストの確⽴、 テレメトリを活⽤したデータドリブンな品質管理へのシフトを 推進。SDETからデータサイエンスマネージャーまで幅広い役割 を経験。 2023年11⽉にSansan株式会社へ⼊社。2025年3⽉よりQuality Assurance Engineering Unitの部⻑として、AI活⽤を含むQA組織 の変⾰に取り組む。 

Sansan株式会社の働き⽅を変えるAXサービス ⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる 「働き⽅を変えるAXサービス」を提供します。 データクオリティマネジメント 請求 名刺 管理 営業 契約 名刺管理から、収益を最⼤化する AI契約データベースが、利益を守る 「なくせる」をつくり、全社の働き⽅を変える 名刺アプリ 経理AXサービス 取引管理サービス ビジネスデータベース 各サービスの活⽤で変わる働き⽅ 情報を分析・活⽤しやすく データに基づいた判断ができる 情報の管理がしやすく すぐに共有できる 必要な情報を すぐに⾒つけられる 個⼈向け 法⼈向け 

4 © Sansan, Inc. 4 © Sansan, Inc. Quality Assurance Engineering Unit Emerging Products グループ Matured Products グループ QAチーム構成 各プロダクトごとにチームに分かれて連携する SET 52名 社員 協⼒会社の⽅ 16名 36名 

今⽇話すこと 1 Sansan QA組織とAI活⽤戦略（佐藤） 組織の背景とAI活⽤の考え⽅ 2 AIの出⼒を"信頼"に変えた仕組み（林） BillOne QAチームのAITAS設計と精度測定 3 学びと今後の課題（佐藤） 横展開の学び、AI駆動開発時代への対応 

AI活⽤の背景 開発側のAI活⽤による⽣産性向上への対応 - AIを⽤いた開発⽣産性の向上が⾒込まれ、QAがボトルネックになるリスクがある - AI⽣成コードの品質検証という新たな課題 → AI活⽤を理解していないと対応できない AIの能⼒を実感として⾝につける必要性 - AIの能⼒の限界・最適な使い⽅・モデル進化による変化は、実際に試さないとわからない - 失敗パターンを知ることも重要 → どこでAIが間違えるかを実感として把握 環境整備の課題 - 52名体制（正社員16名、協⼒会社36名）全員がAIを活⽤できる環境を整える必要がある なぜAI活⽤に取り組むのか ⽣成AIを活⽤するからには、⽣成AIが我々の仕事にとってどういう位置づけであるべきか、 仮説を⽴てる必要がある。まず過去の技術⾰新を振り返り、⽣成AIの特異性を分析してみた。 全社⽅針「AI First」 - 2025年の年間テーマとして、Sansan全社で「AI First」が掲げられた - これにより全社をあげて業務でAIを活⽤する試みを開始 

過去の技術⾰新を振り返る 技術⾰新は常に「⼈の能⼒を増幅するレバレッジ」として機能してきた。 時代 技術 設計者の役割 ユーザーの役割 産業革命 機械 業務プロセスを設計し、 機械に組み込む 設計されたプロセス 通りに操作 CUI時代 メインフレーム コマンド体系・処理 フローを設計 コマンドを覚えて実行 GUI時代 PC/アプリ 利用シナリオを想定し、 UIとして具現化 想定されたシナリオ 内で操作 SaaS時代 クラウドアプリ ワークフローを設計し、 サービスとして提供 想定されたワークフロー 内で操作 共通点：設計者がユーザーの「何をするか」を設計 アプリ・サービス設計者が利⽤シナリオを限定 では、⽣成AIは過去の技術と何が違うのか？ ユーザーは設計された枠組みの中で操作スキルを習得 

⽣成AIで何が変わったか ⽣成AIは利⽤シナリオを限定しない。これが過去の技術との決定的な違い。 観点 過去の技術（産業革命〜SaaS） 生成AI 設計者の役割 利用シナリオを想定・限定 汎用的な能力を提供 ユーザーの 参加開始地点 設計されたシナリオから 目的・設計から ユーザーに 求められること 操作スキルの習得 何を求めるか自ら設計 ユーザーの参加開始地点が上流に移動した 【過去の技術】 ⽬的 設計 シナリオ 定義 ツール 実装 操作 成果物 ▲ ユーザーはここから参加 【⽣成AI】 ⽬的 設計 指⽰ 評価 成果物 ▲ ユーザーは上流から関与 「仕事そのものを理解している⼈」「正しい判断ができる⼈」が有利 上流設計のスキルが重要だという仮説を⽴てた。では、この仮説を検証し、AIの能⼒を実感として ⾝につけるために、実際にAIを活⽤して学びを得る必要がある。 

AI活⽤の対象領域と進め⽅ AIの能⼒は実際に使ってみないとわからない。まず試して、実感として学ぶことが重要。 - Claude Enterprise（Desktop・Code） - ChatGPT Enterprise - Google Gemini - Cursor - Notion AI ※各チームが組み合わせを判断 対象領域 テスト戦略 テスト計画 テスト設計 テスト実⾏ ＋ 周辺業務（情報収集、報告資料作成など） 進め⽅ PoCを回して実験 ベストプラクティス蓄 積 他チーム展開 まだAI活⽤の正しい⽅法は確⽴されていない → まず試してみて実感として学ぶことが重要 この進め⽅の具体例として、Bill One QAチームでパイロットを実施し、AITASが⽣まれた。 詳細は林から。 QA組織で利⽤しているAIツール 

AIの出⼒を"信頼"に変えた仕組み ─ BillOne QAチームのAITAS設計と精度測定 ─ 

林 樹坤 Sansan株式会社 技術本部 Quality Assurance Engineering Unit 2025年1⽉にSansanへ⼊社。 Bill OneのQAエンジニアとして、アジャイル開発プロセスに 参画しながらQAプロセスの改善を担当。 QAにおけるAI活⽤施策の⽴案および推進をしている。 

今⽇の問いかけ AIを使い始めたけど、 その出⼒、 本当に信頼できていますか？ 

AI活⽤の構造的な問題 ⽣成物のばらつき AI・実施者によって 出⼒が異なり、品質が 安定しない 01 過剰⽣成 ⼩さなPBIに対して 100件超の観点が ⽣成される 02 ハルシネーション AIが事実に基づかない 観点を⽣成し、 信頼性が低下する 03 

AITASはなんですか？ AI-driven Test Assistance System AIが忙しいQA業務を"助（たす）ける" テスト分析 観点 ケース AITAS ナレッジシステム (Knowledge System) 仕様書・PBI (Specs & PBI) 

AITASの構造 ケース⽣成 85% 精度 54% ⼯数削減 20分 平均レビュー時間 観点⽣成 Step 3 Step 2 テスト分析 サマリー Step 1 QA サイジング Step 0 PBI仕様書 Figma ナレッジDB INPUT 

AITASの特徴と設計思想 01 モデル⾮依存のプロンプト集 モデルに依存しないプロンプトのコレクションとしてメンバーに展開 02 PBIサイズ駆動の出⼒量制御 PBIの規模に応じて⽣成する観点数を⾃動的にコントロール 03 ナレッジDB連携 既存機能の背景知識をDBから参照し、コンテキストを補完 04 ステップごとのロール切り替え 各ステップでAIの役割を変え、分析・⽣成・レビューを分離 設計思想 コンテキスト駆動型 ─ AIに判断の裁量を⼀部委譲する 

Step 0：QAサイジング 開発サイズ ≠ QAサイズ 開発 XS 01 影響範囲が広さ 02 機能の複雑さ 03 テスト準備の複雑さ QA M 「何をテストするか」の境界を引く 広さ（Scope）── やる／やらないの意思決定 

Step 1：テスト分析サマリー出⼒構造 テスト分析サマリーが⽣成する6つのセクション Section 1 要件定義から理解したこと ビジネス⽬的・主要機能・制約条件 = AITASオリジナルのセクション Section 2 UI仕様から理解したこと 画⾯構成・操作フロー・UX注意点 Section 3 実装仕様から理解したこと 処理ロジック・外部連携・技術的制約 Section 4 統合的な理解と絞り込み戦略 本質1⽂・重要観点・リスクテーブル Section 5 PBIサイズベースの予測 観点数・ケース数をサイズ⽬安から推計 Section 6 テスト戦略の絞り込み⽅針 重点・軽量化・スキップ領域を明⽰ 

Step 1：品質ガードレール プロンプトに組み込んだ3つの制御機構 GUARDRAIL 1 根拠・推測の明⽰ ハルシネーション防⽌ - 不確実な情報は [要確認] と 明記 - 確実な情報のみを記載させる - AIの「それらしい推測」を 抑制 GUARDRAIL 2 リスクベース テストの優先順位を設計 - 影響度 × 発⽣確率で リスク判定 - 重点・軽量化・スキップを 明⽰ - Delta箇所のみテスト対象に 絞る GUARDRAIL 3 細粒度ルール制御 出⼒を細かいルールでコントロール - 約3000⽂字のプロンプトで 出⼒ルールを細かく設定して コントロールしている 

Step 2 & 3：テスト観点 → テストケース Step 2 テスト観点 PBI特性に合わせたグルーピング - 画⾯遷移が多い → 画⾯ごと - 業務フロー主体 → ステップごと - 単⼀画⾯ → 機能ブロックごと → レビュアーが⼀⽬で理解できる⾒出しに 発⽣源の明⽰（PBI vs ナレッジ） PBI由来か既存機能の影響確認かを列で可視化し、 根拠を追跡可能にする Step 3 テストケース グループ構成の継承 Step 2の⾒出しをそのまま引き継ぎ、観点→ケースの 追跡を容易に 観点IDで完全⼀致⽣成 トレーサビリティを確保 期待結果の曖昧表現を禁⽌ 「正しく動作する」→ 具体的に何が表⽰・ 実⾏されるかを記述 観点のグループ構成がそのままケースに引き継がれ、レビュー・追跡が⼀貫する 

精度の数値化：ポイント制スコアリング 精度 = 1 − （重⼤×3 + 中程度×2 + 軽微×1） （観点総数 × 3） - 分⼦：重みづき実ミス点（深刻度を反映） 分⺟：全観点が重⼤ミスだった場合の最⼤点（正規化） 0〜1の精度スコアに変換。ポイントが低い＝精度が⾼い ─ ポイント定義 3pt 重⼤な抜け・間違い 2pt ⽅向性ずれ・仕様誤解 1pt 軽微・表現ミス・重複 0pt インプット起因 ─ 精度ランク（⾃動付与） 80%以上 優秀 60〜80% 許容 60%未満 要改善 

AIと⼈間の役割分担 85% AIが⽣成できる領域 構造化された観点 パターンベースのケース 15% 判断・意思決定は全部⼈間で⾏う - スコープを引く - リスクの最終判断 - 仕様の曖昧さの解釈 - AIが出した量から 「本当に必要なもの」を⾒極める 

持ち帰ってほしい3つのポイント 1 プロセスで信頼を作る 4ステップで⽣成前・中・後をコントロール 2 ナレッジで精度を上げる AIは「よそのQAエンジニア」、ドメイン知識を与える 3 数値で追わないと改善できない 重み付け精度測定があるから改善サイクルが回る 

学びと今後の課題 

例2：Sansanモバイル向けテスト設計システム AITASの成果を踏まえて、他プロダクトへの横展開を進めた。プロダクトの特性に合わせた設計を⾏った。 観点 AITAS（Bill One） Sansanテスト設計システム 対象 Webアプリ（SaaS） モバイルアプリ（iOS/Android） 設計思想 コンテキスト駆動型 定義駆動型 AIへの指⽰ AIに判断の裁量を⼀部委譲 ⼈の暗黙知をタスク化し、外部定義ファイルでAIの判断 を制約 ナレッジ ナレッジDBを⽤途別に参照 12以上の定義ファイル （テストレベル、テストタイプ、観点カタログ等） パイプライン構成 AITASは最初に出た⼀つの解答であり、必ずしも唯⼀の正解ではない。 この2つのシステムを⽐較することで、いくつかの学びが得られた。 事前準備 UI辞書作成 STEP 0 要件整理 STEP 1 画⾯仕様 STEP 2 テスト分析 STEP 3 テスト観点 STEP 4 テストケー ス 

26 © Sansan, Inc. 26 © Sansan, Inc. Bill One - AITAS Sansan Mobile 

3つの学び 1 正解は1つではない - プロダクト特性（モバイル vs Web）が設計を規定する - AITASをコピーするのではなく、各プロダクトに最適な設計を導き出す 2 共通化すべきは「考え⽅」であって「プロンプト」ではない - ⽤語・不確実性管理・品質基準は共通化できる - Context Engineeringは実践中 → Intent / Specification Engineeringは今後の領域 3 プロダクト間共通システム化が必要 - 試⾏段階を経て、誰でも使いやすいシステムを構築する必要がある - 例：Coworkプラグインとして配布可能なシステム - 共通化された⼟台があれば、全プロダクトへの展開（スケーリング）が加速する AITASとSansanシステムの実践と⽐較から、3つの学びが得られた。 これらの学びを踏まえて、AI活⽤に必要な技術とスキルを体系化してみた。 

Context / Intent / Specification Engineering まず、AIのレバレッジを最⼤化するために必要な技術を3つに整理した。 技術 定義 QAでの適⽤例 Context Engineering AIが次のステップで必要とする 「まさに適切な情報」で コンテキストを満たす技術 ナレッジDBの構築、 テスト観点カタログの整備、 PBI情報の構造化 Intent Engineering 「何を達成するためのテストか」 という⽬的をAIに伝え、 正しいゴールに向けて最適化させる技術 「網羅的なテストケース」ではなく 「何を保証したいか」を ⽬標として設定 Specification Engineering AIエージェントが⼈の介⼊なしに 正しく実⾏できる、詳細で 機械可読な仕様を書く技術 テストシナリオ、受け⼊れ基準、 評価ルーブリックの精密な定義 共通点：いずれも「AIに何を・どう伝えるか」を設計する技術 次に、これらの技術を組織に浸透させるためのスキルレベルを定義した。 

AIスキルレベル定義 実践と学びを踏まえて、組織として必要なスキルを4段階で定義した。 レベル 名称 スキルの内容 対応する役割 Lv.1 AI基礎 AIを怖がらずに使い始められる 全員が到達 Lv.2 応⽤判断 AIの出⼒を⾒極め、業務に組み込める 全員が⽬標 Lv.3 システム設計 AI活⽤の仕組み（シナリオ）を設計できる ⼀部 Lv.4 技術実装 AIテスティング基盤を構築できる 少数 組織⽬標 - 全員がレベル2に到達 - レベル3がAI活⽤のシステム化を担う - レベル2がフィードバックを提供し、レベル3がシステムを改善するループが重要 Context/Intent/Specification Engineering → レベル3「システム設計」で求められる能⼒ レベル2の⼈材がフィードバックを提供し、レベル3がシステムを改善するループが重要 このスキルを組織全体で⾝につけていく上で、現実的な課題がある。 

今後の課題：⼆層構造への対応 開発現場では、AI活⽤の程度が異なる2種類のチームが存在する。 従来型＋AI補助 AI駆動開発 プロダクトA ⼀部でAI補助を試⾏ プロダクトB AI補助が定着、⼀部AI駆動へ プロダクトC AI駆動チームが拡⼤中 プロダクトD ⼤半がAI駆動開発へ移⾏ この変化を⾒据え、QA組織として備える必要がある - プロダクトごとに異なるQAアプローチを使い分ける体制づくり - 従来型の品質担保を維持しつつ、AI駆動開発への対応⼒も育てる - 限られたリソースの中での優先順位付け この課題に対して、スキルレベルに応じた役割分担でアプローチする。 

⼆層構造への対応アプローチ スキルレベルに応じた役割分担でスケールするシステムを構築し、⼆層構造に対応する。 Lv.4 技術実装 QA組織の技術的メンバーが共通基盤システムを構築 Lv.3 システム設計 各プロダクトで⼀⼈パイオニアがAI活⽤システム設計を推進 Lv.2 応⽤判断 業務委託メンバーを含むテスト設計に関わる全員をレベル2に到達させる この取り組みを加速するために、レベル3以上のメンバーの採⽤も重要な要素となる。 効果：効率化によりAI駆動開発対応の時間を捻出 共通基盤により全プロダクトへのスケーリングが加速 

We are hiring! 募集職種⼀覧はこちら https://jp.corp-sansan.com/recruit/midcareer/jobs/ 

No content