AWSでRAGを構築する“最短ルート” 関連サービスや注意点を徹底解説：RAG構築術 AWS編

生成AIに自社データを連携させる「RAG」。AWS環境でこれを実装するには、どのようなサービスを組み合わせ、どう最適化すべきか。本稿では、その具体的なアーキテクチャから「Amazon Bedrock」「Knowledge Bases」「Amazon OpenSearch Service」などの関連サービスの詳細、精度向上の勘所などを網羅的に解説する。

[村田知己，キーマンズネット]

　外部情報の検索機能を大規模言語モデル（LLM）に組み合わせる手法、「RAG」（Retrieval-Augmented Generation＝検索拡張生成）を大手クラウドサービスで実装する方法を網羅的に解説する本特集。第3回は「Amazon Web Services」（AWS）編をお届けする。

• 第1回：Microsoft編
• 第2回：Google Cloud編
• 第3回：AWS編（本稿）

AWSでRAG構築するならまずはココから

開発を最小限にするなら「Amazon Q」

　AWSで簡単にRAGを構築する方法としてまず挙げられるのが「Amazon Q」だ。Amazon QはAWSの生成AI開発プラットフォーム「Amazon Bedrock」を基に構築された生成AIアシスタントサービスだ。全従業員向けの「Business」と開発者向けの「Developer」に大別され、Businessは自社のコンテンツやデータに基づいて回答させることが可能だ。ナレッジ検索だけでなく、AIアプリケーションの構築や、「Jira」「ServiceNow」「Salesforce」などのサードパーティアプリケーションの操作もできる。

　Amazon Qはタスクに応じた基盤モデルを自動で選択するため、ユーザー側で基盤モデルを選択できない。利用するモデルを選びたい場合は後述の方法でシステムを構築する必要がある。

　利用には「ユーザーサブスクリプション」という1ユーザー当たりの料金と、「インデックスキャパシティ」という接続したデータソースのインデックスのサイズに応じた料金を支払う必要がある。

　Amazon Qは東京リージョンで提供予定とされているが、本稿執筆時点ではまだ提供されていない。現時点では「英語での対応に最適化されている」ともされており、日本企業が導入しやすい環境が待たれる。

開発者なら便利なテンプレートを

　第1回と第2回で取り上げたMicrosoftとGoogleは「Microsoft 365 Copilot」や「Copilot Studio」「NotebookLM」「Google Agentspace」などRAGを含む機能がパッケージ化されたサービスを豊富に提供している点が特徴的だった。一方、AWSはクラウドインフラ寄りのサービスが中心のため、RAGの提供形態も開発者向けの色が濃い。

　「Amazon Q BusinessはRAG以外にもさまざまな機能を持っており、ナレッジ検索だけを求める場合は機能を持て余す可能性がある」。そう指摘するのはアマゾンウェブサービスジャパンの小林正人氏（サービス＆テクノロジー事業統括本部 技術本部長）だ。

　そこで、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点を挙げた。

• プロンプトエンジニアリング：　良いプロンプトを入力することで、良い出力が得られやすい。優れたプロンプトをテンプレート化することで、ユーザーの習熟度に依存せずに一定の出力品質を保てる可能性がある
• チャンキングの調整：　チャンクのサイズが小さすぎると情報が失われてしまい、大きすぎるとノイズが混じってしまう。文書の性質を考慮して適切なチャンクサイズに調整することでRAGの精度が上がる可能性がある
• 継続的なメンテナンス：　最初から100点満点のサービスを作ることは難しい。上記のようなメンテナンスを、ユーザーからのフィードバックに基づいて継続的に実施することで、ユーザーの要件に沿ったシステムに近づけられる

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

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

AWSでRAGを構築する意味

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

• S3を中心としたサービス群とのシナジー：　S3で安価にデータを蓄積することで効率的にRAGを構築できる。S3でデータを一元管理すれば「Amazon QuickSight」でダッシュボードを作るなど、他の用途にも使える
• 高性能なモデルから安いモデルまで幅広く選べる：　Anthropicの「Claude」シリーズをはじめとしてさまざまなモデルを利用できる。AWSの独自モデル「Amazon Nova」はコストパフォーマンスに優れる
• パートナーが豊富：　パートナー企業の選択肢が豊富だ。RAG構築をサポートしてもらうならAIに関するスキル認定を持つパートナーがおすすめだ。ただし、現状は大手ベンダーばかりなので、予算が限られる場合は「生成AI実用化推進プログラム」に参加しているベンダーから選ぶのが良いという。AWSにコンタクトを取ってパートナーを紹介してもらうことも可能だ

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