アーキテクトや開発者が言語モデル機能を最大限に活用するようにワークロードを設計するにつれて、AI エージェント システムはますます複雑になります。 多くの場合、これらのシステムは、多くのツールとナレッジ ソースにアクセスできる単一のエージェントの能力を超えています。 代わりに、これらのシステムはマルチエージェント オーケストレーションを使用して、複雑な共同作業タスクを確実に処理します。 このガイドでは、マルチエージェント アーキテクチャの基本的なオーケストレーション パターンについて説明し、特定の要件に合ったアプローチを選択するのに役立ちます。
概要
複数の AI エージェントを使用すると、複雑な問題を特殊な作業単位または知識単位に分割できます。 各タスクは、特定の機能を持つ専用の AI エージェントに割り当てます。 これらのアプローチは、人間のチームワークで見つかった戦略を反映しています。 複数のエージェントを使用すると、モノリシック シングル エージェント ソリューションと比較して、いくつかの利点があります。
専修： 個々のエージェントは、特定のドメインまたは機能に集中できるため、コードとプロンプトの複雑さが軽減されます。
スケーラビリティ: エージェントは、システム全体を再設計せずに追加または変更できます。
保守性： テストとデバッグは個々のエージェントに重点を置くことができるため、これらのタスクの複雑さが軽減されます。
最適化： 各エージェントは、個別のモデル、タスク解決アプローチ、知識、ツール、コンピューティングを使用して、その結果を達成できます。
このガイドのパターンは、複数のエージェントを連携させ、結果を達成するための実証済みのアプローチを示しています。 各パターンは、さまざまな種類の調整要件に合わせて最適化されています。 これらの AI エージェント オーケストレーション パターンは、AI 駆動型ワークロード機能で自律的なコンポーネントを調整するという固有の課題に対処することで、従来の クラウド設計パターン を補完および拡張します。
シーケンシャル オーケストレーション
シーケンシャル オーケストレーション パターンは、定義済みの線形順序で AI エージェントをチェーンします。 各エージェントは、前のエージェントからの出力をシーケンスで処理し、特殊化された変換のパイプラインを作成します。
順次オーケストレーション パターンは、各ステージが前のステージに基づいて構築される、ステップ バイ ステップ処理を必要とする問題を解決します。 これは、明確な依存関係を持ち、段階的な改良によって出力品質を向上させるワークフローに適しています。 このパターンは 、パイプとフィルター のクラウド設計パターンに似ていますが、カスタムコード化された処理コンポーネントではなく AI エージェントを使用します。 次に呼び出されるエージェントの選択は、ワークフローの一部として決定論的に定義され、プロセス内のエージェントに与えられる選択ではありません。
シーケンシャル オーケストレーションを使用するタイミング
次のシナリオでは、順次オーケストレーション パターンを検討してください。
明確な線形依存関係と予測可能なワークフローの進行を持つマルチステージ プロセス
データ変換パイプライン。各ステージは、次のステージが依存する特定の値を追加します
並列化できないワークフロー ステージ
ドラフト、レビュー、完成ワークフローなどの段階的な改善要件
すべての AI エージェントの可用性とパフォーマンスの特性を理解し、1 つの AI エージェントの処理が失敗したり遅延したりしても、タスク全体が完了できるパイプライン上のシステム。
シーケンシャル オーケストレーションを回避するタイミング
次のシナリオでは、このパターンを避けてください。
ステージは 恥ずかしいほど並列です。 品質を損なったり、共有状態の競合を作成したりすることなく、それらを並列化できます。
少数のステージだけを含むプロセスで、1つのAIエージェントが効果的に実行できるものです。
初期段階では、エラーが発生したり、低品質の出力が生成されたりする可能性があり、累積エラー出力を使用して後の手順が処理されないようにする適切な方法はありません。
AI エージェントは、作業を引き継ぐのではなく、共同作業を行う必要があります。
ワークフローにはバックトラッキングまたはイテレーションが必要です。
中間結果に基づく動的ルーティングが必要です。
順次オーケストレーションの例
法律事務所のドキュメント管理ソフトウェアは、契約生成に順次エージェントを使用します。 インテリジェント アプリケーションは、4 つの特殊なエージェントのパイプラインを介して要求を処理します。 順次パイプラインステップと定義済みパイプラインステップにより、各エージェントが前のステージからの完全な出力で動作します。
テンプレート選択エージェントは、契約の種類、管轄区域、関係者などのクライアント仕様を受け取り、会社のライブラリから適切な基本テンプレートを選択します。
句のカスタマイズ エージェントは、選択したテンプレートを受け取り、支払いスケジュールや責任の制限など、交渉されたビジネス条件に基づいて標準句を変更します。
規制コンプライアンス エージェントは、適用される法律および業界固有の規制に対してカスタマイズされた契約をレビューします。
リスク評価エージェントは、完全な契約の包括的な分析を実行します。 責任の発生可能性と紛争解決メカニズムを評価し、リスク評価と保護措置に関する言語の推奨事項を提供します。
コンカレント オーケストレーション
同時実行オーケストレーション パターンは、同じタスクで複数の AI エージェントを同時に実行します。 このアプローチにより、各エージェントは、独自の観点または特殊化から独立した分析または処理を提供できます。
このパターンは、同じ問題に対して多様な分析情報やアプローチが必要なシナリオに対処します。 順次処理の代わりに、すべてのエージェントが並列に動作するため、全体的な実行時間が短縮され、問題領域が包括的にカバーされます。 このオーケストレーション パターンは、ファンアウト/ファンイン クラウド設計パターンに似ています。 各エージェントの結果は、多くの場合、最終的な結果を返すために集計されますが、必須ではありません。 各エージェントは、タスクを実行するためのツールの呼び出しや、異なるデータ ストアの並列更新など、ワークロード内で独自の結果を個別に生成できます。
エージェントは独立して動作し、結果を互いに引き渡しません。 エージェントは、独立した処理の一部として独自のオーケストレーション アプローチを使用して、追加の AI エージェントを呼び出す場合があります。 使用可能なエージェントは、処理に使用できるエージェントを認識している必要があります。 このパターンでは、登録されているすべてのエージェントに対する確定的な呼び出しと、タスクの要件に基づいて呼び出すエージェントの動的な選択の両方がサポートされます。
同時実行オーケストレーションを使用する場合
次のシナリオでは、同時オーケストレーション パターンを検討してください。
固定のエージェント セットを使用するか、特定のタスク要件に基づいて AI エージェントを動的に選択することで、並列で実行できるタスク。
複数の独立した視点や、技術、ビジネス、創造的なアプローチなど、同じ問題に貢献できるさまざまな特殊化の恩恵を受けるタスク。 このコラボレーションは、通常、次のマルチエージェントの意思決定手法を備えるシナリオで発生します。
ブレーンストーミング
アンサンブル推論
クォーラムと投票に基づく決定
並列処理によって待機時間が短縮される、時間に依存するシナリオ。
同時オーケストレーションを回避する状況
次のシナリオでは、このオーケストレーション パターンは避けてください。
エージェントは、互いの作業に基づいて構築するか、特定のシーケンスで蓄積されたコンテキストを必要とします。
タスクには、定義されたシーケンスで実行された特定の順序の操作または確定的で再現可能な結果が必要です。
モデル クォータなどのリソース制約によって、並列処理が非効率的または不可能になります。
エージェントは、同時に実行されている間、共有状態または外部システムへの変更を確実に調整することはできません。
各エージェントからの矛盾または競合する結果を処理するための明確な競合解決戦略はありません。
結果集計ロジックが複雑すぎるか、結果の品質が低下します。
コンカレント オーケストレーションの例
ある金融サービス会社は、さまざまな種類の分析に特化した同時実行エージェントを使用して同じ在庫を同時に評価するインテリジェントなアプリケーションを構築しました。 各エージェントは、その特殊な観点から分析情報を提供し、迅速な投資決定のために、時間に依存する多様な入力を提供します。
システムは、並列で実行される 4 つの特殊なエージェントに同じティッカー シンボルをディスパッチすることによって、在庫分析要求を処理します。
基礎分析エージェントは、財務諸表、収益動向、および競争力のある位置付けを評価して、本質的価値を評価します。
テクニカル分析エージェントは、価格パターン、ボリューム指標、およびモメンタムシグナルを調べて取引機会を特定します。
センチメント分析エージェントは、ニュース記事、ソーシャル メディアのメンション、アナリスト レポートを処理して、市場のセンチメントと投資家の信頼度を測定します。
環境、社会、ガバナンス(ESG)の担当者は、環境への影響、社会的責任、ガバナンスの実践レポートを見直し、持続可能性のリスクと機会を評価します。
その後、これらの独立した結果が包括的な投資レコメンデーションに組み合わされ、ポートフォリオ・マネージャーは情報に基づいた意思決定を迅速に行うことができます。
グループ チャット 調整
グループ チャット オーケストレーション パターンを使用すると、複数のエージェントが、ディスカッションを通じて共同作業を行う共有会話スレッドに参加することで、問題の解決、決定、作業の検証を行うことができます。 チャット マネージャーは、次に応答できるエージェントを決定し、コラボレーションブレーンストーミングから構造化された品質ゲートまで、さまざまな対話モードを管理することでフローを調整します。
このパターンは、グループディスカッションを通じて決定に到達するために最適に達成されるシナリオに対処します。 これらのシナリオには、協調的な考え方、構造化された検証、または品質管理プロセスが含まれる場合があります。 このパターンは、自由に流れるブレーンストーミングから、固定のロールと承認ゲートを持つ正式なレビュー ワークフローまで、さまざまな対話モードをサポートしています。
このパターンは、人間が必要に応じて動的チャット マネージャーの責任を引き受け、生産性の高い結果に向けて会話を導くことができる、人間のループ内シナリオに適しています。 このオーケストレーション パターンでは、通常、エージェントは 読み取り専用 モードです。 実行中のシステムでツールを使用して変更を加えることはありません。
グループ チャット オーケストレーションを使用するタイミング
自発的またはガイド付きコラボレーションまたは反復的な作成者チェッカー ループを使用してシナリオを解決できる場合は、グループ チャットオーケストレーションを検討してください。 これらのアプローチはすべて、リアルタイムの人間の監視または参加をサポートします。 ループ内のすべてのエージェントと人間が出力を 1 つの累積スレッドに出力するため、このパターンは透明性と監査性を提供します。
共同作業のシナリオ
異なる視点と知識ソースを持つエージェントがチャットに対する互いの貢献に基づいて構築する創造的なブレーンストーミング セッション
議論とコンセンサス構築の恩恵を受ける意思決定プロセス
ディスカッションによる反復的な絞り込みを必要とする意思決定シナリオ
機能間の対話を必要とする学際的な問題
検証と品質管理のシナリオ
構造化されたレビュー プロセスとイテレーションを含む品質保証要件
複数の専門家の視点を必要とするコンプライアンスと規制の検証
作成と検証の間の懸念事項を明確に分離して編集レビューを必要とするコンテンツ作成ワークフロー
グループ チャット オーケストレーションを回避するタイミング
次のシナリオでは、このパターンを避けてください。
単純なタスク委任または線形パイプライン処理で十分です。
リアルタイム処理の要件によって、ディスカッションオーバーヘッドは許容できません。
議論なしで明確な階層的意思決定または決定論的ワークフローがより適切です。
チャット マネージャーには、タスクが完了したかどうかを判断する客観的な方法はありません。
会話フローを管理し、無限ループを防ぐには注意が必要です。特に、エージェントの数が多いほど管理が困難になります。 効果的な制御を維持するには、グループ チャット オーケストレーションを 3 つ以下のエージェントに制限することを検討してください。
確認者付き製作者ループ
maker-checker ループは、1 つのエージェントである 作成者が何かを作成または提案する、特定の種類のグループ チャット オーケストレーションです。 別のエージェントである チェッカーは、結果の批判を提供します。 このパターンは反復的で、チェッカー エージェントが会話をメーカーエージェントに送り返して更新を行い、プロセスを繰り返します。 グループ チャット パターンではエージェントが順番にチャットを 行 う必要はありませんが、メーカー チェッカー ループには、チャット マネージャーが操作する正式なターンベースのシーケンスが必要です。
グループ チャット オーケストレーションの例
市の公園とレクリエーション部門は、グループ チャット オーケストレーションを含むソフトウェアを使用して、新しい公園開発の提案を評価します。 このソフトウェアは提案案を読み上げ、複数の専門家が異なるコミュニティへの影響の観点について議論し、提案に関する合意に向けて取り組みます。 このプロセスは、提案がコミュニティ レビューのために開かれる前に発生し、受け取る可能性のあるフィードバックを予測するのに役立ちます。
このシステムは、複数の市民の観点から、タスクに従事する専門の自治体エージェントとのグループ協議を開始することによって、公園開発の提案を処理します。
コミュニティ エンゲージメント エージェントは、アクセシビリティ要件、予想される常駐フィードバック、および使用パターンを評価して、公平なコミュニティ アクセスを確保します。
環境計画担当者は、生態学的影響、持続可能性対策、ネイティブ植生の変位、環境規制への準拠を評価します。
予算および運用エージェントは、建設コスト、継続的なメンテナンス費用、スタッフの要件、および長期的な運用の持続可能性を分析します。
チャット マネージャーは、エージェントが互いの推奨事項に挑戦し、その推論を守る構造化された議論を容易にします。 公園部門の従業員がチャット スレッドに参加し、分析情報を追加し、エージェントの知識要求にリアルタイムで応答します。 このプロセスにより、従業員は元の提案を更新して、特定された懸念事項に対処し、コミュニティのフィードバックに対するより適切な準備を行うことができます。
引き継ぎオーケストレーション
ハンドオフ オーケストレーション パターンを使用すると、特殊なエージェント間でタスクを動的に委任できます。 各エージェントは、手元のタスクを評価し、コンテキストと要件に基づいてタスクを直接処理するか、より適切なエージェントに転送するかを決定できます。
このパターンは、タスクに最適なエージェントが事前にわかっていない、またはタスクの要件が処理中にのみ明確になるシナリオに対処します。 インテリジェントなルーティングが可能になり、タスクが最も能力の高いエージェントに確実に到達します。 通常、このパターンのエージェントは並列で動作しません。 1 つのエージェントから別のエージェントへのフル コントロール転送。
ハンドオフオーケストレーションを行うタイミング
次のシナリオでは、エージェントのハンドオフ パターンを検討してください。
専門的な知識またはツールを必要とするが、必要なエージェントの数またはその順序を事前に決定できないタスク
処理中に専門知識の要件が生じ、コンテンツ分析に基づく動的なタスク ルーティングが発生するシナリオ
複数のドメインにまたがる問題で、異なる専門家が順番に働くことが必要です。
1 つのエージェントが機能制限に達し、次にタスクを処理する必要があるエージェントを示すために事前に定義できる論理リレーションシップとシグナル
ハンドオフ オーケストレーションを避けるべきタイミング
次のシナリオでは、このパターンを避けてください。
適切なエージェントとその順序は、常に事前に知られています。
タスク ルーティングは、動的コンテキスト ウィンドウや動的解釈に基づくのではなく、単純で決定的なルールベースです。
最適でないルーティングの決定は、ユーザー エクスペリエンスの低下や不満につながる可能性があります。
タスクに対処するには、複数の操作を同時に実行する必要があります。
無限ハンドオフループを回避したり、エージェント間の過度のバウンスを避けるのは困難です。
エージェントハンドオフパターンの例
通信顧客関係管理 (CRM) ソリューションは、カスタマー サポート Web ポータルでハンドオフ エージェントを使用します。 最初のエージェントは、顧客を支援し始めますが、会話中に専門的な専門知識が必要であることを発見します。 最初のエージェントは、顧客の懸念に対処するために、最も適切なエージェントにタスクを渡します。 元の入力に対して動作するエージェントは一度に 1 つだけで、ハンドオフ チェーンは 1 つの結果になります。
このシステムでは、 トリアージ サポート エージェント が要求を解釈し、一般的な問題を直接処理しようとします。 制限に達すると、ネットワークの問題を 技術インフラストラクチャ エージェントに、課金の紛争を 財務解決エージェントに引き渡します。 現在のエージェントが独自の機能制限を認識し、別のエージェントがシナリオをより適切にサポートできることを認識している場合、それらのエージェント内でさらに引き渡しが行われます。
各エージェントは、顧客の満足が達成されたと判断した場合、または他のエージェントが顧客にこれ以上利益をもたらすことができないと判断した場合に、会話を完了できます。 また、一部のエージェントは、問題を解決することが重要であるが、現在、それに対処する機能を持つ AI エージェントがない場合に、ユーザー エクスペリエンスを人間のサポート エージェントに渡すために設計されています。
ハンドオフ インスタンスの例の 1 つが図で強調表示されています。 最初に、タスクを技術インフラストラクチャ エージェントに引き離すトリアージ エージェントから始まります。 その後、技術インフラストラクチャ エージェントは、タスクを財務解決エージェントに渡し、最終的にタスクをカスタマー サポートにリダイレクトすることを決定します。
マゼンティック オーケストレーション
マゼンティック オーケストレーション パターンは、事前に定義されたアプローチ計画を持たないオープンエンドで複雑な問題に対応するように設計されています。 通常、このパターンのエージェントには、外部システムで直接変更できるツールがあります。 このアプローチを実装する場合と同じように、問題を解決するためのアプローチを構築して文書化することに重点を置きます。 タスク リストは、特殊なエージェントとマゼンティック マネージャー エージェントの間のコラボレーションを通じて、ワークフローの一部として動的に構築および調整されます。 コンテキストの進化に伴い、マゼンティク マネージャー エージェントはタスク台帳を構築し、目標とサブゴールを使用してアプローチ計画を策定し、最終的に最終決定し、それに従い、目的の結果を完了するように追跡します。
マネージャー エージェントは、特殊なエージェントと直接通信して、タスク台帳の構築と調整に合わせて情報を収集します。 必要な回数で反復処理、バックトラック、デリゲートを行い、成功裏に実行可能な計画を構築します。マネージャーエージェントは、元の要求が完全に満たされているか、あるいは進捗が止まっているかを頻繁に評価します。 計画を調整するために台帳が更新されます。
いくつかの点で、このオーケストレーション パターンは グループ チャット パターンの拡張です。 マゼンティック オーケストレーション パターンは、アプローチの計画を構築するエージェントに焦点を当てていますが、他のエージェントは、ナレッジ ストアのみを使用して結果に到達するのではなく、ツールを使用して外部システムに変更を加えます。
マゼンティック オーケストレーションを使用する場合
次のシナリオでは、マゼンティック パターンを検討してください。
事前に定義されたソリューション パスがない複雑なユース ケースまたはオープン エンドのユース ケース。
有効なソリューション パスを開発するために、複数の特殊なエージェントからの入力とフィードバックを検討する必要があります。
AI システムが、人間が実装の前後にレビューできる完全に開発されたアプローチ計画を生成するための要件。
外部システムと対話したり、外部リソースを消費したり、実行中のシステムの変更を誘発したりするツールを備えたエージェント。 エージェントがタスクに従うことを許可する前に、それらのエージェントがどのようにシーケンスされるかを示す文書化されたプランをユーザーに提示できます。
マゼンティック オーケストレーションを回避するタイミング
次のシナリオでは、このパターンを避けてください。
ソリューション パスが開発されているか、決定論的な方法でアプローチする必要があります。
台帳を作成する必要はありません。
タスクの複雑さが低く、より単純なパターンで解決できます。
このパターンでは、最終的な結果に合わせて最適化されるのではなく、実行可能な計画の構築と議論に重点を置いているため、作業は時間の影響を受けます。
解決への明確なパスがない頻繁なストールまたは無限ループが予想されます。
磁気オーケストレーションの例
サイト信頼性エンジニアリング (SRE) チームは、マゼンティック オーケストレーションを使用してリスクの低いインシデント対応シナリオを処理する自動化を構築しました。 自動化の範囲内でサービスの停止が発生した場合、システムは修復計画を動的に作成して実装する必要があります。 これは、事前に必要な特定の手順を知らなくても行われます。
自動化によって適格なインシデントが検出されると、 マゼンティク マネージャー エージェント は、サービスの可用性の復元や根本原因の特定などの大まかな目標を持つ最初のタスク台帳を作成することから始めます。 その後、マネージャー エージェントは、特殊なエージェントと相談して情報を収集し、修復計画を調整します。
診断エージェントは、システム ログ、パフォーマンス メトリック、およびエラー パターンを分析して、考えられる原因を特定します。 結果がマネージャー エージェントに報告されます。
診断結果に基づいて、マネージャー エージェントは特定の調査手順でタスク台帳を更新し、 インフラストラクチャ エージェント に問い合わせて、現在のシステム状態と使用可能な回復オプションを理解します。
通信エージェントは利害関係者通知機能を提供し、マネージャー エージェントは、SRE チームのエスカレーション手順に従って、進化する計画に通信チェックポイントと承認ゲートを組み込みます。
シナリオが明確になると、デプロイの復帰が必要な場合は、マネージャー エージェントがロールバック エージェント を計画に追加したり、インシデントが自動化のスコープを超えた場合に人間の SRE エンジニアにエスカレートしたりする可能性があります。
このプロセスを通じて、マネージャー エージェントは、新しい情報に基づいてタスク台帳を継続的に調整します。 インシデントの進化に伴ってタスクを追加、削除、または並べ替えます。 たとえば、診断エージェントがデータベース接続の問題を検出した場合、マネージャー エージェントは、展開ロールバック戦略から、データベース接続の復元に重点を置くプランにプラン全体を切り替える可能性があります。
マネージャー エージェントは、サービス復旧時の過剰な停止を監視し、無限修復ループに陥らないように保護します。 これは、進化する計画と実装手順の完全な監査証跡を維持し、インシデント後のレビューの透明性を提供します。 この透明性により、SRE チームは学習した教訓に基づいてワークロードと自動化の両方を向上させることができます。
実装に関する考慮事項
これらのエージェント設計パターンのいずれかを実装する場合は、いくつかの考慮事項に対処する必要があります。 これらの考慮事項を確認すると、一般的な落とし穴を回避し、エージェントのオーケストレーションが堅牢で、セキュリティで保護され、保守可能であることを確認できます。
単一エージェント、マルチツール
ツールとナレッジ ソースに十分なアクセス権を付与すると、1 つのエージェントで問題に対処できます。 ナレッジ ソースとツールの数が増えるにつれて、予測可能なエージェント エクスペリエンスを提供することが困難になります。 1 つのエージェントでシナリオを確実に解決できる場合は、そのアプローチを採用することを検討してください。 多くの場合、意思決定とフロー制御のオーバーヘッドは、タスクを複数のエージェントに分割する利点を超えています。 ただし、セキュリティ境界、ネットワークの見通し線、その他の要因によって、単一エージェントのアプローチは実現できない可能性があります。
決定論的ルーティング
一部のパターンでは、エージェント間のフローを決定論的にルーティングする必要があります。 他のユーザーは、エージェントに依存して独自のルートを選択します。 エージェントがコードなし環境またはローコード環境で定義されている場合、それらの動作を制御できない可能性があります。 セマンティック カーネルなどの SDK を使用してコードでエージェントを定義する場合は、より詳細な制御が可能です。
コンテキスト ウィンドウ
多くの場合、AI エージェントにはコンテキスト ウィンドウが限られています。 この制約は、複雑なタスクを処理する能力に影響する可能性があります。 これらのパターンを実装するときは、次のエージェントが有効にするために必要なコンテキストを決定します。 一部のシナリオでは、これまでに収集された完全な生のコンテキストが必要です。 その他のシナリオでは、要約されたバージョンまたは切り捨てられたバージョンの方が適しています。 エージェントが蓄積されたコンテキストなしで動作でき、新しい命令セットのみが必要な場合は、エージェントのタスクを実行するのに役立たないコンテキストを提供するのではなく、そのアプローチを採用してください。
信頼性
これらのパターンには、適切に機能するエージェントとそれらの間の信頼性の高い遷移が必要です。 多くの場合、ノード障害、ネットワーク パーティション、メッセージ損失、カスケード エラーなどの従来の分散システムの問題が発生します。 これらの課題に対処するには、軽減策を実施する必要があります。 エージェントとそのオーケストレーターは、次の手順を実行する必要があります。
タイムアウトと再試行のメカニズムを実装します。
パターン障害の中で 1 つ以上のエージェントを処理するグレースフル デグラデーションの実装を含めます。
サーフェス エラーは非表示にするのではなく、ダウンストリーム エージェントとオーケストレーター ロジックが適切に応答できるようにします。
エージェントの依存関係に対するサーキットブレーカーパターンを検討してください。
エージェントは、できるだけ互いに隔離され、エージェント間で単一障害点を共有しないように設計します。 例えば次が挙げられます。
エージェント間のコンピューティングの分離を確保します。
1 つのサービスとしてのモデル (MaaS) モデルまたは共有ナレッジ ストアを使用すると、エージェントが同時に実行されたときにレート制限が発生する可能性がある方法を評価します。
SDK で使用できるチェックポイント機能を使用して、障害や新しいコードのデプロイなど、中断されたオーケストレーションからの復旧に役立ちます。
セキュリティ
これらの設計パターンに適切なセキュリティ メカニズムを実装することで、AI システムが攻撃やデータ漏えいにさらされるリスクを最小限に抑えることができます。 エージェント間の通信をセキュリティで保護し、各エージェントの機密データへのアクセスを制限することは、重要なセキュリティ設計戦略です。 次のセキュリティ対策を検討してください。
認証を実装し、エージェント間でセキュリティで保護されたネットワークを使用します。
エージェント通信のデータ プライバシーへの影響を考慮してください。
コンプライアンス要件を満たすように監査証跡を設計します。
最小限の特権の原則に従ってエージェントとそのオーケストレーターを設計します。
エージェント間でユーザーの ID を処理する方法を検討します。 エージェントは、すべてのユーザーからの要求を処理するためにナレッジ ストアに広範なアクセス権を持っている必要がありますが、ユーザーにアクセスできないデータを返してはなりません。 セキュリティ トリミングは、パターン内のすべてのエージェントに実装する必要があります。
可観測性とテスト
AI システムを複数のエージェントに分散させるには、適切な機能を確保するために、各エージェントを個別に監視し、システム全体をテストする必要があります。 監視とテストの戦略を設計するときは、次の推奨事項を考慮してください。
すべてのエージェント操作と引き継ぎを監視します。 分散システムのトラブルシューティングはコンピューター サイエンスの課題であり、調整された AI エージェントも例外ではありません。
ベースラインを確立し、ボトルネックを見つけ、最適化できるように、各エージェントのパフォーマンスとリソース使用状況のメトリックを追跡します。
個々のエージェントのテスト可能なインターフェイスを設計します。
マルチエージェント ワークフローの統合テストを実装します。
一般的な落とし穴とアンチパターン
エージェント オーケストレーション パターンを実装するときは、次の一般的な間違いを避けてください。
シーケンシャルまたはコンカレントオーケストレーションで十分な場合に、複雑なパターンを使用することで不要な調整の複雑さを生み出してしまうこと。
意味のある特殊化を提供しないエージェントを追加する。
複数ホップ通信の待機時間の影響を見落とします。
同時実行エージェント間で変更可能な状態を共有すると、エージェントの境界を越えた同期更新が想定されるため、トランザクションに一貫性のないデータが発生する可能性があります。
本質的に非決定的なワークフローに決定論的パターンを使用する。
本質的に確定的なワークフローに対して非決定的パターンを使用する。
同時実行オーケストレーションを選択した場合のリソース制約の無視。
エージェントがより多くの情報を蓄積し、そのモデルを参照してタスクを進めるにつれてコンテキスト ウィンドウが拡大するため、過剰なモデル リソースを消費します。
オーケストレーション パターンの組み合わせ
アプリケーションでは、要件に対応するために複数のオーケストレーション パターンを組み合わせる必要がある場合があります。 たとえば、初期データ処理ステージにシーケンシャル オーケストレーションを使用し、並列化可能な分析タスクの同時実行オーケストレーションに切り替えることができます。 ワークロードのさまざまなステージに異なる特性があり、異なるパターンを使用して各ステージからメリットを得ることができる場合は、1 つのワークフローを 1 つのパターンに適合させないでください。
クラウド設計パターンとの関係
AI エージェント オーケストレーション パターンは、インテリジェントで自律的なコンポーネントを調整する固有の課題に対処することで、従来の クラウド設計パターン を拡張し、補完します。 クラウド設計パターンは、分散システムにおける構造的および行動上の懸念に焦点を当てていますが、AI エージェント オーケストレーション パターンは、推論機能、学習動作、非決定的出力を使用したコンポーネントの調整に特に対処します。
Microsoft セマンティック カーネルでの実装
これらのパターンの多くは、オーケストレーション ロジックに対処するためにコードベースの実装に依存しています。 セマンティック カーネル内のエージェント フレームワークでは、次の エージェント オーケストレーション パターンの多くがサポートされています。
実践的な実装については、実際にこれらのパターンを示す、GitHub の セマンティック カーネル マルチエージェント オーケストレーション サンプル を参照してください。 また、Magentic-One など、AutoGen でこれらのパターンの多くを見つけることもできます。
Azure AI Foundry Agent Service の実装
また、Azure AI Foundry Agent Service を使用して、接続されたエージェント機能を使用して、比較的単純なワークフローでエージェントを連結することもできます。 このサービスを使用して実装するワークフローは、主に非決定的であり、このコードなしの環境でどのパターンを完全に実装できるかが制限されます。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要な著者:
- チャド・キットテル |プリンシパル ソフトウェア エンジニア - Azure パターンとプラクティス
- クレイトン・ジーメンス |プリンシパル コンテンツ開発者 - Azure パターンとプラクティス
その他の共同作成者:
- ヘマヴァシー・アラガナンダム |プリンシパル ソフトウェア エンジニア
- James Lee |データ サイエンティスト 2
- Ritesh Modi | プリンシパル ソフトウェア エンジニア
- Mahdi Setayesh | プリンシパル ソフトウェア エンジニア
- Mark Taylor | プリンシパル ソフトウェア エンジニア
- ヤニヴ・ヴァクニン |シニア テクニカル スペシャリスト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。