※本記事は、AWS re:Invent 2024で開催されたセッション「Using multiple agents for scalable generative AI applications (AIM304)」の内容を基に作成されています。本セッションは、Amazon Web Services (AWS)が主催する世界最大のクラウドコンピューティングカンファレンスの一部として実施されました。
登壇者：
- Michael Liu氏（Amazon Bedrock Agentsのプロダクトリード）
- Mark Roy氏（Amazon Bedrockのプリンシパルアーキテクト、AWS在籍7年、Bedrock担当2年）
- Heiko Zuerker氏（Northwestern Mutualのプリンシパルアーキテクト）
本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報については、AWS re:Invent (https://go.aws/reinvent) の公式サイトをご確認ください。より詳細な技術情報については、AWS公式チャンネル (http://bit.ly/2O3zS75) やAWSイベント動画 (http://bit.ly/316g9t4) もご参照ください。
AWSは世界で最も包括的で広く採用されているクラウドプラットフォームであり、世界中のデータセンターから200以上の機能を提供しています。最も急成長するスタートアップから大手企業、主要な政府機関まで、数百万の顧客がAWSを利用してコストを削減し、アジリティを向上させ、より迅速なイノベーションを実現しています。
1. イントロダクション
1.1. Amazon Bedrock の概要
Michael Liu： re:Inventの3日目にご参加いただき、ありがとうございます。GenAIの開発者、データサイエンティスト、そして熱心な方々に向けたマルチエージェントコラボレーションのセッションへようこそ。
最初に会場の皆さんに伺いたいのですが、エージェントをテストしたり、作成したり、あるいは業界のソリューションで本番環境にデプロイした経験のある方は手を挙げていただけますか？おそらく4分の1程度の方々が手を挙げていただきましたね。
皆さんがどのようなソリューションを使用されているかに関わらず、エージェントの作成、テスト、最適化、デバッグ、デプロイ、スケーリングのプロセスは往々にして困難なものになることがわかっています。本日は、Bedrock Agentsがどのように単一およびマルチエージェントの作成プロセスを容易にするかをご紹介します。
Amazon Bedrockは、業界をリードするモデルプロバイダーから提供される高性能なモデルを幅広く提供する完全マネージド型サービスです。昨日発表された我々独自の1Pソリューションである1Pモデル「Nova」も含まれています。
Bedrockは、カスタムモデルをプラットフォーム上にインポートし、カスタマイズやモデルの蒸留、微調整を行うための使いやすいインターフェースを提供しています。これにより、皆様の特殊な顧客ユースケースにより適合させることができます。
さらに、知識ベース、知識ベースのための検索拡張生成、誤用や乱用から保護するためのGuardrails、プロンプトや呼び出しを決定論的に連鎖させてエンドツーエンドのソリューションを提供するBedrock Flows、そして私の最も好きなトピックであるBedrock Agentsなど、生成AIツールも提供しています。これらすべてはAWS上のエンタープライズグレードのセキュリティ、プライバシー、データガバナンスに支えられています。
私のチームと私は、Amazon Bedrockが皆様のすべての生成AIニーズを構築・スケールする最も簡単な方法となるよう、非常に懸命に取り組んでいます。
1.2. Bedrock が提供する主要機能
Michael Liu： 我々のBedrockは、様々な先進的な機能を提供しています。まず、カスタムモデルのインポートに関して、Bedrockはプラットフォーム上に簡単にカスタムモデルをインポートできるインターフェースを提供しています。このインターフェースを通じて、モデルのカスタマイズや蒸留、微調整を行うことができ、お客様の特殊なユースケースにより適合させることが可能です。
さらに、生成AI用のツール群も提供しています。具体的には、知識ベースとその知識ベースのための検索拡張生成機能を提供しています。また、誤用や乱用から保護するためのGuardrails機能も実装しています。
特に重要な機能として、Bedrock Flowsがあります。これは、プロンプトや呼び出しを決定論的に連鎖させ、エンドツーエンドのソリューションを提供する機能です。そして私が最も注力しているBedrock Agentsも主要な機能の一つです。
これらの機能はすべて、AWS上のエンタープライズグレードのセキュリティ、プライバシー、データガバナンスに基づいて提供されています。我々のチームは、Amazon Bedrockが皆様の生成AIニーズを構築・スケールする最も簡単な方法となるよう、日々改善を重ねています。昨日発表された我々独自の1Pソリューションである1Pモデル「Nova」も、これらの機能群と統合され、より強力なソリューションを提供することが可能になっています。
1.3. 単一エージェントの課題と限界
Michael Liu： 本日の会場で、エージェントをテストしたり、作成したり、あるいは本番環境にデプロイした経験について尋ねたところ、約4分の1の方々が手を挙げていただきました。この結果は、エージェント技術がまだ発展段階にあることを示しています。
これまで多くの皆様との対話を通じて、単一エージェントに関する主要な課題が明らかになってきました。第一に、複雑なワークフローの自動化です。皆様のユースケースは多様で多面的であり、複数の業界にまたがっています。エージェントは単純なユースケースから、より複雑なユースケースへと移行を求められており、これには多段階の推論、ツールの使用、複雑な目標を達成するためのエージェントグループを制御する高度なオーケストレーションが必要です。
第二の課題は、開発速度の向上です。現在のエージェント開発サイクルは、作成、テスト、デバッグ、最適化、スケーリングなど、ライフサイクル全体を通じて非常に時間がかかります。これらには多くのGenAI開発者やデータサイエンティストのチームが必要ですが、プロトタイプから本番環境への移行には、依然として相当の専門知識が必要とされています。
第三の課題は、堅牢性、信頼性、そしてスケーラビリティです。皆様は開発から本番環境まで、堅牢なエンドツーエンドのソリューションを求めています。例えば、基礎となるビジネスプロセスが変更された場合、エージェントソリューションをアップグレードする必要があります。また、基盤となる基礎モデルが新しいモデルバージョンにアップグレードされた場合、それらをより簡単に管理したいというニーズがあります。
これらの課題に対応するため、私たちはAmazon Bedrock Agentsを構築し、お客様が独自のエージェントアプリケーションを作成するための基本的な構成要素を提供しています。
2. マルチエージェントコラボレーション
2.1. マルチエージェント導入の背景
Michael Liu： マルチエージェントワークフローに焦点を当てる理由について、まず会場の皆様に質問させていただきました。他の業界ソリューションを使ってマルチエージェントをオーケストレーションした経験のある方は手を挙げていただけますでしょうか。数人の方が手を挙げていただき、これは確かに励みになります。
私たちがマルチエージェントを導入する理由は、多くのお客様から単一のエージェントが問題解決の複雑さ、スケール、範囲の限界に達していると指摘されているためです。私たちの観察では、エージェントがより多くの役割と責任を担う、より巨大なモノリシックなエージェントにスケールしていくと、タスクの成功率、精度、そしてワークフロー全体の目標達成率が低下することがわかっています。これは、過去に非常に一般的に見られたデザインパターンです。
多くのお客様は、専門化されたエージェントのグループを持ち、それらをスーパーバイザーエージェントを使って連鎖させ、オーケストレーションするマルチエージェントワークフローに有機的に進化していったと教えてくれました。しかし、この進化の中で、複数のエージェント間のオーケストレーションは困難であることも指摘されています。
市場には多くの競合ソリューションや比較可能なソリューションがありますが、お客様が求めているのは、単一エージェントの開発の容易さと複数エージェントのオーケストレーションによる問題解決の効果を組み合わせたマネージドソリューションでした。これこそが、私たちがAmazon Bedrock上に構築したソリューションであり、昨日のCEO Matt Garmanのキーノートでも言及されたマルチエージェントコラボレーション機能として、プレビューとして発表させていただきました。
2.2. 従来の単一エージェントの問題点
Mark Roy： 私の30年以上のキャリアの中で、このような変化の速さやブレークスルーの頻度は見たことがありません。今週だけでもBedrockから2ダースもの製品発表があり、それらすべてが私たちビルダーにとって、より大きなインパクトをより速く実現できるという点で驚くべきものです。
多くのお客様との過去1年間の関わりの中で、典型的な開発の進化パターンが見えてきました。最初は内部の生産性向上ユースケースに取り組むための単一エージェントを試し、次に知識ベースを追加し、さらに機能を追加していく傾向があります。例えば、休暇管理、病欠、その他の機能を扱うHRボットから始め、HR知識ベースを追加し、さらに休職管理機能を追加するというように進化していきます。
しかし、このアプローチには3つの重大な問題が発生します。第一に、コーディングが非常に複雑になります。生活を簡単にしようとしていたのに、すべてのツールが正しい順序で呼び出されることを確認しようとすると、とても扱いづらくなってしまいます。
第二に、エージェントが混乱を起こし始めます。LLMは驚くべき能力を持っていますが、あまりにも多くのことを要求すると本当に問題が発生します。実際、私たちのベストプラクティスブログ投稿の最初に記載しているのは、「エージェントは小さく焦点を絞ったものに保つ」ということです。
第三に、エージェントが遅くなり、コストがかかるようになります。これには2つの理由があります。プロンプトが長くなりすぎ、「この状況に遭遇した場合はこれを試さないでください」や「これを忘れずに実行しましたか？」といった追加のチェックを組み込み始めるためです。そして最高のモデルにアップグレードする必要が出てきます。通常、最高のモデルは他のモデルよりも遅いため、2つの要因が相まって問題となります。
2.3. Bedrock マルチエージェントの特徴と利点
Michael Liu： 私たちのマルチエージェントコラボレーションがAmazon Bedrock上でどのように機能するのかについて説明させていただきます。私たちの内部テストでは、マルチエージェントセットアップにより、お客様はワークフローを専門化されたエージェントのグループに分解し、それらの間でオーケストレーションを行うことができることを示しています。これにより、問題解決、精度、スケーラビリティ、そして回復力が向上します。
Amazon Bedrockでのマルチエージェントコラボレーションの主要な特徴として、以下の点を提供しています。第一に、小規模で焦点を絞ったエージェントと知識ベースを簡単に組み立てることができます。第二に、スーパーバイザーエージェントが、コードやロジックを書くことなく、それらのエージェント間の計画と実行を行うことができます。第三に、エージェント間の会話を統一し、組み込みの意図分類により、適切なサブエージェントへの高速かつ低レイテンシーなルーティングを実現します。
Mark Roy： さらに重要な点として、フローの観測可能性を提供しています。どのサブエージェントが呼び出されているか、プロセス全体のステップだけでなく、サブステップまで確認することができます。また、マルチレベルの階層構造も実現可能です。つまり、あるエージェントが他のエージェントを持ち、さらにそれらのエージェントが他のエージェントを持つという構造を作ることができます。
そして、これらすべてがAWSとBedrock、そしてBedrock Agentsで知られているセキュリティ、Guardrails、プライバシーなどの機能とともに提供されます。私たちのソリューションは、市場の他のソリューションと比較して、新しい未知のタスクにも動的に対応できるエージェントチームをマネージドサービス上でオーケストレーションできる点で優れています。
3. ユースケースとデモンストレーション
3.1. 住宅ローン申請アシスタントのデモ
Mark Roy： マルチエージェントの力を実証するため、Octank Mortgagesの事例を使ってデモンストレーションを行います。Amazon Bedrock導入以前、住宅ローンのお客様は長い待ち時間、煩わしい音声メニュー、コールセンターの高負荷に直面し、限られた取引しかできない単純なウェブサイトを使用せざるを得ませんでした。
私たちはBedrockを使用して、3つの主要な機能を持つモーゲージアシスタントを構築しました。既存の住宅ローンの管理、新規の住宅ローン申請プロセス、そして一般的な質問への回答です。これにより、お客様は少ない労力で素早く優れた回答を得られ、柔軟で個別化された対応が可能になり、コールセンターの負荷も軽減されました。また、新しいビジネス領域や分野に進出する際には、サブエージェントを追加して会話を拡張することができます。
デモでは、シンプルなPythonのStreamlitアプリを使用しています。「次の支払いはいつで、いくらですか？」という質問から始めると、システムは適切なコラボレーターを選択し、get_mortgage_statusツールを使用して回答を提供します。支払期日と金額を示し、「このローンが完了するまでに残りいくつの支払いがありますか？」といったフォローアップの質問にも対応できます。
さらに複雑な質問として、「現在の金利はいくらで、新しい15年固定住宅ローンの金利はいくらで、借り換えるだけの価値はありますか？」という質問にも対応できます。システムは3つのステップから成る計画を立て、既存の住宅ローンの金利確認、新規の15年固定金利の確認、そして知識ベースからの一般的なアドバイスの取得を並列で実行し、これらを統合して包括的な回答を提供します。
このデモは、複数の部門にまたがる情報を統合し、お客様に一貫した体験を提供する機能を示しています。これはRocket Mortgageのような実際の事例でも採用されており、複数のアカウントや要望を持つお客様に対して、シームレスなワンストップの対応を実現しています。
3.2. 複雑なプロセス自動化のデモ
Mark Roy： 複雑なプロセスの自動化の例として、Octankの新しい事業部門であるスタートアップアドバイザリービジネスのケースをご紹介します。これは、スタートアップ企業のマーケティング戦略作成やキャンペーンのアイデア創出、それらの実装を支援する新しいサービスです。需要は非常に高く、お客様からの評価も素晴らしいのですが、専門家スタッフが限られているため、ビジネスの10倍規模への拡大が課題となっていました。
この課題に対し、マルチエージェントコラボレーションを活用して、新規スタートアップの受け入れプロセスを自動化し、初期リサーチ、全体戦略の策定、主要ポイントの概要作成、キャンペーンアイデアのブレインストーミング、最適なキャンペーンアイデアの詳細化、そして全体報告書の作成までを実現しました。
このソリューションでは、スーパーバイザーとして機能するスタートアップアドバイザーと、リードマーケットアナリスト、チーフストラテジスト、コンテンツライター、クリエイティブディレクター、そしてフォーマットされたレポートライターというコラボレーターのセットを用意しました。
プロトタイプには、すべてのコラボレーター間で作業メモリとして機能する簡単なset keyとget keyのツールセットも追加しました。これは単純なDynamoDBのLambdaラッパーですが、各サブエージェントが進行中に情報を保存し、既に決定された情報を取得することで、状態を効果的に共有できます。
デモでは、飛行車の新サービスのマーケティング戦略を作成するというプロジェクト記述を与え、スーパーバイザーに一連の詳細なタスクを実行させました。スーパーバイザーは計画を立て、複数のコラボレーターを活用し、市場調査、戦略、キャンペーンアイデアの草案、各キャンペーンのコピーなどを作成しながら、情報を保存していきます。
特に興味深い点は、コンテンツライターとクリエイティブディレクターがチームとして機能し、適切な品質スコアまたは完成度に達するまで、ドラフトの作成、フィードバックの提供、フィードバックの組み込み、新しいドラフトの作成という反復的なループを実行する点です。最終的に、スーパーバイザーはフォーマットされたレポートライターに、途中で生成された全ての情報を取得させ、チームに渡す洗練されたレポートを作成させます。
3.3. スタートアップアドバイザーのマルチエージェント構成
Mark Roy： スタートアップアドバイザーのシステムでは、5つの異なる専門家エージェントを配置しています。スーパーバイザーとしてのスタートアップアドバイザーの下に、リードマーケットアナリスト、チーフストラテジスト、コンテンツライター、クリエイティブディレクター、そしてフォーマットされたレポートライターを配置しています。
これらのエージェント間でのデータ共有と状態管理のために、単純なset keyとget keyのツールセットを実装しました。これはDynamoDB上の簡単なLambdaラッパーですが、作業メモリとして効果的に機能します。各サブエージェントは処理の過程で情報を保存し、他のエージェントが決定した情報を取得することができます。
特に興味深い点は、コンテンツライターとクリエイティブディレクターの間の反復的な改善プロセスです。例えば、詳細なキャンペーンレポートの作成では、コンテンツライターが草案を作成し、クリエイティブディレクターがフィードバックを提供します。このフィードバックを基に新しい草案が作成され、適切な品質スコアまたは完成度に達するまでこのプロセスが繰り返されます。
最終段階では、スーパーバイザーがフォーマットされたレポートライターに指示を出し、プロセス全体で生成された情報を取得して、チームに提供するための洗練された最終レポートを作成します。このように、各エージェントが専門性を活かしながら、協調的に作業を進めることで、高品質なアウトプットを生成することができます。
このマルチエージェント構成は、投資ポートフォリオ分析、保険金請求の処理、開発者の作業支援など、他の複雑なビジネスプロセスにも応用可能です。さらには、マルチエージェントを使用してマルチエージェントを生成するという、より高度な活用も考えられます。
4. Northwestern Mutual の事例研究
4.1. プロジェクトの概要と目的
Heiko Zuerker： 私はNorthwestern Mutualのプリンシパルアーキテクトを務めています。当社は金融プランニングサービス、資産管理、生命保険や長期介護保険などの保険商品を提供しています。GenAIが世間の注目を集めたとき、私たちはすぐにその価値と可能性を認識し、積極的に技術を取り入れました。過去2年間でこの技術がどのように進化してきたかを見るのは驚くばかりですが、今でも急速に変化し続けています。
多くのユースケースを実験段階から本番環境へと移行してきましたが、今日は特に開発者サポートに関する事例をお話しします。私たちは内部の開発者サポートのほとんどをチャットを通じて提供していましたが、それは必ずしもユーザーにとっても、サポートエンジニアにとっても最適な体験ではありませんでした。特に週末や休暇期間中は応答時間が長くなり、また、既に文書化されている基本的な質問が多く寄せられていました。さらに、ユーザーのロック解除のような簡単に自動化できる要求も多くありました。
私は今年初め、すばらしいチームを率いてこのための試験的なアプリケーションを作成する機会を得ました。私たちは6月に本格的な取り組みを開始し、9月には本番環境での運用を開始することができました。このプロジェクトにBedrockを選択した理由は、同僚の言葉を借りれば、「本当に素晴らしいツールやライブラリが数多く存在しているが、1年前は選択の余地がなかった。しかし今は、RAGのユースケースを数時間や数日ではなく、数分で立ち上げることができる」というものでした。
また、私たちは既にAWSを使用しており、きめ細かいアクセス制御の管理方法を理解していました。さらに、組み込みの暗号化やHIPAAコンプライアンスなど、当社にとって非常に重要な機能も提供されていました。この選択により、サポートエンジニアの関与なしに数分以内にサポート要求に回答できるようになり、サポートエンジニアはより複雑な問題に集中できるようになりました。これは企業にとって素晴らしい成果であり、従業員のエンゲージメントの観点からも非常に効果的でした。
4.2. システムアーキテクチャ
Heiko Zuerker： 私たちのメインアーキテクチャ設計目標の一つは、管理が必要なインフラストラクチャを持たないことでした。そのため、できる限りサーバーレス技術とマネージドサービスを使用することにしました。バックエンドに問題が発生した場合に備えて、メッセージのキューイングにSQSを使用し、現在はLambdaで実行されているPythonで書かれたオーケストレーションレイヤーを実装しました。このオーケストレーションレイヤーは、マルチエージェントコラボレーションに置き換えていく予定です。
また、エスカレーションされたメッセージの状態管理にDynamoDBを使用しています。Bedrock内では、多くのコンポーネントを活用しています。Guardrailsに大きく依存し、潜在的なPII情報やその他の機密情報、あるいはユーザーが誤ってチャットにパスワードを投稿してしまった場合など、必要な情報のマスキングを行っています。また、悪意のある意図や、チャットで管理するのに適切でないものからも保護しています。
特に重要な機能としてクロスリージョン推論があります。現在これは必須の機能となっており、実装も非常に簡単です。異なる推論プロファイルIDを提供するだけで、複数のリージョンのパワーを活用できます。これにより、ソリューションの安定性とパフォーマンスが大幅に向上しました。
私たちは複数のエージェントを使用しており、これらはLambda関数を呼び出し、さらにバックエンドAPIを呼び出して必要なアクションを実行します。また、知識ベースではOpenSearch Serverlessをベクターデータベースとして活用しています。
これらのコンポーネントは、チャットメッセージが最初にオーケストレーションレイヤーに到達し、Guardrailsで保護されたLLMを呼び出して意図を特定し、適切なエージェント（この場合はユーザーエージェント）を呼び出すというフローで連携しています。その後、必要に応じてリクエストのマスキングやブロッキングを行い、アクショングループを通じてユーザーのロック解除などのLambda関数を呼び出します。
4.3. 実装における重要な発見
Heiko Zuerker： 規制された業界で活動する中で、AIが実行できることに関する厳格な社内ルールへの対応が課題でした。特に、AIが直接アクションを取ることが許可されていないという制限は大きな課題でした。エージェントにユーザーに代わってアクションを実行させたい場合、これは明らかに問題となります。
このジレンマを解決するため、リスクパートナーと協力し、長期的に持続可能なソリューションを考案しました。私たちの解決策は、エージェントがユーザーに対して実行予定のアクションを正確に説明し、明示的な確認として「yes」または「no」での回答を求めることでした。LLMは非常に賢く、ユーザーが「yeah」や「sure」、「ya」などと応答した場合でも肯定的な返事として解釈できますが、私たちはそのような曖昧さを許容することはできませんでした。そのため、回答を「yes」または「no」に厳密に制限することで、エージェントを本番環境で運用することが可能になりました。
また、評価エージェントの導入も非常に効果的でした。LLMは非常に協力的で、時には過剰に有用であろうとするため、誤った情報を生成したり、単に役に立たない回答を提供したりすることがあります。評価エージェントはこれらのメッセージをフィルタリングし、良好なユーザー体験を維持するのに役立っています。
さらに、ユーザーの行動変化への対応も重要な発見でした。当初、パイプラインの失敗を分析するエージェントは持っていませんでしたが、ユーザーの行動の変化を観察し、この機能を追加する必要性が明らかになりました。これは、システムが柔軟に進化し、ユーザーのニーズに適応する必要性を示しています。
マルチエージェントコラボレーションは、開発の方法を大きく変えようとしています。より速く、よりシンプルになり、多くの利点があります。私たちのソリューションをマルチエージェントコラボレーションに移行し、コードベースがどのように簡素化されるかを見るのが待ちきれません。
5. 実装のベストプラクティス
5.1. エージェントの設計パターン
Heiko Zuerker： 私たちの実装経験から、エージェントの設計に関するいくつかの重要なパターンが明らかになりました。まず、エージェントに割り当てるアクションの数を制限することが非常に重要です。当初の想定では3〜5のアクションが適切だと考えていましたが、実際の運用を通じて、現在では10以上のアクションでも適切に機能することがわかっています。ただし、一つのエージェントに過度の責任を持たせないよう注意する必要があります。
スーパーバイザーの設計においては、チャットメッセージがオーケストレーションレイヤーに到達した際の意図の判断が重要です。要求がボットのスキルセット外である場合、ユーザーがフラストレーションを感じている場合、人間への対応をエスカレーションするよう要求している場合などを適切に判断する必要があります。私たちの場合、「Hi team」で始まるメッセージや、サポートチャンネルでのアナウンスなど、アクションが不要なメッセージは、アクションが必要になるまで無視するようにしています。
エージェントの役割分担については、これまでに5つの異なるエージェントを実装しています。各エージェントは、ドキュメントの提供、ユーザー管理、リポジトリ管理、パイプライン障害の分析、他のエージェントの応答の評価など、非常に具体的な責任領域を持っています。Mark Royが説明したように、一つのエージェントに多くのアクションを詰め込むと混乱が生じるため、複数のエージェントに分散させることが重要です。
現在、私たちはマルチエージェントコラボレーションへの移行を楽しみにしています。この移行により、コードベースが大幅に簡素化され、エージェント間の連携がより効率的になることを期待しています。また、仮想エージェントとして実装している特別なケース（エスカレーションやメッセージの無視など）も、マルチエージェントコラボレーションに移行することで、よりエレガントに処理できるようになるでしょう。
5.2. セキュリティと規制対応
Heiko Zuerker： 私たちは規制された金融業界で事業を展開しているため、セキュリティと規制対応は最も重要な課題の一つでした。BedrockのGuardrailsを積極的に活用し、誤用や乱用からの保護を実現しています。具体的には、潜在的なPII（個人を特定できる情報）やその他の機密情報に対する保護、ユーザーが誤ってチャットにパスワードを投稿してしまった場合などの自動的なマスキング、そしてチャットで管理するのに適切でない内容や悪意のある意図からの保護を実装しています。
特に重要なのは、AIが直接アクションを実行することに関する厳格な社内規制への対応です。リスクパートナーと協力して開発した解決策では、エージェントがユーザーに対して実行予定のアクションを正確に説明し、明示的な「yes」または「no」での確認を必要とするようにしました。これにより、AIの行動に対する適切な監督と制御を確保しています。
また、AWS上で実行されることで、きめ細かいアクセス制御の管理、組み込みの暗号化、HIPAAコンプライアンスなど、エンタープライズグレードのセキュリティ機能を活用できます。これらの機能は、当社のような規制の厳しい業界で事業を展開する企業にとって非常に重要です。
ノイズをユーザーから遠ざけ、誤った情報生成（ハルシネーション）からユーザーを保護することにも力を入れています。応答率は低くなりますが、良好なユーザー体験を維持することを優先しています。一度ユーザーの信頼を失うと、それを取り戻すのは非常に困難だからです。
5.3. 学習した教訓と推奨事項
Heiko Zuerker： この実装を通じて、私たちはいくつかの重要な教訓を学びました。最も基本的なことですが、データについては依然として「garbage in, garbage out」の原則が当てはまります。GenAIにおいても、適切にキュレーションされたドキュメントがなければ知識ベースは効果的に機能しません。これはGenAIだけに限らない普遍的な真実です。
クロスリージョン推論の使用は、最初から導入すべき重要な機能です。単に異なる推論プロファイルIDを提供するだけで、複数のリージョンのパワーを活用でき、システムの安定性を大幅に向上させることができます。これを使用しない理由はありません。
モデルを使用する際は、必ず決定の説明を求めることが重要です。これによりデバッグが格段に容易になります。また、エージェントに割り当てるアクションの数を制限することの重要性も再確認されました。
ユーザーからノイズを遠ざけることも重要な学びでした。ハルシネーション（誤った情報生成）をユーザーから遠ざけ、良好なユーザー体験を提供することを優先しています。そのためボットの応答率は低くなりますが、メッセージのフィルタリングに重点を置いています。
観測可能性は非常に重要です。システムの技術的な問題やLLMとユーザーの間のやり取りを監視するための良好なフィードバックメカニズムが必要です。また、情報の正確性を確保し続ける必要もあります。私たちの場合、ユーザーの行動が変化し、パイプライン障害の分析の必要性が生まれたように、システムは継続的に進化する必要があります。
マルチエージェントコラボレーションは、開発の方法を大きく変えようとしています。より速く、よりシンプルになり、多くの利点があります。私たちのソリューションをマルチエージェントコラボレーションに移行し、コードベースがどのように簡素化されるかを見るのが待ちきれません。
6. マルチエージェントシステムの構築方法
6.1. スーパーバイザーエージェントの設定
Mark Roy： マルチエージェントシステムを構築する際の最初のステップは、スーパーバイザーエージェントの設定です。たとえば、お客様の体験を統一する場合、スーパーバイザーを設定し、一連のコラボレーターを指定し、そこにマルチエージェントソリューションを構築します。これにより、ユーザーは任意の質問をすることができ、スーパーバイザーが即座に適切な場所にルーティングし、別のアプリケーションに移動することなくシームレスな会話を続けることができます。
スーパーバイザータイプの設定は非常にシンプルです。まず、複数のコラボレーターを用意し、それらの周りにスーパーバイザーエージェントを作成します。その後、どのタイプのスーパーバイザーなのかを指定するフラグを1つ設定します。今回の例では、ルーターのスーパーバイザーとして設定します。
次に、各コラボレーターを使用するシナリオを簡単に説明します。そしてエージェントを呼び出すと、この組み込みの最適化されたルーターが、コードを書くことなく意図分類を実行します。ユーザーからのリクエストがエージェントに届くと、そのコンテキストがルーターに渡され、ルーターが決定を下し、それで完了です。
これは1秒未満で実行されます。自前でこれを構築しようとすると、おそらく3〜4秒かかるオーケストレーションループを実装する必要があり、しかもそれを自分で構築しなければなりません。ここでは1秒未満で、ルーティングに使用するモデルも選択できます。また、複数のサブエージェントにまたがる質問に対しては、ルーターは単一のエージェントを選択するのではなく、スーパーバイザーとして計画を立て、複数のコラボレーターと連携して回答を生成します。
6.2. コラボレーターの定義と統合
Mark Roy： コラボレーターの定義と統合において、まずYAMLファイルで5つのコラボレーターを宣言的に定義します。各コラボレーターには名前と役割、そして簡単な指示セットを与えます。これらのコラボレーターは、リードマーケットアナリスト、チーフストラテジスト、コンテンツライター、クリエイティブディレクター、フォーマットされたレポートライターなど、それぞれ特定の専門性を持っています。
相互作用のパターンについては、例えばコンテンツライターとクリエイティブディレクターの間で行われる反復的な改善プロセスのように、コラボレーター間の協調作業を定義します。一方のエージェントが作業を行い、もう一方がそれを評価してフィードバックを提供し、適切な品質スコアに達するまでこのプロセスを繰り返します。
メモリと状態管理については、プロトタイプでは簡単なset keyとget keyのツールセットを実装しました。これはDynamoDB上の単純なLambdaラッパーですが、すべてのコラボレーター間で作業メモリとして効果的に機能します。例えば、市場調査の結果や戦略の決定事項、キャンペーンのアイデアなど、各サブエージェントが処理の過程で情報を保存し、他のエージェントがそれを取得して利用することができます。
スーパーバイザーへの簡単な指示で「作業メモリを追跡してください」と伝えるだけで、コラボレーター間での情報共有が可能になります。これにより、複雑な処理を必要とするタスクでも、各エージェントが自身の専門性を活かしながら、他のエージェントの成果を活用して効率的に作業を進めることができます。
6.3. YAMLによる設定方法
Mark Roy： 実際のコードを見てみましょう。まずYAMLファイルで5つのコラボレーターを宣言的に定義します。各コラボレーターには名前、役割、そして簡単な指示セットを与えます。スーパーバイザー自体に対しては、コラボレーションタイプを定義します。今回の例では「supervisor」（ルーターとは異なり）を指定し、コラボレーターのリストを提供し、どのように協力すべきか、いつ使用すべきかについての簡単な説明を加えます。
タスク定義については、YAMLファイルで7つのタスクを定義しました。各タスクには名前、説明、期待される出力があります。このタスクリストをスーパーバイザーに渡して「実行」を指示するだけです。
メインのPythonファイルでは、まずYAMLを開いて7つのタスクをインスタンス化します。次に、既存のLambdaに基づいてWebSearchツールを作成します。どのようなアクションがあり、どのようなパラメータを取るのかを記述します。エージェントはこれを使用して次に何をすべきかを判断します。
また、前述の作業メモリツールもあり、setValue（値の設定）とgetValue（値の取得）の機能があります。各コラボレーターがこれにアクセスできます。その後、5つの異なるコラボレーターをインスタンス化し、スーパーバイザーを作成してコラボレーターのリストを渡します。
これで基本的な設定は完了です。次のコード行は単にスーパーバイザー.invoke(tasks)を呼び出し、結果を出力するだけです。このように、YAMLベースの設定により、マルチエージェントシステムの構築と管理が非常にシンプルになります。
この完全なソースコードは、QRコードを通じて提供されるAmazon Bedrock Agentのサンプルライブラリで入手できます。住宅ローンアシスタント、スタートアップアドバイザー、さらにはスポーツチームの詩作成など、約12のマルチエージェントコラボレーションの例が含まれています。