マルチエージェント構成：アーキテクチャとオーケストレーション

執筆：Ai Flowi · 公開日 2026-10-11

マルチエージェント構成では、異なる責任を持つエージェントに作業を分け、その連携を調整します。アーキテクチャは、誰が行動できるか、各エージェントが何を受け取るか、結果を次の段階にどう渡すかを定めます。エージェントのオーケストレーションは、停止や却下を含めた受け渡しの制御です。委任では、別のエージェントに範囲を限定したタスクを渡します。

まず、一つのエージェントでは明確に扱えない受け渡しを特定します。調査、原稿作成、検証の演習は、各段階の合格条件が異なるため有用です。エージェントが増えると、確認すべき受け渡しも増えます。意見が一致するだけで精度が高まるとは言えません。

マルチエージェントのアーキテクチャを選ぶ

これらはアーキテクチャの選択肢であり、検証済みの製品動作モードの一覧ではありません。以下のレポート作成案では、Sequential Crewを使い、調査から原稿作成への依存関係を確認します。ほかの構成パターンは、そもそもその依存関係にチームが必要かを判断するためのものです。カタログの記載だけでは、確実な復旧や連携の成功は確認できません。

エージェント設定前に必要なもの

架空の資料一式、調査の問い、最終レポートの想定構成を準備します。 モデルアクセス を、選択した提供元のアカウントとAPIキーで設定してください。提供元の利用料金は別途かかります。

以下の演習ではカタログのコンポーネントだけを使い、外部への書き込みは行いません。資料一式をタスクのテキストとして渡せるため、この最初の設計に検索サービスは不要です。後から追加するツールには、それぞれ認証情報、入力仕様、エラー時の挙動確認が必要です。プラットフォームの用語については、 エージェント、ワークフロー、チャットボットの比較 を参照してください。

手順1：受け渡しの仕様を定める

調査では、調査結果、出典識別子、裏付けとなる引用、未解決の質問を求めます。原稿作成段階は、承認された調査結果を受け取り、各主張に出典識別子を結び付けた文章を作成します。検証段階は、原稿と元の資料一式を受け取り、裏付けのない主張や欠落を具体的に示す判断を返します。

検証段階での出典へのアクセスには、 プロンプト連鎖のレビュールール を使用してください。

各担当に、識別名付きの資料一式を渡します。調査には問いと出典の資料群、原稿作成には承認された調査結果の識別子とレポート指示書、検証には候補レポートと対応する版の出典資料群を渡します。検証担当は承認または却下、対象となる調査結果の識別子、却下ごとの理由を返します。調査で必須の出典識別子が欠けた場合、その項目を不完全な事実として送らず、原稿作成への受け渡しを保留してください。

手順2：タスクごとに異なる責任を設定する

設定例であり、記録された検証結果ではありません

各Sequential Task Agentには、 allow_code_execution=false, allow_delegation=false, async_execution=false と memory=falseを提案します。これらの明示的な設定により、意図する演習の範囲を限定します。実行時に強制されるかは、別途確認が必要です。設定済みLanguage Modelの model_output を llmに接続します。受け入れられる型はLanguageModelです。

手順3：オーケストレーションの仕様を確認する

順次実行コンポーネントの入力一覧と、タスクオブジェクトの接続型については、 CrewAI連携リファレンス を参照してください。

このレポート演習では、Sequential Crewの memory=false, share_crew=false と use_cache=falseを設定します。架空の資料一式以外を渡す前に、これらの設定で実際に何が除外されるかを確認してください。試行前に、提供元に応じたリクエストの上限を選択します。これらの設定だけでは、既定の動作や、複数タスクの接続が動作することは確認できません。

各受け渡しを、受け取り側の責任に照らしてレビューします。原稿作成側は承認された調査結果を識別できるか、検証側は調査に使われたものと同じ版の出典にアクセスできるかを確認してください。これらの区別なしにテキストだけを渡す接続では、提案したアーキテクチャの要件を満たせません。次に進む前に資料一式の内容を確認し、却下した調査結果は理由とともに、原稿に使う承認済み根拠の集合とは別に保持します。

手順4：停止と委任の範囲を定める

必須の出典根拠がない場合、検証担当が原稿を却下した場合、提供元で障害が発生した場合は停止します。より自信のある回答を得ようと別のエージェントに繰り返し依頼するのではなく、未解決の問いを人に戻してください。実行前に再試行の上限を定めます。モデルを繰り返し試しても、同じ誤った前提を再使用することがあります。

Flow as Toolについては、 関数呼び出しツールの仕様 で説明しています。委任には、さらに、明示した受け取り先と、範囲を限定した返却資料が必要です。

例えば、レポート全体ではなく、解約条項についての問いだけを委任します。専門エージェントは、その問い、使用が許可された出典識別子、指定した調査結果の形式を受け取ります。別の担当に作業を割り当てず、引用で裏付けた調査結果か、未解決の項目を返します。調整役は、次の資料一式を渡す前に、返却内容が元のタスクを満たすかを判断しなければなりません。

調査が資料群の版Aから調査結果F1を返したのに、原稿作成担当が版Bの条項を使用したとします。検証担当は、版が混在した資料一式を却下し、不一致を示す必要があります。候補レポートを最終納品の経路に入れず、レビュー済みの一つの資料群から、影響を受けた受け渡しを作り直します。プロンプトに却下の指示を書くだけでは、停止は強制されません。却下された資料一式で後続作業が始まらないことを確認してください。カタログでは、Sequential Crewにそのような条件付き実行ゲートがあることは確認できないため、この最初の演習は、各受け渡しの手動確認で終了します。

手順5：範囲を限定した一つのエージェントと比較する

一つのAgentに、同じ問い、資料一式、読み取り専用ツール、最終レポートの要件を渡します。 input_value をタスクに、 system_prompt を根拠ルールに使用し、有限の max_iterations を検証前に選択します。全フィールドの一覧は、 Agentリファレンス で確認してください。

両方の設計について、裏付けのある主張、根拠の不足、却下された事例、提供元の障害、実測したノード使用量を確認します。認証情報と出典へのアクセス条件をそろえてください。ツールが使えるチームと、同じ出典へのアクセスが認められない単一エージェントを比較してはいけません。費用や有用性を判断する前に、実際の呼び出しと失敗した試行を記録します。

マルチエージェントシステムに期待する出力と制約は何ですか？

想定する出力は、出典に結び付いた調査結果と、調査結果とは分けて記録した検証担当の判断を含み、不明点を明示したレポートです。この提案構成によるレポートは記録されていません。順次実行のコンポーネントはカタログに記載されていますが、Ai Flowiによる本番環境での検証は行われていません。型付きポートが示すのはインターフェースの互換性であり、実行の成功や独立した判断力ではありません。

固定ルールで問いに答えられる場合、一回のモデル呼び出しと人のレビューで十分な場合、外部操作に必要な承認の境界が提案グラフにない場合は、この設計を避けてください。範囲を限定した行動判断については、 自律型AIエージェントを参照してください。 ユースケースのハブ には、各構成について根拠の対象範囲を示した、既存の基本パターンがあります。

ワークフローの使用量

プラン：Goは年払いで月額USD8から（月払いUSD10）、Plusは月額USD16から（月払いUSD20）、Pro 100は月額USD80から（月払いUSD100）、Pro 200は月額USD160から（月払いUSD200）、Pro 500は月額USD400から（月払いUSD500）。毎月5,000～250,000 Flowi Tokensが含まれ、追加購入も可能です。ノード実行1回につき1トークン。サードパーティのAPIとモデルの利用料金は含まれません。