はじめに
2025年6月に開催された AWS Summit Japan。生成AIを活用した最新のユースケースや、AWSの新サービスの発表など、多くの学びが得られるイベントでした。
私自身もエンジニアとしてこのイベントに参加し、特に印象に残ったのが「生成 AI のためのデータ活用実践ガイド」というセッションでした。
このセッションをきっかけに、RAG（Retrieval-Augmented Generation） というアプローチに改めて注目し、実際にAWSを使ってRAGチャットボットを構築することにしました。
この記事では、RAGとは何か、なぜAWSで構築しようと考えたのか、そして本シリーズの構成についてご紹介します。
AWS Summit Japan 2025 で得た気づき
生成AIは「活用のための土台」が問われるフェーズへ
今回のAWS Summitでは、生成AIのモデル自体よりも「どう活用するか」「どんなデータで強化するか」にフォーカスが移っている印象を強く受けました。
中でも注目したセッションがこちらです。
- セッション名： 生成 AI のためのデータ活用実践ガイド
- キーワード： 「非構造データ」「検索強化生成（RAG）」「Bedrock × OpenSearch」「文脈の重要性」
このセッションでは、「企業独自の知見を活かすためのAI活用には、社内のナレッジや文書をどう連携させるかがカギ」であるというメッセージが繰り返されていました。
RAGとは？
RAG（Retrieval-Augmented Generation）は、外部の情報検索を行ったうえで、生成AIが回答を行うアーキテクチャです。
従来の大規模言語モデル（LLM）は、あらかじめ学習された知識に基づいて応答を行うため、以下のような課題がありました。
- 最新情報に対応できない
- ユーザー固有の情報（社内ドキュメントなど）を反映できない
RAGはこの課題を解決するために、以下のような流れで処理を行います。
- ユーザーの質問をベクトル化
- OpenSearchなどの検索エンジンで、関連文書をベクトル検索
- 検索結果をもとに、生成AIが応答を構築
これにより、「ユーザーの質問に対して、社内の非構造データを活用した回答」が可能になります。
なぜAWSでRAGを構築しようと思ったか？
RAGを実装するには、以下のような機能が必要です。
- ベクトル検索ができるデータストア（例：OpenSearch）
- ユーザーの質問や状況を保存する仕組み（例：DynamoDB）
- ドキュメントの管理やアップロード（例：S3）
- テキストをベクトル化・応答生成できる生成AI（例：Bedrock + ClaudeやTitan）
これらがすべて AWSのマネージドサービスで揃う という点に魅力を感じました。
加えて、LambdaやCDKといったインフラ自動化・Serverlessアーキテクチャとの相性が良いのも大きな理由です。
今後の連載の構成（予定）
本シリーズでは、以下のような流れで「AWS上にRAGチャットボットを構築する方法」をご紹介します。
【第1回】（この記事）
RAGの概要と構築の動機
【第2回】
構成設計と使用サービス紹介（OpenSearch / DynamoDB / Bedrockなど）
【第3回】
S3からPDFを読み込み → ベクトル化 → OpenSearchへのインデックス登録
【第4回】
検索・文脈構築 → Claudeによる応答生成 → API化
【第5回（予定）】
運用・拡張・学習の工夫やTips
まとめ
生成AIは「使い方」が問われるフェーズに入りました。そしてRAGは、まさにその鍵となる技術の一つです。
AWS Summitでの学びをきっかけに、実際に自分の手でRAGチャットボットを構築したプロセスを、これから数回にわたって紹介していきます。
次回は、どのような構成でRAGを実現するか、各AWSサービスの役割と選定理由について詳しく掘り下げていきます。
簡単30秒