ソフトウェア品質でみるDeNAのAI導入とその効果

ソフトウェア品質でみるDeNAのAI 導入とその効果 株式会社ディー・エヌ・エー 2026年07月22日 AI DevEX Conference IT本部エンジニアリング室開発デザイングループ 伊藤 瑛 © DeNA Co., Ltd. 1

目次 1 会社説明 / はじめに 2 計測したデータの紹介 3 活動量とテストに関する分析 4 今後について 5 終わりに © DeNA Co., Ltd. 2

01 会社紹介 / はじめに © DeNA Co., Ltd. 3

沿革 ※配信元：任天堂株式会社 1999 インターネット オークション事業で創業 2018 タクシーアプリ 『タクベル(『MOV』)』を リリース 2006 モバイルSNS 「モバゲータウン」 開始 2022 ヘルスケア領域(2014年参入) に加え、メディカル領域 参入 2011 2013 2015 任天堂との業務・資本提携 ライブコミュニティ事業開始 プロ野球参入 プロバスケットボールクラブの承継(2018年) Jリーグクラブへ経営参画(2021年) 2024 「Pokémon Trading Card Game Pocket」リリース 2025 2026 培われたノウハウ／ 組織を活かし 「AIイノベーション事業」 本格開始 「BASEGATE横浜関内」グランドオープン "Kawasaki Arena-City Project"2030年開業予定 （2020年JapanTaxiとの事業統合によ り『GO』誕生） ※配信元：株式会社ポケモン © DeNA Co., Ltd. 4 4

事業ポートフォリオ ゲーム スポーツ・スマートシティ ライブコミュニティ ヘルスケア・メディカル 新領域・その他 エンタメ新領域（アニメ／グッズ等） AIイノベーション ベンチャー投資 © DeNA Co., Ltd. 5

AIオールイン 「全従業員がAIを使いこなすAIネイティブ化を 含め、全員でこの変革に挑む」 1. 2. 3. © DeNA Co., Ltd. 全社の生産性向上： AIを使って社内のあらゆる業務を 効率化し、従業員一人ひとりの生産性を劇的に高めま す。 既存事業の競争力強化： ゲーム、スポーツ、ライブコミュ ニティ、ヘルスケア/メディカルなど、DeNAの既存事業の 価値を、AIの力でさらに高めていきます。 AIによる新規事業の創出： AIを核とした、今までにない 新しいサービスや事業を生み出していきます。 6

自己紹介 ● 伊藤 瑛 ● DeNAエンジニアリング室開発デザイングループ グループマネージャー (SWETと呼ばれていたところ) ● Go, TypeScriptなどを中心に、Software Testやその周辺領域が好きです ● Web系全般が守備範囲 © DeNA Co., Ltd. 7

本日のテーマ ● AI オールインの宣言から 1 年以上が経ち、開発現場には Cursor, Claude (Code), Copilot, Devin などのAI ツールが浸透した ● それらが開発現場にどのような影響を与えたのか、主にテストの観点で 定量的なデータから考察していく ● DORA2025(*)の結果と近い示唆が得られた 「AI はチームを修正するのではなく、すでに存在するものを増幅するのです。優れたチームは AI を活用して、さらに優れた、より効率的なチームになります。」 ● この結果を元に、今後、我々のチームで開発現場でどうAIと向き合っていくのかを 考える * https://cloud.google.com/blog/ja/products/ai-machine-learning/announcing-the-2025-dora-report?hl=ja © DeNA Co., Ltd. 8

テストに関する注意 ● 以降の分析は、開発者観点から分析したものになります ● 「テスト」という言葉を使う時には、特に断りが無い限りソフトウェアで自動実行 される「自動テスト」のことを指すこととします ● © DeNA Co., Ltd. QAフェイズなどで行われる「手動テスト」は今回の話題の中心とはしません 9

02 計測したデータの紹介 © DeNA Co., Ltd. 10

データソースについて ① AI ツールのメトリクス ② Githubの活動 ③ QAフェイズ不具合検知情報 ツール標準で備わっているテレメトリ などから、各種usageを集計してる。 以下が代表的なデータ: OSS (Apache DevLake)を活用し、 Githubからデータを収集。 CommitやPRの情報、開発に関する活 動量を習得した。 開発プロセスの中のQAフェイズで 発見された不具合のデータ (本番障害ではない）。 Github Copilot 提案行数 / 受容行数 / インタラクション数 など Apache DevLake自体は多様なデータ ソースと連携できるが、今回は、 Githubのデータのみを用いている。 不具合検知数の週次推移、バグ密度、 リオープン率などを計測。 品質の代理指標として利用。 Cursor 編集行数 / Apply, Accept, Reject 履歴 など Claude Code 編集行数 など © DeNA Co., Ltd. 11

データの規模感 ● ① AI ツールの利用: 5 ツール（Cursor / Copilot / Claude Code / Gemini / Devin）の テレメトリ ○ ● ● 最古は Cursor の 2025-04 〜 ② GitHub の活動（DevLake）: ○ 2024 年〜 ○ 4973 リポジトリ／88 万コミット／38 万 PR (DeNAの一部レポジトリ) ③ QA フェイズ不具合検知情報: ○ 2024-11 〜 ○ 45 プロジェクト／報告バグ 延べ 約 1.9 万件 いずれのソースでもデータの全量が収集できているわけではない © DeNA Co., Ltd. 12

データソース① AIツールのメトリクス ● 各 AI ツールのテレメトリから利用状況を取得 ● ツールによって蓄積開始の時期が異なる ○ Cursor 2025-04 ~ / Copilot 2025-10 ~ / ClaudeCode 2025-12 ~ / Devin 2025-10 / Gemini CLI 2025-12 ~ ● (時期の関係上) そこまでデータが蓄積できて いない © DeNA Co., Ltd. 13

データソース② GitHubの活動 (DevLake) ● Apache DevLake（OSS の開発データ分 析基盤）で GitHubからコミット/PR/レ ビュー等の情報を収集 ● DORA メトリクスや PR 指標を標準で算 出できる ● © DeNA Co., Ltd. 本発表の「活動量」の主データ源 14

Apache DevLake(*) とは ● OSS の開発データプラットフォーム。DevOps ツールに散在するデータを取り込み・ 分析・可視化し、エンジニアリングの改善に使う ● 連携先は幅広い: GitHub / GitLab / Bitbucket / Jira / Jenkins / GitHub Actions / GitLab CI など ○ ● 今回は Github のみと連携 標準で DORA メトリクス（デプロイ頻度・変更のリードタイム・変更失敗率・ MTTR）やスループットを算出 (*) https://devlake.apache.org/ © DeNA Co., Ltd. 15

DevLakeの展開 (DeNAでの運用) ● GitHub App をgithubのorgに install するだけ でデータ収集が始まる仕組みを整備 ● 事業本部ごとに許可を得て、管理者権限で一斉にデータ収集 ○ 現場のエンジニアの作業は 0 ● 横断で簡易に活動量データが揃う ● DevLake は標準で Grafana の dashboard を備えているが、今回の分析を行う際に は、一度 BQ に export して、他のデータソースと結合して分析を行っている © DeNA Co., Ltd. 16

DevLakeで取れるデータの例 PRにどれくらいのテストコード が含まれるのかの比率 © DeNA Co., Ltd. PRがマージされるまでの時間 (p75) 17

データソース ③ QAフェイズ不具合検知情報 ● 品質管理部がプロダクトの QA結果を共 通フォーマットでまとめたレポート ○ DeNAでは「案件」という単位でQA を行う ○ 1案件 = 1 ~ n story (事業部により違う) ● 不具合検知数・バグ密度（検知数÷案件 数）・リオープン率などを計測 ● 変更失敗率などの直接の代替ではない が、開発プロセスにおける品質の代理指 標として利用 © DeNA Co., Ltd. 18

「活動量」とは何か（用語の定義） ● 本発表の「活動量」＝ コミット数・作成 PR 数などの、物的な産出量 ○ ● 増えた／減ったが機械的に数えられるものを指す 価値や品質そのものではない（速い・多い＝良い、ではない） ○ (外部品質についはてQAフェイズの情報で一部代理) ● 「生産性」という言葉はここでは使わず「活動量」と呼ぶ ● 示すのは「傾向」: 相関・因果を主張するものではない ○ 全 DeNA のデータを収集できているわけではない。 事業部によっては収集ができていない。 あくまで、「今収集できていることから考察できること」という位置付け © DeNA Co., Ltd. 19

データ収集に際して ● この計測は横断で行っているが、 集めた数値は、個人・チームの評価には一切使わない ● それを組織で合意した上で実施している ● 数値の目的化を防ぐ © DeNA Co., Ltd. 20

03 活動量とテストに関する分析 © DeNA Co., Ltd. 21

活動量は大きく増えた コミット数 - 約2.05倍 作成PR数 - 約2.49倍 開発者数はわずかな増加(約1.17倍) © DeNA Co., Ltd. 22

伸びは事業部で差がある (事業部をいくつか抽出して紹介) コミット数の倍率 (2024年1月 ~ 3月 ->直近3ヶ月) © DeNA Co., Ltd. PR数の倍率 (2024年1月 ~ 3月 ->直近3ヶ月) 23

総論: 質をコントロールしつつ、活動量自体は増やせている ● 活動量（コミット・PR）は倍増した ● それでも QA バグ密度（事業部の中央値） は ほぼ横ばい（3.9 → 4.3） ○ 事業部により 改善も悪化もある （一律に悪化してはいない) ● 活動量の急増が、外形的な品質を一律に 崩したわけではない © DeNA Co., Ltd. 24

PRは「大きく速く」 ● PR あたりの変更行数 ○ 中央値はほぼ横ばい（数十行）だ が、大型 PR （p75）が再拡大 ● 2024 → 2025 前半はむしろ縮小 → 2025 後半（エージェント普及期）に再拡大 ● AI が大きな変更を一度に出すように なったのでは？ ● 「何が」PRのサイズを大きくしている のかを分析する © DeNA Co., Ltd. 25

テストもドキュメントも「量」と「比率」は増えている ● 変更に占めるテスト・ドキュメントの比 率（per-PR 平均） ● ○ テスト比率は 8〜12% → 約20% ○ ドキュメント比率も 5%→ 約15% テストも文書も量・比率が増えた ○ SDD (Spec Driven Development) の普及も示唆 ● © DeNA Co., Ltd. テストが増えたrepositoryを分析する 26

活動量が伸びた repository(*) はテスト比率も上がっている傾向 ● 活動量が伸びたrepositoryのうち、約 80% でテスト比率も上昇 ＝ 活動量が伸びたrepositoryの多くは、テストも一緒に増やしている傾向 ● 「テストを増やすと活動量の増加には何か関連があるのでは？」 という仮説を立て活動量もテストも伸びたrepositoryを以降深掘りしていく *規模やサービスの特性(繁忙期など)によって、大きく変化が出る数値。以降の分析では、規模、 開発者、コミット頻度など、極力同質なものを抽出して比較している 人数の増減もあるので、「アクティブな開発者一人当たり」の活動量の増減をみている © DeNA Co., Ltd. 27

だが「テスト比率↑」がすべて活動量↑ではない ● 活動量↑のrepositoryでは、約80%がテスト 比率も上昇 ● だが、活動量↑ではないrepositoryでも約 46%がテスト比率↑ = 「テスト比率↑」は活動量↑のrepository に限らない ● 活動量が上がったrepository 活動量が上がらなかったrepository 2群にはなんの違いがあるのかを調べていく © DeNA Co., Ltd. 28

❌ 仮説: AI toolの利用率 ● 「AIを使っている率が高いほど活動量が 多い or 少ない」という仮説 ● 両群とも 2026 には 7〜9 割超が AI を利用 ● むしろテスト比率だけ伸びた側の方が 高いこともある 「AI をどれだけ使ったか」は両者をわ けない © DeNA Co., Ltd. 29

❌ 仮説: ハーネス・テスト戦略の有無 「適切なAIへの指示ができている or いない」という仮説 ● skillsやテスト戦略の有無が活動量に反映されている可能性がある。repositoryをサン プリングして調査 活動量も伸びたチームの例 ● ● ● Lintルールの設定 コミット時hookでのテスト規約の強制適用 無検証のmockの利用を禁止 活動量が伸びなかったチームの例 ● ● ● ● Lintルールの設定 AIに対するrulesでLint, テストの規約を明記 TDDの強制 mockのルール明記 どちらのrepositoryにもAI向けのハーネス・テスト戦略は存在している。 量・質ともに差分はあまり発見できなかった © DeNA Co., Ltd. 30

❓仮説: AIが生成するテストコード特有の問題が発生している ● 「AIが生成するテストコードは質が低い」という仮説 例) mockの乱用, 不適切なassertionなど ● 同様にrepositoryをサンプリングして調査 ● mockの乱用問題はどちらの群にも発見されたが... ○ 依存している言語、フレームワークなどの慣習に依存している 今回の切り口 (活動量 x テスト) では言えることは(今のところ)無い © DeNA Co., Ltd. 31

仮説: 「AI 以前からテストを書いていたかどうか」 ● 「初期(2024 年, AI(Agent)以 前）で既にテストを書いていた 2024 年初（入口・AI エージェント以前）の PR に含まれるテスト比率（各群の中央値） か」という仮説 ● 最初からテストを書いていた チームの方が、その後 活動量が 伸びやすい傾向 ● 最初はテストが無く、後から （おそらく AI で）書くように なった側は、伸びにくい © DeNA Co., Ltd. 32

断定はできていない ● 例外は両方向にある ○ 入口でテストがあっても伸びない repo・ほぼ無くても伸びたrepo ● 現時点で言えるのは DeNA社内で見えている「傾向」 のレベル ● 具体的にどういう関連があるのかは、まだ調べている & データの規模を増やして調べる必要がある ● 直感的には「テスト」は一側面で、それ以外の開発文化の側面も関連しているよう に思う © DeNA Co., Ltd. 33

後からテストを増やせば良いか？ ● プロジェクトの後期からテストを増や すのは有効か？ ● データ的にはどちらとも言えない ● テスト比率を最速・最多で増やした チームでも(右図)初期から書いていなけ れば、活動量としては伸びていない ● © DeNA Co., Ltd. ここはまだ未検証 34

DORA2025のサマリ 「AI はチームを修正するのではなく、すでに存在するものを増幅するのです。優れたチー ムは AI を活用して、さらに優れた、より効率的なチームになります。一方、苦戦してい るチームでは、AI が既存の問題を浮き彫りにして悪化させるだけだと感じるでしょう。」 今回の結果はDORA2025をなぞるようになった https://cloud.google.com/blog/ja/products/ai-machine-learning/announcing-the-2025-dora-report?hl=ja © DeNA Co., Ltd. 35

• https://cloud.google.com/blog/ja/products/ai-machine-learning/announcing-the-2025-dora-report?hl=ja

考察 ● なぜ後からAIにテストを書かせてもうまくいかないのか？ ○ 本質的な原因はDORA2025が言うように 「優れたチーム」と「苦戦しているチーム」 ● あえて、「後からテストを書く」ことの難しさについて、 SETの経験則でいくつか考察をしていく © DeNA Co., Ltd. 36

最初からテストを書く vs 後からテストを書く ● そもそも後からテストを書くとどうなるのか？ 最初からテストを書くケース ● ● テストをかけるようにするために ソフトウェアアーキテクチャにテスト観点 (DI, レイヤ設計 etc)を組み込む CIの活用など、自動テスト前提の開発プロセ スになっている 後からテストを書くケース ● ● (単体)テストが書けない実装になっていること がある 振る舞いを担保するための結合度の高いテス トを書きつつ、単体テストを書けるようにす るためのリファクタを行う テストを書くための下準備が必要になることが多い 下準備自体が難しい © DeNA Co., Ltd. 37

後からテストを書く場合の典型的なプロセス ① テスト分析 ② 結合度の高いテストの実装 ③ リファクタ & テスト実装 リファクタは必要か? 必要だとすると、ど こをどうリファクタすると良いか？ の分析を行う ① の分析を元に、結合テストを実装。 flaky(*3) になっていないか、実装難易 度は高くないか、Coverageなどうなっ ているか、などの観点から計測を行う ②のガードレールを元に、リファクタ を行う。 リファクタが必要だった場合、 費用対効果が高く持続性がある(*1) 結合 テストを書くために必要な要素技術を選 定・開発(*2) する リファクタが完了した部分から単体テ ストを実装していく。 *3) 不安定なテストのこと *1) 結合度の高いテストは不安定(flakyなテスト)にな りやすく、不安定なテストは無視されやすい。ここ では結合度は高つつ、安定的に運用できるようなテ ストを目指す。 *2) 上記の目標を達成するために、テストツールを 案件専用に開発することがある。例えば、テスト環 境分離のためのツール、テストフィクスチャ管理 ツールなど。 ①と②を繰り返しながら最適なテスト戦略を組み立てていく © DeNA Co., Ltd. 38

AIでテストを（後から）書かせる ● AIだからダメ、ということでは無い ● 後からプロダクトにテストコードを導入させる場合には、 既存の”ベストプラクティス”やskillsなどを盲信せず、現状のコードに合わせた 分析と実装をさせることが必要 (= ①のテスト分析をさせて、その妥当性を検証してからテストを書かせよう) ● AIはコードの分析能力も高いので、十分この作業を行わせることができる ○ ● © DeNA Co., Ltd. テストを書く際にもちゃんとplanを立てよう 正解は一つでは無いので、複数パターン出させて比較するのがおすすめ 39

この章のまとめ ● AI 以前からテスト文化を持っていたチームは AI 時代に適合しやすかった 可能性がある ○ 活動量も向上し、テスト比率も向上し、尚且つ QA レポート上でのバグ数も削 減できたプロダクトもある ○ ● DORA 2025の結果が部分的に再現できた “後からテストを書かせる時” は分析をしてPlanを立てる。Planの時点での妥当性を 検証する。 ○ © DeNA Co., Ltd. プラクティスをそのまま適用、は効果がでない 40

04 今後について © DeNA Co., Ltd. 41

今後やること ① テスト文化の観点から ● ● © DeNA Co., Ltd. テストとAIを起点とした開発文化の 浸透 AIを利用したテスト技術の発展 ② 分析の観点から ● さらなる分析の推進 ● データを開発現場で活用できるように する 42

開発文化の浸透 ● テストに関わらず、開発文化の浸透がAIを開発に活用するための鍵になっている = skills配って終わり、ではうまくいかない ● 「テスト」と「計測」を起点として、開発チーム自身が開発プロセスを改善できる ようにしていく (今まで通り) ● © DeNA Co., Ltd. 育成は今後も重要。ただ、育成もAIを前提に、かつAIを活用していく。 43

開発デザインでも新人研修のカリキュラムを一部担当 ● 各開発プロセスにおける、AIが出力するアウトプットの判断軸を網羅しつつ 実際に手を動かしてみて、その効果を体験することを目的とした研修 © DeNA Co., Ltd. 44

SET AI Agent ● AI社員の取り組み (Dekopon kun) ● テストのナレッジを徐々に教えている ● 将来的には我々に代わり、テストの壁打 ちをしてくれるようにしたい © DeNA Co., Ltd. 45

AIを利用したテスト技術の発展 ● AIを利用することにより今まで難しかったテスト技術を実現できるようになっている ● 開発コストを抑えられるようになったので、今まで実現が難しかったテスト技術の 開発が可能になり、PoCが実現できている ○ (Stateful) Property Based Testing ○ ミューテーション解析 © DeNA Co., Ltd. 46

ミューテーション解析 ● テストの品質を測定する手法 ● コードに意図的な不具合(ミュータント)を入れて、テストが失敗するかを見る。 ○ 🙆失敗すれば killed ○ 🙅失敗しなければ survived ● Coverageレベルで確認できるのはテストコードがそこを通ったか。 ● ミューテーション解析では、そのテストが不具合を発見できる能力があるかどうか を確認できる。 © DeNA Co., Ltd. 47

2つの側面からのPoC ① 伝統的なミューテーション解析 ② AIを利用したミューテーション解析 ● ASTを分析して機械的に不具合を埋め 込む ● LLMが与えられた文脈から不具合を埋 め込む ● diff + callgraphを見て、PRに影響が ある範囲だけ不具合を埋め込むことに より、現実的な実行時間でミューテー ション解析を実行できるようにする ● 自然言語で指定する形で不具合を埋め こめる https://www.docswell.com/s/DeNA_ Tech/5MQ1G2-2026-03-23-132421#p1 © DeNA Co., Ltd. 48

• https://www.docswell.com/s/DeNA_Tech/5MQ1G2-2026-03-23-132421#p1

さらなる分析の推進 ● まだ分析できていないデータが大量にある ○ ● e.g. PR レビュー, CICD, JIRAのチケット 次の分析課題はレビュー ○ 開発デザイングループでAI Reviewのツールをいくつか運用している それらの影響・効果を分析中 ● © DeNA Co., Ltd. 人間のレビューとAIのレビューの比較などを行っている 49

分析を現場に届けるプラットフォーム ● DevLake, AIツールのメトリクスなどのデータを一度きりの調査で終わらせない ● 現場のエンジニアが、自分のチーム・repository の文脈で使えて、本当の意味で開発 の生産性向上に繋げられる形 に整備する ● AI Agent によるデータ分析プラットフォームとして展開 ○ © DeNA Co., Ltd. Slackで仮説を呟くとAI社員がグラフを描画して送ってくれる 50

05 終わりに © DeNA Co., Ltd. 51 51

We’re Hiring !!!! ● DeNA 開発デザイングループでは一緒に開発生産性領域に挑戦してくれる人を 募集しています!!! ● ● © DeNA Co., Ltd. 業務の例 ○ 分析プラットフォームの構築・運用 ○ 生産性データの分析 ○ 開発生産性向上施策の推進 興味がありましたら伊藤まで！ 52

まとめ ● 活動量は、約2倍に増えた。総論として、品質も落ちていない ● AI 以前からチームにあった 「開発文化」 によって、AI の活用に差が出る可能性が ある ● ○ DORA2025と同じ結果 ○ 表面的なプラクティスではこの差は埋まらない 今後はテストとAIを起点にした開発文化の浸透とテスト技術自体の発展 併せて分析を詳細化し、現場に提供していく © DeNA Co., Ltd. 53

© DeNA Co., Ltd. 54