re:Invent 2025: Sun LifeのAWS生成AIソリューションIrisにおける低レイテンシ実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Accelerating AI: How Sun Life reduces latency and enhances engagement (IND3320)
この動画では、Sun LifeがAWS Professional Servicesと協力し、Amazon ConnectとBedrockを活用して構築した生成AIソリューション「Iris」について解説しています。複雑なワークフローでユーザーエンゲージメントを維持するため、AWS AppSyncのリアルタイムストリーミング機能を採用し、30秒以上かかる処理中も透明性のある進捗更新を実現しました。Dennis Volovicは、Amazon Connect上でのマルチエージェント協調型コンシェルジュシステムの構築について説明し、Model Context Protocolを活用した認証エージェントやITサポートエージェントの実装を紹介しています。Robert Chinは、Content Assistというコンテンツ生成・スコアリングプラットフォームを通じて、XMLベースの精密なプロンプティング手法とMCPによる動的ツール選択の仕組みを解説しました。Walter Kurzatzは、プライベートAPI、GraphQL subscriptions、クロスアカウントリソース共有を活用したアーキテクチャの詳細と、SigV4認証を用いたセキュアな実装について技術的な深掘りを行っています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション開始：Sun Lifeの生成AIソリューション「Iris」とチーム紹介
IND3320へようこそ。「AIの加速：Sun Lifeがいかにレイテンシーを削減し、エンゲージメントを向上させるか」です。私の名前はSalman Moghalです。AWS Professional Servicesのプリンシパルコンサルタントを務めております。本日は、Sun Lifeから3名の素晴らしいリーダー、優秀な同僚たちと一緒に登壇しています。彼らは、複雑なワークフロー中にユーザーのエンゲージメントを維持する生成AIアプリケーション、ソリューション、そしてアーキテクチャを構築する実際の取り組みについて共有してくれます。
Sun Lifeから簡単に自己紹介をしていただきます。まずRobert Chinです。彼はGenAI PatternsのProduct Ownerです。 私にとって、彼はこの全てを始めた元祖であり、Sun Lifeで生成AIを民主化した人物です。彼は2023年初頭から数多くの生成AI技術パターンを構築してきました。Dennis Volovicは、Contact CenterのDirectorでありDomain Enterprise Architectです。彼はAmazon Connect内で非常に革新的なマルチエージェント協調ワークフローを構築しており、本日それについて説明してくれます。そしてWalter Kurzatzです。彼はSenior Principal Engineerで、非常に厳格に規制された安全な環境下でSun Lifeの生成AIパターンを設計し運用する頭脳です。
興味深いことに、このチームは最近、Amazon ConnectとBedrockを使用して、コードネームIrisというオムニチャネル生成AIソリューションを構築しました。このソリューションは最近いくつかのCIO賞を受賞しました。つまり、もしこのチームが実際にどのようにこのソリューションを本番環境に導入したかについて話を聞きたい方は、後ほどぜひお声がけください。たくさんのコンテンツがあります。これが退出前の最後のプレゼンテーションだということは承知していますが、どうか最後までお付き合いください。カバーすべき内容がたくさんあります。
それでは、本日のアジェンダです。まず私が、エンタープライズAIの進化と、この進化がどのように興味深くユニークな課題を引き起こしたかを簡単に説明します。Dennisは、彼とチームがAmazon Connect内でどのように非常に革新的なエージェント型コンシェルジュのようなシステムを構築しているかを説明します。彼らはAmazon Contact Center内でのAI導入を加速させています。Robは、Sun Life内のコンテンツ生成とスコアリングプラットフォームであるContent Assistを紹介します。そして最後に、Walterがアーキテクチャとデモについて深く掘り下げます。
エンタープライズAIの進化がもたらした新たな課題：複雑なワークフローとユーザーエンゲージメント
それでは、エンタープライズAIと、この進化がどのように興味深い新しい課題を引き起こしたかについてお話ししましょう。私たちはRAGシステム、RAGワークフローの出現、あるいは夜明けを目にしてきました。 これらはRetrieval Augmented Generationシステムです。これらはシングルステップソリューションです。シングルステップと言う理由は、コンテンツを生成するためにBedrockや大規模言語モデルへの往復が1回だけであり、多くの人間による監視が関与しているからです。現在、複数のステップやマルチタスクワークフローを自動化する決定論的エージェントが登場しています。これらは依然として中小企業や大企業で活発に開発され使用されています。また、自律型エージェントも登場しています。これらは多様なツールセットを持つマルチステップのエージェント型ワークフローです。真に人間の推論と能力を模倣することができます。そして今、組織全体のチーム間で真に協働できる仮想ワーカー、エージェント型仮想ワーカーが登場し始めています。
この進化は素晴らしいビジネス価値をもたらし、多くの可能性を引き出してきましたが、同時に多くの興味深い課題も引き起こしています。これからそれについてお話しします。では、一つ目です。左側には、シンプルなQ&Aチャットボットが表示されています。これは完璧に機能します。即座に回答が得られます。ユーザーは通常、この即座のレスポンスに非常に満足しています。しかし右側には、より複雑なワークフローが表示されています。これはRobが説明するContent Assistで、先ほどのスライドで見たスペクトラムの右側に位置しています。これらは自律性に向かって進む決定論的なワークフローです。
ガイドラインを分析し、ドラフトを生成し、そして出力を洗練させる、これらのインテリジェントなステップには時間がかかります。30秒、60秒、あるいはそれ以上かかることもあります。では、ここでの問題は何でしょうか？それはレスポンスですよね。ユーザーは即座のレスポンスを期待しています。このようなスピナーや3つの点のアニメーションを見ると、システムが動作していないと思ってしまいます。一方、裏側ではAIは完璧に動作しているのですが、レスポンスに時間がかかるだけなのです。つまり、これは技術的な問題ではなく、ユーザーエクスペリエンスの問題なのです。
Model Context Protocolの登場とagenticシステム構築の加速
そして間違いなく、2025年はModel Context Protocolの年となりました。
これは触媒として機能し、これらのagenticシステムの構築を加速させました。よくagenticなAIシステムのUSB-Cポートに例えられ、裏側でツールやデータソースに接続するための標準化された方法を提供しています。突然、MCPの助けを借りて、企業にとってこれらの自律的なエージェントを構築することが非常に簡単になりましたが、常に落とし穴がありますよね。
その落とし穴とは、これらのものを非常に迅速に構築できる一方で、agenticワークフローの実行には時間がかかるということです。これは先ほど見た課題を本当に増幅させました。そして、より多くの企業がMCPを通じてインテリジェントなエージェントを採用するにつれて、ユーザーをシステムにエンゲージさせ続けることが極めて重要になります。では、この課題をどのように解決すればよいのでしょうか？長時間実行されるAIワークフローの間、どのようにしてユーザーをエンゲージさせ続けるのでしょうか？
AWS AppSyncによるリアルタイムストリーミングソリューション：セキュリティと非同期パターン
さて、皆さんもおそらく予想されていたでしょうし、どこかの時点で対処されたことがあると思いますが、ストリーミングまたはリアルタイム更新が進むべき道です。re:Inventの数多くの発表を追いかけていた方なら、つい最近Amazon API Gatewayがネイティブでストリーミングをサポートするようになったという発表がありました。もしその大胆な道を進みたいのであれば、WebSocketサーバーを自分で構築することもできますが、それらのサーバーをスケーリングするのは困難です。ですから、エンタープライズにとっては、セキュアで必要な機能を最初から提供してくれるマネージドサービスが非常に重要であり、それがAppSyncがより良い選択肢である理由です。
AppSyncは3つの主要な機能を提供します。1つ目は、プライベートAPIによる柔軟なセキュリティです。つまり、トラフィックがVPCから出ることがなく、常に内部で安全に保たれます。2つ目はリクエスト処理です。柔軟なリクエスト処理を提供し、これらのリアルタイム更新をフロントエンドにストリーミングできます。また、リゾルバーも使用できます。AppSyncが何かご存じない方もいらっしゃると思いますが、後でお話しできます。これらの機能を使用して、リクエストとレスポンスのリゾルバーを変更できます。そして3つ目は、APIモデルの柔軟な進化です。想像できると思いますが、バックエンドにより多くのデータポイントと接続を追加していく中で、コンシューマーがAPIを利用しています。GraphQLには、バックエンドの変更がコンシューマーに実際には影響を与えないという機能が組み込まれています。
ストリーミングを可能にするもう1つの重要な機能は、GraphQL subscriptionです。これはマネージドWebSocketを介して行われるため、AppSyncはこれらすべての機能をマネージドな方法で、より安全な方法で提供します。セキュリティについてもう少し詳しくお話しすると、Sun Lifeのような厳しく規制された顧客にとって、セキュリティは非常に重要です。AppSyncは、PrivateLinkを通じてVPCからのみアクセス可能なこのプライベートAPIアクセシビリティを提供します。あらゆるレベルでの制御により、IAMポリシー、エンドポイントポリシー、セキュリティグループなど、さまざまなものを使用できます。これがSun Lifeが裏側で使用しているものです。
AppSyncのもう1つの重要な機能は、Resource Access Manager共有、つまりRAMです。複数のアカウントを扱う必要がある厳しく規制された環境において、複数のアカウント間でAPIを共有できます。通常、foundationalアカウントまたはnetworkアカウントを通じてのみクラウドに入ることが許可されているため、このfoundationalアカウントにワークロードAPIを共有し、そのVPCエンドポイントを通じてアクセスできます。Walterが彼のセクションでこれについてさらに深く掘り下げます。
さて、いくつかのパターンについてです。 シンプルなQ&Aボットの場合、AppSyncは組み込み機能を使用してBedrockを呼び出します。これらはデータソースです。つまり、Bedrockデータソースがあります。コンテキストやプロンプトを持ち込んで、AppSyncを呼び出せば、動作します。これはシンプルなワークフローに適しており、非常にうまく機能します。しかし、実行に長い時間を必要とするより複雑なワークフローには、異なるパターンが必要です。 そしてこれが、私たちが話したAppSyncの非同期パターンです。これは、AIの長時間実行ワークフローのスペクトラムの右側に適用されます。
ユーザーがリクエストを行います。AppSyncのmutationまたはqueryを使って、バックエンドのワークフローを開始します。同時に、アプリケーションはサブスクライブします。AppSyncがLambda関数を呼び出し、Lambda関数はMCPサーバーとBedrockの間でオーケストレーションを行います。そしてMCPサーバーは、標準的なツール、API、データベースのセットをオーケストレーターに提供します。そして、ストリーミングが開始されます。AIオーケストレーターがこれらの複数ステップのプロセスを実行している間、そのデータをフロントエンドやAPIのコンシューマーにストリーミングで返し始めることができるようになります。
つまり、32秒という時間が、より魅力的で、透明性があり、説明可能な体験に変わるのです。このパターンは、あらゆる長時間実行されるワークフローに適用可能です。これがUXを通じたAIオーケストレーションです。
マルチエージェント連携によるコンタクトセンターの変革とセルフサービスの実現
Sun Lifeはまた、コンタクトセンターでマルチエージェントオーケストレーションを活用しました。これにより、「1を押してください」「2を押してください」といったダイヤルトーンを排除し、従来の組み込みNLPインテントよりもユーザーの発話をよく理解する非常にスマートなコンシェルジュシステムを実現しました。Dennisがこの後詳しくお話ししますが、このコンシェルジュがリクエストを専門のサブエージェントにルーティングします。ユーザーを検証または認証する認証エージェントの場合もあります。パスワードリセットのリクエストを処理できるITサポートエージェントの場合もあります。そして、請求や福利厚生タイプのリクエストを処理できる、あらゆる専門的なサブエージェントのセットの場合もあります。重要なのは、これらの複数のエージェントを構築する際に、このレスポンスタイムを管理することです。ここでご覧いただいているのは、エージェント型バーチャルワーカーの例です。これがマルチエージェント連携による完全なセルフサービスの実現です。
まとめますと、MCPはエージェント型ワークフローを可能にします。AppSyncはリアルタイムストリーミングを通じてAIを加速します。Contact CenterまたはAmazon Connectは、音声と会話型コンシェルジュシステムを通じて加速します。Sun Lifeは両方を使用しています。その結果、より良いUX、より速いAI、エンゲージメントの高いユーザーを実現しています。そして、セルフサービスコンタクトのユースケースについてさらに深く掘り下げるために、Dennis Volovicをステージにお招きします。緑のボタンを押してください。
Amazon ConnectとLexによる会話型IVR体験：メニューから自然な対話へ
それでは、こんにちは。私の名前はDennis Volovicです。Sun Lifeのコンタクトセンター担当ドメインエンタープライズアーキテクトを務めています。これまでのre:Inventは素晴らしいものでした。すべての発表に追いつこうとしているところです。Amazon Connectに関して発表された29の新機能を試すのを楽しみにしています。始める前に、Sun Lifeをご存じない方のために説明しますと、私たちは国際的な金融サービス組織であり、クライアントが生涯にわたる経済的安全を実現し、より健康的な生活を送れるよう支援することを目的としています。
想像してみてください。カスタマーサービスに電話をかけると、数秒以内に本当の会話が始まります。メニューもなく、これには1を押してください、あれには2を押してくださいもなく、アカウント番号を3回も繰り返す必要もなく、ただ自然な対話で実際に問題が解決されるのです。これは良すぎて本当とは思えないかもしれません。メニューから会話型IVRへと変革し、キーワードを超えて、コンテキスト、意図、ニュアンスを理解する自然な対話によって、コンシェルジュのような体験を創出する方法をお見せします。そこからさらに、お客様がAIガイド付きのインタラクションを通じて独立して問題を解決できるようにするデジタルアシスタントへと進みます。そして会話型デジタルアシスタントによって、認証のようなタスクで通常直面する摩擦のバランスを取り始めることができます。
コンタクトセンターは、AIが本当に輝き、IVR体験を変革できる場所です。問題は、どこから始めるかということです。私たちはAmazon Connectと数年間取り組んできており、トーンダイヤルから決定論的エージェントへの旅を進める中で、お客様にとって適切な成果と体験に焦点を当てることを確実にするために、思慮深く責任を持ってテストと学習を行っています。これからご紹介するソリューションオプションは、IVR上のカスタマーエクスペリエンスを段階的に向上させながら、サービス品質を改善するのに役立ちました。
まずAmazon ConnectとAmazon Lexについてお話しします。これは、IVRで音声認識と自然言語理解を可能にする方法です。次に、BedrockやEKSのようなサービスをご紹介します。これらは大規模言語モデルとModel Context Protocolを使ってConnect体験を強化し、より文脈を意識した、マルチターンメモリと動的な対話を提供してくれます。決定論的エージェントへの道筋があり、その過程でお客様に価値を提供できることがお分かりいただけるでしょう。
それでは、音声駆動型の体験についてお話しすることから始めましょう。これは非常に優れた代替手段です。 お客様は言葉で自分を表現できることを評価してくださるでしょう。このソリューションはAmazon Lexを使用しています。Connect AIエージェントに関する多くの発表があったことは承知していますが、LexはConnectとそれらのAIエージェントの間に位置する足場として残っていますので、理解しようとすることは依然として重要な概念ですし、Nova Sonicの重要な実現要素でもあります。
Amazon Connectに馴染みのない方のために説明しますと、これはAWSのカスタマーサービスプラットフォームであり、Amazon Lexは会話型インターフェースのビルダーです。では、Lexボットとは何でしょうか?ボットはインテントで構成されています。これらはお客様が取りたいアクション、例えばクレームのステータスについて尋ねたり、補償額がいくらかを尋ねたりすることです。アテランスは、お客様がその質問を表現する方法で、例えば「私は何に対して補償されていますか?」といったものです。
では、Lexはどのように応答するのでしょうか？Lexはインテントから直接応答することができます。変わることのない答えについては、インテントの中に直接入れておくことができ、Lexが応答してくれます。また、スロットを使って応答することもできます。スロットはLexが追加情報を収集する方法です。先ほどお話しした補償の例では、Lexがスロットを提示して「医療補償のことですか、それとも歯科補償のことですか？」と尋ねるかもしれません。最後に、カスタマイズを行いたい場合は、Lambdaを導入することができます。LambdaではAPIに接続するようなことができるので、よりパーソナライズされた応答を作成する機会が得られます。先ほどの歯科補償の例に戻ると、お客様が歯科医院に行く前に、自分がどれだけの補償を受けられるのか正確に分かるように、その応答をパーソナライズしたいと思うでしょう。Lambdaについて最後に一点、Lexボット1つにつき1つしか持てないということです。
では次に、Amazon Connectに注目してみましょう。Amazon ConnectはIVR体験を構築する場所です。ご覧になったことがない方のために説明すると、コンタクトフローデザイナーがあります。これはキャンバスのようなもので、そこにブロックをドロップし、矢印で接続すると、それが基本的にお客様がIVRで辿る旅になります。ここでご覧いただいているフローを見ていくと、このアーキテクチャで旅を管理する方法は、Connectのセッション属性とコンタクト属性を使っています。Lexが何かを返すと、それらのセッション属性を使い、その結果を一緒に使ってユーザーをIVR全体でナビゲートします。
ここで何が起こっているか見てみましょう。3つのLexボットがあります。お客様が電話をかけてきたとき、メニューボットを提示して、お客様が電話をかけた理由を表現できるようにしたいかもしれません。メニューボットを呼び出した結果、お客様が補償額を知りたいということであれば、セルフサービスボットを表示してその問い合わせを解決することになるかもしれません。メニューボットからの別の有効な結果としては、エージェントと話せるようにキューに入れる必要があるということもあり得ます。そして、キューで待っている間に、認証ボットを表示して、待っている間に追加情報を収集しようとするかもしれません。
さて、ここには多くの選択肢があります。すべてのLexボットを1つに統合することもできます。これらは本当に、お客様体験をどのように開発したいかについてのアーキテクチャ上の決定事項になります。繰り返しになりますが、このソリューションには良い利点があります。メニューのフラストレーションを排除し、自然言語理解を導入し、Lexには構造化された性質があるため、お客様が得られる結果が非常に明確です。このソリューションは価値を提供しますが、より会話的な体験を実現したい場合には、いくつかの課題が残ります。
大規模言語モデルとMCPによるLexの拡張：決定論的エージェントの構築
Generative AIの最近の進歩により、いくつかの魅力的なソリューションオプションが登場しており、それらについて説明していきます。1つは、Lexで構築した高度に設定された体験をスケールさせる際に、大規模言語モデルとプロンプトでLexを拡張できることが非常に便利だということです。先ほどの図で見た統合では、Lexがあり、Lambdaがあり、そしてすべてのAPI呼び出しがありました。これはLexの実装に非常に結びついており、ユースケース固有のものに感じられます。Salmanが先ほどお話しした変化について、Model Context Protocolについて言及していました。今では、Lexを拡張してきたこれらの大規模言語モデルを使って、突然MCPサーバー上のツールを発見できるようになりました。最後の課題は、ユーザー体験と状態の管理方法についてです。これは大規模言語モデルを使えばはるかに簡単に解決できます。LangChainやStrandsのようなオーケストレーションフレームワークには、セッション管理と会話履歴をはるかに簡単に実装できるフックがあります。
それでは、ソリューションアーキテクチャについてご説明し、以前のデザインをどのようにレベルアップして、より会話的なものにできるかをお話しします。このアーキテクチャでは、Lexが引き続きゲートウェイとなります。前のアーキテクチャでLexについてお話しした際、その設計方法、インテントの仕組み、そして発話の仕組みについて説明しました。基本的な考え方は、顧客が何か言ったときに、Lexがそれをインテントにマッチングさせて応答するというものです。
ただ、お話ししなかったのは、Lexが理解できなかった場合に何が起こるかということです。フォールバックインテントと呼ばれる別のインテントがあり、これは基本的にLexのキャッチオールで、「申し訳ございません、理解できませんでした。質問を言い換えていただけますか?」といった応答を作成できるようにするものです。では、なぜこれを言及するのでしょうか?その理由は、このアーキテクチャのLexボットにはインテントが一切ないからです。あるのはフォールバックインテントだけです。つまり、顧客が話しているとき、それはLexを通過し、フォールバックして、そのままLambdaに直行しているのです。そこで、このアプローチにおける次の大きな変更点が登場します。
標準のMCPクライアントSDKを使用し、実質的にLambdaをMCPクライアントに変換して、Amazon EKSでホストされているMCPサーバーを呼び出せるようにします。プロセスが開始されると、Lambdaはフェッチを実行します。MCPサーバーに対してリソース呼び出しを行い、必要な設定要素を取得します。オーケストレーションを駆動するために必要なプロンプトも取得します。図の中にAmazon Bedrockもあることがお分かりいただけると思います。そこで大規模言語モデルを取得します。今取得したプロンプトを使って、それを大規模言語モデルに渡すことができ、大規模言語モデルは必要なツールを発見して、認証フローのオーケストレーションを開始できるようになります。
もう一つ新しい点として、DynamoDBがあり、これをセッションと会話履歴の管理に使用しています。Amazon S3を使うこともできました。ここに反映されていないのは、LangChainとLangGraphで、これが私たちのオーケストレーションフレームワークであり、その結果、永続化層はそれに付属するチェックポインターを使用して実装されているということです。
では、MCPサーバーを見てみましょう。最初にこれを始めたとき、エージェントコアはまだ使用できる状態ではなく、迅速性を考えて検討していたことの一つは、LambdaをMCPサーバーに変換してみようということでした。しかし、Lambdaのステートレスな性質と、すぐに終了してしまうという事実により、やめようと考えました。なぜなら、MCPプロトコルは非同期で動作し、ステートフルだからです。もしLambdaを使用するとしたら、DynamoDBやS3に独自の永続化層を再度構築して、それらのセッションIDを書き換えられるようにしなければなりませんでした。そこで、コンテナ化を選択しました。これにより、永続的で長時間実行される仕組みが得られるからです。もう一つは、MCPプロトコルがセッションスティッキネスを使用することで、私たちにとってすべてがうまく機能するということです。
MCP serverについてもう一つお話しします。私たちはFastMCPとマルチスレッディングを使用してMCP serverコンテナをスケールさせています。そして、ワークロードが増加した際には、Amazon EKSが水平スケーリングを担当します。MCP serverの中を見ていただくと、いくつかのサーバーがあることがわかります。一つは認証用のサーバーで、そこにプロンプトを保管しています。そして、ユーザーIDの検証を行うためのユーザーIDツールや、誰かの携帯電話にワンタイムパスコードを送信して検証するためのOTPツールなど、いくつかのツールがあります。また、ナレッジベースのMCP serverも用意しています。
では、このフローがどのようにオーケストレーションされているかについてお話ししましょう。プロンプトエンジニアリングに入る前に、決定論的なエージェントを作るものは何かについてお話しします。私たちの認証シナリオでは、与えられた入力に対して毎回同じ予測可能な出力が必要です。LLMがある日はユーザーIDが良いと判断し、別の日には良くないと判断したり、さらに悪いことに、誰かが完全にバイパスできてしまうようなことがあってはなりません。そのため、エージェントは事前定義されたルールのセットに基づいて動作し、temperatureを下げること、構造化されたJSON出力、そして標準的なレスポンスのためにMCPツールを活用することで、大規模言語モデルの出力をより決定論的にする必要があります。
プロンプトエンジニアリングによるマルチエージェントオーケストレーション：コンシェルジュから認証エージェントへ
先ほどコンシェルジュ体験の作成についてお話ししましたが、これを実現するために、マルチエージェントオーケストレーションを提供するプロンプトを活用しています。コンシェルジュも決定論的です。顧客の意図を適切に理解し、いつ人間にルーティングするか、または別のエージェントに引き継ぐかを知る必要があります。コンシェルジュプロンプトには独自のペルソナ定義があります。独自の指示と信頼度ロジックがあります。いつルーティングするか、または明確化のための質問をするかを知る必要があります。リトライロジックもあります。
コンシェルジュが意図を理解する仕事を終えると、それを実現するために認証サービスを呼び出す必要があると判断する場合があります。ここでマルチエージェントオーケストレーションを行い、認証エージェントを導入します。
これもまた独自のペルソナ定義と、独自のステップバイステップの決定論的ワークフローを持っています。私たちは皆、認証を経験したことがあります。明確な一連のステップがあります。IDを解決してから、OTPのような次の要素に進む必要があるため、プロンプトで作成するフローが非常にステップバイステップで決定論的であることを確認する必要があります。そしてもちろん、ツールディスカバリーがあります。
認証エージェントのもう一つの素晴らしい点は、デュアルモードで動作しないということです。最初のモードではエージェントが次のステップを決定し、もう一方のモードでは、前のスライドで説明したスロットを介してLexが入力を収集します。そして、構造化されたJSON出力があるため、この2つのモード間のシームレスな切り替えが可能になるのです。大規模言語モデルとMCPサーバーでConnectエクスペリエンスを拡張すると、プロンプトエンジニアリングによって多くの可能性が開かれ、これを無限の方向に展開することができます。
タッチトーンから決定論的エージェントへの道筋があることをご理解いただけたと思いますし、その過程で多くの価値が得られます。次のスピーカーに移る前に、ご参加いただきありがとうございます。そして、皆さんのコンタクトセンターでAIを加速し、IVRエクスペリエンスを変革する方法についていくつかのアイデアを提供できたことを願っています。それでは、Robに引き継ぎます。彼がContent AssistとMCPのもう一つの創造的なユースケースについてお話しします。ありがとうございました。
Content Assist：精密なプロンプティングとMCPによる高品質コンテンツ生成プラットフォーム
さて、ありがとうございます、Dennis。re:Inventのステージでコンテンツについて話すことになるとは思ってもみませんでしたが、コンテンツはどこにでもあるようです。ソーシャルメディア、メールブラスト、誰もがInstagram、TikTok、Facebookのコンテンツを持っています。コンテンツの問題は、作成が難しいということです。ドキュメント作成でさえ誰もが嫌がりますが、コンテンツを作成するのは本当に大変です。そこで、GenAIでもっと簡単にできないかというコンセプトが生まれました。そして、まさにそこに向かっているのです。コンテンツのさまざまなユースケースで、どうすれば物事を簡単にできるかということです。
Salmanが言及したように、私はRob Chinで、GenAI Patternsのプロダクトオーナーをしており、2023年頃にSalmanとGenAIの旅を始めました。当時は、学ぶためのAWS GenAIブログもありませんでした。GenAIサービスもなく、今ではGenAIやBedrockが含まれていないセッションを見つけるのはかなり難しいでしょう。2023年にBedrockがリリースされ始めた頃、Google検索ではBedrockはフリントストーンズの出身地だと出ていたのを覚えています。でも今はClaudeがあるので、フリントストーンズを知らなければ、Bedrockの町に誰が住んでいるかClaudeに聞けば、面白い答えが返ってきますよ。
では、Content Assistに入りましょう。Content AssistはGenAIがコンテンツ生成に優れているということから始まりました。では、大規模言語モデルを活用して、コンテンツの作成、スコアリング、さらには書き直しを支援するソリューションを設計できないでしょうか。そして、自分たちを制限する必要はあるのでしょうか。大規模言語モデルは、実際にはどんな種類のコンテンツを作成しているかを本当には知りません。ですから、マーケティング、カスタムサマリー、ドキュメント、さらにはRFPへの回答にも使えます。ガイドさえすれば、間違いなくできるのです。それがContent Assistの目指すところでした。
私たちのソリューションはAmazon Bedrockを活用しています。私たちが好んで使用しているモデルの一つ、そしておそらくこの会場にいる多くの方々もそうだと思いますが、Claude Anthropicはコンテンツ作成のための主要なモデルの一つです。このソリューションの目的は、正確なプロンプティングを通じて高品質なコンテンツを生成することです。正確なプロンプティング、プロンプトの力、すべてはプロンプトの品質次第で質の高いアウトプットが生成されます。これについては後ほど少しお話しします。
そしてコンテンツに関するプロンプティングですが、コンテンツを最もよく知っているのは誰かといえば、それは主題の専門家ですよね。これから進めていく中で、コンテンツ作成というのは実際には技術チームとビジネスチームの協力関係であることがわかってくると思います。なぜなら、私自身はコンテンツについてほとんど知識がないからです。しかし、Content Assistのような基盤を提供してこのコンテンツ作成を前進させることができれば、それが私たちの目指すところです。今日のデモでは、私はずっと自分のモック会社が欲しかったので、PurrfectFrame Studiosを作りました。これはプレミアムな猫の動画を作成することに特化した会社で、誰もが猫の動画は大好きですから、これからPurrfectFrame Studiosを使っていきます。
ここでご覧いただいているのはプレビューです。デモは後ほど行います。これはPurrfectFrame Studios向けにInstagram用に作成されたコンテンツのプレビューで、これから見ていきます。Content Assistは決して一夜にして開発されたものではありません。非常に反復的なプロセスでした。
2024年に数人の好奇心旺盛なユーザーから始まりました。生成AIについて私が気づいたことは、好奇心こそがアイデアを前進させる原動力だということです。「PurrfectFrame Studios向けのInstagram投稿を作成して」といった一行のプロンプトを使っている人たちがいて、それは本当にうまくいきました。彼らは結果に満足していましたが、時間が経つにつれてコンテンツが非常に一般的に見えるようになりました。コンテンツ作成で誰もが慣れ親しんでいたブランドトーンやブランドボイスがなかったのです。
それから私たちは協力して作業を始めました—ITチームとAmazonのプロフェッショナルサービスが—そしてビジネス側に渡せるプロンプトテンプレートを作成し始めました。そうすることで彼らは、自分たちが専門家として知っているブランドガイドラインやブランドボイスを取り入れ始めることができました。私たちはこれらの複雑で、より正確なプロンプトを作成し始め、それらは本当に素晴らしいコンテンツを生成していました。あまりにも素晴らしかったので、多くのユースケースが寄せられるようになりました。ビジネスグループがこれらのテンプレートに記入し、素晴らしいプロンプトを作成していたので、私たちは共有され、人々が使用している多くのプロンプトを蓄積し始めました。それらをChatGPTに似た社内ツールに入れていました。そこにプロンプトとコンテンツを入力すると、Bedrockに接続されてコンテンツが生成されるというものです。
高品質なコンテンツを得るための鍵は、プロンプトにおいて非常に明確で詳細な記述をすることです。これから進めていく中で、いくつかのプロンプティングスタイルについてカバーしていきます。しかし、こうしたプロンプトがどんどん増えてくるにつれて、私たちはその周りにUXラッパーを作成しました。例えば、マーケティング担当者がInstagramの投稿を作成したい場合、システムに入って、希望するカテゴリーを選択すると、バックエンドから事前定義されたプロンプトを取得してコンテンツを作成するという仕組みです。
その後、私たちはこれを他にどこに導入できるか考えました。フロントエンドの観点からは、まずWeb UIを選択しましたが、これは簡単に他のチャネルにも拡張できます。SlackやMicrosoft Teams、あるいはMicrosoftアドインなどです。こうした生成AIソリューション全般において重要なのは、できる限りモジュラーにソリューションを構築することだと思います。なぜなら、次の技術プラットフォームがどこになるかわからないからです。私たちは小さく始めて、自分たちのツール内で素早く動きましたが、その後プロンプトをLambdaに入れ、UXに入れと、すべてを非常にモジュラーにしたので、何も失われることはありませんでした。
さて、精密なプロンプティングについてお話ししましたが、皆さんはおそらく、この高品質なアウトプットを得るために私たちが使っている魔法のようなプロンプトとは何なのか気になっていることでしょう。私たちが考慮した点について、少しご説明します。ご覧のように、私たちが取り込んだブランドガイドラインはXML構造内に収められています。ClaudeというモデルではXML構造を使うことで、物事が非常に整理された状態に保たれます。そのため、プロンプト内でこれらの領域を参照し始めると、Claudeは非常に集中した状態を保てるのです。ですから、この特定のケースではブランドガイドラインをXML形式で構造化できれば、マーケティング投稿をプロフェッショナルで思いやりがあり、平易な言葉で作成したいということになります。
ブランドの例、良い例、悪い例について話すことができますが、これらは非常に重要です。悪い例としては「もしあなたの猫に態度の問題があっても、心配ありません。私たちは扱いにくい才能にも対応できます」というのは、あまり良い例ではありません。しかし「あなたの猫が慣れるのに少し時間が必要なのは、まったく普通のことです」というのはどうでしょう。こうした例は、モデルがコンテンツを作成する際の指針として本当に役立ちます。他にも取り入れられるガイドラインがあります。このコンテンツを見ていくとわかりますが、プロンプティングが新しい開発言語になっているという話をしました。ここにあるすべてのものが、実際にはコンテンツの専門家によるビジネス主導のものであることにお気づきでしょう。つまり、技術的な開発からビジネス側へのシフトが始まっているのです。今やビジネスがコンテンツ生成ロジックの多くを推進しており、私たちは彼らを可能にするための基盤とコンテンツアシストを提供しているのです。
このケースでは、コールトゥアクションなど、マーケティングチームが推進したいものは何でも含めることができます。これは非常に反復的なプロセスです。適切なアウトプットが得られない場合は、プロンプトを見直して詳細を追加してください。この特定のケースのアウトプット形式については、実際の投稿を求めていますが、もう一つ求めているのが推論(reasoning)です。この推論が非常に重要なのです。なぜなら、これらのモデルがコンテンツを生成する際、あなたのガイドラインを使用していますが、人間がループに入ってレビューする際に、なぜ特定の方法でマーケティング投稿を書いたのかを理解するために、LLMが実際に「あなたがそう言ったから書きました」と説明してくれるのです。そして多くの場合、それは的を射ています。なぜなら、あなたのガイドラインが十分に具体的でなかったからです。そうしたら戻って調整を始めることができます。ですから、具体的に書いてください。
そして最後に、LLMに対して、進めていく中で何をしてほしいのかを段階的に正確に伝えていきます。そして、もしLLMが期待通りに動かず、ずれ始めたら、指示をどんどん追加していくんです。こうして、これらのセクションをすべて全体的なプロンプトに組み込んでいくと、今では5ページから10ページもの長さの複雑なプロンプトになっていて、これが本当に良い結果を生み出しているんですが、課題も生まれています。複雑なプロンプトは実行に時間がかかります。これは予想通りですよね。品質を得るには時間がかかるものです。
こういった複雑なプロンプトを実行すると、最大で1分ほどかかることがありました。ユーザーは我慢できません。誰も待つのは好きじゃないですよね。画面を切り替えて、メールを読んだり、別のチャットに行ったりして、そして時には戻ってこないこともあります。これを改善するために、クライアントをエンゲージし続けられるようストリーミングソリューションを検討しました。そこでAppSyncを導入したんです。SalmanがちょっとだけふれましたしWalterが説明してくれます。Bedrockがコンテンツを作成し始めるとすぐにストリーミングが始まり、あのスクロール効果が得られて、ほぼ即座にレスポンスが返ってきます。
2つ目の課題として話したのは、この膨大な複雑なプロンプトのライブラリです。これをどうするかということでした。前面にUIがあって、モデルは、もしこれならあれ、この投稿をするならこのプロンプトを選ぶ、という感じでした。そして、ありがたいことにMCPが登場して、動的なプロンプトライブラリを構築する機会が本当に開けたんです。私たちが検討しているコンセプトは、すべてのプロンプトをMCPカタログに入れて、サーバーに何をしたいかを伝えられるようにすることです。そうすると、バックエンドでプロンプトを選択してくれて、かなり決定論的な出力が得られます。各プロンプトが何をするかについて十分な詳細を入れておけば、適切なツールを選び始めてくれるという点でです。Salmanは、MCPがこれらの決定論的エージェントを構築するためのイネーブラーであるとふれていましたが、Content Assistで私たちが取ってきたこの段階的アプローチは、完全な自律性への道をさらに進めていると思います。まだそこには到達していませんが、道をさらに進んでいます。
LLMとMCPについて最初に話し始めたとき、私には最初少し理解するのが難しかったんです。LLMが人間のように考えられるという概念全体がですね。そこで、私が考えた簡単なアナロジーを共有したいと思います。これは、LLM、ツール、MCPの間のつながりを理解したい場合に、Claude AIで試してみることができる小さな実験のようなものです。誰もが知っているように、エージェント的なものに移行し始めると、非常にゴール指向になります。問題が何かを説明するだけで、LLMにそれを解決してもらいたいわけです。この特定の例では、特定のトピックについて魅力的なソーシャルメディアマーケティング投稿を作成したいとします。
そこで、まずツールのリストを与えることから始めます。SalmanとDennisがそれについて話していましたね。このケースでは、ブランドガイドライン、コンテンツの例、ソーシャルメディア投稿のトレンド、そしてランダムなツールとして、ハンマー、芝刈り機、そしてもちろんインスタントポットがあります。このツールのリストをLLMに提供しました。LLMは何をしたいかわかっていて、どのツールを選ぶか尋ねました。すると実際に、ガイドライン、例、ソーシャルメディアトレンドを選ぶと教えてくれて、ハンマー、芝刈り機、インスタントポットは除外したと実際に教えてくれます。これで、どのツールを選択したかがわかりました。
そして、どうやってこれらのツールを使うつもりなのかと聞いてみます。何の指示も与えずにです。すると実際に、何をするつもりなのかステップバイステップのガイドを作ってくれるんです。私は何も指示する必要がありませんでした。その知識と思考能力だけに基づいて、ステップバイステップで教えてくれました。まずガイドラインから始めて、例を見て、トレンドを理解して、投稿の下書きを作る、と。さらに詳細を提供してくれて、レビューして、書き直して、理由付きで提示してくれました。
ということで、これが次世代のエージェンティックワークフローをどのように形成し始めるかがお分かりいただけると思います。バックエンドでより多くのアクティビティを開始できるようになれば、作成したいかもしれませんし、配信リストにメールで送信し始めたいかもしれませんし、SharePointに置いたり、ワークフローに入れたりしたいかもしれません。これらの異なるステップを作成し始めることができるんです。そしてMCPを使用することの素晴らしさは、より多くのツールを追加し始めると、例えば私たちのソーシャルメディア投稿がどのようにパフォーマンスしているかのライブラリを構築し始めて、それを各投稿の説明付きのシンプルなSharePointに入れたとしましょう。そうすると実際に、標準的なRAGアプローチを行うツールを持つことができて、最新の詳細を引き出せます。何がうまくいっているのか、雪の中の猫の動画がうまくトレンドしているなら、それを良い例として引き込むことができます。そしてコンテンツ作成プロセスで動的な例を作成し始めることができるんです。
つまりMCPには大きな機会があります。そして先ほど言ったように、モジュール式に構築することで、それをドロップインできますし、他のグループもそれらのツールを使用するかもしれません。LLMが決定して、Dennisが言ったコンシェルジュアプローチと同様に公開し始めます。そこには多くのツールがあることになりますし、どれを使うべきかを理解するのにコンシェルジュに助けてもらいたいわけです。ホテルの例で言えば、新しいレストランができて、ピザを売っているとしたら、「ねえ、Rob、そこにピザショップがあるよ、行きたい?」と提案してくれるでしょう。だから動的にそれを公開できますし、LLMはコンシェルジュのように、物事を手助けしてくれるようになります。
木曜日のセッションに登壇する問題点は、re:Inventで非常に多くの新しいリリースがあることです。だから私たちはスライドの一部を更新しました。Swamiのセッションに参加された方は、Agent Corpについて話したのを覚えているでしょう。Content Assistにはたくさんの機会があると思われるでしょうし、確かにその通りです。適切なツールを見つけるためのセマンティック検索があり、これらのエージェントが機能しているか、良い仕事をしているかを確認するためのポリシーと評価があります。
そしてエピソディックメモリーが興味深いものでした。もし何かがある四半期に脱線したとしましょう。例えば、本当に失敗した猫の動画を作成したとします。エピソディックメモリーは、何かを作成し始めるときに、「ねえ、去年良いアイデアがあったけど失敗したよね、そこには行かないで」と思い出させてくれるんです。だからエージェンティックコアに来るこれらすべてのものは、Content Assistを進めていく上で、非常に大きなものになると思います。
アーキテクチャ詳解：AppSyncストリーミング、Lambda、MCPサーバーの統合設計
それでは、これらすべてがどのように連携するかについてお話ししましたが、バックエンドでは多くのことが起こっています。Walterがその背後にあるテクノロジーとアーキテクチャについてお話しします。多くのステップがありますが、Walterに引き継ぎます。ありがとうございます。DennisとRobert、ありがとうございました。素晴らしい背景説明でした。このセクションでは、AWS AppSyncを使用してソリューションを加速し、レイテンシを削減する方法について詳しく掘り下げていきます。リアルタイムストリーミングがユーザーエクスペリエンスをどのように変革し、長い待ち時間をインタラクティブで透明性のある進捗更新に変えたかを探ります。そして、アーキテクチャと主要な設計上の決定事項について説明します。
私の名前はWalter Kurzatzです。Sun Lifeのsenior principal software engineerです。私はAppSync実装の背後にあるエンジニアリング活動を主導し、エンジニアリングチームと緊密に協力して、堅牢なエンタープライズ要件を満たすソリューションを設計し、提供しました。本日は、AppSyncのマネージドGraphQLサービス、プライベートAPI、リアルタイムストリーミングを活用して、複雑で長時間実行されるワークフローをサポートするアーキテクチャをお見せします。AppSyncをAmazon Bedrock、Lambda、そしてModel Context Protocolサーバーと統合して、マルチステッププロセスをオーケストレーションする方法をご覧いただきます。そうですね、後ほどRobがデモをご案内し、ソリューションがリアルタイムで進捗更新をストリーミングする様子をお見せします。ローディングスピナーと不確実性の代わりに、実際に発生している更新をご覧いただけます。
生成AIワークフローの複雑さとスケーラブルなストリーミングインフラストラクチャの欠如が、私たちが克服しなければならなかったハードルの一部でした。生成AIイニシアチブを進めるにつれて、私たちのアプローチを形作るいくつかの重要な課題に直面しました。そして、ユースケースがより複雑になるにつれて、コンテキストの複雑さが劇的に増加し、完了するのに大幅に多くの時間が必要になりました。Robが述べたように、2つ目の課題はユーザーエクスペリエンスでした。私たちのユーザーは即座のレスポンスに慣れており、複雑な推論と長い待ち時間により、ユーザーがセッションを放棄する実際のリスクがありました。
それでは、アーキテクチャの概要から始めて、その後デモに移り、AppSyncストリーミングの実際の動作をご覧いただきます。このスライドでは、AppSyncソリューションの主要なコンポーネントとテクノロジーについて説明します。UIはReact JSで書かれており、Apollo TypeScriptクライアントライブラリを活用してGraphQLのsubscriptions、queries、mutationsを管理しています。ネットワーキングとホスティングについては、OpenShiftとKubernetesをコンテナとオーケストレーション管理に活用しています。そこでは、Lambda関数にアクセスするためのセキュアゲートウェイを実装しています。WebSocket接続を管理するためのリバースプロキシとして機能するNGINXを実装しました。そして最後に、MCPサーバーもコンテナとして実装しています。
また、AWS Identity and Access Managementも活用しています。ネットワークアカウント内でAppSyncにアクセスできるようにするためのinvoke roleを実装しました。そして、そのネットワークアカウントで実際にassume roleを行うためにSTSを使用しており、これによりAppSync自体にアクセスするための一時的な認証情報を取得できます。AWS Resource Access Managerについては、Salmanが言及したように、AppSyncのクロスアカウントリソース共有を可能にするために実装しました。AppSyncは2つの場所、つまりネットワークまたはfoundationアカウントと、プライベートワークロードアカウントに実装されています。
そしてもちろん、AWS AppSync自体は、フルマネージドなGraphQLサービスでして、私たちのソリューションでは、これをリアルタイムストリーミングに活用しています。AWS Lambdaは、サーバーレスコンピューティングですが、これを活用してバックエンドのアプローチ、バックエンド戦略を実装しています。3つのLambda関数があります。API Lambdaがありまして、これはネットワークアカウントでのassume roleを実行するために使用しています。データソースLambdaを使用していまして、これはGraphQLリクエストを処理する中間層として機能します。
そして最後に、Lambda Orchestratorがありまして、これが本当にすべてをまとめているもので、SNSに接続し、Bedrockに接続し、AppSyncに接続しています。そしてもちろん、これは私たちのMCPホストでありクライアントでもあります。 SNSをセキュアなpubとsubの通知に使用しています。このケースでは、データソースLambdaがSNSにパブリッシュし、Lambda Orchestratorがそれをサブスクライブしています。AWS Bedrockを活用してLLM統合を行っていますし、ストリーミングAPIも使用していまして、これを実際にAppSyncのmutationに書き戻すために使っています。そして最後に、Model Context Protocolですが、これをシステムプロンプトのホスティングと、コンテンツスコアリングツールに使用しています。
では、ステップ1を見ていきましょう。ステップ1では、ユーザー、つまりUIがセキュアなゲートウェイを通じてバックエンドLambdaにリクエストを送信し、一時的な認証情報を取得します。これらの認証情報により、UIはネットワークアカウントにある共有AppSyncエンドポイントにリクエストを送信できるようになります。Lambda関数はAWS STSを使用して、ネットワークアカウントのIAMロールをassumeします。ネットワークアカウントのIAMロールは、Lambdaのexecutionロールをtrustし、AppSyncを呼び出す権限を付与します。ここで注意点ですが、私たちはヘッダーでSigV4を使用しています。これはAppSyncに必要なものです。AppSyncはこれを使用して認可と認証を行います。このソリューションを作成した時点では、認証認可のための他のメカニズムがなかったため、SigV4ヘッダーを使用せざるを得ませんでした。
ですので、UIがAppSyncに接続する際、特にWebSocket経由のリアルタイムサブスクリプションの場合、SigV4ヘッダーを使用して初期ハンドシェイクに署名する必要があります。この署名は、Lambdaとクロスアカウントロールassumeを介して取得した一時的な認証情報を使用して、リクエストが認可されていることを証明します。 UIはApolloライブラリを使用し、ステップ2ではApolloライブラリを使用してAppSyncに接続し、イベントをサブスクライブします。SigV4ヘッダーで署名されたWebSocket接続を準備し、それがWebSocket URLのクエリパラメータとして渡されます。WebSocket接続は、NGINXリバースプロキシを通じて確立されます。リバースプロキシはWebSocketアップグレードリクエストを受け入れ、その後WebSocket接続をネットワークアカウントのAppSyncエンドポイントに転送します。
ネットワークアカウントのAppSyncは、SigV4署名と一時的な認証情報を検証し、リクエストをプライベートAppSyncインスタンスに転送します。AppSyncはサブスクリプションを確立し、リアルタイムのデータのストリーミングをWebSocket接続を介してクライアントに有効にします。そして最後に、ちょっとした注意点ですが、GraphQLにおけるサブスクリプションは、特定のイベントやデータの変更が発生したときに、クライアントがサーバーからリアルタイムアップデートを受信する方法です。ですので、特定のイベントやデータストリームを繰り返しポーリングする代わりに、何かが起こったときに即座に通知を受け取ることができます。
それでは、AWS AppSyncについてですが、AWS AppSyncでは、GraphQLサブスクリプションはスキーマ内で定義され、通常はNONEデータソースを使用します。これによりバックエンドに接続することなく、カスタムロジックや変換を実行することができます。マルチアカウント構成では、サブスクリプションリクエストはプライベートなAppSyncインスタンスに安全に転送され、そこでイベントを処理し、WebSocketを介してリアルタイムの更新をクライアントにストリーミングで返します。このアプローチにより、バックエンドリソースを保護したまま、瞬時にイベント駆動型のフィードバックを実現できます。
そして、ステップ ステップ2ですが、スライドの1つがちょっとおかしくなってしまったようです。 ステップ2では、UIはApolloライブラリを使用してAppSyncに接続し、イベントをサブスクライブします。WebSocket接続を準備します。 では、次のセクションに進みます。
ユーザーは確立されたWebSocket接続を通じてGraphQLクエリを送信します。リクエストはNGINXリバースプロキシを経由してルーティングされ、その後WebSocketにリクエストを転送します。ネットワークアカウント内のAppSyncが クエリを受信し、 SigV4署名と一時的な認証情報を検証し、適切なAPIとリゾルバーにリクエストをルーティングします。この場合、リゾルバーはgetContentResponseです。
リゾルバーはGraphQLクエリをデータソースLambda用のペイロードに変換し、その後Lambda自体を呼び出します。データソースLambdaはペイロードを受け取り、処理し、SNSトピックにfire and forgetで公開します。 最後に、LLMオーケストレーターLambdaがそのトピックをサブスクライブしており、トリガーされるとペイロードを受け取り、Bedrock LLMストリーミングAPIを呼び出します。 オーケストレーターLambdaは、Bedrockからトークンをストリーミングし、それらをバッファリングして、生成されたアップデートをAppSyncに送り返します。では、これはどのように行われるのでしょうか？
sendMessageというミューテーションがAppSyncスキーマで定義されており、リゾルバーを使用するようにマッピングされています。これも再びNONEデータソースとして設定されています。リゾルバーは相関ID機構として機能し、WebSocket接続にレスポンスを返す前に、正しいクライアントがミューテーションを受信することを保証します。最後に、MCPは私たちのソリューションにどのように組み込まれているのでしょうか？ユーザーは基本的なコンテキストを提供してソーシャルメディアコンテンツをリクエストします。その後、LLMは Server-Sent Eventsトランスポートを介してMCPサーバーに接続します。
サーバーは利用可能なもの、利用可能なプロンプト、利用可能なツールを通知します。そしてLambdaオーケストレーターがシステムプロンプトをリクエストします。このシステムプロンプトは、コンテンツが実際に生成された後に、利用可能なツールのリストからスコアリングツールを実行するようLLMに指示します。次にLLMがシステムプロンプトに基づいてソーシャルメディアコンテンツを生成し、最後にLLMがシステムプロンプトの指示に従ってMCPスコアリングツールを呼び出します。Lambdaオーケストレーターがスコアリング結果をUIにストリーミングで返します。
ライブデモと学んだ教訓：PurrfectFrame Studiosでのコンテンツ生成実演
次のステップでは、これらすべてが実際に動作しているところをデモでご覧いただこうと思います。それではWalter、ありがとう。さて、皆さんには今クレイジーな技術的な部分をご覧いただきましたので、私からは私が見ている簡単な部分、フロントエンドをお見せします。このデモでは、プレミアムな猫の写真とビデオ制作サービスを提供する架空の猫ビデオグラフィー会社についてお話ししました。私たちがあなたの猫のところに伺います。猫を連れてくる必要はありません。
今回のプロモーションでは、複数の猫を飼っているお客様向けに新しい冬のホリデーフォトパックを開始します。追加の猫1匹につき15%オフです。猫好きのあの買い物が難しい友人へのギフトアイデアとして最適です。 これがContent Assistです。では試してみましょう。右側の画面が実際にAppSyncのストリーミングを表示する画面で、左側は以前動いていたレガシーバージョンです。
ご覧のようにメニューを選択しました。ソーシャルメディア、コンテンツ生成、ターゲットは米国の顧客です。 そしてInstagramを選択して、実行します。踊るドットが表示されますね。AppSyncバージョンでは送信するとすぐにストリーミングが開始されます。 そしてBedrockがコンテンツの作成を開始し、生成し始めます。もう片方の画面もすぐに追いついてくるのが見えるでしょう。投稿を作成し、推論を行います。 そして続けていきます。なぜなら新しいバージョンでは実際にMCPの中にスコアリングエンジンを組み込んでいるので、最後にコンテンツをスコアリングすることを決定したからです。 ご覧のように、カテゴリー全体のスコア、ブランドアライメント、文法が表示されます。これらはすべて、求めているコンテンツの種類に応じて設定できる異なるスコアリングメカニズムです。
つまり、コンテンツに応じて完全にカスタマイズ可能なんです。例えば技術的なコンテンツを書いている場合、技術用語の複雑さという観点で異なるスコアリングをしたいかもしれません。完全にカスタマイズ可能です。先ほども申し上げましたが、すべてはプロンプトと、特定のビジネスユニット向けにそれらをどのように設計するかにかかっています。 これを進める中で学んだ教訓がいくつかあります。Walter、私はあなたにたくさんのクレイジーなアイデアを持ち込みますが、あなたはいつもチームをまとめて実際にソリューションを作り上げてくれますね。
学んだ教訓を振り返ると、対処しなければならなかった最大の課題は何だったと言えますか?
そうですね、ここにいくつか箇条書きで挙げていますが、サーバーサイドのミューテーションでAppSyncのキープアライブを活用することが私たちにとって大きな課題でした。最初にAppSyncを使い始めたとき、期待していたようなパフォーマンスが出なかったんですが、その後、実際には私たちの実装方法や使い方に問題があったことに気づきました。毎回接続を確立してハンドシェイクを行うというのは、コネクションプールを活用する必要があるものでした。それをせずに毎回すべての作業を行うと、時間がかかってしまうんです。
以前お話ししたように、常に新しい技術に対してオープンでいることが大切です。私たちは最初、Sun Life Fastツール内でコンテンツ作成を行うだけのデプロイから始めて、その後コンテナにデプロイするソリューションを構築しました。今は.NET Coreを検討していますし、来週何がリリースされるかわかりません。AWSからは毎週のように新しいリリースがあるようですから、どこにでも移動できるようにモジュール式で構築することです。これが最大の教訓の一つだと思います。まとまりがあって堅牢で、デプロイできるものを構築することですよね?
しかし、ご覧のとおり、これは巨大なアーキテクチャ図でした。多くの人々がこれに取り組まなければなりませんでした。私たちはこれらのさまざまなサービスやシナリオで限界に挑戦しました。ご覧のとおり、これらはソリューションの設計において重要な貢献者の何人かで、それぞれのボックスのすべての部分に関わっています。実は、Walterがプロジェクトミーティングでそのアーキテクチャ図を見せてくれたとき、これらのボックスのそれぞれに名前を関連付けることができました。でも、すべてが一つにまとまって実際にストリーミングのデモを行ったとき、それは本当に素晴らしかったです。無料ですよ。
それでは皆さん、ありがとうございました。最後のセッションまで残っていただきありがとうございます。私たちが皆さんとパーティーの間に立っている形になっていますが、この後も会場にいますので。カバーすべき内容がたくさんあったことは承知しています。MCPでも、AppSyncでも、コンテンツ作成でも、何か質問があればお答えします。ここにいますので。モバイルアプリでアンケートに回答してください。星を残さないでくださいね。これが最後のセッションです。5つ星をつけていただけますが、今夜のパーティーを楽しんでください。楽しんでいただけたことを願っています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion