9.6.5 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': '要約を確認する'}]

CrewAI の役割とタスクの流れ

この例が本当に表していることは？

この例が表しているのは次のことです。

多 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
執筆担当
レビュー担当

実際に本番運用するには、やはり次のようなものを扱う必要があります。

タイムアウト
リトライ
ログ
トレース
権限

そのため、これは「表現方法」や「組織化の方法」に近く、万能な解決策ではありません。

どんなときに CrewAI を選ぶとよいか？

タスクが次のようなものに近いなら：

チーム協働
役割分担
コンテンツ制作の流れ

CrewAI はとても自然に使えます。

たとえば：

「1 人が資料を探し、1 人が書き、1 人がレビューする」

このようなタスクでは、CrewAI の考え方はとてもスムーズです。

しかし、タスクが次のようなものに近いなら：

複雑な状態図
細かい制御ループ

その場合は、グラフ型フレームワークのほうが安定していることがあります。

初学者がよくハマる落とし穴

役割は多いのに、責務が不明確

見た目はチームのようでも、実際には曖昧な役割がたくさん並んでいるだけ、ということがあります。

役割の抽象があればシステムも安定すると考えてしまう

役割はあくまで組織の形であって、エンジニアリング能力まで自動で補ってくれるわけではありません。

「チームっぽくする」ために無理に多 Agent 化する

タスク自体に分担が必要ないなら、多 Agent はむしろ負担になります。

残す証拠

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

問題の形: ワークフローグラフ、検索アプリ、役割チーム、または実験
フレームワーク選択: どの抽象化を追加し、何を隠すか
追跡記録: state、node、tool call、message、または run id
失敗確認: フレームワークの魔法が状態、再試行、または権限を隠す
判断: シングルエージェントのループが明確になってからフレームワークを選ぶ

まとめ

この節で大事なのは、あるフレームワークのクラス名を覚えることではなく、次を理解することです。

CrewAI の核心的な価値は、多 Agent の問題をまず「役割 + タスク + チーム」という協働構造で表現するところにある。

これは役割がはっきりしたコンテンツ系タスクではとても魅力的ですが、すべてのシステムにとって最適な抽象とは限りません。

練習

自分のタスクを 1 つ選び、3 役割の crew を設計してみましょう。
「役割の数が増える」ことが、なぜシステム品質の向上を意味しないのか考えてみましょう。
自分の言葉で、CrewAI と LangGraph の抽象の入口の違いを説明してみましょう。
タスクに多くのループや条件分岐がある場合、それでも CrewAI を優先して選びますか？なぜですか？

解法と解説

有用な 3-role crew の例は researcher、writer、reviewer です。各 role には狭い責務、明確な成果物、次の role への handoff point が必要です。
role が多いほど良いとは限りません。責務が重なり、message が騒がしくなり、最終判断の責任者が曖昧になると品質は下がります。実際のボトルネックを取り除くときだけ role を増やします。
CrewAI は role collaboration から入ります。誰が作業し、task が role 間をどう動くかが中心です。LangGraph は明示的な state と transition から入り、次にどの node がどの条件で動くかが中心です。
loop と条件分岐が多いなら、CrewAI を最優先にしないことがあります。graph / workflow 指向のほうが control flow、retry 上限、failure handling を確認しやすいからです。