生成AIを用いてアプリケーション開発プロセスを変革しよう(3) 設計書生成 ChatGPT編
進化が非常にめざましいAIを、アプリケーション開発に活用することを考えるコラムの第三弾です。
前回のコラム「生成AIを用いてアプリケーション開発プロセスを変革しよう(2) GitHub Copilot設計書生成概要編」では、Copilotに設計書を書いてもらうため、設計書生成の基本から制約となる要素とそれらの回避方法をご紹介しました。
その中でも例えば、チャットでの依頼は一つの依頼に対して一つの回答で完結するだけではなく、人間との会話のように以前の依頼を把握したうえで、次の依頼に対応してくれます。生成AIを使いこなす方法として、少し会話を行ったうえで本命の依頼をするテクニックがあります。
この手法は前回までの検証で、Copilotでは比較的効果を出しにくいようでしたが、ChatGPTはこの点についてCopilotと比較して得意なようであることがわかりました。
以上のような結果などを踏まえ、今回は主にChatGPTを活用した場合について、Copilotとの比較等にも触れつつ、設計書を生成する際のAI活用手法を探っていきたいと思います。
ChatGPT
ChatGPTの概要（参照：https://atmarkit.itmedia.co.jp/ait/articles/2212/23/news019.html）
ChatGPTは、対話に特化した言語モデルを使ってユーザーが対話するためのWebサービスで、2022年11月末にOpenAIによってリリースされました。
- ※プログラミングについての回答をしてくれるため、プログラミングの支援としても期待できます。本コラムでは、このプログラミングの支援能力を期待して検証を行います。
GitHub Copilot の概要（参照：https://docs.github.com/ja/copilot/getting-started-with-github-copilot）
GitHub Copilotでは、プログラムのコーディング時にAIがコードの候補を提示してくれます。
- ※本コラムでは、コーディング時のコード候補の提示だけではない、GitHub Copilotの利用方法を扱います。
以前の検証でGitHub Copilotの検証を行っているため、本コラムはGitHub CopilotとChatGPTを比較するような観点となっています。
- ※本コラムの内容は、2023年8月～2024年2月までの情報をもとにしています。現在進行形で急速に技術革新が進んでおり、最新の状況を把握して活用していくことが重要です。当社でも常にキャッチアップしながら現場適用を行っています。
1. 目的
AI の活用
ソフトウェア開発の開発生産性、品質向上のためのAI活用ノウハウを蓄積します。
今回はChatGPTを活用し、既存プログラムのコードからプログラム設計書の生成を検証します。
本検証では、Microsoft社がサンプルとして公開しているプログラムコードを検証対象として使用しています。
https://github.com/Microsoft/VCSamples/tree/master/VC2010Samples
https://github.com/dotnet-architecture/eShopModernizing
2. 設計書生成の基本
チャットで設計書生成を依頼する
3. GitHub Copilotでの設計書生成の制約
GitHub Copilotでは設計書生成で制約となる要素が10点ありました。
| 制約 | GitHub Copilot の挙動 | 対策 | ChatGPT の場合 | |
|---|---|---|---|---|
| 1 | ファイルを作成してくれない | 設計書の文面を生成してくれるがファイルとしての出力はできず、チャットの回答文として得ることになる | 回答文をコピー&ペーストしてユーザー自身がファイルを作成する | GitHub Copilot と同様の対応を行う |
| 2 | ファイルを見てくれない | ファイルシステム上のファイルを直接読んでくれず、開いているファイルしか読んでくれない | ファイルごとに得た回答をユーザー自身がつなぎ合わせる | ファイルを添付でき、ファイルを見てくれる |
| 3 | ファイルを一つしか見てくれない | 複数のファイルを開いていても一つのファイルしか読んでくれない | ファイルごとに得た回答をユーザー自身がつなぎ合わせる | ファイルを複数添付できる |
| 4 | 開いているファイルの見えている範囲しか見てくれない | ファイルを開いていても画面上に表示されている部分しか読んでくれない（100 行のファイルを開いていて画面上見切れて 50 行までしか表示されていない場合、50 行までしか読んでくれない） | 開いたファイル内のテキストを全選択をする | 上限サイズは未検証 検証プログラムでは最後まで読んでくれた |
| 5 | 一つのファイルに複数のプログラムが書かれていると複数並列で記載される | 『クラス名 クラス1 / クラス2 概要 クラス1の概要 / クラス2の概要』 といった記載がされる |
一つのプログラムだけを選択し回答を得る | クラス名を指定して依頼し一つのプログラムだけの回答を得る |
| 6 | 同じ文言で指定しても、全体のフォーマットによってセクションの記載が変わる | 「処理の詳細」を依頼する場合と「プログラムの概要・処理の詳細」を依頼した場合で、処理の詳細の部分の回答が変わる | セクションごとの断片を生成し、ユーザー自身がつなぎ合わせる | セクションごとの断片を生成し、ユーザー自身がつなぎ合わせる |
| 7 | ファイルが大きいと読んでくれない | 検証では 300 行程度（※実行のたびブレあり）を超えるファイルをインプットとすると、ファイルを与えていない場合の挙動になってしまう（ソースコードが指定されていません、といった旨の回答） | プログラムの一部だけを選択し回答を得ることを繰り返し結果をユーザー自身がつなぎ合わせる | 上限サイズは未検証 |
| 8 | 一度の回答のサイズに上限がある | 回答のサイズが大きくなる依頼をすると回答文の途中で回答が切れてしまう | 短い回答になるよう、プログラムの一部だけを選択し回答を得ることを繰り返し結果をユーザー自身がつなぎ合わせる | 上限サイズは未検証 検証プログラムでは回答をしてくれた |
| 9 | 以前のお願いから期待の傾向を踏まえてくれない | 「プログラムの概要・処理の詳細」を依頼し、続けて「処理の詳細」を依頼し「プログラムの概要・処理の詳細」しても結果が変わらないことが多い（「処理の詳細」と同じ詳細を記載してほしかった） | 詳細な記述をした長い文章の依頼文で回答を得る。一度に多い依頼はできなくなるので、断片ごとに回答を得て結果をユーザー自身がつなぎ合わせる | GitHub Copilot と比較し非常に良い結果が得られやすいが完全ではない。GitHub Copilot と同様の対応を行う |
| 10 | プログラムの詳細ステップを出してもらおうとすると、なかなか解像度が高くならない | プログラムの詳細ステップの解説を依頼すると詳細な情報が出るが、設計書の一セクションに含めると該当セクションで同じレベルの詳細な記載をしてくれない | セクションごとに回答を得ることを繰り返し結果をユーザー自身がつなぎ合わせる | GitHub Copilot と比較すると良い結果が得られやすいが完全ではない。GitHub Copilot と同様の対応を行う |
ヒント
GitHub Copilotでは依頼文に「@workspace」をつけることで、ワークスペース内のファイルを参考情報として参照してくれる機能があります。この機能で改善が見込めますが、「@workspace」機能については今後の追加検証を予定しています。
4. ChatGPTでの設計書生成
1. GitHub Copilotと比較し、良い点
ファイルを添付でき、ファイルを見てくれる／ファイルを複数添付できる
ChatGPTでは、チャットの依頼文に複数の添付ファイル、または複数のファイルを格納した.zipファイルを添付でき、複数のファイルをインプットして読んでくれます。
以前のお願いから期待の傾向を踏まえた回答をしてくれやすい／プログラムの詳細を出してもらいやすい
ChatGPTでは以前の依頼を強く踏まえて以降の回答をしてくれます。
一回依頼して回答の粒度が荒かった場合に、対応として一度個別の場所ごとに詳細の確認を依頼する手法です。するとAIが詳細を覚えてくれるので、次に依頼すると詳細を踏まえた回答をしてくれるという手法です。ただし毎回必ずというわけでなく、また踏まえてくれたとしても必ず個別の詳細と同じ粒度というわけではありません。
確率的には悪くはないのですが、毎回安定した回答を得るというわけにはいきませんでした。
2. GitHub Copilotと共通する課題とその対策
希望の回答を得るためには、断片で依頼しユーザーがつなぎ合わせる
複数のセクションを持つ回答を得たい場合、複数のセクションの出力を一回で依頼をするよりも個別のセクションに分割し、複数回に分けて依頼をした方が安定して希望の回答を得やすいです。
3. プログラム解析能力・プログラム記述能力の課題
プログラムを別のプログラミング言語に書き換える際、機械的に言語仕様に沿って置き換える
プログラミング言語固有の関数などを考慮しない場合や、書き換え前のプログラミング言語の固有の関数を、書き換え後の言語の同等機能に置き換えてくれない場合があります。また、機械的な置き換えをした結果、構造が壊れてしまう場合もあります。
一切解析のできないプログラムがある
検証の中で一切解析のできないプログラムがあったものの、一般的にありふれたプログラムコードで設計書生成対象として十分に想定されるプログラムです。
.Designer.csおよび.xamlファイルともに、Windowsデスクトップアプリの主流のUIフレームワークのプログラムコードファイルです。また、.Designer.csはWindowsフォームデザイナーの出力ファイルです（ChatGPTは出力ファイルではないと主張してしまっています）。XAMLファイルはXMLの拡張フォーマットのファイルです（ChatGPTはXMLではないと主張してしまっています）。
特に.Designer.csは15年以上の歴史のあるフォーマットです。
重要な要素の解析のできないプログラムがある
検証の中で重要な解析のできないプログラムがあったものの、一般的にありふれたプログラムコードで設計書生成対象として十分に想定されるプログラムです。
かつてMicrosoft技術でWebアプリの主流であったUIフレームワークのプログラムコードファイルです。ASP.NET WebFormsというフレームワークです。
今回の例では、再入荷、最大在庫といったコード埋め込み部分（<%#: ～ %>）は認識できているようですが、<asp: で始まるコントロール群が解析できていません。
5. まとめ
GitHub Copilotと比較したChatGPTの概要
- 1.GitHub Copilotと比較し、良い点は多い
- 2.共通する課題があるが、対策も共通のため使い勝手は実質変わらない
- 3.GitHub Copilotと比較し、プログラムの解析能力やプログラムの記述能力は劣る
ポイント
プログラム解析の検証では致命的な結果が出ています。
設計書全体を一気に生成するのではなく、断片を生成しユーザーがつなぎ合わせる使い方が良いという点は変わらず、実質的な使い勝手は変わりません。
使い勝手が実質変わらないこともあり、本検証ではプログラムコードまで見据えた※アプリケーション開発支援としてはGitHub Copilotを本命と結論しています。
- ※業務分析や要件・仕様策定、基盤設計などを主軸とした場合は違った結論があると考えられます。
6. 今後の予定
設計書生成に効果のあるAI活用手法
設計書を生成する際に活用したAI活用手法がいくつかあります。その手法についてまとめを行う予定です。
@workspace
前回のGitHub Copilotの検証中に気が付いた「@workspace」というキーワードがあります。
これは、今回の検証結果で判明した制約を大きく解消してくれる可能性のあるキーワードです。
今後は、このキーワードの効果について検証を進める予定です。
- ※文中の商品名、会社名、団体名は、一般に各社の商標または登録商標です。