re:Invent 2025: PrudentialのMCPとA2Aを活用したマルチエージェントプラットフォーム構築事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Building Prudential’s microagent platform with MCP and A2A on AWS (IND3302)
この動画では、AWS GenAI Innovation CenterとPrudential Financialが共同構築したMicroAgent Platformについて解説されています。Moon Kim氏、Rohit Kapa氏、Subir Das氏が、金融サービス業界における複数のAIエージェントを大規模にスケールさせる際の課題と解決策を紹介します。Life Insurance Advisor AI Assistantという具体的なユースケースを通じて、100,000人以上のアドバイザーが利用するマルチエージェントシステムの実装を説明。orchestration agent、quick quote agent、forms agent、product agentなどの専門エージェントがMCPとA2Aプロトコルを活用して連携する仕組みや、モジュール化されたアーキテクチャによる相互交換性の確保、集中型プラットフォームによるガバナンスの実現方法が詳述されています。ターンアラウンドタイムを6～8週間から3～4週間に短縮した成果や、今後のAgent Core採用を含む将来展望も語られます。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
金融サービス業界におけるGenAIの野心と課題：柔軟性とガバナンスの両立
みなさん、こんにちは。来ていただきありがとうございます。今週も良いスタートが切れていることを願っています。私は Moon Kim で、AWS GenAI Innovation Center のリード機械学習エンジニアです。本日は、MCP と A2A を使用した Prudential の MicroAgent Platform の構築についてお話しします。ここに来られて嬉しいです。Rohit と Subir と一緒にこのプラットフォームを共同構築できて、本当に幸運でした。詳細をお伝えできることを嬉しく思います。
まず、金融サービスと保険業界のお客様が直面している一般的な課題と、それらに対処するために取られているアプローチについてお話しします。その後、Rohit と Subir にバトンタッチして、Prudential について、そしてすべての事業部門にわたって AI イニシアティブを管理することの意味についてお話しします。また、Life Insurance Advisor AI Assistant という特定のユースケースと、それをサポートできるプラットフォームの構築方法についても説明します。その後、インパクトと今後の方向性について議論し、いくつかの重要なポイントで締めくくります。
特に FSI 業界内の企業は、大きな野心を持っており、それはますます大きくなっています。GenAI には多くの機会があります。インテリジェント文書処理、エージェントを使用したデータ分析、顧客向けワークフローの簡素化などです。これらはほんの始まりに過ぎません。一部の企業は、ビジネスの一部として数千のエージェントを持つことを想定しています。市場のおかげで、彼らは緊急性を持って GenAI ソリューションを提供したいと考えています。彼らはゲームの最前線にいたいし、当然その一部になりたいのです。
当然のことながら、開発者とチームは柔軟性と自律性を望んでいるため、POC を迅速に本番環境に持ち込むことができます。これらすべてが 1 つのエンタープライズミッションと一致する必要があります。つまり、ビジネス目標、制約、そして保護すべきブランドがあります。すべての GenAI ソリューションがガバナンス内にあることを確認したいのです。
複雑化するエージェント実装とモジュール性の必要性：AWS GenAI Innovation Centerのアプローチ
多くのお客様が最終的に行うことは、1 つのリポジトリ内に複数のソリューションと複数のエージェント技術ソリューションを構築することです。それは 2～3 年前に RAG アプリケーション用に開発した同じリポジトリかもしれません。しかし、エージェントが多すぎると、これは崩壊し始めます。そして、何かが多すぎるということもあるのです。
Agent の実装が複雑に絡み合って、いくつかのコンポーネントが共有されるようになると、所有権の境界が曖昧になってしまいます。1行の変更を加えるだけで複数のチームからセキュリティアラートが発火して、デプロイメントに数分ではなく数日かかってしまうケースも見てきました。また、PII や PHI のような機密データを適切に管理するのも難しくなります。なぜなら、それぞれのデータに対して特別なロジックが必要になる可能性があるからです。さらに、ユースケースとプラットフォームが時間とともにスケールしていくことを確保することは、長期的な成功にとって非常に重要です。
ソリューションは最新の GenAI トレンドに適応する必要があります。毎週のように新しいテクノロジーが出てきますし、それがあなたのソリューションに合致するかどうかを確認したいですし、もし合致すれば、それを適用できるようにしたいですよね。最適なパフォーマンスを維持するために、モデルやプロンプト、そして時には実装そのものを更新する必要があります。そうすることで、推論機能などの新しい機能を採用することができるようになります。
当然のことながら、アーキテクチャの転換は避けられません。ビジネスロジック、ランタイム実行、ガバナンス、スケーリングといった関心事を分離するために、いくつかのコンポーネントを取り出して分けたいのです。だからこそ、モジュール性が重要なのです。
モジュール性により、関心事を分離して、必要に応じてコンポーネントを簡単に入れ替えることができます。Runtime、Memory、Code Interpreter、Browser Tool といった主要なコンポーネントを特定することは、大きな効果があります。これにより、業界の変化に適応して素早く動くことができるようになります。
成長には必ずガバナンスが伴う必要があります。そうすることで、 一元化されたプラットフォームを使って安定化させることができます。エンタープライズは、ユーザーとエージェントのアクセス制御をリソースに対して管理する必要があります。また、ソリューション全体を統治し、監視して、開発者と AI エージェントが標準とポリシーに従っていることを確認する必要があります。これが、AWS GenAI Innovation Center の私のような立場の人間が、特に Prudential のようなお客様が、スケーラブルで将来に対応できるプラットフォームを構築するのをお手伝いする理由です。 私たちは、問題を特定して、ベストプラクティスを共有することから始めます。そして、ソリューションを構築して、お客様の環境内で本番環境に持ち込みます。
Prudential Financialのビジネス構造とAI活用の全体像：3つのビジネスユニットと共通課題
では、ここからは Rohit に引き継ぎたいと思います。Rohit は Prudential がどのように AI エージェント技術プラットフォームをスケールしているかについて話します。 みなさん、こんにちは。Prudential のデータサイエンス担当 VP の Rohit Kapa です。Prudential がどのような企業かご存じない方のために説明すると、Prudential Financial はアメリカの金融サービス企業で、保険、リタイアメント、投資管理などを提供しています。私たちは世界中の個人および機関投資家向けのビジネスに対応しており、40 以上の国で事業を展開しています。
当然のことながら、Prudential のような規模と大きさを持つエンタープライズでは、顧客はパーソナライゼーション、スピード、信頼、優れたカスタマーサービスなど、さまざまなことに対して異なる期待を持っています。これが大規模な金融サービス企業である Prudential に対して顧客が持つ高い基準であり、一般的な期待値です。では、私たちが持つビジネスをより詳しく見て、AI がこれらの課題にどのように対処しているかを見ていきましょう。
先ほど述べられた、典型的な FSI エンタープライズが直面している課題に関連付けながら、Prudential の観点から、それが AI ユースケースと AI ユースケースのスケーリングにとって何を意味するのかについて、見方を共有したいと思います。全体的には、このスライドはさまざまな課題と AI が提供できる機会を表すマトリックスです。 Prudential には 3 つの異なるビジネスユニットがあります。リタイアメント、グループ保険、生命保険です。このセッションでは投資管理については話していませんが、これらが US ビジネス内の 3 つの主要なコンポーネントです。
これらのビジネスユニットのそれぞれを見ると、ビジネス機能という観点では、おそらく性質は似ています。すべてのビジネスユニットは、流通と営業、引受と リスク、顧客とクレーム対応、そして製品開発とマーケティングを持っています。すべてのビジネスユニットが独自の革新的な製品や異なるカスタマージャーニーを持っていますが、それぞれが同様の種類の課題を抱えています。流通と営業の観点では、アドバイザーのワークフローが断片化されており、パーソナライゼーションが限定的です。引受とリスクの観点では、引受が手作業で遅く、リスクモデルが硬直的です。カスタマーサービスとクレーム対応の観点では、サービスコストが高く、クレーム処理には通常より長い時間がかかります。製品開発の観点では、イノベーションサイクルが遅く、マーケティングの観点では、キャンペーンが一般的で、コンバージョン率が低いです。
これらは潜在的な課題であるだけではなく、これらの異なる機能全体にわたって、一般的な金融サービスの課題に関連付けることができます。AI の成果またはゴールの観点から、ビジネスが前に進もうとしている場所を見ると、AI はどのようにして営業支援ツールとしてスケール時にハイパーパーソナライズされたアドバイスを作成できるでしょうか。影響の観点から見ると、これらの AI ソリューションを、これらのビジネス機能のそれぞれに対して構築しようとすると、それらは組織内で働いている人々に直接影響を与えます。
例えば、流通・販売の領域では、ハイパーパーソナライズされたアドバイスを構築したい、より良い営業支援プロセスを構築したい、あるいはネクストベストアクションモデルを構築したいのであれば、これらは直接的にアドバイザーやブローカーに影響を与えます。同様に、リアルタイムのリスク評価について、これを構築したいのであれば、これは直接的にアンダーライターとリスク分析者に影響を与えます。カスタマーサービスとクレーム対応の観点からすると、AIがセルフサービスプロセスの作成や自動クレーム振り分けを支援できるのであれば、これらは直接的にコールセンターエージェントとクレーム専門家に影響を与えます。製品開発について考えると、AIを活用した市場インサイトやパーソナライズされたライダーや製品内に構築するソリューションを作成しようとするのであれば、これらは直接的に製品開発と製品管理の担当者に影響を与えます。あるいは、実際にはアクチュアリーに影響を与えます。マーケティングについても同じことが言えます。
つまり、ここで見えてくるのは、すべてのビジネス機能にはAIを使って解決できる一連の課題があり、そのAIの目標や成果は、各機能内で働く人々に直接的な影響を与えるということです。これがビジネス戦略です。これが私たちが価値を見出しているところです。
Life Insurance Advisor AI Assistantのユースケース：アドバイザーの業務フローと課題
そして、これが業界が向かっている方向です。本日のディスカッションでは、流通・販売に関するこのようなユースケースの一つを共有したいと思います。また、生命保険事業向けのAIファイナンシャルアドバイザーをどのように実際に活用しているかについてお話しします。私たちは、アドバイザーがパーソナライズされた、より良い営業支援と、現在よりも優れたプロセスを提供するのを支援しようとしています。
Agentic AIはこれらすべてを全体的に提供できますが、私たちは価値の観点からこれらすべてを提供できることを期待しています。最大の質問は、時間とともにスケールできるのか、本当にこれだけ多くのユースケースでスケールできるのか、これらは現実的なのかということです。これらはより大きな質問ですが、このユースケースについて直接的に深掘りしていきたいと思います。
Life insurance advisory assistantと言う場合、アドバイザーの視点から注意したい点が一つあります。生命保険キャリアの観点から、アドバイザーが日々何をしているかを分解すると、アドバイザーは通常、見込み客に対するクライアントエンゲージメントに従事しています。ニーズ評価とソリューション設計を行う必要があります。どの種類の製品がより適切かを特定し、クライアントにイラストレーションを表示し、販売しようとします。例えば、このような製品は30歳または50歳の人に良いかもしれないと言うかもしれません。また、別のIULのような製品を検討するかもしれません。
クライアントがどれだけのメリットを得られるかを示す、異なるプロダクトプレゼンテーションとイラストレーションをクライアントと共有する必要があります。そしてクライアントが同意したら、アドバイザーは通常、アプリケーションと引受サポートに進めます。そこではアプリケーションに記入したり、生命保険に申し込んだり、ポリシーを受け取ったりする必要があります。そしてポリシーを受け取った後は、そのポリシーの10年、15年、または20年間にわたってサービスとフォローアップを行う必要があります。
アドバイザーが日々行うこの全体的なエンドツーエンドループを見てみると、5つか6つの異なるステップがあります。各ステップで、アドバイザーは1つの特定のシステムにログインするか、バックエンドで1つの特定のITシステムを扱う必要があります。全体的に何が起きているかというと、アドバイザーの視点からすると、1つのキャリアに対してこれを行う必要があり、アドバイザーが5つか6つのキャリアと連携している場合、50個か60個の異なるITシステムと相互作用する必要があります。
これはアドバイザーの本当の価値ではなく、おそらくファイナンシャルアドバイザーが行うべきことの価値チェーンを壊しているのです。理想的には、彼らは良いアドバイスを提供するか、おそらくクライアントが何かを提供するのを助けるべきです。彼らが最終的にやっていることは、複数のバックエンド操作と絡み合っており、それが彼らをより良い方法で助けるかもしれません。これには、すべての異なるツールとシステムを見ることが含まれ、アドバイザーはポリシーの人生の10年、15年、または20年間、クライアントとの長期的な相互作用を維持する必要があります。
プロセスで起きていることは、10年前に始めた最初のクライアントに対して、彼らはおそらくコンテキストを忘れてしまうということです。10年前に実際に何について話したのか、なぜその特定のアドバイスを与えたのか、そして定期的なレビューベースで何が起きているのかということです。これらはアドバイザーが通常直面している問題であり、AI アシスタントの観点からこれをどのように解決しようとしているかをお伝えします。
マルチエージェントシステムによる営業・流通プロセスの変革：オーケストレーションエージェントとサブエージェント
これは advisory assistant、ファイナンシャル advisory assistant をどのように構築するか、そしてそれがどのように流通と販売プロセスを変革しているかを示す観点からのビューです。スクリーンの左側に見えているのは、今日の元のエクスペリエンスです。今日と言うと、それは過去のエクスペリエンスであり、アドバイザーは 異なることのために異なるシステムにログインする必要がありました。
左側に見えているのは、QuickCodes上での手動プロセスです。QuickCodeというのは、より非公式なプロセスのようなもので、例えば人々がアドバイザーに連絡したり、アドバイザーが実際にキャリアに連絡して、「見込み客がいるんですが、糖尿病とか高血圧、あるいはがんといった医学的な状態があります。最高の見積もりを提供してもらえますか？」と言うようなものです。通常、リクエストに医学情報が含まれており、バックエンドで何が起こるかというと、キャリア側のアンダーライターが1～2日かけて、アドバイザーに1～2日で回答を返すということです。
これは、これらの見積もりの量が多く、アンダーライターがアドバイザーから来る多くのリクエストで埋まっているためです。これはプロセスに1～2日の遅延が発生するという大きな課題です。同じことが、フォームや製品関連情報の取得にも当てはまります。例えば、アドバイザーが顧客にアプリケーションに記入してもらいたいと考えていて、クライアントに税務上の利益のために1030交換に記入してもらうことを期待していたり、何らかのライダー特典や何らかの開示署名を取得したいと考えている場合、このフォームを見つける必要があります。
バックエンド側でカスタマーケアサービスのようなキャリアシステムに電話をかけるか、正しいフォームが何かを知るために10分間電話で待つか、手動システムで自分で検索して、これが機能するかどうかを判断しようとする必要があります。製品関連情報についても同じことが言えます。通常、保険商品は複雑な性質を持っています。特定の製品機能を特定のクライアントに適用できるかどうかを知りたい場合、多くの知識を持つ必要があります。
アドバイザーは製品スペシャリストにリクエストする必要があり、最良の状況でも10～15分かかります。左側のスペースの非効率性を見ると、アドバイザーが今日直面している重大な課題が見えます。私たちが行ったことは、右側でこれらのプロセスをAI駆動システムで複製することです。
マルチエージェントAIシステムにより、すべての情報をリアルタイムで移動中の財務アドバイザーに提供しています。私たちはアドバイザーエージェントを構築しました。これは自然言語駆動で、豊かなコンテキスト駆動の会話を備えたチャット体験を提供します。アドバイザーはワンストップリソースとして質問をすることができ、彼らが通常扱うさまざまな種類のインタラクションをリクエストできます。私たちが構築した基礎となる製品には、オーケストレーションエージェントが含まれており、これはアドバイザーの単一のエントリーポイントとして機能します。
orchestration agent は、advisor からのさまざまな種類の入力を受け取り、意図を理解し、コンテキストに基づいて複数の subagent にリクエストをルーティングします。これは非決定論的な性質を持っており、特定の状況に適応します。バックグラウンドの subagent には、quick quote agent、forms agent、product agent、illustration agent、および book of business agent が含まれます。各 agent は、advisor に正確な応答を提供するために訓練された専門的なエンティティです。
quick quote プロセスについて強調したいのですが、これは AI を使用して underwriter をレプリケートし、financial advisor に即座の決定を提供する方法を示しています。advisor が「糖尿病とがんのクライアントがいるのですが、医療見積もりをもらえますか？」というようなリクエストを受け取った場合、このチャットボットを使用できます。このチャットボットは、underwriting ドキュメントに基づいて follow-up 質問をするのに十分な知能を持っています。リスク観点から条件をどのようにリスク評価すべきかについての詳細な説明を含む数百のドキュメントで訓練されています。
このアプローチは、異なる保険会社の financial および underwriting 運用全体のリスク評価プロセスと相関しています。すべての underwriter はこのような種類のマニュアルを持っており、私たちはこれらのマニュアルをこれらの質問に自動的に答えるように訓練しました。私たちは、prompt optimization、validation を自動的に実行し、決定を下すために必要な情報のレベルを決定する training および validation パイプラインを構築しました。クライアントの前に座っている advisor がクライアントが糖尿病を持っていると言うと、bot は A1C 値、血糖値、糖の評価、およびクライアントが服用している薬についての follow-up 質問をすぐに尋ねます。
bot は糖尿病の観点からリスクレベルの評価を提供します。同様に、クライアントががんを持っている場合、bot は寛解日、実施された治療、化学療法、およびがんのステージについての follow-up 質問をします。bot は、これらの follow-up 質問を前後に尋ねるのに十分な知能を持っており、適切な決定を下すために advisor から必要な情報を収集します。forms agent も、さまざまな領域にわたる数百の異なるフォームに基づいて構築されており、advisor がオンザフライでフォームを取得できるようにします。
forms agent は、トランザクションのタイプと特定の州に必要な特定のフォームについての follow-up 質問をすることができます。product agent は、advisor がコンテキストの観点からより深い質問をすることができるスマート検索機能として同様に機能します。彼らはクライアントに利用可能な製品、存在する機能、および特定の機能をクライアントに適用できるかどうかについて問い合わせることができます。agent はこれらのクエリに基づいて応答を返します。
全体的には、サブエージェントを持つオーケストレーションエージェントを構築し、それらの間でコンテキストを共有しています。エージェントレベルでは、各エージェントとオーケストレーションエージェントレベルの両方で、機能的な観点からガードレールを確立しました。これらのガードレールは、無効なクエリ、サブクエリ、およびフォローアップを処理します。illustration と book of business エージェントに関しては、これらをエージェントを通じて提供される API として考えてください。
book of business は通常、アドバイザーの book を意味し、過去に彼らが成約させた数十万件のポリシーが含まれています。これらのエージェントは、次のベストアクション、特定のポリシーがどのようなものになるか、およびアドバイザーが彼らの book 内の特定のポリシーに対して取る必要があるアクションに関する情報を提供できます。
アドバイザーにとってこの全体を実際に管理することは本当に難しいので、私たちはこのプロセスを支援するためにエージェントを使用しています。全体的には、アドバイザーを支援するマルチエージェントシステムが見られます。私たちは今日、100,000 人以上のアドバイザーが実際にこれを使用しており、これはより多くのエージェントをこの上に追加できる基盤構造のようなものです。
これは、AI をどのように使用しており、生命保険内での営業と流通をどのように変革しているかの特定の例です。私たちが期待しているのは、前のスライドで、異なるビジネス機能全体で AI を推進したい場所の大きな全体像を見たことです。それが私たちの目標であり、同僚たちがここにいて、その目標に向かってどのように取り組もうとしているのか、そしてプラットフォームの観点から何が必要なのか、またはそこに到達するためにソリューションの観点から何が必要なのかを説明します。
マイクロサービスベースのアーキテクチャ構築：100,000ユーザーへのスケーリングとMCP・A2Aの実装
皆さん、こんばんは。私は Machine Learning Engineer のディレクターの Subir Das です。Rohit が説明したように、ここで既に開発されているユースケースとモデルの準備ができています。モデルの準備ができて、ビジネスがそのモデルを受け入れたら、私たちが直面した最大の課題は モデルを本番環境にデプロイする方法と、同時にスケールする方法です。
デプロイされたモデルは 100,000 ユーザーまでスケールできる必要があります。インテント駆動型のオーケストレーションをサポートできる必要があります。エージェント内のエージェントとコンポーネントは再利用可能である必要があり、同時にデプロイされるソリューション全体がセキュアでコンプライアンスに準拠している必要があります。これらが、この特定の承認されたモデルから出てきた課題でした。
このデプロイメントモデルに加えて、私たちは他のソリューションのスケーリング方法についても課題に直面しました。これが企業全体で再利用可能であることを確認するためです。 これが私たちのマイクロサービスアーキテクチャですが、その前に、時間軸でのスケーリングについて説明させてください。時間軸でのスケーリングというのは、生成 AI の領域では、情報とフレームワークが非常に急速に変化しているということです。
システムが特定のシステムの正確性、完全性、精度に対応するためには、同時に、プロンプト管理の観点から、コンテキストエンジニアリングの観点から、SDK、パイプライン、またはその他の新しいものが出てくるかどうかにかかわらず、そうした強化とフレームワークを活用したいと考えています。これが基本的に時間軸でのスケーリングの問題です。それに加えて、他のチームからも、ソリューション開発全体を民主化する方法について何かを見ました。これにより、これらの様々なエージェンティックソリューションの開発とデプロイメントを、プラットフォームへの最小限のタッチポイントに基づいて他のチームに提供することができます。
確かに、私たちはフレームワーク、パイプライン、ツール、そしてそこで使用されるテックスタックを標準化したいと考えています。これらの課題を抱えて、私たちは AWS Innovation Center に連絡し、スライドに表示されているマイクロサービスベースのアーキテクチャを開発しました。 このスライドでは、ユーザーが UI アプリと対話し、ユーザーのホームアクセスレベルコントロールに基づいて SSO 認証が行われるのが見えます。
ユーザーが認証されると、セキュアなトークンが生成され、その特定のトークンがエージェントレイヤーに渡されます。エージェントレイヤーはトークンを再検証します。トークンが検証されると、コンテキスト固有のウィンドウ ID が生成され、セキュアなトークンにマップバックされます。これら 2 つのペアリングがオーケストレーションエージェントに渡され、オーケストレーションエージェントがそれ全体を構築し、その特定のコンテキスト ID のペアを使用して、エージェンティックディスカッション全体のセッションとコンテキストエンジニアリングを維持します。
同じコンテキスト ID とセキュア ID がフォームエージェントに渡され、フォーム、プロダクト、その他のエージェントが LLM ゲートウェイを使用します。これは LLM にアクセスするための別のセキュアな方法で、レスポンスを取得するためのものです。エージェントがナレッジマネジメントを使用したい場合は、ナレッジマネジメントシステムを使用して関連ドキュメントを取得し、ユーザーに対してレスポンスを生成します。これらすべてが進行中で、このシステム全体が 100,000 ユーザーまでスケールアップするようにデプロイされています。
ここで見られた課題の一つは、この 100,000 ユーザーベースの周辺のコンテキストエンジニアリングで、セキュアトークンとコンテキストウィンドウ ID とペアになっているのですが、これが非常にチャレンジングになるということです。起こることは、モデルが典型的な意味では時々不明な理由でパフォーマンスを低下させるということで、このコンテキストエンジニアリングフレームワークをデバッグして、それを分離し、正確に何が起こったのかを見つけ出すことがこの環境では難しいということです。次のスライドでもっと詳しく話しますが、もう一つ追加したいコンポーネントは、これらすべてが進行中の間に、私たちは積極的にさらにエージェントを開発・追加しており、MCP ベースのツールアクセスおよびエージェントレイヤーの API アクセスのサポートも追加しているということです。
また、エージェントレイヤーにモニタリングとオブザーバビリティのサポートを追加しています。また、エージェントレイヤーに評価フレームワークを付与するサポートも追加しています。これが私たちの内部 エージェントのアーキテクチャのオーケストレーションです。前のダイアグラムは LM システム全体のデプロイメントアーキテクチャでした。これは基本的には特定のエージェント、それがどのようにアーキテクチャされているか、そして内部的にエージェントの異なるセグメント間でどのようにデータを共有しているかに集約されます。
左側の特定のリージョンでデータプレーンにアクセスし、その後 MCP と React フレームワークを使用していることがわかります。短期メモリおよび長期メモリアクセスのためのメモリマネジメント、そしてあるエージェントから別のエージェントに移動するための A2A プロトコルを使用しています。この特定のエージェンティックシステムが PlanProvision という退職マルチエージェントシステムや、別のマルチエージェントシステムである IDP のような他の異なるエージェンティックシステムに遷移してアクセスする必要がある場合、A2A プロトコルを使用します。
これに加えて、コンテキストエンジニアリングフレームワークが積極的に開発中であることがわかります。これは最近リリースされた ACE フレームワークに基づいており、私たちはこのレベルでスケールするために必要なコンテキストエンジニアリングを強化できるかどうかを正確に確認するために、これに対して積極的に開発しています。このような複雑性を維持し、時間とともにスケールし、MCP と A2A の実装を行うために、私たちの場所に来た唯一のソリューションは、プラットフォームベースのアプローチを取る必要があるということです。
エージェンティック・プラットフォームの構築：責任あるAIと価値実現までの時間短縮
これが私たちが構築したものです。エージェンティック・プラットフォームです。 ご覧の通り、従来のモデル空間は SageMaker inference によってサポートされており、エージェントは MCP 経由でこれを利用しています。GenAI 側では、知識管理システムのためのベクトル・ストアが利用可能な GenAI があります。また、Bedrock ベースのエージェントと LLM ゲートウェイがあり、エンタープライズのニーズに対応するための管理・評価フレームワークを積極的に開発しています。
このプラットフォームはエンタープライズ・サービスを利用しており、エージェント・オペレーションや GitHub Actions のためのものです。基本的に、DevSecOps 全体がエンタープライズ・サービスを通じて利用可能になっています。データのニーズについては、エンタープライズ・データに依存しており、インフラストラクチャとテック・スタックについては、AWS システム全体を使用しています。このプラットフォームは主にデータサイエンティストと機械学習エンジニアがモデルの開発とデプロイに使用しており、一方、消費者の観点からは、ビジネスユーザーとアプリケーションによって利用されています。
プラットフォームを構築し、プラットフォーム・ベースのアプローチを採用したので、 このアプローチを採用することで得られたいくつかのメリットをお伝えしたいと思います。直接的に得られたメリットの一つは、プラットフォーム・ベースのアプローチを採用しているため、責任あるAIをそのレベルで確保することができるということです。つまり、その上で実行されるあらゆるものが、この責任あるAIフレームワークを通じて処理されることができるということです。
同時に、利益の実現に重要な役割を果たす価値実現までの時間も達成することができます。何が起こるかというと、マルチエージェント・システムを開発してカスタムでデプロイする場合、共通レイヤーを共有することができません。つまり、毎回共通レイヤーを再構築する必要があり、共通レイヤーの再構築に多くの時間を費やすことになります。しかし、プラットフォーム・ベースのサービスを使用すれば、共通レイヤーの部分を共有することができます。
モニタリングとエージェント・モニタリング、評価の観点からは、エージェント・スパン全体を測定し、エージェント・トレーサビリティと可観測性を提供するのに役立つものを評価・デプロイしています。これで、Rohit に戻して、ビジネス成果と私たちが学んだ教訓をお伝えしてもらいたいと思います。
ビジネス成果と学んだ教訓：パフォーマンス向上への集中とコンテキストエンジニアリングの課題
Suvi が私たちがなぜプラットフォームを構築しているのかを説明してくれたので、皆さんはすでに私たちのビジネス上の野心がどこにあるのかを見ていますし、1つのユースケースがどのように異なるユースケースへと進化してきたのか、そしてなぜプラットフォームベースの構造がそこに到達するのに役立つのか、そして共通ソリューションの観点から agency care プラットフォームの一般的な利点が何なのかをすでに見ています。
このアプローチから得られたビジネス成果のいくつかをハイライトしたいと思いますし、その後、将来の観点から私たちがどこに向かっているのかについてより深く掘り下げたいと思います。ビジネスの観点から全体的に見ると、私たちは benefit realization が起こっていることを観察しています。これが起こっているのは、ターンアラウンドタイムと AI ユースケース自体から実際にビジネス価値を生み出すまでの時間という、私たちが直面している主要な課題のいくつかを削減することができているからです。ターンアラウンドタイムを 6～8 週間から 3～4 週間に短縮しました。
起こっていることは、foundational advisory assistant システムを構築した後、このシステムの上に複数のエージェントを追加でき、開発とデプロイメントの両方の観点から 4～5 週間以内に本番環境にデプロイできるということです。アドバイザーから来ているリクエスト、例えば特定の製品を product-related エージェント内に組み込みたいというようなリクエストに対しても、私たちは迅速に対応でき、スタンドアロンソリューションとしてデプロイできます。これはターンアラウンドタイムの観点から、そして既存の IT アプリケーションやワークフローとの統合能力の観点から私たちを支援しています。
同様に、standardized ソリューションについても、私たちは別の利点を観察しており、1つのユースケースから複数のユースケースへとスケールできるようになりました。私たちが見ているのは、特定のビジネスエリアで特定のユースケースを構築した場合、このような開発を他のビジネスユニット全体で再利用できるようになったということです。このアプローチからのもう1つの利点は、tech debt を削減していることです。マルチエージェントシステム内の多くのコンポーネントは市場で急速に変化しています。新しい context フレームワークが出現し、新しい A2A フレームワークが出現し、新しい SDK が登場しています。これらすべてのものが非常に急速に変化しており、私たちがそのペースに追いつくのは容易ではありません。プラットフォームの観点から standardized ソリューションセットを持つことは、より長期間にわたってアップグレードするのに役立っています。例えば、新しいモデルがリリースされた場合、または observability 関連のシステムで新しい変更があった場合、私たちはそれらの変更に対応することができます。
もう一つ観察していることは、ビジネスフィードバックです。私たちは、ゲームの早い段階でビジネスフィードバックを非常にうまく組み込むことができるようになりました。以前は、データサイエンティストやシステムを構築するエンジニアたちが、エージェントの構築だけでなく、マルチコンテキストの処理方法や、システムが開発環境からステージ環境やUAT環境へ移行する際の処理方法など、周辺コンポーネントにも焦点を当てていました。彼らは通常、開発からステージやUATへの移行時に多くの問題を目にしていて、スケールを考慮に入れると、物事は通常、崩れ始めていました。LLMのパフォーマンスが大幅に低下することが多かったのです。
今では、これらの多くの標準化されたソリューションにより、特定の問題をトレースしたりデバッグしたりして、より深く掘り下げることができるようになり、可観測性の観点からプロンプトのチェーンを理解し、ソリューションが本番環境に移行した後も監視することができるようになりました。これらのことがより簡単になってきています。ビジネスフィードバックを迅速に組み込むことができるようになり、これがAIシステムへのビジネス信頼を得るのに役立っています。実際には、これにより、他のすべてのエンジニアリング関連の側面を見るのではなく、パフォーマンスの観点からソリューションの開発に、より多くの焦点を当てることができるようになりました。これはおそらく私たちにとってより大きな成果です。なぜなら、今ではデータサイエンティストがパフォーマンスの向上に焦点を当てることができるからです。金融サービス、特に私たちが取り組んでいる分野では、パフォーマンスが重要な要素です。パフォーマンスの欠如は、通常、アンダーライターやユーザー、例えば、アドバイザー、アンダーライター、またはリスク担当者の観点から不信感を招きます。
全体的に、私たちが学んだ教訓をシェアしたいと思います。私たちが絶対に学んだことの一つは、エージェントがすべてのビジネス問題に適しているわけではないということです。私が言及したQuickodeのような問題の中には、それ自体がエージェント的なソリューションではないものもあります。むしろ、特定のタスクのために、複雑なLLMアプリケーションシステムを設計によって使用してアンダーライターを複製しようとしている、スタンドアロンのLLMアプリケーションのようなものです。同様に、IDPソリューションの構築を考えるなら、シンプルなIDPソリューションは、あなたが持っているいくつかのユースケースでは機能しないかもしれません。複雑な手書きや、エージェントに渡されている複雑な情報がある場合、おそらくそのための別のプロセスが必要になります。汎用的なエージェントシステムは機能しないかもしれません。
もう一つ私たちが観察したことは、私たちが構築しているソリューションは、エンドツーエンドのバリューチェーンの観点から構築する必要があるということです。例えば、多くのビジネスが解決しようとしている「not in good order」のユースケースを取り上げるなら、IDP関連の問題を解決するためにエージェントを構築しようとしても、それ自体では機能しないかもしれません。IDPソリューションを解決することはできるかもしれませんが、エンドツーエンドのバリューの観点からは、おそらくIDP自体の上に他のコンポーネントが必要になるか、またはNIGOプロセス全体を完全に実装して実行し、ビジネスバリューの利益を見るために、IDPプロセスの上にワークフロー管理の何らかの形が必要になります。ビジネスアラインメントとエンドツーエンドのバリュー創造は、実際には、これらのユースケースからのバリュー利益実現を得るのに重要です。
もう一つ私たちが学んだことは、エージェントのパフォーマンスに予測不可能な低下が起こるということで、本番環境でスケーリングしようとするときに頻繁に発生します。 従来的には、私たちは1つか2つの理由を観察してきました。1つはモデルのアップグレードが起こっていることで、これはおそらくエージェントが実際にどのように動作するかに影響を与えています。もう1つ私たちが観察したことは、あなたのトレーニングと検証データセットが、実際に外の世界で見ているすべてのケースを見ていないかもしれないということです。
また、メモリとコンテキストエンジニアリングがどの程度実際に機能するかについての問題もあり、これも問題です。これはおそらく私たちが解決しようとしている大きな側面の1つです。複数のアドバイザー、複数のアンダーライターへのスケーリングを検討しており、特にA2Aの観点から、別のシステムが構築したエージェントの一部を再利用しようとしている場合、コンテキストエンジニアリングは重要な課題になります。実際にそれをどのように維持するのか、実際にそれをどのようにログに記録するのか、デバッグやトレーシングをどのように行うのか、これらは私たちがこのような使用例を解決しようとするときに重要な側面になります。
将来の方向性、私たちがどこに向かっているのかについて話したいと思います。 私たちが感じたり、実現したりしたことの1つは、他のビジネスラインのエージェントとの統合がおそらく成功への重要な勝利であるということです。なぜなら、他のビジネスが解決している使用例の一部は、他のビジネスシステムでもそれらのエージェントの一部を再利用できるからです。その再利用可能性のコンポーネントを持つことで、実際に多くの問題に対処できます。
もう1つ私たちが観察したことは、メモリとオブザーバビリティに対する標準化されたアプローチを持つこと、そしてコンテキストエンジニアリングもまた、長期的にはスケーリングに役立つかもしれないということです。すべてのマルチエージェントシステムについて、独自のデータベース、独自のキャッシュメモリ、独自の短期、長期メモリ、または静的メモリを実際に再作成し、その周りにコンテキストエンジニアリングを構築することは難しいです。これは長期的にはスケーリングしないかもしれません。1つの特定のエージェントシステムに対して1つのパターンは機能するかもしれませんが、アドバイザリーアシスタントからおそらくリアルタイムシステムに切り替えたり、そこからIDPに切り替えたり、ある使用例から別の使用例に切り替えたりすると、スケーリングがはるかに難しくなります。
Agent Coreのようなもの、これは実際にこれらの機能の一部を組み込みで提供し、業界のほとんどが向かっている方向であり、もし彼らが実際にすべての基礎作業を行っているなら、おそらくこれをあなたのプラットフォームの一部として採用し、これらの機能をあなたのプラットフォームに組み込んで、あなたのシステムで再利用しようとする方が良いでしょう。これはおそらく長期的にはより良いアプローチです。非常に複雑なエッジケースまたは使用例がある場合は、おそらくそれを再エンジニアリングしようとすることができますが、すべての汎用的な使用例については、業界が向かっている方向に固執する方がおそらく良いでしょう。
将来の方向性と重要なポイント：3層アーキテクチャによるモジュール化されたプラットフォームのビジョン
では、これから AI エージェントをスケーリングしていく上での、時間軸とトレンドの観点から、マクロ的な視点でどこに向かっているのかをお話しします。 より大きな全体像が見えてきます。複数エージェントシステムに対して、私たちはより大きな野心を持っています。複数のエージェントを構築する必要がある場合、私たちが持っているもの、あるいは考えているのは、一番上にエージェント開発レイヤーを持つ必要があり、その下にコアプラットフォームレイヤーを持つ必要があり、そして一番下にエンタープライズサービスレイヤーを持つ必要があるということです。
エージェントレイヤーとは何か、そしてプラットフォームコアレイヤーとは何かについて説明します。あらゆる種類のエージェント構築の基礎となるであろう、いくつかのことを標準化する必要があります。一番上のレイヤーであるエージェント開発レイヤーで見ているのは、SDK を使用したり、異なるビジネス環境でフレームワークを使用したりすることで、エージェント構築の方法をサポートし、おそらく民主化するレイヤーです。データサイエンティストだけでなく、このようなフレームワークは、データサイエンティスト、ソフトウェアエンジニア、AI 愛好家が、エージェント的なソリューションであれ非エージェント的なソリューションであれ、自分たちのエージェントを構築できるようにサポートすべきです。
私たちの基本的な考え方は、人々が自分たちのマルチエージェントシステムを構築できるべきであり、プラットフォームの観点から一番上のこの特定のレイヤーは、実際にこれらのレイヤーをその場で構築することをサポートすべきということです。Deep Research Agent、IDP、コール要約、カスタマーサービス要約、画像認識などの機能は、すべてこのエージェントレイヤーの上に構築できます。
コアアイデアは、インタープリタ、実行、ブラウザツールなどのコアサービスを提供することです。これらのツールは、エージェントレイヤーとエージェント開発レイヤー全体にわたって、自動検出可能で再利用可能にする必要があります。このようにすることで、上層の人々は開発に専念でき、他のプラットフォームコンポーネントについて心配する必要がありません。
中央のコアプラットフォームは、その上に構築されるエージェント開発システムの基盤レイヤーになるべきです。コアプラットフォームは、集中管理された Bedrock 環境、コンテキストエンジニアリング環境、SageMaker Unified Studio と Enterprise data stack を備えた開発環境を処理すべきです。追加すべきコアピースの一部には、MCP gateway、A2A gateway、GAI gateway が含まれます。さらに、エージェント検出可能性、エージェント管理、エージェントレポートカード用のレジストリ、および MCP 管理用のレジストリを追加することを検討しています。
基本的に、プラットフォームレイヤーの上に構築されたエージェントは、コア機能を活用し、エージェント設定パターン、エージェントレジストリパターン、エージェントの発見、パフォーマンスの識別、そしてエージェントのデプロイメントを採用することになります。コアプラットフォームは、コアサービスをモジュール方式で提供するための基盤レイヤーになります。これらのモジュール化されたソリューションにより、上位レイヤーのユーザーは大規模にデプロイできるようになります。エージェント監視、エージェント開発、デプロイメントフレームワーク、そしてそれらのフレームワークを下層から再利用して上層にデプロイできます。
私たちは2つの異なるレイヤーを想定しており、インフラレイヤーが中央に位置し、Splunk サービスなどのエンタープライズインフラストラクチャサービスが全体の基本レイヤーとして最下部に位置しています。これが、ハイブリッドなモジュール化されたプラットフォームがどのように形成され、長期的には異なるビジネス機能のための複数エージェントシステムを構築するという野心を実現するのに役立つかについての私たちのビジョンです。
それでは、Moon に戻して、結論と重要なポイントをお願いします。もうすぐです。Rohit、ありがとうございます。終わる前に、3つの重要なポイントがあります。3つに絞るのは本当に大変でしたが、まず第一に、時間とともにスケーリングすることは簡単ではありません。誰もが今日、Kubernetes やその他のスケーリングプラットフォームでスケーリングできますが、時間とともにスケーリングするには、将来に向けてどのように準備するかについてより深く考える必要があります。最新の AI トレンドが何であるか、そしてパフォーマンスを最適に維持する方法を理解することは、ソリューションをモジュール化する必要があることを意味します。モジュール性は長期的な成功の鍵です。
これにより、最初のポイント、相互交換性の確保が可能になります。相互交換性により、ビルディングブロックを持つことができ、必要に応じてより良いものと交換できます。また、関心事を分離して、各ユニットが独立して動作し、独立してスケーリングできるようにすることも意味します。最後に、成長を安定させるための集中型プラットフォームを持ちたいと考えています。Rohit が言ったように、複数のレイヤーが必要です。1つはコアレイヤー、その上に分散レイヤーです。これにより、ガバナンスを提供し、チーム間および AI ソリューション間のサイロを防ぐことができます。また、AI ソリューションがプラットフォーム内でプラグアンドプレイできるようにします。それでは、スライドはここまでです。ご質問をお受けします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion