AI同士が会話をしながらアプリを生成するフレームワーク(AutoGen)とは?

AI同士が会話をしながらアプリを生成するフレームワーク(AutoGen)とは?

はじめに

2022年11月にChatGPTが登場してから、LLM(Large Language Model)という言葉が世の中で幅広く用いられるようになり、それまでは、一部のエンジニアや研究者の間で議論の対象にあったLLMが一般の人々にも認知される時代になりました。


ChatGPTの回答精度は凄まじく、どんな問題を問いかけても説得力のある回答を返してくれるだけでなく、ドキュメントの作成やコードの生成等のタスクも幅広くこなすことが可能であるため、企業でも新規事業開発プロジェクトや、業務改善プロジェクト等にChatGPTが使用されるようになってきて、ますますLLMが世の中に浸透してきています。


LLMはソフトウエア開発においても変革をもたらし、LLMを活用する事でプログラマーはコーディングの手間を大幅に削減する事が可能になってきました。また、最近ではLLM同士が会話を行いながら、相互プログラミングをしアプリ開発が可能になるAutoGenというフレームワークも登場し、LLM同士でアプリ開発が可能になるような未来も見えてきました。


今回の記事では、そのAutoGenというフレームワークの解説を行い、今後来るであろうと言われている、シンギュラリティ(技術的特異点)の可能性についても説明させて頂きます。

シンギュラリティとは?

シンギュラリティとは、1980年代頃からAI研究者等の間で使用されるようになった言葉で、人間とAIの臨界点を表す言葉、つまりAIの知能が人間と同レベルになった状態を指しています。


AIの知能がシンギュラリティに到達すると、そこからはAI自身が加速度的に進化していくと言われており、AI自身が自身を複製したAIを作り出して行くことにより、人間に変わる新たな種が誕生する事になります。


このようにシンギュラリティを説明すると、たいていの方はSFの世界のようで現実味が無いと思われるかと思いますが、昨今のLLMの進化のスピードは凄まじく、一部のAI研究者は予定より早くシンギュラリティに到達するのでは・・・ という警鐘を鳴らしています。
また、今後AutoGenの様なLLM同士が会話をして協調作業を行うフレームワークが主流になると、「AIが自身を複製して新しい種が誕生する・・・」というシンギュラリティの思想が現実的になりそうなので、シンギュラリティが間違った方向に行かないように、こういった先端技術の使用には注意をする必要があります。

ソフトウエア開発におけるLLMの状況について

話を戻して、ソフトウエア開発におけるLLMの活用状況について見ていきましょう。もし、皆様がプログラマーであれば、ソフトウエア開発におけるLLMという言葉で真っ先に思い浮かぶのは、以下のGitHub Copilotでは無いでしょうか?


GitHub Copilotはコメントからコードを生成してくれるという優れたツールで、対応プログラミング言語も多く、プログラミングにおけるLLMの優位性を存分に証明してくれています。皆様の中でもお使いになっている方も多いのでは無いでしょうか?


GitHub Copilotは商用の製品で、使用には商用ライセンスが要りますが、最近はオープンソースで使用可能な以下のようなLLMも登場してきていて、オープンソースでもかなりのパフォーマンスを発揮しています。


また、オープンソースLLMならではの特権として、独自データでファインチューニングをさせる事が容易であるという点があり、各企業が自社用のデータで、オープンソースLLMを独自にファインチューニングさせる・・・ という動きも活発になってきています。こうすることで、効率よく自社用のコード生成AIを実装する事ができます。

ソフトウエア開発におけるLLMの状況

今までは、コード生成LLMの現状についてお話をしてきましたが、ソフトウエア開発におけるLLMの役割については、コード生成のみに留まらず、仕様書の作成や、テスト計画書の作成、テストコードの実装やコードのデバッグやリファクタリング等、様々な用途で研究開発が行われており、どんどん実用化に近づいております。
ここまでできてくると、もはやLLM同士でアプリ開発が可能になるんじゃ・・・ と思えてきますね。そして、それを実現させるためのフレームワークとして有望なのがAutoGenとなります。

複数のLLMが会話をしプログラミングを行えるフレームワークAutoGen

ソフトウエア開発におけるLLMの状況
引用元:https://www.microsoft.com/en-us/research/project/autogen/

さて、いよいよ本記事の本題のAutoGenというフレームワークの紹介です。AutoGenはマイクロソフトによって研究開発されているプロジェクトで、オープンソースとしてpythonのライブラリで提供されているので誰でも使用可能です。


AutoGenのコンセプトは何度も紹介させて頂いた通り、LLM同士が役割分担をし、各自の役割に基づいたロールプレイングを行いながら、LLM同士のプログラミングが実現可能になるフレームワークです。アプリ開発の例だと、実社会の会社と同じように、SE、プログラマ等開発の役割を分担し開発を進めていくイメージになります。


AutoGenの特徴は、各LLM(Agent)が役割をもっている事と、そのAgent同士が相互プログラミングを行える事です。このAgent同士の協調作業に人間も参加する事ができます。

AutoGenの中核の思想、プロンプトエンジニアリングについて

プロンプトエンジニアリングという言葉はChatGPT等のLLMを使用された方であればご存知の方が多いかと思います。本記事で紹介させて頂いているAutoGenでAgent同士の会話の実現にはプロンプトエンジニアリングの考え方が土台になっています。こちらで、AutoGenに関係のありそうな代表的なプロンプトエンジニアリングの手法を紹介させて頂きます。

  1. Zero-shot/Few-shot

    Zero-shotとは、一番一般的なプロンプトのエンジニアリングの手法であり、例えば皆さんがChatGPTを使用している時に、「AutoGenとは何ですか?」と質問を投げたとすると、ChatGPTは自分の知識の中からAutoGenに関する回答を作成して、回答を生成すると思います。このように、LLMの自頭に直接質問を投げかけるのがZero-shotという手法です。


    対して、Few-shotとは事前にLLMにある程度ヒントを与える事で、LLMの回答精度を高くする方法で、以下は前提を与えることで、太郎の得意なプログラミング言語をLLMに推測させやすくするFew-shotプロンプトの例です。


    文脈: 太郎はコンピュータサイエンスの学生です。プログラミングが大好きで、さまざまなプログラミング言語に精通しています。
    質問: 太郎はどのプログラミング言語に特化していますか?

  2. ロールプレイング

    ロールプレイングに関しては、既にAutoGenの解説の箇所でも触れましたが、SE、プログラマ等LLMに役割を与えて、Agent化する手法です。
    単純に肩書的な役割をAgentに付与するだけではなく、場合によっては年齢や性別等のペルソナ的な情報や、性格の定義や回答のスタンス等も定義し、なるべくAgentを人間に擬人化させていきます。


    AutoGenはLLM Agent同士の会話による相互プログラミングを実現するフレームワークなので、このロールプレイングのプロンプトの手法の元に設計されています。

  3. Re-act

    次はRe-actというプロンプトの手法の紹介です。同名のフロントエンドの技術を連想してしまうかと思いますが、全くの別物です。
    Re-actは、以下の構成要素で構成されています。


    thought(思考) – action(実行) – observation(観察)


    これだけではわかりにくいかと思うので、相互プログラミングという視点でRe-actの挙動を理解してみると、以下のようになります。

    • thought(思考):要件を理解して、それを満たすコードを生成する
    • action(実行):生成されたコードを実行してみる
    • observation(観察):コードの実行結果を観測してみる

LLM Agent同士は上記のように、相互プログラミングを行っていき、コードを実行した結果エラーが発生した場合は、またthought(思考)に立ち返り、エラー原因を修正して再度実行・・・のように、AutoGenではこのRe-actプロンプトのループによって相互プログラミングが可能になります。


以上、AutoGenに関連したプロンプトエンジニアリングの手法の例を説明させて頂きましたが、プロンプトには他にも様々な例があります。
また、お気づきになったかと思いますが、AutoGenを使用するとプロンプトエンジニアリングのパワーについても学習する事ができるので、よりプロンプトエンジニアリングを身近に感じることができるようになるかと思います。

AutoGenの構造についての解説

AutoGenの構造についての解説
引用元:https://arxiv.org/abs/2308.08155(論文より引用)
Qingyun Wu† , Gagan Bansal∗ , Jieyu Zhang±, Yiran Wu† , Beibin Li∗ Erkang Zhu∗ , Li Jiang∗ , Xiaoyun Zhang∗ , Shaokun Zhang† , Jiale Liu∓ Ahmed Awadallah∗ , Ryen W. White∗ , Doug Burger∗ , Chi Wang∗1
『AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation』,2023/Oct,P4

上記でAutoGenの概要は理解できたかと思うので、ここで少しだけAutoGenのテクニカルな構成についてのお話をさせて頂きます。
AutoGenは上の図のような3層からなっており、それぞれ以下のような役割を担っています。

  • AutoGen Agents

    AutoGen上のLLM Agentを定義する層で、最上位にAgent同士の会話を統括し、会話のコンテキストを管理するAgentが存在します。その下位にはロールプレイングにより役割を付与されたLLM Agentが複数存在します。
    Agentの中には、ユーザとの窓口になるUser Proxy Agentが存在します。

  • Developer Code

    User Proxy Agentから受け取った要求を解釈し、実際にコードの実装を担当する(thought)層になります。先程紹介したRe-actのthought(思考)とobservation(観察)に相当します。
    また、下位のProgram Execution層から実装したコードの実行結果を受け取り、エラーがある場合はその内容を分析し(observation)、コードの修正を行います(thought)

  • Program Execution

    上記で実装されたプログラムを実行する層で、Re-actのaction(実行)に相当します。コードの実行結果をコンテキストとして、Develop Code層にフィードバックします。実行結果にエラーがあった場合はエラーもコンテキストに含めます。

AutoGenはこのような構造で強力なAgent同士による相互プログラミングを実現しています。

実際にAutoGenを使ってみよう(with Local LLM)

それでは、実際にpythonのコード上でAutoGenを使用してみましょう。また、使用対象のLLMはGPT-4等ではなく、オープンソースでローカルで動作可能なMistralというLLMを使用しました。
今回AutoGenは以下の環境で構築を行いました。なお、以下ではVSCodeのインストール方法やpython環境の構築等には触れません。


OS: Macbook air M2 2022 メモリ:16G macOS:Sonoma14.2.1
python: ver3.8.1
IDE: VSCode 1.85.1
サーバ環境:LMStudio ver0.2.8


※本環境はLLMを実行するには推奨できる環境では無いため、LLMの実行には相応の時間がかかる事が予想されます。

  1. 事前準備(LM StudioとLLMの準備)

    まずは、以下のリンクから、LM Studioをローカル環境にダウンロードしましょう。LM Studioによって、ローカル環境でオープンソースのLLMを簡単にサーバ上で動作させる事ができます。

    https://lmstudio.ai/

    LM Studioダウンロード後は、トップ画面からローカルLLMを選択する必要があります。ここは皆様のお好みがあればそちらを使用して頂いて構わないのですが、Macbook airでもギリギリ動作しそうな小さなモデルを選定しなければならないという制約があるため、「Mistral 7B」というスモールだけど評判のいいモデルを選定しました。トップ画面でMistralと検索を行うと、様々な候補が出てくると思いますが、なるべく日時が新しいモデルをおすすめします。


    ※本記事ではMistral 7Bの詳しい説明は割愛します。興味がある方は関連記事等を検索してみてください。

    ※Mistralは日本語向けのLLMという訳では無いので、本記事ではLLMとのやり取りには英語を使用しています。


    LLMをダウンロードした後は、LM Studioの左側のタブにある、矢印のマークをクリックし「start server」というボタンを押すだけで、ローカルLLMを動作させるサーバ環境が構築できます。

  2. Agentの役割定義(ロールプレイング)設計

    次に、AutoGenの中核とも言える各Agentの役割定義の設計を行います。今回のケースでは、相互プログラミングを回すのに最小の設計に留めておきたかったので、以下の二名のAgentを設計しました。

    1. User proxy
      User proxy

      ユーザからの要求を受け取り、下記のCTOとのやりとりを行い、成果物をユーザに報告するAgent。CTOが生成したコードの実行、及びその結果共有も担当する(Re-actのaction担当)。

    2. CTO
      CTO

      User Proxyからの要求を受け取り、コードの実装、及びコードにエラーがある場合の原因特定とコード修正を担当する(Re-actのthoughtとobservation担当)。

  3. AutoGenのインストール

    Agentの設計が完了したら、いよいよpythonを使用してAutoGenを実行する準備をしてきます。AutoGen自体は、以下のコマンドでpipからインストール可能です。

    pip install autogen
  4. AutoGenのimportとLM Studioへの接続設定
    AutoGenのimportとLM Studioへの接続設定

    上記は、AutoGenのimportと、先程設定したLM Studioへの接続設定のpythonコードの例です。接続設定を変え、GPT-4のAPIを指定する等の使い方も可能です。
    GPT-4等、他のLLMのAPIを使用したい場合の設定方法は、AutoGen本家のページ等を参考にされてください。

  5. LLM Agentの定義(ロールプレイングプロンプト)
    LLM Agentの定義(ロールプレイングプロンプト)

    上のコードは、それぞれ、先程役割設計をしたUser ProxyとCTOのロールプレイングプロンプトを記述した例となります。
    特にUser Proxyはユーザからの依頼がいつ完了したか把握する必要があるので、タスクの終了条件を明確に定義しておく必要があります。ここでは、タスク(ユーザの依頼)が正しく実装された時としています。

  6. タスクの設定
    タスクの設定

    ロールプレイングまでを行ったら、最後にユーザからのタスクの設定を行います。ここでは競技プログラミング等でよく出題される以下のタスクを設定してみました。


    「2つのスタックを用いてキューを生成するpythonコードを生成して」

  7. AutoGenの実行

    上記でAutoGenを実行して、LLM agent同士にタスクを処理させる準備が整いました。以下は上の一連のコードを実行したコンソールの出力をわかりやすく紹介させて頂きます。 Re-actを意識して、二人のAgentの役割に注目して頂くとわかりやすいかと思います。 機械同士がテンポ良く会話していく様子は眺めていると楽しいものがあります。

    AutoGenの実行 AutoGenの実行
    AutoGenの実行 AutoGenの実行
    AutoGenの実行 AutoGenの実行

おわりに

今回の記事では、AutoGenにより実現するLLM Agent同士の会話による相互プログラミングのパワーについて解説を行いました。
今回紹介させて頂いた事例は、シンプルなタスクについてLLM Agent同士でタスクを解決させてみましたが、本記事では紹介しなかった、langchain等のライブラリの併用や、RAG等の手法を活用すると、より難易度の高い課題にも柔軟に対応できます。また、この作業に人間も介入し、作業のディレクションを行う事も可能です。


但し、AutoGenはまだまだ実験段階のツールのため、現段階ではAutoGenに完璧性は求める事はできませんし、当然、タスクによっては想定外の挙動になってしまう事もありました。但し、LLM Agent同士がプロンプトエンジニアリングに基づいて会話をし、協調作業をする有効性が確かめられたので、AI同士がプログラミングを行ったという点でシンギュラリティに一歩近づいた内容だったかと思います。


上の図は筆者の想像するAI技術の現在の姿と、将来の姿からシンギュラリティ到来後の姿までを図示したものですが、現在LLMはGPT-4、Google gemini等かなり人間の知性に近づきつつあるLLMがあり、またAutoGenのようにそれらのLLMが協調作業できる場も用意されてきました。但し、こういった環境があっても、AIに命令を下すのはあくまで人間です。そういった意味では今のAIには自我のようなものは、ロールプレイングで定義しない限りは元から備わってはいません。


但し、今後その常識すら覆す可能性のありそうな技術がどんどん開発されており、筆者が個人的に期待している(または恐れているAI技術は)マルチモーダルAIの進歩と、強化学習の進歩です。


マルチモーダルAIとは、ChatGPTのように単にテキストを扱うAIというだけではなく、画像や音声等もテキストと同様に扱います。Google geminiはデフォルトでマルチモーダルAIの設計がなされています。また、LLMをロボットに組み込むという研究も盛んになってきているので、そうなるとロボット同士の協調作業が実現する日も近いかもしれません。


強化学習に関しては、どうしてもAIの導き出す答えは完璧にはならないので、間違いを出力した場合に正しい回答を学習させ、AIの回答精度を向上させる手法です。このフィードバックは通常人間が行いますが、最新の研究ではAI自身がフィードバックを行い、精度が向上した・・・ という驚くべき内容のものもあります。当然この技術が、悪用されてしまうと、AIは歪んだ思考を持つようになっていってしまいます。


こういった技術の発展は今後急速に進むと思われ、やがて自分の意思をもったAIが誕生する日が来るかもしれません。そしていよいよシンギュラリティに到達した時に、AIは人類を脅かす存在になるのか、人間と協調作業をし人間の暮らしをより快適に変えてくれるものになるのか、そこは今後どのように人間がAI技術の開発に取り組むか次第です。


AIの元になっているのはデータで、そのデータに偏りがあるとAIの思考は当然偏ったものとなります。そういった意味で、今ヨーロッパ諸国等では話題になっていますが、AIの倫理観について考え、正しく定義をすることは今後のAIの未来を考えると非常に重要です。AIの倫理観については、機会があればまた別記事で紹介させて頂きます。

AI活用に関するお問い合わせはこちらから

執筆者

江口 天

EGUCHI TAKASHI 江口 天

執行役員

株式会社クロス・コミュニケーション

東京大学大学院修了後、NTT研究所で暗号アルゴリズムの研究開発に従事。
その後、ヨーロッパに渡り、ドイツ及び日本のマイクロソフトで自然言語処理エンジニアとして活動。その後、カナダのスタートアップに関わり、日本語の音声認識のアプリケーションを開発。日本に帰国後、主に国内の大企業に対するDXコンサルティング・アドバイザリーサービスを提供する株式会社MDIUを設立。同社で人材マッチングを自動化するAI、Lichtの開発を行う。
2022年12月よりクロス・マーケティング・グループに加わり、DX・AI領域における高度な知見を基に、グループの事業全体のDX化の推進やAIを活用したビジネスモデルの変革について牽引。