ECサイトにおける次世代顧客体験の提案アシスタントを構築 「第4回 AI Challenge Day」参加レポート

「AI Challenge Day for Retail」イベント概要

「AI Challenge Day」は、株式会社角川アスキー総合研究所と日本マイクロソフト株式会社が共同で企画・開催している生成AI開発コンテストです。特定業界の課題解決をテーマに開催されており、第4回となる今回は「小売（Retail）」に焦点が当てられました。

目的とテーマ

本イベントのテーマは「NextGen: Virtual Online Store Copilot」。ECサイトを訪れる顧客に対し、これまでにない新しい検索・購入体験を提供するAIアシスタントの開発を競います。単に質問に答えるだけでなく、RAG（検索拡張生成）やAIエージェントの技術を駆使して、多様なデータから顧客の意図を正確に読み取り、購入までをスムーズに導く能力が問われました。

ハッカソンの形式とスケジュール

開発期間は、2025年6月12日のテーマ説明会から、最終プレゼンテーションが行われる6月19日までの約1週間でした。

• 開発期間（オンライン）: 各チームはオンラインで開発を進め、期間中はマイクロソフトの技術者へ質問できるサポート窓口も設けられていました。
• 最終プレゼンテーション（オフライン）: 最終日の6月19日には、全参加チームが日本マイクロソフト品川オフィスに集結し、開発したソリューションについて各社8分間のプレゼンテーションを行いました。この様子はオンラインでもライブ配信されているのでぜひご覧ください。
  【参考】
  アスキーと日本マイクロソフトがタッグを組んだ「AI Challenge Day」4回目に突入！

評価の仕組み

評価は、「スコア」と「審査員によるプレゼン評価」の2軸で総合的に行われました。

• スコア評価:
  開発したアシスタントの性能は、専用の評価プラットフォームへのJSONファイル投稿によって自動採点されます。スコアは大きくふたつのパートに分かれていました。
  a.回答精度（問1〜4）: 事前に与えられた質問に対し、提供データに基づいてどれだけ正確かつ自然な回答を生成できるかが評価されました。
  b.仮想顧客との対話能力（問5）: 仮想顧客エージェントとの対話を通じて、購入までのターン数、購入金額、アップセル／クロスセルの成功、顧客満足度など、ビジネス成果に直結する16項目が評価されました。

• 審査員評価:
  最終日のプレゼンテーションの内容に基づき、以下の特別賞に対応する観点から評価が行われました。
  • ブレイクスルー賞: アーキテクチャの独創性、実践性
  • ASCII賞: ビジネス価値、優れたカスタマーストーリー
  • セキュリティ&トラスト賞: セキュリティや耐障害性などの実装
  • UX賞: 優れたUI／UXの実装

これらの評価を基に、総合評価として「グランプリ」「準グランプリ」が、スコアのみで「インテリジェントエージェント賞」が決まりました。

実現したい新しい検索・購入体験のコンセプト-「検索」から「対話」へ、「推定」から「理解」へ-

今回のハッカソンで私たちが目指したのは、単なるECサイトの機能改善ではありません。AIエージェントとの「対話」を軸に、ユーザーの購買体験そのものを根本から変革することです。

従来の検索体験が抱える課題を乗り越えるため、私たちは以下の3つの体験価値の変化を設計の核に据えました。

1.「要望を伝えて提案を受ける一方向コミュニケーション」から、「対話による双方向コミュニケーション」へ
従来のECサイトにおける商品検索は、ユーザーが明確な条件を設定する必要があります。ECサイトはその条件に合う商品を提示し、合わなければユーザーが再検索を繰り返します。
しかし、「大切な人へのちょっとした贈り物」や「新生活の準備をしたい」などの漠然としたニーズを持つユーザーは、その思いを適切な検索条件に変換する作業を一人で担っています。
新しい体験では、エージェントが言語化前の購買ニーズを拾い上げ、対話の中で目的の深掘りや予算の確認、イメージの具体化をサポートします。まるで実店舗で優秀な店員に相談するように、自然な会話で最適な商品に出会える――それが私たちの提案する「対話型検索」です。

2.単発提案から、顧客の「過去」を踏まえ「今」に寄り添う提案へ
「以前検討していたあの商品、まだ在庫あるかな？」「この前買ったPCに合うマウスが欲しいんだけど…」ECサイトを使うたびに、自分の状況を最初から説明するのは大きなストレスです。私たちが開発したエージェントは、ユーザーとの対話を「記憶」します。
さらに、過去の購入を踏まえた再レコメンドや、PC本体購入後には周辺機器を提案するなど、時系列の文脈を加味した提案も実施。
「言わなくてもわかってくれる」体験は、ユーザーに「自分専属のコンシェルジュ」がいるかのような感覚を与え、ECサイトへの信頼と愛着を育みます。

3.「商品を売る」から「目的を叶える」接客へ
ユーザーが商品を買うのは、「生活を豊かにしたい」、「誰かを喜ばせたい」といった目的達成の手段にすぎません。短期的な売上を追うのではなく、ユーザーの目的達成に寄り添うことこそが、長期的な顧客満足度（LTV）の向上に繋がります。
エージェントは購入目的を深掘りし、真にユーザーの目的を叶える提案を行います。条件に合う商品を並べるだけでなく、ユーザーの購入目的を深く理解し、その目的を叶えるための最適解を「一緒に探す」パートナーとして振る舞います。

実装内容：マルチエージェントシステムの実装

前述のような新しい検索・購入体験を提供するAIアシスタントを目指して、今回は役割に応じて様々なツールを呼び出すマルチエージェントシステムを開発しました。

システム全体像

本システムは、タスクの抽象度が高い順に、以下の3つの役割が階層的に連携します。

• オーケストレーターエージェント
• タスク特化型エージェント
• 機能特化ツール

タスクを細分化し、それぞれを最適なエージェント／ツールへ委譲することで回答品質を高めています。以下、各コンポーネントの詳細を説明します。

1.オーケストレーターエージェント（顧客対応マネージャー）
ユーザーからの入力（テキスト／画像）を受け取り、意図を理解したうえで適切なタスク特化型エージェントへタスクを振り分ける中核的存在です。各エージェントから返ってきた結果を統合し、必要に応じて自身で要約してユーザーへ返答します。単独で回答可能な内容は、他エージェントを呼び出さずに処理します。

• 主な役割
  • 目的理解： ユーザーの言葉の裏にある真の目的を理解します。
  • タスク特化型エージェントへのルーティング： 目的達成に最適な「タスク特化型エージェント」を判断し、タスクを委譲します。
  • 情報統合と要約： 各タスク特化型エージェントからの報告を統合し、ユーザーにとって分かりやすい最終的な回答を生成します。
  • 対話の一貫性維持： セッション全体を管理し、文脈を踏まえた一貫性のある対話を実現します。

2.タスク特化型エージェント
検索、注文処理、FAQ 応答など、特定業務に最適化されたエージェント群です。オーケストレーターの指示を受けて独立に処理し、結果を返却します。今回は、ECサイトの中核業務を担うふたりのエキスパートを用意しました。

• 商品・知識リサーチエキスパート： ユーザーの疑問に答えるため、膨大な情報源を調査するリサーチのプロ。
• 取引実行エキスパート： 商品のカート投入から決済まで、一連のトランザクションをミスなく正確に実行する取引のプロ。

3.機能特化ツール
エージェントは自らデータベースを直接操作したり、外部APIを呼び出したりはしません。その代わりに、標準化されたインターフェースである「ツール」を使用します。これにより、システムの疎結合性を保ち、メンテナンス性と拡張性を高めています。

• リサーチ系ツール：
  • 商品カタログ検索ツール： 在庫や価格などの構造化データを検索。
  • ナレッジ検索ツール： 製品マニュアルやレビューなどの非構造化データを検索。
  • 画像分析ツール： ユーザーから提供された画像を分析。
• 取引系ツール：
  • カート・注文管理ツール： 主催者提供のAPIと連携し、カート操作や決済を実行。

アーキテクチャを支える技術

これらのエージェントを動かすため、以下の技術を選定しました。

• エージェント開発基盤： CrewAI
  • 複数のエージェントを協調動作させるためのフレームワークとして採用。
• 推論エンジン： Azure OpenAI Service （gpt-4o デプロイメント）
  • 全てのエージェントの「頭脳」として、その強力な推論能力とマルチモーダル対応能力を活用。

このアーキテクチャにより、抽象度の高いユーザーの意図理解から、具体的なAPI操作までを一気通貫でカバーし、高品質かつスケーラブルな対話型購買体験の基盤を構築しました。

ブレインパッドのスコア推移と開発の工夫した点・苦労した点

6月19日の発表を終え、ブレインパッドの最終スコアは142点と悔しい結果となりました。 コンセプトとして描いた理想の顧客体験を形にするには技術的に多くの課題があったので、1週間の開発期間で得た学びを振り返ります。

投稿No.	評価スコア	主な開発状況
1	14.0	初回テスト投稿 評価プラットフォームの動作確認
2	70.1	Azure OpenAIのgpt-4oによる基本エージェント実装 最小限の質問応答機能をもつシングルエージェントを実装
3	70.8	コードの微修正に伴うテスト投稿のため、スコアは推移
4	88.7	評価要件の会話コンテキスト実装 問1～4の評価で求めらていた会話履歴コンテキスト欠損を修正 実装が間に合わず空で投稿していた部分を補完
5	124.9	評価用ペルソナ拡張による自動的な点数向上 運営側が評価ペルソナを5体から7体に追加 評価対象拡大により点数が向上
6	113.9	マルチエージェントシステムの実装 エージェント間連携の不具合とRAGツール未完成により性能低下
7	123.9	RAGシステム実装 商品データ、SNS投稿・レビュー、商品資料・画像を活用した検索ツールを実装
8	118.5	オーケストレーターエージェントのプロンプト変更 エージェント間連携強化と出力フォーマットの安定を目指して各エージェントのプロンプト変更 過度に各エージェントの機能を制限する結果となり、性能低下
9	142.0	仮想顧客エージェント対応完成（最終スコア） 問5での仮想顧客との対話機能と購入プロセス追跡機能を実装 販促・アップセル／クロスセルの提案の実装は完了したものの、安定的な能力発揮実現が困難でスコアが伸び悩む

工夫した点

今回私たちは4つの点を意識して開発しました。

1.マルチエージェント実装
システム全体像で示した通り、今回はマルチエージェントシステムを実装しました。オーケストレーターエージェントを正確に機能させ、タスク分担を行うためにプロンプトの修正を繰り返しました。

2.ツール統合アーキテクチャ
Azure AI Searchと連携した動的な商品検索に加えて、ユーザーの質問意図をAIが解釈し、商品カタログ、製品マニュアル、サービスガイドなど複数のデータソースから最適な情報を自動選択するマルチモーダル検索システムを構築しました。テキスト検索と画像検索を組み合わせることで、ユーザーの多様な問い合わせパターンに対応できる柔軟性を実現しました。

3.「おもてなし」の心を持つ対話設計
単なる「エラー処理」ではなく、ユーザーに寄り添う対話設計を重視しました。商品が見つからない場合でも、関連性の高い代替商品を提案したり、検索条件の変更を促したりすることで、対話を継続させユーザーの目的達成をサポートする仕組みを実装しました。この「おもてなし」のアプローチにより、ユーザーとの自然で継続的な対話を維持することができました。

4.API連携による確実な状態管理
フレームワークの標準機能では難しい部分を補うため、カートAPIと直接連携する独自機能を開発しました。これにより、カートの中身や注文情報といった重要なデータを常に正確に把握し、評価に反映させることが可能になりました。

苦労した点

しかし、実装では多くの課題に直面しました。

多様すぎるデータソース
まず、直面したのは検索対象データの圧倒的な多様性です。今回与えられたデータは下記のように多岐に渡るものでした：

区分	種類	形式
構造化データ	商品カテゴリ・値段 在庫状況 購買履歴	テーブル
半構造化データ	X （旧Twitter）の投稿 商品レビュー 過去会話履歴	json
非構造化データ	商品レビュー 製品マニュアル 商品画像	pdf docx, xlsx, pptx png, jpg

これだけ特性の異なるデータを、単一の検索インデックスで柔軟に扱うのは困難と考え、データの種類（商品・マニュアル・レビュー…）や形式（テキスト・画像）に応じてインデックスを複数作成し、クエリに応じて最適なインデックスを参照させる戦略を取りました。しかし、そのパターンが膨大であり、データの特性に応じた個別のチューニングに十分に時間を割くことができませんでした。

エージェントへのデータ接続
インデックスを用意しても、AIエージェントは自動でそれを参照してくれません。「いつ、どのインデックスに、どのようなクエリを投げるべきか」というインデックス・ルーティングのロジックを精緻に定義する必要があります。
本来であれば、このロジックは「高価なプレゼントを探している顧客には、レビュー評価の高い商品インデックスを優先的に参照させる」といった販売戦略と密に連携させるべきです。しかし、実際にはエージェントが見かけ上は正常に動作していても、意図したデータソースを参照しなかったり、微妙に的外れな判断を下したりする予期しない動作パターンに苦労し、ビジネス観点を実装に反映させる前にタイムアップとなってしまいました。

曖昧な日本語に対する検索精度向上
データの特性に依存しない包括的な精度向上策として、私たちは、キーワード検索とベクトル検索を組み合わせたセマンティックハイブリッド検索を実装しました。キーワードの一致を捉える従来のテキスト検索と、文脈や意図を理解するベクトル検索を組み合わせ、さらに、検索結果をLLMで並び替えるセマンティックリランカーを導入し、ユーザーの検索意図をより深く汲み取る構成を目指しました。
この高度な仕組みは、具体的な商品名や機能に関する質問には有効でした。しかし、「ともだちが持ってなさそうなのがいい」や「おはようさん」といった、極めて曖昧で、検索意図そのものが希薄な入力に対しては、期待した効果を発揮できませんでした。最先端の検索技術であっても、ユーザーの心を完全に読み解くことの難しさを痛感した瞬間です。

マルチエージェント設計における複雑なフロー管理
問5では、RAG検索結果、カート操作、ユーザー情報管理などの複数のツールをまたぐ一連のタスクを、構造化されたデータに正確に連携し実行させる必要があり、堅牢なデータフローの設計に苦労しました。ここの設計が、システム全体の安定性を左右する重要な課題となりました。

フレームワーク制約下の設計の難しさ
エージェント開発にはCrewAIフレームワークを活用しましたが、ハッカソンの提供するシステムの制約を満たしつつ、CrewAIフレームワークを活用した柔軟なマルチエージェントシステムを構築する必要がありました。フレームワークの標準機能だけでは実現困難な部分を補うため、独自のAPI連携機能を開発するなど、フレームワークから外れた概念を含む全体システムの設計を必要としました。

もし時間があれば試したかったこと：未来のアーキテクチャへの構想

今回のハッカソン期間では実装できませんでしたが、今回の実装をさらに進化し理想のコンセプトに近づけるため、以下の4つの観点で改善の可能性を見出しています。

1.RAG: クエリ拡張

• HyDE（Hypothetical Document Embeddings）（Gao et al. （2022））
  一般的なRAGは、質問文を直接インデックス化してリファレンスから類似文章を取得するアーキテクチャです。しかし、質問文と回答となるリファレンスでは使用する語彙や表現が異なることが多く、期待する文章を取得できないことがあります。
  HyDE では、質問に対してLLMの内部知識から仮想ドキュメント（仮想的な回答）を生成し、その回答と類似する文章をリファレンスから取得しています。これにより、たとえ質問文と回答文で表現のギャップが生じても精度を落とさず回答できることが期待できます。
• マルチクエリ検索（MultiQueryRetriever）
  先ほどのHyDEと課題感は似ていますが、質問文は人によって文章が微妙に異なっており、文章表現によってはリファレンスから適切に文章を検索できない可能性があります。
  マルチクエリ検索では、元の質問文から複数視点でクエリを自動生成し、それぞれのクエリで検索を実行します。これにより、元のひとつの質問文からは取得できなかったリファレンスも含め、多角的かつ網羅的な回答文章が生成できるようになることが期待できます。

2.RAG: チャンキング ／ インデックス化

• Meta-Chunking（Zhao et al. （2024））
  リファレンスのインデックス時には「チャンク」と呼ばれる単位に文章を分割して、チャンク単位でインデックス化を行います。しかし、トークン、句点、改行ベース等のチャンキングは、文章構造やコンテキストを切断してしまい、検索精度低下を招くと言われています。
  Meta-Chunkingでは、文章の予測困難性などの観点からチャンキングする場所を動的に設定します。これにより、リファレンスのコンテキストを崩さずインデックス化でき、結果的にRAGの回答精度向上が期待できます。
• Markdown形式でのインデックス化
  リファレンス文章のテキスト部分のみをインデックス化すると、文章内の構造情報がなくってしまい、検索精度低下を招くと言われています。
  今回は、HtmlRAG（Tan et al. （2024））の考え方が応用できたと思います。HtmlRAGはHTMLタグを補助情報として文章構造を崩さずにRAGを行う方法です。今回は、HTMLではありませんが、さまざまな文章データが準備されていたため、テキストのみではなくMarkdown形式のように構造を反映した状態でインデックスを作成することで、RAGの回答精度向上が期待できます。

3.エージェントワークフロー

• 今回はオーケストレーターエージェントひとつに対して、商品や顧客情報を検索するエージェントと決済処理を行うエージェントふたつが接続する合計3つのマルチエージェント構造でした。しかし、基本的な役割分担のみの実装に留まり、詳細なエージェントワークフローに関する議論ができませんでした。
  この課題に対しては、専門エージェントの追加、リフレクション機構（Renze and Guven （2024））などエージェントワークフローを再考することで、エージェント単体の性能向上とそれに伴うマルチエージェント全体の性能向上や安定性向上が期待できます。

4.Azureのベストプラクティス活用
機能実装を優先するあまり、Azureの強力な機能を十分に活用しきれなかった点は大きな反省点です。

• インデクサーの積極的活用
  今回のコンペでは、構造化から非構造化まで多様な形式のデータが与えられたため、その前処理に多くの時間を費やしてしまいました。Azure AI Searchのインデクサーは、Azure上の様々なデータソースからの抽出、ファイル形式ごとの解析、インデックスへのマッピングといった一連の処理を自動化します。 これ戦略的に活用すれば、RAGのデータ接続にかかる作業を大幅に効率化し、注力すべき精度改善に時間を多く使えたはずです。 さらに、実運用上の観点からも、データの継続的な更新に対応可能なインデクサーの活用を前提とした設計にすべきでした。
• Well-Architected Frameworkを指針としたアーキテクチャ設計
  短期開発だからこそ、「信頼性、コスト、パフォーマンス、セキュリティ」といったベストプラクティスを定めたWell-Architected Frameworkを初期段階から指針とすべきでした。これにより、アーキテクチャ全体の質を網羅的かつ効率的に高められたと分析しています。

おわりに

私たちは、目指したカスタマーストーリーでは、AIアシスタントが単なる高機能なアシスタントではなく、すべての顧客の「専属の担当営業」となる究極のパーソナル体験を提供することを目指しています。

「スーツが欲しい」顧客に対し、従来の検索エンジンであれば「スーツ」と検索し、その結果を提示するだけで終わっていたところを、我々の目指すAIアシスタントは、「何色のスーツが欲しいのか？」「背丈とウエストはどのくらいか？」「どうしてスーツが欲しいのか？」ということを自律的に質問します。質問に対して顧客から「黒いスーツが欲しい」「身長は170cmで、ウエストは76cm」「就活で必要になったから欲しい」という回答が得られれば、顧客が本当に欲しいものは ”検索上位に提示されるありふれたスーツ” ではなく ”清潔感のある細見の黒いリクルートスーツ” であるとAIアシスタントは判断して提示します。顧客が就活生と分かれば、ネクタイやオンライン面接で利用するWebカメラも必要かもしれないと推測し、顧客の気付かない潜在的需要もAIアシスタントは自律的に推測して提案します。顧客の買い忘れ防止と店舗のクロスセルが両立した接客になります。

このような購入体験を繰り返すことで、購買履歴だけでなく、顧客の嗜好やショッピング思想が蓄積されます。顧客が数年後に再びスーツを購入しようとした際、AIアシスタントは顧客が既に持っているネクタイに良く似合う、顧客好みのスーツを提案できます。さらに何も言われずとも、値段やポイントの付与対象かどうかといった、顧客が購入時に気にしていることを織り交ぜた接客が可能です。顧客からすれば「専属の担当営業」による、最高の購買体験となります。

今回のハッカソンでは構築しきれなかった自律的な質問機能の実装や精度向上施策を再検討することで、この理想の次世代の顧客体験提案アシスタントの構築は可能と考えています。

ブレインパッドには今回ハッカソンに参加した若手データサイエンティスト以外にも、小売業界のスペシャリストや生成AIのスペシャリストが多数在籍します。社内にも今回の学びを持ち帰り、多様な視点を取り入れながら、さらなる精度向上に励みたいと思います。

【参考】
データ活用のパイオニアとして最前線を走り続けてきたブレインパッドが“データのプロ”のノウハウを集約した、小売業向けソリューション
停滞するDXを打開する“AIエージェント”――経営改革の新たな推進力

このような貴重な機会を頂き、最新技術に触れる貴重な機会をくださった日本マイクロソフト様、角川アスキー総合研究所様、そして運営を支えてくださった皆様、誠にありがとうございました。