1．はじめに

コード生成ツールは，ソフトウェア開発におけるソースコードの作成を支援するツールである．近年では，GitHub Copilot[1]やAmazon CodeWhisperer[2]など，生成AIを活用することでユーザーの期待に近いレベルのソースコードを生成できるツールが登場している．

全社導入したことを公開している企業も増えており，効果についても肯定的な意見の記述も多い[3]．

一方，G7広島サミットにて国際的なガバナンスが討議されるなど，生成AIのリスクについてとりあげる記事も増えている[4]．このため，生成AIの利用を原則禁止し，業界における方向性が安定するまで，利用範囲を絞り許可を与えていく運用を行っている企業もすくなくない[5]．

こうした状況下において，組織として導入判断を下すためには次の2つの課題に対しての解決策を講じる必要がある．

• 導入リスクの評価
• 導入効果の評価

本稿では，これらの評価方法を提案し，実際に計測した結果をもとに有効性を説明する．

2．GitHub Copilot

2023年4月時点において，正式版が公開されているコード生成ツールのうちGoogle Trendsが上位であったGitHub Copilotを選択した．

GitHub Copilotは，GitHub社が提供するコード生成ツールであり，統合開発環境（IDE）の拡張機能として提供されている．IDE上に拡張機能をセットアップし設定することで使用が可能となる．GitHub Copilotには2つの有料サブスクリプションが提供されているが，本稿では企業向けのGitHub Copilot for Businessを対象とした．

2.1　使い方

GitHub Copilotを使用する場合，従来のIDE上での開発操作を変える必要はない．コード記述操作中に改行などのタイミングで，次行以降の候補を表示する．候補を採用する場合はタブキー，採用しない場合は別の操作を行うことで候補を削除することができる．既存開発操作との親和性が高いため，ツール習熟のための学習時間はほぼ不要である．

公式ドキュメントには生成対象プログラミング言語の指定はない．試行段階でJava，C，C++，Fortran，JavaScript，HTML，CSS，Shell，Dockerfile, 各種定義ファイル（JSON, XML），Markdownドキュメントの生成を確認した．

2.2　生成AI

GitHub Copilotに使用されているCodexモデルは，OpenAI社の生成AIをベースとしている．このためGitHub Copilotを組織内で使用する場合，リスクに対して正しく対処していく必要がある．

3．導入リスクの評価

導入リスクの定量化を行うために，既存のガイドラインを参考に方針を策定した．すでに東京都など公共公益団体では生成AI導入のガイドラインを公開している[6]．これらのガイドラインでは，自組織におけるユースケースを規定し，どのようにリスクを低減させるかの手段が記述されている．

これらのガイドにならい，本稿における方針として次のような導入リスク評価を実施することとした．

• 自組織におけるツールのユースケースを規定
• リスク低減方法の策定

3.1　ユースケースの規定

コード生成ツールの利用局面は，ソフトウェア開発における実装フェーズに限定される．しかしGitHub Copilotは，IDE上で作成するすべてが生成対象となる（候補がない場合は表示されない）．よって，今回の対象は，開発フェーズにおける成果物の作成，とした．

なお，後述のサンプル開発の前提とする成果物の種類は次のとおり．

• HTML
• CSS
• 画像イメージ
• コード

3.2　リスク低減方法の策定

自組織で運用されている通常のリスク管理プロセスは，次のとおり．

1. リスクの識別（Identification）
2. リスクの評価（Assessment）
3. リスクの対処（Migration）
4. リスクの監視（Monitoring）

対象としたユースケースに対し，順番に対処した．

3.2.1　リスクの識別

GitHub Copilot使用時に考慮すべきリスクを洗い出すために，一般的な生成AIに対するリスクをベースにリスク評価検討要否の判断を行った．

• セキュリティリスク：不要
  コード生成ツール固有のリスクではない．既存の品質管理プロセスにて対応する．
• 著作権侵害のリスク：不要
  既存対応に加え，GitHub Copilot for BusinessのOSS類似コード提案禁止設定もあわせて行う．
• 品質管理のリスク：不要
  コード生成ツール出力後は，ユーザーの責任下で品質管理プロセスを行う．
• バイアスのリスク：要
  過去のプロジェクトでも潜在的バイアスへの対処は明文化されたルールに則ることなく運用している場合があったため新規検討が必要である．
• コストのリスク：要
  ユーザー候補による試行を行い，リスク発生の可能性を評価する必要がある．

3.2.2　リスクの評価

コストのリスクは，実運用に近い環境での試行を行うことで評価可能であるが，バイアスのリスクについては，改めて検討が必要である．よって，生成AI使用することで発生する潜在的バイアスを列挙した[7][8]．

• ジェンダーバイアス
• 文化的バイアス
• 言語的バイアス
• 技術的バイアス
• 人種的バイアス

これらのうち技術的バイアスについては，既存の品質管理プロセスでも対応可能であるが，評価方法を今後も継続的維持する可能性を踏まえ，すべてのバイアスを前提とした．

そして成果物の種類ごとに，各潜在的バイアスが発生するケースを洗い出し，チェックリストを作成した．

3.2.3　リスクの対処と監視

潜在的バイアスチェックは，過去のプロジェクトの一部では暗黙ルールとして運用していた．通常のシステム開発業務では，潜在的バイアスチェックリスト（図1）を品質管理プロセスに組み込み，全成果物に対して違反がないことを合格基準としてプロジェクト計画書に明記する方法を提案する．

本稿での検証作業時の導入リスク評価は，後述のサンプル開発を実施し，作成された成果物に対して合格率を計測した．

4.　導入効果の評価

導入効果については図2に示す方法を提案する．

4.1　参加者

2023年7月のうち2日間導入効果の評価に参加可能なWebアプリケーション開発スキルを持つメンバーを公募し，12名が参加した．参加者の経験や保有スキルを均一化することは不可能であるため，ABテストを応用し，図2に示すとおり2つのグループに分割した．分割方法は，参加申込順で行った．

自組織内での評価指標は実際の作業時間単価（円／時）を用いたが，本稿では表1のとおりSEランクという分類を設けた上でコスト比率（ポイント／時）を定義した．

またGitHub Copilotの費用についても単位をポイント／時に変換して使用した．

4.2　サンプル開発

サンプル開発はともに1日以内の単独作業で完了できるボリュームのWebアプリケーション開発から切り出したものを用意した．テストケースも準備し，品質評価指標計測に使用した．

参加者の経験や保有スキルを均一にすることはできないため，サンプル開発2実装のための開発言語は自由選択とした．

2つのサンプル開発を参加者単独で作業してもらい，次のアウトプットを提出してもらった．

• 成果物（HTML／CSS／画像イメージ／コード）
• 作業時間（単位：時間，小数点以下1位まで）
• アンケート（2つのサンプル開発完了後）

4.3　組織主観評価指標

組織の観点で評価するために，表3に示す品質，コスト，スケジュールの観点ごとに指標を計測した．

品質指標にはテスト合格率を使用するが，今回は生成AIを用いたツールを使用したリスクについても品質指標に加える必要があっため，洗剤バイアスチェックリスト合格率との積を用いた．

コスト指標は，EVMのコスト効率指標として使用されるCPIを用いた[9]．CV（コスト差異）ではなくCPIを採用した理由は，出来高（EV）算出に金額のかわりにコスト比率を用いたためである．なおGitHub Copilotを使用した場合は実コスト（AC）の段階からツール費用（ポイント／人時）を加算している（プロジェクト計画時はツール導入を予定していない想定とし，完成時総予算には加算していない）．

スケジュール指標ではスケジュール差異（SV）を使用せず，作業時間余剰率を使用した．これは，すべての指標が同じ単位（%）であり，数字の大きい方が良好となるように調整したためである．

4.4　ユーザー主観評価指標

組織主観とユーザー主観の評価の差異の確認を目的として，次の項目について選択回答形式のアンケートを実施した．

• 期待するコード生成率
• GitHub Copilot導入から得られる効果（品質／納期）
• 個人・組織にとってGitHub Copilot導入は有効か

5.　結果

5.1　潜在的バイアスチェック合格率

参加者に対して潜在的バイアスチェック項目を事前連携していない状態で実施したが，全員すべてのアウトプットが100%で合格となった．

5.2　組織主観指標

表4は，組織主観評価をまとめたものである．GitHub Copilot使用時・不使用時の平均値を比較している．

GitHub Copilotを使用したグループの方が，品質・コスト・スケジュールすべて向上した．特にコスト効率の効果が高かった．

5.3　ユーザー主観評価

図3は，ユーザーが希望するコードが生成される確率についてグラフ化したものである．平均値は50%，分散0であったため，ユーザーごとに生成率が異なり明確な傾向を掴むことはできない，という結果となった．

図4は，GitHub Copilot導入による効果を集計したものである．参加者の半数が経験年数3年未満であるため，コスト効果については設問に加えていない．スケジュール効率については肯定的な回答が多かった反面，品質効果は否定的な回答が多かった．

図5は，個人・組織にとってGitHub Copilotは有効であるかについて5段階評価を実施した結果である．個人にとって“有効”・“やや有効”と回答した参加者が3/4であったが，組織にとってという質問では5/6に増加した．組織を対象とした場合，導入に否定的な回答は0であった．

6.　考察

6.1　導入リスクの評価

潜在的バイアスチェックリストの合格率が100%であったことは，評価実施前からも予想していた．チェック対象の項目は，すべて暗黙ルールにおいても発生していなかったためである．

組織としてAI使用による発生リスクの定量化可否は重要な導入判断ポイントである．特に生成AIは性能を向上させており，G7広島サミット発表の前後からさまざまな組織が利用に関するガイドの公開を開始している．潜在的バイアスチェックリストは，限定されたユースケースであれば，運用も比較的容易である．今回実際に使用した結果から，リスクの定量化の方法の1つになりうると判断した．

なお，大規模な組織では既存の倫理規定を設けている場合が多く，整合性をあわせる仕組みづくりがポイントとなる．

留意すべき点として，すでにIDE拡張機能ベータ版としてChat機能の追加や，次期バージョンであるGitHub Copilot X[10] などユースケース拡大が予定されており，更新作業は並行して実行していく必要がある．

6.2　導入効果の評価

6.2.1　コスト指標：母集団全体で向上

コスト指標が最も大きく向上するという結果は，組織が企業である場合は導入を積極的に検討する理由となり得る．より詳細を分析するために，すべての組織主観評価に対して表1にて定義したSEランク別に分解した．結果を図6に示す．

SEランクA，Bは品質，コスト，スケジュールすべての指標が向上しているが，SEランクCはすべてが悪化していることが判明した．

SEランクCに相当する参加者は，経験年数が5年未満であり，保有スキルも他のランクと比較しても少ない．このため，生成されたコードを選択するかどうかの判断や採用するための修正個所の決定などの次動作が遅延する．コスト効率では，Copilot費用を超えるスケジュールの短縮ができなかったのではと推察される．

図7は，今回の参加者の経験年数の分布をあらわしている．半数が5年未満の若手で，残りの半数は階段状に経験年数が高くなっている．このような経験年数分布となる要員配置を行う開発プロジェクトは少なくない．参加者の構成を確認せずに，GitHub Copilotの導入を決定すると，コストについてはむしろ悪化する可能性があることを示唆している．

開発プロジェクトごとに導入を判断する場合では，要員構成に留意の上決定することを推奨する．

6.2.2　スケジュール指標：特にSEランクAで向上

作業時間が1日約17分短縮した．Copilotあり・なし別ではコスト指標が最も大きく向上していたが（表4），SEランク別ではSEランクAのスケジュール指標の向上率がさらに上回った効果があった（図6）．GitHub Copilotの有効性は，高い経験・スキルを持つユーザーのスケジュール短縮にあることが判明した．

6.2.3　品質指標：客観評価と主観評価が不一致

一方，組織として“GitHub Copilot導入は有効か”という質問に対して5/6が有効と判断しているが，表4に示した通り組織主観評価指標の効果増減はあまり大きい値ではなく，結果に差異が現れた．

コード候補提案機能は，個人の経験・スキルから不便に感じる場合もあるが，大半の参加者が組織として判断すると基本的に有益な機能であると多くの参加者が判断したためである．

この結果は，ユーザー主観評価のみで組織的な導入判断をくだす場合の問題を露出させた．

7.　まとめ

実際に計測した結果および考察から，GitHub Copilotの導入条件は，①潜在的バイアスチェックの品質管理システムへの組み込みが可能であり，②ユーザーの経験・スキルが一定以上である場合は品質・コスト・スケジュールに対する効果が見込めること，を導出した．これにより，提案した方法の有効性を示すことができた．

現段階で厳しく統制をかけている組織においても，今後はChatGPT[11] やMicrosoft 365 Copilot[12] などの登場から業務適用を検討する組織は増えることが予想される．提案手法は，コード生成ツールだけでなく，これらの生成AIを活用したビジネスツールの評価にも応用可能である．

ただし，短時間の擬似業務を作成し，定量評価可能なテストケースを用意することが可能であること．参加者は実業務メンバーから，可能な限り無作為に有効標本数の参加者を選出し，擬似業務を実行してもらうこと．参加者全員にアンケートを回答してもらうことが前提となる．

そして可能であれば，参加者のスキル・経験などの指標があれば，分析を細かく実行できる．

生成AIは，アーキテクチャが難解で内部構造を把握しているメンバーの確保が困難であり，それゆえ導入する際の不安が生まれやすい．

本稿が，組織が生成AIに対して正しく恐れることへの一助となれば，幸いである．

サンプルシステム実装を担当した12名の参加者に，謹んで感謝の意を表する．