はじめに
サブライムコンサルティングの大塚です。
弊社サブライムコンサルティングでは、ITコンサルティングに加えて、受託開発、サービス開発を行っています。
受託開発、サービス開発事業においてより品質の高いサービスを提供するために、システム開発の生産性や品質を向上するための施策を定常的に行っています。
具体的な取り組みとして、自社フレームワークの作成や社内開発標準の策定などを行っています。
上記施策の一環として、生成系AIを導入することによりシステム開発の生産性を向上できるか検証しています。
導入当初は期待した結果が得らませんでしたが、他の生成系AI同様、AIモデルにどのような指示を与えるのか、つまりプロンプトエンジニアリングが重要であることが分かってきました。
少しずつですが、知見が溜まってきたので紹介したいと思います。
GitHub Copilot
AIツールとして、GitHub Copilotを採用しました。
競合製品も存在しますが、GitHub Copilotは広く普及しており、関連情報も豊富であるという利点を理由に選びました。
概要について以下にまとめていますのでご参照ください。
検証概要
本検証ではWebアプリケーションの開発を対象とします。
GitHub Copilotを使用することで生産性を向上できるか、効果的な使用方法について検証します。
構成としては、WebAPIを提供するサーバーサイドアプリケーションと、Webブラウザ上で動作するフロントエンドアプリケーションからなるSPA(Single Page Application)構成を前提とします。
今回はサーバーサイドアプリケーションについて検証しています。
開発言語、フレームワーク
検証で使用する言語とフレームワークは以下の通りです。
弊社ではこれらの言語とフレームワークの実績が多くあり、また、GitHub上で多くのソースコードが公開されておりGitHub CopilotのAIモデルもこれらのソースコードを学習されており、一定以上の品質で対応できると考えたためです。
| 言語 | Java17 |
| フレームワーク | Spring Boot 3 |
開発環境
弊社ではIDEについてJet Brains社製のものを標準としています。
今回の検証でもJet Brains社のIntelliJ IDEAを使用しています。
IntelliJ IDEAにGutHub Copilotプラグインをインストールして検証しています。
検証の対象範囲
サーバーサイドアプリケーションを以下のレイヤに分けて検証します。
レイヤごとの特性を踏まえての検証の方針と結果概要は以下の通りです。
| レイヤ | 説明 | 検証方針・検証結果概要 |
|---|---|---|
| アプリケーションフレームワーク | 使用する外部ライブラリの管理、プロパティや定数、メッセージの管理といったアプリケーションで共通となる機能を提供するレイヤ | Copilotの適用を試した結果、人間が設計・開発すべきレイヤと判断。 |
| Controller | リクエストを入力として、各種業務処理を行い、レスポンスを返却するクラス。Model(SQL)の呼び出しも基本的にはControllerで行う。 | 検証の結果、適切に使用することでCopilotの効果が最も見込めるレイヤ。 |
| DTO | WebAPIにおけるリクエスト、レスポンスデータを格納するレイヤ。 | 検証対象外。単純なJava Beanであり自動生成などが適していると考えたため。 |
| Model | DBへのアクセスを行うレイヤ。SQLのコーディング含む。 | Copilotによる効果は見極め中で、継続して検証予定。 |
| DAO | ModelがDBへアクセスする際、DBへ渡すデータ、DBから取得するデータを格納するためのレイヤ。 | 検証対象外。DTOと同様の理由。 |
| Utility | 各処理から呼び出される共通的な機能を提供するレイヤ。単純な文字列の書式変換やAWSサービスなどの機能を想定。 | Copilotによる効果は見極め中で、継続して検証予定。 |
サーバーサイド検証結果
検証の詳細については別の記事として記述していますので、こちらを参照ください。
GitHub Copilot検証 詳細
サーバーサイドの検証した結果の考察は以下となります。
フレームワークへのCopilotの適用について
使用するライブラリの整備や、アプリケーションの骨子となるアーキテクチャの設計・開発へのCopilotの適用は難しく、アーキテクト等人間が整備すべきと判断しました。
Copilotがソースコードを提案してくれるのですが、実業務でのシステム運用を考慮すると、最終的に有識者が確認する必要があると考えたためです。
各種パラメータの設定について詳細な仕様を把握して、非機能面（性能、セキュリティ等）を考慮しての提案までは期待できません。
依存するライブラリのバージョンの妥当性についても適切に評価することも同様です。
疎結合などを考慮してのアプリケーションのアーキテクトを設計することも、現時点のAIモデルにはハードルが高いタスクです。
ただ、PoCやデモ用のとりあえず動くものを開発する際には効果が見込めます。
筆者も、知見が少ないGoLangで簡単なDBアクセスをするWebAPIを極力Google等で検索せずIDE+GitHub Copilotのみで開発してみたところ、1、2回検索する程度で完成させることができました。
このようなケースではCopilotは有用かと思います。
Copilotを効果的に使用するためのポイント
Copilotの提案するソースコードの質を高めるためには、大きく二つポイントがあります。
- 指示の出し方
コメントで指示を出しますが、コツが必要となってきます。
これは生成系AI全般に共通する内容であり、プロンプトエンジニアリングというAIを効率的に使用するための方法を研究する学問領域もあります。
Copilotが提案してくれるソースコードが想定するものと全く違う場合でも、追加で詳細な指示を与えることで品質が上がることはありますが、その指示の出し方に結構くせを感じました。
試行錯誤した結果をガイドラインとして整備して、より効率的に使用できることを目指しています。
- 別タブによるインプット情報の追加
別の記事(GitHub Copilotの概要)でも説明していますが、Copilotはコメントによる指示に加えて、別タブで開いているソースコードをインプットにして、ソースコードを提案してくれます。
この特徴を利用することで、Copilotの提案の精度を向上させることが出来ます。
もしろ、コメントによる指示だけでの活用には限界があると考えます。Copilotは一般に公開されているソースコードを対象に学習したモデルを使用しているため、各アプリケーション独自の特徴を追加情報として与えないと一般的な提案しか出来ないためです。
また、別タブで開くソースコードについても、関係ないものを開いていると想定外の提案をしてきたり、あとは、同じ拡張子のソースコードしかインプットにしない等、公開されていない仕様やコツがあり、ここについても試行錯誤した結果をガイドラインにまとめることを考えています。
Copilotの適用が適しているレイヤ
上記の特性を踏まえると、今回の検証の範囲ではWeb APIのロジックを記述するControllerクラスの作成にはCopilotを活用することで生産性の向上が見込まれます。
APIの処理はある程度分類することができ、多くの部分でソースコードは類似しています。
参考となるソースコードを事前に用意することで、Copilotが提案してくれるソースコードを使用してコーディング量を大幅に削減できると考えています。
記事を作成しつつ、現在、実際の開発でも使っていますが、効果が出てきています。
その他のUtilityやSQLへのCopilotの適用
Utilityについては、例えばAWSのサービスを使用する共通機能の開発を想定していますが、フレームワークと同じでとりあえず動くものを開発するのであればCopilotを活用できますが、実業務で使用する機能の開発については継続して検証しているところです。
提案されたソースコードで使用されているSDKは古いバージョンのものではないか、などの確認はやはり必要となったりしますので。
SQLのコーディングについても継続して検証しています。
最初はSQLのコーディングにおいて、全然Copilotの適用方法が分かりませんでしたが、コメントにDDL(create table文)を記述する等、指示の出し方を工夫すればそれなりのSQLを提案してくれるようになったのですが、生産性向上に繋げられるかは今後の課題となります。
まとめ
GitHub Copilotの検証について紹介させて頂きましたが、まだまだ試行錯誤な段階です。
プログラミングはAIに取って代わられる、と良く言われますが、現時点ではAIを適用できる領域はかなり限定的であると感じています。
ただ、大規模言語モデルの登場により急速に発展している分野であり、システム開発への適用に着目して検証を進めていきます。
今後は以下あたりを進めたいと考えています。
-
フロントエンドの検証
JavaScript、TypeScriptで試したところJavaと同様な感触でしたが、CSSなどサーバーサイドと異なる要素も多々あるので、その辺を踏まえて検証したいと考えています。 -
モバイルアプリケーションの検証
弊社ではモバイルアプリケーションの開発も行っています。
iOS、Androidの両端末をご要望されるお客様が多いため、弊社ではFlutterを使用することが多いのですが、Webシステム開発とは違う要素も多く、こちらも検証をしたいと考えています。 -
ガイドラインの整備
記事内でも記載しましたが、コメントによる指示や、別タブでのインプット情報の追加には公開されていない情報や使い方のコツが必要となってきます。
現在、社内でガイドラインの整理を進めているところですが、まとまったものができれば公開したいと考えています。 -
大規模言語モデルに対する理解
GitHub Copilotのコアとなる技術は大規模言語モデルです。
大規模言語モデルの特徴を踏まえた上で、システム開発へのAIの活用を検討していきます。
活用できるスコープはどこなのか、よりよく使用するためにはどうすればよいのか、今後どのような方向で発展することが見込まれるか、などを適切に判断するために大規模言語モデルについての理解も深めていきたいと考えています。
記事は以上となります。
GitHub Copilotの導入を検討されている方への参考になれば幸いです。