本記事は 2026 年 7 月 1 日 に公開された「 Run log analytics for a fraction of the cost with the new engine for Amazon OpenSearch Service 」を翻訳したものです。 Amazon OpenSearch Service はリアルタイムの検索・分析エンジンで、AI ワークロードからログ分析まで幅広く使われています。業界全体で見ると、組織が扱うログ量は毎年 30〜40% ずつ増え続けており、オブザーバビリティ基盤のインフラコスト膨張とクエリ速度の低下が避けられない状況です。必要なデータを残すか、予算を守るか。多くのチームがこの二択を迫られています。 今回、Amazon OpenSearch Service にログ分析専用の新エンジンが加わりました。価格性能比は最大 4 倍、データ取り込み速度は 2 倍、分析クエリは最大 2 倍高速、ストレージコストは最大 70% 削減されます。ログ分析に最適化しつつも、OpenSearch の強みである全文検索は同じデータに対してそのまま使えるため、コスト削減と検索能力のトレードオフに悩む必要がなくなります。 この記事では新エンジンの仕組み、使い始める手順、そして数十億ドキュメントを使ったベンチマーク結果を紹介します。 最適化エンジンの仕組み 最適化エンジンは Amazon OpenSearch Service ドメイン内の新しいエンジンモードです。コンソール、API、セキュリティモデル、ネットワーク設定はすべて汎用エンジンと共通なので、運用の仕組みを変える必要はありません。 内部では、すべてのデータが Apache Parquet 形式で保存されます。検索対象として設定したフィールドには転置インデックスも作られるため、カラムナストレージの効率と全文検索の速度を両立しています。クエリが来ると Apache Calcite が解析・最適化を行い、カラムナデータの集計は Apache DataFusion、全文検索は Lucene と、処理に応じて最適なエンジンに振り分けます。この 2 つはクエリの途中で連携するため、ログ本文の検索と集計を 1 回のリクエストで完結できます。 利用者から見ると、取り込みには汎用エンジンと同じ REST API やクライアントライブラリがそのまま使えます。エージェントやパイプラインの変更は不要です。クエリ言語は Piped Processing Language (PPL) と SQL の 2 つに対応しており、どちらもベクトル化エンジンで直接実行されます。なお Domain Specific Language (DSL) のクエリ API はローンチ時点では未対応です。 使い方 ローンチ時点では、最適化エンジンはドメイン作成時に選ぶドメインレベルの設定です。既存ドメインへの追加や、個別インデックス単位での有効化には対応していません。最適化エンジンを使うには新しいドメインを作成し、取り込みパイプラインをそちらに向ける必要があります。 Amazon OpenSearch Service コンソールで新規ドメインを作成し、ユースケースに Observability を選ぶと、最適化エンジンがデフォルトで有効になった状態でドメインが構成されます。コンソール上には両エンジンの機能比較が表示されるので、自分のワークロードにどちらが適しているか判断できます。 ドメインが準備できたら、汎用エンジンと同じ Bulk API とクライアントライブラリで JSON を投入できます。既存の取り込みパイプラインやアプリケーションコードをそのまま流用できるため、移行時にコード変更は不要です。 ログ分析向け最適化エンジンのメリット 新エンジンで得られる改善をまとめます。 最大 4 倍の価格性能比 — 私たちが実施したベンチマークで汎用エンジンと比較した結果です。インシデント調査用の全文検索も引き続き利用できます。 最大 2 倍の分析クエリ速度 — データをカラム単位のバッチにまとめて処理するベクトル化実行パスにより、大規模データセットでも高速に結果を返します。 最大 2 倍の取り込みスループット — 追記専用のカラムナ書き込みパスで、持続的な取り込みレートが向上します。 最大 70% のストレージ削減 — カラムナストレージにより同じコストで最大 3 倍のデータを保持できます。 以下のセクションでは、数十億ドキュメント規模のオブザーバビリティワークロードで実施したベンチマークの方法、環境、結果を説明します。実際のワークロードでの効果はユースケースごとに異なるため、ご自身の環境でもテストされることをおすすめします。 ベンチマークの方法 OpenTelemetry の Telemetry Generator で合成トレースとログを大量に生成し、OTEL トレース、OTEL ログ、Web サーバーアクセスログの 3 種類のデータセットを作りました。生成データは bulk 形式の NDJSON として Amazon Simple Storage Service (Amazon S3) に保存し、AWS Fargate 上の Amazon Elastic Container Service (Amazon ECS) パイプラインで取り込みました。パイプラインは S3 からチャンクを読み、タイムスタンプを変換して OpenSearch の Bulk API に書き込む構成で、本番のオブザーバビリティフローを再現しています。 テスト環境は OpenSearch 3.5 を動かす 2 つの OpenSearch Service ドメインで、それぞれ 3 アベイラビリティゾーン構成、データノード 9 台です。 構成 最適化エンジン Standard Lucene インスタンスタイプ 9x or2.4xlarge.search 9x r8g.4xlarge.search リーダーノード 3x m7g.large.search 3x m7g.large.search EBS 2,500 GB gp3、7,500 IOPS、500 MB/s (ノードあたり) 2,500 GB gp3、7,500 IOPS、500 MB/s (ノードあたり) エンジンモード OPTIMIZED General Purpose ( best_compression ) 3 データセット合計で 244 億ドキュメント、9.5 TB の生 JSON を取り込みました。インデックスは 9 プライマリシャード、1 レプリカで、ISM ロールオーバーはプライマリシャードあたり 50 GB に設定しました。Lucene 側は best_compression (zstd) コーデック + _source 有効で、一般的な本番構成を再現しています。 取り込みパイプラインは同一 VPC 内の Fargate タスク 90 個 (各 16 vCPU、120 GB RAM、48 ライタースレッド、バルクサイズ 3,000 ドキュメント) で実行しました。 結果 取り込みスループット 最適化エンジンは追記専用のカラムナストレージを採用しており、ドキュメントごとに stored field を書く必要がありません。複数ドキュメントをまとめてカラムナセグメントとして一括書き込みするため、高いスループットを実現しています。 メトリクス 最適化エンジン Lucene ベースライン ピークスループット 178 万 docs/sec 約 64.7 万 docs/sec ピーク時クラスタ CPU 62% 72% Write rejection 0 0 取り込みドキュメント総数 244 億 157 億 同じ並列度で毎秒 178 万ドキュメントを維持し、Lucene の約 2 倍のスループットを CPU 負荷を抑えながら達成しました。write rejection は両ドメインともゼロでした。1 日に数テラバイトを取り込むチームなら、同じ量をより少ないノードで捌けるか、同じインフラでより長い保持期間を取れることになります。 ストレージ圧縮 Parquet のカラムナ形式では、同じフィールドの値がまとめて格納されるため、辞書エンコーディングや型に特化した圧縮が高い効率で効きます。加えて、行単位で生 JSON を保持する必要がないため、オブザーバビリティデータのストレージを大幅に削減できます。 244 億ドキュメントでの実測値: データセット ドキュメント数 ソース 最適化エンジン Lucene (デフォルト) 圧縮率 vs. ソース Lucene 比削減率 Web ログ 87.6 億 2,360 GB 254 GB 614 GB 89% 59% OTEL ログ 82.0 億 3,720 GB 815 GB 1,549 GB 78% 47% OTEL トレース 74.3 億 4,131 GB 841 GB 1,790 GB 80% 53% 合計 244 億 9,539 GB 1,910 GB 3,953 GB 80% 52% 結果として、生 JSON に対して 5 倍の圧縮 (80% 削減) を達成しています。デフォルトの Lucene 構成 ( _source 有効) と比べてもストレージはおよそ半分です。最適化エンジンは _source をクエリ時に Parquet カラムから再構成するため、ドキュメントの取得機能を維持しつつ生 JSON を別途保存する必要がなくなっています。 分析クエリ性能 オブザーバビリティダッシュボードの典型的なパターンとして、数十億のログイベントに対し 15 分間のタイムウィンドウで絞った分析集計のレイテンシーを計測しました。最適化エンジンは @timestamp カラムの row-group プルーニングでクエリ対象外のデータをスキップし、必要な部分だけを読みます。 クエリパターン データセット 最適化エンジン Lucene ベースライン 高速化倍率 サービス別エラー数 OTEL ログ 717 ms 2.8 s 3.9x ホスト別ログ量 OTEL ログ 252 ms 17.6 s 70x サービス・メソッド別 5xx エラー OTEL ログ 171 ms 885 ms 5.2x エラー上位サービス OTEL トレース 635 ms 569 ms 約 1x ポイントルックアップ (単一 traceId) OTEL トレース 394 ms 783 ms 2x すべてのクエリは 15 分ウィンドウでスコープ。インデックスサイズ: OTEL ログ 82 億イベント、OTEL トレース 74 億スパン。 最適化エンジンは、数十億ドキュメントに対する時間フィルター付き分析クエリを 171 ms〜717 ms で完了しました。特にフィルターなしの集計 (ホスト別ログ量: 70 倍高速) で差が顕著に現れており、必要なカラムだけを読むカラムナエンジンの特性が効いています。一方、Lucene の転置インデックスが高い選択性を発揮するクエリ (トレースのエラー上位サービス) では両者の性能は同程度でした。 検索とポイントルックアップ 分析だけでなく検索も高速です。最適化エンジンはカラムナストレージと Lucene 転置インデックスの両方を持っており、クエリプランナーが選択的なルックアップ (特定の traceId の検索など) を検出すると、カラムナスキャンではなく転置インデックスにルーティングします。74 億スパンに対する単一 traceId ルックアップは 165 ms で完了しました。 実際の障害調査では、まず集計で問題を絞り込み、次にポイントルックアップで該当トレースを引く、という流れが 1 つのドメインで完結します。 提供開始 Amazon OpenSearch Service のログ分析向け最適化エンジンは、OpenSearch Optimized Instances が利用できるすべての商用 AWS リージョン (AWS GovCloud (US) および中国リージョンを除く) で一般提供されています。 料金はインスタンスとストレージの標準 Amazon OpenSearch Service 料金に準じ、最適化エンジンの追加費用はかかりません。詳細は Amazon OpenSearch Service の料金 を参照してください。 設定と使い方の詳細は Optimized for Log Analytics (Amazon OpenSearch Service ドキュメント)、サービス概要は Amazon OpenSearch Service Log Analytics を参照してください。 フィードバックは AWS re:Post for Amazon OpenSearch Service または AWS サポートまでお寄せください。 著者について Jagadish Kumar Jagadish は Amazon Web Services のシニアソリューションアーキテクトで、OpenSearch と分析ワークロードを担当しています。 Rohin Bhargava Rohin は Amazon OpenSearch Service のシニアプロダクトマネージャーです。 Michael Supangkat Michael は Amazon Web Services のソリューションアーキテクトで、検索とオブザーバビリティを専門としています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

みなさんこんにちは！本ブログではApache Kafkaの強力なコア概念である 「コンシューマーグループ（Consumer Group）」 を取り上げていきます。今回はPythonとtmux（4分割ターミナル）を使い、トピックへ100件のイベントを送信した際の挙動と、裏側の分散ロジックについて検証した記録をまとめました。 1. コンシューマーグループ（Consumer Group）とは Kafkaは、データを受け取る受信アプリを「グループ」という単位で管理します。このグループの組み方によって、1つのトピックに対して2つの異なる挙動を同時に実現できます。 異なるグループ間 ➔ パブサブ型（イベントの複製）： 別のグループ同士には、まったく同じデータがそれぞれ全件コピー（複製）されて配信されます。 同じグループ内 ➔ キュー型（負荷分散）： 同一グループ内のサーバー同士では、データを重複することなく綺麗に分担して配信されます。 2. 検証デモの実行手順と環境構成 パーティション数を「3」に設定したトピック five を作成し、ターミナルをtmuxで4分割して以下の手順で検証を行いました。 【左上・左下ペイン】 Group-X（2台起動）： 負荷分散を検証するコンシューマー（Consumer-X1 / X2） 【右上ペイン】 Group-Y（1台起動）： イベントの複製（全件受信）を検証するコンシューマー（Consumer-Y1） 【右下ペイン】 Producer： 送信側から userA 50件、 userB 50件（計100件）を連続送信 3. 使用したPythonスクリプト 検証に使用した主要なソースコードです。（事前に pip install confluent-kafka の実行が必要です） ■ 受信側：consumer_flexible.py from confluent_kafka import Consumer import sys group_id = sys.argv[1] consumer_id = sys.argv[2] conf = { 'bootstrap.servers': 'localhost:9092', 'group.id': group_id, 'auto.offset-reset': 'earliest' } consumer = Consumer(conf) consumer.subscribe(['five']) print(f"--- 【{consumer_id}】 グループ【{group_id}】としてデータ待ち中... ---") try: count = 0 while True: msg = consumer.poll(1.0) if msg is None: continue if msg.error(): continue count += 1 print(f"[{count}件目] Key: {msg.key().decode('utf-8')}, Value: {msg.value().decode('utf-8')}") except KeyboardInterrupt: pass finally: consumer.close() ■ 送信側：key_producer.py from confluent_kafka import Producer import time p = Producer({'bootstrap.servers': 'localhost:9092'}) print("データの送信を開始します（100件）...") for i in range(50): p.produce('five', key='userA', value=f'data-A-{i}') p.produce('five', key='userB', value=f'data-B-{i}') p.flush() time.sleep(0.05) print("送信完了") 4. デモの実行結果と受信件数 ▼ デモ実行画面（プロデューサーからイベント送信中の様子） イベント送信完了後、各ペインに立ち上げたコンシューマーの受信ログおよび最終的な合計件数は以下の通りになりました。 グループ名 サーバーID 最終受信件数 ログから見えた決定的な特徴 Group-X (2台構成) Consumer-X1 50件 userB のイベントのみを100%固定受信（負荷分散） Consumer-X2 50件 userA のイベントのみを100%固定受信（負荷分散） Group-Y (1台構成) Consumer-Y1 100件 全件（ userA userB ）を漏れなく受信（イベントの複製） なぜ自動的に綺麗に分かれたのか？裏側の仕様 ソースコード側には割り当ての設定を1行も記述していません。それなのにこの結果になったのは、Kafkaのデフォルトの仕様によるものです。 Keyによる「固定配置」： 送信時にユーザー名をKeyに指定したため、Kafkaが自動的にハッシュ値を計算し、 userA はパーティション2、 userB はパーティション1へと固定配置しました。 重複なき「自動割り当て」： 3つのパーティションに対して同じグループに2台のサーバーがいたため、Kafkaは裏側で自動的に仕事を割り振りました（X1がパーティション1、X2がパーティション2を担当）。 この2つの標準仕様が合体した結果、 「負荷を完全に分散させつつ、同じユーザーのデータは必ず同じサーバーに届く（順序性の保証）」 という挙動が完全自動で実現しています。 5. まとめ 今回の実証デモを通して、コンシューマーグループを分けることで「イベントの複製（並列処理）」、グループ内では「負荷分散・順序保証」が完璧に行えることが確認できました。 データ量が増えても、プログラムを1行も変えずにコンシューマーの台数を増やすだけで処理能力を水平スケールできる、Kafkaの洗練された設計の美しさを体感できる検証となりました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Apache Kafkaのコンシューマーグループとは？～イベントの「複製」と「負荷分散」について first appeared on SIOS Tech Lab .

本記事では、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 層で成り立っています。 本部の「問い」 — 本部は「今日気になったお客様の反応は？」「新しい商品の売れ行きは？」といった、確実に確認したい内容を定型質問として設定します。これはノーコードで編集可能で、キャンペーンや季節に合わせていつでも差し替えられます。 AI の「深掘り」 — 本部が設定した質問に対するスタッフの回答内容を起点に、AI が “なぜ？” を追いかけます。深掘りの仕方はプロンプトで調整でき、本部の仮説や関心を AI に埋め込むことができます。音声入力にも対応しており、閉店後、片手間でも答えられる設計です。 気づきがデータに — 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 点を軸に設計しました。 フルサーバーレス — DB・インスタンスなどサーバーレス構成のため、運用負荷が低く、また使われていない時間帯のコストを低く抑えることができます。 CDK ワンコマンドデプロイ — git clone して cdk deploy --all するだけで、約 20 分で環境一式が立ち上がります。 リージョン — デフォルトリージョンを ap-northeast-1 で指定しており、インスタンス・DB・LLM 実行などのデータを国内リージョンにとどめて利用が可能です（グローバル配信を担う Amazon CloudFront とそれに紐づく AWS WAF は us-east-1 に配置されます）。 図4. SMART の AWS アーキテクチャー 各サービスの役割は次の通りです。 レイヤ サービス 役割 フロントエンド配信 Amazon CloudFront + Amazon S3 + AWS WAF React アプリのグローバル配信、アクセス制御 認証 Amazon Cognito（User Pool） JWT トークンベースのユーザー認証、店舗所属グループ管理 Transcribe 認可 Amazon Cognito（Identity Pool） 認証済みユーザーに Transcribe Streaming の最小権限を払い出し 音声入力 Amazon Transcribe Streaming（ ja-JP ） ブラウザの AudioWorklet から送られた音声をリアルタイム文字起こし API エンドポイント Amazon API Gateway（REGIONAL）+ AWS WAF REST API、Cognito Authorizer で認証、WAF で IP・ドメイン制限 API 実行 AWS Lambda（Python 3.13、FastAPI + Mangum） ビジネスロジック、AgentCore Runtime の呼び出し AI エージェント実行 Amazon Bedrock AgentCore Runtime Strands Agents で書いた 2 種類のエージェントをサーバーレスでホスト 会話履歴の永続化 Amazon Bedrock AgentCore Memory セッション単位の短期記憶、actor 単位の長期記憶 LLM Amazon Bedrock（Claude） エージェントの思考・応答生成、日報マークダウンの生成 データ基盤 Amazon S3 Tables（Apache Iceberg）+ Amazon Athena アンケート・売上・チャット履歴・マスタを単一クエリで結合 ここでは、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 つです。 質問項目 — 管理画面からノーコードで編集できます。 admin_survey テーブルに保存され、キャンペーンや季節などに応じて差し替え可能です。 AI の引き出し方（プロンプト） — 現行実装では cdk/prompt/ 配下のテキストファイルを編集します。自社で本格運用する際は、本部の運用担当者が管理画面から直接編集できる形に発展させることを推奨します。 データソース — 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 です。