2026年1月: Pythonで始めるマルチエージェントAI - CrewAI入門¶
杉田 (@ane45) です。今月の「Python Monthly Topics」では、CrewAIを紹介します。 従来の LLM(大規模言語モデル)の活用は、単一のモデルに1つのプロンプトを投げて完結させる使い方が中心でした。しかし、複雑なタスクになると「調査→分析→執筆」のように役割を分けた方が効率的です。人間のチームと同じように、AIも役割分担することで品質が向上します。CrewAIは、このような「AIチーム」を簡単に構築できる軽量で高速なPythonフレームワークです。
CrewAIとは¶
CrewAIは、複数のAIエージェントを役割ごとに編成し「チーム」として協力させ、複雑なタスクを自律的に実行させることができます。
公式ドキュメント: https://docs.crewai.com
Crews と Flows¶
CrewAIには中核となる2つの概念があります。
Crews(本記事のメイン)
宣言的な記述で簡単に「AIチーム」を作成するための仕組み
人間のチームのように、各エージェントが役割、目的、背景を持ち協力して問題を解決
Flows
Crews や個々の Agent の実行を組み合わせ、処理の流れを制御するための仕組み
状態管理・条件分岐・イベント制御などを用いて、より複雑なワークフローを構築できる
Flows の詳細には触れませんが、より高度な制御が可能です。 興味のある方は、以下の公式ドキュメントをご参照ください。
本記事では、Crewsに焦点を当てて基本的な使い方を解説します。
Crewsの構成要素¶
CrewAIでAIチームを作る際の基本要素は以下の4つです。
Agent: 明確な役割と目的を持ち、Task を遂行する自律的なAIエージェント
Task: Agent に割り当てられる具体的な作業内容と期待される成果物を定義したもの
Process: Task の実行順序を制御(順次プロセス、階層型プロセス)
Crew: 複数の Agent と Task をまとめ、指定された Process に従って実行をオーケストレーションする実行単位
CrewAIを動かしてみる¶
動作環境¶
Python 3.10以上 3.14未満(CrewAI の要件)
Python 3.13 / CrewAI 1.8.1(本記事での動作確認環境)
それでは実際にCrewAIを使ってみましょう。
最小構成で動かす(順次プロセス)¶
まずは必要なライブラリをインストールして、最もシンプルなコードで動作を確認します。
pip install "crewai[google-genai]" python-dotenv
crewai[google-genai] は、CrewAI 本体とあわせて Google の Gemini API を利用するためのライブラリをインストールします。
python-dotenv は、環境変数を .env ファイルから読み込むために使用します。
CrewAI は、使用する LLM プロバイダの API キーなどを環境変数として参照します。 後続の処理で複数の LLM を使い分けられるように、あらかじめ OpenAI[1] と Google (Gemini API)[2] の両方の API キーを .env に設定しておきます。
OPENAI_API_KEY="your-api-key"
GOOGLE_API_KEY="your-api-key"
CrewAI は複数の LLM プロバイダに対応しており、必要な環境変数や設定内容は、使用する LLM プロバイダごとに異なります。 対応している LLM の一覧および設定方法については、以下の公式ドキュメントを参照してください。
最もシンプルな構成で、Agent・Task・Crew がどのように連携するかを確認します。
この例では、「調査担当」と「執筆担当」の 2 人のメンバーでチームを構成し、 調査担当が収集した最新の AI 技術トレンド情報をもとに、 執筆担当が一般の読者向けの技術記事を作成します。 タスクは調査 → 執筆の順に実行され、前のタスクの結果を次のタスクに引き継ぐ構成になっています。
from crewai import Agent, Crew, LLM, Process, Task
from dotenv import load_dotenv
# .envファイルから環境変数を読み込む
load_dotenv()
# 1. Agent定義
# 調査担当エージェント
researcher = Agent(
role="AI技術調査員",
goal="最新のAI技術動向を調査する",
backstory="あなたは技術トレンドに精通した調査の専門家です",
llm="gpt-4.1",
)
# 執筆担当エージェント
writer = Agent(
role="技術ライター",
goal="調査結果を分かりやすい記事にまとめる",
backstory="あなたは複雑な技術を平易な言葉で説明できるライターです",
llm=LLM(model="gemini/gemini-2.5-flash"),
)
# 2. Task定義
# 調査タスク
research_task = Task(
description="2025年のマルチエージェントAIの主要な進展を3つ挙げてください",
agent=researcher,
expected_output="主要な進展3つをそれぞれ1-2文で説明したリスト",
)
# 執筆タスク
writing_task = Task(
description="調査結果をもとに、200文字程度の技術ニュース記事を書いてください",
agent=writer,
expected_output="導入・本文・まとめの構成を持つ簡潔な記事",
context=[research_task], # 調査タスクの結果を受け取る
)
# 3. Crew定義(チーム編成)
my_crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task],
process=Process.sequential, # タスクを順番に実行
verbose=True, # 実行過程を表示
)
# 4. 実行
result = my_crew.kickoff()
print("\n=== 最終結果 ===")
print(result.raw)
1. Agent の定義
CrewAI では、Agent を定義する際に次の3つのパラメータが必須です。
role:Agentの役割goal:達成すべき目的backstory:振る舞いを補強する背景設定
この例では、調査担当と執筆担当の2つの Agent を定義し、それぞれに明確な役割を与えています。 これにより、Agentごとに異なる専門性を持たせることができます。
2. Task の定義と役割分担
Task には必須パラメータとして、以下を設定します。
description:Taskで実行する内容の説明expected_output:期待される出力の形式や詳細
agent は任意パラメータで、Task を担当する Agent を指定します。
ただし、Crew に Process.sequential を指定した場合、各 Task には agent の指定が必須となります。
この例では Process.sequential を使用しているため、すべての Task に agent を指定しています。
調査タスクでは「2025年のマルチエージェントAIの進展を調べる」ことを指示し、その Task を 調査担当エージェント に割り当てています。
執筆タスクでは、context パラメータを使って調査タスクを指定しています。
これにより、調査タスクの出力がそのまま次のTaskの入力として渡され、Agent 間で連携が可能になります。
3. Crew定義 と 実行戦略(Process)
Crew では、Agent と Task をまとめて「チーム」として定義します。 Process.sequential を指定すると、tasks に記載した順番どおりにTaskが実行されます。 この例では、調査タスク-> 執筆タスクという流れが保証されます。
4. 実行と結果の取得
kickoff() メソッド を呼び出すことで、Crew 全体の処理が開始されます。
最終的な出力は、最後に実行されたTask(この例では執筆タスク)の結果であり、result.raw から取得できます。
このコードを実行してみましょう。
$ python sequential_example.py
このコードを実行すると Crewのverbose引数にTrueを指定しているため、CrewAI の実行過程がログとして表示されます。
ログには、Crew の開始から各 Task・Agent の実行状況、最終的な出力に至るまでの流れが段階的に表示され、最終結果は result.raw に格納されます。
なお、同じ入力・同じモデルであっても、実行のたびに生成される出力が変わる場合があります。
実行結果およびログ(全文)は以下を参照してください。
実行ログには、主に以下の情報が表示されます。
Crew 実行の開始(Crew 名や ID)
各 Task の実行開始・実行中・完了といったステータス
Task を担当する Agent の起動
Agent に割り当てられたTask内容
Agent が生成した最終回答(Final Answer)
すべての Task 完了後に出力される Crew 全体の最終結果
また、より詳細な実行ログを確認したい場合は、CrewAI が提供するトレース機能を利用できます。 トレースでは、各 Task や Agent の内部的な処理状況をより細かく把握できます。 具体的な使い方や確認方法については、以下を参照してください。
Agent / Task / Crew の主なパラメータ¶
Agent、Task、Crew には、それぞれの振る舞いや役割を定義するための様々なパラメータがあります。 以下に、主なパラメータを紹介します。
Agent¶
パラメータ |
型 |
説明 |
|---|---|---|
|
|
(必須)Agent の役割・機能を定義 |
|
|
(必須)Agent が達成すべき目的 |
|
|
(必須)Agent の背景やキャラクター説明 |
|
|
Agent が使用する言語モデル。デフォルトはOPENAI_MODEL_NAMEで指定されたモデルまたは「gpt-4」です。 |
|
|
Agent が利用できるツール一覧 |
|
|
詳細ログ出力の有無 |
|
|
Task 委譲の許可フラグ |
Task¶
パラメータ |
型 |
説明 |
|---|---|---|
|
|
(必須)Task で実行する内容の説明 |
|
|
(必須)期待される出力の形式や詳細 |
|
|
この Task を担当する Agent |
|
|
Task 実行中に利用できるツール一覧 |
|
|
他 Task の出力を入力コンテキストとして利用 |
|
|
非同期で Task を実行するかどうか |
|
|
人間の確認・入力を要求するかどうか |
|
|
出力を Markdown 形式にするかどうか |
|
|
Task の出力を書き込むファイルパス |
|
|
JSON 形式で出力するための Pydantic モデル |
|
|
Pydantic モデルとして構造化出力する指定 |
Crew¶
パラメータ |
型 |
説明 |
|---|---|---|
|
|
(必須)この Crew が実行する Task のリスト |
|
|
(必須)Crew に含まれる Agent のリスト |
|
|
Task 実行のプロセスフロー |
|
|
詳細ログを出すかどうか |
|
|
階層プロセスで使用するマネージャー Agent の LLM |
|
|
メモリ設定(短期/長期/エンティティメモリ等) |
上記で紹介したパラメータ以外にも細かな制御を行うために様々な設定が可能です。詳細は以下を参照ください。
階層型プロセスとツール連携¶
前の例では Process.sequential(順次プロセス)を使用し、Task をあらかじめ決めた順序で実行しました。 ここでは、Process.hierarchical(階層型プロセス)を用いた例を紹介します。 階層型プロセスでは、マネージャー役の LLM が全体の進行を管理し、 状況に応じて適切な Agent に Task を割り当てながら処理を進めます。
Process |
実行方法 |
|---|---|
順次プロセス(Sequential) |
Task は定義した順番に実行される |
階層型プロセス(Hierarchical) |
マネージャー役の LLM が Agent に Task を動的に割り当て |
この例では、ブログ記事作成を題材に、 「データ収集」「トレンド分析」「コンテンツライター」という役割を持つ複数の Agent が協力して作業を進めます。
また、Agent が外部情報を取得できるように、ツール(tools) を利用します。 ツールは、Agent がタスク実行中に検索や API 呼び出しなどの外部機能を使うための仕組みです。 データ収集およびトレンド分析担当の Agent には、Google 検索を行うための SerperDevTool を割り当てています。
SerperDevTool を使用するには、事前に Serper.dev で API キーを取得し、環境変数として設定しておく必要があります。[4]
まず、実行に必要なライブラリをインストールします。
pip install "crewai[google-genai,tools]" python-dotenv
crewai[tools]は、CrewAI で利用可能な各種ツールを提供するライブラリです。
OPENAI_API_KEY="your-api-key"
GOOGLE_API_KEY="your-api-key"
SERPER_API_KEY="your-serper-api-key" # SerperDevTool で使用する
以下が、サンプルコード全体です。
from crewai import Agent, Crew, LLM, Process, Task
from crewai_tools import SerperDevTool
from dotenv import load_dotenv
# .envファイルから環境変数を読み込む
load_dotenv()
# Google Web検索機能を表すツールオブジェクトを生成
# このインスタンスを Agent の tools に渡すだけで、検索ツールとして利用できる
search_tool = SerperDevTool()
# 1. エージェント定義
# データ収集
data_collector = Agent(
role="データ収集専門家",
goal="最新の統計データと数値情報を収集する",
backstory=(
"あなたはデータ収集の専門家です。"
"統計データ、数値、グラフなどの定量的な情報を見つけることが得意です。"
),
llm=LLM(model="gpt-4"),
tools=[search_tool],
verbose=True,
)
# トレンド分析
trend_analyst = Agent(
role="トレンド分析専門家",
goal="最新のトレンドや動向を分析する",
backstory=(
"あなたはトレンド分析の専門家です。"
"業界の最新動向、専門家の意見、将来予測などを調査します。"
),
llm=LLM(model="gpt-4"),
tools=[search_tool],
verbose=True,
)
# コンテンツライター
writer = Agent(
role="コンテンツライター",
goal="魅力的で分かりやすい記事を書く",
backstory=(
"あなたは経験豊富なライターです。収集された情報をもとに、読みやすい記事にまとめます。"
),
llm=LLM(model="gemini/gemini-2.5-flash"),
verbose=True,
)
# 2. タスク定義
task = Task(
description=(
"「{topic}」をテーマに読者に価値のあるブログ記事を作成してください。"
"2026年の予測データ、市場規模、成長率、導入率などの数値を盛り込んでください。"
"必要に応じて調査・分析・再調査・構成変更を行ってください。"
),
expected_output="完成したブログ記事(日本語で600文字程度)",
)
# 3. Crew定義(Hierarchical Process)
crew = Crew(
agents=[data_collector, trend_analyst, writer],
tasks=[task],
process=Process.hierarchical, # 階層的プロセス
manager_llm="gpt-4.1", # マネージャー用のLLMを指定。階層型プロセスでは必須のパラメータ。
planning=True,
verbose=True,
)
# 4. 実行
if __name__ == "__main__":
result = crew.kickoff(inputs={"topic": "マルチエージェントAIシステムの2026年の展望"})
print("\n=== 最終結果 ===")
print(result.raw)
python hierarchical_example.py
このコードを実行すると、階層型プロセスに基づいて、マネージャー LLM が全体を統括しながら処理が進行します。 以下のシーケンス図は、実際の実行ログをもとに、Agent 間のやり取りを可視化したものです。 実行時のおおまかな流れは以下のとおりです。
マネージャー LLM は Task の内容を把握し、全体の実行計画を立案する。実行計画には、次のような工程が含まれる。
テーマの理解(基礎知識・文脈の把握)
必要なデータの収集(市場規模・成長率・導入率などの収集)
データの分析(収集データから重要なトレンドやインサイトを抽出)
記事構成の決定
初稿の作成
再調査(不足情報の補完)、校正、最終確認、発表
マネージャー LLM は、各 Agent の役割や能力を踏まえ、実行計画の一部を各 Agent に割り当てる。
作業内容 |
担当Agent |
|---|---|
テーマの理解、必要なデータの収集 |
データ収集専門家 |
データの分析 |
トレンド分析専門家 |
初稿の作成 |
コンテンツライター |
「4. 記事構成の決定」および「6. 再調査・校正・最終確認・発表」については、独立した作業として各 Agent に割り当てられていることは確認できませんでした。
マネージャー LLM の指示のもと、以下の流れで処理が進行する。
データ収集専門家が「マルチエージェントAIの基礎」「最新動向」「2026年展望」「市場規模・成長率」についてWeb検索を実施
トレンド分析専門家が収集データをもとに、2026年のトレンド・ビジネスインパクト・今後の展望を分析・要約
コンテンツライターが分析結果を踏まえ、600文字程度の日本語ブログ記事初稿を作成
マネージャー LLM がコンテンツライターの出力を受け取り、表現の簡略化・出典の明確化・文体の統一などの修正を加えて最終成果物として出力
このように、階層型プロセスでは、マネージャー LLM が各 Agent にタスクを割り当て、その出力を受け取りながらワークフロー全体を統括します。
実行時の処理の流れ¶
ツール連携
CrewAI は多様なツール連携に対応しており、SerperDevToolの他にも、ファイル操作・Web スクレイピング・RAG・データベース検索など、さまざまなユースケースで活用できます。 対応ツールの一覧については、公式ドキュメントを参照してください。
CLIによるプロジェクト管理¶
ここまでの例では、Agent や Task、Crew をすべて Python コード上で定義してきましたが、 CrewAI では、Agent や Taskの定義は、YAMLによる管理を推奨しています。 YAML形式によるプロジェクト管理には次のような利点があります。
設定(Agent / Task)とロジック(Crew)が分離され、保守性が向上する
YAML を変更するだけで挙動を調整できる
チーム開発時に差分レビューやバージョン管理がしやすい
特に、Agent や Task の数が増えるケースでは、コード管理よりも YAML 管理の方が見通しが良くなります。 また、CrewAIの CLI コマンドを利用することで、 YAML 定義を含んだプロジェクトの雛形作成や実行を効率よく行うことができます。 ここでは、その基本的な使い方を簡単に紹介します。
CrewAI CLI でプロジェクトを作成する¶
まずは CLI ツールを使って、CrewAI プロジェクトの雛形を作成します。 以下のコマンドを実行すると、CrewAI 用の標準的なプロジェクト構成が自動生成されます。
# インストール
pip install crewai
# プロジェクト作成
crewai create crew my_crew
cd my_crew
作成されるプロジェクト構造は次のとおりです。
.
├── README.md
├── knowledge # Agentが参照する補助的な知識や前提情報を配置する
│ └── user_preference.txt
├── pyproject.toml
├── src
│ └── my_crew
│ ├── __init__.py
│ ├── config
│ │ ├── agents.yaml # Agent定義
│ │ └── tasks.yaml # Task定義
│ ├── crew.py # Crew定義(メイン)
│ ├── main.py
│ └── tools # エージェントが利用する独自ツールを定義するためのファイル
│ ├── __init__.py
│ └── custom_tool.py
├── .env # 環境変数の設定
└── tests
作成されたプロジェクトでは、Agent や Task の設定を YAML ファイルとして切り出し、Python 側では実行ロジックに集中できる構成になっています。 agents.yaml や tasks.yaml では、Agent の役割や Task 内容を宣言的に定義できます。
また、tools/custom_tool.py では、Agentが利用できる独自ツールを実装できます。 独自ツールを作成し、外部 API の呼び出しや独自処理を組み込むことで、LLM の振る舞いを柔軟に拡張することが可能です。詳細は以下を参照ください。
knowledge ディレクトリは、Agentが参照する補助的な知識や前提情報を配置するための場所です。 詳細は、後述しています。
プロジェクトの実行は、プロジェクトのルートディレクトリで次のコマンドを実行します。
$ crewai run
参考までに、前述の「最小構成で動かす順次プロセス(sequential_example.py)」を YAML で管理した例を用意しました。 詳細は以下を参照してください。
その他の機能¶
ここでは、さらに知っておくと便利な機能をいくつか紹介します。
Memory(記憶機能)¶
memory=True を Crew に設定すると、Agentは 過去のやり取りや情報を記憶し、複数のTaskや実行セッションをまたいで活用できるようになります
crew = Crew(
agents=[researcher, analyst],
tasks=[research_task, analysis_task],
memory=True # メモリを有効化
)
Memoryの種類
CrewAI では、用途に応じて複数の種類のメモリが内部的に使い分けられています。
短期記憶(Short-term)
実行中の現在のTaskや直近の結果を一時的に保存し、文脈を維持するために利用されます。
長期記憶(Long-term)
過去のセッションや実行から得られた情報を蓄積し、次回以降のセッションで再利用できます。
エンティティ記憶(Entity)
人名・組織名・固有概念などの重要なエンティティ情報を整理して記憶し、より深い理解や関係性の保持に役立てます。
コンテキストメモリ(Contextual)
短期・長期・エンティティなど複数のメモリを統合し、総合的な文脈を維持して応答に反映させるための仕組みです。
デフォルトでは、Memory のデータは CrewAI の内部ストレージに保存されます。
短期記憶・エンティティ情報・ナレッジベースは ChromaDB[5]、長期メモリは SQLite によって管理されています。
保存場所をカスタマイズしたい場合は、環境変数 CREWAI_STORAGE_DIR を設定してください。
Knowledge(外部ナレッジの参照)¶
CrewAI では、RAG(Retrieval-Augmented Generation)の仕組みを利用して、外部のナレッジファイルを Task 実行時に Agent が参照できるようにすることができます。
以下は、記事執筆時のルールをナレッジとして与える簡単な例です。
記事は必ず日本語で書く
専門用語には簡単な補足を入れる
結論を最初に書く
このようなテキストファイルを knowledge ディレクトリに配置し、Crew 定義時に Knowledge Source として登録することで、 AgentはTask実行時にこれらのルールを参照しながら文章を生成します。
from crewai import Agent, Crew, Task
from crewai.knowledge.source.text_file_knowledge_source import TextFileKnowledgeSource
# 執筆ルールを記載したテキストファイルを Knowledge Source として読み込む
rules = TextFileKnowledgeSource(file_path="writing_rules.txt")
writer = Agent(
role="テクニカルライター",
goal="社内のルールに従って記事を書く",
backstory="経験豊富で、社内の執筆基準に従うテクニカルライター。",
verbose=True
)
task = Task(
description="CrewAIのMemory機能について記事を書く",
expected_output="ルールに沿った日本語記事",
agent=writer,
)
crew = Crew(
agents=[writer],
tasks=[task],
knowledge_sources=[rules]
)
crew.kickoff()
この例では、Taskの description にルールを直接書かなくても、Agentが Knowledge を検索・参照し、 「日本語で書く」「結論を最初に書く」といった前提を自然に守って出力します。
Knowledge として利用できるのはテキストファイルだけでなく、Markdown、PDF、CSV などのファイル形式にも対応しており、 仕様書やガイドライン、FAQ などをそのまま知識として扱うことが可能です。
本番利用を見据えた運用¶
CrewAI は外部サービスとの統合や高度なワークフロー構築を想定した設計になっています。 特に AWS との統合として、CrewAI の公式統合ツールのひとつに Bedrock Invoke Agent Tool があり、これを使うことで CrewAI のワークフロー内から Amazon Bedrock 上のエージェントを呼び出し活用できます。
Amazon Bedrock は AWS が提供する フルマネージドの生成 AI 基盤サービスです。 CrewAI と Bedrock を組み合わせることで、次のような利点が期待できます。
Bedrock によってAgent実行や基盤構築の多くを AWS に委ねられる
Anthropic、Amazon Titan など、Bedrock が提供するモデルを統一的に扱える
Bedrock や AWS の IAM、ネットワーク管理を活用したアクセス制御とポリシー適用が可能
本番運用では、アクセス制御・監視・ロギング・コスト管理といった運用面の考慮が重要になります。 CrewAI と Amazon Bedrock の組み合わせは、こうした要件を満たしつつ、拡張性のあるマルチエージェントシステムを実装するうえで有力な選択肢の一つです。
参考:
まとめ¶
本記事では、CrewAI を使ったマルチエージェントシステムの構築方法について、 Agent・Task・Crew という基本要素を組み合わせるだけで、複数の AI エージェントが協調してタスクを実行できることを紹介しました。 複雑になりがちなマルチエージェント構成を、比較的シンプルな記述で表現できる点が、CrewAI の大きな特徴です。
筆者自身、複数の視点から株価分析を行う「エヴァンゲリオンの MAGI」のような仕組みを検討・実装する中で CrewAI を知り、 段階的な分析や、専門性の異なる視点を組み合わせたワークフローを直感的に構築できる点に大きな可能性を感じました。 こうしたケースでも、実装負荷を抑えつつ構成を試行錯誤できるのは大きな利点です。
一方で、パラメータの組み合わせによっては期待どおりの出力が得られなかったり、 回答を安定させるために、本記事では紹介しきれなかった項目の調整が必要になる場面があることも実感しました。 トレースやモニタリングを活用しながら、挙動を確認しつつ試行錯誤していくことが重要だと感じています。
CrewAI は豊富な設定パラメータにより細かな動作制御が可能で、本記事で紹介した内容はその一部にすぎません。 監視・評価・最適化のための仕組みなど、本番利用を見据えた拡張も可能です。
まずは最小構成から試し、少しずつ機能を追加しながら、自身のユースケースに合わせて発展させてみてください。 本記事が、AI 活用の可能性を広げるきっかけになれば幸いです。