そこで、AWSでRAGを構築したいユーザーに小林氏が薦めるのが、AWSがGitHubで公開している実装サンプル集「Generative AI Use Cases」（GenU）だ。「GitHub」のリポジトリと実装の手順書がセットになっており、AWSのアカウントさえあれば手順書に沿って簡単にデプロイできる。「parameter.ts」（環境設定をまとめたTypeScriptファイル）で「RAG」や「Agent」など必要なユースケースを指定しておくことで、「AWS Cloud Development Kit」（CDK）がデプロイ時にその情報を参照し、必要なリソースが確保される。あとはデータストアに必要なデータを格納するだけですぐにRAGを試せる。

GenUのトップページ（出典：AWSのWebサイト）

　日本でも複数の企業がこのサンプルを基にサービスを開発している。既にAWSの環境を持っていて開発経験があるのなら、まずはここからRAGの構築を始めてみてほしい。

AWSのRAG関連サービス

　GenUを使えば比較的簡単にRAGを構築できるが、精度やコストを自社に最適化するためには各サービスの設定のチューニングが必要だ。GenUで配布されているサンプルのアーキテクチャは以下の通りだ。ユーザーの指示に従って、Amazon Bedrockを中心にさまざまなサービスが連携していることが分かる。

GenUのアーキテクチャ図（出典：GenUのドキュメント）

　以下では、この中でもRAGの構築に深く関連するものについて解説する。

「Amazon Bedrock」と「Amazon SageMaker AI」でモデルを提供

　Amazon BedrockはAWSの生成AI開発プラットフォームだ。複数の基盤モデルを単一のAPIで提供し、RAGやAIエージェント、安全対策などの機能も盛り込む。

　Amazon SageMaker AIは、機械学習モデルの開発からデプロイ、推論、運用まで実行できるフルマネージドサービスだ。オープンウェイトモデルのファインチューニングするなど、モデルに対して独自の調整を施したい場合はこちらを基盤としてRAGを構築することもできる。

「Amazon Bedrock Knowledge Bases」と「Amazon OpenSearch Service」で文書を検索

　「Amazon Bedrock Knowledge Bases」（以下、Knowledge Bases）はデータソースとモデルをつなげてRAGを実現するサービスだ。上記のアーキテクチャではKnowledge Basesからベクトルデータベースの「Amazon OpenSearch Service」（以下、OpenSearch）を介して「Amazon S3」（以下、S3）に接続しているが、実際の流れは以下の通りだ。

　まずKnowledge BasesがS3（データソース）から文書を抽出してチャンク（意味を持つ数語のかたまり）に分割し、Embedding（埋め込み：テキストをベクトルに変換する技術）によってベクトルデータを生成する。そのベクトルデータは「OpenSearch」に格納され、ユーザーが入力したプロンプトに応じて検索対象となり、検索結果を基にモデルが回答を生成する。

RAGのプロセス（出典：AWSのWebサイト）

「Amazon Kendra」での検索も可能

　「Amazon Kendra」（以下、Kendra）はAWSのエンタープライズ検索サービスで、生成AIブーム以前から提供されている。S3や「Box」「Microsoft SharePoint」などさまざまなソースのデータをベクトルストアに格納し、インデックスの作成と検索を実行する。

　Knowledge Basesと似たサービスに見えるが、Kendraはあくまで検索サービスのため、チャンキングの調整やベクトルストアの選択など、RAGの精度を向上させるための細かいチューニングには対応していない。特定のデータソースに基づいたRAGをイチから構築する場合はKnowledge Basesが便利だが、既にKendraを利用している場合はRAGの「Retrieve」を担わせることもできる。社内データを広く検索対象としたり、生成だけでなくエンタープライズ検索も必要だったりする場合は検討の価値があるだろう。

「Amazon S3」でデータを一元管理

　S3はAWSのクラウドストレージサービスだ。2006年から提供されており、本稿執筆時点では1GB当たり0.025米ドル（東京リージョン）から使用できる。データレイクやログデータの保存先などさまざまな用途で使用されており、GenUのアーキテクチャでもデフォルトのデータソースとして位置付けられている。S3でデータを一元管理している企業はAWSでのRAGの構築がスムーズに進められそうだ。

　2025年7月には「Amazon S3 Vectors」が発表され、S3をベクトルストアとして利用できるようになった。OpenSearchとの連携機能も発表されており、あまり使用されないベクトルデータをS3に格納することでベクトルストアの利用コストを抑えられるという。

Amazon S3 Vectorsの連携イメージ（出典：AWSのWebサイト）

　AWSでRAGを構築する場合、これらのサービスでの開発が基本形となる。

導入時の注意点

　GenUを使うことで比較的手軽にRAGの構築が始められそうだが、「思ったように精度が上がらない」「意外とコストがかかる」といった問題は起こりがちだ。

　小林氏はRAGの精度を上げるコツとして次の3点を挙げた。

　モデルの利用料は「『意外と安い』という声をよく聞く」と小林氏は述べる。利用するモデルにもよるが、1ユーザー当たり1日数回の問い合わせでは大した料金にはならない。一方、RAGのコストで最も大きいのはベクトルストアの利用料だ。問い合わせ回数が少なくても、検索対象のデータを蓄積しておくのに料金がかかる。不要なデータソースを接続しないよう注意する必要がある。

　その他、RAG導入時の主なリスクとして挙げられるのは「情報漏えいのリスク」と「思ったより使われないリスク」だ。前者については、個人情報など機微のあるデータがソースに含まれていないかを確認したり、適切な権限管理を徹底したりといった対策が重要だ。後者については「現場を巻き込んで作る」ことが重要だと小林氏は指摘する。IT部門が開発したものを一方的に配るのではなく、要件定義の段階でユーザーの声をしっかりと取り入れることが重要だ。

AWSでRAGを構築する意味

　ここまで3回に渡ってMicrosoft、Google Cloud、AWSのクラウドサービスにおけるRAG構築について解説してきたが、その中でもAWSを選ぶ意味は何か。小林氏は以下の3点を挙げる。

　本特集では3回にわたってハイパースケーラー各社のクラウドサービスにおけるRAG構築術を解説した。製品の進化が速い分野のため、あくまで本稿執筆時点の情報として導入の参考にしてほしい。