最新AI論文をキャッチアップ

AIエージェントがソフトウェア開発を行う仮想の会社「CHATDEV」を設立!?

AIエージェントがソフトウェア開発を行う仮想の会社「CHATDEV」を設立!?

agent simulation

3つの要点
✔️ 多様な役職のAIエージェントが働く仮想のソフトウェアテクノロジー会社であるCHATDEVを設立
✔️ ソフトウェアの開発プロセスを複数のサブタスクに分解するフレームワークであるchat chainを提案
✔️ 実験によりCHATDEVのソフトウェア開発プロセスにおける効率性と費用対効果が実証された

Communicative Agents for Software Development
written by Chen QianXin CongCheng YangWeize ChenYusheng SuJuyuan XuZhiyuan LiuMaosong Sun
(Submitted on 16 Jul 2023 (v1), last revised 18 Jul 2023 (this version, v2))
Comments: 25 pages, 9 figures, 2 tables
Subjects: Software Engineering (cs.SE); Computation and Language (cs.CL); Multiagent Systems (cs.MA)

code:  

本記事で使用している画像は論文中のもの、紹介スライドのもの、またはそれを参考に作成したものを使用しております。  

はじめに

大規模言語モデル(Large Language Models, LLM)は質問応答・機械翻訳・コード生成などの幅広いタスクにおいて目覚ましい性能を発揮しており、最近では複数のAIエージェントを生成することで人間の行動をシミュレートする研究が盛んになってきています。

こうした背景と、ソフトウェア開発の核となるコードとドキュメントはどちらも言語(すなわち文字の並び)と見なすことができることから、LLMをソフトウェア開発におけるコスト削減に用いる方法が模索されてきました。

一方で、LLMを使用してソフトウェアを生成するにあたって、以下の問題点が挙げられていました。

  1. 質問応答タスクなどにみられるハルシネーション(LLMが事実とは異なるもっともらしいウソを出力する現象)と同様に、関数の不完全な実装・依存関係の欠落・潜在的なバグなどを引き起こす可能性がある
  2.  ソフトウェア開発において、コードレビューや提案のフィードバックのような、他者からのチェックが不可欠であり、こうした第三者の不在は重大なリスクである

本稿では、上記の問題に対処するために仮想のソフトウェアテクノロジー会社であるCHATDEVを設立し、プログラマー・テストエンジニア・アートデザイナーなどの様々な役職の生成エージェント間の相互的なコミュニケーションを基にした開発プロセスにより一貫性のあるソフトウェア開発を可能にした論文について解説します。

CHATDEV

前述したように、質問応答タスクなどにみられるハルシネーションと同様に、LLMを使用してソフトウェアシステム全体を直接生成すると様々な問題を引き起こすことが指摘されてきました。

本論文の筆者たちは、これらの問題はタスクの具体性の欠如と相互的な確認の欠如が原因だと考え、下図に示すような仮想のソフトウェアテクノロジー会社であるCHATDEVを設立することを提案しました。

CHATDEVはプログラマー・テストエンジニア・アートデザイナーなどの多様なアイデンティティを持つエージェントから構成されており、これらのエージェントはタスク(例:五目並べゲームを開発せよ)が提示されると、実行可能なシステム・ガイドライン・ユーザーマニュアルを含む必要なソフトウェアを開発するためにチャットを通じて効果的なコミュニケーションと検証を行います。

CHATDEVでは、ソフトウェア開発のライフサイクルモデルとして広く採用されているウォーターフォールモデルを採用し、ソフトウェア開発プロセスをdesigningcodingtestingdocumentingの4つのフェーズに分けていますが、実際のソフトウェアの開発においては各フェーズにおける複数の役職のエージェントの間で効果的なコミュニケーションが必要不可欠になります。

こうした円滑なコミュニケーションを可能にするために、本論文ではchat chainという各フェーズのタスクを複数の小さなタスクに分解するアーキテクチャを提案しています。

Chat Chain

chat chainは、下図のようにPhase-LevelChat-Levelの2つのコンポーネントで構成されています。

Phase-Levelでは、ウォーターフォールモデルを使用してソフトウェア開発プロセスを4つの連続したフェーズ(designingcodingtestingdocumenting)に分割します。

Chat-Levelでは、各フェーズはさらにアトミックチャットというチャットに分解され、このアトミックチャットでは2人のエージェント間でタスク指向のロールプレイが行われ、協調的なコミュニケーションが促進されます。

このようにエージェントが各チャット内で特定のサブタスクを達成するためにコミュニケーションをとることによって、望ましいアウトプットが出力される構造になっています。

次に、Phase-Levelの4つのフェーズであるdesigning・coding・testing・documentingについてそれぞれ解説します。

Designing

designing phaseは、CHATDEVが人間のクライアントから最初のアイデアを受け取るフェーズであり、下図に示すようにRole SpecializationMemory StreamSelf-Reflectionの3つの機能から構成されています。

Role Specializationでは、エージェントをCEO(Chief Executive Officer, 最高経営責任者)CPO(Chief Product Officer, 最高製品責任者)CTO(Chief Technology Officer, 最高技術責任者)の3つの役職に割り振り、役職を与えられた各エージェントに指定された役職に沿ったコミュニケーションを行わせます。 

Memory Streamは既存研究で提案された機能であり、エージェントのこれまでのコミュニケーションの記録を保持し、その後の意思決定を支援するメカニズムになります。

Self-Reflectionは、あらかじめ定義した終了条件(例:本タスクに適切なプログラミング言語を決定する)を満たす結論が出たにも関わらず、コミュニケーションが終了しない問題を解決するためのメカニズムになります。 

このメカニズムでは、チャットを行うエージェントとは別にPseudo Questionerというエージェントを生成しておき、Pseudo Questionerがこれまでのコミュニケーションの履歴の記録・要約し、エージェントに対して終了条件を満たす結論につながる質問をすることで終了を促します。

これらのメカニズムを基に各役職のエージェントが議論を行うことで、下図のようにソフトウェアの詳細部分を決定していきます。

 

Coding

coding phaseでは、エージェントをCTO(Chief Technology Officer, 最高技術責任者)プログラマーアートデザイナーの3つの役職に割り振ります。

その後、CTOは前のフェーズで決定された設計に基づいて、プログラマーにマークダウン形式を使用したソフトウェアシステムの実装を支持し、プログラマーはそれに応えるコードを生成します。

複雑なソフトウェアシステムを扱うために、CHATDEVはPythonのようなオブジェクト指向のプログラミング言語を利用し、プログラマーはGit関連のコマンドを用いてプロジェクトを管理します。

Testing

人間のプログラマーにおいても、最初に書いたコードにエラーが含まれないことは稀であり、こうしたエラーに対処するためにコードの実行結果を分析・調査し、実装エラーを修正しなければなりません。

Testing pahseではこうした一連のタスクを行うために、エージェントをプログラマーレビュアーテスターの3つの役職に割り振ります。

このプロセスはピアレビューシステムテストの2つのタスクから構成されており、ピアレビューはソースコードを検査することで潜在的な問題を特定し、システムテストはプログラマーがインタプリタを使用して実施するテストを通じてソフトウェアの実行を検証します。

Documenting

designingcodingtestingの各フェーズの後、CHATDEVは下図のようにエージェントをCEO(Chief Executive Officer, 最高経営責任者)CPO(Chief Product Officer, 最高製品責任者)CTO(Chief Technology Officer, 最高技術責任者)プログラマー4つの役職に割り振り、ソフトウェアの仕様書やユーザーマニュアルなどの関連ドキュメントを作成させます。

CTOはプログラマーに環境依存の設定について指示を出し、プログラマーにrequirements.txtのようなドキュメントを作成させ、同様にCEOは要件とシステム設計について指示を出し、CPOにユーザーマニュアルを作成させます。

ユーザーマニュアルはソフトウェアの技術的なアーキテクチャやインストール手順、および機能に関する包括的な情報を含んでおり、このドキュメントとマニュアルにより人間のユーザーは独自に環境を構築することができ、適切なインタプリタを使用して実際にソフトウェアを実行することができます。

Experiments

本論文では、CHATDEVによるソフトウェア開発の有効性を実証するための以下の条件で実験を行いました。

  • 大規模言語モデルにはChatGPTのgpt3.5-turbo-16kを使用
  • coding phaseでは、コード完成までに最大5回までの試行が許可される
  • Testing phaseでは、修正を提案のために最大5回までチャットが許可され、ソフトウェアシステムのテストが行われる
  • Pythonベースのシステムでは、テスト用のインタプリタとしてPython3.8.16を使用する

これらの条件のもと、CHATDEVによって生成されたソフトウェアシステムの統計分析を行い、ファイル構成・コードの複雑さ・バージョン管理などからCHATDEVの開発に関する包括的な情報を収集しました。

分析結果を下図に示します。

本結果で特に注目すべきはCHATDEVが開発したソフトウェアのコード行数であり、通常39行〜359行、平均131.26行と比較的小規模なコードでソフトウェアを作成する傾向があることがわかりました。

これはオブジェクト指向のプログラミング言語の設計によるものであると考えられ、コードを再利用することで冗長性を減らしていると推察できます。

加えて、ユーザーがあまり具体的でないタスクを指定した場合、CHATDEVによって生成されたソースコードは短くなる傾向があり、より明確で具体的なタスクを与えることで要求に沿ったコードを生成するように促すことができると考えられます。

また、表よりソフトウェアのバージョン更新が平均13.23回行われていることが読み取れますが、これはソースコードが平均で約13回修正されていることを示しており、ソフトウェア開発プロセス全体を通して、エージェント間の相互的なコミュニケーションによりコードの修正が繰り返されていることを反映していると言えます。

下図は、実験で行われたCHATDEVによる五目並べゲームの開発プロセスを表したものです。

一番左の画面はGUIなしで作成されたソフトウェアを表しており、コマンドターミナルからしかプレイできず、素朴なデザインになっていますが、プログラマーのエージェントがGUIデザインを組み込み、デザイナーがグラフィックを追加することで、視覚的に分かりやすく、より魅力的なゲームになっていることが分かります。

加えて、デザイナーエージェントのデザインに満足できない場合においても、CHATDEVがソフトウェアを完成させた後にユーザーが自由にカスタマイズができるなどの柔軟性を持ち合わせていることも実証されました。

まとめ

いかがだったでしょうか。今回は、仮想のソフトウェアテクノロジー会社であるCHATDEVを設立し、プログラマー・テストエンジニア・アートデザイナーなどの様々な役職の生成エージェント間の相互的なコミュニケーションを基にした開発プロセスにより一貫性のあるソフトウェア開発を可能にした論文について解説しました。

本実験結果より、CHATDEVによるソフトウェア開発の有効性が実証された一方で、以下のような問題も残っています。

  • 大規模言語モデルには固有のバイアスが存在することが分かっており、生成されたプログラマーにより人間のプログラマーの思考とは一致しないコードパターンが生成される危険性がある
  • 悪意のあるユーザーが本フレームワークを悪用する危険性がある

一方で、強化学習などを取り入れることでタスク解決への戦略の最適化を行える可能性があるなど、他分野の技術を統合することでソフトウェア開発の更なる効率化を達成することも考えられるため、今後の進展に注目が集まります。

今回紹介したアーキテクチャや実験結果の詳細は本論文に載っていますので、興味がある方は参照してみてください。

  • メルマガ登録(ver
  • ライター
  • エンジニア_大募集!!

記事の内容等について改善箇所などございましたら、
お問い合わせフォームよりAI-SCHOLAR編集部の方にご連絡を頂けますと幸いです。
どうぞよろしくお願いします。

お問い合わせする