re:Invent 2025: 生成AIとエージェントアプリの大規模展開を支えるWell-Architected基盤の構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Build a well-architected foundation for scaling generative AI and agentic apps
この動画では、AWSのChaitra、Aamna、そしてSageのDaveが、生成AIとエージェントアプリケーションを本番環境に大規模展開するための包括的な基盤について解説しています。Model hub、Agent hub、Tools hubを中核とし、gateway、orchestration、observabilityの3つの柱で構成される基盤アーキテクチャを提示。Amazon BedrockとBedrock AgentCoreを活用した実装方法、LiteLLMを使用したLLM gateway、AgentCore Gatewayによるツール統合、Langfuseでのトレース収集とオフライン評価の実装をデモで紹介しています。SageはAgent Meshアーキテクチャを採用し、200以上の製品にまたがるエージェント連携を実現。Functional quality、cost、latency、riskの測定、golden datasetを用いた継続的評価、DevOpsパイプラインへの統合など、AgentOpsの実践的なアプローチが詳述されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
月曜朝のセッション開始：生成AIアプリケーションの本番展開への挑戦
おはようございます。本日はご参加いただきありがとうございます。私は月曜日の朝のセッションが好きなんです。なぜなら、私たちはまだ新鮮で、週の初めで、他のことに影響されていないからです。まだ興奮と期待に満ちているので、これは良い時間帯です。ご参加いただき嬉しく思います。私の名前は Chaitra で、AWS の GenAI スペシャリストです。本日は、同僚の Aamna が一緒に参加しています。
皆さん、こんにちは。私は Aamna で、生成 AI のシニアスペシャリストソリューションアーキテクトです。また、AWS のお客様である Sage の Dave も参加しています。
こんにちは。私は Dave Senior で、アイルランドのダブリンを拠点としており、Sage の Central Services チームのデータと AI の責任者です。私たちはプロダクト組織の一部であり、私たちが構築するすべてのものはカスタマーフェーシングです。
ありがとうございます。では、今日はなぜここにいるのでしょうか？何を学ぶのでしょうか？これは数年前にチャットボットで起こり始めたことです。非常にシンプルに見えます。プロンプトを入力すると、レスポンスが返ってくる。それが始まりでした。
しかし、実際にはそれよりもはるかに複雑であることを私たちは知っています。オーケストレーション、エージェント、RAG、そしてセーフガードの適用があります。つまり、LLM がすべてを生成するだけではないということです。こう想像してみてください。以前は1つのアプリケーションについて話していました。今、私たちはこれらの多くをプロダクションに投入しようとしている段階にいます。では、ここでのいくつかの課題と複雑さは何でしょうか？これは簡単な仕事ではなく、本当に複雑です。
これが今日のこのトークで取り組もうとしていることです。生成AIとエージェントアプリケーションを本番環境に、さらには大規模に展開するための強固な基盤がどのようなものかを見ていきます。私たちが定義した包括的な基盤があるのですが、今日はその中のいくつかのレイヤーに深掘りして、詳細を見ていきます。その後、Aamnaが開発した基盤のデモを見て、実際にどのような見た目なのか、そしてこれらの基盤をすべて組み合わせ始めるとどうなるのかを確認します。その後、Daveからエージェントメッシュプラットフォームを構築した彼らのジャーニーについて聞きます。エージェントの運用について見て、最後にまとめます。持ち帰ってもらえるようにいくつかのリソースをお見せします。
本番環境への移行が困難な理由：エージェントならではの技術的課題
生成AIまたはエージェントのいずれかのProof of Conceptを開発したことがある人、手を挙げてもらえますか？いいですね。本番環境に持っていくことについてはどうですか？思ったより多いですね。それが全部AWSの上だといいんですが。ですから、これが簡単ではないことは分かっています。スケールが課題であることはすでに理解していました。しかし、わずか数個のアプリケーションを本番環境に持っていくことさえ課題なのです。クラウドに物を持っていくことと本番環境に持っていくことに関して、これまで話してきたすべての課題はここでも有効ですが、それ以上のものがあります。
パフォーマンスの観点から、エージェントは単なるリアクティブではありません。理由は、彼らは計画を立て、拡張されたセッションの中で行動するからです。ですから、低レイテンシーとパフォーマンスが重要であり、これは本当に難しい最適化の課題です。スケーラビリティ：数千のエージェントを本番環境に投入する場合、目的別に構築されたオーケストレーションと、そのスケールに対応するための目的別に構築されたインフラストラクチャを検討する必要があります。これらのエージェントは機密データにアクセスしており、機密データへのアクセス権を持つツールにアクセスする可能性があります。ですから、適切な分離制御とアイデンティティ制御がない場合、小さなエラーでも壊滅的な問題を引き起こす可能性があります。これらのエージェントはコンテキストが必要であり、進化するコンテキストが必要です。定期的に、そして大規模に更新する必要があり、セキュアである必要があります。このメモリはセキュアである必要があります。これはもう一つの技術的課題です。スケールし、セキュアなメモリを提供することです。生成AIアプリケーションを構築するまで、セーフガードを適用することはガードレールで十分でした。しかし今、エージェントでは、継続的に監視し、継続的に評価し、継続的に監査し、場合によっては人間の監視を置いて、これらのエージェントが整合しているようにする必要があります。わかりました、これが非常に複雑であることは誰もが理解しています。では、何を言っているのか？強固な基盤を整備すべきだと言っているのです。それはどういう意味ですか？
包括的な基盤アーキテクチャ：共有サービスから運用まで
二つの見方ができます。一つは、一つまたは複数のアプリケーションを構築していて、基盤となるアーキテクチャを整備したいという場合です。もう一つの見方は、プラットフォームチームまたはITチームであり、中央プラットフォームを整備していて、異なるビジネスラインやチームをオンボーディングしているという場合です。それはどのような見た目ですか？ここで詳細には説明しませんが、別のスライドでより詳しく説明しています。基本的な考え方は、コンポーネントを統合し始めて、共有サービスを提供するということです。
共有サービスを中央集約的なガバナンス管理と共に提供すれば、あらゆるポリシー、コンプライアンス、セキュリティ対策を実装しながら、同時にコスト効率化も実現できます。共有サービスの一例としては、モデルカタログが挙げられます。アプリケーションを構築するチームがそれぞれ独自のモデルカタログを保守するのではなく、それを中央の場所にプラットフォーム提供として置いて、これらのアプリケーションを構築するすべてのチームがアクセスできるようにするわけです。
では、それはどのような形になるのでしょうか。私たちが言っているのは、包括的な基盤ということです。その中核にあるのは hub で、model hub と agents と tools hub です。そして、gateway を通じてこれらへのアクセスを提供します。これらの agent を構築したり、モデルをカスタマイズしたり、ツールを構築したりする際には、実行環境と、これらをホストするための runtime が必要になります。
データはサイロ化されていたり、data lake や data warehouse に存在していますが、これらのアプリケーションを構築するために、すべてのデータが必要というわけではありません。このレイヤーは、ingestion pipeline を構築したり、indexing pipeline を構築したり、そのデータを取得して vector store に入れたり、agent のための長期・短期メモリストアを持つことに関わっています。
その上にあるのが orchestration です。Orchestration というのは、これらすべてのコンポーネントへのアクセスを持つことであり、本当にフローを構築することです。それは workflow かもしれません。つまり、既知の一連のステップで、クエリを実行したり、モデルを呼び出したり、別のプロンプトを追加したり、異なるモデルをチェーンしたり、RAG アーキテクチャを構築したりすることです。Agent を含むこともできますが、それが必ずしも基盤の一部であるという意味ではありません。ただし、テンプレートを提供したい場合は、orchestration レイヤーが重要なレイヤーになる可能性があります。例えば、RAG テンプレートを提供して、みんなが使えるようにしたいのであれば、それを orchestration レイヤーに置くのは良い場所です。
その後、すべてのこれらにアクセスするクライアントがあります。3 つの最も重要な柱を忘れてはいけません。operational excellence、observability、security です。Observability は、これらがブラックボックスであるため、何が起こっているのかについての洞察を得るために非常に重要です。本当のところ、内部で何が起こっているのかをどのようにして知ることができるのでしょうか。Operations というのは、基盤そのものを運用することだけではなく、この基盤の一部としてこれらのアプリケーションに提供するもの、つまり、それらを運用化するのに役立つものについてです。例えば、prompt management store のようなもので、プロンプトテンプレートを保存・バージョン管理して、基盤の一部として、それを消費するアプリケーションとチームが使用できるようにすることです。
Amazon BedrockとBedrock AgentCore：基盤構築を支えるマネージドサービス
セキュリティ、データプライバシー、データ分離についても忘れてはいけません。見た目は大きなテーマに見えるかもしれませんが、いくつかの部分に深掘りしていきます。レイヤーについて説明する前に、お話ししたい2つのサービスがあります。1つ目は Amazon Bedrock で、これは生成 AI アプリケーションを構築できる完全マネージドサービスです。最先端のモデルにアクセスでき、ファーストパーティとサードパーティの両方があります。異なる消費モードがあるため、コスト効率的にスケールでき、レイテンシー、コスト、精度のバランスを取るための多くの機能があります。自分のデータでモデルをカスタマイズしたり、RAG アーキテクチャを構築したりでき、Guardrails 機能を使ってガードレールを適用できます。
もう1つお話ししたいサービスは その基盤を構築するのに役立つ Amazon Bedrock AgentCore です。ご存知かもしれませんし、そうでないかもしれませんが、これは数週間前に GA になったもので、エージェントを構築・スケールするための多くのマネージドサービスを提供する完全マネージドエージェントプラットフォームです。エージェントを構築・デプロイするための安全なランタイム、長期・短期メモリの管理、ツールにアクセスするためのゲートウェイ、そしてプラットフォームに組み込まれたトレースの全可観測性とインストルメンテーションを提供します。
この2つを組み合わせると、こんな感じになります。モデルカタログとゲートウェイについて説明した Amazon Bedrock があります。Bedrock はそのモデルカタログの要件を満たすのに役立ちます。次に、エージェントとツールをデプロイするためのランタイムについて説明しており、Amazon Bedrock AgentCore がそれを実現するのに役立ちます。Amazon Bedrock AgentCore の大きな利点は、Strands、Crew AI、LangChain、LlamaIndex のような多くの異なるオープンソースフレームワークを使ってエージェントを構築できることです。
それらをコンテナ化してランタイムにデプロイします。以上です。サービスがそれを管理してくれます。これは素晴らしいことです。
ゲートウェイの役割：LLM、ツール、エージェントへの統一アクセス
包括的な基盤がどのようなものかを見てきました。その1つについて深掘りしましょう：ゲートウェイです。いくつかのパターンが浮かび上がってきています。1つは LLM gateway と呼ばれるものです。これはしばらく前からあります。これはすべて、モデルカタログへの安全なアクセスを提供し、開発者が異なる API 仕様と異なるプロンプトテンプレートを持つ異なるモデルにアクセスすることについて心配する必要がないように、統一された API を提供することについてです。ゲートウェイはそのすべてを処理できます。
他に出現しつつある2つのパターンは、tool gateway と agent gateway です。これらが人気になってきています。tool gateway はアクションと統合をセキュアにして標準化し、レジストリが agents がアクセスできるツールの中央リポジトリとして機能します。同様に、agent gateway は agents へのアクセスを提供し、agent registry はデプロイされた agents とそのすべての機能とメタデータのカタログです。agents の登録と登録解除はすべてこのレジストリを通じて行われます。すべてが必要かどうかという質問があるかもしれません。必ずしもそうではありません。構築しているユースケースの種類によって異なります。
例えば、LLM gateway を見てみると、なぜ LLM gateway が必要なのでしょうか？モデルが Amazon Bedrock にあり、これは私たちのサービスですが、またはカスタマイズされたモデルを持っていて SageMaker に置いている場合、これも私たちのマネージドサービスの1つですが、または EKS でホストしている場合、またはそれが AWS 上にさえなく別のプロバイダーからの場合、開発者がこれらすべての異なるモデルにアクセスする際の摩擦を減らしたいのです。彼らにそれについて心配させたくありません。gateway がそのオーケストレーションを処理し、統一された API を提供します。ほとんどの場合、これらすべてのツールで見てきたのは OpenAI 仕様です。
私たちが見ている費用のほとんどはトークンコストであり、これをコントロールして属性付けしたいのです。gateway はコスト属性付けを行うことができます。ユースケースが来ると、どのユースケースが最も多くのトークンを使用していて、予算に最も大きな影響を与えているかを見ることができます。これらの異なるチームにレート制限を適用することができます。その方法は、これらの異なるチームまたはユーザーに API キーを配布し、その後、コストとすべてのアクションを追跡し始めることができるということです。
もう1つの大きな利点は、guardrails を適用できることです。例えば、企業全体で常に適用したい guardrails があるとします。これらのモデルにアクセスするアプリケーションを構築する誰もが、これらの guardrails を使用する必要があります。これはそれらを配置するのに最適な場所です。さて、私たちが示した基盤のすべてが、私たちがそれらのレイヤーのすべてに対してサービスを持っているという意味ではありません。いいえ、私たちはギャップを持っています。私たちが行ったことは、well-architected な方法で、AWS の外で利用可能で、セキュアで、コスト効率的で、信頼性の高いソリューション提供を展開する方法を示すソリューションを公開することです。
これは LiteLLM と呼ばれるオープンソースソリューションを使用しています。彼らは2つのバージョンを持っています：SDK とプロキシサーバーです。これはプロキシサーバーを取り、EKS または ECS に置き、デプロイします。LiteLLM は LLM gateway について私たちが話したすべての機能を備えています。これは単にそれを取り、コンテナ化して AWS にデプロイすることについてです。他にも多くのソリューションがあります。例えば、Kong AI Gateway がこれを持っており、Envoy、OpenRouter もあります。探索できるソリューションがたくさんあります。
質問は、もし1つのプロバイダーや1つのサービスのモデルにアクセスしているだけなら、これは必要ないかもしれません。でも、コスト配分をしたい、そして異なるチーム間で分離・隔離したいのであれば、モデルアクセスの前にゲートウェイを置くというのは素晴らしいことです。 では次に見ていきたいのは、ツールとエージェントレジストリです。出てきているパターンは、これらそれぞれに対して目的別に構築されたゲートウェイとレジストリがあるということですが、これらを組み合わせることもできます。これら2つのものを組み合わせて、サービスとして提供している解決策が出てきています。
ツールゲートウェイの一例は、AgentCore の一部として提供される AgentCore Gateway です。これはすべてのツールへの統一されたアクセスを提供します。エージェントが AgentCore で実行されているか、外部で実行されているかは関係ありません。それでもゲートウェイを使用することができます。API エンドポイント、Lambda 関数、または MCP サーバーにアクセスでき、それらをターゲットとしてアタッチします。
これにより、それらすべてに対して MCP エンドポイントが作成され、エージェントはゲートウェイのセマンティック検索機能を使用してこれらを発見することができます。これはツールにアクセスするための一種のレジストリとゲートウェイを提供するツールゲートウェイの例です。
オープンソースのMCPレジストリとエージェントゲートウェイソリューション
では次に、私たちの同僚が開発したオープンソースソリューションをお見せしたいと思います。これは包括的なゲートウェイとレジストリです。 MCP とエージェントの両方で機能し、これら両方へのアクセスを提供します。オープンソースで利用可能なので、ぜひチェックしてみてください。良いところの1つは、エンタープライズ対応の observability が統合されているということです。
その仕組みは、フロントに agentic サーバーエンドポイントがあり、その他すべてが EKS クラスター内に MCP サーバーとしてデプロイされています。また、2種類の認証をサポートしています。JWT を使用した M2M と、3LO 認証です。両方で本当にうまく機能していて、多くの開発が進行中です。オープンソースなので貢献することができます。ぜひ見てみてください。
Observabilityの重要性：品質、コスト、リスクの測定と評価
ゲートウェイについて見てみましたが、様々なレイヤーがあります。全てについて説明するわけではありませんが、非常に重要なトピックについてお話ししたいと思います。それは observability です。私は長年この業界でソフトウェアアプリケーションを構築してきました。その当時、observability というのはシステムを生かし続けることが中心でした。アップタイムやレイテンシー、エラーについて心配していました。しかし今は状況が変わりました。システムを一貫性のある状態に保つことが中心になっています。品質やバイアスについて心配するようになりました。毒性やハルシネーションが起きていないか、そういったことを気にするようになったわけです。以前はインフラストラクチャーのモニタリングでしたが、今はほぼインテリジェンスをモニタリングしているような状態です。
なぜ observability が必要なのか。品質は非常に重要です。レスポンスの品質を理解したいのです。正しいツールが選択されているかどうかを理解したいのです。エージェントは多くのツールにアクセスすることで機能するので、適切なツールが利用可能かどうか。正しいツールを選んでいるのか。正しいパスに収束しているのか。収束というのは、レスポンスを得るまでに最短経路を取っているかということです。これら全てが品質に関わります。コストは暗黙的に含まれています。コストを理解したいのは確実です。レイテンシーはシステムのレイテンシーではなく、なぜエージェントがレスポンスに時間がかかっているのか。プロセスのどのステップが時間を取っているのか。そしてリスクも測定したいのです。リスクが最も重要なものです。どのように測定するのか。PII のリークがないか、毒性のあるアウトプットがないかを見ることで測定します。それを行う方法があり、私がお話しします。
これが observability システムの仕組みです。エージェントはログ、トレース、メトリクスの形で運用的および意味的なシグナルを生成しています。もう一つの重要なメトリクスはユーザーフィードバックで、これを収集する必要があります。observability プラットフォームまたはツールがこれらのシグナルを集約して可視化します。もう一つ重要なことで、多くの場合セットアップされていないのが evaluation レイヤーです。その役割は、いくつかの評価を使って品質とリスクを解釈することです。いくらメトリクスを集めても、それを評価に使わなければ、コストを理解する以外に利点はありません。evaluation レイヤーが全てを評価した後、最適化ループが起こります。そこでアウトプットが本当に望むものを生成していないことがわかるので、別のモデルや別のプロンプトを使うようになります。何か変更を加えて、このループが続きます。この observability プラットフォームはどのツールでもあり得ます。例えば Langfuse は素晴らしいツールです。AgentCore にも observability があり、これも素晴らしいツールです。ここにこれらのツールのいずれかをプラグインできます。
では、何を測定しているのか。Functional quality が重要です。retrieval augmented generation アプリケーションでも、検索が起きていることに関連しているのか。プロンプトに基づいてベクターデータベースからチャンクが抽出されます。正しいチャンクを識別しているのか。正しいツールを見つけているのか。ツールに正しいパラメータを渡しているのか。それが第二象限です。そして第四象限のユーザーフィードバックも重要です。イエスかノーか。このレスポンスは機能するのか、それともそのレスポンスは機能するのか。
ユーザーに二つの選択肢を与えることができます。イエスかノーか。特定の属性を暗黙的に示すこともできます。例えば、ユーザーが何度も同じことをプロンプトしている場合、おそらく答えは満足のいくものではないのかもしれません。セーフティー、毒性、PII リーク、バイアスは測定するのに非常に重要です。これらは包括的なリストではありません。測定を開始できるものはもっと多くありますが、これらは非常に重要で大切なメトリクスです。
評価には2つのタイプがあります。オフライン評価は開発中に行われます。これを DevOps パイプラインに統合して、システムとアプリケーションを継続的に評価します。使用するデータセットは、あなたが作成したゴールデンデータセットです。ユーザーが注釈を付けたものでも、合成データセットでも構いません。それが完了したら、次はオンライン評価です。ここでは実際のユーザーインタラクションが測定されます。これはライブシステムで行われます。
observability システムから出てくるすべてのトレースを測定する必要はありません。ただし、非常にリスクの高いアプリケーションの場合は、すべての出力を測定して、期待通りに動作しているかどうかを確認する価値があります。そうでない場合は、5% や 10% などの特定のデータセットをサンプリングして、それらを評価し始めることができます。継続的なイテレーションが重要です。
評価とテストのライフサイクル：ゴールデンデータセットから継続的最適化まで
では、ライフサイクルを見てみましょう。まず、ゴールと指標を定義して、このゴールデンデータセットをキュレーションします。これを忘れないでください。ゴールデンデータセットは本当に重要です。アプリケーションを開発して、本番環境に投入して、どのように動作するかを見るだけだと思うかもしれません。いいえ。アプリケーションを開発して、ゴールデンデータセットでテストしてから、本番環境に投入します。異なる条件下でテストしてください。
テストには3つの異なる方法があります。1つ目は automated evaluation を使用することです。これは、何らかのコーディングを使用して評価したり、regex を使用したり、ground truth データセットと比較したりすることを意味します。2つ目の方法は、別の LLM、別のモデルを使用して出力を見て、「ここにプロンプトがあり、ここに出力があります。測定値をくれませんか」と言うことです。その LLM のプロンプトは非常に良いものである必要があります。本当に良い LLM を使用してください。これは LLM as a judge と呼ばれます。
3つ目の方法は、人間を使用することです。最も費用がかかるオプションですが、キューを作成して、人間がより正確性に近い形で評価することができます。ただし、コストについて考えてください。その後、continuous optimization が来ます。これをどのように行いますか？Observability は2つの方法で統合および実装できます。1つは、これらの observability ツールすべてに SDK が付属していることです。その SDK を使用して、アプリケーションにそのインストルメンテーションを構築できます。たとえば、Langfuse には使用できる SDK があります。
もう一つのやり方は、すべてのトレースとフィードバックを OTel collector に集約することです。これはテレメトリデータを収集・処理するための標準です。その後、測定方法に応じて異なるシステムにそのデータを流すことができます。AWS のサービスである CloudWatch に流すことができ、そこでダッシュボードを作成できます。または Amazon S3 という拡張性の高いデータストアに流すこともできます。 そこからオフライン分析を行うことができます。または Langfuse のようなシステムに流すことができ、そこから多くのインサイトを得ることができます。 それを分析して評価レイヤーに流すことができます。
Agentic AI Foundation Acceleratorの紹介：オープンソース基盤の全体像
では Aamna からのデモを見てみましょう。Chaitra、ありがとうございます。今日 Chaitra と Dave とステージを共有できて本当に興奮しています。Chaitra は生成 AI アプリケーションをスケールして本番環境に展開するための基礎コンポーネントを構築するジャーニーについて説明してくれました。でも、これが実際にどのように動作するのか、そしてこれを具体的にどのように想像するのか、気になっている人は多いのではないでしょうか。
私のチームが Agentic AI Foundation Accelerator という accelerator をオープンソース化したことをお伝えできて本当に興奮しています。これは基本的に Chaitra が話していた多くの基礎コンポーネントを結びつけるもので、generative AI gateway、observability、オフライン評価、 アプリケーションを保護するための guardrails、そしてインフラストラクチャ・アズ・コード デプロイメントが含まれています。これは軽量ですが、よく設計された基盤で、Terraform を使用してインフラストラクチャ・アズ・コードを活用してこのソリューションをデプロイする機会を提供し、Amazon Bedrock AgentCore Runtime を活用してエージェントをセキュアでスケーラブルな方法でホストするのに役立ちます。
ここの中央上部に見えるのが Amazon Bedrock AgentCore Runtime で、エージェントをホストするのに役立ちます。このデモでは、LangGraph というオープンソースフレームワークを活用していますが、独自のフレームワークを持ち込むこともできます。Strands、Crew AI、独自のコードロジック、独自の実装が考えられ、Runtime でホストできます。その後、中央下部に LLM gateway が見えます。私たちの accelerator では、LiteLLM guidance を活用して、エージェントが AWS ランドスケープだけでなく、Bedrock だけでなく、その先の任意のモデルを呼び出すことができるようにしています。私たちの accelerator は、SageMaker 上のモデルやサードパーティプロバイダーのモデルも活用するのに役立ちます。
私たちの場合の LangGraph エージェントは 3 つの異なるツールを使用しています。今日デモンストレーションするユースケースは非常にシンプルなカスタマーサービスチャットアプリケーションです。しかし、この基盤をあなたのユースケースと業界に適応させることもできます。基礎は同じです。基本的にあなたのプロセスに基づいてコードと実装を行います。私たちの例では、エージェントは AgentCore Gateway の背後にある 3 つのツールを活用しています。このツール gateway の背後にあるのが 3 つのツールです。最初のものは RAG ベースのツールで、エンタープライズのインデックス化されたデータからコンテキストを取得するのに役立ちます。これは Amazon Bedrock Knowledge Base を活用しています。私たちが活用しているもう一つのツールは、サポートチケットの作成と情報提供のためのサードパーティ API です。例えば、エージェントが顧客クエリに答えられない場合、エージェントはこれをルーティングしてサポートチケットを作成します。3 番目のツールはウェブ検索ツールで、これも gateway の背後にあります。Tavily を使用したサードパーティ API を活用しています。
これらすべてが、右側に見える Amazon CloudWatch だけでなく、Langfuse という第三者の observability ツールを使って監査されています。エージェントのインタラクションのトレースを収集して、その上で開発フェーズ中にオフライン評価を実行して、このアプリケーションが期待通りに動作していることを確認しています。これらすべてが実際にどのように機能するかを示すために、上部に配置したのは Streamlit で動作するフロントエンドアプリケーションです。これが私がデモンストレーションして、これらすべてがどのように一緒に機能するかを示すものですが、私たちはこれもオープンソース化しています。プレゼンテーションの最後に、GitHub のリソースを皆さんと共有しますので、皆さんも実際に試してみたり、ビルダーのところに持っていってフィードバックを得たり、これらの基礎となるコンポーネントがどのように一緒に機能するかを確認することができます。
デモンストレーション：カスタマーサービスエージェントの実装と評価
これは基本的に、AWS インフラストラクチャ上に構築された LiteLLM gateway を活用しているカスタマーサービスチャットアプリケーションです。このエージェントは、皆さんが選択したモデルにアクセスできます。2つのモードがあります。ローカルモードと、エージェントが AgentCore Runtime でホストされるモードです。
つまり、ローカルでテストしてから AWS にデプロイして、ARN を提供します。つまり、識別子、リージョン、そして認証をサポートしています。ユーザーアクセストークンを提供して、ユーザーを認証します。ご覧の通り、LiteLLM gateway と統合されています。このエージェントは、アクセスできるモデルのリストを持っています。Bedrock モデルだけでなく、Bedrock 外のモデルもあります。例えば OpenAI のモデルなどです。そして、ユーザー識別子もあって、トレースにタグを付けることができます。
基本的には hello を送るだけです。簡単な hello を送ると、設定したシステムプロンプトに基づいてエージェントが応答します。これは任意の企業向けのカスタマーサービスエージェントで、ダミー企業用です。そして、インデックスしたデータがあります。ルーターハブをリセットする方法について質問します。
任意の企業がサポートしているデバイスがあります。エージェントが答えを提供します。基本的には retrieve_context ツールを活用して答えを提供しています。ご覧の通り、活用したソースもリストアップされています。
どのドキュメントを使用したか、そしてその検索の関連性を確認できます。また、使用されたモデルは何か、どのツールが使用されたか、引用情報（ドキュメント、ページ番号など）も表示されます。さらに、可観測性のためのトレース ID も追加されています。別の質問をしてみます。
答えに基づいてルーターハブをリセットしようとしますが、うまくいきません。エージェントが別の手順を提供しますが、その後
「これで満足できない場合は、サポートチケットを作成できます」と言います。そこで「はい、作成してください」と言います。エージェントはその情報を使用して
さらにクエリを実行し、メール ID、問題の説明など、追加の詳細について質問します。それらの詳細を提供します。エージェントは十分にインテリジェントで、その情報をすべて取得して、AgentCore Gateway の背後でホストされている create_support_ticket ツール呼び出しのパラメータとして使用します。
これらのパラメータが何であるかを明示的に述べていません。自然言語でその情報をすべて提供しているだけで、エージェントがそれを取得して、create_support_ticket ツールを呼び出す必要があることを理解します。
この場合、サードパーティの API を使用してチケットが作成されたのが見えます。 すべての情報を提供してくれます。また、このプロセスで create_support_ticket ツールが呼び出されたのも確認できます。ここで別のアプローチを試してみます。エージェントに投資アドバイスも提供しているかどうか聞いてみると、入力内容がポリシーに違反していると言われます。 また、Bedrock Guardrails と統合して、このアプリケーションが安全で信頼できるものになるようにしました。PII 検出などの他の機能も備えることができます。 次に、どのデバイスについてサポートを求めたのかを聞いてみます。これはセッション管理のための短期メモリの例です。同じセッション内で情報を繰り返す必要はありません。router hub についての質問をしたこと、そしてサポートチケットを作成したことを覚えています。
ここでローカルモードから AgentCore モードに切り替えます。 自分のエージェントに非常に満足しており、AgentCore Runtime にホストしました。エージェントの識別子を提供します。 そしてユーザーアクセストークンを提供します。前述の通り、OAuth も統合されています。認証トークンを提供すると、AgentCore Runtime に接続されたと表示されます。 これでクラウド上のエージェントと対話しています。再び同様の質問をしてみます。AnyCompany broadband ではどのような種類のデバイスがサポートされているのか。 retrieve_context ツール呼び出しを行い、同様の方法で動作します。ここで示したいのは、 ローカルモードをクラウドにホストできるということです。
ここで LiteLLM が見えます。このゲートウェイは、基本的に共有コンポーネントであるモデルカタログを表示しています。 LiteLLM ゲートウェイを通じてエンタープライズでサポートされているすべての異なるモデルとプロバイダーは、LiteLLM の UI でチェックアウトできます。 アクセスキーや API キーをチームまたはユースケース用に作成し、そのチームまたはユースケースにコストを割り当てることができます。 また、プレイグラウンドもあり、そのキーを使用してテストすることができます。包括的な使用ダッシュボードもあります。 これにより、チームごとの支出、トップ API キー、トップモデル、組織内で消費されているトッププロバイダーが表示されます。 さらに、ログも利用可能です。これらはモデル呼び出しのログです。 エージェントが行ったすべての呼び出しについて、総トークン数、コスト、成功したかどうか、失敗したかどうかが分かります。これが LiteLLM の様子です。
次に、observability ツールである Langfuse に切り替えます。この例では、Streamlit アプリケーション経由でエージェント呼び出しのために生成されたトレースを見ていきます。 プラットフォームのこのトレーシングタブに移動して、最新のトレースでフィルタリングします。 これは、先ほど見た対話のトレースです。コードでは、これらのトレースにタグを付けています。 非常に簡単に、メトリクスを作成する際にこれらのトレースをフィルタリングして分類できます。私の場合は、LangGraph customer service agent トレースです。 これはフロントエンドアプリケーションでも見たユーザー ID です。
ユーザー ID、プロジェクト ID などに割り当てることができます。これらはエージェントトレースの出力として収集されている異なるメタデータです。 タイムラインビューがあるので、各ステップにかかった時間も確認できます。エージェントが本当に遅い場合、 retrieve context ステップか create support ticket ステップのどちらが長い時間がかかったのかを判断でき、エージェントの速度とレイテンシを簡単に最適化できます。 ここには異なるメタデータを持つ異なるステップがあります。例えば create support ステップには、 このツール呼び出しを呼び出すために使用されたすべてのパラメータがあります。retrieve context では、関連性スコアが何であったか、 どのアイテムが取得されたかなどの詳細も取得できます。ここからは、ユーザーフィードバックをどのように収集しているかを示します。 Chaitra も述べたように、これは収集する別の重要なメトリクスです。アプリケーションにいくつかの質問をして、エージェントがこれらの質問に答えます。満足している場合、つまり私は満足しているので、親指を立てて、パフォーマンスについての洞察を得るために取り組むことができる自然言語コメントも提供します。これも Langfuse で収集しています。
ご覧の通り、user feedback というものがあり、これを正規化してコメントも収集して、全体がどのように機能しているかを理解しようとしています。では、offline evaluation がどのように機能するかをデモンストレーションします。これは私たちが作成した基本的な Python スクリプトで、ground truth データを使用して、私の agent にいくつかのクエリを送信しています。その後、Langfuse からトレースを収集して、LLM as a judge を使用して、latency、faithfulness、correctness、tool accuracy といった特定のメトリクスを作成しています。私の期待していたツール呼び出しは、例えば retrieve_context だったのですが、agent は support ticket を作成してしまいました。ですので accuracy はゼロでした。このような種類のものは開発フェーズ中に作成することができ、DevOps パイプラインに組み込むことができます。先ほど申し上げたように、これをオープンソース化しましたので、ぜひ確認していただきたいと思います。Chaitra が後ほどリソースを共有してくれます。
要約すると、Bedrock と他のモデルを活用する LLM gateway があります。異なるツールを活用する tools gateway があります。そして、observability や offline evaluation といった異なるコンポーネントもあり、ここで golden dataset を持ち込んで、異なるメトリクスを作成します。私は「router hub をリセットするにはどうすればいいですか？」というクエリを持っています。期待されるツール呼び出しは retrieve context のようなものです。Python ロジックを使用して tool accuracy、parameter accuracy を作成し、また LLM as a judge を使用して faithfulness などのような response quality メトリクスを作成しています。さらに、先ほど申し上げたように、infrastructure as code も提供しています。これは Terraform で利用可能です。これの主な目的は、developers と builders が迅速にソリューションをエンドツーエンドでデプロイしてテストし、これらの基礎的なコンポーネントがどのように組み合わされているかを理解できるようにすることです。ご覧になったすべてのもの、そしてデモの一部としてデプロイされたすべてのものは、infrastructure as code でエンドツーエンドでデプロイできます。
Sageのエージェントメッシュ戦略：分散アーキテクチャでの実装事例
これが基本的にデモでした。多くのことを見ました。LiteLLM gateway を見ました、AgentCore Runtime が agent をホストしているのを見ました、また異なるツールが背後にある AgentCore Gateway も見ました。これらすべては Langfuse で追跡・監視され、その上に offline evaluation がありました。デモについてはこれが全てですが、まだまだ用意しているものがあります。次のセグメントに進むのは本当に楽しみです。ぜひ David Senior をステージにお招きしたいと思います。彼は Sage が自分たちの組織で agentic AI をどのように実装しており、基礎的なコンポーネントをどのように活用しているかについて、より詳しく説明してくれます。ステージへようこそ。
ありがとうございます。そして、本日ここでプレゼンテーションする機会をいただき、ありがとうございます。まず Sage が誰であり、何をしているかについて少しお話しします。私たちは主に accountancy、HR、payroll の分野で活動しています。これらのドメインでソフトウェアを製造しています。画面にはいくつかの成長数字も表示されています。世界中に 11,000 人の従業員がおり、20 カ国に分散しています。世界中で 600 万のビジネスが Sage 製品を使用しています。面白い事実として、UK の従業員の 4 分の 1 は Sage ソフトウェアを通じて給与を受け取っています。では、現在 agent スペースで何を持っているかというと、Help Search があります。
私は皆さんが現在このようなタイプのソリューションを構築していると思います。ですので RAG ベースの Help Search です。私たちの product teams はこれを 5 日以内に production 内の製品に統合できます。これは素晴らしいパフォーマンスです。Instant Analysis があります。Instant Analysis は LLM を使用して financial reports を要約し、それらについて顧客の質問に答えます。
私たちの Accounting Agent があります。これは多くの機能をまとめたもので、顧客が自然言語を通じて製品と対話できるようにしており、さらにデータの変更に関する洞察と、データ入力時の潜在的なエラーについての情報も提供しています。そして、Close 向けの Agent があります。これは、顧客が会計製品でピリオドクローズを行うのを支援する Agent の別の例です。ただし、私たちにはいくつかの課題もあります。
私たちは非常に分散されたアーキテクチャを持っています。Sage は世界中に 200 以上の製品を持っており、長年にわたって買収を通じて大規模に成長してきました。このような大きな組織を持っているため、意思決定も分散しています。私のチームは Central Services チームで、AI ソリューションを構築していますが、Sage で AI に取り組んでいるのは私たちだけではありません。誰もが AI に取り組んでいます。
私たちのスイート戦略に対応するために、顧客にパッケージの形でソフトウェアを販売したいのですが、それらの製品にまたがる AI エクスペリエンスも必要です。つまり、顧客が会計製品から HR 製品と対話するために私たちの Agent を使用でき、その逆も可能である必要があります。また、payroll とも連携したいと考えています。ここで agent mesh アプローチが登場します。
Agent mesh アーキテクチャについて少し説明します。ここに画面上にいくつかの例があります。基本的な mesh があり、これはより小さなセットアップ向けで、agent registry があるかもしれませんし、ないかもしれません。これにより、agent は agent-to-agent プロトコルを使用して互いに対話できます。Gateway mesh があります。Gateway mesh では、すべての agentic リクエストが中央のポイントに送られて、適切な agent にルーティングされる必要があります。
その課題は、このようなすべてを一元化しようとしている大きな組織がある場合、単一障害点を構築することになり、組織内のすべてのチームがそれと対話および統合する必要があるという要件を構築することになるということです。また、ここに hierarchical mesh の例もあります。ここでは、説明されているように、orchestrator と agent の階層があります。そして、より複雑な mesh があり、これは federated mesh で、複数の mesh 間のブリッジがあり、複数の認証ソースもあるかもしれません。
これが私たちが考え出したアーキテクチャです。 これは Sage のためのエージェント戦略で、以前お見せした異なるメッシュの組み合わせを使用しています。これを右から左の観点で説明すると、私たちが今持っているものと将来に向けて取り組んでいるものについて議論できます。一番右側に私たちのツールがあります。MCP サーバーもあります。また、業界がその標準に落ち着く前に MCP が登場する前に構築した MCP のようなソリューションもあります。
ワークフローオーケストレーターとそのようなソリューションを持っています。今では AgentCore Gateway for MCP も使い始めています。これらは Sage の複数のビジネスユニットと複数の製品に分散しています。ゲートウェイの前に、私たちのエージェントがあります。アーキテクチャで定義した 3 つのタイプのエージェントがあります。特定のロールベースのタスクを実行する専門エージェントがあります。
それらのロールベースのサービス全体で調整される複雑なタスクを計画できる計画エージェントがあります。そして私たちのメインエージェントがあります。メインエージェントはオーケストレーターです。メインエージェントは製品内のエージェント体験のエントリーポイントになります。顧客が製品内のエージェント体験を開くと、メインエージェントに接続されます。ユーザーのリクエストに基づいて、
エージェントは計画エージェントを使用して、それらの専門エージェント全体で調整される複雑なワークフローをリクエストする必要があるかもしれません。または、単純なタスクのために専門エージェントをトリガーするだけかもしれません。別の選択肢は、ユーザーがローカル製品でサポートされていないアクションをリクエストすることです。例えば、会計ソフトウェアでデータ入力をしていて、来週新しいスタッフが入ってくることを思い出したとします。そこでエージェントに HR プラットフォームで新しいユーザーを作成するよう依頼します。
この状況では、メインエージェントはエージェントメッシュに行き、サインインしているテナントに基づいて顧客の権利を検索する必要があります。これは MCP を経由して発生します。私たちはそのための MCP ゲートウェイを持っていて、エンタイトルメントサービスを検索し、この顧客のテナントが Sage から購入した HR 製品を取得しています。その後、エージェント間プロトコルを使用して、その製品のメインエージェントへのエージェント間ハンドオフを実行します。ユーザーは HR のメインエージェントと同様の方法で対話できます。計画エージェントによって生成される計画が必要な複雑なタスクかもしれません。または、単にロールベースのエージェントをトリガーするだけの単純なタスクかもしれません。
私たちの製品ドメインの外側で、メッシュの中には observability も備えています。先ほど言及されたように、環境内で何が起こっているかをしっかり理解するためには、observability が必要です。エージェント間のやり取りだけでなく、私たちの製品を通じて流れるトリガーもトレースできる必要があります。ユーザーが私たちの製品内で API をトリガーしている場合、そのアクションが正常に完了したのか、それとも失敗したのかを確認できる必要があります。
また、私たちのメッシュの一部として centralized identity も備えており、Sage ID サービスを使用しています。すべてのユーザーは Sage ID を通じて認証されます。ただし、アクセス制御は centralized ではありません。アクセス制御は製品ドメイン内に存在します。HR agent に対してアクションをリクエストした場合、そのアクションを完了する権限があるかどうかは不確定です。エージェントはローカル製品内の entitlements を検索して、あなたの代わりにそのアクションを実行できるかどうかを理解する必要があります。
また、just-in-time elevation of privilege も構築する予定です。これにより、エージェントはより高い権限を持つユーザーにそのアクションを 1 回限りであなたの代わりに実行するよう要求することができます。では、次は何でしょうか。私たちが構築したエージェントを Bedrock AgentCore を使用するように modernize することを検討しています。今日、私のチーム内で構築したほとんどのものは AWS サービス上に構築されています。modernize という表現は、AI と LLM とこの世界がどれほど新しいかを考えると、ちょっと面白い言い方ですが、業界が動いている速度はそのくらい速いということです。
私たちは Bedrock AgentCore を使用して私たちのアーキテクチャを最新の状態に保ち、メッシュに統合することを検討しています。今日、Sage 内には多くの isolated AI experiences があります。これを単一のメッシュとして統合したいと考えています。その後の次のステップは、より多くのエージェントを構築することです。私たちは内部的に、エージェントをどのように構築する必要があるかについての独自の reference architecture を公開する予定です。お時間をいただきありがとうございました。AgentOps に関する別のセッションに戻します。
AgentOpsとエンタープライズ運用：DevOpsパイプラインとプラットフォームマインドセット
では、AgentOps です。 これは私たちが提供できる単一のソリューションではありません。単一のツールでもありません。Ops は、これらを取得して本番環境で管理できるようにするための processes と tools の集合です。prototype から production へのライフサイクルを考えると、すべてのステップで ops は、次のステップに進むための capability と components を提供することです。prototype フェーズでは、開発者は異なるモデルへのアクセスが必要です。これらのすべての異なるモデルで迅速に実験する方法と、異なるエージェント frameworks で実験する方法が必要です。
A/B testing は1つのアプローチです。その後、開発に進むと、サンドボックス環境にこれをデプロイできる環境を提供して、observability を統合し始めて、evaluation を実行し始めます。開発側でも evaluation を実行できますし、その後、ゲートウェイのような私たちが話した他のサービスに統合することもできます。テストに関しては、エンドツーエンドの QA テストが中心になりますが、QA システムに異なるデータセットがあるかもしれないので、ここでも evaluation を実行することができます。本番環境に進むと、既に話した live monitoring がありますが、セキュリティとガバナンス、監査可能性の維持、システムの定期的な監査、そして bias、toxicity、risk assessment を定期的に実行することも含まれます。
また、これは DevOps プロセス、つまりこれらのアプリケーションとエージェントのライフサイクル管理についてです。エージェントは廃止される必要があり、モデルはバージョン変更を経ます。 では、これらすべてをどのようにまとめるのでしょうか？それが大きな用語を形成します。私たちが operations と呼ぶものです。パイプラインがどのようなものかの例を挙げると、エージェント開発者がエージェントを開発したとしましょう。 git flows を使ってそのコードをチェックアウトしてコンテナをビルドすることができます。ここでコンテナについて話しているのは、AgentCore の例を挙げているからです。AgentCore にデプロイしてから evaluation を実行します。 この evaluation は dev アカウントでコンテナとして実行することもできますが、必ずしもそうとは限りません。示されているように、スクリプトをローカルで実行して、その dev エンドポイントを golden dataset に対してテストして、期待通りに動作していることを確認することができます。問題ありません。それをレジストリに入れます。Agent registry は、そこにいくつかのツールがあるか、またはこのメタデータをデータベースに保存し始めることができるものです。そこから、QA にデプロイしてさらに evaluation を実行します。 このデータセットは dev データセットとは異なるかもしれません。常に、例えば Langfuse にトレースを送信しています。Langfuse には Environments という機能があり、dev、QA、prod を持つことができるので、これらのトレースを分離することができます。これは異なるアカウントをアーキテクチャする非常に良い方法です。
期待通りでない場合は、最適化を始めて、サイクルが再び始まります。さらに変更を加えて、異なるモデルを使うかもしれませんし、異なるプロンプトを使うかもしれません。 その後、すべてが問題ないと、本番環境に進む前に常に手動承認があり、prod にデプロイします。 ここで online evaluation を実行しています。この online evaluation は、自分たちで構築することもできますし、これらのツールも online evaluation を実行する機能を持っています。例えば、Langfuse を使う場合、それらの online evaluation 機能を使ってそれを実行することができます。ただし、それを実行するために必要な特定のデータをサンプリングしていることを確認してください。その後、アプリからユーザーフィードバックを収集します。すべてが observability システムに入ります。これは、エージェント DevOps がどのように設定できるかの例です。必ずしもすべてがこのようである必要はありませんが、参考にしてください。
エンタープライズスケールで運用することが何を意味するのか：プラットフォームチームまたは IT チームであり、この基盤を設定しているとしましょう。どのように設定しますか？私たちが皆見てきたクラウド運用モデルに戻ると、集中型は多くの良い標準化を提供します。分散型は、これらのエンドチームに多くの俊敏性を提供しますが、federated は、バランスの取れたアプローチです。ですから、私が platform core と言うところ、それが私たちの基盤です。 おそらくいくつかの共有サービスを提供します。例えば、model catalog と gateway は素晴らしい例です。これは集中的にホストされるものになる可能性があります。ただし、これは1つのデプロイメントであることを意味しません。複数のデプロイメントになる可能性がありますが、あなたはそれを制御し、集中的な方法でそれを管理しています。
Agent foundations、私が意味するのは runtimes と memory です。Tools も platform の一部になることができます。モデルをカスタマイズしている場合、つまり fine-tuning または pre-training を意味しますが、そのインフラストラクチャは中央プラットフォームの一部になることができます。そして observability です。左側にあるのは、これらの consuming applications です。彼らが自分たちのデータを所有しているか、多くの場合、プラットフォームチームはデータについて気にしたくないので、おそらくそれは consuming チームの責任です。繰り返しになりますが、これは異なる方法でスライスして分割することができます。
重要なのは、あなたの組織体制に基づいて、運用モデルを調整することです。 念のため、これが私たちが話した基礎であり、かなり広範なものです。覚えておくべきことは、コア機能を設定することです。 すべてが必要というわけではありません。アプリケーションを構築するために必要なものの方が重要です。ただし、絶対に構築しなければならないものがあります。それは observability と safety です。
プラットフォームマインドセットを持つことです。特に agentic AI の場合、これがますます重要になってきていると思います。ガバナンスは大きな要素です。このガバナンスをどのように一元化するのか。リスクをどのように一元的に管理するのか。このようなプラットフォームマインドセットを持つことは価値がありますが、イノベーションを阻害するほどではないようにする必要があります。ですから、柔軟性を考慮して設計してください。一元化すると、しばしば機敏性が失われますよね。異なるチームがアプリケーションを構築してデプロイするための、すべてのボトルネックになってしまいます。ですから、私たちが federated model で話したように、微妙なバランスがあります。ここにいくつかのリソースがあります。
すべてが最初のブログにあるわけではありません。最初のものです。 2 番目のものは、私たちが示した LLM gateway ソリューションについて公開したブログです。下の最初のものは、Aamna が話していた guidance で、彼らが open source として公開したソリューションです。ぜひ見てみてください。基礎を構築し始めるための足がかりになるでしょう。下の 2 番目のものは、MCP registry と agent registry で、私たちが話したソリューションです。
agentic AI のスキルを引き続き構築したい場合は、こちらの Skill Builder リンクをご覧ください。ぜひ探索してみてください。アンケートに記入することをお忘れなく。良い意見も悪い意見も、フィードバックをいただくことは私たちにとって重要です。お時間をいただきありがとうございました。皆さんがここにいてくれることに感謝します。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion