mcpField
G
getting-started

getting-started

github.com/crewaiincエージェントワークフロー488.4k 回インストール3 週間前に更新
リポジトリ

getting-started について

CrewAI の抽象レベルの選択、コマンドラインによるプロジェクト生成、Agent・Crew・Flow の構成を案内するスキルです。生成済みプロジェクトから本番ワークフローや会話型 Flow を構築する開発者向けです。

主な機能

  1. 01抽象レベルの選択ガイド
  2. 02CLIを使ったプロジェクト生成
  3. 03Agent・Crew・Flowの構成パターン
  4. 04YAML設定の案内
  5. 05本番ワークフローのオーケストレーション

活用シーン

  1. 01適切なCrewAI構成要素の選択
  2. 02CLIスキャフォールドからの開発開始
  3. 03複数ステップの本番ワークフロー構成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/crewaiinc/skills --skill getting-started

インストール後、Claude Code で/getting-startedを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
conversational-flows.md
crew-yaml-config.md
flow-routing.md
mcp-servers.md
tools-catalog.md

詳細

CrewAI の始め方とアーキテクチャ

適切な抽象化を選び、プロジェクトをひな形から作成し、すべてを連携させる方法です。

2026-10-01 に crewai 1.15.23 で検証済みです。 2026-10-01 に実際の LLM を使って動作確認済みです。 まず crewai version を実行してください。メジャーまたはマイナーバージョンが 1.15 と異なる場合は、ask-docs スキルでバージョン依存の詳細を再確認してください。


必須のワークフロー — まずお読みください

crewAI のプロジェクトファイルを手動で作成してはいけません。 必ず CLI でひな形を作成してください。

crewai create flow <project_name>

これは必須です。必要なのがクルー 1 つだけの場合や、ファイル構成を熟知している場合でも、まず CLI を実行し、その後に生成されたファイルを変更してください。main.py、crew.py、agents.yaml、tasks.yaml、pyproject.toml を最初から手作業で作成してはいけません。

理由: CLI は、正しいインポート、ディレクトリ構成、pyproject.toml の設定、そして手動で作成するとわずかな間違いが生じやすい定型コードを設定します。以下のリファレンスでは各要素の仕組みを説明します。目的は、ひな形から作成したコードを変更できるようにすることであり、ひな形作成の手順を置き換えることではありません。

ワークフロー:

  1. crewai create flow <name> を実行します(アンダースコアを推奨します。CLI はフォルダー名とパッケージ名のために、ハイフンとスペースをアンダースコアに変換します)
  2. 生成された YAML ファイルと Python ファイルをユースケースに合わせて編集します
  3. crewai install を実行してから、crewai run を実行します

1. 適切な抽象化を選ぶ

crewAI には、よく使われる抽象化の選択肢が 5 つあります。要件に合う最もシンプルなものを選んでください。

レベル使用する場面オーバーヘッド例
LLM.call()単一のプロンプト、ツールなし、構造化抽出最小メールをフィールドに分解する
Agent.kickoff()ツールと推論機能を備えた 1 つのエージェント。マルチエージェント連携は不要低ウェブ検索でトピックを調査する
Crew.kickoff()複数のエージェントが関連タスクで協力する中調査 + 執筆 + レビューのパイプライン
Flow wrapping crews/agents/LLM calls`状態、ルーティング、条件分岐、エラー処理を備えた本番アプリ最大分岐ロジックを含む複数ステップのワークフロー
会話型 Flow同じセッション ID でユーザーの各発言ごとに Flow を再実行するマルチターンチャット最大 + 試験的ルーティングされたチャット、調査、エスカレーションに対応するサポートアシスタント
判断フローチャート
Do you need tools or multi-step reasoning?
├── No  → LLM.call()
└── Yes
    └── Do you need multiple agents collaborating?
        ├── No  → Agent.kickoff()
        └── Yes
            └── Do you need state management, routing, or multiple crews?
                ├── No  → Crew (but still scaffold as a Flow for future-proofing)
                └── Yes → Flow + Crew(s)

Do users send multiple chat messages in one session?
└── Yes → Conversational Flow with handle_turn(message, session_id=...)

経験則: 本番アプリケーションでは、必ず Flow から始めてください。Flow のステップ内に LLM.call()、Agent.kickoff()、または Crew.kickoff() を組み込めます。これにより、状態管理とエラー処理を利用でき、将来的な拡張にも対応できます。

チャットアプリケーションでは、Crew.kickoff() や Flow.kickoff() をチャットループのように使おうとせず、会話型の Flow から始めてください。ユーザーの各発言に対して flow.handle_turn(message, session_id=...) を呼び出すか、ローカルのターミナル REPL には flow.chat() を使用します。公式ガイド:https://docs.crewai.com/en/guides/flows/conversational-flows


2. LLM.call() — LLM の直接呼び出し

ツールやエージェントの推論が不要な、シンプルな単一ターンのタスクに使用します。

from crewai import LLM
from pydantic import BaseModel

class EmailFields(BaseModel):
    sender: str
    subject: str
    urgency: str

llm = LLM(model="openai/gpt-4o")   # non-OpenAI providers need their extra, e.g. uv add "crewai[anthropic]"

# Plain call - returns a string
raw = llm.call(messages=[{"role": "user", "content": "Summarize this text..."}])
print(raw)  # str

# With response_model - returns the Pydantic object directly
result = llm.call(
    messages=[{"role": "user", "content": f"Extract fields from this email: {email_text}"}],
    response_model=EmailFields,
)
print(result.sender)   # str — access Pydantic fields directly
print(result.urgency)  # str

llm.call(..., response_format=Model) を実行すると、TypeError: ... unexpected keyword argument 'response_format'. Did you mean 'response_model'? が発生します。LLM.call() ではキーワードに response_model を使用し、Agent.kickoff() では response_format を使用します(次のセクションを参照)。

使用しない場面: ツール、複数ステップの推論、または再試行が必要な場合は、代わりに Agent を使用してください。


3. Agent.kickoff() — 単一エージェントの実行

マルチエージェント連携は不要でも、ツールと推論機能を備えたエージェントが 1 つ必要な場合に使用します。

from crewai import Agent
from crewai_tools import SerperDevTool
from pydantic import BaseModel

class ResearchFindings(BaseModel):
    main_points: list[str]
    key_technologies: list[str]

researcher = Agent(
    role="AI Researcher",
    goal="Research the latest AI developments",
    backstory="Expert AI researcher with deep technical knowledge.",
    llm="openai/gpt-4o",       # Optional: defaults to the MODEL / MODEL_NAME / OPENAI_MODEL_NAME env var, else "gpt-4.1-mini"
    tools=[SerperDevTool()],   # needs SERPER_API_KEY
)

# Unstructured output
result = researcher.kickoff("What are the latest LLM developments?")
print(result.raw)            # str
print(result.usage_metrics)  # token usage dict

# Structured output with response_format
result = researcher.kickoff(
    "Summarize latest AI developments",
    response_format=ResearchFindings,
)
print(result.pydantic.main_points)

注: Agent.kickoff() の結果は LiteAgentOutput でラップされます。構造化出力には result.pydantic からアクセスしてください。これは Pydantic オブジェクトを直接返す LLM.call() とは異なります。

使用しない場面: 複数のエージェント間でコンテキストを受け渡す必要がある場合は、Crew を使用してください。


4. CLI スキャフォールドのリファレンス

前述のとおり、crewai create flow は絶対に省略しないでください。 このセクションでは、CLI が生成する内容を記載しています。手作業で再作成するためではなく、変更すべき箇所を把握するためのものです。

crewai create flow my_project

命名: crewai create flow my-project も引き続き動作します。CLI はフォルダーとパッケージを my_project として作成しますが、入力する名前とインポートするパッケージ名を一致させるため、アンダースコアを使用してください。

以下が生成されます(crewai 1.15.23)。

my_project/
├── src/my_project/
│   ├── crews/
│   │   └── content_crew/
│   │       ├── config/
│   │       │   ├── agents.yaml    # Agent definitions (role, goal, backstory)
│   │       │   └── tasks.yaml     # Task definitions (description, expected_output)
│   │       └── content_crew.py    # Crew class with @CrewBase
│   ├── tools/
│   │   └── custom_tool.py
│   └── main.py                    # Flow class with @start/@listen, plus kickoff() and plot()
├── .env                           # OPENAI_API_KEY placeholder - replace it, never commit it
├── AGENTS.md, CLAUDE.md, GEMINI.md, CURSOR.md   # coding-assistant instructions
├── README.md
└── pyproject.toml                 # [tool.crewai] type = "flow"; scripts kickoff, plot, ...

生成されるスキャフォールドが依存するのは crewai[tools] のみです。crewai create flow も crewai create crew --classic もプロバイダー用のエクストラを追加しないため、OpenAI 以外のモデルを使う場合は、crewai install の前に uv add "crewai[anthropic]"(または該当するエクストラ)を実行してください。

生成される main.py は絶対パッケージパスでインポートします。from my_project.crews.content_crew.content_crew import ContentCrew および from crewai.flow import Flow, listen, start の形式です。このスタイルを維持してください。相対インポート(from .crews...)は uv run src/my_project/main.py で動作せず、crewai deploy validate も失敗します(deploy-to-amp スキルを参照)。main.py の kickoff() は None を返すようにしてください。コンソールスクリプトは sys.exit(kickoff()) を実行するため、結果を返すとプロセスは終了コード 1 で終了します。Flow のスキャフォールドの詳細は、build-flow スキルを参照してください。

crewai create flow を推奨します。 ルーティング、状態、または複数の Crew が今後必要になることは絶対にないと確信できる場合に限り、crewai create crew <name> --classic を使用してください。--classic を指定しない場合、crewai create crew は対話型ウィザードを起動し、以下の @CrewBase + YAML 形式ではなく、JSON プロジェクト(crew.jsonc、agents/*.jsonc)を書き出します。ターミナルがない場合は Aborted! と表示されます。スクリプトでプロバイダーのプロンプトを省略するには、--skip-provider を追加してください。


5. Crew:YAML 設定と @CrewBase

スキャフォールドでは、YAML でエージェントとタスクを定義し、それらを @CrewBase クラスで連携させます。2 エージェントを使用する完全な例については、Crew の YAML 設定を参照してください。

# config/agents.yaml
researcher:
  role: >
    {topic} Senior Data Researcher
  goal: >
    Uncover cutting-edge developments in {topic}
  backstory: >
    You're a seasoned researcher with a knack for uncovering
    the latest developments in {topic}.
  # Optional overrides: llm: openai/gpt-4o, max_iter: 20, max_rpm: 10

# config/tasks.yaml
research_task:
  description: >
    Conduct thorough research about {topic}.
  expected_output: >
    A detailed report on the top 5 developments in {topic}.
  agent: researcher
  output_file: output/report.md
from crewai import Agent, Crew, Process, Task
from crewai.project import CrewBase, agent, crew, task

@CrewBase
class ResearchCrew:
    """Research crew."""

    agents_config = "config/agents.yaml"   # these two paths are also the defaults
    tasks_config = "config/tasks.yaml"

    @agent
    def researcher(self) -> Agent:          # method name == YAML key
        return Agent(config=self.agents_config["researcher"])

    @task
    def research_task(self) -> Task:
        return Task(config=self.tasks_config["research_task"])

    @crew
    def crew(self) -> Crew:
        return Crew(agents=self.agents, tasks=self.tasks, process=Process.sequential, verbose=True)

主なルール:

  • {variable} プレースホルダーは、実行時に crew.kickoff(inputs={...}) を通じて置換されます
  • expected_output は常に文字列です(Pydantic クラス名は指定しません)。Python の @task メソッドで output_pydantic=Model を設定してください
  • agent の値は agents.yaml のエージェントキーと一致する必要があります。また、メソッド名も YAML のキーと一致させてください(def researcher → researcher:)
  • Process.sequential では、各タスクがそれ以前のすべてのタスクの出力をコンテキストとして自動的に受け取ります
  • 順次実行ではない依存関係には、context=[other_task] を使って出力を明示的に渡してください

6. Flow — 本番環境の基盤

本番環境の crewAI アプリケーションを構築するには、Flow の使用を推奨します。Flow は、状態管理、条件付きルーティング、Human-in-the-Loop、永続化を提供し、Crew、エージェント、LLM 呼び出しを一貫性のあるワークフローにまとめます。このセクションでは、各抽象化がどのように連携するかを説明します。Flow API 全体(状態のルール、or_/and_、@persist、チェックポイント、@human_feedback、plot())については、build-flow スキルを参照してください。

基本的な Flow — main.py
from crewai.flow import Flow, listen, start
from pydantic import BaseModel
from my_project.crews.research_crew.research_crew import ResearchCrew

class ResearchState(BaseModel):
    topic: str = ""
    report: str = ""

class ResearchFlow(Flow[ResearchState]):

    @start()
    def begin(self):
        print(f"Starting research on: {self.state.topic}")

    @listen(begin)
    def run_research(self):
        result = ResearchCrew().crew().kickoff(
            inputs={"topic": self.state.topic}
        )
        self.state.report = result.raw

def kickoff():
    flow = ResearchFlow()
    flow.kickoff(inputs={"topic": "AI Agents"})   # do not return the result

if __name__ == "__main__":
    kickoff()

主なポイント:

  • flow.kickoff(inputs={"topic": "AI Agents"}) を実行すると、self.state.topic に値が設定されます(キーは Pydantic フィールド名と一致する必要があります。一致しないキーは通知なく破棄されます)。YAML の {variable} 置換はその後、Flow のステップ内で crew.kickoff(inputs={"topic": self.state.topic}) を呼び出したときに行われます。処理の流れは、Flow の入力 → 状態 → Crew の入力 → YAML 置換です。
  • 各 @listen メソッドは、依存先の処理が完了した後に実行されます
  • すべての Flow ステップを通じて状態は保持されます。Crew 間でデータを渡すには、この状態を使用してください

状態: 型安全性と検証のため、構造化状態(Pydantic モデルを使う Flow[MyState]。すべてのフィールドにデフォルト値を設定)を使用してください。一時的なプロトタイプには、class MyFlow(Flow) で辞書形式の状態(self.state["topic"])を使用できます。id は自分で宣言しないでください。Flow が追加します。

Flow 内での Agent.kickoff() の使用(一般的なパターン)

多くの本番環境の Flow では Crew を使わず、Agent.kickoff() を介して個々のエージェントをオーケストレーションします。これにより、きめ細かな制御が可能になります。各 Flow ステップで、目的に特化したエージェント(役割を絞り、特定のツールを使用)を構築して状態を渡し、result.raw(または response_format=Model を指定した result.pydantic)を状態に保存します。オーケストレーションは Flow が担い、推論はエージェントが担います。次の例にある handle_simple ステップがこのパターンです。

Flow で Agent.kickoff() と Crew.kickoff() を使い分ける基準:

Agent.kickoff() を使う場合Crew.kickoff() を使う場合
各ステップが、異なるツールを使う個別のエージェントである複数のエージェントが 1 つのタスクで協力する必要がある
Flow で処理の順序を制御したいステップ内でエージェント同士がコンテキストを受け渡す必要がある
ステップが独立していて、エージェント間の委任を必要としないマネージャーを配置した階層型プロセスが必要である
ステップ間で受け渡すデータを最大限制御したいサブワークフローが自己完結しており、再利用可能である
Flow 内で抽象化を組み合わせる

Flow では、1 つのワークフロー内ですべての crewAI 抽象化を組み合わせることができます。

from crewai import LLM, Agent
from crewai.flow import Flow, listen, router, start

class ProductFlow(Flow[ProductState]):

    @start()
    def classify_request(self):
        # LLM.call() for simple classification
        llm = LLM(model="openai/gpt-4o")
        self.state.category = llm.call(
            messages=[{"role": "user", "content": f"Classify as 'simple' or 'complex': {self.state.request}"}],
            response_model=Category,
        ).category

    @router(classify_request)
    def route_by_category(self):
        if self.state.category == "simple":
            return "quick_answer"
        return "deep_research"

    @listen("quick_answer")
    def handle_simple(self):
        # Agent.kickoff() for single-agent work
        agent = Agent(role="Helper", goal="Answer quickly", backstory="...")
        self.state.answer = agent.kickoff(self.state.request).raw

    @listen("deep_research")
    def handle_complex(self):
        # Crew.kickoff() for multi-agent collaboration
        result = ResearchCrew().crew().kickoff(
            inputs={"topic": self.state.request}
        )
        self.state.answer = result.raw
ルーティング、合流、永続化、人間によるフィードバック — 簡易版
  • @router(method) は文字列ラベルを返し、@listen("label") はその分岐を実行します。ラベルを、それをリッスンするメソッドの名前と同じにしてはいけません。また、すべてのラベルにリスナーが必要です(対応するリスナーのないラベルが返されると、Flow は何も通知せずに終了します)。
  • or_(a, b) は、最初に完了した条件で 1 回 実行されます。and_(a, b) は、すべての条件が完了した後に 1 回実行されます。どちらも crewai.flow からインポートしてください。
  • @persist()(括弧付き。from crewai.flow import persist)は状態をローカルの SQLite ファイルに保存します。kickoff(restore_from_state_id=...) で再開できます。
  • @human_feedback(message=..., emit=[...], llm=..., default_outcome=...) はレビューのために一時停止し、その結果に応じてルーティングします。レビュー担当者のテキストは、HumanFeedbackResult の result.feedback(または self.last_human_feedback.feedback)に格納されます。
  • flow.plot("my_flow.html", show=False) は、一時ディレクトリにインタラクティブな HTML を書き込み、そのパスを返します。PNG は生成されません。

それぞれのテスト済みパターンは、Flow Routing と build-flow スキルにあります。

handle_turn() による会話フロー

サポートアシスタント、ルーティングされたリサーチヘルパー、オンボーディングウィザードなど、同じユーザーが複数のターンを送信する UI のように、製品がチャットセッションである場合は、会話型の Flow を使用します。

基本モデル:

  • 各ユーザーメッセージは、同じセッション ID を使用する新しい Flow の実行です
  • handle_turn(message, session_id=...) はユーザーのメッセージを state.messages に追加し、ターンごとの実行トラッキングをリセットして、内部で kickoff(inputs={"id": session_id}) を呼び出します
  • Flow.kickoff() は user_message= または session_id= のキーワード引数を受け付けません(TypeError)
  • route_turn() と @listen("ROUTE") ハンドラーを使ってチャットのターンをルーティングするか、route_turn() を省略して LLM ルーターにハンドラーから選択させます
  • ハンドラーが返す文字列はアシスタントの返信になります。明示的に記録したい場合は append_assistant_message(reply) を呼び出します(重複して記録されることはありません)
  • 自分で管理するループは try/finally で囲み、finalize_session_traces() を呼び出します。flow.chat() はローカル REPL 向けにこれを実行します

crewai.flow からインポートしてください。crewai.experimental.conversational は同じモジュールの非推奨エイリアスです。@ConversationConfig デコレーターはすでに conversational = True を設定しており、defer_trace_finalization のデフォルトは True です。llm を設定しない場合、converse ルートは「LLM が設定されると、会話を続けられます。」と返信します。

LLM によるルーティングに追加設定は不要です。@ConversationConfig(llm=...) を指定して route_turn() を省略すると、ルーターが自動的に有効になり、@listen("ROUTE") ハンドラーとその docstring からルートのカタログを作成します。ルーターのプロンプトにルート一覧を重複して記載しないでください。プロンプト、説明、またはフォールバックを変更する場合にのみ、RouterConfig を渡します。

最小限のテスト済みサンプル(カスタムハンドラーと converse を使う route_turn() を try/finally 内で handle_turn() により実行)と、ライフサイクル、ルーティング、ストリーミング、永続化、トレースに関する詳細なガイダンスは、会話フローにあります。


7. inputs による変数の補間

{variable} パターンを使うと、Crew を再利用できます。

# Variables flow through: kickoff → YAML templates → agent/task prompts
crew.kickoff(inputs={
    "topic": "AI Agents",
    "current_year": "2025",
    "target_audience": "developers",
})

YAML では、{topic} と {current_year} が置換されます(エージェントの role/goal/backstory と、タスクの description/expected_output の両方が対象です)。

research_task:
  description: >
    Research {topic} trends for {current_year},
    targeting {target_audience}.

よくある間違い:

  • inputs を指定せずに kickoff() を呼び出す → リテラルの {variable} がプロンプトに渡されます
  • YAML で参照されている変数が不足した inputs を渡す → ValueError: Missing required template variable 'Template variable 'current_year' not found in inputs dictionary'
  • 単一の中括弧 { } ではなく、Jinja2 構文の {{ }} を使う → crewAI は単一の中括弧を使用するため、{{ topic }} はそのまま残ります
  • YAML のプレースホルダーに一致しない変数を渡す → 無視されます

8. プロジェクトの実行

# Install dependencies
crewai install

# Run the flow (or classic crew)
crewai run

または、プロジェクトディレクトリから直接実行します。

cd my_project
uv run kickoff                  # flow: the console script in pyproject.toml (run_crew for a classic crew)
uv run src/my_project/main.py   # also works with the scaffold's absolute imports

モデルとキーは環境変数または .env から取得されます。MODEL=anthropic/claude-haiku-4-5(または任意のプロバイダー文字列)と、そのプロバイダーのキーを設定し、uv add "crewai[anthropic]" でプロバイダーの追加パッケージをインストールします。MODEL と llm= のどちらも指定しない場合、エージェントは gpt-4.1-mini を使用し、OPENAI_API_KEY が必要です。

9. 簡易診断チェックリスト

症状考えられる原因解決方法
エージェントの出力に{topic}がそのまま表示されるkickoff()にinputs=が指定されていないcrew.kickoff(inputs={"topic": "..."})を渡します
ValueError: Missing required template variableinputsは指定されているものの、YAMLのプレースホルダーが1つ抜けているYAMLで使用されているすべての{variable}を渡します
self.agents_config['name']でKeyErrorが発生するメソッド名がYAMLのキーと一致していない@agent def researcherがYAMLのresearcher:と一致していることを確認します
ModuleNotFoundError/ImportError: attempted relative import相対インポート、またはフォルダーと一致しないパッケージパススキャフォールドの絶対パス形式from my_project.crews.crew_name.crew_name import CrewClassを使用します
ImportError: cannot import name 'persist'from crewai.flow.flow import persistfrom crewai.flow import persist
llm.callでTypeError: ... unexpected keyword argument 'response_format'が発生するLLM.call()のキーワードが間違っているllm.call(messages, response_model=Model)
Crewは実行されるが、Flowの状態が空結果をself.stateに書き戻していない@listenメソッドでCrewの出力をself.state.fieldに代入します
Process.SEQUENTIALでAttributeErrorが発生する列挙型が大文字になっている小文字のProcess.sequentialを使用します
エージェントがツールを無視するツールはエージェントに割り当てられているが、タスクで必要とされているツールをタスクレベルに移動するか、エージェントに適切なツールがあることを確認します
エージェントが検索結果を捏造するツールが割り当てられておらず、エージェントが実際に検索できないtools=[SerperDevTool()]または同等の設定を追加します。ツールのないエージェントはデータを幻覚します
@listenが一度も実行されないリスナー文字列がルーターの戻り値と一致しない、または@listen("method_name")に誤字がある@routerは、@listen("label")が期待する文字列と完全に一致する値を返す必要があります。メソッドチェーンでは@listen(method_ref)を推奨します
2つの先行処理が完了したのに、リスナーが一度しか実行されないor_は最初に完了した時点で一度だけ実行されますすべての先行処理の完了後に実行する必要がある場合は、and_()を使用します
crewai runでFlowにエラーがあったと表示されるが、出力は正しく見えるmain.pyのkickoff()が値を返したNoneを返します
crewai create crewでAborted!が表示される、またはウィザードの質問が出る--classicを付けていないため、JSONウィザードが起動しているcrewai create crew <name> --classic(またはcrewai create flow)を使用します
AuthenticationError、API key not found、またはOPENAI_API_KEY is requiredモデルプロバイダーの環境変数が設定されていない.envにプロバイダーキー(OPENAI_API_KEY、ANTHROPIC_API_KEYなど)と、検索ツール用のSERPER_API_KEYを設定します
Anthropic native provider not availableプロバイダーの追加パッケージがインストールされていないuv add "crewai[anthropic]"(または対応する追加パッケージ)を実行します
構造化出力でエージェントが延々と再試行するPydanticモデルがLLMにとって複雑すぎるモデルを簡素化するか、ネストを減らすか、より高性能なllmを使用します
エージェントが完了せずにmax_iterまでループするタスクの説明が曖昧、またはexpected_outputと矛盾しているexpected_outputを具体的で達成可能な内容にします。早く失敗させるにはmax_iterを下げます
@routerの戻り値が無視されるメソッドに@routerが付いていない分岐するメソッドには@listen(condition)ではなく@router(condition)を使用します
AttributeError: ... 'feedback_text'古いHumanFeedbackResultのフィールド名を使用しているresult.feedback
Flow.kickoff(user_message=..., session_id=...)が失敗する会話用のキーワード引数はkickoff()で受け付けられないチャットメッセージにはflow.handle_turn(message, session_id=...)を使用します
チャット履歴にアシスタントの返信がないハンドラーが文字列を返さず、返信も記録していない返信文字列を返すか、self.append_assistant_message(reply)を呼び出します

参考資料

特定のトピックについて詳しく知りたい場合は、以下を参照してください。

  • Crew YAML 設定 - agents.yaml、tasks.yaml、@CrewBase を使った crew.py の完全な例
  • Flow のルーティング、永続化、ストリーミング、ヒューマンフィードバック - @router、or_()、and_()、@persist、ストリーミング、@human_feedback のパターン
  • 会話型 Flow - handle_turn()、stream_turn()、chat()、ConversationConfig、ルーターの動作、永続化、トレーシングを使った複数ターンの Flow API
  • MCP サーバー — ネイティブツールより公式 MCP サーバーを優先してください。セットアップ、DSL 統合、公式サーバーの一覧
  • ツールカタログ - インポート、環境変数、よくある組み合わせを含む一般的な組み込みツール(MCP サーバーがない場合の代替手段として利用してください)

関連するスキルについては、以下を参照してください。

  • build-flow - Flow API 全般:状態のルール、ルーター、or_/and_、@persist、チェックポイント、@human_feedback、plot()
  • check-crewai-api - 現行の Agent/Task/Crew/LLM API と、記憶に頼った 0.x 形式との比較
  • connect-tools-and-mcp - カスタムツール、使用可能な crewai_tools の名前、mcps=[...] の形式とタイムアウト
  • design-agent — エージェントの Role-Goal-Backstory フレームワーク、パラメーターの調整、ツールの割り当て、メモリーとナレッジの設定
  • design-task — タスクの説明と expected_output のベストプラクティス、ガードレール、構造化出力、依存関係
  • test-crewai-project - スタブ LLM を使って Crew と Flow をオフラインで実行する
  • deploy-to-amp - CrewAI AMP のデプロイで必要となるプロジェクト構成とエントリーポイント
  • call-deployed-crew - HTTP 経由でデプロイ済みの Crew または Flow を呼び出す
  • ask-docs - これらのスキルで扱われていない質問について、CrewAI の最新ドキュメントを検索する

コメント