(上の画像をクリックすると、このレッスンのビデオを視聴できます)
複数のエージェントを扱うプロジェクトに着手するとすぐに、マルチエージェント設計パターンを考慮する必要があります。しかし、いつマルチエージェントに切り替えるべきか、その利点は何かがすぐに明確になるとは限りません。
このレッスンでは、以下の質問に答えていきます：
- マルチエージェントが適用されるシナリオはどのようなものか？
- 複数のタスクを行う単一エージェントよりもマルチエージェントを使うメリットは何か？
- マルチエージェント設計パターンを実装するための構成要素は？
- 複数のエージェントがどのように相互作用しているかをどのように可視化するのか？
このレッスンを終えた後には、以下のことができるようになるでしょう：
- マルチエージェントが適用可能なシナリオを特定できる
- 単一のエージェントよりマルチエージェントの利点を認識できる
- マルチエージェント設計パターンの構成要素を理解できる
全体像は？
マルチエージェントは、複数のエージェントが共通の目標を達成するために協力する設計パターンです。
このパターンはロボティクス、自律システム、分散コンピューティングなど、多様な分野で広く利用されています。
どのようなシナリオがマルチエージェントを使う上でよいケースか？答えは、多くのシナリオで複数エージェントを使うことが有益で、特に以下の場合が挙げられます：
- 大規模な作業負荷：大きな作業負荷は小さなタスクに分割され、異なるエージェントに割り当てられ、並列処理と高速な完了が可能になります。例えば大規模なデータ処理タスクの場合です。
- 複雑なタスク：大規模な作業負荷と同様に、複雑なタスクは小さなサブタスクに分けられ、異なるエージェントが各々特定の側面を専門的に担当します。自動運転車の例として、ナビゲーション、障害物検知、他車両との通信を管理する複数のエージェントが存在します。
- 多様な専門知識：異なるエージェントが多様な専門知識を持ち、単一エージェントより効果的に異なる側面を処理できます。医療例では、診断、治療計画、患者監視を担当するエージェントがいます。
単一エージェントシステムは単純なタスクには適していますが、より複雑なタスクには複数エージェント利用のほうが多くのメリットがあります：
- 専門化：各エージェントは特定のタスクに特化できます。単一のエージェントでは専門性が乏しく、複雑なタスクに直面すると何をすべきか混乱してしまうことがあります。例えば、最適なタスクではない作業を誤って行う場合があります。
- スケーラビリティ：システムの拡張は、単一エージェントに負荷をかけ続けるより、新たにエージェントを追加するほうが容易です。
- フォールトトレランス：１つのエージェントが故障しても他のエージェントが動作を継続し、システムの信頼性を確保できます。
例として、ユーザーの旅行予約を考えましょう。単一エージェントシステムでは、フライト検索からホテルやレンタカーの予約まで、すべてを担当する必要があります。これには各タスクを扱うためのツールが必要であり、複雑でモノリシックなシステムとなって維持や拡張が困難になる可能性があります。対照的にマルチエージェントシステムでは、フライト検索、ホテル予約、レンタカー予約に特化したエージェントが存在し、よりモジュール化され、保守性・拡張性が高まります。
これを、家族経営の旅行代理店とフランチャイズ運営の旅行代理店に例えることができます。家族経営の方は単一のエージェントがすべての予約を担当し、フランチャイズの場合は異なるエージェントが予約プロセスの異なる側面を担当しています。
マルチエージェント設計パターンを実装する前に、パターンを構成する部品を理解する必要があります。
ユーザーの旅行予約という例で具体化してみます。この場合、構成要素は以下のようになります：
- エージェント間通信：フライト検索、ホテル予約、レンタカー予約のエージェント間で、ユーザーの希望や制約に関する情報を共有し合う必要があります。プロトコルや通信手段を決めることが必要です。たとえば、フライト検索エージェントはホテル予約エージェントと旅行日程を共有し、同じ日程でホテルも予約できるようにします。つまり、どのエージェントが情報を共有し、どのように共有するかを決めるのです。
- 調整メカニズム：エージェントがそれぞれの行動を調整し、ユーザーの希望と制約を満たすようにします。たとえば、ユーザーが空港近くのホテルを希望し、レンタカーは空港でのみ借りられるという制約があるとします。ホテル予約エージェントはレンタカー予約エージェントと調整し、ユーザー条件を満たすようにします。つまり、エージェントがどのように行動調整を行うかを決定する必要があります。
- エージェントアーキテクチャ：エージェントは意思決定し、ユーザーとの相互作用から学習できる内部構造を持つ必要があります。例えば、フライト検索エージェントは過去のユーザーの好みに基づき機械学習モデルを使ってフライトを提案するかもしれません。つまり、エージェントがどのように意思決定し学習するのかを決めます。
- マルチエージェントの相互作用への可視化：複数エージェントがどのように相互作用しているかを見える化することが重要です。エージェントの活動ややりとりを追跡するツールや技術が必要で、ログやモニタリングツール、可視化ツール、パフォーマンス指標などが利用されます。
- マルチエージェントパターン：マルチエージェントシステム実装のパターンには、中央集権型、分散型、ハイブリッド型があり、自身のユースケースに合うパターンを選択します。
- 人間の介在：多くの場合、人間が介在し、エージェントが人間の介入を必要とするときに指示を受ける形を取ります。例えば、ユーザーが特定のホテルやフライトを希望し、それがエージェントの提案にない場合や、予約前に確認を求める場合などがこれにあたります。
複数エージェントがどのように相互作用しているかの可視化は、デバッグや最適化、システム全体の効果検証に不可欠です。そのためにエージェントの活動と相互作用を追跡できるツール・技術が必要で、ログやモニタリングツール、可視化ツール、パフォーマンス指標がその例です。
例えば、ユーザーの旅行予約の場合、各エージェントの状況、ユーザーの希望や制約、エージェント同士のやりとりを表示するダッシュボードを用意できます。ダッシュボードはユーザーの旅行日程、フライトエージェントの推奨フライト、ホテルエージェントの推奨ホテル、レンタカーエージェントの推奨レンタカーを示し、エージェント間の相互作用とユーザー希望の充足状況を明確に把握できます。
以下の要素を詳しく見てみましょう。
- ログとモニタリングツール：各エージェントの行動をログ化することが望ましいです。ログには、行動を実施したエージェント、行動内容、実施時間、結果などが含まれます。この情報はデバッグや最適化に役立ちます。
- 可視化ツール：エージェント間の相互作用をより直感的に理解できるようにします。例えば、エージェント間の情報の流れを示すグラフが考えられます。これによりボトルネックや非効率、問題点の特定がしやすくなります。
- パフォーマンス指標：マルチエージェントシステムの有効性を評価するために使います。例えば、タスク完了に要した時間、単位時間あたりの完了タスク数、エージェントの推薦の正確さなどを追跡し、改善点の特定とシステム最適化に役立てます。
マルチエージェントアプリを作成する際に使える具体的なパターンを見ていきましょう。注目すべき興味深いパターンは以下の通りです：
このパターンは、複数のエージェントが互いにコミュニケーションを取るグループチャットアプリを作りたいときに有効です。典型的な利用ケースは、チームコラボレーション、カスタマーサポート、ソーシャルネットワーキングです。
このパターンでは、各エージェントがグループチャット内のユーザーを表し、エージェント間でメッセージプロトコルを使ってメッセージをやり取りします。エージェントはグループチャットにメッセージを送信し、受け取り、他のエージェントのメッセージに応答します。
実装は、すべてのメッセージが中央サーバーを経由する中央集権型、またはエージェント間で直接メッセージを交換する分散型のいずれかが可能です。
このパターンは、複数のエージェントがタスクを互いに引き継ぐアプリを作りたいときに適しています。
典型的な用途は、カスタマーサポート、タスク管理、ワークフロー自動化です。
このパターンでは、各エージェントがタスクやワークフローのステップを表し、事前に決められたルールに基づきエージェント間でタスクを引き継ぎます。
このパターンは、複数のエージェントが協力してユーザーへの推薦を行うアプリを作りたいときに有効です。
複数のエージェントが協力する理由は、それぞれ異なる専門知識を持ち、推薦プロセスに多様な観点から貢献できるからです。
例えば、ユーザーが株式市場で買うべき銘柄の推薦を求めるケースを考えます。
- 業界専門家：１つのエージェントは特定の業界の専門家です。
- テクニカル分析：別のエージェントはテクニカル分析の専門家です。
- ファンダメンタル分析：さらに別のエージェントはファンダメンタル分析の専門家です。このように協力することで、より包括的な推薦が可能になります。
製品の返金を求める顧客を想定します。このプロセスには多くのエージェントが関わりますが、このプロセス専用のエージェントと他のプロセスでも使用可能な汎用エージェントに分けてみましょう。
返金プロセス専用エージェント:
返金プロセスに関わる可能性があるエージェントは以下の通りです：
- 顧客エージェント：顧客を表し、返金プロセスの開始を担当します。
- 販売者エージェント：販売者を表し、返金手続きを処理します。
- 支払いエージェント：支払い処理を表し、顧客への返金を実施します。
- 解決エージェント：問題解決プロセスを表し、返金手続き中に起こる問題の解決を担当します。
- コンプライアンスエージェント：規制やポリシーに従って返金プロセスが実行されているかを確認します。
汎用エージェント：
これらはビジネスの他の部分でも利用できるエージェントです：
- 配送エージェント：配送プロセスを担当し、製品を販売者に返送します。返金プロセスだけでなく、購入した製品の一般配送にも使えます。
- フィードバックエージェント：顧客からのフィードバック収集を担当し、返金プロセス以外のタイミングでも利用可能です。
- エスカレーションエージェント：問題を上位のサポートレベルに引き上げるプロセスを担当し、課題のエスカレーションが必要な任意のプロセスで利用できます。
- 通知エージェント：返金プロセスの複数段階で顧客に通知を送る担当です。
- 分析エージェント：返金プロセスに関するデータ分析を担当します。
- 監査エージェント：返金プロセスが正確に実行されているか監査します。
- 報告エージェント：返金プロセスのレポート作成を担当します。
- 知識エージェント：返金に関する知識ベースを維持し、返金だけでなく他のビジネス領域に関する情報も含みます。
- セキュリティエージェント：返金プロセスのセキュリティ確保を担当します。
- 品質エージェント：返金プロセスの品質管理を担当します。
返金プロセス専用とビジネスの他の部分で使う汎用両方のエージェントがかなり多くリストアップされました。これによりマルチエージェントシステムでどのようにエージェントを選ぶかの参考になれば幸いです。
カスタマーサポートプロセスのマルチエージェントシステムを設計してください。プロセスに関わるエージェント、それぞれの役割・責任、および相互作用の仕組みを特定してください。カスタマーサポート専用エージェントとビジネスの他の部分でも使える汎用エージェントの両方を考慮してください。
次の解決策を読む前に少し考えてみてください。想像以上に多くのエージェントが必要になるかもしれません。
TIP: カスタマーサポートプロセスの異なる段階や、システムに必要なエージェントについても考慮してください。
Question: いつマルチエージェントの使用を検討すべきですか？
- A1: 作業量が少なく、タスクが単純な場合。
- A2: 作業量が多い場合。
- A3: タスクが単純な場合。
このレッスンでは、マルチエージェントデザインパターンを取り上げました。マルチエージェントが適用されるシナリオ、単一エージェントに比べたマルチエージェントの利点、マルチエージェントデザインパターンの実装における構成要素、および複数のエージェントがどのように相互作用しているかを把握する方法について説明しました。
Microsoft Foundry Discord に参加して、他の学習者と交流したり、オフィスアワーに参加したり、AIエージェントに関する質問に答えてもらいましょう。
免責事項： 本書類はAI翻訳サービス「Co-op Translator」（https://github.com/Azure/co-op-translator）を利用して翻訳されました。正確性を追求しておりますが、自動翻訳には誤りや不正確な箇所が含まれる可能性があります。原文の母国語の文書を正本としてご参照ください。重要な情報については、専門の人間による翻訳を推奨いたします。本翻訳の利用により生じたいかなる誤解や誤訳についても責任を負いかねます。
