ChatDev 2.0（DevAll）とは｜1.0との違いとチュートリアル・導入手順【2026年7月】

ChatDevは、LLMを載せた複数のAIエージェントを協調させて成果物を作らせるオープンソースのフレームワークです（OpenBMB／Apache-2.0／GitHubスター33,718・2026年7月13日時点）。

ただし日本語で流通している「CEO・CTO・プログラマが対話してアプリを自動生成する仮想ソフトウェア会社」という説明と、python3 run.py --task ... で動かすチュートリアルは、いま公式リポジトリのmainブランチには当てはまりません。2026年1月7日にChatDev 2.0（DevAll）が正式リリースされ、mainの構成も導入手順も入れ替わったためです。本記事は公式リポジトリのREADME・設定ファイル・実コードを一次情報として、2.0の実体、1.0との違い、現行の導入手順、そして旧手順を使いたい場合の進め方を整理します。

まとめ：ChatDev 2.0を最短で理解する要点

• 2026年1月7日にChatDev 2.0（DevAll）が正式リリースされ、GitHubのmainブランチは2.0に置き換わった。1.0のコードは chatdev1.0 ブランチに残っている。
• 2.0の位置づけは「A Zero-Code Multi-Agent Platform for Developing Everything」。ソフトウェア開発専用ツールから、エージェントとワークフローをYAMLまたはGUIで定義する汎用のマルチエージェント基盤へ射程が広がった。
• 1.0の固定ウォーターフォール（設計→コーディング→テスト→文書化）は、2.0では yaml_instance/ChatDev_v1.yaml という40本以上あるテンプレートの1つになり、任意のワークフローをDAG（有向非巡回グラフ）で組む形へ一般化された。
• 導入は uv sync（Python 3.12系・Node.js 18以上）＋フロントエンドの npm install、起動は make dev。.env に API_KEY と BASE_URL を書けば、OpenAI以外にGemini・Ollama・LM Studioも指定できる。
• 日本語のChatDevチュートリアルの多くは1.0（2023〜2024年）が前提。そのままmainをクローンすると手順が噛み合わないため、1.0を再現したいなら chatdev1.0 ブランチを明示的に指定する。

ChatDev 2.0（DevAll）の現在地：2026年1月にゼロコード基盤へ刷新

「仮想ソフトウェア会社」から「Dev All」への射程拡大

1.0のChatDevは、ソフトウェア開発という1つのゴールに特化していました。ユーザーはタスク文を1行渡し、あとはCEO・CTO・プログラマ・テスターの役を与えられたエージェントが固定の工程を流れていく。裏を返せば、工程も役割も作者が決めたものから動かせません。

2.0のリポジトリ説明文は「ChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration」です。READMEはこれを「A Zero-Code Multi-Agent Platform for Developing Everything」と表現し、コードを書かずにエージェント・ワークフロー・タスクを定義して、データ可視化・3D生成・ディープリサーチといった開発以外のシナリオも組める、と述べています。2.0の主役は「仮想の会社」ではなく、ユーザーが自分で組むワークフローそのものです。エージェント協調の設計パターンを俯瞰したい場合はAnthropic公式が示すマルチエージェント協調5パターンの全体像と選定意義も合わせて読むと、ChatDevがどのパターンに当たるか位置づけやすくなります。

リポジトリの実体：main＝2.0、1.0は chatdev1.0 ブランチ

混乱の元は、URLが同じまま中身が入れ替わったことにあります。github.com/OpenBMB/ChatDev のmainブランチ直下には現在、server_main.py（FastAPIバックエンド）・frontend/（Vue 3のUI）・workflow/・yaml_template/・yaml_instance/・Makefile・compose.yml・uv.lock が並びます。1.0の象徴だった chatdev/・camel/・CompanyConfig/・WareHouse/ はmainにはありません。これらは chatdev1.0 ブランチに保存されています。

紛らわしいのは、mainにも run.py と requirements.txt が残っている点です。名前は同じでも中身は別物で、2.0の run.py はYAMLで書いたワークフロー定義を読み込んで実行するCLIです。依存解決も pyproject.toml と uv.lock が正で、pip install -r requirements.txt はコマンド自体は通っても2.0が想定する構成にはなりません。1.0の記事を見ながらmainを触ると、この2つのファイル名が「同じ手順が使えるはず」という誤解を生みます。

1.0と2.0の違い：ChatChainの固定工程からDAGワークフローへ

ChatChain（1.0）：役割ペアの二者対話で工程を進める

1.0の中核はChatChainと呼ばれる設計です。開発工程を設計・コーディング・テスト・文書化のフェーズに分け、各フェーズを「指示役（instructor）」と「実行役（assistant）」のエージェント2体の対話（サブタスク）に落とし込みます。論文「ChatDev: Communicative Agents for Software Development」（arXiv:2307.07924、ACL 2024採択）が提案したCommunicative Dehallucinationは、実行役が即答せずに指示役へ質問を返して条件を確定させることで、思い込みによる誤生成を減らす仕組みです。この二者対話モデル自体は2.0でも土台として生きています。

MacNetとPuppeteer（2.0）：DAGと中央オーケストレータ

2.0はエージェント同士のつながりをDAGで表現します。背景にあるのが「Scaling Large Language Model-based Multi-Agent Collaboration」（arXiv:2406.07155、ICLR 2025採択、MacNet）と「Multi-Agent Collaboration via Evolving Orchestration」（arXiv:2505.19591、NeurIPS 2025採択）で、後者は強化学習で最適化される中央オーケストレータ（puppeteer型）を提案しています。実装面では、YAMLファイルまたはドラッグ＆ドロップのビジュアルデザイナでワークフローを構成し、Python SDKからプログラム制御もできます。yaml_instance/ には demo_majority_voting.yaml（多数決）、demo_loop_counter.yaml（ループ）、demo_human.yaml（人間の介在）、demo_mcp.yaml（MCP連携）、demo_sub_graph.yaml（サブグラフ）といった制御パターンが実ファイルとして揃っており、これらを組み合わせて自分のワークフローを作る想定です。

ChatDev_v1.yaml：1.0の仮想会社は2.0の1テンプレート

1.0と2.0の関係を最も端的に示すのが yaml_instance/ChatDev_v1.yaml です。かつて製品そのものだった「仮想ソフトウェア会社モデル」が、2.0では他のテンプレートと同列に置かれた設定ファイルになっています。同じディレクトリには MACNet_v1.yaml、deep_research_v1.yaml、data_visualization_basic.yaml、blender_3d_builder_simple.yaml、react.yaml、reflexion_product.yaml など40本以上が並びます。2.0を「1.0の改良版」と捉えると読み違えます。1.0は2.0が実行できるワークフローの一例になった、というのが正確な理解です。

ChatDev 2.0チュートリアル：uv syncからWeb UI起動まで

前提環境：Python 3.12系・Node.js 18以上・.env の2変数

READMEが要求するのはPython 3.12以上とNode.js 18以上（対応OSはmacOS／Linux／WSL／Windows）です。1.0時代の記事にあるPython 3.9前提のままでは合いません。注意したいのは、pyproject.toml の指定が requires-python = ">=3.12,<3.13" になっている点で、3.13以降では依存解決が通りません。READMEの「3.12以上」を鵜呑みにして最新版のPythonを入れると、最初の uv sync で止まります。

git clone https://github.com/OpenBMB/ChatDev.git
cd ChatDev
uv sync
cd frontend && npm install && cd ..
cp .env.example .env

.env で設定する主要な変数は API_KEY と BASE_URL の2つだけです。BASE_URL を差し替えればプロバイダを変更でき、.env.example にはOpenAI（https://api.openai.com/v1）、Gemini、LM Studio（http://localhost:1234/v1）、Ollama（http://localhost:11434/v1）の例が列挙されています。Web検索やページ読み取りを行うワークフローでは SERPER_DEV_API_KEY・JINA_API_KEY が追加で必要です。

バックエンドとフロントエンドの起動

推奨はリポジトリルートでのMakefile経由の一括起動です。個別に立てる場合はバックエンドがポート6400、フロントエンドはVite側から VITE_API_BASE_URL でバックエンドを指します。

# 推奨（バックエンド＋フロントエンドを同時起動）
make dev

# 個別に起動する場合
uv run python server_main.py --port 6400 --reload
cd frontend && VITE_API_BASE_URL=http://localhost:6400 npm run dev

# Dockerを使う場合
docker compose up --build

起動後はブラウザのビジュアルデザイナでエージェントとエッジを配置し、そのままワークフローを実行できます。ゼロコードを名乗る根拠はこのUIにあります。

YAMLワークフローをCLIで実行する

UIを介さず、既存のYAMLを直接叩くこともできます。2.0の run.py は --path（ワークフロー定義ファイル。既定は yaml_instance/net_loop_test_included.yaml）と --name（プロジェクト名。既定は test_project）を取り、生成物は WareHouse 配下に出力されます。--attachment で初期メッセージにファイルを添付でき、複数回指定できます。

# 1.0の仮想ソフトウェア会社モデルを2.0上で走らせる
uv run python run.py --path yaml_instance/ChatDev_v1.yaml --name my_project

# 参考資料を添付してディープリサーチ用ワークフローを実行
uv run python run.py --path yaml_instance/deep_research_v1.yaml --name research_demo --attachment ./input.pdf

1.0の --task（作りたいソフトの説明文）や --model（GPT_3_5_TURBO 等の列挙値）は2.0の run.py には存在しません。タスクの中身とモデル指定は、ワークフロー定義と .env 側に移りました。

ローカルLLM運用の限界：往復回数とコンテキスト長

.env.example がOllamaとLM Studioのエンドポイントを公式に例示しているとおり、ローカルモデルでも起動はします。一方でモデル側の要件はREADMEにも .env.example にも書かれていません。ChatDevのワークフローは指示役と実行役の往復を各フェーズで繰り返し、demo_loop_counter.yaml のようなループや多数決ノードを挟めば呼び出し回数はさらに積み上がる構造です。会話履歴を持ち回る分だけコンテキスト長も伸びるため、量子化した小型モデルでは途中で出力形式が崩れ、ワークフローが最後まで通らないことがあります。ローカルLLMでエージェントを実用ラインに乗せる際の判断材料はPi（pi-coding-agent）をローカルLLMで動かす設定手順と実用ラインを解説で扱っており、必要なコンテキスト長やモデル選定の考え方はChatDevにもそのまま当てはまります。

旧1.0のチュートリアルが動かない理由と、1.0を使う手順

日本語のChatDev解説やハンズオン記事は2023〜2024年に書かれたものが多く、pip3 install -r requirements.txt の後に python3 run.py --task "Develop a Gomoku game." --name "Gomoku" を実行し、WareHouse/ に成果物が出る、という流れで統一されています。この手順は1.0のものです。mainをクローンしてこれをなぞると、参照するディレクトリが無い、引数が受け付けられない、といった形で噛み合いません。記事が間違っていたのではなく、リポジトリの中身が入れ替わったのが原因です。

論文の再現やベンチマーク比較のために1.0の挙動そのものが必要なら、ブランチを明示してクローンします。1.0のREADMEはPython 3.9の仮想環境を前提にしています。

git clone -b chatdev1.0 https://github.com/OpenBMB/ChatDev.git chatdev-legacy
cd chatdev-legacy
conda create -n ChatDev_conda_env python=3.9 -y
conda activate ChatDev_conda_env
pip3 install -r requirements.txt
export OPENAI_API_KEY="your_key"
python3 run.py --task "Develop a basic Gomoku game." --name "Gomoku"

ただし1.0の --model の既定値は GPT_3_5_TURBO で、選択肢もGPT-4o世代までしか列挙されていません。実運用の道具として使うなら、2.0側の ChatDev_v1.yaml で同じ工程を再現するほうが、モデル指定もツール連携も現行仕様に乗ります。1.0ブランチは「当時の実装を確認する保存先」と割り切るのが妥当です。

ChatDevを採用すべきでない場面

ChatDev_v1.yaml のようなコード生成ワークフローが作るのは、ゼロから書き起こされた小規模なプログラムです。2.0でワークフローを自由に組めるようになった今も、既存リポジトリへの機能追加や、テストを通しながらのリファクタリングは守備範囲外と考えてください。この領域は、リポジトリ全体を文脈に取ってdiffを出すコーディングエージェントの担当です（Coding Agentとは｜種類・主要ツール比較と選び方【2026】で各ツールの守備範囲を比較しています）。

もう1つ、単発の質問応答や短い定型処理にChatDevを持ち出すのも過剰です。エージェントを増やし往復させるほどLLM呼び出し回数は増え、トークン費用と実行時間が積み上がります。既存の開発ツールに載ったCodexのサブエージェント／カスタムエージェントのように、必要な場面だけ役割を分ける構成のほうが安く済むケースは多くあります。マルチエージェントシステムとシングルエージェントシステムの違いで整理されているとおり、分割・並列化・相互批評が効かないタスクでは単一エージェントのほうが速く安価です。ChatDevが噛み合うのは、工程を分けて役割ごとに批評させる価値がある、ある程度まとまった量の生成タスクです。

よくある質問

ChatDevのGitHubリポジトリはどこですか

github.com/OpenBMB/ChatDev です。mainブランチがChatDev 2.0（DevAll）、1.0のコードは chatdev1.0 ブランチにあります。ライセンスはApache-2.0です。

ChatDev 2.0は無料で使えますか

ソフトウェア自体はApache-2.0のオープンソースで無償です。ただし各エージェントはLLM APIを呼ぶため、OpenAIやGeminiを指定すればその従量課金が発生します。費用をかけたくない場合は .env のエンドポイントをOllamaやLM Studioに向け、ローカルモデルで動かす構成になります。

ChatChainとは何ですか

1.0で使われた協調設計の名称で、開発工程をフェーズに分割し、各フェーズを指示役と実行役のエージェント2体の対話（サブタスク）として順に実行する仕組みです。2.0では二者対話を土台に残しつつ、工程の並び自体をDAGで自由に定義する形へ一般化されました。

GPT以外のモデルでも動きますか

動きます。2.0は .env の BASE_URL と API_KEY でプロバイダを切り替える設計で、.env.example にはOpenAI・Gemini・LM Studio・Ollamaの記述例が含まれます。OpenAI互換のエンドポイントを持つサービスであれば同様に指定できます。

ChatDevの論文はどれを読めばよいですか

基礎は「ChatDev: Communicative Agents for Software Development」（arXiv:2307.07924、ACL 2024）です。2.0の設計を追うなら、エージェント数のスケーリングを扱った「Scaling Large Language Model-based Multi-Agent Collaboration」（arXiv:2406.07155、ICLR 2025）と、中央オーケストレータを提案した「Multi-Agent Collaboration via Evolving Orchestration」（arXiv:2505.19591、NeurIPS 2025）が該当します。

関連記事

• マルチエージェントシステムとシングルエージェントシステムの違い
• Anthropic公式が示すマルチエージェント協調5パターンの全体像と選定意義
• Coding Agentとは｜種類・主要ツール比較と選び方【2026】
• Pi（pi-coding-agent）をローカルLLMで動かす設定手順と実用ラインを解説
• Codexサブエージェントとカスタムエージェントの使い方｜TOML定義・config.toml設定・並列実行【2026年7月版】