9.6.5 CrewAI
もしあるフレームワークが「状態フローエンジン」に近いとしたら、CrewAI の第一印象はたいてい次のようなものです：
分担のある小さなチームを組んでいる感じ。
特に重視するのは次の要素です。
- 役割
- 目標
- タスク
- 協力の順序
そのため、もともと「複数人の協働」のようなタスクにとても向いています。
学習目標
- CrewAI の最も基本的な抽象概念を理解する
- なぜチーム型の多 Agent シナリオに特に向いているのかを理解する
- 最小限の crew ワークフローを読み取れるようになる
- その強みと限界がどこにあるかを理解する
CrewAI の本質的な抽象とは何か？
先に状態図を描くのではなく、まず役割を定義する
CrewAI の考え方は、現実のチーム管理にとてもよく似ています。
- 誰が調査を担当するか
- 誰が文章を書くか
- 誰がレビューするか
つまり、最初に考えるのは次のようなことではありません。
- ノードをどうつなぐか
まず考えるのは：
- このチームは誰で構成されるのか
とても直感的なたとえ
CrewAI は次のようなイメージに近いです。
「先にチームを作って、それからタスクを割り振る」。
これは、LangGraph のような「まず状態と辺を定義する」考え方とはかなり違います。
最も重要な 3 つの概念
Agent
1 人のメンバーです。
通常は次のような要素を持ちます。
- 役割
- 目標
- 得意分野
Task
具体的な作業です。
通常は次のような要素を持ちます。
- タスク内容
- 担当者
- 期待される出力
Crew
共通の目標に向かって協力する、小さなチームです。
まずは一言で覚えましょう。
Agent は人、Task は仕事、Crew はチーム。
最小限の crew の例
crew = [
{"role": "researcher", "goal": "返金ポリシーを調べる"},
{"role": "writer", "goal": "要約にまとめる"},
{"role": "reviewer", "goal": "条件の抜け漏れがないか確認する"}
]
tasks = [
{"owner": "researcher", "task": "返金ポリシーを探す"},
{"owner": "writer", "task": "要約を書く"},
{"owner": "reviewer", "task": "要約を確認する"}
]
print(crew)
print(tasks)
想定出力：
[{'role': 'researcher', 'goal': '返金ポリシーを調べる'}, {'role': 'writer', 'goal': '要約にまとめる'}, {'role': 'reviewer', 'goal': '条件の抜け漏れがないか確認する'}]
[{'owner': 'researcher', 'task': '返金ポリシーを探す'}, {'owner': 'writer', 'task': '要約を書く'}, {'owner': 'reviewer', 'task': '要約を確認する'}]
この例が本当に表していることは？
この例が表しているのは次のことです。
多 Agent システムは、まず「役割とタスク」で組み立てることができ、必ずしも先に低レベルの状態フローで組む必要はない。
これこそが、CrewAI がとても入りやすく感じられる理由です。
なぜこの抽象はコンテンツ系の協働タスクに特に向いているのか？
多くのタスクは、最初から小さなチームが動いているような形をしています。
- まず材料を集める
- 次に下書きを書く
- そのあとレビューする
たとえば：
- 調査レポート
- ポリシー要約
- コンテンツ制作
- コードドキュメント
CrewAI の抽象はこうしたタスクにとても合っています。だから、次のように感じやすいです。
「これは低レベルのグラフワークフローより、実際の協働プロセスに近い。」
もう少し完全な小型 Crew ワークフロー
def researcher_agent(topic):
return f"資料：{topic} の重要な条件には、7 日以内と学習進捗の制限が含まれます。"
def writer_agent(material):
return f"要約案：{material}"
def reviewer_agent(draft):
if "学習進捗の制限" in draft:
return {"approved": True, "comment": "重要情報はかなり揃っています"}
return {"approved": False, "comment": "学習進捗の情報が不足しています"}
topic = "返金ポリシー"
material = researcher_agent(topic)
draft = writer_agent(material)
review = reviewer_agent(draft)
print("material:", material)
print("draft :", draft)
print("review :", review)
想定出力：
material: 資料：返金ポリシー の重要な条件には、7 日以内と学習進捗の制限が含まれます。
draft : 要約案：資料：返金ポリシー の重要な条件には、7 日以内と学習進捗の制限が含まれます。
review : {'approved': True, 'comment': '重要情報はかなり揃っています'}
この例が示しているのは次の点です。
- 役割分担がはっきりしている
- 入出力が明確
- 協力の流れも自然
CrewAI の強みはどこにある？
理解しやすい
複雑な状態図よりも、「チームの役割」という考え方のほうが、多くの人にとって直感的です。
見せやすい
デモ、アーキテクチャ説明、協働の説明などで、とても説明しやすいです。
役割分担が明確なタスクに向いている
特に向いているのは次のような作業です。
- 調査
- 執筆
- レビュー
- 要約
つまり、「誰が何をするか」がはっきりしている場面です。
CrewAI の限界も理解しておこう
複雑な状態フローを自動で解決してくれるわけではない
もしシステムが次のような特徴を持つなら：
- 分岐が多い
- ループが多い
- 中間状態が複雑
この場合、単に「役割の抽象」だけでは足りないことがあります。
役割の抽象は、下層のエンジニアリング複雑さを見えにくくすることがある
見た目は次のようにわかりやすくても：
- researcher
- writer
- reviewer
実際に本番運用するには、やはり次のようなものを扱う必要があります。
- タイムアウト
- リトライ
- ログ
- trace
- 権限
そのため、これは「表現方法」や「組織化の方法」に近く、万能な解決策ではありません。
どんなときに CrewAI を選ぶとよいか？
タスクが次のようなものに近いなら：
- チーム協働
- 役割分担
- コンテンツ制作の流れ
CrewAI はとても自然に使えます。
たとえば：
- 「1 人が資料を探し、1 人が書き、1 人がレビューする」
このようなタスクでは、CrewAI の考え方はとてもスムーズです。
しかし、タスクが次のようなものに近いなら：
- 複雑な状態図
- 細かい制御ループ
その場合は、グラフ型フレームワークのほうが安定していることがあります。
初学者がよくハマる落とし穴
役割は多いのに、責務が不明確
見た目はチームのようでも、実際には曖昧な役割がたくさん並んでいるだけ、ということがあります。
役割の抽象があればシステムも安定すると考えてしまう
役割はあくまで組織の形であって、エンジニアリング能力まで自動で補ってくれるわけではありません。
「チームっぽくする」ために無理に多 Agent 化する
タスク自体に分担が必要ないなら、多 Agent はむしろ負担になります。
まとめ
この節で大事なのは、あるフレームワークのクラス名を覚えることではなく、次を理解することです。
CrewAI の核心的な価値は、多 Agent の問題をまず「役割 + タスク + チーム」という協働構造で表現するところにある。
これは役割がはっきりしたコンテンツ系タスクではとても魅力的ですが、すべてのシステムにとって最適な抽象とは限りません。
練習
- 自分のタスクを 1 つ選び、3 役割の crew を設計してみましょう。
- 「役割の数が増える」ことが、なぜシステム品質の向上を意味しないのか考えてみましょう。
- 自分の言葉で、CrewAI と LangGraph の抽象の入口の違いを説明してみましょう。
- タスクに多くのループや条件分岐がある場合、それでも CrewAI を優先して選びますか？ なぜですか？