CrewAI完全ガイド｜マルチエージェント設計2026

CrewAIは、「複数のAIエージェントを“クルー(チーム)”として組織化し、役割分担しながらタスクを協調実行させる」ためのPython製マルチエージェント・オーケストレーション・フレームワークです。LangGraphが「状態遷移グラフでエージェントを記述するライブラリ」、AutoGenが「会話駆動でエージェント同士を喋らせるフレームワーク」だとすれば、CrewAIは「役割×タスク×プロセスをロール定義で先に組み、SequentialまたはHierarchicalで回す“組織モデル”」に最も近いアーキテクチャを採用しています。この記事では、公式ドキュメント（docs.crewai.com）とAnthropic公式のマルチエージェント設計指針を一次ソースとして、Crew・Agent・Task・Processの内部構造、tool定義、Anthropic/OpenAIモデル接続、Process.sequential と Process.hierarchical の挙動差、LangGraph/AutoGenとの本質的な違い、本番運用で必ず詰まる箇所、そして月次コスト試算まで、12,000字超で一気通貫に整理します。

結論：CrewAIは「役割ベースのマルチエージェント組織」を最短で組むためのフレームワーク

先に結論を3点だけ置きます。CrewAIを評価軸ごとに比較すると、次のように整理できます。

• 記述スタイル：CrewAIは role / goal / backstory / tools / tasks / process という人間組織の語彙で書く。LangGraphの「ノードとエッジでstate machineを書く」、AutoGenの「Agent同士を会話させる」より、PMやドメイン専門家がレビューしやすい記述になる。
• 制御モデル：CrewAIは Process.sequential（順次）と Process.hierarchical（マネージャーAgentが委譲）の2モードが中心。LangGraphの任意グラフほど自由ではないが、AutoGenの自由会話ほどカオスでもない、“中庸の制約”が魅力。
• 適性：「リサーチ→ライティング→レビュー」「データ抽出→集計→レポート生成」のようなパイプライン型ワークフローと相性が良く、無限ループするオープンエンドな対話系より、有限ステップの業務自動化で真価を発揮する。

つまり、「自由に動くエージェントの動物園」ではなく、「役割分担と承認フローのある仕事のチーム」をAIで再現したいケースでCrewAIを選ぶ、というのが2026年5月時点の妥当な意思決定です。逆に、グラフ的な分岐・ループ・ストリーミングが多い対話アプリではLangGraphのほうが書きやすく、研究用途のエージェント間ディベートではAutoGenのほうが素直、という棲み分けになります。

CrewAIの全体アーキテクチャ：4つのコアプリミティブ

CrewAI公式ドキュメント（docs.crewai.com）の構成を読むと、フレームワークは大きく4つのコアプリミティブで成り立っていることが分かります。

1. Agent：役割を持つ自律的な作業者。role, goal, backstory, tools, llm を持つ。
2. Task：Agentに割り当てる作業の単位。description, expected_output, agent, context, output_file を持つ。
3. Crew：Agent群とTask群を束ねるオーケストレーター。process, verbose, memory, manager_llm などのCrewレベル設定を持つ。
4. Process：Crew内のTask実行戦略。Process.sequential（順番に実行）と Process.hierarchical（マネージャーAgentが委譲する階層型）の2種類。

この4プリミティブに、外部世界と接続するためのTools（関数呼び出しやRAG検索）、長期記憶を持たせるためのMemory、そしてエンタープライズ用途のFlows（イベント駆動の上位ワークフロー）が乗る、という階層構造です。

設計マトリクス：どこに何を書くか

CrewAIで詰まる人の多くは、「ロジックをAgent側に書くのか、Task側に書くのか、Crew側に書くのか」で迷子になります。原則は次のマトリクスです。

分類	Agentに書く	Taskに書く	Crewに書く
役割定義	○（role/goal/backstory）	×	×
作業手順	×	○（description/expected_output）	×
使用ツール	○（恒久的に持つツール）	○（このTask限定のツール）	×
使用LLM	○（Agentごとに変える場合）	×	○（manager_llm／デフォルト）
記憶/共有メモリ	×	×（contextでTask間連携）	○（memory=True）
実行戦略	×	×	○（process=sequential/hierarchical）

「役割は変わらないがツールが特殊」というTaskでは、AgentのtoolsとTaskのtoolsを併用できます。逆に「同じドメイン専門家だがTaskごとにモデルを変える」は推奨されません。モデル切替は通常Agent単位で行います。

最小コード例：5分で動くリサーチ→ライティングCrew

まず最短で動くサンプルを見せます。pip install crewai crewai-tools したあと、次のコードを main.py として保存します。

import os
from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool
from langchain_anthropic import ChatAnthropic

os.environ["ANTHROPIC_API_KEY"] = "sk-ant-..."
os.environ["SERPER_API_KEY"] = "..."  # serper.dev

claude = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0.2)

search = SerperDevTool()

researcher = Agent(
    role="リサーチャー",
    goal="指定トピックについて2026年時点の一次ソースを5本以上集める",
    backstory="技術系メディアで5年のリサーチ経験。一次ソース原則を徹底する。",
    tools=[search],
    llm=claude,
    allow_delegation=False,
    verbose=True,
)

writer = Agent(
    role="テクニカルライター",
    goal="リサーチ結果を3000字の記事ドラフトに整形する",
    backstory="開発者向けメディアで100本以上の解説記事を書いてきた。",
    llm=claude,
    allow_delegation=False,
    verbose=True,
)

research_task = Task(
    description="CrewAI v0.x の最新リリース内容と、主要な使い方を調査する。",
    expected_output="箇条書き10項目以上の調査メモ。各項目に一次ソースURLを付ける。",
    agent=researcher,
)

write_task = Task(
    description="調査メモを元に、開発者向けの3000字記事ドラフトを書く。",
    expected_output="Markdown形式の記事ドラフト（H2を5個以上含む）。",
    agent=writer,
    context=[research_task],  # research_taskの結果を入力として受け取る
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential,
    verbose=True,
)

result = crew.kickoff()
print(result)

このサンプルで押さえておきたいポイントは4つです。

• context=[research_task] を write_task に渡しているので、Task間のデータ受け渡しが明示的に行われる。CrewAIはこの依存関係をDAGとして解釈する。
• llm=claude をAgentに渡しているので、CrewAIが内部で使うLLMはAnthropic Claudeになる。指定しなければデフォルトは環境変数 OPENAI_API_KEY 経由でOpenAIモデルが使われる。
• allow_delegation=False としているので、各Agentは他Agentに作業を投げない。True にすると、AgentがAgentに対して「あなたに依頼する」というツール呼び出しを発行できるようになる。
• Process.sequential は、tasksリストの順番に1つずつ実行する最も素直なモード。後述の Process.hierarchical ではこの順序がマネージャーAgent判断で動的に変わる。

Agentの内部構造：role / goal / backstory / tools / llm

Agentの公式仕様で重要なのは「自然言語で書ける属性」と「機械的な属性」が混在している点です。前者の代表が role / goal / backstory、後者の代表が tools / llm / allow_delegation / max_iter / max_rpm です。

属性	型	役割	設計時のコツ
role	str	肩書き／職種	「シニアSEOアナリスト」のように具体化
goal	str	そのAgentの目的	定量的に書く（「5本以上集める」等）
backstory	str	背景・専門性	過剰なRPGロールプレイは避ける
tools	list[Tool]	恒常的に持つツール	3個以下に絞ると選択精度が上がる
llm	BaseLanguageModel	Agent専用LLM	難タスクはOpus、軽タスクはHaiku等で混在
allow_delegation	bool	他Agentへの委譲可否	hierarchical時のみTrue推奨
max_iter	int	ReAct的な反復上限	15〜25が無難。低すぎると未完了で打ち切り
max_rpm	int	毎分API呼び出し上限	本番ではプロバイダ上限の70%
verbose	bool	ログ出力	開発時True、本番False

このうち、品質に直結するのは goal の具体性と backstory の方向性です。「優秀なライターです」とだけ書かれたAgentは、Taskの description にどれだけ詳細を書いてもブレやすい。「過去にSaaS系の解説記事を100本書いた、結論ファースト派のテクニカルライター」のように、文体や判断基準まで滲ませると出力が安定します。

Taskの内部構造：description / expected_output / context / output_file

Taskは「Agentが今このターンで完了させる作業」の単位です。CrewAIで最もチューニング効果が大きいのは、expected_output の精度です。Agentはこの記述を「合格基準」として参照するので、ここが曖昧だと完了判定がブレ、無駄なReAct反復が起きて課金が跳ねます。

analysis_task = Task(
    description=(
        "提供されたCSVから、月次MRRの推移とチャーン率の相関を分析する。"
        "ピアソン相関係数を算出し、有意水準5%で検定すること。"
    ),
    expected_output=(
        "次の3要素を含むMarkdownレポート:n"
        "1. 月次MRRとチャーン率の推移表（12ヶ月分）n"
        "2. ピアソン相関係数と p値n"
        "3. ビジネス的含意を200字で要約"
    ),
    agent=analyst,
    context=[ingest_task],
    output_file="reports/mrr_churn.md",
    async_execution=False,
)

主要属性は次のとおりです。

属性	役割	使いどころ
description	作業内容	主語＋目的＋制約を3行以内で
expected_output	成果物のフォーマット	「3要素」「JSON Schema」など機械的に書く
agent	担当Agent	hierarchicalでは省略可（マネージャーが選ぶ）
context	依存Taskリスト	DAGの辺を作る。直前Taskの出力を渡す
tools	Task限定ツール	このTaskでだけ使う特殊APIを指定
output_file	出力ファイルパス	レポート系で便利
output_json/output_pydantic	構造化出力スキーマ	Pydanticモデルで型安全化
async_execution	非同期実行	Trueにすると後続Taskと並列化可能
human_input	人間の承認	完了前にヒューマンレビューを挟む

output_pydantic は本番運用で特に重要です。LLMの出力をPydanticモデルに強制すると、後段のロジックが破綻しなくなります。「JSONで出して」と祈るより、Pydanticで縛るのがCrewAIの正解パターンです。

Process.sequential vs Process.hierarchical：実行戦略の本質差

CrewAIのProcessは現状2種類です。両者の挙動を正確に理解しないと、コストとレイテンシが意図せず数倍に跳ねます。

Process.sequential：定義順に1本道で流す

tasksリストの順番にTaskを1つずつ実行し、各Taskの出力は context 経由で後続Taskに渡されます。実行フローはDAGというより直列パイプラインに近く、挙動が予測しやすいのが最大のメリットです。

• 長所：デバッグが容易、コスト試算が立てやすい、フォールバック設計しやすい
• 短所：分岐や並列が書きづらい（async_execution併用で部分的に可能）
• 推奨ユースケース：リサーチ→ライティング→校正、ETL→分析→レポート、要件抽出→設計→コード生成

Process.hierarchical：マネージャーAgentがTaskを割り振る

Process.hierarchical を選ぶと、CrewAIは内部でマネージャーAgentを1体生成します。マネージャーは manager_llm（または manager_agent で明示）に指定したLLMを使い、各Taskを「どのAgentに任せるか」「再依頼するか」「結果を承認するか」を判断します。Anthropicの「Building effective agents」でいう Orchestrator-Workers パターンに対応します。

crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, write_task, review_task],
    process=Process.hierarchical,
    manager_llm=ChatAnthropic(model="claude-opus-4-1-20250805"),
    verbose=True,
)

• 長所：要件が動的に変わる業務（顧客対応・問い合わせトリアージ）に強い、Agentが自然に役割分担する
• 短所：マネージャーAgentの追加トークンでコストが1.3〜2倍に膨らみがち、デバッグ難度が一段上がる
• 推奨ユースケース：問い合わせ仕分け、複合的なリサーチ（どの専門家に振るかが事前に決まらない）、品質ゲートとして上長レビューを挟みたいワークフロー

選択早見表

状況	推奨Process	理由
Taskの順序が固定	sequential	マネージャー不要、コスト最小
Taskが3〜5本で固定だが品質ゲート必須	sequential + 最終Taskにreviewer Agent	hierarchicalまで重武装する必要はない
顧客からの問い合わせ内容で担当が変わる	hierarchical	マネージャーが動的アサインする価値が出る
分岐とループが多い対話型UI	そもそもCrewAI不向き	LangGraphでstate machineを書くべき

初期実装はsequentialから始め、運用実績で「動的アサインが必要」と分かってからhierarchicalへ移行するのが安全です。

Toolsの定義：BaseTool継承と @tool デコレーター

CrewAIのToolは crewai_tools のビルトイン（SerperDevTool / FileReadTool / WebsiteSearchTool 等）に加え、自前でも簡単に書けます。書き方は2系統あります。

方式A：BaseToolを継承する（推奨）

from crewai.tools import BaseTool
from pydantic import BaseModel, Field
import requests

class InvoiceLookupInput(BaseModel):
    invoice_id: str = Field(description="請求書ID（INV-で始まる文字列）")

class InvoiceLookupTool(BaseTool):
    name: str = "invoice_lookup"
    description: str = (
        "社内会計システムから請求書情報を取得する。"
        "invoice_idを渡すと、金額・取引先・支払期日を返す。"
    )
    args_schema: type[BaseModel] = InvoiceLookupInput

    def _run(self, invoice_id: str) -> str:
        r = requests.get(f"https://internal.example.com/api/invoices/{invoice_id}", timeout=10)
        r.raise_for_status()
        d = r.json()
        return f"金額: ¥{d['amount']:,} / 取引先: {d['client']} / 期日: {d['due_date']}"

BaseTool継承のメリットは、args_schema による型検証と description によるツール選択精度の向上です。Agentは複数Toolの中からこのdescriptionを読んで「どれを使うか」を判断するので、ここは丁寧に書くほどReAct反復が減ります。

方式B：@toolデコレーター（軽量）

from crewai.tools import tool

@tool("get_weather")
def get_weather(city: str) -> str:
    """指定された都市の現在の天気をJSON文字列で返す。"""
    # 実装省略
    return '{"city": "Tokyo", "temp": 22, "condition": "Cloudy"}'

軽い関数ツールはこちらが手軽。ただし入力スキーマの厳格な検証や、状態を持つToolではBaseToolを推奨します。

Anthropic / OpenAI / その他プロバイダー接続

CrewAIはLangChainのChatModelをそのまま受け取れるので、Anthropic Claude・OpenAI・Google・Groq・ローカル（Ollama）など多くのプロバイダーに接続できます。

from langchain_anthropic import ChatAnthropic
from langchain_openai import ChatOpenAI
from langchain_google_genai import ChatGoogleGenerativeAI
from langchain_community.chat_models import ChatOllama

claude_sonnet = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0.2)
claude_opus = ChatAnthropic(model="claude-opus-4-1-20250805", temperature=0.1)
gpt5 = ChatOpenAI(model="gpt-5.1", temperature=0.2)
gemini = ChatGoogleGenerativeAI(model="gemini-2.5-pro")
local = ChatOllama(model="llama3.1:70b")

researcher = Agent(role="リサーチャー", goal="...", backstory="...", llm=claude_sonnet)
writer     = Agent(role="ライター", goal="...", backstory="...", llm=claude_sonnet)
critic     = Agent(role="クリティック", goal="...", backstory="...", llm=claude_opus)

本番でのモデル選定の鉄則は、「考える役はOpus、書く役はSonnet、整形役はHaiku/Mini」というように、Agentの役割で温度感を変えること。全Agent最高位モデルで揃えると、コストが3〜5倍に跳ねがちです。後段のコスト試算でこの効果を数字で見ます。

Memory：短期・長期・エンティティ・コンテクスチュアル

CrewAIのmemory=Trueを有効化すると、Crew内で次の4種類のメモリが立ち上がります。

種類	役割	裏側
Short-Term Memory	現在の実行内での情報	RAGストア（ChromaDB等）
Long-Term Memory	過去のkickoff結果から学習	SQLite永続化
Entity Memory	登場した人物・組織・概念	RAGストア
Contextual Memory	上記3つを統合した文脈	クエリ時に動的合成

本番運用では、個人情報を含む業務はLong-Term Memoryを安易にONにしないのが原則です。SQLite永続化先のディレクトリと暗号化・アクセス制御を必ず設計してください。コンプライアンス上必要なら、デフォルトのChromaDBではなく、社内VPCに置いたベクトルDBへ向けることもできます。

LangGraph / AutoGen との比較：選択基準

2026年時点で、Pythonのマルチエージェント・フレームワークとして実務で名前が挙がる三大選択肢がCrewAI / LangGraph / AutoGenです。役割が違うので、機能の優劣ではなくどのメンタルモデルに馴染むかで選びます。

観点	CrewAI	LangGraph	AutoGen
メタファー	役割×タスクの組織	状態遷移グラフ	エージェント間会話
記述スタイル	Agent/Task/Crew	Node/Edge/State	Agent.send/receive
得意分野	業務パイプライン	対話・分岐・ストリーミング	研究・エージェント間ディベート
制御の自由度	中（sequential/hierarchical）	高（任意グラフ）	高（自由会話）
学習曲線	緩やか	中〜急	中
ヒューマンインザループ	Task.human_input	interrupt()	UserProxyAgent
非開発者の読みやすさ	◎	△	○
主要観測ツール連携	LangSmith/AgentOps	LangSmith（同社）	各種

使い分けのざっくりした目安は次のとおりです。

• 業務自動化（リサーチ・ライティング・レポート・社内問い合わせ仕分け）：CrewAI 一択級。PMやドメイン専門家にコードを読ませて「役割は合ってるか」を議論できるのが大きい。
• 対話アプリ・複雑な分岐／ループ・ストリーミング：LangGraph。状態を TypedDict で持って、ノードを純粋関数として書く設計が向く。CrewAIで無理に書くと、Process.hierarchicalの上に独自ロジックが乗って読みづらくなる。
• 研究・実験・複数Agentのディベート：AutoGen。発話ターン制御や役割切替が会話メタファーで書きやすい。本番のSLA管理は別途仕組みが必要。

そして3つは排他ではありません。「外側はLangGraphでstate machineを組み、特定ノードの中身でCrewAIをkickoffする」のような併用も実務では一般的です。エンタープライズ案件では、CrewAIで業務単位のクルーを20〜30本作り、それを上位のオーケストレーター（LangGraphやTemporal等のワークフローエンジン）から呼ぶ構成が落ち着きどころです。

このオーケストレーターとワーカーの役割分担そのものの設計指針は、マルチエージェント設計パターン（Orchestrator-Worker型）の解説記事で詳しく扱っているので、CrewAIに乗せる前にアーキテクチャ判断したい人はそちらも合わせて読んでください。

本番運用の落とし穴：トークン爆発・無限ループ・観測欠如

CrewAIのデモは動かしやすい一方、本番でPoCから抜けるときに必ずぶつかる落とし穴があります。代表的な5つを潰しておきます。

1. トークン爆発：contextの肥大化と verbose ログの混入

Task間の context は、デフォルトでは「直前Taskの最終出力全文」が後続Taskのコンテキストに乗ります。10本のTaskを直列に組むと、最終Taskの入力が初期プロンプト＋全前段出力＋ツール呼び出しログで数万トークンに達することがあります。対策は2つ。

• expected_outputをJSON Schemaで縛り、後段Taskが必要なフィールドだけを引き継げるようにする。Pydantic（output_pydantic）を使うと特に強い。
• 長いTaskチェーンでは、中間にサマライザーAgentを挟み、3000字以上の中間生成物は500字以下に要約してから次へ渡す。

2. 無限ループ：allow_delegation=True と max_iter のミスマッチ

Process.hierarchical かつ複数Agentで allow_delegation=True にすると、AgentがAgentに無限に投げ合う事故が起きます。CrewAIには max_iter（Agent単位）と max_execution_time（Crew単位）があるので、本番では必ず両方設定してください。目安は max_iter=15〜25、max_execution_time=600〜1800秒です。

3. レート制限：max_rpmとリトライ戦略

Anthropic / OpenAIともに、組織単位とモデル単位でレート制限があります。複数Agentが同じLLMを並列に叩く構成では、簡単に上限に当たります。Agent単位の max_rpm を設定し、プロバイダー上限の70%程度に留めるのが安全です。さらに、ツール呼び出しのリトライポリシー（指数バックオフ、最大3回）も独自Toolで実装しておきます。

4. 観測欠如：本番でprintは犯罪

verbose=True のprintログだけでは、本番事故の原因究明はほぼ不可能です。最低限、次の観測項目をログ／OpenTelemetryで送ります。

• Agentごとのトークン消費（入力／出力）
• Taskごとの所要時間と完了/失敗フラグ
• Tool呼び出しの引数・戻り値・失敗時の例外
• マネージャーAgentの委譲判断ログ（hierarchical時）

CrewAI公式はAgentOps / LangSmith / WeaveLineage等との連携を案内しています。LangSmithを使った観測設計の具体的なTraceスキーマやEvalセット設計は、LangSmithでのAIエージェント観測・評価ガイドで詳しく解説しています。

5. プロンプトインジェクション：Toolの引数バリデーション

マルチエージェントはAgent間のメッセージが内部プロンプトになるため、外部から流入したテキスト（顧客の問い合わせ、Webスクレイピング結果）が次Agentのプロンプトに混入します。Toolの引数は必ずPydanticで型・パターンを検証し、自由文字列はサニタイズしてからLLMに渡してください。社内APIを叩くツールは、Agent側のロールに関わらず認可ロジックをTool側で再チェックするのが鉄則です。

コスト試算：典型ワークフローでの月額シミュレーション

「結局、月いくらかかるのか」が一番重い意思決定材料なので、典型ワークフローでのざっくり試算を出します。前提は2026年5月の公開単価をベースに、控えめなトークン量で見積もったものです（実値はプロバイダー公式価格を必ず確認してください）。

ケース1：3 Agentリサーチ→ライティング（sequential）

• 構成：researcher（Claude Sonnet）→ writer（Claude Sonnet）→ editor（Claude Sonnet）
• 1回のkickoffあたりトークン：入力15,000＋出力5,000程度
• 月間100記事生成すると仮定
• 月額試算：Anthropic Claude Sonnet系の標準的な単価レンジで概ね ¥30,000〜¥60,000 オーダー

このボリュームなら、コストは月数万円台で十分に収まります。本番ではむしろ、ベクトルDB（記憶用）とSerper等の検索APIの方が固定費としてじわじわ効きます。

ケース2：マネージャー付き5 Agent業務トリアージ（hierarchical）

• 構成：manager（Claude Opus）＋ specialist 4体（Claude Sonnet）
• 1回あたり：マネージャーが2〜4回の委譲判断を行うため入力40,000＋出力10,000程度
• 月間問い合わせ5,000件処理を想定
• 月額試算：マネージャーがOpus系のため割高で ¥800,000〜¥1,500,000 オーダー

このボリュームになると、マネージャーAgentのLLM選定がコストを支配します。Opusで全件さばく構成から、「初期分類はSonnet→難案件のみOpus」へ二段構えにするだけで30〜50%削れる、というのが典型的なチューニングパターンです。

ケース3：全Agent Opus化（誘惑に負けた構成）

• 構成：全Agent最高位モデル
• 同じワークロードでケース2比 2〜3倍 のコスト
• 多くの場合、品質改善は10〜15%程度

「とりあえず一番強いモデルで」は技術的には楽ですが、コスト効率は最悪です。Agent単位でモデルを変えられるのがCrewAIの大きな利点なので、必ず役割×難易度ベースでモデルを分散させてください。

YAML駆動・CLIワークフロー：crewai create crew

v0.x以降のCrewAIにはCLIが同梱され、crewai create crew my_projectで雛形を生成できます。生成されるディレクトリは次の構造です。

my_project/
├── pyproject.toml
├── src/
│   └── my_project/
│       ├── config/
│       │   ├── agents.yaml
│       │   └── tasks.yaml
│       ├── crew.py
│       ├── main.py
│       └── tools/
│           └── custom_tool.py
└── tests/

agents.yamlとtasks.yamlで宣言的に役割と作業を書くスタイルは、レビューと運用に強いのが特徴です。コードで毎回 Agent(role="...", goal="...") を書くより、yamlを差分管理した方がPRがクリーンになります。

# config/agents.yaml
researcher:
  role: >
    シニアリサーチアナリスト
  goal: >
    {topic} の最新の一次ソースを5本以上集める
  backstory: >
    技術系メディアで5年のリサーチ経験
  verbose: true

writer:
  role: >
    テクニカルライター
  goal: >
    {topic} に関する3,000字記事ドラフト作成
  backstory: >
    開発者向けに100本以上の記事執筆実績
  verbose: true

# config/tasks.yaml
research_task:
  description: >
    {topic} について最新の一次ソースを5本以上集め、箇条書きにまとめる
  expected_output: >
    箇条書き10項目以上、各項目にURLを付ける
  agent: researcher

write_task:
  description: >
    research_taskの結果を元に3,000字記事を書く
  expected_output: >
    Markdown形式の記事（H2を5個以上含む）
  agent: writer
  context:
    - research_task

{topic} のようなテンプレ変数は main.py 側で inputs={"topic": "..."} としてkickoff時に渡せます。これにより、同一Crew定義で100本の記事を量産する、といったテンプレ運用が可能になります。

OpenAIネイティブと比較した時のCrewAIの立ち位置

2025〜2026年にかけて、OpenAI Agents SDKやAssistants APIなど、プロバイダー純正のAgentランタイムが整備されてきました。「ベンダーロックインを避けたいか、最短で本番に乗せたいか」で選び方が変わります。OpenAI Agents SDKと一般的なPythonエージェントフレームワーク、TypeScript版との比較は、OpenAI Agents SDKのTypeScript版・Python版比較の記事で別途整理しているので、純正SDKとの比較で迷っている人はそちらを併読してください。

CrewAIの強みは、マルチプロバイダーで動く・組織モデルで書ける・Sequential/Hierarchicalの2モードで意思決定が単純な点です。逆に、ストリーミングUIや会話駆動の自由度はLangGraphに譲りますし、プロバイダーネイティブの最新機能（例：OpenAIのResponses API＋Toolsの最新拡張）への追従はネイティブSDKほど速くありません。「業務自動化の足回り」と割り切るのが正しい使い方です。

CrewAI導入のステップガイド（PoCから本番まで）

最後に、CrewAIをPoCから本番まで進めるときの実務ステップを置きます。

1. 業務の選定：有限ステップで、入出力が明確で、ヒューマンレビューを挟める業務から始める（リサーチ系・社内文書生成系・問い合わせ仕分けが鉄板）
2. 役割の棚卸し：人間の組織で誰が何をしているかを書き出す。これがそのままAgent定義になる
3. Taskの定義：1人がこなす作業を1Taskに切る。expected_outputは必ずスキーマで書く
4. Processの選択：Task順序が固定ならsequential、動的に変わるならhierarchical
5. モデル選定：難思考はOpus相当、文章生成はSonnet相当、整形は最小モデル
6. Tool統合：社内API・社内検索・社内DBをBaseTool継承で実装
7. Memory設計：個人情報を含むなら永続化先と暗号化を必ず先に決める
8. 観測導入：LangSmithやAgentOpsでトレース、トークン、レイテンシを可視化
9. 評価セット作成：Golden Setを20〜50件用意し、PR毎にスコア回帰チェック
10. 段階リリース：シャドーモード → 人間レビュー必須 → 部分自動化 → 全自動化、と段階を踏む

このうち、最も省略されやすいのが 評価セット作成と段階リリースです。CrewAIは「動かすのが簡単」だからこそ、観測と評価を後回しにすると、PoC成功→本番リリース→事故、のルートを踏みやすい。AnthropicのBuilding effective agentsでも繰り返し強調されているとおり、エージェント開発の8割は「動かす」より「評価し続ける」仕事だと考えてください。

まとめ：CrewAIは“役割で考える”チームに向くフレームワーク

CrewAIは、エージェントを役割×タスク×プロセスの3軸で記述するという、最も人間組織に近いメンタルモデルを持つマルチエージェントフレームワークです。Sequential / Hierarchicalの2モードに絞られた制約が、PoC速度と本番デバッグ性のバランスを取っています。LangGraphの自由度やAutoGenの会話メタファーには無い「業務オーケストレーションの読みやすさ」が最大の武器であり、業務自動化文脈では2026年時点で最有力候補のひとつです。

一方で、本番ではトークン爆発・無限ループ・観測欠如・プロンプトインジェクションといった共通課題に必ず直面します。Pydantic駆動の出力スキーマ、max_iter / max_rpm / max_execution_time の3点セット、AgentOpsやLangSmithでの観測、Tool層での認可再チェックを最初から組み込むことが、PoC止まりにせず本番に乗せる分水嶺です。役割で書けるからこそ、組織設計の手抜きが直接コストとリスクに転化します。逆に言えば、「業務をいかにきれいに分解するか」「expected_outputをいかに具体的に書くか」を一度突き詰めた組織は、その後のエージェント実装すべてに効く資産を手にできます。