AWS re:Invent 2025セッションレポート：Amazonの自律型購買AI「Buy for Me」のアーキテクチャを読み解く（AMZ404）

1. セッション概要

本セッションの基本情報は以下です。

• セッションタイトル：Revolutionize shopping: Inside Amazon's AI-powered 'Buy for Me' experience
• セッションコード：AMZ404
• セッションタイプ：Chalk talk
• セッションレベル：400 – Expert
• 所要時間：1時間
• 登壇者：
  • Burak Gozluklu, Principal Applied Scientist, AWS
  • Adriano Devillaine, Director Shopping Conv Foundations, Amazon
  • Adrien Montpellier, Senior Manager, Amazon Buy For Me, Amazon
  • Abe Ray, Sr. Principal Technologist, Amazon
• セッション紹介文：Join this interactive session where we'll dive deep into the architecture of "Buy for Me," Amazon's autonomous shopping AI agent. Using whiteboard diagrams and real-world examples, we'll explore how we built and deployed this customer-facing solution using Amazon Bedrock, Titan, and Claude models. Through collaborative discussion, we'll break down our system design, integration patterns, and reliability strategies. Bring your questions as we sketch out autonomous purchasing workflows and quality assurance frameworks. This technical session includes hands-on architecture discussions and practical insights from our production implementation.

本セッションはチョークトークというホワイトボードを用いて質疑しながら進めていく形式のセッションにはなっているものの、他のチョークトークに比べて解説時間が長く、すみずみまで解説してくれたのが大きな特徴です。

※セッションタイプ別の特徴は、こちらの「AWS re:Invent初参加のTop Engineersがどのタイプのセッションがおすすめかランキング付けしてみた！」の記事にまとめていますのでこちらもご確認ください。

また、Buy for Meは一見すると「便利なAI機能」に見えますが、実際のセッション内容はなぜ簡単に自律化できないのかを丁寧に深堀りするものでした。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

2. Buy for Meとは？

Buy for Meとは、ユーザーが購入条件を指定し、実際の購入操作（外部サイトを含む）をAIエージェントが代行する仕組みです。

最終的な承認はユーザーが行いますが、商品選択・在庫確認・カート投入などはAIが自律的に実行します。

本セッションで登壇したチームは、Buy for Meの前にShop Directという機能も提供していたようです。

Shop Directが「外部サイトへの遷移を補助する体験」であるのに対し、Buy for MeはAmazon内で制御しつつ外部操作まで含めて自律実行する点が大きく異なります。

3. 全体アーキテクチャ

Buy for Meのアーキテクチャを理解するうえで最も重要なのは、1つの万能AIがすべてを行っているわけではないという点です。

この仕組みでは、購入という一連の流れを複数の小さなエージェントに分割し、それらを束ねる構成が採られています。

3-1. オーケストレーター（Shopping Mission）が“状態”を持って全体を制御

中心に位置するのが、セッション内でShopping Missionと呼ばれていたオーケストレーターエージェントです。

ここで重要なのは、単に「次はこのエージェントを呼ぶ」といった制御だけでなく、今どのステップにいるのか、どこまで成功していて、どこから再実行が必要か、といった状態（State）を明示的に持つ点です。

これにより、途中で失敗しても「最初からやり直す」のではなく、安全なポイントから再開できる設計になっています。

3-2. 目的別エージェント（Variant / Cart / Checkout など）に分割する意図

Buy for Meでは、商品選択、バリエーション選択、カート操作、決済確認などがそれぞれ目的別のエージェントとして構築されています。

これは実装を複雑にするためではなく、失敗したときに影響範囲を限定できる特定の処理だけを改善・差し替えしやすいという、運用を前提にした設計判断です。

3-3. タスク特化エージェント（ポップアップ処理・例外処理）が効いてくる場面

実運用では、ポップアップ表示や想定外の画面遷移など「人間でも面倒な処理」が頻繁に発生します。

こうしたケースを汎用エージェントに任せるのではなく、例外処理専用のエージェントとして切り出すことで全体の成功率を高めている点が印象的でした。

4. エージェント内部の動き（Perceive / Plan / Act / Check）

Buy for Meの各エージェントは、単に考えて動くだけではなく、以下の4ステップを繰り返す構造を持っています。

4-1. Perception（知覚）：Webは人間向けであり、そのままでは読めない

まず直面するのがPerception（知覚）の難しさです。

Webサイトは人間向けに作られており、DOM構造、動的要素、広告、装飾などAIにとってはノイズだらけの情報空間です。

そのためBuy for Meでは、全部を理解しようとするのではなく、本当に必要な要素だけを抽出することに注力しています。

4-2. Planning（計画）：レアケースでハルシネーションが出る

次にPlanning（計画）では、「次に何をすべきか」を論理的に組み立てます。

しかし、ZIPコード入力や地域依存のフォームなど出現頻度は低いが重要なケースでは、LLM特有の推論の不安定さが問題になります。

セッションでは、「計画は正しそうに見えても現実とズレることがある」という点が繰り返し強調されていました。

4-3. Action（実行）：サイト側は制御不能という前提

Action（実行）フェーズでは、AIが正しい操作を行っても「ボタンが反応しない」「ページがリロードされる」「タイムアウトが発生する」といった事象が起こります。

ここで重要なのは、「AIの判断が間違っているとは限らない」という前提で設計されている点です。

4-4. Governance（ガードレール）：最終確認で誤購入をしない

最後のCheck / Governanceでは、「本当に成功したと言えるか」を厳しく検証します。

Buy for Meでは、少しでも確信が持てない場合、成功とみなさず処理を止める設計が採られています。

5. 信頼性・品質保証の考え方

Buy for Meは、成功率を100%に近づけるよりも失敗しても事故を起こさないことを優先しています。

5-1. 価格・在庫の再確認と価格バッファという設計

購入直前に価格や在庫が変わる可能性を考慮し、あらかじめ許容できる価格バッファを設定しています。

想定範囲を超えた場合は、自律実行を続けません。

5-2. 最終チェックで上限超過なら止めてユーザーに戻す

条件を満たさない場合は、AIが判断を続けるのではなく、必ずユーザーに確認を戻す設計になっています。

5-3. 迷ったら失敗させるとうAmazonブランドを守るための判断基準

セッションで特に印象的だったのは、「迷ったら成功させない」という明確な判断基準です。

これは技術的な制約というより、ブランドと信頼を守るための設計思想だと感じました。

6. モデルとBedrockの使い分け

汎用LLMだけで押し切らない理由

すべてを大規模LLMに任せるとコスト・レイテンシ・安定性の面で課題が生じます。

タスクに応じたモデル選択

小さな判断には軽量モデル、複雑な推論のみ高性能モデルを利用する構成です。

Bedrockを前提にするメリット

モデル非依存な設計により、将来的なモデル差し替えが容易になります。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

7. Internet of Agents構想

Buy for Meの延長として、チケット、旅行、交通などのドメインエージェントと連携するInternet of Agents 構想が紹介されました。

これはあくまで方向性の共有ですが、例えばAmazonのエージェントと他社のエージェントが相互に接続し、目的達成のために相互に動いていくという方向性についてすでに他社と会話をし始めているということでした。

8. まとめ

本セッションでは、単なるアーキテクチャの紹介だけでなく、実際の事例に基づいて苦労した点や工夫した点など余す所なく伝えていただきとても有意義な1時間となりました。

私は現在、業務の都合上レスポンスが重視されるアプリケーション開発を行っているため、なかなかマルチエージェントのシステム構築を実務で行うチャンスがないのですが、実験的に構築してみようと思えました。

一方でマルチエージェント構築を実運用使用した場合の大変さも伝わってきましたのでその辺りの知見が見えてきたらまた共有したいと思います。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

• Amazon Web Services(AWS)および記載するすべてのAmazonのサービス名は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。