社内文書を検索させてLLM（大規模言語モデル）に回答させる仕組みを、手作業のコンソール操作ではなくコードで管理したいと考えているインフラ担当・バックエンドエンジニアに向けた内容です。AWS上でRAG（検索拡張生成、Retrieval-Augmented Generationの略）基盤をTerraformで構築する際の構成要素と、そこで発生する設計判断を整理します。
RAGは、LLMが学習時点の知識だけでなく、外部の文書ストアから取得した情報を根拠に回答を生成する仕組みです。仕組みはよく知られていますが、実際にAWS上でIaC（Infrastructure as Code、インフラをコードで定義・管理する手法）化しようとすると、S3・Bedrock Knowledge Bases・OpenSearch Serverless・IAMという4つのサービスの依存関係を正しく組む必要があります。ここが実装のハードルになります。
RAGのパイプラインとAWS各サービスの役割
RAGの処理は「取り込み（ingestion）」と「検索・生成（query/retrieval）」の2フェーズに分かれます。
取り込みフェーズでは、文書をチャンク（chunk、検索しやすい単位に分割した文章の断片）に分割し、埋め込みモデル（embedding model）でベクトル化し、元テキストとメタデータと一緒にベクトルデータベースへ格納します。AWS構成では、Amazon S3が文書の置き場所、Amazon Bedrock Knowledge Bases（KB）が取り込みパイプラインの管理役になります。
具体的な流れは次の通りです。ユーザーがS3のdocsバケットに文書をアップロードし、Bedrock KBの同期（StartIngestionJob）を実行します。KBはS3から文書を読み込み、チャンク分割し、Titan Text Embeddings v2で埋め込みを生成し、結果をOpenSearch Serverlessに書き込みます。
検索フェーズでは、ユーザーの質問文もTitan Text Embeddings v2で埋め込みに変換され、OpenSearch Serverless上でのベクトル類似度検索によって関連チャンクが取得されます。取得したチャンクを質問文と一緒にLLMへ渡すことで、根拠付きの回答と引用元情報が生成されます。
ベクトル検索の内部構造を理解する
OpenSearch Serverlessのインデックス設計では、knn_vectorフィールドとKNN（k-最近傍探索）を有効化します。近似最近傍探索のアルゴリズムにはHNSW（Hierarchical Navigable Small World、階層的な近傍グラフ探索手法）を使い、内部エンジンとしてFAISSを採用する構成が示されています。
ベクトルの類似度計算にはコサイン類似度、または今回の構成のようにL2距離が使われます。コサイン類似度はベクトルの向きの近さ（角度）を評価する指標で、意味的に近い文章ほど1に近い値になります。L2距離はベクトル間のユークリッド距離で近さを測る方式で、どちらを選ぶかはBedrock KB側の埋め込みモデルとの組み合わせで決まる設定項目です。
ベクトル検索だけでなく、OpenSearchは従来型のBM25（キーワードの出現頻度に基づくランキングアルゴリズム）による字句検索も同時に扱えます。固有名詞やIDなど「意味」より「表記の一致」が重要なクエリでは、ベクトル検索とBM25検索の併用（ハイブリッド検索）を検討する余地があります。
Elasticsearchやpgvectorとの比較で見る立ち位置
自前でRAG基盤を組む場合、ベクトルDBの選択肢としてElasticsearch/OpenSearchのセルフマネージド版、PostgreSQLの拡張機能pgvector、専用のベクトルDB（PineconeやWeaviateなど）が候補になります。
OpenSearch Serverlessを選ぶ利点は、クラスタのキャパシティ管理やスケーリングをAWS側に委ねられる点です。ノード数やシャード数を運用チームが常時監視する必要がなく、Bedrock Knowledge Basesとの統合もマネージドサービス同士で完結します。
一方で、既存システムがすでにAmazon RDS for PostgreSQLを使っているなら、pgvectorで同じDBインスタンス内にベクトル検索を追加する方が構成をシンプルにできる場合もあります。どちらを選ぶかは、既存インフラとの親和性と、取り込むドキュメント量・クエリ頻度のスケール見込みで判断すると整理しやすくなります。
今日から確認できること
この構成をTerraformで実装する前に、確認しておきたいポイントを挙げます。
- IAMロールの設計: Bedrock KBがS3読み取りとOpenSearch Serverlessへの書き込みを行うため、サービスロールに
bedrock.amazonaws.comを信頼するAssumeRoleポリシーとS3・OpenSearchへの最小権限ポリシーを付与しているか - 埋め込みモデルのリージョン対応: Titan Text Embeddings v2がデプロイ予定のAWSリージョンでBedrockから利用可能か、AWSマネジメントコンソールのBedrockモデルアクセス画面で確認する
- OpenSearch Serverlessのコレクションポリシー: ネットワークポリシー・データアクセスポリシー・暗号化ポリシーの3種類をTerraformリソースとして個別に定義する必要があるため、抜け漏れがないか
- チャンクサイズの設定値: Bedrock KBのチャンク戦略（固定サイズ・階層的など）はドキュメントの種類によって検索精度に影響するため、初期値のまま本番投入する前に少量データで試すか
公式のTerraformプロバイダドキュメントでは、aws_bedrockagent_knowledge_baseリソースとaws_opensearchserverless_collectionリソースの必須パラメータを確認できます。実装前にこれらのリソースのarguments一覧を一度読んでおくと、後から設定漏れに気づいて手戻りする事態を避けやすくなります。
まとめ
AWS上でのRAG基盤構築は、S3・Bedrock Knowledge Bases・OpenSearch Serverless・IAMという4サービスの責務分担を理解することが出発点になります。
Terraformで管理する場合は、IAMロールの権限設計とOpenSearch Serverlessの3種類のポリシー定義が実装の大部分を占めます。まずはAWSコンソールでBedrockのモデルアクセス設定を確認し、対象リージョンでTitan Text Embeddings v2が有効になっているかをチェックしてみてください。
そのうえで小規模なドキュメントセットを使い、チャンクサイズや距離計算方式（コサイン類似度かL2距離か）を変えて検索精度を比較してみると、本番投入前の設計判断の材料になります。