単一エージェントまたは複数のエージェント

この記事では、組織全体で単一エージェント システムとマルチエージェント システムのどちらを構築するかを決定するのに役立つ基準について説明します。 組織は、AI エージェント導入の ビルド エージェント フェーズ中にこの決定に直面します (図 1 を参照)。

図 1.Microsoft の AI エージェント導入プロセス。

ワークロード チームは設計上の意思決定を柔軟に行う必要がある一方で、組織は標準的な一連の期待を持つことでメリットを得ることができます。 これらの期待は、作成されるエージェントの数と、時間の経過と同時に管理および保守する必要がある内容をガイドするのに役立ちます。 わかりやすくするために、主な定義を次に示します。

• 単一エージェント システムでは、 すべてのロジックが 1 つのエージェントに統合されます。 このアプローチにより、実装が簡略化され、運用オーバーヘッドが削減され、予測可能な実行モデルが提供されます。
• マルチエージェント システムは 、複数の特殊なエージェント間で責任を分割します。 これにより、モジュール性、懸念事項の明確な分離、スケーラビリティの向上が可能になりますが、追加の調整とオーケストレーションが必要になります。

AI エージェントのデシジョン ツリー

AI エージェントのデシジョン ツリー (図 2 を参照) を使用すると、マルチエージェント システムから開始するか、単一エージェント テストを実行するか、既定で単一エージェント設計にするかを判断できます。 以下のセクションでは、すべての条件について詳しく説明します。

図 2. Microsoft の AI エージェントデシジョン ツリー。

マルチエージェント システムから開始するタイミング

マルチエージェント システムは、1 つのビジネス プロセス内で個別のタスク用に 2 つ以上のエージェントをデプロイします。 このアーキテクチャにより、さまざまなオーケストレーション パターンと特殊化が可能になります。 エージェント間の調整により、各ハンドオフ ポイントで待機時間が発生し、コンポーネント間で明示的な状態管理が必要になります。 組織は、次のような特定の条件で分離が義務付けられている場合にのみ、マルチエージェント アーキテクチャ から開始 する必要があります。

1. セキュリティとコンプライアンスの境界を越える。 規制またはポリシーで厳密なデータ分離が義務付けられている場合は、複数のエージェントを構築します。 異なるセキュリティ分類には、単一のエージェントでは提供できない独立した処理環境が必要です。 この最小特権設計では、個々のエージェント境界内に侵害を含めることで、セキュリティ インシデントの爆発半径が制限されます。 多くの場合、金融サービスでは、あるエージェントがトランザクションを準備し、別のエージェントがトランザクションを検証し、アーキテクチャを使用して職務を分離する必要があります。

2. 複数のチームが関与します。 個別のチームが個別のナレッジ領域を管理する場合は、マルチエージェント設計を採用します。 独立した開発サイクルでは、チームがドメイン固有のエージェントを管理する分離アーキテクチャの利点があります。 各チームは、他のチームを待たずに、専門の専門知識とデータ ソースを使用します。 この配置は組織構造を反映し、並列開発を可能にします。 Teams は個別に更新プログラムを展開しますが、ドメイン間の明示的なインターフェイスによってガバナンスが簡素化され、統合リスクが軽減されます。

3. 将来の成長が計画されています。 ソリューション ロードマップに多様な機能、データ ソース、またはビジネス ユニットが含まれている場合は、モジュール式のマルチエージェント設計を選択します。 モノリシック エージェントは、責任が元の範囲を超えて拡大するにつれて、保守が困難になります。 懸念事項を早期に分離することで、操作を中断する大規模なリファクタリングを防ぐことができます。 3 つ以上から 5 つ以上の異なる関数にまたがるソリューションは、このアーキテクチャのメリットを受けます。 個々のエージェントは、システム全体に影響を与えずに個別に最新化でき、アップグレードリスクを軽減し、増分的な改善を可能にします。

マルチエージェントオーケストレーションとワークフロー

マルチエージェント システムでは、Azure アーキテクチャ センターに記載されている オーケストレーション パターンを 実装するためのワークフローが必要です。 エージェントを手動でチェーンすると、予期しない障害が発生する不安定な接続が作成されます。 ワークフローは、信頼性の高いエージェントの対話を保証する構造化された調整を提供します。 マルチエージェント システムでワークフローを使用する利点を次に示します。

テクノロジ固有の実装オプションについては 、「オーケストレーション戦略 」を参照してください。

マルチエージェント システムのトレードオフ

各エージェントの対話には、プロトコルの設計、エラー処理、および状態の同期が必要です。 すべてのコンポーネントには、個別のプロンプト エンジニアリング、監視インフラストラクチャ、デバッグ機能が必要です。 セキュリティ サーフェスは、エージェント間の追加の資格情報管理とデータ転送ポイントによって拡張されます。 各エージェントが冗長コンテキストを処理し、通信オーバーヘッドにエージェント数が乗算されるため、コスト構造が増加します。 各ハンドオフ ポイントで待機時間が蓄積され、ユーザー エクスペリエンスが低下する可能性があります。

1 つのエージェント システムを最初にテストするタイミング

ユース ケースがマルチエージェント システムの条件を満たしていない場合は、通常、1 つのエージェントでテストすることから始める必要があります。 特定のシナリオに最適なアーキテクチャを選択する前に、主要な前提条件を早期に検証することが重要です。 マルチエージェント アーキテクチャが必要な場合もありますが、多くの場合、複雑さまたはパフォーマンスに関する未テストの前提条件に基づいて選択されます。 次の条件を満たすユース ケースの場合は、単一エージェント のプロトタイプから始めてベースライン機能を確立します。 テストで単一エージェントの最適化では解決できない制限が明らかになった場合にのみ、マルチエージェント アーキテクチャに移行します。

1. 関係する役割を明確にします。 ロールの分離に複数のエージェントが必要であると想定しないでください。 個別のロール (Planner、レビュー担当者、Executor など) では、複数のエージェントが提案される場合がありますが、マルチエージェント アーキテクチャは自動的には正当化されません。 多くの場合、ペルソナの切り替え、条件付きプロンプト、コンテキスト対応ポリシーを使用する 1 つのエージェントは、オーケストレーションを追加せずにロールベースの動作を満たすことができます。 1 つのエージェントを使用してプロトタイプを作成し、想定を検証し、ロール エミュレーション (ペルソナ プロンプト、ツールのアクセス許可、コンテキスト ゲーティング) が必要な結果を達成するかどうかを測定します。 マルチエージェントに移行するのは、単一エージェント のテストで、プロンプト、取得の改善、またはポリシー制御によって修復できない制限が示されている場合のみです。

2. 迅速な市場投入が必要です。 単一エージェント プロトタイプを使用すると、検証の高速化、イテレーションの高速化、および以前のユーザー フィードバックが可能になります。 マルチエージェント システムでは、調整ロジック、通信プロトコル、およびワークフロー オーケストレーションが追加され、早期の開発が遅くなり、テストが複雑になります。 マルチエージェント調整に投資する前に、単一のエージェントを使用して迅速に価値を証明します。

3. 低コストの優先順位。 単一エージェント設計では、1 つのエンティティ内でコンテキストを維持することで、トークンの使用と API 呼び出しを減らします。 オーケストレーションのオーバーヘッドを追加する前に、プロトタイプを作成してコストのメリットを検証します。 マルチエージェント システムは、冗長なコンテキスト処理と、予算の制約を超える可能性があるエージェント間通信によって費用を乗算します。

4. 大量のデータが処理されます。 1 つのエージェントが、完全なデータ スコープを処理しながら、使用可能なコンテキスト ウィンドウ内で正確に動作できるかどうかを検証します。 スケーラビリティの問題の多くは、アーキテクチャではなく、取得設計に起因します。 たとえば、チームはチャンクとインデックス作成を調整し、クエリに合わせて通路の選択を調整し、モデルのウィンドウ内に収まるように不要なコンテキストを減らすことができます。 テストでコンテキスト ウィンドウの拡大、モデルのアップグレード、キャッシュ、再ランク付け、プロンプト/チェーン最適化を行ったにもかかわらず、永続的な精度や待機時間の低下が示される場合にのみ、マルチエージェントに移行します。

5. 需要の高いプロセス。 運用環境に似た負荷の下で、単一のエージェントでスループットと待機時間を測定します。 マルチエージェント アーキテクチャは、並列化によって測定可能なパフォーマンスが向上する場合にのみ値を提供します。 調整のオーバーヘッドにより、多くのシナリオでコンカレンシーの利点が無効になり、単一エージェントの効率が向上します。

6. 異なるモダリティが関与している。 まず、1 つのエージェント内のテキスト、画像、およびその他の形式を処理するマルチモーダル モデルから始めます。 特殊なエージェントは、一般的なモデルでは提供できない個別の最適化が特定のモダリティで必要な場合にのみ使用します。 複雑な画像分析やリアルタイムオーディオ処理は、特殊なリソースを持つ専用エージェントを正当化する場合があります。

1 つのエージェント システムを使用する場合

単一エージェント アーキテクチャでは、ロジック、コンテキスト、およびツールの実行が 1 つのエンティティに統合されます。 この統合により、設計の複雑さが軽減され、実装が簡略化され、ガバナンスが合理化されます。 組織は、オーケストレーションの仕組みではなく、ビジネス価値に重点を置くことができます。 単一エージェントは、 複雑度の低い ユース ケースに最も効率的な開始点を提供します。

1. 明確に定義された問題ドメイン。 ワークフローが境界付けられたコンテキスト内で予測可能なパターンに従う場合は、単一のエージェントを選択します。 このアプローチにより、システムの保守性が維持され、開発サイクルが高速化されます。 固定 API シーケンスを実行する特定のナレッジ ベースまたはアシスタントから回答する FAQ ボットは、一般的な単一エージェント シナリオを表します。

2. 運用効率が重要です。 単一エージェントは、待機時間と障害点を導入するエージェント間通信プロトコルを排除します。 すべてのロジックが 1 か所に存在する場合、デバッグは簡単になります。 メンテナンス チームは、複雑なエージェント操作や分散ログを移動することなく、問題を追跡できます。

単一エージェント ワークフロー

多くの場合、単一エージェントはオーケストレーションなしでユーザー要求に直接応答します。 ワークフローは、単一のエージェントでも信頼性とエンタープライズ統合に不可欠な構造を提供します。

• 再現性。 ワークフローは、手動介入なしで入力全体で一貫したタスクを実行します。 夜間のバッチ集計またはスケジュールされたレポート生成には、単一エージェントに関するワークフロー自動化が必要です。
• システム統合。 ワークフロー コネクタを使用して、エージェントの出力をダウンストリーム システムにルーティングします。 ワークフローは、SharePoint への結果の送信、Teams への通知の投稿、エンタープライズ データベースへのデータの書き込みなどのアクションをトリガーします。
• ガバナンスとコンプライアンス。 ワークフロー機能を使用して、ログ記録、承認ゲート、監査証跡を実装します。 これらの制御は規制要件を満たし、エージェントの決定に対する運用上の可視性を提供します。
• 人によるレビュー。 ユーザーがダウンストリームの実行前にエージェントの出力を検証するチェックポイントを挿入します。 この人間のループ内パターンは、自動化の利点を維持しながら品質を維持します。

テクノロジ固有のワークフロー実装オプションの オーケストレーション戦略 を参照してください。

単一エージェント システムのトレードオフ

コンテキスト長の制限により、エージェントが同時に処理する情報量が制限されます。 広範な機能要件では、1 つのエージェントがすべての潜在的なアクションに対するアクセス許可を必要とするため、最小限の特権のセキュリティが複雑になります。 複雑なドメインでは、単一のエージェントが過剰に使用され、コンテキストの拡大に伴って精度が低下したり応答時間が増加したりする可能性があります。

意思決定フレームワーク

次のステップ