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

ChatDevは、LLMを載せた複数のAIエージェントを協調させて成果物を作らせるオープンソースのフレームワークです。開発元はOpenBMBで、ライセンスはApache-2.0、GitHubリポジトリのスターは34,628（2026年10月31日にGitHub APIで取得）です。

日本語で流通している「CEO・CTO・プログラマが対話してアプリを作る仮想ソフトウェア会社」という説明と、python3 run.py --task ... で動かすチュートリアルは、いまのmainブランチには当てはまりません。2026年1月7日にChatDev 2.0（DevAll）が正式リリースされ、mainの構成も導入手順も入れ替わったためです。本記事では2.0のインストールから自作YAMLワークフローの実行までを手順として示し、10月に入った安全設定の変更と、1.0を動かしたい場合の進め方も扱います。

まとめ：ChatDev 2.0チュートリアルの要点

• 2026年1月7日にChatDev 2.0（DevAll）が正式リリースされ、mainブランチは2.0に置き換わった。1.0のコードは chatdev1.0 ブランチにある。最新リリースはv2.2.0（2026年3月23日）。
• 2.0はエージェントとワークフローをYAMLまたはWeb UIで定義する汎用のマルチエージェント基盤。1.0の仮想ソフトウェア会社は yaml_instance/ChatDev_v1.yaml という1テンプレートになった。
• 導入は uv sync（Python 3.12系）＋フロントエンドの npm install、起動は make dev でブラウザの http://localhost:5173 を開く。接続先は .env の API_KEY・BASE_URL と、YAML各ノードの provider・name（モデル名）の組み合わせで決まる。
• 2026年10月16日のmainの修正で、ワークフローからのコード実行は既定で無効になった。生成コードの実行やパッケージ導入を伴うワークフロー（ChatDev_v1.yaml を含む）は、サーバー側で MAC_ALLOW_UNSAFE_CODE_EXECUTION=1 を設定しないと該当の呼び出しが拒否される。
• 自作ワークフローは graph の下に nodes・edges・start・end を書くだけで組める。実行はCLIの run.py --path か、Python SDKの run_workflow()。

ChatDev 2.0（DevAll）の現在地：v2.2.0までの変更点

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

1.0のChatDevはソフトウェア開発に特化し、タスク文を1行渡すとCEO・CTO・プログラマ・テスター役のエージェントが開発工程を流れていく作りでした。工程・フェーズ・役割は CompanyConfig/ のJSON（ChatChainConfig.json など）で変えられましたが、対象はあくまでソフトウェア開発でした。

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の主役は仮想の会社ではなく、利用者が自分で組むワークフローです。エージェント協調の設計パターンの中での位置づけはOrchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】で確認できます。

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

混乱の元は、URLが同じまま中身が入れ替わったことです。mainブランチ直下には現在、server_main.py（FastAPIのバックエンド）・frontend/（Vue 3のUI）・workflow/・yaml_instance/・Makefile・compose.yml・uv.lock が並びます。1.0の chatdev/・camel/・CompanyConfig/ はmainに無く、chatdev1.0 ブランチに残っています。

紛らわしいのは、mainにも run.py と requirements.txt が残っている点です。名前は同じでも、2.0の run.py はYAMLのワークフロー定義を読み込んで実行するCLIで、引数も別物です。依存関係は pyproject.toml と uv.lock が正なので、1.0の記事のとおり pip install -r requirements.txt から始めると手順がずれていきます。

リリースの経緯：v2.1.0・v2.2.0と10月の安全修正

2.0の正式版以降、GitHubのリリースは2回出ています。v2.2.0以降はリリースが無く、10月の修正はmainにだけ入っています。

v2.1.0のリリースノートでは、複数タスクをまとめて流すバッチ実行と、その結果を比べる実験用のLaboratory画面が追加されました。旧来のChat Completions形式のAPIへの対応と、関数呼び出しまわりの不具合修正もこの版です。v2.2.0では、OpenClawのエージェントチームをワークフローから呼べるようになり、Python SDKとDocker Composeでの開発環境が加わりました。

1.0と2.0の違い：開発用ChatChainから汎用グラフワークフローへ

ChatChain（1.0）：役割ペアの二者対話による工程進行

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

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

2.0の背景にあるのは、エージェントのつながりを有向非巡回グラフ（DAG）で表すMacNet（arXiv:2406.07155、ICLR 2025採択）と、強化学習で最適化される中央オーケストレータを提案した論文（arXiv:2505.19591、NeurIPS 2025採択）です。実装のワークフローは非巡回に限らず、demo_loop_counter.yaml（回数付きループ）、demo_majority_voting.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では9体のエージェントノードとループカウンタで組まれた設定ファイルの1つになりました。同じディレクトリには MACNet_v1.yaml、deep_research_v1.yaml、data_visualization_basic.yaml、react.yaml などYAMLが42本あります（2026年10月31日時点）。2.0は1.0の改良版ではなく、1.0は2.0が実行できるワークフローの一例になったと捉えるのが正確です。

ChatDev 2.0チュートリアル：インストールからWeb UI起動まで

前提環境：Python 3.12系・Node.js 18以上・.env の設定

READMEの要件はPython 3.12以上とNode.js 18以上、対応OSはmacOS・Linux・WSL・Windowsです。ただし pyproject.toml の指定は requires-python = ">=3.12,<3.13" で、実際に動くのは3.12系だけです。uv sync はこの条件に合う3.12を探し、無ければ自動で取得するので通常は意識しなくて済みます。.python-version や UV_PYTHON で3.13以降を固定している環境、またはuvを使わずpipで3.13の仮想環境に入れる場合は、この条件で止まります。

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つです。.env.example にはOpenAI（https://api.openai.com/v1）・Gemini・LM Studio（http://localhost:1234/v1）・Ollama（http://localhost:11434/v1）の接続先が例示されています。ただしURLだけでは呼び出し方は変わりません。OpenAI互換のLM Studio・Ollamaは各ノードの provider: openai のまま接続先とモデル名を替え、Geminiはワークフロー定義のガイドのとおり provider: gemini を指定します。Web検索やページ読み取りを使うワークフローでは SERPER_DEV_API_KEY・JINA_API_KEY も設定します。

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

推奨はリポジトリ直下での make dev です。バックエンドがポート6400、フロントエンドが5173で立ち上がり、ブラウザで http://localhost:5173 を開くとワークフローの編集画面が出ます。

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

# 個別に起動する場合（リポジトリ直下から、ターミナルを2つに分けて実行）
# ターミナル1：バックエンド
uv run python server_main.py --port 6400
# ターミナル2：フロントエンド
cd frontend && VITE_API_BASE_URL=http://localhost:6400 npm run dev

# Docker Composeを使う場合（v2.2.0以降）
docker compose up --build

画面が出てもバックエンドにつながらないときは、まず lsof -i :6400 で6400番を別のプロセスが使っていないかを確かめます。使われていれば、READMEのとおりバックエンドを --port 6401、フロントエンドを VITE_API_BASE_URL=http://localhost:6401 に揃えて変えます。

コード実行の許可設定：MAC_ALLOW_UNSAFE_CODE_EXECUTION

2026年10月16日のmainのコミット「fix: confine workflow writes and gate unsafe code execution」で、ワークフローが持ち込んだコードの実行は既定で止まるようになりました。対象はPythonノード、code_save_and_run、execute_code、uvのツール（パッケージ導入を含む）、Manimのスクリプト、ローカルのMCPサーバープロセスで、リモートのMCPは対象外です。.env.example には「this is not a sandbox」と明記されています。

ChatDev_v1.yaml のエージェントはuv系のツール群を持っているため、既定のまま1.0相当のワークフローを流すと、生成したコードをuvで動かす・依存を入れるといった呼び出しが拒否されます。許可するには、サーバープロセスの環境変数か .env に次の1行を書き、サーバーを再起動します。値は 1・true・yes・on のいずれかで、ワークフローの vars やノードの env からは有効にできません。

# .env（サーバー側の設定。信頼できるワークフローだけで使う）
MAC_ALLOW_UNSAFE_CODE_EXECUTION=1

手元のmacOSやWindowsで直接有効にするのは勧めません。LLMが書いたコードが利用者の権限でそのまま動くためです。有効にするならDocker Composeで起動し、コンテナの中で動かします。compose.yml はリポジトリ全体をコンテナの /app にマウントしているので、コンテナ内でもリポジトリ配下のファイルは書き換えられる点は残ります。なお、PyPIの chatdev 0.1.0は3月の配布でこの修正を含まず、ゲート自体がありません。

YAMLワークフローの定義と実行

graph・nodes・edgesの最小構成

2.0のワークフローは、graph の下に nodes・edges・入口の start・出口の end を書きます。次は、要約役が作った下書きをレビュー役が読みやすく整える2ノードの例です。${API_KEY} と ${BASE_URL} は .env の値に置き換わります。name は使うプロバイダのモデル名に合わせてください。

version: 0.0.0
graph:
  id: summary_review
  description: 要約してからレビューで直す2段のワークフロー
  log_level: INFO
  start:
    - Writer
  end:
    - Reviewer
  nodes:
    - id: Writer
      type: agent
      config:
        provider: openai
        base_url: ${BASE_URL}
        api_key: ${API_KEY}
        name: gpt-4o
        role: |
          入力された文章を300字以内の日本語で要約してください。
    - id: Reviewer
      type: agent
      config:
        provider: openai
        base_url: ${BASE_URL}
        api_key: ${API_KEY}
        name: gpt-4o
        role: |
          受け取った要約の重複と曖昧な表現を直し、300字以内の最終版だけを出力してください。
  edges:
    - from: Writer
      to: Reviewer

ノードの type には agent のほか、人間の入力を待つ human、回数で抜けるループ用の loop_counter などがあります。書き間違い（存在しないノードへのエッジ、未定義の type など）は、run.py がタスク文を聞く前の読み込みで DesignError として止まります。READMEにある make validate-yamls は、2026年10月31日時点のmainでは呼び出し先の check.check に実行用の入口が無く、壊したYAMLでも成功扱いになるため検証には使えません。項目の全体像は uv run python run.py --inspect-schema でJSONとして出力されます。

run.pyによるCLI実行と引数

2.0の run.py は --path（ワークフロー定義）と --name（プロジェクト名）を取り、起動後に「Please enter the task prompt:」とタスク文を標準入力で聞いてきます。--attachment で初期メッセージにファイルを添付でき、複数回指定できます。

# 上のYAMLを yaml_instance/summary_review.yaml に保存して実行
uv run python run.py --path yaml_instance/summary_review.yaml --name summary_demo

# 1.0の仮想ソフトウェア会社を2.0上で動かす（コード実行の許可が必要）
uv run python run.py --path yaml_instance/ChatDev_v1.yaml --name gomoku

1.0の --task（作りたいソフトの説明）や --model（GPT_3_5_TURBO 等の列挙値）は2.0の run.py にはありません。タスク文は実行時の入力に、モデル指定はYAMLの name と .env に移りました。

Python SDKによるワークフロー実行

複数の入力を順に流すなら、Python SDKの run_workflow() が向いています。リポジトリ内ではそのまま使え、PyPIの chatdev（0.1.0・Python 3.12以上3.14未満）としても配布されています。

# リポジトリ内のSDK（PyPI版は from chatdev import run_workflow）
from runtime.sdk import run_workflow

result = run_workflow(
    "yaml_instance/summary_review.yaml",
    task_prompt="要約したい本文をここに入れる",
    attachments=None,
    variables={"API_KEY": "sk-..."},  # .env の値を上書きしたいときだけ
)
if result.final_message:
    print(result.final_message.text_content())

戻り値の final_message は end に書いたノードの出力です。PyPI版の chatdev.run_workflow は戻り値が ChatDevResult で、ノードごとのモデル設定を差し替える agent_configs 引数を持つなど、リポジトリ内のSDKと形が違います。PyPI版は10月の安全修正より前の配布なので、コード実行を伴うワークフローをSDKで回すなら、修正が入ったmainをクローンしてリポジトリから使います。

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

日本語のChatDev解説の多くは2023〜2024年に書かれ、pip3 install -r requirements.txt のあと python3 run.py --task "..." を実行する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_MINI までしかありません。道具として使うなら2.0の ChatDev_v1.yaml で同じ工程を動かすほうが、モデル指定もツール連携も現行の仕様に乗ります。1.0ブランチは当時の実装を確かめるための保存先と割り切るのが妥当です。

ChatDevを採用すべきでない場面と他フレームワークとの使い分け

既存リポジトリの改修・単発タスクでの採用判断

ChatDev_v1.yaml のような標準のコード生成ワークフローは、ゼロから小規模なプログラムを書き起こす前提で組まれています。1.0には既存コードを起点にする --config "incremental" もありましたが、既存リポジトリへの機能追加や、テストを通しながらのリファクタリングに使うなら、読み込み・差分適用・テスト実行のノードを自分で設計する必要があります。その手間を考えると、リポジトリ全体を読んで差分を出すコーディングエージェントのほうが手早く済みます（Coding Agent（コーディングエージェント）とは？仕組み・3つの型と主要ツールの料金・選び方【2026年10月】で各ツールを比べています）。

単発の質問応答や短い定型処理に持ち出すのも過剰です。エージェントを増やして往復させるほどLLMの呼び出しは増え、費用と実行時間が積み上がります。シングルエージェントとは？マルチエージェントとの違いと使い分けの判断基準【2026年10月】で整理しているとおり、分割・並列化・相互批評が効かないタスクは1体のほうが速く安く済みます。ChatDevが合うのは、工程を分けて役割ごとに批評させる価値がある、ある程度まとまった生成タスクです。

ローカルLLMで回すときの限界

OllamaやLM Studioでも起動はしますが、モデル側の要件はREADMEに書かれていません。ChatDev_v1.yaml は9体のエージェントがループを挟んで往復し、会話履歴の分だけ入力も長くなります。まず上の2ノード程度の小さなワークフローで、指示した出力形式と字数が守られるか、ツール呼び出しが返るかを確かめてから、ノード数の多いテンプレートへ広げます。

MetaGPT・CrewAI・LangGraphとの違い

ChatDev 2.0の特徴は、ワークフローをYAMLとWeb UIで組み、コードを書かずに実行まで持っていける点です。同じく「ソフトウェア会社」を模したMetaGPTは、標準作業手順（SOP）を役割に落とし込むPythonのフレームワークで、考え方はAgent SOPとは？LLMエージェントを標準作業手順で制御する仕組みと実装判断が詳しく扱っています。アプリケーションに組み込んで状態や承認フローまで制御したいなら、CrewAIやLangGraphでAIエージェントを実装する手順のようにコードで定義する系統が向きます。主要8種の比較はAIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】にまとめています。ChatDevは試作や研究で構成を素早く組み替える用途、業務システムへの組み込みはコード定義の系統、と分けて考えると選びやすくなります。業務に合わせたエージェントの設計・構築を外部に任せる場合は、AIエージェント開発の支援も検討材料になります。

よくある質問

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 APIはモデルによって無料枠があり、その範囲を超えると課金されます。費用をかけない場合は .env の BASE_URL をOllamaやLM Studioに向けてローカルモデルで動かします。

ChatChainとは何ですか？

1.0で使われた協調設計の名称で、開発工程をフェーズに分け、各フェーズを指示役と実行役のエージェント2体の対話として順に実行する仕組みです。2.0では、工程の並び自体をグラフで自由に定義する形へ一般化されました。

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

動きます。2.0は .env の BASE_URL と API_KEY、YAMLの provider と name でモデルを指定する設計で、.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）が該当します。2.0のプラットフォーム自体は「ChatDev 2.0: A No-Code Multi-Agent Platform for Developing Everything」（arXiv:2609.00714、2026年9月公開・EMNLP 2026 Demo Track採択）で説明されています。

関連記事

• AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】
• マルチエージェントとは？仕組み・構成パターンと採用判断を研究データで解説【2026年10月】
• シングルエージェントとは？マルチエージェントとの違いと使い分けの判断基準【2026年10月】
• Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】
• Coding Agent（コーディングエージェント）とは？仕組み・3つの型と主要ツールの料金・選び方【2026年10月】