--- title: QA領域でのLLM活用　確認を楽にする工夫と利用データの活かし方 tags: #dena ai talks author: [DeNA_Tech](https://docswell.com/user/DeNA_Tech) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/LELM334V7R.jpg?width=480 description: 2026年9月29日に開催した「DeNA × AI Talks #9 LLMとどこまで付き合ったか」の登壇スライドです。 イベント概要：https://dena.connpass.com/event/404885/ published: September 30, 26 canonical: https://docswell.com/s/DeNA_Tech/5MQR68-2026-09-30-153449 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/LELM334V7R.jpg) QA領域でのLLM活用 確認を楽にする工夫と利用データの活かし方 DeNA Yuki Sugawara / Atsuhiro Matsuyama DeNA × AI Talks #9 © DeNA Co., Ltd. 2026.09.29 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/4JMYDDKNJW.jpg) 自己紹介 Yuki Sugawara IT本部AI・データ戦略統括部AI技術開発部 AIジャーニー推進グループ ● 2019年 DeNA新卒入社 ● AIドラレコ開発（出向） ● ライブ配信PocochaのCS審査効率化 ● AIジャーニー推進 今日話すこと｜前半 DAAQ全体像・開発の方針など © DeNA Co., Ltd. 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/PJR944X479.jpg) 自己紹介 Atsuhiro Matsuyama IT本部AI・データ戦略統括部AI技術開発部 AIジャーニー推進グループ ● 2026年 DeNA新卒入社 ● AIジャーニー推進 今日話すこと｜後半 表示テスト改善の具体の事例など © DeNA Co., Ltd. 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/PEXQ226ZJX.jpg) 発表の流れ 1 背景：QA業務の難しさ、内製ツール DAAQ の紹介、動作イメージ 2 DAAQテスト作成：テスト作成機能開発の4つの工夫 3 表示テスト生成の現状：表示テスト生成の作成プロセスの解説 4 開発事例：表示テスト生成の改善プロセスの3つの事例 まとめ © DeNA Co., Ltd. 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/3EK9MM1VED.jpg) 1. 背景 © DeNA Co., Ltd. 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/L73WYYNQ75.jpg) 背景 1 DeNA AI Advanced Quality (DAAQ) QA業務を広くカバーする内製ツール。 インスペクション／機能テスト／表示テスト…等、 多数のテストタイプ QA の課題 © DeNA Co., Ltd. 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/87DK55WWJG.jpg) 背景 1 QA業務の難しさ サービス・事業毎に要求される品質基準は異なる DeNAでは、QAコストが年間数十億円規模 QA業務のフロー（企画からテスト実行・検収まで） 企画 仕様書 テスト作成 テスト項目表 テスト実行 検収 インスペクション （矛盾・不足の指摘） QA業務の難しさ 1 仕様全体の把握が難しい 2 仕様の問題が後工程で見つかる 3 テスト設計が人に依存する • 仕様書が大きく、要件や条件が複 雑に絡み合う • 横断して読むのに時間がかかる • 矛盾や記載不足がテスト設計・実 施の段階で発覚 • 手戻りがコスト・スケジュールに 影響 • テスト要否や観点の判断が担当者 の経験で変わる • 品質や工数にばらつき © DeNA Co., Ltd. 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/VJPKGG9XE8.jpg) 背景 1 DAAQの支援範囲 DAAQ はテスト作成〜テスト実行までを支援。 今日話すのは DAAQテスト作成。 DAAQテスト作成 DAAQテスト自動化 今日話すのはこちら 企画 仕様書 テスト作成 テスト項目表 テスト実行 検収 テスト設計 検証手順生成 テスト作成の中身 インスペクション 要件整理 （矛盾・不足の指摘） テスト分析 複数の工程に分かれ、各工程で人が確認・修正 • 作業の効率化・成果物の標準化を AI で支援 • 人はレビューと判断に注力 • レビュー効率が上がる構造・データがたまる構造（データフライホイール）を目指す 成果 © DeNA Co., Ltd. 80% テスト作成工数を削減 95% 作成結果が修正不要 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/2EVV66M3EQ.jpg) 背景 1 DAAQのテスト作成・テスト実行の画面イメージ 仕様書（表計算・文書・PDF…） DAAQテスト作成 → テスト項目表 テスト目的・前提条件・手順・期待値 DAAQテスト自動化 項目 → 操作 → 照合 → 証跡 テスト項目のイメージ例：ナビのページ内スクロール 手順 https://dena-daaq.com/ へアクセス → ヘッダーの「サービス」をクリック 確認 「URL が dena-daaq.com/#service ・ 見出し「Service」が画面内に表示 ・ 再読み込みされていない」ことを確認する テスト項目表の質が、テスト自動化の上限を決める。 © DeNA Co., Ltd. 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/57GLNNGYEL.jpg) 2. DAAQテスト作成 © DeNA Co., Ltd. 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/4EQYQQX6JP.jpg) DAAQテスト作成 開発方針の工夫 2 課題 多様な仕様書 AIの不確実性 確認コスト 改善が積み上がらない 形式も書き方も 案件ごとに違う 低確率で間違え、 出力が揺れる 完成品を毎回全部 読み直すのは重い 直した結果が 次回に活きない 方針 1 入力の柔軟性 2 LLMに任せる・ LLMに任せない LLM 共通の処理で 扱えるように、 処理の上流で対応する © DeNA Co., Ltd. 3 確認のしやすさ 4 データの蓄積 人のレビュー効率を上げる ・レビュー観点の絞り込み ・確認しやすい UI 利用データを蓄積し、 同一 PJ の次回以降の 改善に使う コード LLM が不適な箇所は、 決定論的な処理に落とす 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/KJ4WNN6M71.jpg) DAAQテスト作成 入力の柔軟性 2 多様な形式は共通の取り込みで受け、特殊な形式だけ上流で変換する。 表計算 DAAQ本体のテスト作成処理 文書 PDF 画像 共通の 取り込み処理 要件整理 テスト分析 テスト設計 検証手順 生成 テスト 項目表 … 特殊な形式 必要に応じて変換 できるだけ上流（入力段階）で • 共通の取り込み処理：表計算・文書・PDF・画像など、多様なファイルに対応 • 必要に応じて変換：PJ 資料が独特な場合だけ、上流に個別の前処理。本体への影響を最小限に • 個別処理はやみくもに作らず、必要なら本体の共通処理へ取り込む。本体の開発に集中 例：特殊な形式 ＝ セル本文・図形・書式を使い分けた、視覚的に意味のある表計算ファイルなど © DeNA Co., Ltd. 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/LE1Y55VY7G.jpg) DAAQテスト作成 2 LLMに任せる・LLMに任せない 最近の LLM は（ほぼ）何でもできる。 それでも低確率で間違える。定型処理にトークン消費はもったいない。→ コードに落とせる処理は落とす。 処理の性質で分ける LLM に任せる { } コード（アルゴリズム）に任せる 意味の解釈が必要な処理 決定論的に処理できる処理 仕様の条件を読み解く 組み合わせを展開する テスト要否を判断する 件数を数える・照合する 観点・期待値・手順を書く 採番・転記・整形する 柔軟性が効く。出力は揺れ得るので、 人が確認する 同じ入力に同じ出力。コードをテストすれば、 毎回の確認を省ける 例：条件の機械的組み合わせ LLM が出した独立3条件 × 各2値 → コードで直積展開、2³＝8件 LLM の不確実な範囲が狭まり、人の確認は条件や観点の妥当性に絞れる。 © DeNA Co., Ltd. 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/GEWG55L1J2.jpg) DAAQテスト作成 確認のしやすさ：確認観点の絞り込み 2 テスト作成 仕様書 テスト項目表 テスト作成の中身（4つの工程） 要件整理 テスト分析 テスト設計 検証手順生成 この工程の成果物 この工程の成果物 この工程の成果物 この工程の成果物 整理した要件の一覧 テスト要否と理由 条件と期待値 操作手順 人が見るポイント 人が見るポイント 人が見るポイント 人が見るポイント 要否は妥当か 条件・期待値は 合うか 操作して 判定できるか 読み落としはないか テスト作成は成果物を直接作るのではなく、多段工程で実施。 工程ごとに人が見るポイントを絞り、レビュー負荷をさげる 確認回数は増えるが、上流の修正が後工程にも効くため、確認のレバレッジがかかる。 © DeNA Co., Ltd. 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/47ZLNNMXJ3.jpg) DAAQテスト作成 2 確認のしやすさ：成果物の見せ方 各確認ステップでレビューしやすい形を整える。 表示テストとは アプリ画面に、必要なUI要素（ボタン・見出し・文言など）が正 しく表示されているかを確かめるテスト UI要素の検出例 AI が見た場所をbbox表示し人が確認・修正 後半で詳しく © DeNA Co., Ltd. 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/YJ6W88NPJV.jpg) DAAQテスト作成｜工夫 4／4 2 データの蓄積と活用 1 利用する 2 記録する 人が確認・修正 LLM の入出力と 人の修正内容を記録 データフライホイール 次回以降の生成・評価に使う © DeNA Co., Ltd. 4 次回以降に使う 3 知見にまとめる テスト観点を生成時に参照 評価データで変更前後を比較 よく出るテスト観点まとめ 評価データ （入力・基準・正解データの候補） 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/GJ5M995PJ4.jpg) 3. 表示テスト生成の現状 © DeNA Co., Ltd. 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/9E2922NZ7R.jpg) 表示テスト生成の現状 - 要素検出 1 画面のスクショから、UI要素の種別、位置、文言を抽出 ● 仕様書（Figma など）から抽出した各画面の画像を 入力 ● 各画像ごとに、画像内のUI要素の種別・位置・文言 を抽出 ○ 要素種別は選択式 ■ （ボタン / ヘッダー / タブ など） ○ 位置は bbox [x0, y0, x1, y1] ● 位置検出は現状100% LLMで求める ○ タイル分割＋多段LLM検出 © DeNA Co., Ltd. 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/D7Y4YYPNEM.jpg) 表示テスト生成の現状 - テスト項目の生成 2 要素 × 観点 で、テスト設計行を作成 ● 各UI要素ごとに必要なテスト観点を判断し、観点ごとにテスト内容を組み立てる ○ 観点は全4種: 規定文言 / UIコンポーネント / 当たり前品質 / 全体配置 ● 設計行から検証手順を生成する ○ LLMとアルゴリズムの分担 UIコンポーネントのテスト 出力 内容（DAAQ インスペクション画面の実出力） 作っているもの 前提条件 ・テスト対象のシステムにログインしていること ・DAAQ_インスペクション画面を表示していること LLM 因子1 / 因子2 / 因子3 新規実行ボタン ／ クリック ／ UIコンポーネント（要 素の存在確認） アルゴリズム 期待値 ・ボタン：「新規実行ボタン」が表示されていること ・ボタンを押下できること LLM 検証手順（簡易） 1. 因子1を表示する 2. 因子1に対して因子2を実行する3. アルゴリズム 因子3を確認する 検証手順（詳細） 1.「新規実行ボタン」（UIコンポーネント:「ボタン」） が表示されていることを確認する 2.「新規実行ボタン」を押下する LLM 1画面あたり数十件ほど。LLMとアルゴリズムの分担については後述 © DeNA Co., Ltd. 検出内容 (新規実行ボタン) 要素種別：ボタン 規定文言：「+ 新規実行」 → 規定文言と UIコンポーネン トの2観点でテスト設計 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/VENYPP5VJ8.jpg) 表示テスト生成の現状 - 確認画面と評価結果 3 テスト確認UI、正解データと比較した精度比較を整備 ・確認画面 — 検出結果を人が確認し、修正しやすいUIを整備（→ 事例２） ・評価結果 — 正解データを整備し、機械的に精度を定量評価する仕組みを整備（→ 事例１） © DeNA Co., Ltd. 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/Y79P33YVE3.jpg) 4. 開発事例 © DeNA Co., Ltd. 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/G78DMM647D.jpg) 開発事例 - 評価の自動化 評価の自動化 — (1) 背景と取り組み 1 ● モデル・プロンプト・ワークフローは継続的に変更する。そのたびに改善の有無を確 認する必要がある ○ 当時の確認手段はQAのレビューのみ ■ QAチームに負担がかかり、検証速度も遅くなる → 正解データを固定資産として持ち、照合と評価を機械的に行う ● 正解データを人手で検品して用意し、全実行が参照する固定資産として配置 ● UI要素の検出漏れ、テスト作成内容（手順や期待値など）を、アルゴリズムやLLMで 人手を介さず判定する © DeNA Co., Ltd. 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/L7LM339VJR.jpg) 開発事例 - 評価の自動化 評価の自動化 — (2) 課題 2 ● 当初はLLMが出力した要素名からUI要素を正解と照合しなければならなかった ○ 要素名は揺れうる — 同一要素に複数の名前（ログインボタン / ログイン / Login） ○ 検出粒度も一致しない（どこまでを1要素と数えるか） ● 照合は LLM で行っていた ○ LLMの判断精度の評価が必要 ○ 評価コストがかかる ○ 実用ラインまでLLM判断自体の精度を引き上げること大変 ① 要素名が揺れる ② 検出の粒度が揃わない 実行 A — カード全体を1要素 ログインボタン ログイン Login ログイン 同一モデルでも実行ごとに名前が変わる。 名前をキーにすると、正解と予測を突き合わせられない © DeNA Co., Ltd. vs 画面上の要素は1つ ボタン 実行 B — 中の要素を個別に 1件 3件 どこまでを1要素と数えるかが、実行間で一致しない。 人手で紐付けても、一部は判断が分かれる 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/4EMYDDZNEW.jpg) 開発事例 - 評価の自動化 評価の自動化 — (3) アプローチ 3 ● 要素検出の出力に bbox を追加した ● 照合を枠の重なりに置き換えた ○ 名前の一致に依存しない ○ LLMを使わないため、同一入力には常に同 一の結果が出る ○ 取りこぼし・過剰・分割・結合を分類し て集計できる 枠の重なり判定（ケース1〜3） ケース1 ケース2 ケース3 ほぼ一致 大枠が小枠を飲む かすっているだけ 同じ要素 ◯ 同じ要素◯ 違う要素 ✕ （分割されて検出） → bboxを追加で出力させることにより評価を行いやすくした © DeNA Co., Ltd. 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/PER94464J9.jpg) 開発事例 - 評価の自動化 4 評価の自動化 — (4) 結果 ● 定量評価を自動化し、モデル選定と構成変更の判断に実際に使っている ○ 機械評価のモデル順位は、担当者の定性評価と概ね一致した ○ 実際には要所でQAの定性評価も継続して行っている ● 正解データを資産として持つと、評価が継続的に回る → ②LLMに任せる／任せない に対するアプローチ （正解との照合をアルゴリズムに寄せた、 ワークフローにも手を加えた） © DeNA Co., Ltd. 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/P7XQ22MZEX.jpg) 開発事例 - 評価の自動化 5 評価の自動化 — (5) 今後 蓄積したユーザの修正を、正解データの作成と生成の両方に回す ● 評価に回す ○ 利用時にQAが修正した内容を蓄積し、正解デ ータとして利用する ○ →利用に応じて正解データが増える構成 ● 生成に回す ○ 人手で確定した版を、新規入力との一致度に 応じて再利用する ■ ①同一・類似画面で要素の粒度・命名・ 規定文言の抽出が安定する ■ ②そのプロジェクトの文脈に沿った項目 が出せる (いずれも未実装・設計中) 生成 QAが確認・修正 修正を蓄積 ここから先は未実装・検討中 評価に回す 生成に回す 正解データの候補として増 える 一致度に応じて確定版を few-shot で再利用 利用するほど正解データが増え、 案件ごとの記述に沿った出力に寄る → ④データの蓄積 に対するアプローチ © DeNA Co., Ltd. 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/37K9MMGV7D.jpg) 開発事例 - 確認作業の効率化 6 確認作業の効率化 — (1) 課題 ● DAAQにより作成コストは下がったが、確認コス トは残った ○ 現状のQAの負荷の中心 ● 既存の確認画面は、テスト項目を表で見て直す 作り ○ 画面（スクショ）が表示されていなかった ● 表だけでは、テスト1件が画面のどの要素を指す か分からない ○ 要素名を読んでスクショと突き合わせる手 作業になる © DeNA Co., Ltd. 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/LJ3WYY5QJ5.jpg) 開発事例 - 確認作業の効率化 7 確認作業の効率化 — (2) アプローチと結果 スクショに枠を描き、その場で直せる確認画面を提供した ● 評価のために整備した bbox を、人の確認にもその まま使えるようにした ● テスト1件が画面のどの要素に対応するかを、枠と番 号で特定できる ○ 拾えているか／拾えていないかを、テキストを 読まずに判断できる ● 開発エンジニアの工数が取れず、別環境のPoCとし て先行提供した ○ Cloud Run でデプロイし、URLを渡せば使える ● サブツールとして実際に利用されている（好評） → ③確認のしやすさ に対するアプローチ © DeNA Co., Ltd. 28 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/8JDK55DWEG.jpg) 開発事例 - 後段処理のアルゴリズム化 後段処理のアルゴリズム化 — (1) 課題 8 テスト作成にかかる時間が長すぎる ● 1画面からテスト設計が数十件出る。その1件あたりLLMを5回呼んでいた ○ 件数が増えるほど実行時間が伸び、画面1枚の生成が待たされる ● 5つのプロンプトを読み解くと、出力がパターン化されているものもあった # 出力 何を整理する機構か 具体例（1-11_連動企画 の実出力） LLMをなくせそうか ① 因子 テスト対象・操作・観点を一言に 企画名見出しテキスト ／ 操作なし ／ 規定文言「連動企 画」 一定パターンがあるのでなく せそう ② 前提条件 テストを開始できる状態（ログイン・画面・テ ストデータの要否など） ・ログインしていること ・1-11_連動企画画面を表示して いること ③ 期待値 何が満たされていれば合格か ・「連動企画」という文言が表示されていること ④ 検証手順（簡易） 手順の骨組みの形だけ（2〜3手順の概要） 1. 因子1を表示する 2. 因子3を確認する ⑤ 検証手順（詳細） テスターがそのままなぞれる操作列（開始画面 から確認対象の画面まで） 1.「企画名見出しテキスト」の規定文言:「連動企画」が表示 されていることを確認する かなり出力が固定的で、なく せそう 特に④は、LLMに「"因子1" という文字列をそのまま出力せよ」と指示していた © DeNA Co., Ltd. 29 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/VEPKGGXX78.jpg) 開発事例 - 後段処理のアルゴリズム化 9 後段処理のアルゴリズム化 — (2) アプローチと結果 要素種別ごとに対応表を作っておけば、実行時のLLMは要らない UI要素種類マスタ（48種別・抜粋） 要素種別 操作有無 操作（因子2） 動作動詞 ボタン あり クリック 押下する テキストインプット あり テキスト入力 入力する チェックボックス あり 選択 選択する ヘッダー なし 操作なし — → ②LLMに任せる／任せない に 対するアプローチ © DeNA Co., Ltd. ● 48種別に対し、操作語彙は8値 ○ クリック／テキスト入力／選択など ○ 因子1/2/3 と検証手順（簡易）は、 この表を引くだけで決まる ● LLM呼び出しが消えた。 ○ 1件あたり 5回 → 3回 ■ コスト減・高速化 ● 表引きは同じ入力に同じ出力を返すため、 毎回の目視確認が要らない ● 残る3つ（前提条件・期待値・検証手順詳 細）はLLM生成。 30 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/27VV66L37Q.jpg) 10 事例まとめ 課題・アプローチ・前半の工夫との対応 課題 アプローチ 前半の工夫 評価の自動化 改善したかどうかを、QAのレビューで 正解データを固定資産にし、bboxの重なり しか判定できない で照合して機械的に測る 確認作業の効率化 生成結果の確認を、テスト項目の表だ けで行っていた 後段処理のアルゴリズム化 テスト項目の生成に時間がかかる（1件 テーブルを整備して、機械的に解決できる部 ②LLMに任せる/任せない あたりLLM×5） 分をアルゴリズムへ © DeNA Co., Ltd. ②LLMに任せる/任せない ④データの蓄積 スクショに枠を描き、その場で直せる確認画 ③確認のしやすさ 面を提供 31 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/5JGLNNXY7L.jpg) まとめ © DeNA Co., Ltd. 32 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/47QYQQ86EP.jpg) まとめ 生成で終わらせず、確認と評価まで設計する 1 入力の柔軟性 多様な形式を共通の取り込みに。特殊な形式 は上流で変換 2 LLMに任せる・任せない 意味の解釈はLLM、決定論的な処理はコード 3 確認のしやすさ 工程ごとに見るポイントを絞る。内容に合う 画面で見せる 4 データの蓄積 入出力を記録し、観点の蓄積と評価に使う 実際に動いているもの © DeNA Co., Ltd. 33