CrewAIとは｜マルチエージェント協調フレームワークの使い方・料金とLangGraph/AutoGenとの違い

CrewAI（クルーAI）入門として、役割を持った複数のAIエージェントを「クルー（船の乗組員）」のように協調させるPython製マルチエージェントフレームワークの使い方を解説します。

CrewAIは、調査担当・執筆担当・レビュー担当といった役割を自然言語で定義し、それぞれにツールと目標を与えてチームとしてタスクを完了させる仕組みです。GitHubで57,000star超、月間検索数も高水準で推移しており、2026年のマルチエージェント入門の定番になっています。

本記事は、Crew/Agent/Task/Processの4概念・インストールから実行までの使い方・料金体系・LangGraphやAutoGenとの違い・本番運用・落とし穴までを一枚で俯瞰できる入門ガイドとしてまとめます。

AIエージェントそのものの仕組みや代表的フレームワークの全体比較は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 をご覧ください。本記事はその中の「マルチエージェント協調」を担うCrewAIに絞った各論です。

要点まとめ：CrewAIとは何か

CrewAIは、役割（role）・目標（goal）・背景（backstory）を持つ複数のAIエージェントを「クルー」として編成し、分業でタスクを完了させるPython製フレームワークです。中核はAgent・Task・Crew・Processの4概念だけで、pip install crewaiから数十行で動きます。使い方は素のPythonコードで書く方法と、公式CLI crewai create crew でYAML構成のプロジェクトを生成する方法の2系統があります。料金はOSS本体が無料・MITライセンスで、チームでの運用管理には有償のCrewAI AMP（旧Enterprise）があります。LangGraph・AutoGen・Mastra・OpenAI Agents SDKといった競合とは設計思想が異なり、「宣言的な役割分担のしやすさ」がCrewAIの強みです。

背景と文脈：なぜCrewAIがマルチエージェント入門の定番なのか

CrewAIが2026年のマルチエージェント入門の定番になっている背景には、単一LLMの限界があります。1つのプロンプトに「調査して」「書いて」「校正して」を全部詰め込むと、指示が長くなるほど精度が落ちます。これを「役割ごとに専門化したエージェントへ分業する」ことで解決しようとするのがマルチエージェント設計で、CrewAIはその中でも学習コストの低さを武器にしています。

公式は CrewAI を「LangChainや他のエージェントフレームワークから完全に独立した、ゼロから作られた軽量で高速なPythonフレームワーク」と説明しています。初期バージョンはLangChainに依存していましたが、現在は独立実装に移行しており、依存が軽く起動が速いのが実装上の特徴です。公式の学習コースには100,000人超の開発者が認定を受けており、「まず動かして概念を掴む」入門用途での採用が広がっています。

同じ「制御フローを書く」系のフレームワークである LangGraph入門｜とは？状態遷移でマルチエージェントを作る基本とLangChainとの違い・比較 も合わせて読むと、CrewAIの「宣言的な役割分担」とLangGraphの「グラフで厳密に状態遷移を書く」設計思想の違いがはっきりします。

詳しく見ていく：4つの基本概念とインストール〜実行

Crew/Agent/Task/Processの4概念

CrewAIは、たった4つの概念を理解すれば全体像が掴めます。

・Agent（エージェント）：役割（role）・目標（goal）・背景設定（backstory）を持つ自律ユニット。ツールを装備でき、自分の担当タスクを判断しながら実行する
・Task（タスク）：エージェントに渡す具体的な仕事。説明（description）と期待する成果物（expected_output）、担当エージェントを指定する
・Crew（クルー）：エージェントとタスクをまとめたチーム。kickoff()で実行を開始する
・Process（プロセス）：クルーがタスクをどの順序・体制で進めるか。SequentialとHierarchicalの2種類がある

この4つの関係は「Agentが人、Taskが仕事、Crewがチーム、Processが進め方のルール」と覚えると直感的です。

Crews と Flows

CrewAIにはもう一段上のレイヤーとして「Flows」があります。CrewとFlowsは目的が異なります。

・Crews：自律的に協調するエージェントのチーム。役割ベースで柔軟に判断する。”任せる”側
・Flows：イベント駆動の本番向けワークフロー。状態の永続化・条件分岐・実行制御をPythonで厳密に書ける。”制御する”側

実務では、Flowsで全体の流れ（入力→Crew実行→保存）を管理し、判断が要る部分だけCrewに委譲する組み合わせが定石です。入門段階ではまずCrewだけで十分動きます。

インストール（pip / uv）

CrewAIはPython 3.10〜3.13が対象です。公式はパッケージ管理に高速な uv を推奨していますが、通常の pip でも導入できます。

# uvを使う場合（公式推奨・高速）
uv pip install crewai

# 通常のpipでも導入可能
pip install crewai

# ツール群（検索・ファイル読み込み等）も含める場合
uv pip install 'crewai[tools]'

ModuleNotFoundError: No module named 'tiktoken' のようなエラーが出た場合は uv pip install 'crewai[embeddings]' を試す、というトラブルシューティングも公式READMEに明記されています。

使い方1：CLIでYAMLプロジェクトを生成する

公式が「Getting Started」の標準手順として案内しているのは、CLIでプロジェクト一式を生成する方法です。

crewai create crew my_project

このコマンドで、agentsとtasksをYAMLで定義する以下の構成が自動生成されます。

my_project/
├── pyproject.toml
├── .env
└── src/my_project/
    ├── main.py          # 実行のエントリーポイント
    ├── crew.py          # Crewの定義
    ├── config/
    │   ├── agents.yaml  # エージェントの役割・目標を定義
    │   └── tasks.yaml   # タスクの説明・期待成果物を定義
    └── tools/
        └── custom_tool.py

役割やゴールをコードでなくYAMLに書けるため、非エンジニアともエージェント設計をレビューしやすいのが利点です。

使い方2：Pythonで直接定義する最小コード

概念を素早く試したい場合は、Pythonコードで直接Agent/Task/Crewを定義する書き方も使えます。

from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role="シニアAIリサーチャー",
    goal="{topic} に関する最新動向を正確に調べる",
    backstory="あなたは技術トレンドの調査に長けた専門家です。",
)
writer = Agent(
    role="技術ライター",
    goal="調査結果を初心者向けの日本語記事にまとめる",
    backstory="あなたは難しい技術を平易に書くのが得意なライターです。",
)

research_task = Task(description="{topic} について主要な動向を3点調べる",
                      expected_output="箇条書き3点のリサーチメモ", agent=researcher)
write_task = Task(description="リサーチメモをもとに初心者向け記事を書く",
                   expected_output="見出し付きのMarkdown記事", agent=writer)

crew = Crew(agents=[researcher, writer], tasks=[research_task, write_task],
            process=Process.sequential)
result = crew.kickoff(inputs={"topic": "CrewAI"})
print(result)

Sequentialなのでresearch_taskの出力が自動的にwrite_taskの文脈に渡り、「リサーチャーが調べ、その出力を受けてライターが記事を書く」分業がこの十数行で動きます。

Process・Tools・Memory・Knowledge

入門の最小例を超えて、実務で使う4つの機能を押さえます。

・Process.hierarchical：マネージャーエージェントがどのエージェントに何を任せるかを動的に判断して委譲する。manager_llmまたはmanager_agentの指定が必須
・Tools：tools=[...]でAgentに装備させる「手足」。crewai_toolsパッケージにWeb検索・ファイル読み込み・コード実行など多数が用意されている
・Memory：memory=Trueで有効化。CrewAIはメモリアーキテクチャを単一のMemoryクラスに統合しており、remember(content, scope, source)で保存、recall(query, scope, depth, limit)で意味的類似度・新しさ・重要度を加味した検索ができる。既定の保存先はLanceDBで./.crewai/memory（CREWAI_STORAGE_DIRで変更可）
・Knowledge：エージェントが参照する「事前に与える参考資料」。Memoryが「過去の経験」なのに対しKnowledgeは「事前知識」という違いがある。PDF/CSV/JSON/テキストなど多様なソースに対応

crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, write_task, review_task],
    process=Process.hierarchical,
    manager_llm="gpt-4o",   # マネージャー役のLLM
    memory=True,            # Memoryを有効化
)

エージェント数が増え、割り当てを動的に最適化したいときはHierarchicalが効きますが、その分トークン消費と非決定性が増えます。最初はSequentialから始めるのが無難です。

CrewAIのアーキテクチャと仕組み

CrewAIの動作を1枚の図で押さえます。ユーザーが目標を渡すと、Crewが各Agentに割り当てられたTaskをProcessのルールに従って実行し、成果物を返します。

図のポイントは3つです。

・Crewが入力を受け取り、Processの種類に応じてタスクをエージェントに割り当てる
・Sequentialなら定義順、Hierarchicalならマネージャーエージェントが動的に委譲先を決める
・各AgentはTaskをこなしながらToolsで外部に働きかけ、KnowledgeとMemoryを参照する

このループを通じて、単一LLMでは難しい「分業による複雑タスクの完遂」を実現するのがCrewAIの本質です。実運用では、この図の一連の流れをさらに大きな「Flow」の1ステップとして組み込み、状態管理や条件分岐をFlowsが担う構成が一般的です。CloudflareのAIコードレビューシステム解剖｜7専門エージェント並列実行の仕組みと実績は、CrewAIとは別実装ながら「複数の専門エージェントを並列実行して1つの成果物にまとめる」設計思想が共通する実例として参考になります。

他の選択肢との比較：LangGraph・AutoGen・Mastra・OpenAI Agents SDK

主要なエージェントフレームワークとCrewAIを比較します。どれも「マルチエージェント」を謳いますが、設計思想と得意分野が異なります（Star数は2026-08-17時点のGitHub実測値）。

ざっくり選び分けると次の通りです。

・役割分担を宣言的に最短で組みたい → CrewAI
・制御フローを厳密に書きたい → LangGraph
・既存のAutoGen資産を保守したい／新規は後継を検討 → AutoGen／Microsoft Agent Framework
・TypeScript/フロント統合 → Mastra
・OpenAIモデル中心で軽量に → OpenAI Agents SDK

CrewAIが選ばれる理由は「制御の厳密さ」ではなく「立ち上がりの速さ」です。LangGraphのような明示的な状態機械を書かずに済むぶん、複雑な分岐が必要な本番フローでは設計の柔軟性が下がるトレードオフがあります。

実務への影響：料金・本番運用・落とし穴・実例

料金の考え方

CrewAIの本番コストは大きく2系統です。

・LLM API課金：OpenAIやAnthropic等の従量課金。自律ループは消費が読みにくいので、上限とアラートを必ず張る
・CrewAI AMP（旧CrewAI Enterprise）：デプロイ・監視・スケーリングをマネージドで提供する有償プラン。クルーをAPIとしてデプロイし、実行履歴やバージョンを一元管理できる。OSS版を自前インフラで動かす限りCrewAIへの課金は発生しない

個人開発や検証はOSS版＋API従量で十分です。チーム運用や可観測性が必要になった段階でAMPを検討する流れが現実的です。ローカルLLM（Ollama）へ切り替えてAPIコストをゼロに近づける選択肢もありますが、ツール呼び出しの精度はモデルサイズに依存するため、まずクラウドの高性能モデルで設計を固めてから置き換えるのが安全です。モデル選定や量子化の基礎を先に押さえたい場合は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 が参考になります。

可観測性とチェックポイント

エージェントは非決定論的に動くため、「なぜその判断をしたか」を追える可観測性が本番では必須です。CrewAIはAMP上のダッシュボードで各Agent/Taskの実行タイムラインとLLM呼び出しの入出力をトレース表示する機能を備えており、verbose=Trueのログだけでは追いにくいタスク間の依存関係やレイテンシを可視化できます。

長時間実行するCrewやFlowでは、途中経過を保存して失敗地点から再開できるチェックポイント機能も用意されています。CLIツール（TUI）でチェックポイント履歴をツリー表示し、任意の時点からResume（再開）やFork（分岐）ができるため、途中でエラーが起きても最初からやり直す必要がありません。

実例・サンプルコード集

「まず動くコードを見たい」場合は、公式のcrewAI-examplesリポジトリが最短です。Landing Page Generator（LP自動生成）・Trip Planner（旅行プラン作成）・求人票ライティングなど、実行可能なCrewの実例がYouTube解説動画付きで公開されています。いずれも「調査→生成→レビュー」の分業パターンを異なる題材で示しており、自分のユースケースに近い例から読み始めると設計の勘所を掴みやすくなります。

よくある落とし穴

入門者がつまずきやすいポイントを先回りで挙げます。

・roleやgoalが曖昧で出力がブレる：抽象的な役割定義は出力品質を直接下げる。「優秀なライター」より「IT初心者向けに専門用語を噛み砕く技術ライター」のほうが出力が安定する
・いきなりHierarchicalにして制御不能：マネージャー委譲は便利だが非決定性が増す。まずSequentialで挙動を固める
・トークン消費の暴走：自律ループや多エージェントは想定の数倍消費しうる。max_iter・予算アラートを最初から組み込む
・MemoryとKnowledgeの混同：Memoryは「過去の経験」、Knowledgeは「事前に渡す参考資料」。役割が違うので使い分ける
・バージョン差での書き方の食い違い：CrewAIは更新が速く、Memory周りなどAPIが変わる。2026-08-14に1.15.15、2026-08-17時点で1.15.16と週単位でパッチが出ており、uv pip show crewaiでバージョンを確認し、そのバージョンの公式ドキュメントを参照するのが確実

特に最後の「バージョン差」は実害が出やすい点です。記事やチュートリアルのコードが動かないときは、まず自分の環境のCrewAIバージョンを疑うと早く解決します。キャリアパス全体でマルチエージェント設計がどう位置づけられるかは バイブコーディングは終わった？2026年版Agentic AIエンジニアのロードマップと進化の全体像 でも扱っています。

まとめ：CrewAIの使い方を最短で押さえる

CrewAIは、役割を持つエージェントを「クルー」として協調させるマルチエージェントフレームワークです。覚えるべきはAgent・Task・Crew・Processの4概念だけで、使い方はCLI（crewai create crew）でYAMLプロジェクトを生成する方法と、Pythonコードで直接定義する方法の2系統があります。料金はOSS本体が無料・MITライセンス、チーム運用にはCrewAI AMPという棲み分けです。制御を厳密に書きたいならLangGraph、TS統合ならMastraという使い分けを押さえつつ、まずはSequentialな最小クルーで「分業が動く」感覚を掴むのが最短の入門ルートです。

参照ソース

・CrewAI 公式サイト — フレームワークの概要・AMP情報
・crewAIInc/crewAI（GitHubリポジトリ・README） — インストール手順・Getting Started・Key Features・ソースコード
・CrewAI 公式ドキュメント：Memory — 統合Memory API（remember/recall）・LanceDBストレージの一次情報
・crewAIInc/crewAI-examples（GitHubリポジトリ） — 実行可能なCrewの実例集
・Microsoft AutoGen（GitHub） — 比較対象。メンテナンスモード移行の公式告知
・Microsoft Agent Framework（GitHub） — AutoGenの後継として公式が案内する移行先