はじめに
最近、生成AIを活用したシステム開発に興味があり、実際の企業レベルでどのような構成でRAGチャットボットが作られているのか調べていました。
先日、AWSの公式ブログで紹介されていた「Hardening the RAG chatbot architecture powered by Amazon Bedrock」という記事を見つけて、とても参考になったので自分の学習のためにアーキテクチャを詳しく分析してみました。
単純にChatGPTやClaude APIを呼ぶだけではない、本格的な企業向けRAGシステムの構成を理解できたので、備忘録として共有します。
参考記事
システム概要
目的
- ユーザーからの質問や入力に対して、生成AI（Claude 3）を用いて自然な応答を返す
- 社内ドキュメントや過去の履歴を基にした回答（＝検索拡張生成：RAG）を可能にする
実現されている機能
1. ユーザーインタフェース（UI）からの簡単な入力
- Streamlitなどを使ったWeb UIで、ユーザーが質問を入力できる
2. 自然な対話型応答（LLM）
- Amazon Bedrock上のClaude 3を使って、高精度な応答を生成
3. 社内データを元にした回答（RAG：検索拡張生成）
- 過去のドキュメントやレポートをOpenSearchで検索
- Titan Embeddingsを使って意味ベースで類似情報を検索し、生成AIの回答に利用
4. データの永続化と管理
- DynamoDBにユーザーのチャット履歴やログを保存
- S3に元データを保持（埋め込み処理などの対象）
5. スケーラブルでメンテナンスしやすい構成
- FargateやLambdaなどのサーバーレス技術でインフラの運用負荷を軽減
- API Gatewayで疎結合な設計
想定ユースケース
- 社内ヘルプデスク／FAQ自動応答システム
- 顧客サポート用チャットボット
- ナレッジ検索支援
- レポート内容の要約・検索付き生成支援
AWSコンポーネント
フロントエンド・API層
| サービス | 役割 |
|---|---|
| Amazon ECS Fargate | コンテナベースのアプリケーション（例：Streamlit UI）の実行環境 |
| API Gateway | クライアント（ユーザー）とバックエンド（Lambda）間のリクエスト仲介 |
コンピュート・データ層
| サービス | 役割 |
|---|---|
| AWS Lambda | サーバーレスでビジネスロジックを実行。外部AIやデータベース、検索エンジンと連携 |
| Amazon DynamoDB | チャット履歴やユーザーデータなどを保存するNoSQLデータベース |
| Amazon S3 | ドキュメント、テキスト、ファイルなどの保存先。埋め込みベクトルの元データにも使用可能 |
AI・検索機能
| サービス | 役割 |
|---|---|
| Amazon Bedrock | Claude 3やTitanなどのファウンデーションモデルをAPI経由で提供 |
| Anthropic Claude 3（Bedrock内） | 自然言語でユーザーの質問に応答する生成AIモデル |
| Amazon OpenSearch Service | ベクトル検索や全文検索により、関連情報の高速検索を提供 |
| Titan Embeddings（Bedrock内） | テキストをベクトルに変換し、検索や分類タスクに利用 |
アーキテクチャの詳細分析
このシステムの興味深い点は、2つの明確に分離されたフェーズで構成されていることです。
フェーズ1：文章格納（事前準備・バッチ処理）
RAGで使用する知識ベースを構築する段階です。
処理手順
- 文書アップロード: 管理者またはバッチ処理などにより、PDF・テキスト・Word等の文書が Amazon S3 にアップロードされる
- 文書読み取り: AWS Lambda または別のETLパイプラインが S3 上の文書を読み取る
- ベクトル化処理: 文書の中身がテキスト抽出され、Titan Embeddings を用いてベクトル化される（Bedrock API）
- インデックス登録: 得られたベクトルは、Amazon OpenSearch に登録（インデックス化）される
- メタ情報保存: メタ情報（文書タイトル、カテゴリ、作成日など）は DynamoDB に格納される
フェーズ2：質問と回答（リアルタイム処理）
ユーザーが実際にチャットボットを使うときの流れです。検索拡張生成（RAG）を用いた回答生成処理になります。
処理手順
- 質問入力: ユーザーがStreamlit UI上で質問を入力
- リクエスト送信: 入力は API Gateway 経由で AWS Lambda に送信
- 履歴取得: Lambda が必要に応じて DynamoDB から過去の履歴を取得
- 質問のベクトル化: ユーザーの質問を Titan Embeddings でベクトル化
- 類似検索: ベクトルクエリを使って OpenSearch に類似情報を問い合わせ
- 文書取得: 類似ドキュメント（社内文書）を取得
- AI応答生成: 質問＋取得ドキュメントを Claude 3（Bedrock）に送信
- 回答生成: Claude が自然言語で回答を生成
- 結果返却: Lambda → API Gateway → UI に回答を返却
- 履歴保存: 同時に会話履歴を DynamoDB に保存
2つのフェーズに分離する意味と利点
| フェーズ | 役割 | 主なコンポーネント | 実行タイミング |
|---|---|---|---|
| 文章格納 | 知識ベースの構築 | S3, Lambda, Titan, OpenSearch, DynamoDB | 事前準備・バッチ処理 |
| 質問応答 | ユーザーとの対話と回答生成 | ECS Fargate, API Gateway, Lambda, Bedrock, OpenSearch | リアルタイム処理 |
この分離により、以下の利点があります：
- パフォーマンス: 大量の文書処理は事前に行い、ユーザーからの質問には高速に応答
- スケーラビリティ: 知識ベース構築と質問応答を独立してスケール可能
- 運用性: それぞれ異なる運用要件（バッチ vs リアルタイム）に最適化
よくある疑問点の整理
アーキテクチャを見ていて疑問に思った点について、元記事から回答を整理しました。
Q1: なぜ Web UI を ECS Fargate でホストしているのか？ Lambda だけではダメなのか？
A1: ECS Fargate は常時起動が可能なため、インタラクティブな UI を持つ Streamlit アプリのような状態を維持する必要があるサービスに適しています。Lambda はイベント駆動の一時的な関数実行に適しており、長時間実行やセッション管理が必要な UI には向いていません。
Q2: ユーザーの問い合わせ内容はどこに保存されているのか？履歴は残るのか？
A2: ユーザーのインプットや対話履歴は AWS Lambda によって Amazon DynamoDB に保存されます。これにより、後続の応答生成で過去の会話を文脈として活用できるほか、ユーザー体験のパーソナライズや分析にも役立ちます。
Q3: なぜ Titan Embeddings と OpenSearch を使っているのか？Claude にそのまま聞くだけではだめ？
A3: Claude などの生成AIは強力ですが、社内固有の文書やFAQなどを即座に理解して活用するわけではありません。Titan Embeddings を用いてユーザーのクエリをベクトル化し、OpenSearch で社内ドキュメントから意味的に近いものを検索し、それを Claude にコンテキストとして渡すことで、社内知識に基づいた回答（RAG: 検索拡張生成） が可能になります。
Q4: Claude 以外のモデルは使えないのか？
A4: この構成では Amazon Bedrock を使っているため、Claude 3 に限らず Amazon Bedrock が対応している他のモデル（Jurassic, Titan Text, Mistral, Command-Rなど） にも切り替えや併用が可能です。用途に応じてベストなモデルを選択できる柔軟性があります。
Q5: セキュリティはどうなっている？外部にデータが漏れる心配は？
A5: すべてのコンポーネント（ECS, API Gateway, Lambda など）は VPC（仮想プライベートクラウド）内で構成 されており、外部との通信には制限が設けられています。また、Amazon Bedrock や S3、DynamoDB なども IAM（アクセス制御）によってアクセスが管理されており、機密性が高い構成です。
Q6: OpenSearch のインデックスはどうやって作られているの？
A6: Amazon S3 に格納された文書データが定期的またはイベントベースで Lambda によって処理され、Titan Embeddings によってベクトル化されます。そのベクトルデータが OpenSearch にインデックスとして登録され、後続の検索処理で利用されます。
学習したポイント
1. 2つのフェーズに分離した設計の重要性
最初は単純な質問応答システムだと思っていましたが、「事前の知識ベース構築」と「リアルタイムの質問応答」が明確に分離されていることで、パフォーマンスとスケーラビリティの両方を実現している設計の巧みさを理解できました。
2. RAGシステムの具体的な実装方法
「検索拡張生成」という概念は知っていましたが、実際にTitan Embeddingsでベクトル化→OpenSearchで検索→Claude 3に渡すという具体的な流れを理解できました。
3. 企業レベルのセキュリティ考慮事項
VPCやIAMなど、個人開発では意識しないセキュリティ要素が重要であることを再認識しました。
4. AWSサービス間の連携の複雑さ
8つのAWSサービスが有機的に連携してひとつのシステムを構成している点が印象的でした。
今後の学習計画
- ハンズオン実装: 小規模なRAGシステムを実際に構築してみる
- ベクトル検索の深掘り: Titan EmbeddingsとOpenSearchの詳細な使い方を学習
- セキュリティ対策: VPCやIAMの設定方法を実践的に学習
- 他のLLMとの比較: Claude 3以外のモデルでの実装も試してみる
まとめ
今回、AWSの公式ブログをベースにRAGチャットボットのアーキテクチャを詳しく分析してみました。
単純にAPIを叩くだけではない、本格的な企業向けシステムの複雑さと、それを実現するための設計思想を理解できたのが大きな収穫でした。
特に、2つのフェーズに分離した設計パターンは他のシステム開発でも応用できそうなので、今後の設計時に参考にしたいと思います。
RAGシステムの構築を検討している方の参考になれば幸いです。