今回はECサイト用のバーチャルアシスタント パワーアップしたお題に8社が挑む！
RAG、マルチモーダル、AIエージェント AI Challenge Dayで生成AIの高みを目指せ
アーキテクチャとカスタマーストーリーのバランスが最高だったシステムサポート
7社目はシステムサポートの古城道崇氏。2月のColombus DAYで事例創出件数1位となった企業向けAIチャットボット「Smart Generative Chat」を開発している4名で参加している。「工数使うからには優勝してこい！」という上司のプレッシャーに負けずにがんばってきたという。
短時間に説明を詰め込んだシステムサポートの古城道崇氏
その甲斐あってか、評価スクリプトは22.725という高得点をマークした。「火曜日～水曜日を評価上げるところにあてることができたので、かなりいい数字になったと思います」と古城氏は振り返る。
アーキテクチャは「ただのポンチ絵にならない、根拠のあるアーキテクチャ」（古城氏）を実現すべく、「信頼性」「セキュリティ」「コスト」「オペレーショナルエクセレンス」「パフォーマンス管理」の5ポイントを満たすためのマイクロソフトのWell-Architected Frameworkを採用した。
まず信頼性を担保すべく、AI Searchへのデータ取り込み（インデックス、インデクサー、スキルセット）はJSONで管理できるようにしたほか、アプリは再利用が容易なコンテナを採用。Cosmos DBやPostreSQL、Blobストレージなどのデータソースはリージョン冗長を行なった。セキュリティに関しては、OSやミドルウェアの管理はマイクロソフトのPaaSを用い、開発コードもPromptFlowを含めて、脆弱性対策が可能なGitで管理した。データソースに関しても、Private Linkを用いて、パブリックアクセスができないよう配慮されている。
コストに関しては、アラートを設定しつつ、未実装ながらトークン数をベースにしたリクエスト制限を検討。オペレーショナルエクセレンスの観点ではではGitHub ActionとACRを連携させたCI/CDの採用。インデクサーを定期実行させることで、データソースとAI Searchの自動同期を実現している。ただ、パフォーマンスに関しては、未知のサービスもあったため、具体的な定義は行なっていないという。
RAGに関しては、やはり多様なバリエーション、長大なドキュメント、感情分析の情報の欠如などがデータソース側の課題。Cosmos DBのデータ型が揃っていない点も、データ登録やインデックス作成のハードルだった。また、回答生成の挙動としても、インデックス選択時のプロンプト、適切なFunctionの選択、そして取得時にコンテキストを取り過ぎる点も課題だったという。
RAGの構築で工夫した点と感想
こうした中、工夫したのは質問が来た段階で、AIによるFunctionの選択と実行を複数回行なうという点。プロンプトエンジニアリングにより、選択肢を減らして、適切なFunctionを呼び出しつつ、同じFunctionを呼び出さないよう制御を施した。また、選択肢としてあえてGPT4o-miniを活用したのもポイント。「GPT4oは賢すぎ、気が利き過ぎちゃうんですよね」（古城氏）とのことで、コストメリットも考慮して、GPT4o-miniを利用した。
データソースの取得に関して、ユーザーの問い合わせからSQLを自律的に組み立てるText-to-SQLを実装した。問題準拠の恣意的なプロンプトや関数を実装することなく、自由に回答を返せるようにした。Cosmos DB上に配置されたSNSデータに関しても、全量取得ではなく、サンプリングをかけ、コンテキストとして渡すようにした。
その他、インデクサーによる取り込み時にデータの種類ごとにスキルセットを作成したり、SKUをアップグレードしてBlobインデクサーが処理できるテキスト量を向上。画像データのEmbeddingモデルもあえて使用せず、取り込み前にGPT-4oで説明文を生成し、メタデータとして付与する方法を採用し、検索結果を安定させることが可能になった。
続いて初日に行なったというカスタマーストーリーの説明。まずECサイトに関しては、従来は機械的なリコメンドが多かったが、今後のECサイトは「店員さんが近くにいるような安心感を提供できること」が必要だと考えた。「たとえば、お客さまの不安や複雑な問いに対しても、AIアシスタントがいれば、家にいても安心して買い物ができる。こういう安心感を提供したかった」（古城氏）。
一方で、従来型のサイトに性格にあっているという顧客もいる。「この双方の共存を目指さなければいけない」というのが、カスタマーストーリーにおける議論の結論。自ら問題を解決し、1人で黙々と買い物するタイプの顧客に加え、新しいジャンルの買い物や複雑な要望に対して店員に助言をもらいたいという新しいタイプの顧客にも使ってもらえるよう、ユーザーインターフェイスも工夫した。具体的には、ECサイトの下部にチャットマークを入れておき、押すと起動し、店員がいるようなイメージで、チャットに答えてくれる。Reactコンポーネントとして作成しているので、既存システムへの取り込みも容易だという。
1つのサイトで2つのタイプの顧客をサポート
続く部門2のECサイトの分析側においては、AIチャットボットを社内システムのインターフェイスとして横断的に接続できるようにした。現状はAzureリソースに限られているが、今後は社内のオンプレサーバーや他のCRM製品などとのAPI連携も視野に入れていく。「こいつに聞けば、すべてわかるというのは目指していくべき姿」と語る。
今後の課題としては、手組みで実装していたFunctionの呼び出しだ。Prompt Flowを組んだ後にFunction Callingの機能に気づいたため、今後はこちらを活用していきたいという。また、Cosmos DBへのクエリの自動生成やデータ処理までAPI化したCopilot連携も今後の課題。「Teamsアプリとしてデプロイすれば、Copilot for Microsoft 365からも利用できる」とのことで、試していきたいという。古城氏は、「意識が飛びそうなくらいしんどかったが、今回は本当に貴重な経験をさせていただいた。改めて関係者の方々に感謝したいと思います」という謝辞で締めた。
日本マイクロソフトの花ケ﨑氏は、「スコアが高くて素晴らしかった。ここまでやられちゃったかと（笑）。めちゃくちゃ疲れさせてしまって申し訳ないです。エンタープライズで運用やセキュリティを満たすべく、マイクロソフトが出しているWell-Architected Frameworkを使って構築してくれたのが、僕としてはとてもうれしかった。モデルの特性に応じてminiを使いこなす点も、非常によかった。個人的にはText-to-SQLがうまくいったか気になったのですが……」と質問。古城氏も、「実は昨日の夜に大きなバグを見つけて、FIXしたのですが、それ以降はほぼとれないことはなくなった」と応じた。
参考プレゼンで模範アーキテクチャを見せつけたゼンアーキテクツ
8社目のゼンアーキテクツは、課題に向き合う時間がなかったということで、参考プレゼンを行なった。代表の三宅和之氏は、「参考に出ておりますゼンアーキテクツの三宅と申します。マイクロソフトパートナーで、AIのスペシャリスト認定を受けているので、取り組むからには模範となるアーキテクチャを作らなければいけないということで、そこに特化させてやらせていただきました」とコメント。早くも余裕が感じられる。
終始余裕を漂わせていたゼンアーキテクツ 代表の三宅和之氏
今回参加したのはAI、Azure、フロントエンド、モバイルアプリなど同社のコアメンバー5人。「ただ、全員が集まれたのは1日しかなく、できる範囲でやりましょう」ということで競技には参加しないことにした。「点数はすべてではないし、本気出してやったわけではないので」という結果の評価スクリプトは22.555点。「これくらいで勘弁してください」というコメントには会場から笑いも起きる。
同社は社名の通り、アーキテクチャの設計が本業。しかも、ハッカソン形式で顧客の難題に対して、その場で答えていくのがゼンアーキテクツのスタイルだ。今回もお客さまの課題に向き合う形式で1日時間をとって、アーキテクチャの設計からスタート。「10時から始めて12時半くらいですかね。この形になっています。課題は複雑でしたが、わりとオーソドックスなアーキテクチャパターンになった」（三宅氏）とのこと。結果的に花ケ﨑氏が提示したアーキテクチャと似通っており、「今求められているアーキテクチャなのかなと」と三宅氏。
ナレッジストアにはCosmos DBを採用
アーキテクチャで他社と異なるのは、ナレッジストアのベクター検索にAI Searchではなく、Buildで発表されたCosmos DBのNoSQL APIを用いている点だ。今回はECサイトということで、信頼性や拡張性を重視し、Well-Architected Frameworkを意識して作られている。「AI Searchを使うと、SLAは絶対に99.9％以上は行かない。ここは現場でも問題になるので、Cosmos DBを使ってSLA99.99％以上いけるようにした」と三宅氏は語る。
また、マルチエージェントのためにAzure Functions（Durable Functions）で実装している。三宅氏は、「マルチエージェントって、本来的にはエージェントやマネージャーが自律的に会話して回答を返すという定義になっていると思うんですけど、今回本来のマルチエージェントにはならないけど、それぞれの質問に特化したエージェントを選んだり、前処理など複数のエージェントを利用している」と語る。
たとえば前処理ではユーザーの質問で出てきた「最新の」を拾い上げ、マスターから最新の製品を検索し、質問をリライトする。最後のマネージャーエージェントは、複数のエージェントの回答を選択したり、マージすることで、最終的な回答を行なう。AIエージェントがチームを組んで最適解を返すわけだ。三宅氏は、「これって基本はワークフローなんですよね。その点、Azure Durable Functionsは5年以上前からワークフローの実装をサポートしていて、いい意味で枯れている技術。出たばかりの温まってない技術を使うのであれば、こちらの方がよいと現時点では判断した」と語る。
時間がなかったため、アーキテクチャ設計終了後は、それぞれをタスクに落として、各自に勝手に進めるというスタイルで構築を行なった。各エージェントも独立しているため、並行開発も可能で、「気がつけば8つできていた」（三宅氏）とのことだ。
マルチエージェント構成で並列にLLMを動かす
一方で、課題2の方はアプローチを変えた。データを集約したCosmos DB for NoSQLに集約し、Text-To-SQLではなく、Text-To-NoSQLのアプローチにより、LLMでクエリ生成を行なった。「ここは開発効率を重視。プロンプトが鍵になる。Cosmos DBからよりよいデータを得るためにクエリ生成が一番ポイントとなる」と三宅氏。
最適なプロンプトを作るためには、学習とプロンプトの書き換えを継続的に行なう必要があるため、ホットリロードでプロンプト編集が可能な「Prompty」を利用している。具体的にはPromptyのプロンプトをコードから読み込めるprompt.coreを用いて、アプリケーションに動的にプロンプトをロード。イベント前日に発表されたばかりの.NET9でしか利用できないライブラリをさっそく使っていると言うことで、そのスピード感には驚かされる。
ここまで話しておきながら、三宅氏は「こうやって苦労して作るのもいいんですけど、本来的にはMicrosoft Fabricを使いたかった」と語る。検討したのはMicrosoft FabricミラーリングでCosmos DBのデータをOneLakeに集約し、Copilot for FabricでLLMによる分析処理を実行する方法だ。ただ、Copilot for Fabricを動かすためには、今回利用可能なサブスクリプションでは難しく、切り替えたとしてもコストがかかるということで、今回はPromptyを使う方法になった。UIもReactで作成し、実際に試せると話したところで、プレゼン時間の10分は終了。模範演技とも言えるゼンアーキテクチャのセッションは終了した。
日本マイクロソフト 内藤稔氏は、「いろいろ言いたいことはあるんですけど（笑）、聴衆のみなさまにお伝えすると、ゼンアーキテクトさんは稼働日1日しかないけど、やってみたいと言ってくれたし、私たちもぜひ話してほしいと無理言って出てもらいました。で、本気じゃないかもしれないけど、思ったより本気で来ましたね（笑）。三宅さんのCosmos DBとDurable Functionsの話を久しぶりに聞いてニヤニヤしたし、発表されたばかりの.NET9もしれっと使っている。盛りだくさん過ぎて、1時間くらい聞きたい素晴らしい発表でした」とコメントした。
週刊アスキーの最新情報を購読しよう
