【DeNA QA Night #8】その検証、AIなら即日です

その検証、AIなら即日です 諸冨 弘樹 IT本部品質管理部ソーシャルQAグループ 株式会社ディー・エヌ・エー © DeNA Co., Ltd. 1

こんな現場課題ありませんか リリース直前のバグ発覚 テスト設計が「ベテランの勘」依存 テスト終盤でクリティカルな不具合が見つか 仕様の行間を読むテストや過去の障害観点が り、修正と再テスト（リグレッション）でリ 経験者の頭の中にしかなく、品質が属人化し リース予定が大きく狂う ている 開発スピードに追いつかない テストの運用保守が負担 アジャイル等で開発サイクルが高速化する 仕様変更が頻発する中、膨大なテストケース 中、テスト工数が削られ検証が形骸化してい や自動化スクリプトのメンテナンスに追われ く悪循環 手が回らない © DeNA Co., Ltd. 2

私たちの場合 リリース直前にNGで手戻り 判断が「熟練者頼み」になっている リリース予定日を控えストア審査は一発合格 低頻度の倫理観点やガイドライン解釈は経験 したいのにリジェクト、修正・再検証で予定 者の頭の中にしかなく、属人化が深刻 が大幅に狂う スピードと品質のトレードオフ 基準の更新と継承 リリースサイクルを早めるほど検証が形骸化 Apple・Googleの規約や審査OK/NGラインの し、致命的なリスクを見落とす懸念 知識のメンテナンス © DeNA Co., Ltd. 3

ガードレールの徹底 AI推進の絶対条件 ＝ 「他社IP・権利の保護」と「自社ブランドの守護」 攻めと守りを両立する独自のAI利用ガイドラインに沿った強固なガバナンス ・ツールの安全性 社外AIツールの利用規約（学習利用の有無等）に合せて用途を使い分ける ・インプットの保護 IPや個人情報を含むデータの取り扱いは厳格に運用し、基準をクリアしたものだけを利用 ・アウトプットの担保 他社の権利を侵害しないか、「最終判断は必ず人間が行う」プロセスを組み込む © DeNA Co., Ltd. 4

即日完了するための取組 3層のアプローチ 組み合わせることで精度を固める Layer 3：多段検証・統合判定 Layer 2：AIの識別精度向上 Layer 1：形式知化 © DeNA Co., Ltd. 5

即日完了するための工夫 知識への投資サイクルを回す AI向けのデータ加工 「AIへの丸投げ」はしない 「前処理」に投資する 公式ガイドラインやAIモデルの性能差を利用 スプレッドシートやPDFをそのまま投げ込ま するのではなく、約1600件の審査実例や約 ず、AIがコンテキストを正確に把握できるよ 500件の市場炎上事例をベースに、「独自の うにGASを用いて、自動でMarkdown化する リスク基準」に変換してAIに学習させました などの工夫を徹底することで情報のコンテキ ストの解像度があがり、ハルシネーションが 減りました © DeNA Co., Ltd. 6

即日完了するための工夫 多段検証 ＋ 統合判定 統合AI (フィルター処理) AIは量、人は質 1回では拾えないリスクを確実に捕捉するた 「過検出」を許容し、人が最後は判断 見逃しをゼロにするため、一次AIにはあえて め、ハルシネーションと判断のブレを防ぐ 大量のリスクを検知させて、後段のフィル Syncシステムを導入 ターAIが精錬することで人の認知負荷を軽減 🚨 重大リスク検知: 1回でもSランクのリスクが出たら要確認 ⚠ 判断ゆらぎ検知: 低リスクでもAI間で事実認識が割れたら人 AI run 1 AI run 2 にアラート 統合AI 有人判断 AI run 3 © DeNA Co., Ltd. 7

成果 AIと人の役割分担を明確に分業することで 即日検証完了と業務の属人化から脱却を両立 © DeNA Co., Ltd. 指標 / 項目 Before (従来) After (AI導入後) 人が最終確認する検証項目 全て 数件(▲90%以上削減) 検証精度 高い 従来と同等 検証完了のタイミング 平均５営業日 即日検証完了 検証品質の一貫性 属人的 持続的 8

明日からできる３ステップ 「完璧な準備」より「小さく始めてすぐ学ぶ」 AIの進化スピードは速いのでまず「やってみる」が大事 暗黙知の棚卸 小さなデータで 統合判定の から始める AI検証を試す ルールを決める 熟練者の頭の中にある基準 過去のバグ事例や審査NG どこまでAIに任せ、どこか や検証基準を言語化し、ま 事例など、少量のデータを ら人間が最終判断するか、 ずはテキスト化する 使ってAIの反応を見る ガードレールを設定する © DeNA Co., Ltd. 9

おわりに 汎用AIモデルの性能が上がるほど、 最後に差を生むのは「自社の生きたデータ」です © DeNA Co., Ltd. AIが瞬時にドラフトを作り、 自分たちの「得意」を 人がレビューと承認を行う 言語化し、AIを育てる 10

当日頂いたご質問と回答① 参加者のご質問 登壇者の回答 形式知化にコストをかけたと言っていましたが、どういった情 報をどのように形式化されたのでしょうか？ 主に「特にNGになった過去の審査事例」と「ベテランの頭の 中にあった判断基準」を形式化しました。 具体的には、「なぜこれはNGなのか」という理由を過去の事 例から深掘りし、それをAIが理解しやすいようにマークダウン 形式のルールやガイドラインとして言語化・構造化する作業に コストをかけています。 3回runになにか理由はありますか？ 5じゃなく2でもないいい塩梅みたいなものかと思いますが3回 にした理由が知りたいです 最大の理由は「コストと精度のバランス」です。 回数を増やせば比例してAPIの利用コストや処理時間が膨らん でしまうため、実用性とすり合わせ結果精度のバランスが最も 良かったのが私たちの場合「3回」でした。 「自分たちの「得意」を言語化し、AIを育てる」とのことです が、自分たちの得意を言語化することが難しいこともあるかと 思います。言語化をする際の課題点や工夫点などありましたら 教えてください。 まずは既存のデータでAIに判定させ、熟練者の判断と異なる結 果が出た際に「なぜ人間はこれを見抜けたのか？」「AIには何 の情報が足りなかったのか？」を分析します。 この「ズレの分析とルールの追加」を泥臭くトライ＆エラーで 繰り返すことで、自分たちの「得意」をAIへ与え育てました。 © DeNA Co., Ltd. 11

当日頂いたご質問と回答② 参加者のご質問 登壇者の回答 属人化を減らせたと言う話がありましたが、暗黙知を明らかに して言語化する上で工夫したことはありますか？ 「人用の項目書」をそのままAIに渡すのではなく、「AI用の項 目書」へと翻訳・再定義したことです。 アプリ審査では約1300件の実例、倫理チェックでは500件の実 例をベースに、人間が経験則でやっていた「こういう機能があ る場合はここも見る」といった条件分岐を、AIが迷わないよう 専用のプロンプト指示として明確に言語化し直しました。 「AIに学習させた」とはコンテキストエンジニアリングではな く、モデル自体を改善したということでしょうか？ いいえ。モデル自体の改善ではなく、コンテキストエンジニア リングで改善しました。 検証観点（動画用、メタデータ用、倫理用など）に応じて「役 割を細分化した複数のAI」を使い分けることで、汎用LLMから 高い専門精度を引き出しています。 ドキュメントに明記されない暗黙的な仕様はどうやって補完し ていますか？ POCフェーズでの「反復テスト」によって補完しました。 同じサービスに対して何度も人間とAIの並行検証を回し、「人 間ならここは指摘するのにAIはスルーした」という差分（暗黙 の仕様）を徹底的に洗い出し、それをAI用項目書に追記してい く泥臭いチューニングを繰り返しました。 © DeNA Co., Ltd. 12

当日頂いたご質問と回答③ 参加者のご質問 登壇者の回答 一見問題ないワードでも全体の文脈を考慮したリスク検知は考 えられていますか？ はい、考慮しています。具体的には、プロンプト内で直接的な NG表現だけでなく、『間接的表現』『皮肉』などもリスクと して必ず拾うよう明示的に指示を出しています。 そのため、単語自体は無害であっても、文章全体として特定の 対象を貶めていたり、悪意を含む文脈になっていれば、AIがそ れを解釈してアラートを上げます。 倫理チェックで検出するキーワードは元々の自社DBですか？AI 独自の判断も含まれますか？ ハイブリッドです。 自社で過去に炎上した事例などをベースにした「独自のチェッ クリスト」をプロンプトで指定しつつ、AIが事前学習として 持っている一般的な倫理観念に基づく独自のアラートも拾い上 げるようにしています。 ツールの精度に関するテストはどのように行われたのか教えて いただきたいです。 人間の熟練者とAIを並行して走らせる「ミラー検証」を実施し ました。 ミラー検証用の精度評価リストを用いて、AIの「見逃し率」と 「過検出率」をスコア化し、人間と同等の網羅性が出せるま で、同じサービスで何度もテストと項目書の改訂を繰り返しま した。 © DeNA Co., Ltd. 13

当日頂いたご質問と回答④ 参加者のご質問 登壇者の回答 「精度」の定義を教えてください。テスト設計の精度100%とは どういう状態でしょうか？ 我々の定義する精度100%とは、「致命的な見逃しがゼロである 状態」です。 ノイズ（過検出）が発生しても構わないというスタンスで、人 間が最終確認すべき危険箇所を100%網羅できている状態を目標 としています。 人間も完璧ではないのでは？今日の話は人間が完璧前提のよう に感じました。 仰る通りです。 人間は完璧ではありません。また熟練者であっても体調に検証 精度が左右されることもあります。 そのため、「Syncシステム」のような複数AIによる多段検証を 入れています。 人間の見落としやブレをAIの「網羅性」でカバーし、AIのハル シネーションを人間の「文脈理解」や「運用工夫」でカバーす る。互いの不完全さを補い合う関係が、この運用の強みです。 経験値の高いQAエンジニアの役割は「AIの確認作業」に変わ るのでしょうか？ 人間の役割は「リスク環境の変化に応じた最終的なリスクの定 義」と、「AIをより賢くするための項目書・プロンプトの育 成」へと変わりました。 © DeNA Co., Ltd. 14

当日頂いたご質問と回答⑤ 参加者のご質問 登壇者の回答 QAで行うテストと開発で行うテストのレイヤー違いをどう教 えていますか？ AIへの「役割定義」で明確に制御しています。 「あなたはアプリストア審査の統括マネージャーです」「倫理 ・コンプライアンスの専門家です」といったペルソナと独自の 判断軸を与え、複数判定の際に異なった役割を使い分けること で、精度の相互補完をしています。 倫理チェックツールを使うのは開発チームですか？ QAですか？ 「QA」が使用しています。 開発チームにツールを丸投げするのではなく、開発とは独立し たQAが対応することで、品質の客観性を担保します。 前提とするデータの継続的なアップデートはどのように行われ ていますか？ 自社でのアプリ審査リジェクト事例が発生した場合、お客様か らのご意見でリスクの高いお声を頂いた時が基本です。 また、日々の市場調査（他社事例やストア規則の改定、SNS・ ニュースでの炎上事例）を行い、速やかにAIの参照資料へ反映 ・追加するフローを繰り返しています。 5日かかっていたものが即日対応になったことで、サービス全 体で考えた場合の効果は？ 検証が即日で終わるため開発スピード全体が向上し、万が一改 修が必要になっても再確認がスムーズに進むことが、事業側へ の最大の効果になっています。 © DeNA Co., Ltd. 15

© DeNA Co., Ltd. 16