9.6.6 AutoGen【選択】

この節の位置づけ

もし一部のフレームワークが「ワークフロー図」や「知識整理レイヤー」に近いとしたら、AutoGen の第一印象はだいたいこうです：

複数の Agent が、何度もメッセージをやり取りしながら協力してタスクを完成させる。

大事なのは「役割が多い」ことではなく、「対話でタスクを進める」ことです。

学習目標

AutoGen スタイルのシステムが、なぜ複数 Agent の対話を重視するのかを理解する
LangGraph / CrewAI のようなフレームワークとの本質的な違いを整理する
最小限の AutoGen スタイルのメッセージループを読めるようになる
この種のフレームワークが特に向いている場面と、暴走しやすい場面を知る

AutoGen スタイルのいちばん核心的な直感は何か？

先にフローを図にするのではなく、まず役割を「会話させる」

多くのフレームワークは、まず次のように考えます。

現在の状態は何か？
次はどのノードへ進むのか？

AutoGen スタイルは、もっとこう問いかけます。

planner は coder にどう依頼すべきか？
coder が書き終えたら、どうやって reviewer に渡すのか？
reviewer のフィードバックは、どう次のラウンドを前に進めるのか？

つまり、システムを次のように抽象化します。

互いにメッセージを送り合う役割の集合。

生活のたとえ

AutoGen スタイルのシステムは、グループチャットの仕事用チャンネルのようなものだと考えられます。

プロダクトマネージャーが要件を伝える
開発者がタスクを受け取る
レビュー担当が問題点を返す
みんなで何度もやり取りを続ける

このたとえはとても大切です。なぜなら、このフレームワークが得意なタスクの形を、そのまま表しているからです。

なぜこの「対話型マルチ Agent」は自然に感じられるのか？

それは、複雑なタスクの多くがもともとこういう形をしているからです。

まず要件を出す
次に試してみる
その後、フィードバックに合わせて修正する

たとえば：

コード生成とレビュー
研究レポートの作成
問題の切り分け

これらのタスクは一直線ではなく、何度も往復する形になりがちです。
そのため、AutoGen スタイルの抽象化は人間の協働の感覚にとても近いのです。

最小限の AutoGen スタイルの例

まずは本物のフレームワークを使わず、純粋な Python で「複数回の対話による協調」の雰囲気をつかみましょう。

messages = []

def send(sender, receiver, content):
    msg = {
        "from": sender,
        "to": receiver,
        "content": content
    }
    messages.append(msg)
    return msg

send("planner", "coder", "返金対象かどうかを判定する関数を実装してください。")
send("coder", "reviewer", "初版を書きました。確認してください。")
send("reviewer", "coder", "学習進度が 20% を超えた場合の処理を追加してください。")

for msg in messages:
    print(msg)

想定出力：

{'from': 'planner', 'to': 'coder', 'content': '返金対象かどうかを判定する関数を実装してください。'}
{'from': 'coder', 'to': 'reviewer', 'content': '初版を書きました。確認してください。'}
{'from': 'reviewer', 'to': 'coder', 'content': '学習進度が 20% を超えた場合の処理を追加してください。'}

このコードは単純ですが、何を教えているのでしょうか？

このコードが教えているのは次のことです。

協調の単位は「メッセージ」である
システムは「誰が誰に何を言ったか」によって進む
複数 Agent だからといって、最初から明示的な状態図が必須なわけではない

これが AutoGen スタイルの最も基本的な入り口です。

なぜ AutoGen は「コード実行」系の場面とよく結びつくのか？

この種の場面は、もともと多段階のフィードバックに向いているから

コードのタスクは、たいてい 1 回で終わりません。

まずコードを書く
次に実行する
エラーを見る
さらに修正する

この流れは、AutoGen のメッセージ往復の模式ととても相性が良いです。

最小限の「書く -> 実行する -> フィードバックする」のイメージ

conversation = [
    {"from": "planner", "to": "coder", "content": "割引計算関数を書いてください"},
    {"from": "coder", "to": "executor", "content": "def discount(price): return price * 0.7"},
    {"from": "executor", "to": "reviewer", "content": "実行結果：discount(100)=70"},
    {"from": "reviewer", "to": "coder", "content": "不正な入力の処理を追加してください"}
]

for turn in conversation:
    print(turn)

想定出力：

{'from': 'planner', 'to': 'coder', 'content': '割引計算関数を書いてください'}
{'from': 'coder', 'to': 'executor', 'content': 'def discount(price): return price * 0.7'}
{'from': 'executor', 'to': 'reviewer', 'content': '実行結果：discount(100)=70'}
{'from': 'reviewer', 'to': 'coder', 'content': '不正な入力の処理を追加してください'}

この例は、多くの AutoGen 教材で見かけるワークフローの骨組みにかなり近いです。

AutoGen の本当の強みは何か？

「複数の役割が往復しながら協力する」表現が自然

特に得意なのは、次のような関係です。

planner <-> worker
writer <-> reviewer
coder <-> executor <-> critic

このような、複数ラウンドのフィードバック関係です。

プロトタイプや実験に向いている

最初から状態図をきっちり描かなくてもよいからです。
まずは次のように始められます。

いくつかの役割を定義する
それらに対話させる
その後で、システムの進み方を観察する

探索段階では、このやり方に大きな価値があります。

ただし AutoGen スタイルのリスクも理解しておこう

メッセージの往復回数が簡単に増えすぎる

システムが主にメッセージ往復で進むと、次のようなことが起きやすくなります。

何度も話しすぎる
同じ議論を繰り返す
すでに十分な情報があるのに、まだ続けてしまう

役割の境界があいまいになりやすい

各役割の境界をはっきり決めないと、こうなりがちです。

planner がコードを書き始める
reviewer が検索までやり始める

その結果、役割分担がどんどん崩れていきます。

終了条件を明確にしないといけない

「いつ終わるのか」のルールがないと、システムは非常に長く走り続けやすくなります。

だから、AutoGen でとても重要なエンジニアリング上の原則は次の通りです。

対話は自然でよいが、終了条件は必ず明確にすること。

CrewAI、LangGraph との違いはどこにあるのか？

CrewAI との違い

CrewAI は、次の点をより強く意識します。

役割
タスク
チーム

一方、AutoGen は次の点をより強く意識します。

役割同士のメッセージ往復
どう会話が進むか

ざっくり覚えるなら、次の区別がわかりやすいです。

CrewAI は「チームの担当表」に近い
AutoGen は「チームの会話による協働」に近い

LangGraph との違い

LangGraph は、次の点をより強く意識します。

明示的な状態
ノード
条件付きエッジ

AutoGen は、次の点をより強く意識します。

対話のターン数
会話のラウンド進行

そのため、「チャットのようにタスクが進む」システムを表現するなら、AutoGen のほうが自然に感じられることがあります。

どんなときに AutoGen を選ぶ価値があるのか？

特に向いているのは、次のような場面です。

複数ラウンドの相談が必要なタスク
コード生成 + 実行 + フィードバック
執筆 + レビュー + 修正
プロトタイプや探索的な実験

あまり向いていない可能性があるのは、次のような場面です。

厳密な状態機械制御が必要な本番システム
分岐が複雑で、しかも強い制御が必要なフロー

つまり、AutoGen は次のようなものに近いです。

「会話型協働」を表現するのにとても向いているフレームワーク。

実務でとても大事な注意点

AutoGen スタイルのシステムを本格的に作るなら、できるだけ早く次を入れておくのがよいです。

trace
最大ターン数
役割の権限境界
フェイルバック

これらがないと、システムは簡単に次のようになってしまいます。

すごく賢そうに見える

しかし実際には、

よく話すけれど、効率は低い

という状態に落ちやすいです。

小結

この節でいちばん大事なのは、AutoGen という名前を覚えることではなく、次を理解することです。

AutoGen は、「複数の役割が対話を通じて順番にタスクを進める」システムを表現するのが得意である。

タスクがもともとグループチャットの協働に近いなら、このフレームワークはとても自然です。
ただし、強い状態制御が必要な場合は、ターン数と収束条件に特に注意する必要があります。

練習

planner -> coder -> reviewer の 3 役割メッセージフローを設計してみましょう。
考えてみましょう。なぜ AutoGen スタイルのタスクでは「話しすぎる」問題が起きやすいのでしょうか？
自分の言葉で説明してみましょう。AutoGen と CrewAI の核心的な違いは何ですか？
あなたのタスクに強い状態機械の制御が必要なら、このような対話型抽象化を最優先で選びますか？なぜですか？

学習目標​

AutoGen スタイルのいちばん核心的な直感は何か？​

先にフローを図にするのではなく、まず役割を「会話させる」​

生活のたとえ​

なぜこの「対話型マルチ Agent」は自然に感じられるのか？​

最小限の AutoGen スタイルの例​

このコードは単純ですが、何を教えているのでしょうか？​

なぜ AutoGen は「コード実行」系の場面とよく結びつくのか？​

この種の場面は、もともと多段階のフィードバックに向いているから​

最小限の「書く -> 実行する -> フィードバックする」のイメージ​

AutoGen の本当の強みは何か？​

「複数の役割が往復しながら協力する」表現が自然​

プロトタイプや実験に向いている​

ただし AutoGen スタイルのリスクも理解しておこう​

メッセージの往復回数が簡単に増えすぎる​

役割の境界があいまいになりやすい​

終了条件を明確にしないといけない​

CrewAI、LangGraph との違いはどこにあるのか？​

CrewAI との違い​

LangGraph との違い​

どんなときに AutoGen を選ぶ価値があるのか？​

実務でとても大事な注意点​

小結​

練習​