--- title: "ChatDev 2.0（DevAll）チュートリアル｜導入手順・YAMLの書き方と1.0との違い【2026年10月】" url: "https://www.issoh.co.jp/tech/details/10820/" published: 2026-02-02 updated: 2026-10-31 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # ChatDev 2.0（DevAll）チュートリアル｜導入手順・YAMLの書き方と1.0との違い【2026年10月】 ChatDevは、LLMを載せた複数のAIエージェントを協調させて成果物を作らせるオープンソースのフレームワークです。開発元はOpenBMBで、ライセンスはApache-2.0、[GitHubリポジトリ](https://github.com/OpenBMB/ChatDev)のスターは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年版】](/tech/details/12108/)で確認できます。 ### リポジトリの実体：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にだけ入っています。 | 時期 | 版 | 主な変更 | | ---------- | ------------------ | ----------------------- | | 2026-01-07 | v2.0.0 | 2.0（DevAll）正式リリース | | 2026-01-22 | v2.1.0 | バッチ実行・Laboratory画面 | | 2026-03-21 | PyPI chatdev 0.1.0 | Python SDKの配布開始 | | 2026-03-23 | v2.2.0 | OpenClaw連携・SDK・Docker構成 | | 2026-10-16 | main（未リリース） | コード実行の既定無効化 | [v2.1.0のリリースノート](https://github.com/OpenBMB/ChatDev/releases/tag/v2.1.0)では、複数タスクをまとめて流すバッチ実行と、その結果を比べる実験用のLaboratory画面が追加されました。旧来のChat Completions形式のAPIへの対応と、関数呼び出しまわりの不具合修正もこの版です。[v2.2.0](https://github.com/OpenBMB/ChatDev/releases/tag/v2.2.0)では、OpenClawのエージェントチームをワークフローから呼べるようになり、Python SDKとDocker Composeでの開発環境が加わりました。 ## 1.0と2.0の違い：開発用ChatChainから汎用グラフワークフローへ | 観点 | ChatDev 1.0 | ChatDev 2.0（DevAll） | | ------ | -------------------- | ------------------------- | | ブランチ | chatdev1.0 | main | | 対象 | ソフトウェア開発 | 開発／可視化／3D／リサーチ | | 中核概念 | ChatChain（JSONで設定） | グラフのワークフロー | | 定義方法 | Python＋CompanyConfig | YAML／Web UI／SDK | | 依存管理 | requirements.txt | uv（pyproject.toml） | | Python | 3.9 | 3.12系 | | UI | CLI＋ログ可視化 | Web UI（FastAPI＋Vue 3） | | モデル指定 | –model の列挙値 | .env の BASE\_URL／API\_KEY | ### ChatChain（1.0）：役割ペアの二者対話による工程進行 1.0の中核はChatChainと呼ばれる設計です。開発を設計・コーディング・テスト・文書化のフェーズに分け、各フェーズを指示役と実行役のエージェント2体の対話に落とし込みます。論文「[ChatDev: Communicative Agents for Software Development](https://arxiv.org/abs/2307.07924)」（arXiv:2307.07924、ACL 2024採択）が提案したCommunicative Dehallucinationは、実行役が即答せずに指示役へ質問を返して条件を確定させ、思い込みによる誤生成を減らす仕組みです。 ### MacNetとPuppeteer（2.0）：DAGと中央オーケストレータ 2.0の背景にあるのは、エージェントのつながりを有向非巡回グラフ（DAG）で表すMacNet（[arXiv:2406.07155](https://arxiv.org/abs/2406.07155)、ICLR 2025採択）と、強化学習で最適化される中央オーケストレータを提案した論文（[arXiv:2505.19591](https://arxiv.org/abs/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は[ワークフロー定義のガイド](https://github.com/OpenBMB/ChatDev/blob/main/docs/user%5Fguide/en/workflow%5Fauthoring.md)のとおり `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](https://github.com/OpenBMB/ChatDev/commit/5f8142d4)」で、ワークフローが持ち込んだコードの実行は既定で止まるようになりました。対象は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](https://pypi.org/project/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月】](/tech/details/7036/)で各ツールを比べています）。 単発の質問応答や短い定型処理に持ち出すのも過剰です。エージェントを増やして往復させるほどLLMの呼び出しは増え、費用と実行時間が積み上がります。[シングルエージェントとは？マルチエージェントとの違いと使い分けの判断基準【2026年10月】](/tech/details/4261/)で整理しているとおり、分割・並列化・相互批評が効かないタスクは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エージェントを標準作業手順で制御する仕組みと実装判断](/tech/details/13287/)が詳しく扱っています。アプリケーションに組み込んで状態や承認フローまで制御したいなら、[CrewAI](/tech/details/13598/)や[LangGraphでAIエージェントを実装する手順](/tech/details/17447/)のようにコードで定義する系統が向きます。主要8種の比較は[AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】](/tech/details/15367/)にまとめています。ChatDevは試作や研究で構成を素早く組み替える用途、業務システムへの組み込みはコード定義の系統、と分けて考えると選びやすくなります。業務に合わせたエージェントの設計・構築を外部に任せる場合は、[AIエージェント開発の支援](/service/ai/agent/)も検討材料になります。 ## よくある質問 ### 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](https://arxiv.org/abs/2609.00714)」（arXiv:2609.00714、2026年9月公開・EMNLP 2026 Demo Track採択）で説明されています。 ## 関連記事 - [AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】](/tech/details/15367/) - [マルチエージェントとは？仕組み・構成パターンと採用判断を研究データで解説【2026年10月】](/tech/details/13604/) - [シングルエージェントとは？マルチエージェントとの違いと使い分けの判断基準【2026年10月】](/tech/details/4261/) - [Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】](/tech/details/12108/) - [Coding Agent（コーディングエージェント）とは？仕組み・3つの型と主要ツールの料金・選び方【2026年10月】](/tech/details/7036/) --- 出典: [ChatDev 2.0（DevAll）チュートリアル｜導入手順・YAMLの書き方と1.0との違い【2026年10月】]()（株式会社一創）