9.6.6 AutoGen【選択】

この節の位置づけ

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

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

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

学習目標

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

---

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

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

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

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

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

• プランナーはコーダーにどう依頼すべきか？
• コーダーが書き終えたら、どうやってレビュー担当に渡すのか？
• レビュー担当のフィードバックは、どう次のラウンドを前に進めるのか？

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

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

生活のたとえ

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 回で終わりません。

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

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

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

conversation = [
    {"from": "planner", "to": "coder", "content": "ステータス正規化関数を書いてください"},
    {"from": "coder", "to": "executor", "content": "def normalize_status(status): return status.strip().lower()"},
    {"from": "executor", "to": "reviewer", "content": "実行結果：normalize_status('  OPEN ')=open"},
    {"from": "reviewer", "to": "coder", "content": "不正な入力の処理を追加してください"}
]

for turn in conversation:
    print(turn)

想定出力：

{'from': 'planner', 'to': 'coder', 'content': 'ステータス正規化関数を書いてください'}
{'from': 'coder', 'to': 'executor', 'content': 'def normalize_status(status): return status.strip().lower()'}
{'from': 'executor', 'to': 'reviewer', 'content': "実行結果：normalize_status('  OPEN ')=open"}
{'from': 'reviewer', 'to': 'coder', 'content': '不正な入力の処理を追加してください'}

この例は、多くの AutoGen チュートリアルで見かけるワークフローの骨組みにかなり近いです。

---

AutoGen の本当の強みは何か？

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

• プランナーがコードを書き始める
• レビュー担当が検索までやり始める

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

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

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

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

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

---

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

CrewAI との違い

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

• 役割
• タスク
• チーム

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

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

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

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

LangGraph との違い

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

• トレース記録
• 最大ターン数
• 役割の権限境界
• フェイルバック

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

• すごく賢そうに見える

しかし実際には、

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

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

---

小結

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

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

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

---

残す証拠

このページを終えたら、この証拠カードを残します。

問題の形

ワークフローグラフ、検索アプリ、役割チーム、または実験

フレームワーク選択

どの抽象化を追加し、何を隠すか

追跡記録

state、node、tool call、message、または run id

失敗確認

フレームワークの魔法が状態、再試行、または権限を隠す

判断

シングルエージェントのループが明確になってからフレームワークを選ぶ

練習

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

解法と解説

1. 基本 flow は、planner が task と acceptance criteria を定義し、coder が実装案や修正を出し、reviewer が correctness と risk を確認し、planner が次の round の必要性を判断する形です。
2. AutoGen 型は会話が増えすぎやすいです。conversation 自体が control mechanism だからです。停止条件、role 境界、review criteria がなければ、Agent は完了せず交渉を続けがちです。
3. AutoGen は Agent 間の conversational interaction を重視します。CrewAI は role / task organization を重視します。実務では重なりますが、mental model が設計を変えます。
4. 強い state-machine control が必要なら、conversational abstraction は第一候補でない場合があります。state、上限、transition、traceability を明確に強制できる場合だけ使います。