人間と AI のチームワークによるアジャイルベースの生成的ソフトウェア開発の強化

ACM に投稿された原稿として書かれたこの論文は、生成的ソフトウェア開発 — エンドユーザーの要件から直接ソフトウェアを生成すること — を扱い、そうした要件は通常不完全であるという観察から出発する。論文は既存のエージェントを 4 つのカテゴリーに分類する。ユーザーが命じたことをそのまま実行する受動的エージェント、AutoGPT のようにタスクを自律的に分解・実行する自動思考エージェント、MetaGPT や ChatDev のようなマルチエージェント協調エージェント、そして GPT-Engineer や gpt-pilot のようにユーザーに質問して要件を拡張する質問型エージェントである。著者らは、これらのいずれにも受け入れ基準が欠けていること、ウォーターフォール型のエージェントでは LLM のハルシネーションが段階を追って蓄積すること、そして質問型エージェントはエンドユーザーがしばしば持たないドメイン知識を要求することを論じる。

著者らの提案である AgileGen は、アジャイル手法と振る舞い駆動開発（BDD）から着想を得ている。1 行の要件から、BDD の形式言語である Gherkin でユーザーシナリオを生成し、これが受け入れ基準となる。インタラクションブリッジがシナリオを自然言語に変換してユーザーが確認・追加・削除・修正できるようにし、決定されたシナリオを再び Gherkin に変換する。これらのシナリオは、ビジュアルデザイン、「一貫性要因」 — 生成されたコードを 1 回自動的に修正するために使われる、テスト可能なビジネスロジックのケース — の生成、そしてコード生成を導く。その後、ユーザーは動作するプロトタイプをテストし、さらなる反復でデザインや機能の変更を求める。こうしてエンドユーザーは各反復の両端に置かれ、その中間をエージェントが担う。また、メモリープールが過去のユーザーが決定したシナリオを保存し、類似した新しい要件に対して推薦する。

著者らは Web アプリケーション開発を実証のドメインとし、オープンソースの「50projects50days」コレクションの 30 プロジェクトに参加者が書いた 10 件の要件を加えたものと、ChatDev の SRDD データセットからサンプリングした 20 プロジェクトで AgileGen を評価した。評価は、自動指標、実行可能性とユーザー体験に関する人間による評価、アブレーション、ケーススタディを組み合わせて行われた。著者らは、AgileGen が CodeBLEU と Pass@1 で比較対象のエージェントを上回り、高いユーザー満足度を得たと報告している。

要点

• 論文は生成的ソフトウェア開発のエージェントを、受動的、自動思考、マルチエージェント協調、質問型に分類し、いずれもユーザー要件を補完する際に受け入れ基準を捉えられていないと論じている。
• AgileGen はユーザーの要件から Gherkin シナリオを生成することで受け入れ基準を補完する。著者らはこれを、このタスクのための生成的エージェントに BDD の概念を初めて導入したものとして提示している。
• ユーザーは 3 つの意思決定に参加する。要件の提示、シナリオの決定（確認、追加、削除、修正）、そしてプロトタイプの受け入れまたは変更の提案である。
• 一貫性要因 — 決定された Gherkin シナリオから導出されるビジネスロジックのテストケース — は、ユーザーが目にする前に生成されたコードの自動修正を駆動する。
• メモリープールは各要件をユーザーが決定したシナリオとともに記録し、Jaccard 類似度が 0.7 のしきい値を超える最も類似した過去のエントリーを、新しいシナリオ設計の例として提供する。
• 30 の「50projects50days」プロジェクトにおいて、GPT-3.5 を用いた AgileGen は CodeBLEU 0.339、Pass@1 62.5% を報告しており、著者らはこれが GPT-3.5 を用いた最新版の ChatDev をそれぞれ 0.089、16.4% 上回ると述べている。GPT-4 を用いた場合は 0.362 と 71.5% である。
• コードの実行可能性に関する人間による評価では、AgileGen のアプリケーションは「50projects50days」のタスクの 45% で 2、50% で 3 と評価され、サンプリングした SRDD のタスクでは 85% で 2、15% で 3 と評価された。公平性のため、生成は人間とのインタラクションなしで実行された。
• アブレーションでは、Gherkin シナリオ設計を取り除くと Pass@1 は 62.5% から 20.6% に低下し、一貫性要因を取り除くと 47.0% に低下した。著者らはこれを、性能を左右しているのはベースモデルではなくフレームワークの設計であることを示すものと解釈している。

補足

評価の対象は静的な Web アプリケーション（HTML、CSS、JavaScript）だが、著者らはこの設計は Web 開発に限定されないと述べている。メモリープールは公平性のために実験中は意図的に空のままにされていたため、ユーザーの意思決定コストを削減する効果は測定されていない。ユーザー体験のアンケートで最もスコアが低かった次元は新規性であり、著者らはこれを、LLM が学習したありふれたコードを生成しがちであることに起因するとしている。生成されたアプリケーションは、モデルが生成したリソースへのリンクが機能しないため、プレースホルダーのマルチメディアに頼ることが多い。著者らは、ユーザーが提供する API の利用や、今後の課題として Gherkin シナリオの自動テストのための Cucumber ツールを挙げている。