ag2 v1.0 は AutoGen 系の書き換えだった：autogen 名前空間を捨てた AgentOS の中身
AG2 (formerly AutoGen): The Open-Source AgentOS.Join us at: https://discord.gg/sNGSwQME3x
ひと目でわかる
- これは何？
- AG2 v1.0 は Classic からの drop-in アップグレードではない。import 名、中核エージェント、複数エージェントの編成方式がすべて変わり、Classic は別リポジトリの ag2-classic として残っている。移行を決める前に、何が同じで何が別物なのかを README の記述から整理する。
- 誰に向いている？
- 新規プロジェクトで Python 3.10 以上を使い、async 前提の設計を許容できるなら ag2 を選ぶ理由はある。ConversableAgent と GroupChat で組まれた既存コードを抱えているチームは、ag2-classic を固定して classic.docs.ag2.ai を見るべきで、ag2>=1.0 への置き換えは移行作業そのものである。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
v1.0 で autogen 名前空間は切り離された
このリポジトリの最大の特徴は機能ではなく、パッケージの分割そのものにある。README の冒頭には、ConversableAgent、GroupChat、import autogen を探しているならそれは AG2 Classic だと明記されている。AG2 v1.0 以降、protocol 駆動のフレームワークがトップレベルのパッケージになり、import ag2 として読み込む。Classic 側は ag2ai/ag2-classic という別リポジトリに移り、classic.docs.ag2.ai で文書化されている。
つまり pip install ag2 は、かつての autogen パッケージの後継ではあるが、同じ名前空間を提供しない。README は「This repository (pip install ag2) no longer ships the autogen import name or the classic agent classes」と述べている。autogen という import 行が残っているプロジェクトは、依存を ag2 に上げた瞬間に動かなくなる。
移行ガイドは Network のドキュメント配下、docs.ag2.ai/docs/user-guide/network/migration_from_group_chat/ に置かれている。GroupChat から Network への移行が、この書き換えの中心だという配置になっている。
Agent と Network：編成の単位が変わった
README の比較表では、Classic の中核エージェントが ConversableAgent であるのに対し、AG2 v1.0 側は Agent とされている。複数エージェントの編成も、Classic の GroupChat、swarms、nested chats から、Network（hub + channels）へと変わった。
GroupChat が会話の参加者を並べて発言順を管理する仕組みだとすれば、Network は hub と channel という接続の構造でエージェント間の経路を表す。README はこの違いを表の1行で示すにとどまり、hub や channel の具体的な API には触れていない。詳細は docs.ag2.ai の Network 概要ページに委ねられている。この記事の材料から確認できるのは、編成の抽象が「会話」から「接続」に移ったという一点である。
エージェントの機能面としては、エージェント同士の相互作用、各種 LLM の利用、ツール利用、自律実行と human-in-the-loop、複数エージェントの会話パターンが README に列挙されている。目次には agent harness として knowledge と compaction という項目もあり、文脈の圧縮を framework 側の責務として扱う構成が見える。
インストールは extra で Provider を選ぶ
対応 Python は 3.10 以上。PyPI 上の名前は ag2 で、既定では最小限の依存だけが入る。使うモデル Provider に合わせて extra を指定する。README が挙げているのは ag2[openai]、ag2[anthropic]、ag2[gemini]、ag2[ollama] で、末尾は「and so on」とされている。
コマンドはシェルによって書き方が変わる。Windows と Linux では pip install ag2[openai]、Mac では pip install 'ag2[openai]' とクォートする。zsh が角括弧をグロブとして解釈するためで、これは AG2 固有の話ではなくシェルの挙動だが、README が明示的に書き分けている以上、コピーする側も区別したほうがいい。
API キーは Provider ごとの標準的な環境変数から読まれる。README の例は export OPENAI_API_KEY="<your-api-key>" で、ANTHROPIC_API_KEY や GEMINI_API_KEY も同様とされている。キーをコードに埋め込まない前提の設計である。
キーを明示的に渡す経路も用意されている。README は OpenAIConfig(model="gpt-4o-mini", api_key=...) という形を挙げ、リクエストごとにキーが変わる場合に有用だとしている。マルチテナントの SaaS に組み込むなら、環境変数ではなくこの経路を使うことになる。
もう一点、AG2 は全体が async だと README は述べている。この一文は途中で切れているため、具体的な API 名や await の付け方は確認できない。同期関数の中でそのまま呼べる保証は、この材料からは読み取れない。
Classic からの移行は「アップグレード」ではない
README の注意書きは率直である。AG2 v1.0 は Classic からの drop-in upgrade ではなく、agent model、orchestration、imports のすべてが変わったと書かれている。3つとも変わると明言されている以上、依存バージョンを上げてテストが通ることを期待するのは現実的でない。
Classic 側に留まる判断も README は否定していない。autogen は引き続きメンテナンスされ、インストール可能で、既存コードは動き続ける。移行する場合は ag2>=1.0 ではなく ag2-classic を固定する、という指示が pip install ag2-classic というコマンドで示されている。
ここで実務上の分岐点になるのは、コード内に import autogen、from autogen import ConversableAgent, GroupChat、from autogen import AssistantAgent, UserProxyAgent のいずれかが現れるかどうかだ。README はこれを判別条件として提示している。1行でも該当すれば Classic 側であり、参照すべき文書は classic.docs.ag2.ai になる。
つまりこのリポジトリは、既存ユーザーをそのまま引き継ぐ形の v1.0 ではない。新規に設計する層と、既存を維持する層を、リポジトリ単位で分離した再出発である。
この分割が向くケース、向かないケース
新規にエージェントを組み、async を前提にした設計を最初から書けるなら、ag2 の側を選ぶ理由はある。Provider ごとの extra で依存を絞れる点、キーを環境変数か Config オブジェクトで渡せる点は、構成管理の上で素直だ。
逆に、GroupChat と ConversableAgent で既に動いている業務コードを抱えている場合、ag2 への移行はライブラリ更新ではなく移植作業になる。README 自身が agent model と orchestration の変更を認めているので、会話の制御ロジックは Network の hub + channels に合わせて書き直す前提で見積もる必要がある。
もうひとつの注意点は、README が Network の詳細をほとんど書いていないことだ。比較表の1行と移行ガイドへのリンク以外に、hub や channel の API、エラーの扱い、会話の終了条件についての記述はこの材料にはない。GroupChat で使っていた発言順の制御や停止条件が Network でどう表現されるかは、docs.ag2.ai の Network 概要を読むまで判断できない。ここは文書が薄い領域だと見ておいたほうがいい。
向かない例をもうひとつ挙げる。Python 3.9 以前の環境しか用意できない場合、AG2 は 3.10 以上を要求するので選択肢に入らない。Classic 側の要件はこの材料からは分からないが、少なくとも ag2 側は 3.10 が下限である。
比較対象としての LangGraph と CrewAI
複数エージェントの編成を扱う Python の枠組みとしては、LangGraph と CrewAI が挙げられる。LangGraph は処理をグラフのノードと辺として明示的に定義し、状態の遷移を開発者が書き下す。CrewAI は役割を与えたエージェントの集まりを crew として定義し、タスクを割り当てる。AG2 の Network は hub と channel という接続構造でエージェント間をつなぐ、という表現をとる。
三者の違いは抽象の置き方にある。LangGraph は制御フローを、CrewAI は役割とタスクを、AG2 は接続を前面に出す。GroupChat から Network への移行ガイドが用意されていることからも、AG2 自身が「会話の並び」から「接続の構造」へ抽象を移したと読める。
ただし、この比較は README に書かれた AG2 側の記述と、各プロジェクトの一般的な位置づけに基づくもので、同一タスクでの挙動を比べたものではない。どの抽象が自分の問題に合うかは、扱いたい制御がフローなのか役割なのか接続なのかで決めるしかない。AG2 を選ぶなら、GroupChat で書いていた逐次の発言制御を Network でどう表すかを、移行ガイドで先に確認しておきたい。
Apache-2.0 とメンテナンスの見取り図
ライセンスは Apache-2.0。特許許諾条項を含む寛容なライセンスで、商用利用や改変、再配布が可能とされる。ただし本記事は法的助言ではない。自社の利用形態がライセンス条件を満たすかは、法務担当者かライセンス全文で確認してほしい。
メンテナンス体制について README が述べているのは、複数組織の有志による maintainer グループが運営しているという点と、maintainer に関心があれば Chi Wang と Qingyun Wu に連絡するという案内である。企業が単独で抱える体制ではないことが読み取れる。
リリースは v1.0.2 が 2026-08-15、v1.0.3 が 2026-08-28、v1.0.4 が 2026-09-07 で、およそ2週間間隔。1.0 系のパッチが継続して出ている状態で、破壊的変更が続いている最中ではない。
アップグレード費用で見落としやすいのは、extra の選び方だ。Provider を追加するたびに ag2[anthropic] のような extra を依存に足す必要があり、requirements や lock ファイルの更新が Provider の切り替えと連動する。また Classic と ag2 を同じ環境に入れる場合、import autogen と import ag2 が別パッケージとして共存することになる。名前空間が分かれているので衝突はしないが、どちらのドキュメントを見るべきかをチーム内で決めておかないと、参照先が混ざる。
編集部の結論
新規プロジェクトで Python 3.10 以上を使い、async 前提の設計を許容できるなら ag2 を選ぶ理由はある。ConversableAgent と GroupChat で組まれた既存コードを抱えているチームは、ag2-classic を固定して classic.docs.ag2.ai を見るべきで、ag2>=1.0 への置き換えは移行作業そのものである。採用前に確認すべきは、自分の Provider に対応する extra が存在すること、そして Network の hub + channels が自分の編成要件を満たすかどうか。この2点が確認できないうちは、pip install ag2 を実行しないほうがいい。
コミュニティノート