---
title: ソフトウェア品質でみるDeNAのAI導入とその効果
tags: 
author: [DeNA_Tech](https://image.docswell.com/user/DeNA_Tech)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/KJ4WQ2WZ71.jpg?width=480
description: Findy様 AI DevEX Conference 2026( https://dev-productivity-con.findy-code.io/aidevex2026 )で発表した資料となります。
published: July 27, 26
canonical: https://image.docswell.com/s/DeNA_Tech/ZE1Q11-2026-07-27-182241
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/KJ4WQ2WZ71.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/LE1YPMYD7G.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GEWG23G8J2.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/47ZLDVL9J3.jpg)

沿革
※配信元：任天堂株式会社
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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/YJ6W15WDJV.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GJ5M4YM8J4.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LE3WG5WGE5.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/8EDK1DKN7G.jpg)

本日のテーマ
●
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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/V7PKQXKNJ8.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/2JVV5LVYJQ.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/5EGL6XLWJL.jpg)

データソースについて
① 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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4JQY48YQ7P.jpg)

データの規模感
●
① 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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/K74WQ2WYE1.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LJ1YPMYNEG.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/GJWG231M72.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4EZLDVPM73.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/Y76W15M57V.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/G75M4YZG74.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/9J29VGRDER.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/DEY43VDMJM.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/VJNYVM6378.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/YE9P6NLPJ3.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/GE8DZKXXED.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/LELMDZ8N7R.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/4JMYPV6QJW.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/PJR912PK79.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/PEXQYD35JX.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/3EK93XYRED.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/L73WG59G75.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/87DK1DGNJG.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/VJPKQX3NE8.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/2EVV5L4YEQ.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/57GL6X1WEL.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/4EQY48DQJP.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/KJ4WQ2ZY71.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/LE1YPMRN7G.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/GEWG23YMJ2.jpg)

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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/47ZLDVXMJ3.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/YJ6W1545JV.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/GJ5M4YQGJ4.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/9E29VGPD7R.jpg)

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


# Page. 42

![Page Image](https://bcdn.docswell.com/page/D7Y43V5MEM.jpg)

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


# Page. 43

![Page Image](https://bcdn.docswell.com/page/VENYVMN3J8.jpg)

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


# Page. 44

![Page Image](https://bcdn.docswell.com/page/Y79P6NRPE3.jpg)

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


# Page. 45

![Page Image](https://bcdn.docswell.com/page/G78DZKWX7D.jpg)

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


# Page. 46

![Page Image](https://bcdn.docswell.com/page/L7LMDZNNJR.jpg)

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


# Page. 47

![Page Image](https://bcdn.docswell.com/page/4EMYPVXQEW.jpg)

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


# Page. 48

![Page Image](https://bcdn.docswell.com/page/PER912NKJ9.jpg)

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


# Page. 49

![Page Image](https://bcdn.docswell.com/page/P7XQYDN5EX.jpg)

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


# Page. 50

![Page Image](https://bcdn.docswell.com/page/37K93XNR7D.jpg)

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


# Page. 51

![Page Image](https://bcdn.docswell.com/page/LJ3WG5VGJ5.jpg)

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


# Page. 52

![Page Image](https://bcdn.docswell.com/page/8JDK1D8NEG.jpg)

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


# Page. 53

![Page Image](https://bcdn.docswell.com/page/VEPKQX8N78.jpg)

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


# Page. 54

![Page Image](https://bcdn.docswell.com/page/27VV5LNY7Q.jpg)

© DeNA Co., Ltd.
54