CrewAI とは
CrewAIは、エージェント、タスク、クルー、フロー、ツールという独自のプリミティブを持つ、MITライセンスのスタンドアロンなPythonフレームワークです。クルーは、ロールを持つエージェントのチームで、タスクに自律的に協調して取り組みます。フローは、実行パス、状態、分岐を精密に制御できるイベント駆動のワークフローです。プロジェクトは実行中の人間の入力をサポートしており、商用のCrewAI AMP Suiteは、マネージドなデプロイ、オブザーバビリティ、ガバナンス、サポートのためのコントロールプレーンを追加します。
自律的なクルーとガバナンスの効いた設定
CrewAIはエージェントの自律性を重視します。ロール、目標、タスクを記述すると、クルーが協調の方法を考え出し、より厳密な制御が必要な場面ではフローを使います。EDDIは制御を重視します。決定論的なBehavior Rulesが次に実行するアクションを決め、LLMは宣言されたタスク内で呼び出され、マルチエージェントの作業は明確なフェーズを持つ名前付きのグループディスカッションスタイルに従います。どちらもマルチエージェントシステムを構築できます。違いは、事前にどこまで自分で決め、実行時にどこまでモデルに決めさせるかです。
コードで書くエージェントと設定としてのエージェント
| 観点 | CrewAI | EDDI |
|---|---|---|
| 主要な抽象化 | タスクを持つロールベースのエージェントのクルーと、イベント駆動のフロー | エージェント設定：パイプライン、Behavior Rules、LLMタスク、ツールをバージョン管理されたJSONとして定義 |
| 言語とランタイム | アプリケーションに組み込むPythonライブラリ | 仮想スレッドを使うJVM（Quarkus）プラットフォーム。エージェントにコードは不要 |
| ライセンス | MIT（オープンソースのフレームワーク）。その上に商用のAMP Suite | Apache 2.0（OSI承認） |
| 制御フロー | 協調の方法は実行時にエージェントが決定。フローはコードで明示的な分岐を追加 | 決定論的なBehavior Rulesが次のアクションを選択。グループのスタイルがフェーズを定義 |
| コード実行 | コードインタープリターツールはcrewai-toolsから削除され、エージェントレベルのコード実行は非推奨。ドキュメントはE2BやModalなどの専用サンドボックスを推奨 | プラットフォーム内に実行時のeval()やコード実行はない。ロジックは宣言するか、MCPツールやHTTP呼び出しの先に置く |
| ヒューマン・イン・ザ・ループ | 実行中の人間の入力をサポート | ターン、ツール呼び出し、グループのフェーズにゲート、タイムアウトポリシー。Manager、REST、MCP、Slackで承認 |
| マルチエージェントのパターン | クルーのプロセスとフローをコードで実装 | 7つのスタイルとカスタムのグループディスカッション。決定事項、集計、反対意見の記録、署名付きのトランスクリプトエントリ |
| 管理とガバナンス | トレーシングとガバナンスを備えたコントロールプレーンは商用のAMP Suiteに含まれる | Manager UI、シークレットVault、オプションのKeycloak/OIDC、監査台帳をオープンソース版に搭載 |
| 監査証跡 | コントロールプレーンまたは独自のツールによるトレーシングとオブザーバビリティ | HMAC署名付き、追記専用、連番検証付きの台帳。GET /auditstore/verify/{conversationId} |
| モデル | Pythonから多数のプロバイダーを利用可能 | 19のLLMプロバイダーに加え、OllamaまたはJlama経由のローカルモデル |
他ツールに関する内容は、2026年10月時点の公式ドキュメントとリポジトリで確認しています。これらのプロジェクトは変化が速いため、判断する前にベンダーに最新の挙動をご確認ください。
選び方
CrewAI が適している場面
- チームがPython中心で、エージェント、ツール、クルーのロジックを、他のコードと同じリポジトリに置きたい場合。
- ロールを持つエージェントの自律的な協調を素早くプロトタイプし、コードを編集して調整したい場合。
- 設定では表現できない任意のロジックを持つ、カスタムのPythonツールが必要な場合。
- 運用するプラットフォームよりも、組み込むライブラリを好む場合。
- 商用のAMP Suiteのコントロールプレーンが、組織のクルーのデプロイと監視の方法に合っている場合。
EDDIが適している場面
- マルチエージェントの挙動を、レビューできる程度に予測可能にする必要がある場合：自由な自律性ではなく、名前付きのフェーズ、記録された決定、ルールによる制御。
- 特定のツール呼び出しやグループのフェーズに人間の承認が必要で、その決定を署名付き台帳に記録する必要がある場合。
- ガバナンス、管理UI、監査を、別の商用ティアではなくオープンソース版で利用したい場合。
- セキュリティレビューで推論時にどのようなコードが実行されるかを問われ、プラットフォームでは何も実行させたくない場合。
- 非エンジニアが、プルリクエストなしでエージェントの挙動を変更する必要がある場合。
CrewAI からのクルーの移行
ロールと目標は、プロンプトとグループのフェーズに置き換わります。最も大きく変わるのは自律性です。クルーが実行時に決めていたことは、ルール、フェーズ、承認ゲートとして明文化することになります。
| CrewAI | EDDI |
|---|---|
| エージェント（ロール、目標、バックストーリー） | LLMタスク内のシステムメッセージを持つEDDIエージェント |
| タスク | パイプラインのタスク、またはグループディスカッションのフェーズ |
| クルーのプロセス | グループディスカッションスタイル（例：タスクフォースやラウンドテーブル） |
| ルーターを持つフロー | inputmatcherやactionmatcherなどの条件タイプを使ったBehavior Rules |
| カスタムのPythonツール | MCPツール、httpCall、またはOpenAPIからインポートしたAPI |
| 人間の入力 | PAUSE_CONVERSATIONルール、toolApprovals、またはフェーズのrequiresApproval |
| メモリとナレッジソース | 会話メモリのスコープとRAGナレッジベース |
よくある質問
EDDIはマルチエージェントシステム向けのCrewAIの代替になりますか？
はい。マルチエージェントの協調を、ガバナンスの効いたサービスとして運用したいチームには適しています。EDDIのグループディスカッションは、明確なフェーズを持つ名前付きのスタイルで実行され、決定と反対意見を記録します。CrewAIはエージェントにより多くの自律性を与え、Pythonで定義するため、コードの中にとどまりたいチームに向いています。
EDDIにはCrewAIのような自律エージェントがありますか？
EDDIのエージェントはツールを呼び出し、グループディスカッションで協調できますが、制御フローはエージェントの即興に任せず、利用者が設定するBehavior Rulesとフェーズによって決まります。これは、自律性と引き換えに予測可能性を得る意図的なトレードオフです。
ここでコード実行が重要なのはなぜですか？
生成されたコードを実行するエージェントには、分離が必要です。CrewAIは組み込みのコードインタープリターから離れ、専用のサンドボックスサービスを推奨しています。EDDIはプラットフォーム内で実行時にコードを評価しないことで、この問題を回避します。実際のロジックが必要なものは、宣言して承認できるツールの先に置かれます。
両方を使えますか？
はい。CrewAIのサービスは、REST API、MCPサーバー、OpenAI互換API経由でEDDIを呼び出せ、EDDIはhttpCall経由でCrewAIのエンドポイントを呼び出せます。コードレベルの実験にCrewAI、ガバナンスの効いた本番エージェントにEDDIという使い分けは、妥当な分担です。