生成AI活用への取組〜AIペアプログラマー（GitHub Copilot） PoC実践編

はじめに

アーキテクトチームの長沼です。

先日は生成AI活用への取組の第一弾としてPoC準備についてご紹介しました。
今回は実際にPoCを行ってみた結果についてご紹介したいと思います。

PoCで使用するツールは、開発における生成AIの草分け的存在でもあるGitHub Copilot、そのビジネス向け製品であるGitHub Copilot Business を採用して実施しました。

PoC対象の概要

JDEPでは特性の異なる様々なアプリケーション（以下APL）を開発運用しています。
今回のPoCでは、その中から以下のAPLを開発するチームに協力をお願いしました。

アプリ名	開発言語	概要	開発フェーズ	メンバ数
APL1	Go	APIサービス	リリース済（エンハンスフェーズ）	7
APL2	TypeScript	画面（SPA¹）を持つWebサービス	リリース前（新規開発フェーズ）	7

PoC実施結果

PoCで得られた結果のうち、特徴的だった内容について以降でご紹介していきます。

アンケート結果（定性的な結果）

PoC準備編でもご紹介したアンケートを用いて、次のような結果を得ることができました。
いずれも開発メンバには好印象だったことが分かりました。

質問：開発効率化に効果はありましたか？

実にPoCに参加した90%以上の開発者が「効果がある」と回答しました。この結果から、利用することでほとんどの開発者には良い効果があるといえます。

質問：提案内容は期待に合っていましたか？

横軸が提案に対して期待値に合っていたと感じた割合（0=0% 〜 10=100%）で、縦軸に各割合と回答した人数、を示しています。例えば、提案のうち70%が期待に合っていたと答えた開発者の人数は4人でした。
この結果から、図にも記載している通り、多くの開発者が期待に合った提案が得られたと回答しています。

質問：効果があると思うユースケースを教えて下さい

質問：使ってみて良かった＆悪かった体験を教えて下さい

定性的な結果の最後として、具体的な体験（感想）の一例もご紹介しておきます。
多くの開発者は良い体験を得ることができた一方で、開発者によっては逆に余計なお節介と感じることもあるようです。

良かった体験
- 単純だが記述量が多いような処理や、規則的な処理の記述において記述量が減って楽になった。
- 周辺の情報やコメントを元に雛形が生成されるため、一から記述する手間が減った。
  また提案結果を元に不明点を調べればよいことが多く、（特に曖昧な記憶で実装するようなケースにおいて）一から調べる手間も省力化された（アタリをつけて情報を探すことができるようになった）。
- 単体テストのように規則的な処理を書く際は予測変換の精度が高く便利だった。
- 単純作業が減ったので、本当に時間をかけたいロジックやアーキテクチャの思考により多くの時間をかけることができるようになった。
悪かった体験
- 補完が出てくるのを邪魔に感じるときがあった。

定量的な結果

質問：　利用により効率化できた時間（週平均）は体感でどのくらいですか？

同じくアンケートにおいて、開発者にGitHub Copilot Businessを利用することによって、体感でどの程度の時間が効率化できたかを質問しました。その結果は、以下のようになりました。

効率化できる時間（分）	人数(人)
10	1
20	1
30	2
60	3
90	1
100	1
120	3
180	2

上記を集計すると今回のPoCでは、開発者の体感で、一人あたり週平均として約84分（約5時間/月）くらいの時間が効率化（コード記述にかける時間を省力化）できたという結果が得られました。

テレメトリデータ： Acceptance Rateほか

アンケートによる方法以外として、Acceptance Rate（提案されたコードをどの程度採用したか）等の情報を利用することもできます。

項目	値
(A) Total Shown	約11,700 回
(B) Total Accepts	3,149 回
(C) Acceptance Rates (= B/A)	27.0%
(D) Lines of Code Accepted	4,587 lines

PoC期間中（約３週間）の Acceptance Rate は 27% （約11,700回の提案のうち3,149回採用）となりました。30%前後が一般的とのことですので、初利用かつAcceptance Rateを向上させる工夫・施策なしに利用した値としては良好な結果が得られたのではないかと考えています。

費用対効果に対する考察

これらの定量結果を用いると、費用対効果についても幾つかの仮説を立てることができます。
なお計算においては、以下の数字も用いて計算しています。

今回のPoC期間: 3週間（15日）
1ヶ月の稼働日: 20日

まず効果について、GitHub Copilot Businessを用いることによって効率化（省力化）できた時間は、例えば以下いずれかのように見積ることができます。

なお、α・βは開発状況などを考慮した係数（定数）となります。
αは1回の採用で効率化できる平均時間を意味しています。例えば開発者にヒアリングしてみたり、幾つかの利用時に計測したりすることで設定することができます。
βは、生産性を測る指標として使われることが多い、１ヶ月あたりの開発量（line）の逆数に起因した定数を意味しています。ただし生産性を測る指標は通常、テストや設計も含まれますので、コード記述のみを対象とする今回のケースには直接適用できない点は注意が必要です。

いずれにしても上記のように算出される時間を、GitHub Copilot Businessを使用しなかった場合に比べ、早くプロダクトをリリースできると見ることができます。もしくは別のよりクリエイティブな時間に充てることができるようになったと見ることができます。
また効果を金額に換算したい場合は、これらいずれかの効果時間に対して開発者一人あたりの平均時間単価をかけることで変換もできます。

まとめ

これらのPoC結果からJDEPの開発では、開発者体験の観点と、費用対効果の観点のいずれにおいても有用であることを確認できました。
そこでJDEPでは、GitHub Copilot Business（Businessとする理由は後述補足参照）を採用することとし開発を進めています。今後、GitHub Copilot Businessを利用した開発を進めてみて、さらに分かったことや活用例などあれば別の機会にご紹介したいと思います。

最後となりましたが、JCBでは我々と一緒に働きたいという人材を募集しています。詳しい募集要項等については採用ページをご覧下さい。

補足: 利用における注意点とJDEP開発での対応

生成AI由来の技術は、効率化の観点以外に、これまで問題にならなかった新たな課題へも対処が必要となります。
これら課題について、JDEPでは以下のように考察したうえで、これが可能である GitHub Copilot Business を採用することとしました。
今後もリスク・課題を適切に見極め・対処したうえで新しい技術を積極的に採用していきたいと考えています。

課題	概要	JDEPでの主な対応
正確性	提案内容が必ず正確とは限らない	コードマージ時のレビューや各種テストにて正確性を担保
機密情報の扱い	機密情報が外部に漏洩する	・利用環境を限定し業務情報が存在しない（開発データしか存在しない）環境/APLでの利用・サービス側の規約/設定として漏洩・再利用されないことを確認
他者権利侵害	提案内容を採用した結果、他者の権利侵害が発生する	・サービス側の設定として権利侵害発生を低減する設定の有効化を実施・万が一に備え、リスク受容可能なAPL開発のみへ適用
自社権利確保	提案内容を採用した結果、自社権利の喪失する	規約にて提案内容に対してサービス提供者側が所有権を主張しないことを確認
法規制	各国・地域で求められる生成AI由来の法律へ対応する	- (各法規制に対して個別に考察のうえ対処)