re:Invent 2025: Cox AutomotiveのBedrock AgentCoreで5週間3本番展開の実践
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Cox Automotive's Blueprint for Agentic AI on Amazon Bedrock AgentCore (IND3329)
この動画では、Cox AutomotiveがAmazon Bedrock AgentCoreを活用してAIエージェントを本番環境へ移行させた実例が紹介されています。同社はわずか5週間で5つのagentic AIプロジェクトに挑戦し、3つを本番環境へデプロイしました。特にディーラーシップ向けの完全自動化された仮想アシスタントは、営業時間外のリード対応を実現し、顧客応答率を50%向上させています。実装にはStrandsフレームワークを採用し、AgentCoreの基盤上に構築することでフレームワーク変更をわずか2週間で完了させました。成功の鍵として、red teamingによる脆弱性テスト、Hard/Soft guardrailsの設計、LLM as a judgeを用いた自動評価、circuit breakerによるコスト制御が挙げられています。非決定論的なシステムの特性を理解し、Day Oneの精神で即座に行動を起こすことの重要性が強調されました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AIエージェントを本番環境へ：Cox Automotiveの挑戦
皆さん、こんにちは。本セッションへようこそ。私はAWSのシニアソリューションズアーキテクトの Ravi です。本日は、Enterprise Architecture の Associate Vice President である Brian Lloyd Newberry と、Cox Automotive のリードアーキテクトである Tabaré Gowon が参加しています。本題に入る前に、ちょっと質問があります。皆さんの組織で AI エージェントの実験をしている方はいますか？本番環境にデプロイして、スケールで運用している方は手を上げたままにしてください。ご覧の通り、手が下がりますね。これが今日お話しする内容で、Cox Automotive のこの課題に対するブループリントをご紹介します。
こちらがアジェンダです。まず私が Amazon Bedrock AgentCore について簡単に紹介してから、Brian Lloyd Newberry にバトンタッチします。彼は Cox Automotive の agentic AI の取り組みと成功のブループリントについてお話しします。 その後、Tabaré がリファレンス実装、重要な検討事項、そして実戦から得た教訓をご説明します。質問があればお答えしますので、さっそく始めましょう。
私たちが見ている最大の課題は、エージェントをプロトタイプから本番環境へ移行させることです。そもそも AI エージェントとは何か。それは自律的なシステムで、推論し、意思決定を行い、ツールを使ってアクションを取り、目標を自律的に達成できるものです。皆さんの概念実証は素晴らしく機能しますが、実行時に対処しなければならない 5 つの重要な課題があります。長時間実行されるワークフローと複雑なオーケストレーションをパフォーマンスのオーバーヘッドやコストの超過なしに実行するための、スケーラブルなインフラストラクチャが必要です。
エージェントはコンテキストを維持し、セッション間でエンドカスタマーと意味のある会話を行う必要があるため、マネージドメモリソリューションが必要です。エージェント自体、それらがアクセスするツール、そしてデータへのセキュアなアクセスが必要です。エージェントが既存のシステムを agent-ready ツールを通じて発見し、他のエージェントとシームレスに通信するためのメカニズムが必要です。エージェントは本質的に非決定論的であるため、その実行を完全に可視化して、トレース、デバッグ、動作を評価できる必要があります。
サービス技術者アシスタントの事例とAmazon Bedrock AgentCoreの機能
例を挙げて説明しましょう。サービス技術者アシスタントを想像してください。顧客がチェックエンジンライトが点灯した状態で来店します。技術者はダッシュボードの写真を撮り、エンジン音を録音し、顧客の懸念事項を入力します。エージェントはこのデータを使用し、OEM マニュアル、技術サービスブレティン、リコール通知などの知識ソースを参照して、適切な診断計画を立案します。
テクニシャンが作業を始めると、別の問題が見つかります。そうするとエージェントは適応して、異なる推奨をしなければなりません。このように、車を診断して適応させるというやり取りが続いていくわけです。エージェントがサービステクニシャンが車を修理するために部品が必要だと判断します。その後、エージェントは内部システムにアクセスして、価格、在庫、入手可能性をチェックしながら、顧客の好みを念頭に置きます。この顧客は品質の高い OEM 部品を好むとか、この顧客は予算を重視しているとか。そして部品を推奨します。部品が在庫にない場合、エージェントはレガシーサプライヤーアプリケーションやウェブアプリケーションにログインして注文を発注しなければならないかもしれません。
この修理には数時間かかることもあり、エージェントはセッション全体を通じて対応を続けます。顧客が数週間後に戻ってきたとき、エージェントはすべてを覚えていて、診断プロセスを再開する必要があります。さて、このインフラ全体がスケールアップして、複数のテクニシャンをサポートし、完全なセッション分離で複数の顧客の問題に対応することを想像してください。エージェントが特定の診断ステップを推奨した方法と、それが使用したソースのすべてを追跡して、完全なデバッグと評価を行う必要があります。これらの機能がなければ、プロトタイプモードに留まったままだと私たちは考えています。そしてそれが AgentCore が埋める隙間なのです。
AgentCore は、2つの特別な目的のツールを備えた5つの完全に管理されたサービスを提供しています。Runtime はセキュアでスケーラブル、サーバーレスです。最大 100 メガバイトのペイロードを持つマルチモーダル入力をサポートし、最大 8 時間のロングランニングセッションに対応しています。任意のフレームワークを使用してエージェントを構築でき、任意のモデルと一緒に使用できます。
Memory は、会話状態を保存するための短期メモリと、顧客インタラクションから抽出して学習し適応するための長期メモリを提供します。ユーザー設定、セマンティックファクト、要約など、すぐに使える戦略があります。これらの戦略を使用することも、上書きすることも、独自の戦略を持ち込むこともできます。 Identity は、セキュアな認証と認証情報管理を提供します。OAuth と IAM をすぐにサポートしています。 Gateway は、既存の API と Lambda 関数をエージェント対応の MCP ツールに変換し、インテリジェントな検出のための組み込みセマンティック検索メカニズムを提供します。Observability は、すべてのインタラクションに対する完全な可視性を提供します。
エージェントのパストラジェクトリには、すぐに使える CloudWatch ダッシュボードが含まれており、OpenTelemetry フォーマットを介して既存の observability スタックと統合されます。 Browser により、エージェントは複雑なウェブオートメーションタスクを実行でき、code interpreter により、エージェントはセキュアなサンドボックス内で任意の言語で複雑なアドホック計算を実行できます。これがエージェントを本番環境に導くインフラだと私たちは考えています。では、Cox Automotive のエージェンティック AI ブループリントについて説明するために、BLN にバトンを渡します。
Cox Automotiveの事業概要とagentic AIへの取り組み
よろしく、聞こえていますね。私の名前は Brian Lloyd Newberry で、みんなは私のことを BLN と呼んでいます。なぜそう呼ばれているのか知りたければ、トークの後で喜んでお話しします。私は Cox Automotive の Product and Technology Innovation lab をリードする幸運に恵まれています。私と小さなチームは、過去3年間、生成 AI に完全に没頭し、agentic software へ移行するこの旅に取り組んできました。まず Cox Automotive についてご紹介したいと思います。というのも、このブランドや Cox Automotive という企業体をご存知ないかもしれないからです。ですが、車を探したり、車を買ったりしたことがあれば、AutoTrader.com や Kelley Blue Book といったブランドを聞いたことがあるかもしれません。これらは自動車業界で最大級のコンシューマーポータルです。人々は毎日これらを使って車を買っていますし、私たちはそこで大量のトラフィックを得ています。
私たちはアメリカの大多数の OEM、つまり自動車メーカーのウェブサイトを作っているので、そこでも大量のウェブトラフィックを見ています。コンシューマースペースでは、膨大なコンシューマー情報が集まってくるのを見ています。また、私たちは自動車市場に流動性をもたらしています。車をトレードインしたことがあれば、その車はおそらく Mannheim Auctions を通じて流動化されており、ディーラーがそれを売却し、Mannheim Auctions から他の車を買って他の人に売っています。また、ERP、カスタム CRM、インベントリ管理といったディーラーソフトウェアの全スイート、および金融アプリケーションのスイートも提供しています。モビリティや他の分野にも進出しています。私たちは自動車業界のソフトウェアプロバイダーとしての支配的なプレイヤーです。
業界でそれほどの可視性を持っているため、起きていることすべてを見ることができます。私たちは毎日自動車業界を見ています。ざっくりした数字として、市場の車に関する約5.1兆のインサイトを持っています。人々が車を見たり、車をサービスしてもらったり、そのライフサイクルを通じて移動する際に、何億もの顧客インタラクションを見ています。私たちはそのすべての情報、つまり AI の血液ともいえるものを取り、それを AI モデルでラップしています。私たちはかなり前から AI をやっています。本番環境に数百の AI モデルを持っています。先月超えた閾値は150何かだと思います。そのいくつかはヒューリスティックかもしれません。
今日私がしたいことは、組織としてどのように動き始めることができるかをお話しすることです。組織全体の product チームや engineering チームと一緒に仕事をする中で見ていることの一つは、agentic AI でたくさん遊んでいるということです。ただし、ほとんどの場合、人々は agentic AI ではなく、単に assistant で遊んでいるだけです。生成 AI がたくさんあり、いろいろ試行錯誤していますが、人々は agentic アプリケーションが何であるか、どのように動き始めるか、どのように構築するかを本当には理解していません。私たちの chief product officer にはこんな言い方があります：「crazy から始めて逆算する」。ですから、私は先月の8月に実行した crazy な実験についてお話しし、その後 Tabaré が私たちが開始した特定のプロジェクトの一つがどのように進んだかをお見せし、それからまとめます。
Generative AIからagentic AIへの進化と5週間チャレンジ
私が言ったように、私たちはこの旅に長い間取り組んでいます。私たちのオークションプロバイダーである Mannheim は、おそらく現在80年ほど前からあります。2018年に、私たちは AWS に全力投球し、50のデータセンターから3つに移行し、残りは AWS リージョン（東と西の両方）で実行されています。私たちは従来の機械学習モデルを使用して、非常に長い間予測 AI をやってきました。
Kelley Blue Book、つまり人々が中古車の価格を調べるために実際に買っていたあの小さな本ですが、これは100年にさかのぼる車の評価の数学的な集約だったんです。2023年に何かが起きました。2022年11月30日、OpenAIがChatGPTをリリースしたんです。ChatGPT 3モデルが公開されて、すごく話題になりました。私たちはこれらのモデルが存在することを知っていて、ずっと注視していたんですが、これが本当に大きな話題を呼んだんです。
そして2023年3月に、私たちはGenerative AIに全力で取り組むことにしました。私が今リードしているチームを使って、1ヶ月以内に複数のプロバイダーとモデルを私たちの環境にアクセスできるようにしました。サンドボックスを構築して、プロダクトの開発を始めて、その翌年には3つの大きなプロダクトが本番環境で動いていました。そのうちの1つは、他の場所でコンテンツを生成するために支払う必要をなくすことで、年間約75万ドルを節約でき、さらに私たちのコンテンツはより良く、より速くなりました。また、ディーラー向けのプロダクトも開発して、顧客からの応答率を50パーセント増加させることができました。他にもいろいろなプロダクトを作りました。
そのGenerative AIモデルを動かすために、私たちは本当にデータに焦点を当てて、すべてのデータを一緒に集約することに力を入れました。2024年、Amazon re:Inventから帰る途中に、私たちは新しいイニシアティブをローンチしました。agentic空間に飛び込んで業界に先んじるために、いくつかのチームを立ち上げました。そこには多くのFUDと興奮がありましたが、実質的な内容はそこまでありませんでした。私たちは膨大な作業をして、内部アプリの構築とProof of Conceptの実施で本当に成功しましたが、私たちはある種の行き止まりに達してしまいました。プロダクトからの実際の引き合いがそこまで多くなかったんです。
本番環境でGenerative AIを使用している4つか5つのプロダクトがあり、そのうちのいくつかは内部向けで、残りは外部向けでしたが、プロダクトチームからの実際の引き合いが見られませんでした。みんなやることがあって、自分たちがやっていることを混乱させたくなかったんです。みんな怖かったんです。もし私たちが全員座って、agentとは何かを聞いたら、実は議論が起きると思います。Agentic applicationについて、人々はGenerative AIインターフェースが付いたチャットボットのようなものだと考えていて、これはagenticAIの非常に素朴なバージョンです。Google Deep Researchは、この種のシステムの真の力を示す最初の例の1つです。
高校の物理のNewtonの原理に戻ると、慣性、運動量、反作用があります。あなたがすべきことは、どうやって動き始めるかを考え出すことです。何も変えていなければ、何も変わりません。動き始める必要があります。agenticAIシステムを構築することの専門家は誰もいません。これはここ1年くらい存在しているんですよね。数学の博士号を持っていても役に立ちません。なぜなら、これはソフトスキルだからです。システムを見て、システムモデリングをして、これらのLLMsにものをさせるのを助けるテキストを書くことです。何か1つ選んで、チームを動かし始めてください。
では、この大変なことについて少し話しましょう。7月の第2週、私たちのチーフプロダクトオフィサーが「Labor Dayまでに5つのプロダクトをローンチしたい、そしてそれらはエージェンティックAIプロダクトで、市場に全く新しいプロダクト機能をもたらすものになる」と言ったんです。私たちは「わかりました」と答えました。私たちはいろいろなものを構築していて、それができることを知っていたのですが、5週間でやらなければならず、私たちが持っていたチームはエージェンティックAIプロダクトを構築したことがなかったんです。Tabaréとそのチームは少し構築していましたが、彼らは少し先を行っていたものの、そこまで遠くはなく、私たちはゼロから始めていたんです。
チーフプロダクトオフィサーとプロダクト・テクノロジーのEVPが「Labor Dayまでに5つのプロダクトをローンチする」と言っているときに、あなたは何をしますか？5つのチームでゼロから始めていて、白紙の状態という問題を抱えているので、パニックになります。急いでデッキを作らなければならないときのようなものです。どこに行ったらいいのか分からない、どう動いたらいいのか分からない、身動きが取れない。では、加速するために必要なことはここです。目標を持つ、期限を設定する、そして興奮を生み出す。私たちは5つのプロジェクトを5つのチームで本番環境にする目標を持っていました。期限はLabor Dayで、その時点から約5週間半でした。そして私たちが行ったことは、その5つのチームを1つの部屋に集めたので、興奮がありました。
私たちはそれについて大きな騒ぎを立てました。それは大きなイベントで、私たちはこの難しいことをやると言いました。5つのプロダクトをローンチするんだ、そしてこれがプロダクトだ。完全には詰められていませんでしたが、それらの周りに良いコアがあり、私たちはエージェンティックAIを使ってそれらを提供し、市場にもたらす解決策を実現するつもりです。だから興奮があります。では、次に何をしますか？私たちの資産は何か？ギャップは何か？では、進みましょう。
Amazon Bedrock AgentCoreとStrandsフレームワークの選択
では、私たちは何を持っていますか？私たちはAWSに全力を注いでいました。彼らとは密接なパートナーです。私たちは彼らのプロダクトロードマップを理解していて、Bedrockに深く関わっていました。私たちはBedrockモデルを本番環境で実行している最初の顧客の1つで、Cloudへのアクセスでは最初でした。私たちは小さな内部専門知識チーム、このタイプのアプリを構築した数チームを持っていて、いくつかのアイデアを持っていました。それらが良いものかどうかは、まだ分かりませんでした。私たちはそれらを本番環境に入れる必要があり、5つのものをローンチしなければなりませんでした。これが私たちの在庫です。
では、私たちに必要なものは何ですか？私はアーキテクトで、白紙のページはアーキテクトにとって怖いものです、特に新しい分野ではそうです。だから、reference architecture placematから始めます。これが私たちが取り組んで作業したものです。このグレーの大部分は私たちがすでに解決していたものですが、ここにはたくさんの白いボックスがあり、私たちが理解する必要があったものです。コスト管理、モデルモニタリング、オーケストレーション、エージェントワークフロー、ツール、APIマネジメント、そしてそれを私たちのデータに接続する方法と何が起こっているのかを見る方法のようなものです。
Ravi が話してくれた AWS の Bedrock と Agent Core の製品について、ストーリーがどこに向かっているかはもうご存知ですね。でも、これは多くのチームにとって本当に怖い問題なんです。なぜなら、真っ白な状態から始まるからです。何をすればいいのか分からないんですよ。 では、私たちは何をしたか。Amazon Bedrock を使っていて、ここに留まろうと決めました。リスクを取って Agent Core に飛び込もうと。Agent Core はまだリリースされていませんでした。これらのプロジェクトが終わった後にリリースされたんです。私たちは市場に製品をリリースしたことがなくて、その時点ではハイパースケールされていませんでしたが、第一世代のテクノロジー製品を市場に投入することはしません。ここではそうしました。AWS とパートナーシップを組んだからです。ロードマップを見て、何があるのかを理解して、自分たちで構築するのがどれだけ馬鹿げているか、そしてチームが自分たちで構築方法を考え出さなければならないのがどれだけ馬鹿げているかを知っていたんです。Ravi が先ほど話していたことの一部を聞きましたね。
次に私たちが下した決断は、どの agentic フレームワークを使うかという話に入ることです。冗談ではなく、本当のことなんですが、2～3日ごとに新しい agentic フレームワークが出てきます。ここ1年以上、毎日新しいモデルが出てくるのと同じようにね。1つ選んで進めてください。ここでやっていることについては次に話しますが、ピボットして変更する能力があります。特に Agentic AI を使ってその作業を手伝ってもらっている場合はね。物事を選んで進めてください。Strands は AWS がバックアップしているオープンソース製品で、ネイティブに実行され、私たちが始めた時点では Agent Core 上で実行する最良の選択肢でした。そして、私たちが必要としていたすべてのニーズを満たしていました。
もう1つのポイントは、Agent Core は他のフレームワークも実行できたし、5つのチームそれぞれに異なるフレームワークを与えることもできたかもしれません。でも、もしかしたら何か学べたかもしれません。でも、私たちは本当に5週間で市場に出たかったので、1つのことを学ぶことに全力を注いで、それを本当に上手くなって、チームを支援したかったんです。フォーカスはこれの重要な部分です。Strands について ハイレベルなアーキテクチャレベルで少し話しました。エージェントを構築することについて、どれだけ魔法のようなのか、そして保守しなければならないすべてのことについて話しますが、開発者として自分でエージェントを構築するとき、エージェント内でやることはほんの数個のコアなことだけです。
1つ目は、テキストを書くことです。これはプロンプトです。2つ目は、設定を行うことです。これは通常、テキストでも書かれています。3つ目は、それをモデルにアタッチすることです。設定パラメータを使ってね。そして、それをツールにアタッチします。それがツールに物事をさせることを可能にします。概念的には、Strands でやることはこれだけです。本当に考えるべきことは、書くテキストが何か、使うツールが何か、そしてその非常に抽象的なシステムをどのように現実にするかだけです。文字通り、Python を設定として書いているだけです。
Strands のウェブサイトからのこの非常にシンプルなケースでは、エージェントを持ってきて、既に存在する calculator ツールを持ってきます。今日はそのツールの実装を見せる時間がありませんが、もし見たなら、Python のドキュメンテーションがツールが何か、いつ使うか、パラメータ値が何を意味するかを説明しているのを見るでしょう。ちょうど、あなたが書くべき任意の Python またはソースコードと同じようにね。それはよくドキュメント化されていて、Strands フレームワークはそれを持ってきて、自動的にワイアリングすることができます。
では、そのエージェントに「その数字の平方根は何ですか？」と言うわけです。ちなみに、これが LLM が実際に数学の問題を解く方法です。あるいは、解くべき方法です。決定論的なプロセスに頼るべきなんです。本当にそれだけシンプルなんですよ。Strands はデスクトップで実行することも、AWS インフラストラクチャで数分で実行することもできます。ここでの重要なメッセージは、始めることです 。そして、チームをフレームワークやインフラストラクチャではなく、機能と機能性に集中させることです。言語は関係ありません。私があなたのために書くことができます。フレームワークも関係ありません。100 個もあって、どれもほぼ同じことをしています。本当にサポートが充実しているものを見つけて、それを実行してください。皆さんは AWS カンファレンスにいるので、AgentCore と Strands から始めてください。必要に応じて他のフレームワークを使用することができます。
仮想アシスタント開発の実践：基盤構築からガードレール設計まで
Tabaré を招待したいと思います。Tabaré は、私たちが立ち上げたプロジェクトの 1 つのリード アーキテクトで、おそらく最も成功したプロジェクトで、今日最も多くの顧客が使用しているプロジェクトです。彼は、彼が学んだことと、そのプロジェクトの過程がどのようなものだったかについて話してくれます。その後、私たちは一緒に、残りのプロジェクトがどのように進んだかについてまとめます。では、マイクは入っていますか？素晴らしい。わかりました。ありがとうございます。皆さん、こんにちは。私の名前は Tabaré Gowon で、先ほど述べたように、Cox Automotive のリード アーキテクトです。ちょうど先ほど、私たちのエージェンティック ジャーニー、私たちの会社全体のエージェンティック戦略、そしてこれらの原則を使ってどこに向かっているのかについて、皆さんと共有しました。今、Cox Automotive のプロダクト チームで、それが実際にどのようなものだったかについて、皆さんを案内したいと思います 。そして、独自のエージェンティック ソリューションを構築するのに役立つパターンをいくつか皆さんに残したいと思います。もちろん、私たちがどのようにしてここに到達したのかを皆さんに説明する必要があります。
では、最初から始めましょう。先ほど述べたように、2022 年から 2023 年頃で、LLM が ChatGPT などでメインストリームに入ってきた時期です。私たちのチームのようだったなら、この時期に、このテクノロジーは実は結構いいな、どうやって使おう、ここに入れたらどうだろう、あそこに入れたらどうだろう、と考えていたと思います。私たちのチームは 2023 年の終わりに最初の GenAI PoC を開始し、今年の初めに、Predictive Insights という製品を実際に立ち上げました。これは、私たちの会社の CRM のための人間参加型の GenAI メッセージ ジェネレータです。
Predictive Insights では、ディーラーがボタンをクリックすると、先ほど述べたすべてのデータを使用して、顧客に対してパーソナライズされたメッセージを作成できます。今年の初めに立ち上げて以来、私たちは多くの良い評価を受けています。ディーラーは、シンプルなクリックで顧客をカスタマー ジャーニーに沿って進めることができるので、気に入っています。しかし、私たちには問題があります。Predictive Insights では、実際にボタンをクリックしてメッセージを生成する必要があります。しかし、現実は、ディーラーシップでは、営業時間外に来るリードが半分以上あり、その時間にはボタンをクリックする人がいないということです。
そこで、私たちは自分たちに言いました。これはうまくいっているな。では、私たちが今構築したものを取って、完全に自動化された状態に移行するにはどうしたらいいだろう。そのプロセスの中で、実際の質問は、ユーザーが信頼できる自動化された AI ソリューションをどのように構築するのか、ということに気づきました 。ディーラーの声を知り、ブランドを知り、一日中いつでも顧客に対応できるソリューションを構築する必要があると言うのは 1 つのことです。しかし同時に、人間の監視なしに、私たちとディーラーの安全性とブランド評判を維持しながら、それを行う必要があります。それが課題になり、ここが私たちが構築したものです。
これは、ディーラーシップでの 顧客との会話に対応する、完全に自動化された仮想アシスタントです。Amazon AgentCore と Strands agent framework の上に構築されています。トップから見ると、オーケストレーターがあります。顧客が新しいメッセージを送信すると、オーケストレーターはそのインテントを理解し、そのメッセージを複数のサブエージェント（sales、service など）のいずれかにルーティングします。各サブエージェントは独自のドメインを理解し、会話の自分の部分を独立して処理できます。
すべてのサブエージェントが完了すると、オーケストレーターはそのすべての結果データを取得し、顧客へのメッセージを作成して、会話を続けます。これは会話が必要な限り、行ったり来たりを繰り返します。このダイアグラムでわかるように、この話にはもっと多くのことがあります。すべての技術的な詳細を提供することもできますが、実際のところ、こうしたプロジェクトを開始するとき、実際にはどこから始めるのでしょうか？あなたは基盤から始めるのです。そしてその基盤が Agent Core です。
会話型アシスタントを構築するとき、必要なことの 1 つは、データを分離しておくことです。先ほど述べたように、皆さんの多くはこれらの AI フレームワークが毎日変わることをご存知です。ですから、今日ソリューションを構築するために使用するツールは、明日使用するツールではないかもしれません。ビジネスの進化に伴って進化できる、安全で信頼性の高いものの上にインフラストラクチャを構築する必要があります。そしてここで Agent Core が登場するのです。
Agent Core はデータセッションを分離した状態に保ち、スタック全体を再構築することなくフレームワークを入れ替えることができます。私のチームがプロセスを開始したとき、複数のソースから受け取ったガイダンスは Agent Squad（これは AWS Labs だと思います）から始めることでした。しかし、プロジェクトの中盤に到達するまでに、新しいガイダンスは Strands agents を使用することでした。これはより良いソリューションです。昔は、これはプロジェクトの移行に数週間かかる可能性がありましたが、堅牢な基盤から始めたおかげで、わずか 2 週間で済みました。
ソリューションを構築するときは、ビジネスとともに進化できる基盤から始めてください。これにより、安全性のように、実際にあなたのドメインに関係する問題について考える余地が生まれます。これらのエージェンティックなソリューションをどのように安全に保つのでしょうか？私たちの場合は、red team を行っています。
Red teaming というのは、システムを意図的に脱線させようとすることで、いろいろなやり方があります。例えば、私たちのアシスタントの場合、外国語で質問してみるということができます。別のやり方としては、読み取り不可能な文字列をアシスタントに入力してみるとか、もし工夫を凝らそうとするなら、アシスタントに甘い言葉をかけてシステムプロンプトやツール定義を引き出そうとするとか、そういったことができます。基本的には、システムの失敗モードを見つけようとしているわけです。
Testing は何が機能するかをチェックしますが、Red teaming は実際にそれを壊そうとします。このタイプのソリューションは最後に残しておくことはできません。私たちの場合、Alpha フェーズの前、Beta フェーズの前、そして本番環境に移行する際も Red teaming を行っています。すべてのエクスプロイトをカタログ化して、それを修正して、次のものに反復していきます。コードをデプロイするたびに、プロンプトを変更するたびに、これを行います。現実的には、ステークホルダーはこのシステムがどのように壊れるのかを聞いてくるからです。これをやっておけば、何が悪くなる可能性があるかについての答えと例の両方を持つことになり、もちろんそれを修正する必要があります。
では、これらのソリューションをどのように修正するのでしょうか？Guardrails を使います。 Bedrock guardrails について聞いたことがあると思います。ほとんどの人が、AI が脱線するのを防ぐために何かが必要だということを知っています。それは当たり前です。しかし、カスタマーサービスを扱う場合、ブロッキングだけに焦点を当てると、顧客体験が悪くなってしまいます。私たちの考えでは、Guardrails を少なくとも 2 つの観点から考える必要があります。システムを完全にブロックするもの、そして会話を別の方向へ優しく導くもの、つまり実際に何かをしたい方向へ導くものです。これらを Hard guardrails と Soft guardrails と呼んでいます。
Hard guardrails では、システムは LLM と通信さえしません。通常、これらの Guardrails は一番上に位置していて、「申し訳ありませんが、それはお手伝いできません」といった応答をするものです。そして会話は終わります。これらは Bedrock guardrails で設定できるものです。一方、Soft guardrails は LLM を使いますが、ワークフローやプロンプト設計で設定します。例えば、自動車業界向けの仮想アシスタントを作成したとしましょう。顧客との会話の過程で、顧客が「この車は本当に気に入っているんですが、クレジットスコアがあまり良くないので、月々 100 ドルから 150 ドルくらいで購入できたらいいなと思っているんです」と言ったとします。
仮想アシスタントは多くの問題を解決するように設計されていますが、価格交渉を処理させたくはありません。Soft guardrails を使う場合、システムが「それは Finance チームにぴったりな質問ですね。予約を入れさせていただきます」と応答するようにシステムをチューニングします。このような Guardrails により、安全を保ちながら役に立つ対応を続けることができます。Guardrails についてこの両方の観点から考えてください。
すでにたくさんお話ししてきました。ここで一度立ち止まりましょう。ここにいる多くの皆さんが、あのオレンジ色の「準備完了」マイルストーンに到達しようとしていて、この会話の後で AgentCore を基盤として使うことに決めたとしましょう。私が今言ったことが正しいと思ったので、家に帰ってアプリケーションに対してレッドチーミングを行うわけです。私たちはこのエージェント型ランドスケープの安全な実践者なので、ガードレールも設定して、物事が脱線しないようにします。そしてソフトガードレールを使うんです。この時点で、もう起動する準備ができていますよね？いいえ。現実は、システムをレッドチーミングして破壊されるかどうかを確認したとしても、実際にそれが機能することをテストしなければならないということです。従来のテストには限界があります。なぜなら、これらの LLM は確率的だからです。より動的なものを見つける必要があります。
自動評価とサーキットブレーカー、そして成功への教訓
私たちはこれを知っているので、どのような選択肢があるでしょうか？まあ、すべての会話を手動でレビューすることもできます。それは数十の会話、おそらく数百の会話までなら機能します。しかし、毎日数万件のトランザクションを扱っている場合、手動レビューはスケールしません。他の選択肢を探す必要があります。ここで自動評価が登場するわけです。評価を自動化するとはどういう意味ですか？LLM を使ってこれらの応答を生成できるのと同じように、別の LLM を使ってこれらの応答が正しいかどうかを判断することができます。このアプローチは LLM as a judge と呼ばれており、プロセスは簡単です。まず、テスト会話をたくさん生成します。次に、それらをシステムを通して実行します。その後、どのようにできたかを評価し、時間をかけて追跡します。
実際のデータを手に入れたら、同じ評価フレームワークを使って、システムが重要なことに対して機能しているかどうかをテストできます。このタイプのテストは、実際に何が正しいかをチェックします。私たちの場合、関連性、完全性、トーンなどのメトリクスを追跡しています。顧客との会話に重要なことです。もちろん、皆さんのものは異なるでしょうから、ビジネスにとって最も重要なメトリクスを見つけてください。前のスライドにもう一度戻ります。私たちはまだここにいます。AgentCore に行くことを知っています。レッドチーミングは正しいことです。もちろん、ガードレールとソフトガードレール、わかりました。そして今、皆さんは、何が壊れるかをテストしようとしているだけでなく、それが機能することを確認する必要があることを知っています。
ですから、評価を自動化して、実際の本番ニーズに対応できるようにスケールアップします。この時点で、今は起動する準備ができていますよね？皆さんはすでにこれがどこに向かっているか知っていると思います。いいえ。なぜなら、さっき言ったように、LLM は確率的であり、このすべての作業をしても、LLM は予期しないことをする可能性があるからです。最後に望むことは、莫大な LLM の請求書で目を覚ますことです。では、どうしますか？システムが皆さんが周りにいない間に脱線するのを止めるために何かを実装する必要があります。ここで circuit breaker が登場するわけです。
circuit breaker について話すとき、私は、物事がうまくいかないときにアシスタントを停止するハードリミットについて話しています。私たちの場合、2 つのメトリクスをハードリミットと考えています。コストリミットとターンリミットです。例えば、会話の過程で、会話がコストの観点から P95 閾値に達したことが判明したとしましょう。その時点で、アシスタントは停止します。同様に、会話をしていて、行ったり来たり、行ったり来たり、行ったり来たりしていて、突然システムがターンリミットを超えたことを認識したとしましょう。
同時に、下に2と0がある理由はよくわかりませんが、仮に20ターンに達したとしましょう。いずれにせよ、P99のターンあたりのコストで、私たちはディーラーシップの誰かに会話を引き継ぎます。つまり、彼らはこの会話を続けるかどうかを決めることができるわけです。コストとターンといったこれらのメトリクスは、Bedrockがあなたのために追跡するものですが、そのデータを分析して、あなたのビジネスにとって最も意味のあるしきい値を設定するのはあなたの仕事です。
初日からこれらの制限を設定して、自分たちの境界線がどこにあるかを知っておきましょう。そうすれば、失敗するときに優雅に失敗することができ、夜もぐっすり眠ることができます。これらは、私たちのプロジェクトをベータ版以降に進める過程で学んだパターンの一部です。今日の私たちの状況をお伝えしましょう。私たちは現在ベータ版の段階にあり、のディーラーが必要な結果を見ています。彼らの顧客が昼間と営業時間外の両方で必要な答えを得ていると聞いています。
私たちはQ1の初めにローンチする予定なので、ご期待ください。今のところ、これが私が持っているすべてです。しかし、あなたのシステムは異なって見えるでしょう。なぜなら、あなたの要件は当然異なるからです。しかし、AgentCoreのような正しい基盤から始めて、重要なパターンに焦点を当てれば、あなたもまた、ユーザーが信頼できる自動化されたAIを作成することができます。ありがとうございました、Stanford。
では、私たちがどのようにしたかを上がってきて説明することを約束しましたが、その前に、誰が思いますか—ご存知のように、1つ見ましたね—誰がそれが唯一の成功だと思いますか？誰が5つすべてを完璧に成功させたと思いますか？今日は5つのプロジェクトがありました。私たちはベータ形式で本番環境にある3つのアプリを持っています。完全にライブになる最初のものは、Tabaréがあなたに話しているものです。
ディーラーシップで実際に使用されているアプリが本番環境に入ろうとしています。インベントリの価格設定をするとき、やらなければならない仕事がたくさんあり、私たちは人々にそれをするよう促しますが、彼らはそれをしません。私たちは彼らのためにそれをするエージェント的なソリューションを構築しました。そして、彼らに仕事をするよう促す代わりに、「ねえ、私があなたのためにその仕事をしました。大丈夫ですか？」と言い、その後、それを完全にエージェント的に前に進めます。これは私たちが構築した別のタイプの製品です。私たちは他にも2つ構築しました。つまり、3つは今日本番環境にあります。1つはもう少し後で本番環境に入ろうとしており、1つは描画板に戻して再考したと言いましょう。
実は、それはおそらく私たちが得た中で最も価値のあるデータの一つです—うまくいかなかったことですね。お伝えしたいのは、agentic システムは難しいということです。私たちが直面した最大の課題は、これがソフトウェアプログラミングの一種だということです。決定論的ではないんです。この全体が非決定論的なので、製品の観点からどのように考えるか、そしてここでどのように機能を考えるかが異なります。Agents には agency があります。彼らは自分たちがやりたいことをすることができます。彼らの周りにガードレールを置く必要がありますが、それは製品の観点から人々が理解するのが難しいことです。
では、私たちの教訓は何でしょうか？今日の教訓について簡単に話しましょう。最初の教訓は、動き始めることです。誰も専門家ではありません。Bedrock には素晴らしい Amazon のオファリングがありますし、AgentCore Strands も選択肢ですが、別のものを好む場合は実行できる agentic フレームワークがたくさんあります。もう一つは、破壊的に考えることです。多くの人々は、5つのプロジェクトを取り、5週間で顧客とのライブ本番トラフィックに置くとは言わなかったでしょう。それは正気の沙汰ではないですよね？
クレイジーなところから始めて、逆算して考えてください。Agentic AI を使えば、根本的に仮定を変えることができます。これを使って、これまで想像できなかったほど速くシステムを構築できますし、これまで想像できなかったものを構築させることができます。Agentic の受け入れが重要であり、エンジニアとしてだけでなく、プロダクトリーダーとして、エンジニアリングリーダーとして、アーキテクトとして、毎日それを使用する必要があります。Agentic が異なるという根本的な理解を超えるまで、agentic 製品を構築する方法を理解することはできません。少し前に chatbot について話しましたが、Tabaré のアプリケーションは chatbot よりもはるかに多くのものです。
複数の agentic レイヤーがあります。背景で他の agents が仕事をしている chatbot agent があります。Deep research のようなツールを構築できます。本質的にショッピングファネルを反転させるツールを構築できるので、顧客にボタンをクリックして購入する能力を与えることができます。Chatbot だけではない、あらゆる種類のことができます。Chatbot を超えて考えてください。ただし、毎日それを使う必要があります。それはあなたの仕事のやり方を変えるからです。
これらのことを考えて、構築を始めるとき、これの直後に何から始められるでしょうか？第一に、今日から red teaming を始めてください。明日と書いてありますが、今日始めてください。あなたのシステムがどのように壊れるかを学んでください。あなたのシステムを壊す方法を学んでください。そして顧客が最初にそこに到達する前にこれらのことをしてください。そうすれば、ガードレールを設定して、その後のラインでそれらのことのいくつかが起こるのを防ぐことができます。
次に、最悪のケースを想定して設計することです。もしあなたが既に、あなたの agentic ソリューションについて夜も眠れないような懸念を持っているなら、その周辺に評価フレームワークを構築してください。そうすることで、時間をかけて、それが本当に最悪のケースだったのか、そしてあなたがその危機の発生を軽減できたのかどうかを確認できます。そして最後に、これまで述べたように、これらすべてのことを行ったとしても、物事はまだ間違う可能性があります。ですから、物事はおそらくまだ間違うでしょう。ですから、ハードリミットを設定し、あなたのしきい値が何であるかを理解し、あなたの境界が何であるかを理解してください。そうすれば、これらの障害が発生したときに、優雅に失敗することができます。
これらのことを行えば、あなたは大丈夫です。では、これをまとめるために、私たちは AWS re:Invent にいるので、これをどのメッセージで締めくくるのが正しいかを考えていました。今日はあなたの Day One です。これは Bezos の名言です。 Day One は Amazon のコア哲学です。私たちはそれと非常に密接に協力しています。私たちは Day One について話し、それを私たちの実践に採用し、それをモデル化しようとしています。 Day Two は停滞であり、その後に無関連性が続き、その後に苦痛に満ちた衰退が続き、その後に死が続きます。だからこそ、常に Day One なのです。動いてください。 誰か他の人がこれをやるのを待つことや、正しい答えを待つことに固執しないでください。動いて、5週間か1週間で何かを構築してください。
ここにいくつかのリソースがあることを知ってほしいです。スキルをレベルアップするための QR コードがあります そして AgentCore の深掘り ハンズオンワークショップの QR コードがあります。それを強くお勧めします。これらのものを構築するのがいかに簡単かを実際に体験するのに最適な方法です。ですから、ぜひこれらの QR コードをスキャンしてください。そして、モバイルアプリでセッションサーベイを完了してください。本当にお願いします。あなたのフィードバックと、私たちがどのようにより良くできるかについて聞きたいです。本当にありがとうございました。ご質問がある場合は、私たちはここにいますので、もう少しの間ここにいます。部屋を返す必要があるまでに、あと数分あります。本当にありがとうございました。本日のご参加ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion