AWS で実現する新しい E-Commerce の形 〜 Future of Agentic Commerce みなさんこんにちは。ソリューションアーキテクトの中島です。 本記事では AWS Summit Japan 2026 で展示した、流通小売消費財業界ブース「AWS で実現する新しい E-Commerce の形 〜 Future of Agentic Commerce」の様子を皆様にお伝えさせていただきます。 Agentic Commerce とは Agentic Commerce とは、自律的な AI エージェントが、ユーザーに代わって商品の検索・比較・購入・決済までを独立して実行する、新しい形の e コマースです。従来の EC ではユーザー自身が検索・比較・購入を行い、意思決定もすべて人間が担っていましたが、Agentic Commerce では AI エージェントが検索・比較・購入・決済を自律的に実行し、人間は条件設定と監督に役割が変わります。なお現状では、購入の最終判断は人が行い、決済は人の指示を受けてエージェントが代行する形が中心です。 こうした AI エージェント経由の商品発見・購買は、直近のニュースでも大きく取り上げられています。たとえば AWS は、決済パートナーと連携して AI エージェント向けのステーブルコイン決済基盤（ Amazon Bedrock AgentCore payments ）を発表し、自律型 AI エージェントがリアルタイムに購入を行えるインフラの構築を進めています。また EC プラットフォーム側でも、AI エージェント経由の意図しない購買を防ぎつつ、マーチャントが商品データを適切に連携できるフィード機能の提供が始まるなど、各社の対応が急速に進んでいます。 Amazon 自身も、こうした Agentic Commerce の実装を既に提供しています。Amazon Shopping アプリ内の AI アシスタント「Rufus」（2026 年 5 月より Alexa と統合し「Alexa for Shopping」としてリニューアル）は、Amazon Bedrock を活用して数億人規模の顧客に会話型の商品検索・比較体験を提供しており、その裏側のアーキテクチャは こちらのブログ で詳しく紹介されています。Onsite Agent（EC サイト上での接客エージェント）の実運用例として参考になる内容です。 日本国内でも、EC サイト上に AI アシスタントを組み込む取り組みや、AI プラットフォーム上に自社の商品を発見してもらう取り組みが、複数の企業で始まりつつあります。 AWS Summit Japan 2026 の会場では、こうした AI エージェントが商品を探し、比較し、購入するという新しい EC の姿を、実際に動くデモとともにご紹介しました。AI プラットフォーマーが提供する Incoming Agent から EC サイトに流入し、そのまま自社 EC サイト上の Onsite Agent による接客を経て購入に至るまで、そして裏側で動く EC バックエンド・バックオフィスの仕組みまで、一つの Demo システムとして統合してご覧いただきました。 このブログでは、当日の様子や Demo シナリオ、ブースでご紹介した Demo システムのアーキテクチャをダイジェストでご紹介します。 AWS 展示ブーステーマ 「Future of Agentic Commerce」 AI プラットフォーマーが提供するショッピング機能や、EC プラットフォーマーが組み込む AI エージェントの台頭により、消費者の商品発見から購入までの体験は大きく変わり始めています。この変化を「来たる Agentic Commerce 時代を売上向上の Big Opportunity に」できるよう、ブースでは実際に稼働する Demo システムを通じて、Agentic Commerce の実装イメージを具体的にご覧いただきました。 デモのご紹介に入る前に、本デモに登場する 2 種類のエージェントについて簡単に整理します。 Incoming Agent（インカミングエージェント）: AI プラットフォーマー側（チャットアプリや AI アシスタントなど）に存在し、ユーザーに代わって複数の EC サイトを横断的に検索・比較し、商品を推薦・購入までつなぐエージェントです。ユーザーは EC サイトを直接訪れるのではなく、普段使っている AI プラットフォーム経由で EC 事業者の商品と出会います。その後、AI Agent が決済まで終わらせるケースもあれば、EC サイトへ流入するケースもあります。 Onsite Agent（オンサイトエージェント）: EC 事業者が自社サイト上に実装するエージェントで、訪問したユーザーに対して商品検索・比較・接客を行います。従来の EC サイト内検索やレコメンドの役割を、対話型のエージェントが担う形です。 本デモでは主に Incoming Agent 経由の体験を中心にご紹介しつつ、Onsite Agent による自社 EC 上での接客体験もあわせてご覧いただける構成にしています。 デモでは、次の 6 つのストーリーをご覧いただけるようにしています。 複数の EC 事業者にまたがって商品を探し、1 つの仮想的なカートで管理した上で、AI プラットフォーマーが提供するウォレットで購入するケース（購入の最終確認はユーザー自身が行い、確認ボタンを経て決済する） 同じくウォレットでの購入において、あらかじめ 5,000 円以下の決済権限をエージェントに与えておき、その条件に該当する場合はユーザーの確認なしにエージェントが購入まで自律的に実行するケース 仮想的なカートに商品を入れるところまでは同様だが、そこから「EC で購入したい」ボタンを押すことで、連携先の EC 事業者側のカートに商品が転送され、そちらで購入を完了できるケース Onsite Agent が自社 EC 上で最適化された UI/UX を通じて、来訪したお客様をおもてなしするケース なお、このデモの決済には Amazon Pay を採用しています。Amazon Pay の Payment Method On File（PMOF） は、初回に支払い方法を設定しておくことで、以降はワンクリックで決済が完了する方式です。Onsite Agent との対話から購入確定までをチャット UI 内で完結させる、スムーズな決済体験を実現しています。さらに本デモでは、ECP を通じて AI プラットフォーム側のエージェントからも同じ Amazon Pay 決済を呼び出せる実装としています。 友達同士で買い物をするケース：それぞれのユーザーに紐づいた AI エージェントが、購入前に互いに会話をして、各ユーザーの趣味・嗜好データを踏まえながら「何を買うか」「予算をどうするか」を事前に調整し、方針が決まったところで「こういう議論をしてこう決まったけれど、これでいいですか」とユーザー本人に確認を取る、という未来の購買体験を示すコンセプトデモ 注文した商品が在庫切れとなった場合の例外処理を EC バックオフィスエージェントが検知し、ユーザーに代替品を提案するケース Agent に Apps を導入して EC 側のデザインやビジネスロジックを持ち込むケース Demo システム全体像 Demo システムは、AI プラットフォーム側の Incoming Agent と、EC 事業者側の EC フロントエンド・EC バックエンド・EC バックオフィスエージェントまでを一つのシステムとして統合し、Agentic Commerce の一連の流れを再現しました。（図の Amazon Bedrock AgentCore runtime アイコンが見えづらいのですが、MCP, UCP Server を ホストしています。） AI プラットフォーム側の Incoming Agent: AI プラットフォーム側から EC 事業者の商品を発見・推薦するエージェント。 UCP (Universal Commerce Protocol: AI Agent が購買するために必要な一連の機能と I/F を定義したプロトコル) / AP2 (Agent Payments Protocol: AI Agent が決済時に使用するプロトコル) / ECP (Embedded Checkout Protocol) / MCP Apps (Model Context Protocol Apps: UI 転送を伴う MCP) といった複数のコマースプロトコルに対応 EC フロントエンド: 自社 EC サイトに実装した Onsite Agent が、MCP Apps を通じて商品検索・接客を提供 EC バックエンド: 商品 Feed、在庫、決済などの機能を EC API・MCP/UCP 経由で提供。複数の Agent 間連携は A2A（Agent-to-Agent）Mesh で実装 EC バックオフィスエージェント: 発注、顧客管理、在庫管理と連携し、例外処理の解決を行う AI プラットフォーマー側を入り口にして、自社の EC サイトで決済をしていくというユーザーストーリーまで、一連のカスタマージャーニーを実現しています。 Demo システムで利用している AWS サービス 用途 AWS サービス AI プラットフォーム側 Agent、EC の認証サービス Amazon Cognito 静的アセットの配信 Amazon CloudFront 静的アセットの配置 Amazon S3 API 呼び出し、Agent 呼び出し時の入り口 Amazon API Gateway ビジネスロジックの実装 AWS Lambda EC / UCP checkout session の管理 Amazon DynamoDB 商品 Feed からの検索 Amazon OpenSearch Serverless 商品 Feed の連携 AWS Step Functions AP2 の鍵管理 AWS Secrets Manager LLM 推論 Amazon Bedrock （Claude Sonnet 4.6） Agent、MCP Server の Host Amazon Bedrock AgentCore ※ 決済には Amazon Pay（AWS サービス外）を利用しています。詳細は後述の「アーキテクチャのポイント」をご参照ください。 アーキテクチャのポイント AI プラットフォーマー側 AI Agent は Amazon Bedrock AgentCore runtime 上に Strands Agents で実装 商品検索は Amazon OpenSearch Serverless で実装 すべての推論は Amazon Bedrock 経由で Claude Sonnet 4.6 を利用 EC 事業者側 OpenSearch Serverless への Ingest パイプライン（商品が追加されるとベクトル化 → Ingest を自動実行）を実装 MCP Apps Server、UCP（MCP）Server も Amazon Bedrock AgentCore runtime 上にパススルー構成で実装 複数の Agent 間連携は A2A（AgentCore runtime 上）で実装 決済は Amazon Pay の Payment Method On File（PMOF）で実装。初回設定以降はワンクリックで決済が完了し、Onsite Agent の購買体験を途切れさせない。ECP 経由で AI プラットフォーム側からも呼び出し可能 プロトコルについて（UCP / AP2 / ECP） 本デモでは、Agentic Commerce を支える複数のコマースプロトコルに対応しています。それぞれの位置づけは以下のとおりです。 UCP（Universal Commerce Protocol）: Google と Shopify が中心となって策定した、AI エージェントが商品発見・条件交渉・チェックアウト・購入後のデータ連携までを行うためのオープンな仕様です。 AP2（Agent Payments Protocol）: Google が提唱する、暗号署名された Mandate（委任状）を用いて、エージェントによる決済を安全かつ検証可能な形で実行するためのプロトコルです。UCP と組み合わせて利用され、現在は FIDO Alliance がガバナンスを担っています。 ECP（Embedded Commerce Protocol）: UCP を EC サイト内に埋め込む形（embedded 版）で利用するための実装形態を指します。本デモでは、ギフト設定が可能な EC 側のチェックアウト画面を AI PF 側に転送する仕組みや、そのチェックアウト画面にて EC 事業者が使用する決済手段を指定する仕組みとして活用しています。 これらのプロトコルは 2026 年に入ってから急速に整備が進んでいる分野であり、今後も仕様のアップデートが続くことが予想されます。最新の動向は各プロトコルの公式サイトをご確認ください。 認証について（補足） 今回の Demo では、認証はすべて Amazon Cognito で一元管理し、AI プラットフォーマー側と EC 事業者側の ID を単一の Cognito で代替しています。ただし本来、AI プラットフォーマーと EC 事業者間の ID 連携は、世界的にもまだ標準化の議論が進行中で、業界標準は定まっていません。今回のデモでは、その先にある体験（ID 連携済みの世界）を示すために、便宜上 1 つの Cognito に統合している点にご留意ください。 実装上の注意点 今回のデモでは MCP Apps Server・UCP Server を Amazon Bedrock AgentCore runtime 上にパススルー構成で自前実装していますが、これが唯一の実装パターンというわけではありません。Agentic Commerce を取り巻くプロトコルやサービスはまだ発展途上であり、今後リファレンスアーキテクチャが出てくることが期待されます。 ご来場いただいたお客様の声 ブースにお立ち寄りいただいたお客様からは、たくさんの生の声をいただきました。 まず印象的だったのは、「AI エージェントに決済まで任せたい」という声はそれほど多くなく、むしろ「AI プラットフォーマーに自社の商品を推薦してもらい、自社の EC サイトへ流入させたい」というニーズを持つお客様が多かった点です。Agentic Commerce というと購入・決済の自動化に注目が集まりがちですが、現場の実感としては、まず「見つけてもらうこと」への関心の高さがうかがえました。 また意外な反応をいただいたのが、「友達同士で買い物をする」というコンセプトデモです。「これはいいね」という反応もあれば、「ここまで技術的にできるんですね」と驚かれるお客様もいらっしゃり、Agentic Commerce の可能性を考えるきっかけとして興味深い反応をいただきました。 そしてもう一つ大きな評価をいただいたのが、「Agentic Commerce という言葉は知っているが、実際にどういう挙動をするものなのか、業界としてどこまで進んでいるのか（全体像）がわからない」という声に対して、ブースが一つの「アンサー」を示せたという点です。実際に「Agentic Commerce という名前しか知らず、何のことかよくわからなかったが、このブースを見て完全に理解できた。自分たちが何を検討すればいいかが分かった」と言って帰られたお客様もいらっしゃいました。まだ日本国内では実際に触れられる Agentic Commerce の実装例が少ない中、こうした「わかる」体験を提供できたことは、現在の日本市場において意味のあることだったと感じています。 まとめ Agentic Commerce は、まだ「購入の最終判断は人間が行う」段階にあるものの、AI プラットフォーマーや EC プラットフォーマーによる対応が急速に進んでおり、日本国内でも Onsite Agent・Incoming Agent の取り組みが着実に増え始めています。 AWS Summit のブースでご紹介した Demo システムは、 Amazon Bedrock AgentCore を中心に、Incoming Agent・Onsite Agent・MCP Apps Server・UCP（AP2）Server・A2A による Agent 間連携までを、実際に動く形で統合したものです。ぜひ皆さまの自社 EC における Agentic Commerce 対応の第一歩として、AWS サービスをご活用ください。 これからも、AWS 小売・消費財チームはユーザー企業様間の情報共有・議論の場をご提供し、1 つでも多くのお客様ビジネス課題の解決をご支援させていただく所存です。今後ともご期待ください！ 著者 中島　佑樹 西日本の小売・消費財のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としています。Agentic Commerce x AWS を推進中。最近 Google AI 要約で “日本の Agentic Commerce の有名なエンジニア?” で検索すると自分の名前が出てくることに喜びを感じています。 木下 尚英 (Naohide Kinoshita)  アマゾンジャパン合同会社 Amazon Pay シニアソリューションアーキテクト  Amazon Pay の日本の事業者様向け技術支援を担当しています。カートシステムを提供するプラットフォーム事業者様から大手・中小の EC 事業者様まで、業種を問わず数多くの導入・ローンチをご支援してきました。最近は決済の観点から Agentic Commerce の実装を検討・提案しています。好きなサービスは Amazon Bedrock AgentCore です。趣味はガンプラと旅行です。 堀内 保大 (Yasuhiro Horiuchi) / @ka_shino_ki アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 大規模なWeb系のお客様をご支援する傍ら、Eコマース関連のお客様を横断的に技術支援しています。 好きなサービスは、Amazon EKS や Amazon ECS 等のコンテナ関連サービスですが、最近はAmazon AgentCore Evaluationsに夢中です。趣味は旅行とスノーボードです。 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon Quick です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

報告者：柾本 彬（技師 / 技術推進グループ・softcreate）　 会期：2026年6月2日(火)〜3日(水) 会場：Fort Mason Center マイクロソフトが毎年開催している開発者向けイベント「Microsoft Build 2026」に参加してきました。ガチガチの技術レポートは参加した各社の優秀なエンジニアの方々が書いてくれていますし、同行した若き？エンジニア達も書いてくれそうなので一旦置いておいて、「現地に行って参加するってこんな感じなんだなぁ」というレポートをさせていただきます！ 個人的には一昨年（2024年）のシアトルに続いて2度目のBuild参加。 今年の舞台はサンフランシスコです。

こんにちは。ニフティの基幹システムグループ インフラシステムチームに所属している轟木です。 担当業務はオフィス及びデータセンターのネットワーク設計・構築・運用です。 今回は、育休中に感じた家事分担のモヤモヤをきっかけに作った「家事トラッキングシステム」について紹介します。 家事はお互いにやっているはずなのに、なぜか「自分の方が多くやっている気がする」。この感覚を減らすために、Slack、Google Apps Script、Google スプレッドシート、Looker Studioを組み合わせて、家事を記録・可視化する仕組みを作りました。 背景：既存アプリが我が家に合わなかった 夫妻で同時期に育休を取ったことで、家にいる時間が増えました。すると、これまで見えにくかった家事の分担が気になるようになりました。 お互いに家事も育児もしているのに、 自分の方が家事を多くやっている気がする 相手がいつ何をしてくれたのか分かりにくい 「やった」「やっていない」が感覚ベースになり、話し合いづらい という状態になっていました。 最初は家事分担アプリも試しましたが、用意されたテンプレートが我が家の家事の粒度や負担感と合わず、記録のためだけに新しいアプリを開く習慣も定着しませんでした。 そこで、普段から使っているSlackとスプレッドシートを中心に、自分たちの生活に合わせた仕組みを作ることにしました。 Claudeに要件定義から相談した 最初にClaudeへ、改善したい点と使いたいサービス名を伝えました。 入力はできるだけ簡単にしたい 夫妻それぞれの家事をポイント化したい Slack、Google スプレッドシート、Looker Studioを使いたい 将来的にはAlexaから音声入力したい するとClaudeは、目的、スコープ、システム構成、データ設計、運用ルールまで含めた要件定義書を作ってくれました。 育児中でまとまった時間を取りづらい中でも、普段の業務ではあまり触らないSlack AppやGASまわりの設計・実装を短時間で進められました。 作ったもの 今回作った構成は次の通りです。 流れはシンプルです。Slackで家事ボタンを押すと、GASがイベントを受け取り、Google スプレッドシートにログを書き込みます。そのログをLooker Studioで集計・可視化します。 ポイントは、入力導線を「普段から開いているSlack」に寄せたことです。よく使う家事はボタンとして常に表示し、頻度が低い家事はプルダウンから選べるようにしました。 実際のSlack画面は以下のような形です。 家事をしたら、該当するボタンを押すだけで記録完了です。できるだけ考えずに入力できるようにしたことで、記録のハードルを下げられました。 工夫したところ 家事マスタをスプレッドシートで管理する 家事マスタはコードに埋め込まず、Google スプレッドシートで管理しました。 家事マスタ内の家事項目やポイントを変えたい時は、スプレッドシートを編集するだけで済みます。運用しながら家庭内ルールを調整しやすいようにしました。 ポイントは1〜5点で、作業時間だけでなく、頻度・負担感・心理的ハードルも考慮して夫妻で決めています。 ログを集計しやすい形にする 家事を記録するたびに、ログシートへ1行追加する形にしました。 ログには、日時、記録者、家事ID、家事名、ポイント、カテゴリ、入力経路を保存します。後からLooker Studioで集計しやすいように、1回の家事を1行として扱うシンプルな形にしています。 Slackボタン方式にした Slack入力は、スラッシュコマンドではなくボタン方式にしました。 スラッシュコマンドは3秒以内にレスポンスを返す必要があります。一方、GASのWebアプリはコールドスタート時に数秒かかることがあり、タイムアウトする可能性があります。 そのため、ボタン付きメッセージからGASのエンドポイントを呼び出す方式にしました。ボタン選択にすることで、家事名の表記ゆれも避けられます。 Looker Studioで可視化する 記録したログは、Looker Studioで可視化しました。 主に見ているのは、今週の家事ポイントと、どのジャンルの家事が多いかです。 ポイントで家事の大変さを完全に表せるわけではありませんが、偏りや貢献が数字で見えるだけで、感覚だけで話すより冷静に振り返れるようになりました。 導入して変わったこと 導入して一番変わったのは、「自分ばかり家事をしている」という感覚が減ったことです。 数字として見えるようになると、相手がやってくれていた家事にも気づきやすくなります。また、自分のポイントが増えると少しうれしく、家事に対するモチベーションも上がりました。 誤タップをきっかけに「押したならやるか」と実際に家事をすることもあり、記録の仕組みが行動にも少し影響するのは想定外でした。 苦労しているところ：Alexa連携 次の改善として、Alexaからの音声入力にも挑戦しています。当初はAlexaをメイン入力、Slackボタンを補助入力にする想定でしたが、現在はDeveloper Consoleのシミュレータでは動く一方で、実機ではLambdaまでリクエストが届かない状態です。 今回は完成しているSlack入力を中心に紹介しましたが、音声入力までできると、さらに記録のハードルを下げられそうです。 まとめ Claudeに要件定義から相談し、Slack、GAS、Google スプレッドシート、Looker Studioを組み合わせて、家庭内の家事トラッキングシステムを作りました。 使っている技術はどれも一般的なものです。それでも、普段の生活に合う入力導線を作り、家事を自分たちの基準で定義し、リアルタイムに可視化することで、家事分担のモヤモヤを減らすことができました。 今回の一番の学びは、AIを使うことで、既存アプリでは合わせきれなかった家庭ごとの事情を要件として整理し、自分たち用の小さな仕組みに落とし込めることです。 同じように、家庭内のタスク管理や家事分担にモヤモヤを感じている方の参考になればうれしいです。