re:Invent 2025: Amazon Bedrock AgentCoreとLangGraph等のエージェントフレームワーク統合手法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Integrate any agent framework with Amazon Bedrock AgentCore (AIM396)
この動画では、Amazon Bedrock AgentCoreとオープンソースフレームワークの統合について解説されています。AgentCore Runtimeを使用することで、LangGraph、CrewAI、Strandsなどのエージェントをコード変更なしまたは最小限の変更でデプロイでき、MCPやA2Aといったオープンプロトコルを通じてツールやエージェント間の標準化された通信が可能になります。Arisは、OpenTelemetryとLangfuseを活用したAgentOpsのアプローチを紹介し、実験、QA、本番環境という3段階のプロセスを提案しています。Cohere HealthのKeithは、医療事前承認プロセスにおける実装事例を共有し、LangGraphとArizeを使用した評価システムや、LiteLLMによるモデルプロバイダー管理について具体的に説明しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション導入：AWSのオープンソースへのコミットメントとAgentCoreの位置づけ
皆さん、こんにちは。AIM 396へようこそ。ここではオープンソースフレームワークをAmazon Bedrock AgentCoreと統合する方法についてお話しします。私の名前はShreyas Subramanianです。AWSのPrincipal Data Scientistを務めています。また、AWSのSenior GenAI Specialist SAであるArisも一緒です。そして、Cohere HealthのVP of EngineeringであるKeithとも、このステージを共有できることを嬉しく思います。
さて、始める前に、ちょっと手を挙げていただきたいのですが、ノーコードツールやローコード、あるいはオープンソースフレームワークでエージェントを構築したことがある方はどのくらいいらっしゃいますか？かなり多くの方がいらっしゃいますね。そうですね、ここに表示されているフレームワークやプロトコルのいくつかをご存知かもしれません。 基本的なエージェントを構築するには、これらすべての異なる複雑なコンポーネントを組み合わせる必要がありますよね。フレームワークの選択、統合するツールの選択、そして状態管理もあります。しかし幸いなことに、これらのオープンソースフレームワークの一部が先に登場し、エージェントを構築する方法を本当に簡素化してくれました。また、MCPやA2Aのようなオープンプロトコルもあり、エージェント同士やエージェントとツールを接続するのに役立ちます。認証のためのOAuthのようなオープンプロトコルや標準があります。可観測性のためのOpenTelemetryもあり、これらすべてが非常に迅速に開始してPOCを構築するのに役立ちます。しかし、POCから本番環境への移行は、まったく別の話ですよね。
AWSでは、創業以来オープンソースに貢献してきており、それを誇りに思っています。オープンソースは皆にとって良いものだと考えています。Linux Foundationや、GitHubのオープンソースプロジェクトに貢献してきました。エージェント関連のセッションですので、私たち自身のエージェンティックフレームワークであるStrandsや、他のオープンソースフレームワークにも貢献していきたいと考えています。オープンソースは皆にとって良いものだと信じています。これをマネージドサービスを通じてお客様に提供することにコミットしており、Cohere HealthのKeithからもこれについてさらに詳しくお聞きいただけます。
AgentCore：エンドツーエンドのエージェント技術プラットフォームとその構成要素
今日は特に、AgentCoreがオープンソースフレームワークとどのように連携するかについてお話しします。他のAgentCoreセッションに参加されていない方のために説明しますと、AgentCoreは、エージェントを大規模に構築し運用するのに役立つエンドツーエンドのエージェント技術プラットフォームです。そして、少し視点を広げて、AgentCoreを30,000フィートの高さから見てみると、 画面に表示されているこれらすべてのコンポーネントをご覧いただけますが、AgentCoreはこれらすべての個別のサービスで構成されています。必要なものを選んで使うことができます。画面の中央にあるのがAgentCore Runtimeです。Runtimeを使用すると、コードの変更なし、または最小限のコードの変更で、あらゆるオープンソースエージェント、MCPサーバー、A2Aサーバーをデプロイできます。
これらのランタイムエージェントは、セッション分離環境で実行されます。会話型インターフェースを持つ対話型エージェントにすることも、ディープリサーチエージェントのように何時間も実行できる長時間実行エージェントにすることもできます。Runtimeは、これら他のすべてのAgentCoreサービスとも統合されています。たとえば、Runtimeは、エージェントのアイデンティティと認証情報管理サービスであるIdentityと統合されています。また、Memoryとも統合されており、これは最初のエンタープライズグレードのメモリ機能の1つで、インフラストラクチャのセットアップがゼロで済みますが、エージェントにアタッチできる短期メモリと長期メモリを持つことができます。
また、最近AgentCoreにPolicy and Evalsを導入しました。これにより、エージェントを制約し、本番環境でエージェントがどれだけうまく機能しているかを判断することができます。これらすべての異なるサービスを接続しているのは、オブザーバビリティ、つまりAgentCore Observabilityです。これはOpenTelemetryまたはOTelフォーマットで動作します。AgentCoreの素晴らしい点は、先ほど申し上げたように、エージェントアプリケーションを構築するために必要なサービスを自由に選択できることです。そして今日は、オブザーバビリティのさまざまなフレーバーを見ていきます。例えば、Keithが本番環境でどのようにArizeを使用しているかについて話します。ArisはAgentCoreでLangfuseをどのように使用できるかについても話します。
カスタマーサービスのユースケースとエージェントフレームワークの選択基準
では、詳細に入る前に、本当に基本的なシナリオから始めましょう。例えば、お客様が注文を追跡したいとして、通常はカスタマーサービスに連絡しますよね。そして、このカスタマーサービス担当者は、注文管理システムや外部の配送業者のAPIを調べたり、あるいは電話をかけて注文状況を確認したりする必要があるかもしれません。また、他の技術サポートや人的リソースと協力する必要があるかもしれません。つまり、2つのチームが協力して最終的な回答を得るわけですが、その回答は多くの場合「再起動を試しましたか」というものです。つまり、これだけの努力の末に、数日後に回答が得られるかもしれないということです。
これらの2人の人間、つまり人的リソースチームをエージェントに置き換えようとしています。カスタマーサービスエージェントと技術サポートエージェントですね。さて、これらのエージェントは、これらの担当者の仕事の全機能を置き換えるわけではないかもしれません。部分的な仕事をするだけかもしれませんし、ドメイン固有のコパイロットかもしれません。
では、どのように始めればよいのでしょうか？最初の直感的な反応は、オープンソースフレームワークを調べることです。なぜなら、オープンソースフレームワークには深く広範な統合とコミュニティサポートがあり、始めるための素晴らしい例があるからです。ですから、私たちの直感的な反応は通常そこにあるのですが、どのフレームワークから始めるべきかをどのように選ぶのでしょうか？チームがすでに特定のフレームワークで作業している方法など、さまざまな要因がありますが、私たちのマイナーリストには3つのトップフレームワークをリストアップしています。LangGraph、CrewAI、そしてStrands Agentsです。エージェントフレームワークを選択するためのいくつかの要因をリストアップしています。
LangGraphは、広範なオープンソース統合を備えたグラフベースの実行を提供します。強力ですが、他のフレームワークと比較して非常に急な学習曲線があります。それでも、強力なコミュニティサポートを持つ複雑なエージェントオーケストレーションには適しています。一方、CrewAIは非常に簡単に始められます。特に、マルチエージェントクルーを実行するロールベースおよびチームベースのエージェントに最適で、これが始めるのに最適な場所です。Strandsは、私たち自身のオープンソースエージェントフレームワークで、モデルベースのアプローチを提供し、例えばローカルおよびAgentCore memoryへのアクセスを持っています。これは、AWS上で実行されるエンタープライズグレードのエージェントアプリケーションの出発点として理想的です。
つまり、これらすべての選択肢があるわけです。実際にはもっと多くの選択肢があるかもしれません。実際、私たちはGitHubリポジトリに多くのアプリケーションとユースケースを公開していますので、ぜひチェックしてみてください。しかし良いことに、適切な仕事に対してフレームワークを選んで使うことができるんです。この場合、カスタマーサービスエージェントにはStrandsを選び、テクニカルサポートエージェントにはLangGraphを選んでいます。2つの異なるフレームワークを選ぶ必要はありません。同じフレームワークを選ぶこともできますが、この例では、カスタマーサポートにはStrandsを、テクニカルサポートにはLangGraphを選んでいるということです。
AgentCore Runtimeによるローカル開発から本番環境へのスケーリング
では、それを始めるための最良の方法は何でしょうか？例えば、ラップトップ上でローカルに動作しているStrandsのカスタマーサポートエージェントがあるとします。そこにはローカルクレデンシャルがあります。そのクレデンシャルによって、AWSでホストされているAPIにアクセスできます。これらのAWS APIには、ローカルクレデンシャルがあるのでアクセスできるわけです。テクニカルサポートエージェントについては、カスタマーサポートエージェントとテクニカルサポートエージェント間で何らかのハードな統合を行っています。また、カスタマーサポートエージェントには、外部サービスプロバイダーと統合するためのAPIキーがあることもわかります。しかし、これがスケールしないことはすぐにお気づきでしょう。これはラップトップ上で動いているので、ホストして複数のユーザーに使ってもらえるようなものではありません。しかし、あなたの目標は、これを何万人ものユーザーに使ってもらうことです。では、どうすればいいのでしょうか？
そこで登場するのがAgentCore Runtimeです。AgentCore Runtimeについては少しお話ししました。ここで、LangGraph、Strandsやその他のエージェントフレームワークについて触れましたが、これらのエージェントを非常に簡単にホストでき、専用のエンドポイントが得られます。これらのエンドポイントはリクエストに応じて自動的にスケールし、ゼロから本番環境まで本当に素早く移行できます。また、これらのエージェントを任意のモデルプロバイダーに接続できるので、Bedrockである必要はありません。OpenAIでも構いませんし、ほぼどんなモデルプロバイダーでも使えます。また、非常に厳格なセキュリティガイドラインに従って作業することもできるので、VPCオンリーモードにしたり、IAMのみを使用したりできます。
最近、リソースベースのアクセスポリシーも導入しました。本日、MCP仕様の完全サポートもローンチしました。MCPサーバーをお持ちの場合、コードを一切変更することなくMCPサーバーをホストできます。また、双方向ストリーミングも最近ローンチされました。これはカスタマーサービスエージェントのようなものに便利です。現在、テキストベースのインターフェースを想像していますが、それを音声ベースのインターフェースに変換したいと思ったとします。Runtimeを使えば非常に簡単にそれができます。なぜなら、Runtimeは双方向ストリーミングをサポートしているからです。さて、では実際に、カスタマーサポートエージェントとこのLangGraphエージェントという2つのエージェントがあると言いましたが、
これらをRuntimeにどうやってホストするのでしょうか？主に2つの方法があります。コードをDockerコンテナにパッケージ化することができます。そのDockerコンテナはECRリポジトリにプッシュされ、そのECRリポジトリがRuntimeへのデプロイの出発点として使用できます。もう1つのさらに簡単な方法は、デプロイメントをzipファイルに圧縮して、それをS3バケットにプッシュすることです。そうすると、そのS3バケットがRuntimeでのデプロイメントの出発点になります。つまり2つの異なる方法があり、これを行うには実際に数行のコード変更を行う必要があります。
そしてこれは基本的に、Bedrock AgentCore SDKから適切なインポートを行い、このアプリを初期化します。これは実際にはStarletteアプリなんですが、そしてデコレーターがあります。簡単なデコレーターで、app.entry_pointがこのハンドラーまたはこのエントリーポイントをエージェント実行の開始点として指定します。その中で起こること、つまりご覧いただいているmy_agent関数の中で起こることは、完全にあなた次第で、どんなエージェントでも、統合しているどんなフレームワークでも、どんなビジネスロジックでも構いません。そして最後にレスポンスを返します。
期待通りに動作するもの、それが同期レスポンスであろうと非同期レスポンスであろうと、あるいはストリーミングレスポンスであろうと、これらすべてがローカルで実行されているかのように動作するはずです。そしてこれはランタイムと連携します、そうですよね。さて、コードにこれらの小さな変更を加えたら、次のステップは実際に私たちのBedrock AgentCoreスターターツールキットを使用することです。これはローカルに存在するコードからデプロイ可能なコードへ移行するための本当にシンプルな方法です。
3つのステップがあります。最初のステップはAgentCore configureを実行することです。AgentCore configureは基本的に、着地させたいECRリポジトリ、ロール、IAMかOAuthかなど、そういったものをセットアップします。これらはすべてローカルの設定ファイルに保存されます。後から戻って自分で編集することもできますが、AgentCoreで管理するのが簡単です。AgentCore CLIには次のステップとしてdeployもあります。AgentCore deployを実行すると、前のスライドで覚えていらっしゃると思いますが、その2つの選択肢に応じてランタイムにデプロイされます。つまり、コンテナバージョンかzipデプロイメントバージョンのどちらかです。
そして最後に、1分以内にデプロイされ、エージェントの呼び出しを開始できます。スケーリングやインフラストラクチャ管理のすべて、それらすべてが裏側で快適に管理されており、心配する必要はありません。エージェントを起動したら、もちろん呼び出しを開始できます。そしてこの場合、私たちは2つの異なるランタイムを使用すると言っています。1つはStrandsエージェント用、もう1つはLangGraphエージェント用です。両方を共存させたいユースケースもありますが、この場合は、2つの異なるコンテナが起動していると言っています。
それ以外はすべて同じです。つまり、AgentCoreランタイムには実行ロールがあります。これによりAWS APIにアクセスできます。また、Identity Storeを使用してシークレット認証情報を保存することもできます。これは例えば、外部の配送プロバイダーのAPIキーなどで、そのAPIを通じて出荷を追跡したい場合などです。しかし、これらのコンテナとAPIの間の統合、そして1つのコンテナから別のコンテナへの統合は、あなたが管理するものであることに注目してください、そうですよね。
エージェントのためのコンテキストエンジニアリングと統合コードの課題
さらに深く掘り下げる前に、エージェントのためのコンテキストエンジニアリングについてお話ししましょう。これは、ご存知かもしれませんが、コンテキストエンジニアリングやプロンプトエンジニアリングについて以前聞いたことがあるかもしれませんが、エージェントに適用する場合、ズームアウトして、これらのエージェントの1つにズームインすると、つまりStrandsのものでもLangGraphのものでも、そのエージェントに提供するコンテキストが非常に重要であることがわかりますよね。ユーザー指示を持つことができますし、システム指示を持つことができます。例えばRAGシステムから取得した情報があります。以前の会話からの短期記憶が入ってくるかもしれませんし、追加のコンテキストを提供する外部または内部のツールがあるかもしれません。
ですから、もしあなたのツールが間違ったコンテキストや間違った応答を返したり、さらに悪いことに、間違ったツールを呼び出したり、LLMがあなたの代わりに間違ったツールを呼び出したりした場合を想像してみてください。それでもあなたのエージェントのコンテキストに残り、あなたのエージェントはそれに基づいて応答することになります。では、これらすべてが処理されることを確実にしながら、実際には統合ポイントを処理する必要がないようにするにはどうすればよいでしょうか。つまり、開発者としてあなたは基本的にこれらの異なるノードを接続する責任がありますよね。
カスタマーサービスエージェントがあり、それはStrandsですが、注文管理システムに接続するための統合コードを書き、API呼び出しを行うための別の統合コードを書きます。そして、あるエージェントから別のエージェントに接続する際にも、別の統合コードを書くことになります。すぐに、統合コードがコードベース全体の大部分を占めるようになりますよね。ビジネスロジックに集中しているのではなく、これらすべての統合コードになってしまいます。しかし、これらのオープンプロトコルのいくつかを使用してそこで助けを得ることができたらどうでしょうか。
MCPとA2Aによる標準化されたエージェント間通信の実現
すでにおそらく聞いたことがあるものの1つはMCPです。MCPを使用すると、共通のインターフェースを通じて外部データやツールに安全にアクセスできます。AgentCore内にはMCPへの2つの接続ポイントがあります。1つは、独自のMCPサーバーをホストしている場合、またはMCPサーバーのコードを持っている場合、コードの変更なしでruntimeでホストできます、文字通りコードの変更なしです。内部のAWSツールに接続する外部APIやSmithyモデル、または接続したいAPI GatewayセットアップとMCPファイルがある場合は、そのためにGatewayを使用できます。
つまり、AgentCore Gatewayは、既存のすべてのAPIに対してMCPインターフェースを作成するのに役立ちます。AgentCoreコンポーネントを取得してMCPに接続し直す方法が2つあるわけです。これはエージェントからツールへですよね。では、エージェント間はどうでしょうか。名前が示すように、A2Aはエージェント同士が通信したいときのインターフェースを標準化しています。もともとはGoogleによって開発されましたが、その後すぐにLinux Foundationに寄贈されました。
エージェントは異なるフレームワーク、異なる言語、異なるモデルで構築される可能性があり、また異なるプロバイダーから提供されることもあります。しかし、それでもそれらをネイティブに相互通信させたいわけです。そして右側では、A2Aを使って3つの異なるエージェントが互いに通信している例を示しています。A2AはMCPのようなネイティブプロトコルであり、ランタイムでサポートされているため、再度申し上げますが、コードに変更を加える必要はなく、A2Aサーバーを直接ホストすることができます。MCPクライアントと同様に、A2AクライアントをこれらのA2Aサーバーに接続してテストすることもできます。
素晴らしいですね。それでは、あのアーキテクチャ図を少し変更していきます。カスタマーサービスエージェントがあり、青い線で示されているA2Aを通じて別のLangGraphテクニカルサポートエージェントに接続されています。赤い線は現在MCPですので、これはStrandsエージェントからオーダー管理APIへの標準インターフェースとなります。ちなみにこれは、皆さんが持っている内部のAWSセットアップです。また、外部の配送プロバイダーAPIへの別の接続もあります。
Strands、LangGraph、CrewAIとの深いオープンソース統合
例えば、外部の配送プロバイダーAPIのOpenAPI仕様がある場合、それをMCPゲートウェイにインポートすることができます。また、フレームワーク自体からこれらのエージェントコアコンポーネントへのより深いオープンソース統合も用意しています。そのため、この開発の一部を常にオープンソースフレームワークにフィードバックしています。できることの1つとして、Strandsカスタマーサービスエージェントに組み込みのセッションマネージャーを使用し、エージェントコアメモリを追加することができます。つまり、スライドにSTMと表示されている短期メモリと、長期メモリの両方です。
同様に、LangGraphでも深い統合があります。エージェントコアメモリセーバーと呼ばれるものを使用でき、これによってチェックポイントを保存およびロードできます。チェックポイントには、ユーザーとAIの会話やグラフ実行状態などの情報が保存され、それをメモリにロードできます。そして、アプリケーションやエージェントコンテナを再起動すると、コンテナを再ハイドレートして、中断したところから再開できます。LangGraphおよびLangChainとのパートナーシップを継続できることを嬉しく思っており、私たちの例はすべてこれらのオープンソースフレームワークに基づいています。
LangGraphに関しては、LangChain AWSライブラリを介してこれを行いますので、LangChain AWSをpip installできます。これにより、例えば先ほど見たメモリチェックポイントなど、すべてのAWS LangGraphスーパーパワーが得られます。Strandsに関しては、もちろんこれは私たち自身の自社開発エージェントSDKですが、4,000スターと100万ダウンロードを獲得しており、成長を続けています。まだご覧になっていない方は、ぜひチェックしてみてください。始めるのは簡単ですし、たくさんの例も用意しています。私たちはStrandsの主要なメンテナーですが、完全にオープンソースのプロジェクトです。
最後に、CrewAIのような他のフレームワークとどのように協力しているかというと、私たちは彼らのリポジトリに直接貢献を行っています。実際、Arisがブログを公開していますので、そちらをスキャンしてご覧いただけます。CrewAIとAmazon Bedrockを使ってエージェントシステムを構築する内容です。また別に、私はLlamaIndexのRAG実装やagent coreへの統合を支援しました。このような取り組みを今後も継続して行っていく予定です。
では、最後にアプリケーションに話を戻しましょう。今、カスタマーサービスエージェントとLangGraphテクニカルサポートエージェントを実行するために使用されるagent core runtimeがあります。そして、これら2つのエージェント間のインターフェースとしてA2Aがありますよね。次に、各エージェントにアタッチされたメモリリソースがあります。別の選択肢もあります。アプリケーションの設定方法によっては、2つのエージェントが共通のメモリリソースを持つこともできます。しかし、このケースでは、カスタマーサポートエージェントとテクニカルサポートエージェントのために2つの別々のメモリリソースがあると想像してください。そして最後に、外部ツールに接続するゲートウェイもあります。
DevOpsからAgentOpsへ：運用の卓越性の進化
それでは、Arisに登壇してもらい、エンジニアリングチームが従来のDevOpsから私たちがAgentOpsと呼んでいるものへどのように移行しているかについて話してもらいます。ありがとう、Shreyas。さて、agent coreのようなAWSサービスやオープンソースフレームワークを使って強力なエージェントを構築する方法、そしてこれら2つの間の強力な統合について学んできました。次のステップとして、これを本番環境に投入し、もちろん運用の卓越性を実現する方法について考えたいと思います。
次の20分間で、オープンソース分野の主要なプレイヤーと共にここ数ヶ月取り組んできたいくつかのことについてお話ししたいと思います。まず運用の卓越性から始めましょう。従来のソフトウェアエンジニアリングにおける運用の卓越性について考えると、おそらく誰もがDevOpsが重要だと言うでしょうね。そして、DevOpsは一次元的なものではないということにも同意していただけると思います。DevOpsには多くの異なる次元があり、この分野で優れた成果を出すためには、それらを正しく理解する必要があります。
インフラストラクチャから始めて、上から下までインフラストラクチャを管理する必要があります。多くの自動化を備えた適切なツールを選択する必要があります。そして、私たちは皆人間であり、エンジニアリングコミュニティであり、特定の文化を受け入れるプロセスの中で働いています。さて、DevOpsの初期の頃は、これらすべてのことが本当に簡単ではありませんでした。なぜなら、クラウドはありましたが、多くのマネージドサービスがなかったからです。今日私たちが持っているような包括的なツールセットがなかったんですね。
そして、私たちはまだ新しい共通の文化について合意していませんでした。多くのことがまだ非常にウォーターフォール的だったので、エンジニアたちは本当に苦労していました。しかし、私たちAWSはこの10年間でそれを先駆けてきました。多くの組織やオープンソースの世界でも過去10年から15年の間に多くのクールなものを発明してきましたよね。
私たちAWSは、LambdaやEKS、S3、CloudWatchなど、私たち全員の生活を楽にしてくれる強力なサービスを立ち上げてきました。オープンソースの世界から生まれた企業全体もあります。GitHubやDockerを考えてみてください。そして私たちはコミュニティとして、CI/CDによる多くの自動化を伴う非常にアジャイルなソフトウェアエンジニアリングの新しいやり方を受け入れてきました。これは実際に私たちに大きな恩恵をもたらしていますよね。
では、今日お話ししたいのは、従来のソフトウェアエンジニアリングでうまくいっているものをどのようにして、今始まっているエージェント時代へと進化させることができるか、そして発生している新しい機能要件と非機能要件にどう対応するかということです。そして、最後にまとめる前に、一つ一つの柱を順番に見ていきたいと思います。
AgentCoreとLangfuseによるインフラストラクチャとオブザーバビリティの統合
インフラストラクチャから始めますが、先ほど申し上げたように、私たちはLambdaやS3など多くのサービスで、従来のソフトウェアエンジニアリングのためにその分野を先駆けてきました。そして、私たちは皆さんのために再発明することを止めていません。Shreyasが、7月にニューヨークサミットでローンチしたサービスについて言及しました。AgentCoreは本当にエージェントワークロードに特化しています。
もう一度多くの時間を費やすつもりはありません。Shreyasから多くのことを聞いたと思いますし、おそらくこの数日間でこのサービスについて多くのことを聞いたと思いますが、このサービスは本当にこの特定のシナリオで非常に有用です。なぜなら、これはサーバーレスサービスだからです。エージェントを素早く立ち上げることができます。このサービスが基本的に管理してくれることがたくさんあるので、AgentCoreのようなサービスを使うことを強くお勧めします。そして、他の柱を順番に見ていく中で、それがどのように役立つかがわかるでしょう。
それではツールについてお話しします。ツーリングは実際、過去1年から3年の間、非常に活気のある分野でした。組織が構築してきた多くのものがあり、私たちもBedrock内で多くのツーリングを構築してきましたし、AgentCoreでも、オブザーバビリティのプリミティブや、今回のre:Inventでローンチした評価機能などを考えていただければと思います。しかし、オープンソースの分野やスタートアップの分野も非常に活気がありました。私はこの1年から2年の間、多くのスタートアップと一緒に仕事をしてきました。
Y Combinatorのコホートはそういったスタートアップで溢れていましたし、多くの素晴らしいツーリングが登場してきました。今回はエコシステムとオープンソースのセッションということで、本日はその分野に焦点を当てていきます。そしてShreyasがすでに述べたように、私はLangfuseに焦点を当てます。これはagent opsのオブザーバビリティにおける最大級のオープンソースプロバイダーの一つです。
私はこの数ヶ月間、これからご紹介するアプローチを開発するために、Langfuseの方々と強力に協力してきました。しかし繰り返しになりますが、プロプライエタリであれオープンソースであれ、すべてがオープンスタンダードの上に構築されているため、本当に自由に選択できます。そしてオープンスタンダードについて考えると、オブザーバビリティ、オペレーション、DevOps、agent opsにおいて、本当に最も重要なものの一つがOpenTelemetryです。
OpenTelemetryとは何でしょうか？これは新しいものではありません。従来のソフトウェアエンジニアリングでは何年も前から存在していますが、私たちがコミュニティとして行ってきたことは、新たに生じる機能要件と非機能要件に対応できるよう、さらに発展させてきたということです。これは一連のセマンティック規約を定義しており、右側に表示されているものがそれです。つまり、基本的にはデータポイント、つまりテレメトリをオブジェクトでキャプチャする方法を標準化しているのです。
そして、実際にそれらを収集し、いわゆるOpenTelemetryバックエンドに送信する方法も標準化しました。その仕組みは、私たちは皆これらのオープンソースフレームワークを使用しています。それらは自動計装されています。つまり、正しく設定すれば、自動的にメトリクスを収集するコードがすでにその中に入っているということです。
組織やオープンソースによって構築されている標準化されたエクスポーターがあり、それらがデータをエクスポートして、バックエンドにストリーミングしています。そして、これらのバックエンドは、私たちが話してきたプラットフォームになります。つまり、CloudWatchと緊密に統合されている私たちのオブザーバビリティプラットフォーム、あるいはLangfuseのようなサードパーティのオープンソースのものです。
さて、ここで少し時間を取って、Langfuseについてお話しして、皆さんが同じ理解を持っていることを確認したいと思います。Langfuseとは何でしょうか?これは、OpenTelemetryバックエンドの1つであるオープンソースのLLMエンジニアリングプラットフォームです。
これは、トレースとテレメトリをストリーミングして、そこに保存できることを意味します。その上に、活用できる豊富な機能セットがあります。コアオブザーバビリティがあり、エージェントで実際に何が起こっているのかを視覚的に見ることができます。また、プロンプトとデータセット管理、評価、実験、人間によるアノテーションキュー、その他多くの機能もあります。これらのいくつかは、この後使用していきます。
では、 Shreyasがこのセッションで順次構築してきたソリューションアーキテクチャに戻りますが、AgentOpsにとって必ずしも重要ではないいくつかのコンポーネントを削除したことにお気づきかもしれません。私たちが本当にやりたいことは、Langfuseを使用することです。そのため、ホストする必要があります。MITライセンスの下でオープンソースとして提供されているので、必要に応じてAWSアカウントでホストすることができます。マーケットプレイスのオファリングがあり、そこでLangfuse Cloudと呼ばれるLangfuseの完全マネージドSaaSバージョンを選択できます。これは、このセッションの最後に共有するコードリポジトリで使用されているものでもあります。
さて、ここにAgentCore RuntimeとLangfuseを接続する2本の黒い線が見えます。上の線に注目したいと思います。なぜなら、これが実際に稼働する前に 行う必要がある最後のことだからです。トレースのストリーミングがどのように機能するかを実際に設定する必要があります。 難しくはありませんが、設定する必要があるいくつかの項目があります。例えば、テレメトリをストリーミングするエンドポイントや、Langfuseに対してどのように認証するかといった設定をする必要があります。それを行う良い方法は、AgentCoreでエージェントをデプロイする際に環境変数を設定することです。右側でそれを見ることができます。
左側には、基本的にAgentCore用のStrandsにおけるボイラープレートのエージェント実装があります。Shreyasが以前共有したいくつかのことを認識されるでしょう。実際に必要なのは、エクスポーターを初期化する2行のコードを追加することだけです。これにより環境変数が取り込まれ、そして設定がセットアップされると、エージェントを使用している間にLangfuseにトレースが流れ込んでいくのが見えるようになります。このように見えます。タイムスタンプ、エージェントの入力と出力といった高レベルの豊富な情報セットがあります。エージェントがいくつの観測レベルを経ていたか、つまり問題を解決するまでに何回のターンを行ったか、トークン数、レイテンシー、そして多くの情報を見ることができます。そして、異なるトレースにズームインすることもできます。
左上の観測レベルでは、複雑な実行を視覚的に見るための、私たち人間にとって有用なグラフ実行ビューがあります。右側には、私たちが定義したセマンティック規約に基づいてトレースで収集したデータポイントが表示されています。
さて、これでインフラストラクチャとツールを接続しました。何が起こっているかがわかります。次の質問は明らかに、これを活用して本番環境に向けて私たちの生活を楽にするようなプロセスをどのように構築できるかということです。実際、私たちはLangfuseの方々と一緒に始めるための良いアプローチは何かについて多くのことを考えていました。私たちはDevOpsから逆算して作業を始めました。つまり、DevOpsで何がうまく機能しているか、そしてそれをどのように進化させることができるかを考えていたのです。
評価駆動型の3段階アプローチ：実験、QA、本番運用のサイクル
最初に実際に気づいたのは、DevOpsにおける重要な概念はテストだということです。DevOpsはテストなしでは機能しません。Gen AIやエージェントにおけるテストへの類推は、少し複雑ではありますが、評価です。そこで私たちは、エージェントアプリケーションのライフサイクル全体において、評価がどのように重要な役割を果たすかについて考えていました。Evidentlyから実際にそれを示すかなりクールなイラストを見つけました。
私たちは通常、良い実装を見つけ出そうとするモードから始めます。つまり、コードを変更したり、異なるフレームワーク、異なるモデル、プロンプト、ツールのセットを試したりします。何が最も効果的かを見つけたいので、まとめたいくつかのデータセットに基づいて実験を実行し、その上で評価を実行します。これは反復的なプロセスであり、ある時点で私たちは、ある時点で基本的に、本番環境にデプロイするのに十分だと思われる状態に到達します。本番環境にデプロイし、先ほど見たようにトレースを収集し、そして私たちはまず第一にオペレーショナルエクセレンスに向けて努力するフェーズに入ります。
より オンラインでの評価の実行、ダッシュボードの構築、自動アラートの作成といった方法に移行することで、私たちはオペレーショナルエクセレンスに焦点を当てています。システムが適切に動作することを望んでいます。しかし、ループを閉じることも望んでいます。本番環境で起きていることから学びたいのです。つまり、本番環境からの学びをテストデータセットにフィードバックできるということです。データセットの分布が本番環境の実際の分布と一致していないことに気づいた場合、本番環境で起きていることからインスピレーションを得て、新しいことを実装することもできます。それがバグの修正、問題の修正、あるいは次の最良の機能であってもです。
次のステップは、この素晴らしい理論的フレームワークをもう少し具体的にし、後で実装できる順序立ったプロセスにする方法を本当に考えることでした。私たちが考え出したのは、この3段階のアプローチです。まず、何がうまく機能するかを試したい実験とハイパーパラメータ最適化のフェーズから始めます。次に、本番環境に向けてさらに進み、本番環境へのガードレールを設けます。基本的に、すべてが機能していることを本当に確認したいので、QAとテストのフェーズがあり、それをCI/CDで自動化したいのです。なぜなら、それはDevOpsでも非常にうまく機能しているからです。そして本番環境に入り、オペレーショナルエクセレンス、本番環境で機能していることから学び、ループを閉じます。
さて、理論から実践に移り、もう一歩深く掘り下げると、私たちは進化させたいプロセスと文化について話してきました。今度はインフラストラクチャとツーリングの柱に戻って、実際にどのように実装できるかについてお話ししたいと思います。まずインフラストラクチャから始めて、次にツーリングに移りますが、その前に、これらすべてを構築する上で基盤としている2つのコアとなる前提があります。最初の前提は、dev、test、prodといった異なるステージング環境を持つマルチ環境セットアップを使用することを強く推奨しているということです。本番環境で実験して本番アプリケーションのバックエンドを壊したくないので、これは本当に理にかなっています。おそらく多くの方がすでに実装されていると思いますが、もしそうでなければ、強く推奨します。
2つ目は、開発者にとっては議論の余地があるかもしれませんが、エンドツーエンドのリモートクラウドベース開発を強く推奨しています。特にサーバーレスサービスが手元にある場合はなおさらです。多くの人がローカルで開発すること、概念実証のためにローカルでノートブックを使って始めることを好んでいることは知っています。それは素晴らしいことです。しかし、作業が成熟し、多くのチームがそれを行い、多くのユースケースがあると、実際にはもうスケールしないポイントに到達します。リモートにあるModel Context Protocolツールがあり、それは自分が所有していないもので、アクセスできない可能性があります。開発者が数週間の開発作業を費やして、構築したものがローカルマシンでは動作するがターゲット環境では動作しないことに気づくという事態は本当に避けたいのです。これらの前提を踏まえて、さらに進み、実装を開始します。
最初のフェーズは実験とハイパーパラメータ最適化で、一連のハイパーパラメータや実装の中で何がうまく機能するかを見極めたいと考えています。しかし、経験則でいくつか試してみて何が機能するかを見るというやり方ではやりたくありません。確かなデータポイントと実証済みの方法論を持ちたいのです。実際にできることは、Infrastructure as Codeのような自動化の概念を使用することですが、クラウドとAgentCoreを使って数秒でエージェントを立ち上げられるという事実も活用します。これは本当に便利です。なぜなら、エージェントのフリートを起動できるからです。例えば、ハイパーパラメータの組み合わせごとに1つのエージェントです。これはハイパーパラメータ最適化におけるグリッドサーチになります。それらを立ち上げ、評価を実行し、非常に倹約的な方法で再び破棄し、データポイントを取得し、すべての組み合わせをテストし、基本的に意思決定の根拠とできる確かなデータベースを持つことになります。
それでは次に進みます。理想的なセットアップが見つかったら、これをコードバージョニングリポジトリ、GitHub、CodeCommit、お好きなものにプッシュします。これによって自動化されたCI/CDパイプラインがトリガーされ、QAとテストのために使用されます。ここでは別のエフェメラルエージェントをデプロイします、今回は1つのエージェントだけです。テストを実行し、結果を取得します。もし設定した基準を下回っていれば、最初のフェーズに戻ります。しかし、十分に良い結果が得られたと仮定しましょう。そうすれば本番環境にデプロイできます。今度は本番アプリケーションのバックエンドとして使用したい永続的なエージェントになります。
そして本番環境で起きていることから学ぶことでループを閉じます。これがインフラストラクチャ側の話です。では、ツール側ではどのように見えるでしょうか？まず認識しておきたいのは、これら3つのフェーズすべてが、トレースが利用可能であるという概念に基づいているということです。トレースがなければ、エージェントで何が起きているのか分かりません。基本的にトレースが必要なのです。これが、その上に残りを構築していく核となる前提です。
さて、最初の2つのフェーズは、実はある意味でかなり似ています。私たちが設定したデータセットを使用して、主にオフライン評価に基づいた異なる規模の実験を実行しています。主な違いは、それらのフェーズで他のことをテストしたいので異なる評価を使用したい場合があることと、データセットのサイズが変わり得ることです。考えてみてください、最初のステップではエージェントのフリートがあります。もし巨大なデータセットを使用すると、コストがかかります。次のステップでは、テストするエージェントは1つだけなので、同じ予算でもう少し多くのテストサイクルを実行できるかもしれませんが、これは本当に検討する必要があるトレードオフです。
そして2番目のフェーズでは、基本的にもう少しオンラインでの評価方法に移行していきますが、オフライン評価も可能だと思います。そして、Langfuseのクールな機能、アノテーション機能を使用する、または使用したいと考えています。この機能では実際に人間がトレースにアノテーションを付けてそれをデータセットにフィードバックすることができます。
すべてをまとめると、DevOpsをAgentOpsと呼べるようなものに実際に進化させる方法についてお話ししました。これは、サードパーティのオブザーバビリティやエージェントツーリングプラットフォームと統合しているAgentCoreのような強力なサービスで出てきた要件を満たすものです。そして、それらがうまく統合されるため、本当に柔軟性があります。また、ここで提案している新しいプロセスを伴う新しい文化についてもお話ししました。皆さんがこれを受け入れて、このエージェント空間において成功するソフトウェアエンジニアリングの新しい時代を迎えることを願っています。
さて、終わりにしてKeithに引き継ぐ前に、皆さんにいくつかのリソースがあることをお伝えしたいと思います。実際に私たちが構築したものがあります。コードリポジトリがありまして、皆さんの組織内で出発点としてフォークして使用することができます。皆さんの組織とは異なる部分もあるかと思いますが、かなり良い出発点になると思います。そして、今日私が20分でお話しした内容よりも深く掘り下げたい場合は、右側にあるYouTube動画をチェックしてみてください。数週間前にLangfuseのCEOと一緒に録画したディープダイブの動画です。
Cohere Health事例：医療事前承認プロセスにおけるAgentCoreの実践的活用
それでは、Cohere HealthのVP EngineeringであるKeithに引き継ぎたいと思います。彼は今日お話ししたことの多くを、彼のチームと日々の業務で活用しています。ありがとう、Arisさん。Cohereでは最近、AgentCoreのベータ版とローンチについてAWSチームとパートナーシップを組む機会がありました。そして、その上にReview Resolveと呼ばれるものを構築しました。これは事前承認プロセスの改善を推進するために使用している製品です。
事前承認に馴染みのない方のために説明しますと、米国の医療システムでは、臨床医が処置を行う前に、その処置の承認を得るために健康保険会社にリクエストを行う必要があるという一般的な慣行があります。その処置が承認されるかどうかの判断は、ポリシーに依存します。そのポリシーは保険会社によって定義されることもあります。州レベルのポリシーもあれば、連邦レベルのポリシーもあります。これらのポリシーには、処置が承認される前に満たさなければならない医学的必要性のガイドラインがあります。
例えば、膝を怪我したとして、医師と話をして、彼女が膝の手術を勧めたとします。手術を行う前に、彼女は医療保険会社に事前承認リクエストを提出しなければなりません。私たちはポリシーを確認します。ポリシーには、例えば医学的必要性基準の一部として、膝の手術の前に、理学療法のようなより保守的な治療を2ヶ月間試みる必要があると示されているかもしれません。膝の手術の承認を得る前にです。この例は非常にわかりやすいものです。
現実には、アメリカの医療における事前承認プロセスは非常に複雑なものです。年間約350億ドルのコストがかかると推定されています。臨床医にとって膨大な量の管理業務のオーバーヘッドを生み出し、患者との時間を減らしてしまいます。また、患者が必要な適切な治療を受けるタイミングにも影響を与えます。
Cohere Healthでは、臨床医と患者がより早くイエスにたどり着けるよう支援することに注力しています。私たちは多くの自動判定を行っており、事前承認リクエストで受け取った情報、患者に関する臨床情報、そして審査するポリシーに基づいて、場合によっては最大85%の自動承認率を達成できます。しかし、その15%については、臨床医によるレビューが必要になります。私たちは機械学習やAIを使って請求を拒否したり、事前承認リクエストを拒否したりすることは決してありません。しかし、AIとエージェントを使用しているのは、臨床医のレビュープロセスにおいて臨床情報を表面化させ、医療必要性ガイドラインが満たされているかどうか、その処置が承認できるかどうかを判断する手助けをするためです。これにより、事前承認ケースの判定を行うために私たちのレビューツールを使用する臨床医、医師、看護師のレビューが30から40%高速化されるという成果が出ています。
それでは、ここで問題空間と、私たちがエージェントで解決しているいくつかの課題についてお話しします。一般的に、エージェントや言語モデルを扱う場合、レイテンシー、コスト、そして何らかの精度指標の間で最適化を行っていると思います。この場合、私たちにとってレイテンシーとコストは主要な要因ではありません。精度と正確性が最も重要です。私たちの臨床医は、患者が適切なケアを受けられるかどうかを決定する判断を下しています。非常に正確な情報を求めて、潜在的に膨大な量のデータを調べています。
ここでの言語は複雑で専門的です。最先端のフロンティアモデルは、これらのいくつかを拾い上げるのにかなり良い仕事をします。しかし、ここにはいくつかの複雑な問題があります。例えば腰痛は、lower back pain、low back pain、pain in the lower back、LBPと表現されるかもしれません。言語モデルやNLPを扱ったことがある人なら、それらを意味的にグループ化するのはかなり簡単に解決できる問題だと思うでしょう。しかし問題は、それを効果的な方法で行うためには、ポリシーが使用しているのと同じオントロジーとタクソノミーを使用する必要があるということです。つまり、用語の正規化、概念の解決、ポリシーの言語との照合、あるいはポリシーと臨床情報と第三のオントロジーとタクソノミーを取り、すべてをそれにマッピングする必要があります。これは非常に複雑な領域であり、箱から出したばかりの言語モデルでは、これらの問題の多くを処理することができません。
エージェント管理も複雑です。私たちは構造化データと非構造化データの両方を扱っています。構造化データは例えば請求履歴かもしれません。非構造化データは臨床記録である可能性があります。これらのどちらも膨大な量になる可能性があります。そして、この時点で言語モデルを使った多くの作業を行ってきた方なら、精度と正確性に基づいて直感的に、従来のベクトルRAG検索、類似性検索のようなものはここでは特に有用ではないことがわかると思います。有用な場合もありますが、似ているものを探しているのではなく、非常に正確に一致するものを探しているのです。
そのため、モデルで多くのコンテキスト内学習を行う必要があります。つまり、構造化データを渡すということです。また、データの異なる表現も必要です。つまり、構造化データと非構造化データを組み合わせて、例えばグラフ表現にし、エージェントが推論するためにそのデータをどのように取得したいかのオプションを与えることが重要です。
ここには重要な時間的要素もあります。先ほど膝の手術の保存的療法について触れましたが、過去2ヶ月間に患者が理学療法を受けたかどうかを確認するために、臨床データや請求データを見る必要があります。時系列の血液検査値を見ることもあるでしょうし、特定の時間枠内での非常に具体的な投薬情報を見ることもあるでしょう。このような時系列データの取得は、言語モデルが通常あまり得意としないものです。
ここにはコンテキストウィンドウ管理の問題もあります。請求データや臨床データでコンテキストウィンドウを簡単にオーバーフローさせてしまう可能性があります。では、探しているものをどのように絞り込むのか？どのようなヒューリスティックを使って、コンテキスト内でモデルに渡すものを決定できるのか？ここでの評価の範囲は急速に拡大します。異なるデータ表現を扱い、大量のデータを扱い、評価を実行するための多くのグラウンドトゥルースデータが必要になります。ここでの複雑さは急速に増大します。
明らかにこれはAgentCoreのセッションですので、なぜ私たちがAgentCoreを使用しているのかについてお話ししたいと思います。ShreyasとArisが話していたように、bring your own toolingがここでの重要な原則です。私たちはすでにLangGraphとLangChainのエコシステムにいたので、ECSからAgentCoreへかなり迅速に移行することができました。テレメトリと可観測性にはArizeを使用しています。ArisがちょうどLangfuseについて話していましたが、これは素晴らしいです。ArizeにはPhoenixというオープンソース製品があり、これも素晴らしいです。私たちはArizeのEnterprise edition、Arize DXを使用していますが、彼らのオープンソースのPhoenixはLangfuseと比較する上で素晴らしい選択肢です。また、LLMゲートウェイとしてLiteLLMも使用しています。ここにいる方々の中でLLMゲートウェイを使用している方がどれくらいいるかわかりませんが、次のスライドで少しお話しします。
スタートアップである私たちにとって本当に魅力的なのは、最小限、つまりここではインフラ管理がないということです。私のチームがハードウェアやインフラを管理していない時間は、製品開発に集中しています。私たちは規制された業界にいるので、micro VMアーキテクチャ、高速なスピンアップとスピンダウン、レッドメモリがないことは私たちにとって重要です。CLIは既存のCI/CDパイプラインに非常にうまく適合し、OpenTelemetryはArizeへのデータ投入に非常にうまく機能します。これらすべてが最小限のコード変更で、箱から出してすぐにシームレスに動作します。
私たちにとって本当に重要な2つのことは、AgentCoreゲートウェイとガバナンスとセキュリティであり、これらは非常に密接に結びついていると考えています。例えば、請求関連の専門サブエージェントがあるとしましょう。これは患者の請求データを取得し、請求履歴内のデータを検索できるものです。内部的に、請求情報とやり取りするための異なるエンドポイントを持つAPIがあるかもしれません。素晴らしいのは、その前にAgentCoreゲートウェイを配置できることですが、重要なのは、セキュリティバイデザインの観点だけでなく、コンプライアンスバイデザインの観点から、レビューセッションでメインエージェントと誰がやり取りしているのかを知る必要があるということです。
サブエージェントがクレームデータを見るための呼び出しがあった場合、そのサブエージェントへの呼び出しを行ったユーザーのアイデンティティは何でしょうか?そのユーザーは何を見ることを許可されているのか、そして彼らがアクセス権を持つ患者の情報のみを取得できることを保証できるでしょうか?これはコンプライアンスと監査にとって非常に重要です。Shreyasは短期記憶と長期記憶についても言及しました。短期記憶はテキストとバイナリデータをサポートします。彼はLangGraphのチェックポイント機能について言及しましたが、これはバイナリデータを使用する必要があります。AWSチームによる非常に簡単なプラグインで、LangGraphに組み込んで短期記憶ストレージを取得できます。
長期記憶はもっと複雑だと思います、使用しているフレームワークに関係なく。私たちが有用だと感じたことの一つは、マルチテナント環境を管理するための名前空間です。ここではメモリアーキテクチャについて時間をかけて考える必要があります。これは、短期記憶よりもかなり複雑だと言えます、特に複数のエージェントがある場合は。では、ここで私たちのアーキテクチャについて少しお話しします。そうですね、ここにポインターがあればよかったのですが。
複雑に見えますが、実際には複雑さは軽減されています。私はCohere Healthプラットフォーム内にある一つのエージェントだけを示していて、ちょうど真ん中にチャットボットスーパーバイザーが表示されています。これはLangGraphで動作していて、そこでAgentCoreの短期記憶に接続しています。先ほど言ったように、非常にシームレスな統合です。チャットボット自体、つまりこの特定のエージェントは、マイクロVM上のAgentCoreインフラストラクチャで動作しています。私たちのトラフィックはすべてLiteLLMを通じてBedrockに流れています。LiteLLMはAIゲートウェイです。もしこれらのいずれかを使ったことがない場合、これは異なるモデルプロバイダーと通信するためのリバースプロキシのような機能を果たします。レート制限、ユーザーごとのトークン使用量の洞察、コスト管理など、本当に素晴らしい機能を提供してくれますし、共通のガードレールを設置することもできます。
私たちは主にBedrockを使用していますが、LiteLLMの背後にGeminiやOpenAIの何でもシームレスに組み込むことができます。LiteLLMの前にいるクライアントがそれらを使いたい場合、実際にはAPIキーとモデルの名前を変更するだけです。他のすべての作業はゲートウェイ経由で処理されます。左側にArizeのプロンプト管理を使用しているのが見えます。これについては後ほどお話しします。私たちにとって、プロンプトをアプリケーションコードから分離する傾向があります。そうすることで、コードとは別のプロンプトのライフサイクルとデプロイメントライフサイクルを持つことができます。コンテナを再デプロイすることなくプロンプトを更新できます。
下部には左下にindication level LLMプロンプトの表示が見えます。そのクレームエージェントについて少し考えてみると、このスーパーバイザーエージェントがあって、それが医師や看護師が対話しているものです。クレーム用の特殊なサブエージェントへの呼び出しを行うかもしれません。Model Context Protocolについて話すときに、私たちがよく話していると感じることの一つはツールです。Model Context Protocolでプロンプトをどのように使用するかは本当に興味深いと思います。それについてはあまり見かけません、もしかしたら私が間違った著者を読んでいるのかもしれませんが。しかしこの場合、医療必要性基準をそのクレームエージェントに渡すことができます。それはどのクレーム履歴を取得したいかを決定し、また医療必要性基準、つまり私たちが使う用語ではindication levelが何であるかを選択できます。クレーム履歴でこの情報を探すために、どのプロンプトを取得したいのか?
これは、ファインチューニングされたモデルを含め、臨床データ抽出を処理する複数の方法があります。しかし、これは特に興味深く、また評価の複雑さを増すものでもあります。強力な方法論ではありますが、臨床領域が拡大し、プロンプトの数が増えるにつれて、そのサブエージェントに対して正しいプロンプトを取得し、そのデータに対して正しい方法で適用して求めている情報を得られたかどうかを評価できることが、実行しなければならない別の評価セットになります。セッションレベルの評価の発表は本当にエキサイティングです。エージェント的なインタラクション全体にわたって評価を実行できることは、本当に重要です。
それでは、ここで評価について簡単に触れたいと思います。私のスライドはArisのものよりもずっと情報量が多いです。先ほど述べたように、私たちはすでにArizeのエコシステムに入っています。オンライン評価があり、LangGraphとAgentCoreから、Arizeにデータが流れています。それを私たちのオンライン評価にパイプすることができます。そこでLLMをジャッジとして、ハルシネーション率のようなものを見ることができます。ガードレール違反を見ることもできます。オンライン評価で見たいと思うものは数多くあります、特にパフォーマンスが何らかの形で変化しているかどうかを判断したい場合には。
また、ここでオフライン評価にも接続しています。スタッフには臨床医、医師、看護師、専門家がいるので、ここでループに人間のアノテーターを入れることができます。それらすべてをオフライン評価プロセスに投入して、特定のプロンプトの有効性、ファインチューニングされた小規模言語モデルの有効性、エージェントシステムまたはエージェント呼び出しのセット全体の有効性を判断しています。そして、Langfuseと同様に、私たちはすでにこのようなものを持っていました。これをほぼそのまま維持し、AgentCoreにプラグインして、必要な方法ですべてのデータをハイドレートすることができました。
セッションまとめ：AgentCoreとオープンソースエコシステムの統合価値
私からは以上です。Shreyasに戻します。ありがとうKeith、そして、要約すると、私たちが見たのは、複数のオープンソースフレームワークやプロトコルと統合できるAgentCoreでした。ArisはAgentOpsとLangfuseとのより深い統合について説明してくれました。そして、Cohere Healthの本当にエキサイティングな実世界のアプリケーションも見ました。このスライドをここに表示しておきますので、スキャンしてください。 私たちが切り替えるときに、皆さんが急いで素早くスキャンしようとしているのは知っています。セッションにご参加いただき、本当にありがとうございました。有益な内容だったことを願っています。後ほど質問を受けるために、ここでしばらく待機しています。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion