店舗の気づきを本部に届ける AI エージェント SMART のご紹介 — Amazon Bedrock AgentCore × Strands Agents によるユナイテッドアローズでの取り組み

本記事では、AWS サンプルアセットである AI エージェント SMART（Store Manager Agent for Retail Tech） についてのご紹介と、それを活用した株式会社ユナイテッドアローズ（以下、ユナイテッドアローズ）の取り組みについてご紹介します。小売業にとって、店舗の声をどう本部に届けるかは永遠のテーマです。売上数字の裏には、現場スタッフだけが感じている気づきが必ずあります。しかし店舗の日報や週報のフォーマットだけでは、その気づきを届けるのは難しいのが実情です。SMART は、店舗の気づきを AI の力で引き出し言語化して、本部に届けることを支援するために誕生しました。

1. 現場の気づきをどう本部に届けるか

店長・店舗スタッフの皆さんは、毎日、たくさんの気づきを生み出されています。「今日は雨だったけれど、来店されたお客様の購買率は高かった」「新しいデザインの商品についてお客様の反応が予想以上にいい」「休憩の回し方を変えたら接客効率が上がった気がする」。こうした気づきは、売上や客数といった定量データだけでは見えない、店舗運営にとってかけがえのない手がかりです。
一方で、一日の売場で生まれる数多くの気づきを、閉店後の限られた時間のなかで日報の自由記述欄に記録するのは、仕組みとして難しいところがあります。接客、在庫確認、レジ締め、翌日準備をこなしたあとに、うまく言葉にしづらい感覚的な気づきまで文章化するのは、誰にとっても相応の負担がかかる作業です。現場で毎日生まれている観察の豊かさに対して、日報フォーマットが持つ受け皿で拾うには、自ずと限界があります。本部側としても、定型フォーマットの数字だけでは現場の肌感が読み取れず、良い兆候があっても背景までは見通しにくい状況があります。
このような課題は小売業界全体に共通しています。米国・カナダの小売業界のリーダー 227 人を対象にした Zipline 社の調査「Misaligned」2026 によれば、店舗施策が正しく実行される確率は 36% にとどまり、その主な原因としては 人員不足（51%） と 時間不足（32%） が挙げられています。店舗リーダーの 70% は「本部にフィードバックを伝える明確な手段がない」と答え、43% の小売リーダーが「実行不備による売上・収益の損失」を経験していると報告しています。
海外の調査ではありますが、日本の小売業の現場でも、似たような課題を感じておられる企業は多いのではないでしょうか。

業界も同じ課題に向き合っている — Tapestry の事例

こうした課題は、グローバルの大手企業も向き合ってきたテーマです。Coach や Kate Spade などのブランドを展開する Tapestry 社（ 2024 年時点で、世界 70 カ国以上で約 1,400 店舗を運営）は、店舗の第一線で生まれる気づきを本部に届ける仕組みの必要性を認識し、AWS 上で Tell Rexy というフィードバック収集アプリを開発しました。Amazon Bedrock と Amazon Transcribe を組み合わせて音声入力に対応させ、1 年で 約 3 万件 の気づきを集め、マーチャンダイジングの改善に活かしています（AWS Case Study: Tapestry）。

SMART は、ユナイテッドアローズの店舗運営に関わる事業部門の声を伺いながら、AWS のプロトタイピングエンジニアがサンプルを開発し、AWS Samples として公開しました。

2. SMART のアプローチ — 本部の「問い」× AI の「深掘り」

なぜ “自由記入欄” では不十分なのか

忙しい閉店後の店舗スタッフに、日報フォーマットの自由記入欄や、普段コミュニケーションとして使っているチャットアプリケーション等に今日の気づきを書くのは難しいはずです。仮に仕組みとして「今日はどうでしたか」と問いかける形でも、返す答えは 「普通でした」「特に問題なし」 で終わるのではないでしょうか。一日の疲れのなか、自分の気づきを一から構造化して語るのは、誰にとっても負担が大きい作業のはずです。
SMART は、この前提を逆転させました。名前の通り、Store Manager Agent for Retail Tech — 店長を助ける AI エージェントです。ポイントは、本部からの “問い” を起点に AI が現場に深掘りする設計にあります。

3 層の設計

SMART は、次の 3 層で成り立っています。

1. 本部の「問い」 — 本部は「今日気になったお客様の反応は？」「新しい商品の売れ行きは？」といった、確実に確認したい内容を定型質問として設定します。これはノーコードで編集可能で、キャンペーンや季節に合わせていつでも差し替えられます。
2. AI の「深掘り」 — 本部が設定した質問に対するスタッフの回答内容を起点に、AI が “なぜ？” を追いかけます。深掘りの仕方はプロンプトで調整でき、本部の仮説や関心を AI に埋め込むことができます。音声入力にも対応しており、閉店後、片手間でも答えられる設計です。
3. 気づきがデータに — AI との一連の対話は、店舗名・日付・カテゴリといった構造化情報に変換され、売上などの定量データと同じ場所に蓄えられます。翌朝、店長や本部側には「売上データ × 現場の気づき」を掛け合わせたインサイトが届きます。

具体例：雨の日に何が起きたのか

たとえば、本部が 「今日のお客様の反応で、気になったことは？」 と問いかけたとします。あるスタッフが「雨だったけど、購買率は高かった」と答える。ここで従来のアンケートなら、この回答は「雨 / 購買率高」とタグ付けされて終わります。SMART の場合、ここから AI が 「どんなお客様が来店されましたか？」 と深掘りします。「目的買いの方が多かった気がする。あ、今週発売した限定商品の T シャツを求めにきた若い男性が多く、それに似合うパンツも一緒によく売れました」という回答が返ってくる。この一連のやりとりから、「雨天 × 目的買い → 客単価が上がる可能性」 というインサイトが生まれます。翌朝、同じ問いへの回答が他店舗からも集まっていれば、本部は「この傾向は自店舗固有か、横展開できる学びか」 を、その日のうちに判断する材料として手にできます。

設計思想 — AI を介して、立場の異なる人どうしをつなぐ

SMART が目指しているのは、立場の異なる人や組織を、AI やデータを介してつなぐという使い方です。興味深いのは、会話から生まれた気づきがデータ資産として蓄積される点にあります。元のコミュニケーションの当事者間（店舗と本部）を超えて、別の店舗や部門、別の AI エージェントがその資産を活用することができます。たとえば、商品企画の担当者が「去年の同時期、現場ではどんな気づきがあったか」を過去のデータから振り返る、あるいは別の AI が需要予測をするときに現場の声も参考材料にする、といった 他部門・他業務での再活用にも発展することが可能になります。
店舗の第一線と、本部の意思決定、そのあいだに AI エージェントを置くことで、本部の問いが現場に届き、現場の気づきが本部に還ってくる。さらに、その会話そのものが構造化されたコミュニケーションデータとして蓄積され、時間とともに双方の判断を支える資産になっていきます。
AI 任せでも、現場任せでもないこのバランスが、限られた時間のなかで豊かな気づきを引き出す鍵ではないかという仮説を持っています。AI がコミュニケーションを円滑にし、データを蓄積し、立場の異なる双方の意思決定を支える — SMART が目指しているのは、そうした関係性の支援です。

3. SMART を使うと何が起きるか — 画面と 1 日の流れ

3.1 3 つの画面と 1 日の流れ

SMART は店舗スタッフと店長、それぞれの時間軸で主に  3 つの画面が連動して動きます。動画と合わせて利用シーンについて説明します。

閉店時に店舗スタッフが実施

① 日次アンケート画面 — 定型質問に数分で回答
閉店後、店舗スタッフまたは店長がログインして最初に開く画面です。本部が事前に設定した定型質問（星評価・選択式・自由記述・数値）に、数分で回答します。画面上部には管理者や本部からの連絡事項も表示され、日報入力時に考慮して欲しい事項（新商品やキャンペーン、急な店舗オペレーションの変更など）を掲載することで、それに関連する気づきがあれば入力してもらうことを促すことができます。

② AI チャット画面 — AI が “なぜ” を深掘りする
アンケート回答を提出すると、AI チャット画面に移ります。本部が設定したプロンプトに沿って、AI がスタッフの回答を起点に “なぜ” を深掘りします。「なるほど、コラボ T シャツが売れたんですね。それは確かに珍しいから、お客さんも興味を持ちやすいですよね」といった自然な会話で追加ヒアリングが進みます。マイクアイコンから音声入力にも対応しており、片手間でも答えられます。

図1. 閉店時の店舗スタッフの実施イメージ — ① 日次アンケート（本部が設定した定型質問に数分で回答）→ ② AI チャット（本部が設定したプロンプトに沿って AI が追加ヒアリング）

翌朝に店長が実施

③ Daily Insights 画面 — AI が売上 × 気づきを統合して分析する

翌朝、店長が確認できる AI からのフィードバック画面です。売上金額・購入件数・購入率（前日比・目標比）といった定量データに、前日の店舗スタッフによる日次アンケート回答と AI 対話から抽出した定性の「気づき」を統合し、AI が客観的分析結果を応答します。「売上達成／阻害要因の分析」「AI の気づき」「今日のアクション提案」という形で、本部の意思決定に直結するインサイトが 1 ページにまとまっています。AI に回答して欲しい内容は、プロンプトでチューニングが可能です。なお、売上などの定量データについては、すでにそのデータを管理する DB や DWH システムが別に存在することが一般的であるため、それらと連携するためのカスタマイズが必要となります。またこれらのデータは日次集計されているケースが多いため、翌朝にフィードバック確認の実施を想定しています。

図2. Daily Insights（AI が売上 × 定性データを統合して生成したフィードバック）を確認

3.2 リクエスト〜レスポンスのシーケンス

1 日の中で SMART が行う処理を、閉店後のアンケート入力と AI 対話、翌朝確認するフィードバックに分けて表現すると次のようになります。

図3. SMART のリクエスト〜レスポンスのシーケンス

閉店後はスタッフとの対話（hearing エージェント）、翌朝は日報生成（daily_summary エージェント）の 2 つが別のタイミングで動きます。

4. ユナイテッドアローズでの取り組み

4.1 導入の背景と取り組みの概要

ユナイテッドアローズは、1989 年の設立以来、日本のファッションアパレル業界をリードする小売企業です。同社でも「日報が手入力、週報作成には 2,3 時間要している」「店長の記憶頼りで報告粒度が店舗間で異なる」という、多くの小売業に共通する課題を抱えていました。解決するためのアイデアはあるものの、専任の内製開発体制があるわけではなく、企画からモック作成・PoC までに時間がかかることが、新しい仕組みを試すうえでのハードルになっていました。一方、Kiro をはじめとした AI の活用を進めてきた中で、「今なら自分たちでも開発できるのではないか」という仮説のもと、AWS Prototyping Program を組み合わせて、プロトタイプの作成と内製開発力の獲得を同時に進めるアプローチを採りました。
取り組みは 2025 年 12 月から 2026 年 3 月にかけて、IT 部門、事業部門・店舗スタッフが連携して実施しました。SMART をベースに Kiro を活用して内製でカスタマイズをして、 4 店舗の協力のもと PoC を実行しました。目指したのは、現場の空気感や気づきを鮮度の高いうちに吸い上げ、構造化・データ化して戦略立案の土台にすることです。そして店舗スタッフが接客に集中できる環境を整えることでした。

4.2 店舗スタッフ・店長の声

PoC 後のアンケートでは、「誰もが直感的に操作できる」「曖昧で感覚的な表現を、具体化する質問で引き出してくれる」「『事実・考察・改善案』に分けて整理してフィードバックしてくれる」といった声が寄せられ、複数の設問で 8 割以上のスタッフが「当てはまる」と回答し、高い評価を得ました。
店長からは、こんな声がありました。「昨日の店舗がどうだったかを、わざわざ人に聞かなくてもすぐに把握できるようになった」。さらに想定していなかった変化として、「AI が『なぜ』を深掘りしてくれることで、スタッフ自身に『考える習慣』や『改善行動を意識する姿勢』が広がってきた」という気づきも語られました。日報の入力支援にとどまらず、現場の思考の質そのものに作用しはじめている点が印象的です。

4.3 本部スタッフの声

本部側にも変化がありました。「現場から直接ヒアリングする時間を減らせた」という業務効率の面に加えて、「店舗スタッフを効率よく配置するためのヒントが得られ、売上向上につながる気づきがあった」という、意思決定に直結する手応えも得られています。これまで数字だけでは見えなかった現場の “なぜ” が、定量データと並んで本部に届くようになったことで、施策の打ち手を考える材料が広がりつつあります。

4.4 加藤 大輔 氏のコメント — 開発視点での副次効果

「当初は、店舗スタッフの『日報業務の効率化』を主目的に始めましたが、実際にやってみて最も価値を感じたのは別のところでした。AI からのフィードバックを受けることで現場が能動的に改善を意識して行動するようになったと聞き、大きな手応えを感じています。また、AWS Prototyping Program という AWS さんからの支援 と Kiro を組み合わせたことで、内製開発の経験が少ない私たちでも、企画段階から事業部門とともに課題と要件の解像度を上げながら取り組みを進めることができました。後工程の手戻りや無駄な投資を抑えながらも、何よりチームメンバーの成長を感じることができたことは、今後の社内 DX を進めるうえで大きな財産になっています。」 — 加藤 大輔（IT ソリューション本部 IT セキュリティ部 副部長）

5. アーキテクチャと技術詳細

5.1 全体像

SMART のアーキテクチャーは、次の 3 点を軸に設計しました。

1. フルサーバーレス — DB・インスタンスなどサーバーレス構成のため、運用負荷が低く、また使われていない時間帯のコストを低く抑えることができます。
2. CDK ワンコマンドデプロイ — git clone して cdk deploy --all するだけで、約 20 分で環境一式が立ち上がります。
3. リージョン — デフォルトリージョンを ap-northeast-1 で指定しており、インスタンス・DB・LLM 実行などのデータを国内リージョンにとどめて利用が可能です（グローバル配信を担う Amazon CloudFront とそれに紐づく AWS WAF は us-east-1 に配置されます）。

図4. SMART の AWS アーキテクチャー

各サービスの役割は次の通りです。

ここでは、Agent 実行基盤・Agent 構成の 2 つについて解説します。

5.2 Agent 実行基盤 – Amazon Bedrock AgentCore

Agent の開発・運用では、Agent の実行場所、メモリ戦略、ログの運用管理など様々な周辺機能が必要になります。特に、メモリ戦略では短期記憶・長期記憶をどう切り分け、どこまで遡り、何を要約するか。それらを自前で実装することもできますが、ここに手をかけすぎずに Agent のコアロジックの実装にできるだけ時間を割きたいと思われる方が多いと思います。 そこで SMART では、Agent を効率的に開発・運用するためのマネージドサービスである Amazon Bedrock AgentCore から、以下 2 つの機能を利用しています。

Amazon Bedrock AgentCore Runtime:

AgentCore Runtime は Agent の実行基盤をすぐに立ち上げることができ、フルマネージドのため細かなインスタンスの運用管理が不要です。以下のように、Agent のコード内に Runtime のエントリポイントを定義することで実装できます。BedrockAgentCoreApp が HTTP リクエストの受け口になり、@app.entrypoint で関数を登録するだけで、ローカルでもクラウド（AgentCore Runtime）でも同じコードが動くため、ローカルでの検証やデバッグなど開発が行いやすいです。

# backend/store-agent/agentcore_main.py （一部抜粋）
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from agent_router import route_agent_request
app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload, context):
        return route_agent_request(payload)
if __name__ == "__main__":
    app.run()

Amazon Bedrock AgentCore Memory:

AgentCore Memory は、細かな Agent Memory ロジックの実装なしにすぐに立ち上げ、使い始めることができ、Strands Agents とも簡単に連携できます。AgentCoreMemorySessionManager を Strands Agents の Agent に渡すだけで、会話履歴の取得・保存が自動で行われます。アプリ側で「前回のセッションの取得」や、「プロンプトへの挿入」といったコードを書く必要がありません。

# backend/store-agent/hearing_agent.py （一部抜粋）
from strands import Agent
from bedrock_agentcore.memory.integrations.strands.config import AgentCoreMemoryConfig
from bedrock_agentcore.memory.integrations.strands.session_manager import (
    AgentCoreMemorySessionManager,
)

def create_hearing_agent(session_id=None, actor_id=None) -> Agent:
    bedrock_model = get_bedrock_model()
    system_prompt = _load_system_prompt("hearing_system_prompt.txt")

    memory_id = config.HEARING_AGENTCORE_MEMORY_ID
    memory_config = AgentCoreMemoryConfig(
        memory_id=memory_id, session_id=session_id, actor_id=actor_id
    )

    session_manager = AgentCoreMemorySessionManager(
        agentcore_memory_config=memory_config, region_name=config.REGION
    )

    agent = Agent(
        model=bedrock_model,
        system_prompt=system_prompt,
        session_manager=session_manager,
        tools=[],
    )
    return agent

5.3 Agent 構成

SMART の Agent は、 Strands Agents を使って以下の 2 つの Agent を実装しています。 SMART では、Agent のプロンプトをテキストファイルとして Amazon S3 に配置し、バージョニング管理しています。利用開始後にユーザーからのフィードバックや、業務要件の変化に合わせてプロンプトを修正したい時に、アプリケーションの改修なしにすぐにプロンプトを更新することが可能です。

① ヒアリングエージェント（hearing）

閉店後の店舗スタッフへの追加ヒアリングを担います。事前にスタッフが回答したアンケート結果を Agent に渡し、回答の背景にあるコンテキスト情報を引き出す質問を考えます。質問の量や掘り下げる観点でプロンプトを記述しています（cdk/prompt/hearing_system_prompt.txt）。

② 日次サマリエージェント（daily_summary）— ツールでデータを引いてレポート生成

翌朝の Daily Insights を生成するエージェントです。こちらは次の 2 つのツール を持ち、それぞれが Athena にクエリを投げてデータを取得します。

• get_previous_day_survey_data — 前日の日次アンケート回答を取得（定性データ）
• get_store_sales_data — 前日の売上金額・来客数・購入件数・購入率・予算達成率などを取得（定量データ）

この 2 つを組み合わせることで、「定量 × 定性」の両輪 で AI からのフィードバックを生成します。

6. 今すぐ試してみよう

SMART は、GitHub で公開しています。デプロイ手順や環境準備は、リポジトリの DEPLOYMENT.md をご覧ください。

自社に合わせるカスタマイズポイント

SMART をそのまま使うのではなく、自社の業種・業態に合わせて調整するポイントは主に 3 つです。

1. 質問項目 — 管理画面からノーコードで編集できます。admin_survey テーブルに保存され、キャンペーンや季節などに応じて差し替え可能です。
2. AI の引き出し方（プロンプト） — 現行実装では cdk/prompt/ 配下のテキストファイルを編集します。自社で本格運用する際は、本部の運用担当者が管理画面から直接編集できる形に発展させることを推奨します。
3. データソース — backend/store-agent/tools.py に新しい @tool 関数を追加し、daily_summary_agent.py の tools=[...] に並べれば、基幹システム側の在庫などのデータも AI に参照させて示唆を考えさせることが可能です。

まとめ

「現場の声をどう本部に届けるか」という課題は、小売業に限りません。たとえば飲食チェーンなら、営業後のヒアリングで「今日のランチ帯、満席で断ったお客様はいましたか？」といった本部からの問いに対して、AI が「その時間帯、待ち時間が長かったのは何組くらいですか？」とさらに深掘り。翌朝には、売上・原価率・回転率・スタッフシフトと前日の定性観察を統合した AI の気づきやアクション提案が店舗や本部に届けられます。ほかにも、ホテル・宿泊、物流・倉庫、医療・介護、製造業など、現場スタッフが定量データの裏にある “なぜ” を持っている業界であれば、SMART のひな型を自社に合わせてカスタマイズすることで、活用できるのではないかと考えています。
本記事では、店舗の気づきの言語化を支援し、本部に届ける AI エージェント SMART と、ユナイテッドアローズでの取り組みについてご紹介しました。忙しい店長を助ける仕組みのサンプルとして、ご活用いただけたら幸いです。

AWS Summit Japan 2026 でお会いしましょう

本記事の内容は、AWS Summit Japan 2026 でも、AWS 濱上がユナイテッドアローズ 加藤氏とのセッションでご紹介します。

• セッションID: AIM258（L200）
• タイトル : 忙しい店長を助ける AI エージェント「SMART」— ユナイテッドアローズと創る、現場の声がデータになる日
• 日時 : 2026 年 6 月 25 日（木）13:30 – 13:50
• 会場 : 幕張メッセ ホール7  Theater2

また会場では、ユナイテッドアローズの活用事例ブースでのデモ展示も実施します。
ぜひお立ち寄りください。

著者について

加藤 大輔（Daisuke Kato） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 副部長 セキュリティ、EA（エンタープライズアーキテクチャ）、データ活用領域を担当しています。社内システムの企画・運用や共通基盤の整備を推進しながら、生成 AI の活用による業務効率化や新たな価値創出に取り組んでいます。 好きな AWS サービスは Amazon Elastic Container Service です。

池添 雄起（Yuki Ikezoe） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 データ連携基盤、システム監視基盤を担当しています。好きな AWS サービスは Kiro です。

大橋 遼子（Ryoko Ohashi） 株式会社ユナイテッドアローズ IT ソリューション本部 IT セキュリティ部 業務効率化アプリの企画・開発に取り組んでいます。好きな AWS サービスは Amazon Bedrock です。

石橋 直樹（Naoki Ishibashi） アマゾン ウェブ サービス ジャパン合同会社 ML プロトタイピングエンジニア AWS では生成 AI・MLOps など AIML に関連するプロトタイピング開発、技術相談などの支援を中心に行っています。好きな AWS サービスは Amazon SageMaker AI です。好きなファッションブランドは、UNITED ARROWS green label relaxing です。

濱上 和也（Kazuya Hamagami） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 流通・小売業のお客様の技術支援を行っています。好きな AWS サービスは Amazon Connect Customer で、業界問わずコンタクトセンター関連の技術支援も行っています。好きなファッションブランドは、UNITED ARROWS green label relaxing です。