AutoGen (Microsoft Multi-Agent Conversation Framework)

AutoGenのGroupChatメカニズムは具体的にどのように機能しますか？GroupChatManagerはどのように次の発言者を決定しますか？

AutoGen GroupChatは複数のConversableAgentを定義することで機能します。各Agentはその役割を定義する独自のSystem Promptを持ちます。これらのAgentを最大ラウンドとspeaker_selection_methodを指定したGroupChatオブジェクトに追加します。発言者選択オプション：auto（デフォルト）：GroupChatManagerがLLM推論を使用して次の最も適切な発言者を決定します——最も柔軟ですが最も予測不可能です。round_robin：事前定義された順序でAgentを順番に発言させます——最も予測可能ですが動態性を失います。カスタム関数：現在の会話状態とAgentリストに基づいて次の発言者を返すPython関数を定義できます。クリプト分析シナリオへの推奨：カスタム関数を使用して明確な議論フローを設計します（テクニカル分析 → オンチェーンデータ → マクロ分析 → 最終統合）。

AutoGenとLangGraph（LangChainのマルチエージェントフレームワーク）のクリプトシナリオでの最大の違いは何ですか？どちらを選びますか？

LangGraphのコアアドバンテージ（実行レイヤーに適している）：DAGワークフローは実行パスを完全に決定論的にします。これによりテスト可能性・監査可能性・Prompt Injectionへの優れた防御が実現します（Agent間の通信は自由形式の自然言語ではなく事前定義されたState辞書を通じて行われます）。資金操作認可を持つAgentレイヤーでは、「柔軟性」より「これらの特性」が重要です。AutoGenのコアアドバンテージ（分析レイヤーに適している）：マルチAgentの動的な議論が意思決定の品質を向上させます。選択の原則：LangGraphを使って確定論的な「決定 → 実行」フローを構築し；AutoGenを使って「入力 → 多角度分析 → 分析レポート出力」の議論フローを構築します。完全なクリプトAgentシステムでは両方を組み合わせることができます。

AutoGen 2.0とAutoGen 0.x（旧バージョン）の主要なアーキテクチャ変更は何ですか？旧バージョンから移行する際に注意すべきことは何ですか？

AutoGenは2025年にバージョン2.0をリリースし、重要なアーキテクチャ変更がありました。旧バージョンのユーザーが移行するには以下のコアの違いを理解する必要があります：

最大のアーキテクチャ変更：AutoGen 2.0はコアの抽象として「Actorモデル」を導入し、Agentを異なるランタイム（runtime）で実行できる独立したActorとして定義しました（Pythonプロセス内のオブジェクトだけでなく）。これによりAutoGen 2.0のAgentを異なるマシンや異なる言語環境（Pythonだけでなく）に分散させることができ、より大規模なマルチエージェントデプロイメントをサポートします。

APIレベルの破壊的変更：AutoGen 0.xのConversableAgent・AssistantAgent・UserProxyAgentは2.0で新しい等価物を持ちます（AssistantAgentは2.0でも存在しますが内部実装が完全に書き直されています）。GroupChatとGroupChatManagerの初期化パラメータが調整されています。

移行上の注意事項：AutoGen 2.0は移行ガイドを提供していますが、古いコードは直接2.0で実行できません。主な移行作業：Agentの初期化方法の更新・GroupChatの設定方法の更新・使用しているモデルAPIフォーマットがまだ互換性があるか確認（2.0はOpenAI互換APIのサポートが最も良い）。

推奨事項：2025年以降にAutoGenを使い始めるなら直接バージョン2.0を使用します；既存の0.xコードは、移行前に隔離されたテスト環境で完全な機能テストを実行し、すべてのGroupChatの動作が一致することを確認してから移行します。実際の資金を持つAgentがまだ使用している環境では直接アップグレードしないでください。まったく新しいテスト環境で検証してから移行してください。

AutoGenの「コード実行」機能はクリプトシナリオでどのような潜在性とリスクがありますか？

AutoGenのコード実行機能は、Agentが実際のPythonコードを生成・実行できるようにします（隔離された実行環境で）。これはクリプトシナリオで特別な応用の潜在性がありますが、かなりのリスクもあります。

潜在性：各分析タイプをツールとして事前定義する必要なく、Agentがオンチェーン分析コードを動的に生成・実行できます（例：「Uniswap v3の過去7日間の取引量を照会してTWAPを計算するPythonコードを書く」）。高度にカスタマイズされた分析タスク（定量的な戦略のバックテスト・オンチェーンアドレスの行動クラスタリング）に対して、コード実行は固定ツールより柔軟です。

リスク：Agentが生成したコードにセキュリティ脆弱性が含まれる可能性があります——Prompt Injectionによって操作されたAgentは、「オンチェーンデータを照会する」コードを生成しますが、実際には「秘密鍵を外部サーバーに送信する」ロジックが含まれているかもしれません。より隠れた攻撃は、表面上合理的に見えるデータクエリコードを生成させますが、実際にはバックグラウンドで他の操作を行います。

コード実行を使用する場合のセキュリティ設計要件：外部ネットワークアクセスなし（または特定のホワイトリストAPIのみ）の完全に隔離されたDockerコンテナまたはSandbox環境で実行する必要があります。コンテナには秘密鍵や認証情報があってはなりません；コード実行には厳格なタイムアウト設定（例：最大30秒）；各コード実行の完全な記録（生成されたコード+出力+実行時間）は監査のためにログに書き込みます。

実際の推奨事項：2026年のクリプトAgentの本番環境では、非常に強力なSandboxセキュリティ能力がない限り、資金操作能力を持つAgentでのコード実行はお勧めしません。「純粋な分析・完全に隔離・秘密鍵との接触なし」のSub-agentに限定し、テキスト分析のみを出力し、操作指令は出力しないようにします。