はじめに

前回の記事では、AWS Summit Japan 2025 で得た学びをきっかけに、生成AIとRAG（検索拡張生成）の重要性に気づき、AWS上でチャットボットを構築することを決めた経緯をご紹介しました。
今回はその続編として、実際にどのような構成でRAGチャットボットを実現するかについて解説していきます。

システムアーキテクチャ全体図

まずは、構築したRAGチャットボットの全体構成を以下に示します。

各サービスの選定理由と役割

Amazon Bedrock：生成AIのハブ

役割：

  • テキストをベクトルに変換（Titan Embeddingsなど）
  • ユーザーの質問と文脈に基づいて自然言語で回答を生成（Claude 3など）

選定理由：

  • ClaudeやTitanなど複数のLLMを統一APIで利用可能
  • モデルホスティング不要
  • 商用利用・セキュリティ面で企業向けに強い

Amazon OpenSearch Service：ベクトル検索エンジン

役割：

  • Bedrockで埋め込んだベクトルを元に類似文書を高速検索
  • 文書チャンクごとにインデックスされており、クエリに近い内容を取得

選定理由：

  • ベクトル検索（KNN）をネイティブにサポート
  • マネージドサービスでスケーラブル
  • JSONでの操作が可能でLambdaとの親和性が高い

Amazon DynamoDB：ユーザー状況コンテキスト保存

役割：

  • ユーザーごとの属性情報・過去履歴などの「状況コンテキスト」を保存
  • プロンプトの冒頭に「状況」を組み込むためのソース

選定理由：

  • サーバレスかつ高速
  • キーアクセス前提のシンプルな用途に最適
  • Lambdaとの統合がスムーズ

Amazon S3：ナレッジの格納

役割：

  • インデックス対象となるPDFやテキストなどの非構造データの保管場所
  • Lambdaから定期的に読み込み、ベクトル化・インデックス化

選定理由：

  • 非構造データの格納に最適
  • サーバレス連携が容易（Lambdaトリガー等も対応可能）

AWS Lambda：全ての処理の実行基盤

役割：

  • OpenSearchへのインデックス登録
  • ベクトル検索・Bedrockによる応答生成
  • PDF抽出・ベクトル生成などの一連の処理をサーバレスで担当

選定理由：

  • サーバの管理が不要
  • 小規模〜中規模ワークロードに最適
  • IAMやAPI Gateway、S3、Bedrockとの連携がスムーズ

データフローの全体像

  • 入力：ユーザーのクエリとユーザーID
  • 内部処理：状況コンテキスト＋セマンティックコンテキストを取得し、プロンプトを構築
  • 出力：Bedrockによる自然な応答

なぜ Lambda（＝Serverless）なのか？

RAGのようなチャットボット処理は「イベント駆動・軽量処理」が多く、常時稼働型である必要はありません。そのため、

  • コスト効率が高い（リクエストごとの課金）
  • スケーリングが自動
  • コードの更新・デプロイが容易（CDK + Lambda）

などの点で、Lambdaは非常に適した選択肢です。

まとめ

RAGの構成にはいくつかの選択肢がありますが、AWSでは主要な要素（生成AI・ベクトル検索・ストレージ・ステート管理）をすべてマネージドでカバーできます。
特に以下の組み合わせは、小規模なPoCから本番運用までシームレスにスケールできる柔軟な設計です。

  • Bedrock
  • OpenSearch
  • DynamoDB
  • S3
  • Lambda

次回予告：インデックス登録の自動化

次回は、実際にS3に保存されたPDFを処理し、ベクトル化してOpenSearchに登録する方法について解説します。
LambdaからBedrock Embeddingモデルを使ってインデックスする一連の処理を、どのように構築・自動化したのかを詳しく紹介します。