AIと開発プロセスの改善チャレンジ

はじめに

皆さん、こんにちは。DeNA IT本部品質管理部 SWET第一グループのグループリーダーの伊藤です。SWET（SoftWare Engineer In Test）は、品質管理部の中でもテストを起点に開発の生産性や品質の改善・向上を担う、ソフトウェアエンジニアが主体となっているグループです。

DeNAが掲げる「AIオールイン」の取り組みの一環として、SWETでは開発生産性にフォーカスをし、開発プロセスにおけるAIの活用と、それにともなって起きる品質面での課題について、取り組みを行っています。本記事では、SWETで取り組んでいる施策の概要と、その途中経過を紹介します。

本記事を通して、読者の皆さんがDeNAのAI Agentを用いた開発の方向性を理解し、ご自身の組織におけるAIを使った開発のあり方や、その議論の論点を得るきっかけとなれば幸いです。

SWETについての詳しい説明や、過去に取り組んできたことについては別の blog がありますので、そちらをご覧ください。

開発現場へのAI Agentの導入とその課題

今までもAIが人間のコーディングをサポートする技術はありましたが、AI Agentは、サポートにとどまらず、人間に取って代わって主体的にコーディングやテストを実装・実施する能力を備えています。しかし、コーディングやテスト一つ一つのタスクの品質は高いとは言えず、ただ単純に導入しただけでは、 AI Agentのアウトプットの確認と修正に人間の工数を取られ、むしろ生産性が落ちているというケースもあります。開発生産性を改善するためには、この人間が介入するポイントを減らす、つまり、AI Agentが自律的に長期間稼働しつつも、品質問題の発生を極力抑えるような仕組みが必要となってきます。

高品質な状態を保ったまま、いかにAI Agentを稼働させられるか

SWETではこの課題に対して、ソフトウェアエンジニアリングやテスト、静的解析、形式手法などの領域の過去の資産を適合させたり、メンバーそれぞれのケーパビリティを活用したりしながらチャレンジをしています。

SWETのチャレンジ

SWETはソフトウェアエンジニアで構成され、ソフトウェア開発に知見を持つチームですが、メンバは事業部にも所属し、各々のプロダクト開発でAI Agentを活用しています。

その経験をもとにAI Agentの利活用についてディスカッションを行い、上記の目標の設定と、目標を達成するために必要な施策を4つに絞りました。

以下に開発プロセスの全体をPFD[^1]の形で表現しています。その中で現在SWETがチャレンジしている施策が対象とする領域を図示します。

(* 説明の都合上開発の詳細度が高いものになっています。)

図示されたそれぞれの領域について、簡単な説明と現時点での進捗を紹介しますより具体的な技術に関しての説明は後日別の記事を公開いたします。

(1) ソフトウェアメトリクスの探索と活用

この施策では以下の2つの観点からソフトウェアのメトリクスを用いてAI Agentが出力するソフトウェアの品質[^2]を向上させます。

(a) AI Agentに自身が書いたコードのソフトウェアのメトリクスを計測させ、一定基準を下回ったときにリファクタリングをさせるような指示を与えることにより、AI Agentが出力するコード自体の品質が担保されている状態を目指す
(b) 経験則により、AI Agentが品質の高いコードを生成する場合と、そうではない場合があることがわかっている。この違いは元々のコードの設計やアーキテクチャを起因とする可能性があるため、ソフトウェアアーキテクチャに関するメトリクスを計測し、AI Agentが品質の高いコードを生成しやすい状態とは何かを推定する

それぞれについて簡単に紹介します。

(a)の施策

(a)ではAI Agentが出力するコードの品質向上を目指します。例えば以下のようなメトリクス取得と改善をAI Agentのプロンプトに組み込み、品質改善の効果があるかを計測しています。 AI Agentが実装中にメトリクスを取得することを想定しているので、一回の測定にそこまで時間がかからないようなものを選択しています。

メトリクス名	メトリクスの概要	狙い	プロンプトの例	取得できるツールの例
テストカバレッジ	テストで実行されたコード行の割合	リグレッションテスト目的・AIが出力したコードの動作確認	「自分が新規に書いたコードについてxxxというコマンドでカバレッジを計測すること。新規に書いたコードについて、カバレッジがn%以上になるまで、テストを追加すること」など	test tool一般
循環的複雑度	分岐数に基づく制御フローの複雑さ	可読性・保守性の確保、過度な複雑化の抑制、リファクタ対象の抽出	「循環的複雑度をxxxというコマンドで計測し、n以上のものがあったらリファクタリングすること」	gocyclo 、 ESLint など
重複コード率	同一/類似コード片の割合	重複コードの排除 (AIは重複するコードをよく生成する、という経験則から)	「xxxというツールを使って重複コード率を計測し、n以上であればリファクタリングして共通化すること」	similarity など
ミューテーションスコア	ミューテーション解析の結果	AIが生成したテストコードの品質測定	「xxxというツールを使って実装したテストに対してミューテーションスコアを計測する。基準を上回るまでテスト実装を続ける」	stryker , pitest など

基本的には既存ツールを用いてメトリクス収集を行なっていますが、既存ツールが今回のユースケースにあっていないもの(例えば実行速度が遅い、など)については、独自ツールの開発を行っています。独自ツールの開発にもAI Agentを活用し、その開発経験をそれぞれの施策にフィードバックする、という体制になっています。

(b)の施策

AI Agentを用いて開発を行っていると、「AI Agentがうまくコードを生成する場合と、そうではない場合がある」ということに気づくかと思います。 SWETでは、少なくともこの違いを生み出す原因の一部は元々のコードの設計やアーキテクチャではないか、という仮説をたて、この仮説の検証と、どういったアーキテクチャであればよりAI Agentが効率的にコード生成を行えるのか、という検証をしています。

直近では O’REILLYのソフトウェアアーキテクチャメトリクスなどの本を参考に、結合度や複雑度といったメトリクスを計測し、それらとAIが生成するコードを観察しています。 (これらの詳しいメトリクスの説明についてはソフトウェアアーキテクチャメトリクスの本に譲ります。)

(a) ではメトリクスの計測にかかる時間もポイントになってきていましたが、こちらの施策ではそこまで高頻度で取得する必要がないので、実行速度の制限は必要なく、測定に時間がかかる複雑なメトリクスについても取得可能になっています。

(2) モバイル領域でのAI Agentが実施するSmoke Testの研究

モバイルアプリケーション(Android, iOS)開発において、実装を終えたコードをQAする前に、開発者自身で動作確認、つまりSmoke Testを行うことが実質的には必須になっています。現状ではジェスチャーなどの特殊な動作を自動化するのが難しく、開発者が実機上で手動で実施せざるを得ない場合もあります。 AI Agentを用いた開発でもこの点は変わらず、コードの実装自体はAI Agentが行っても、Smoke Testに人の手が入るため、ここが開発のボトルネックになってしまうことが想定されています。

こちらの施策では mobile-mcp などのAI Agentからモバイルアプリケーションを操作できるツールを活用し、 AI Agentが人間が手動で行っているSmoke Testを実施できるような基盤作りを行っています。

(3) レビュー効率化

AIによるコードレビュー支援ツールの導入や、レビュープロセス自体のAIによる最適化を検討し、開発者が品質の高いコードを効率的にレビューできる環境を構築しています。こちらについては以前にblogを公開しましたので、そちらを参照してください。

(4) 仕様トレーサビリティ

仕様は設計・実装・テスト等の多くの工程から参照されます。 SWETでは過去に各仕様にユニークな「仕様ID」を付与し、仕様・実装・テストのトレーサビリティを確保できる仕組みを整備してきました。（参考: 画面仕様書への静的検査器を実装したらたくさんの欠陥を発見できた話）。 AIが実装、レビュー、テストを行うとして、その際にも明確に対象の仕様との関連を認識できる必要があると考えられます。この施策では、既存の仕様IDを用いたトレーサビリティ確保の仕組みを活用し、仕様やコード、テスト項目等を一気通貫してインデックス化し、AIからも仕様のトレーサビリティが認識できるようなインターフェイス(例えばMCP Server)の構築を目指します。

また、仕様IDとの対応が明確なコードほどAIが意図どおりの実装を行う確度が高いという経験則も得られています。 (1.b)とも関わりますが、この経験則についても施策を進めていく中で関連を観測していきたいと考えています。

今後の展望

(1) ~ (4) の施策を簡単にですが紹介しました。いずれも、SWETメンバのAI Agentを用いた開発の経験から生まれた施策です。今後はこちらの施策をそれぞれ進めつつも、それらに対する効果の計測についても考慮していく必要があります。

例えば、(1.a)の施策において、「重複コード率」と「循環複雑度」はそれぞれ独立して使っている分には問題ないかもしれませんが、併せて使うことでお互い矛盾する結果を出力し、Agentがループしたり、トークン使用量が跳ね上がったりすることがあるかもしれません。

この例のように、何かしらの施策を導入したときに、結果的に開発効率や品質が低下してしまうことが容易に起こりうる領域なので、そのことに気がつけるような仕組みを構築していく必要があると考えています。

SWETでは(1) ~ (4)の施策に加え、この点にも挑戦していく予定です。

まとめ

SWETは開発現場で得られた経験則や課題から出発して、SWETの過去の資産やケーパビリティを活かしつつ、 (1)メトリクス活用、(2)モバイル自動テスト、(3)レビュー効率化、(4)仕様トレーサビリティの4施策を推進しています。

この記事ではそれぞれ簡単な紹介にとどまってしまいましが、それぞれの領域の詳細な取り組みについては、また別の記事で紹介をさせていただきたいと考えています。

AI Agentを導入し開発速度を向上させつつも、品質面でも妥協しない開発を目指し、引き続き取り組みを続けていきます。

脚注

[^1] PFDとはProcess Flow Diagramの略。詳しくは SWET Blog を参照
[^2] ここでいう品質とは、ソフトウェアの内部品質を指します。SWETのケーパビリティを効率的に生かすために、最初のステップとしては内部品質を対象とする選択をしています。