はじめに

記事を開いていただきありがとうございます。サーバサイドエンジニアのオーです。

今回は「SlackとAWSを利用した社内AIチャットボット」をテーマに「チャットボットの実用例」と「バックエンド構成例」を簡単にご紹介させていただきます。

LDIでは、業務生産性の向上の一環としてAIの導入活動を積極的に進めている段階であり、その一環として「ローソンアプリ領域のAIチャットボットの導入」を進めております。この度、私もバックエンドAPI構築パートとして加わり、この機会を借りて発信させていただきます。

SlackとAIチャットボットの連携やAWSを活用したチャットボットに興味がある方の一助になれば幸いです。

チャットボットの実用例を紹介

①新しい会話を始める

以下は、SlackからAIチャットボットへメッセージを送る動画(gif)です。 Slackを通して「ローソンアプリのアプリ予約はどういったことができるサービスですか？」という質問をAIチャットボットに送信しています。

AIチャットボットにメンションしてメッセージを送ると、スレッドを通して回答をもらうようになります
最初は会話IDが届きます。「問い合わせ・ログ追跡」や「会話履歴DBのキー」となどに使われます
続いて送信メッセージにリアクションがつきます
AWS Bedrock処理まで完了すると、スレッドにAIからの回答が届きます

※ リアクションの意味

リアクション	定義の説明
	Slackから送信されたイベントを受信
	AI回答処理要求をAWS SQSの待機列に送信
	AI回答処理を開始
	AI回答処理を完了、回答結果をSlackへ送信

②引き続き会話を行う

以下は、Slackスレッドを通して引き続き会話を行う動画(gif)です。先ほどの会話スレッドから「どういった商品を予約できますか？」という質問をAIチャットボットに送信しています。

会話のスレッドから、AIチャットボットにメンションしてメッセージを送った後、同じスレッドを通して回答が届きます
AIチャットボットは、バックエンド側に記憶されている以前の会話を参照し会話を繋いでいきます

③Slack Workflowを利用し会話を始める (カスタムオプション指定)

以下は、SlackのWorkflowを利用して、AIチャットボットに対しカスタムなオプションを指定して会話を行う動画(gif)です。 Workflowを起動し、「iOS, Android」と「コーデイング規約」という条件を指定の上、「どういうアーキテクチャを採用してますか？」という質問と共にをAIチャットボットに送信しています。

目的に合わせて知識検索の範囲を具体的に指示し、より正確な回答の誘導を図るための機能です
まだ実験段階の機能であり、他のオプションの追加や利便性改善を検討中です

システム構成・処理概要の紹介

システム構成図

以下は、システム構成と処理概要を表した図です。
※ 簡略化のため一部機能や構成を省略しています（会話ID送信、リアクション送信、RAG構成等）

仕様についての補足

②イベント受信

Slackのイベントを受信する方法として、「WebSocket受信」方式を採択しています
他の連携方法としては「A. HTTPコールバック受信」「B. SlackとAWS Chatbot+Bedrock Agent連動」の連携方法もありますが、以下の理由で今の方法を採択しています
- 「A」の場合は、コールバック受信エンドポイントを用意する必要があり、Private性確保が難しい
- 「B」の場合は、リクエスト段階でのAWS BedrockのRAG検索条件・プロンプト・パラメータなど微細なコントロールが難しい

④リクエスト受信・SQSへ送信・受理応答、⑤非同期処理開始

API GatewayとLambdaを経由してSQS送信を行っている部分と、チャット回答処理を非同期で行う部分は、「Slack以外の連携時の拡張性確保」の目的でおいています

⑥会話履歴照会

SlackのスレッドID(tsまたはthread_ts)と紐付けて照会します。履歴がある場合は⑦の回答生成時に参照されます

⑦知識検索・回答生成

知識検索においてKnowledgeBaseとOpenSearchが参照されます。EmbeddingはS3と連動し行われます

今回の活動で改善した課題

今回AIチャットボットのSlack連携により、主に以下の３つの課題の解決を進めました。

①「チャットボットツール利用」のハードルを改善

課題
- 別のプログラムやWeb画面を使ってAIチャットボットを利用する手段しかなく、多くの人が利用するにはハードルが高い状態となっている
解決
- 「Slackで人に質問するような体験」を提供し、使い慣れた社内ツールから直接AIチャットボットを利用できるようにして解決

②「会話セッション」機能の改善

課題
- ②-1) 会話セッションの保存機能がなく、クライアント終了や新しいセッション開始時に前のセッションが消えてしまうため、再び参照や質問を行うことができない
- ②-2) 会話セッションがサーバ上に保存されていないため、2回目以降の質問では前の質問と回答の文脈を踏まえるためには、毎回すべての会話を送信する必要があり、リクエストペイロードとして非効率的だった
解決
- Slackのスレッド活用により、会話セッションの保存と再参照を可能にすることで②-1の課題を解決
- 会話履歴のDB保存により、2回目以降の質問からはDBの履歴を参照するようにすることで②-2の課題を解決

③「AI処理時間の遅延により発生する問題」を改善

課題
- AI質問・回答は時間がかかる演算であり、同期処理ではAPI GatewayやLambdaのタイムアウト引き上げなどの特殊な対応が必要だった
- 長い応答時間により、Slackなど他プラットフォームとの連携に制約が生じ、プラットフォーム拡張の障壁となっていた
解決
- AWS SQSを活用した非同期処理構成に移行したことにより解決

今後の活動について

まだ検討中で実施が確実ではない内容も多いですが、以下の改善やサービス拡大をしたいと考えています。

A. 機能改善の観点

①AI推論精度の最適化
- 主にAWS Bedrockと関わる部分で、タスクフォースで活動を進めていただいてます
- 引き続き、データ収集・分類・定型化・学習・検証・パラメータ調整のサイクルを実施し、最適化を進めています。私も今後、本格的に加わっていければと思います
②Slackを利用した知識検索の条件やプロンプト・パラメータ調整機能
- 目的に合わせて知識検索の範囲を具体的に指示し、より正確な回答の誘導ができるように検討しています
- すでに一部実装が行われてますが、知識検索時の分類条件の追加(version)やLLMプロンプトの調整も行えるよう検討中です
③AIチャットボットの多様化
- ②の条件をプリセット化したSlack Botやショートカットを用意し、高い利便性を担保しつつ、高度な条件設定のメリットを得られるように機能改善を検討しています
④マルチモーダル対応
- まだ構想段階ですが、ドキュメントや画像を含めたマルチモーダル処理について、ユースケースとその価値を検討しながら実現方法を考えていきたいと思います