getting-started について
CrewAI の抽象レベルの選択、コマンドラインによるプロジェクト生成、Agent・Crew・Flow の構成を案内するスキルです。生成済みプロジェクトから本番ワークフローや会話型 Flow を構築する開発者向けです。
主な機能
- 01抽象レベルの選択ガイド
- 02CLIを使ったプロジェクト生成
- 03Agent・Crew・Flowの構成パターン
- 04YAML設定の案内
- 05本番ワークフローのオーケストレーション
活用シーン
- 01適切なCrewAI構成要素の選択
- 02CLIスキャフォールドからの開発開始
- 03複数ステップの本番ワークフロー構成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ crewaiinc/ skills --skill getting-startedインストール後、Claude Code で/getting-startedを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/conversational-flows.mdcrew-yaml-config.mdflow-routing.mdmcp-servers.mdtools-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 の設定、そして手動で作成するとわずかな間違いが生じやすい定型コードを設定します。以下のリファレンスでは各要素の仕組みを説明します。目的は、ひな形から作成したコードを変更できるようにすることであり、ひな形作成の手順を置き換えることではありません。
ワークフロー:
crewai create flow <name>を実行します(アンダースコアを推奨します。CLI はフォルダー名とパッケージ名のために、ハイフンとスペースをアンダースコアに変換します)- 生成された YAML ファイルと Python ファイルをユースケースに合わせて編集します
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 variable | inputsは指定されているものの、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 persist | from 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 の最新ドキュメントを検索する