Bedrock RAG ハンズオン入門 Knowledge Bases OpenSearch Agents Terraform

1. RAG とは・ユースケース・従来検索との違い

1-1. RAG とは何か

大規模言語モデル (LLM) は学習データ外の最新情報や社内固有知識を問われると、事実と異なる回答を自信満々に生成する「幻覚 (Hallucination)」問題を抱えている。モデルをファインチューニングして知識を注入する方法もあるが、毎回の学習コストと時間が膨大になる。RAG (Retrieval-Augmented Generation) はこの問題を「外部知識を検索してプロンプトに注入する」手法で解決する。モデルの重みを変えず、最新の文書を動的に参照できるのが最大の特長だ。

処理は次の 3 段で構成される。

1. Retrieve (検索) — ユーザーのクエリをベクトル化し、Vector Index から意味的に近い文書チャンクを Top-K 件取得する
2. Augment (拡張) — 取得したチャンクをプロンプトテンプレートに埋め込み、LLM へのコンテキストを構築する
3. Generate (生成) — LLM が注入されたコンテキストを根拠に、出典に基づいた回答と citation を生成する

主要用語:

なお、RAG はすべての質問に万能ではない。学習データ内の一般知識で回答できる質問やリアルタイム計算が必要な質問には RAG より直接のファインチューニングや関数呼び出しが有効な場合もある。「社内固有ドキュメントへの回答」「頻繁に更新される情報への参照」「引用元を明示した回答生成」が必要なシナリオこそが RAG の真骨頂だ。

1-2. Bedrock Knowledge Bases の位置付け

従来の RAG 自前実装では LangChain + Pinecone + OpenAI Embeddings のように複数のサービスを組み合わせ、チャンキング処理・Embedding API の認証管理・Vector Index のスケーリング・ライフサイクル管理をすべて自前で担う必要があった。Amazon Bedrock Knowledge Bases (2024 年 Q1 GA) はこれらをフルマネージドで提供し、RAG 基盤の実装負担を大幅に削減する。取込からベクトル検索・回答生成までを同一 AWS アカウント内で完結できるため、データが外部サービスに送出されないセキュリティ面の利点もある。

1-3. ユースケース 4 選

Bedrock RAG が特に効果を発揮する代表的なユースケースを示す。

各ユースケースの特性をさらに補足する。

• (a) 社内 FAQ bot は Q&A 形式のデータが多く、1 チャンクが 1 Q&A ペアに収まりやすいため SEMANTIC チャンキングが文脈を保ちやすい。Slack・Confluence・社内 Wiki を S3 に定期エクスポートして連携するパターンが一般的。
• (b) 製品マニュアル は数十〜数百ページの PDF が中心で、章をまたぐ参照関係が多い。HIERARCHICAL チャンキングはページ単位の親チャンクと段落単位の子チャンクの 2 層構造で参照精度を高める。
• (c) コードレビュー補助 はコードブロックの境界でチャンクを切る必要があり、FIXED_SIZE でトークン数を揃えつつ関数境界を意識した前処理が効果的。
• (d) 契約書分析 は誤った引用が法的リスクにつながるため、Guardrails で「根拠なき断言を禁止する」トピックフィルターを設定することが必須。

更新頻度が高いデータソースは INCREMENTAL sync を活用して取込コストを抑えることができる。チャンキング戦略の詳細は §4 で解説する。

1-4. 従来検索との違い

キーワード検索 (BM25/Lucene) とベクトル検索の根本的な違いを理解することで、自社ユースケースに最適な検索設計を選択できる。

2026 年 4 月時点の OpenSearch Serverless は BM25 + kNN (faiss/nmslib) + sparse neural search の 3 方式に対応している。sparse neural search は BERT 系モデルで語彙ベクトルを生成し、全文検索の語彙精度とベクトル検索の意味理解を自然に統合する手法だ。本記事のハンズオンでは kNN (dense vector) を中心に扱い、ハイブリッド検索の発展的活用は §5 のコラムで補足する。

また、LLM のコンテキストウィンドウの拡大 (Claude 3.5 Sonnet v2 は 200K tokens) により「すべてのドキュメントをプロンプトに詰め込む」アプローチも技術的には可能になっているが、検索精度・コスト・レイテンシの観点から、Vector Index による Top-K 検索は依然として RAG の推奨アーキテクチャとなっている (2026 年 4 月時点)。

1-5. この記事で到達する範囲

本記事の 8 章を通じて、terraform apply で全インフラを構築し python retrieve_and_generate.py を実行して RAG の応答と citation (出典チャンク) を確認できる状態を目指す。Agents まで進めれば「RAG 検索 + 外部 API 呼び出し」の合わせ技エージェントも体験できる。

読了時間の目安は約 120 分、terraform apply 〜 Agents 作成を含むハンズオン実機操作は 45〜60 分を見込む。各章は独立性を意識して書かれているため、OpenSearch 構築 (§3) や Agents (§6) のみを参照することも可能だ。なお、本記事全体で使用するコードは hashicorp/aws provider ~> 5.70 / Python 3.11+ / boto3 1.35.x を前提としており、バージョンが異なる場合は動作保証外となる (2026 年 4 月時点)。

1-6. 前提環境

# 前提環境確認
python --version # Python 3.11.x 以上
pip install "boto3==1.35.76"
terraform -version  # Terraform v1.9.x 以上

1-7. 本記事で扱う API バージョンと範囲宣言

Bedrock Knowledge Bases・Agents・OpenSearch Serverless は 2024-2025 年にかけて API・リソースが急速に拡張されている。本記事は 2026 年 4 月時点 の GA 機能のみを対象とし、以下の機能は範囲外とする (将来記事で別途扱う):

• Agents multi-agent collaboration (2025 Q4 GA): 複数エージェント協調。本記事は single agent 構成のみ
• Prompt caching (2026 Q1 GA): プロンプトキャッシュ。本記事の retrieve_and_generate では未使用
• Model Distillation / Batch Inference: 推論最適化・バッチ処理系は別テーマ

また Terraform aws_bedrockagent_* リソース群 は 2024 Q3 以降に追加され、provider 5.x 内で破壊的変更が数回発生した履歴がある。本記事は hashicorp/aws ~> 5.70 でピン留めしており、terraform init -upgrade で上位に移る場合は必ず AWS Provider CHANGELOG を確認してほしい。API 仕様・料金・モデル ARN は執筆時点 (2026 年 4 月) の AWS 公式 doc を一次ソースとし、読者自身の実行タイミングで再確認することを強く推奨する。

次章へ: Knowledge Bases データソース設計

2. Knowledge Bases for Amazon Bedrock 概論 + データソース設計

2-1. Knowledge Base / Data Source / Vector Store の 3 層モデル

Amazon Bedrock Knowledge Bases のアーキテクチャは Knowledge Base (KB) / Data Source / Vector Store の 3 層で構成されている。各層の役割を理解することで Terraform での宣言設計がスムーズになる。

• Knowledge Base (KB) — RAG 処理のトップレベルエントリーポイント。retrieve / retrieve_and_generate API のエンドポイントとなり、Embeddings モデルや Vector Store の接続設定を保持する
• Data Source — ドキュメントの取込元を定義する設定単位。S3 バケット・Web Crawler の URL・Confluence スペースなどを指定する。1 つの KB に複数の Data Source を関連付けられる
• Vector Store — Embedding ベクトルを格納・検索する永続ストレージ。本記事では Amazon OpenSearch Serverless を使用する。1 つの KB に対して 1 つの Vector Store が紐付く制約があることを必ず押さえておく

この 3 層の制約を図で表すと 1 KB : N Data Source : 1 Vector Store となる。複数の Data Source (例: 製品マニュアル S3 + コーポレートサイト Web Crawler) を同一 KB に登録し、Ingestion Job を実行すると、全データソースのチャンクが単一の Vector Store に蓄積される。検索時はその Vector Store 全体から Top-K 件を取得する仕組みだ。

Ingestion Job (データ取込処理) は Data Source 単位でトリガーする。Job 実行中に S3 に新しいドキュメントを追加しても、次回 Ingestion Job まで Vector Store には反映されない点に注意が必要だ。自動化には EventBridge Scheduler + Lambda で定期実行するパターンが一般的で、§7 で扱う。

2-2. データソース 3 種の比較

Knowledge Bases が対応するデータソースの種類は 2026 年 4 月時点で S3 / Web Crawler / Confluence (SharePoint・Salesforce を含む) の 3 カテゴリがある。自社のドキュメント管理形態に応じて選択する。

FULL_SYNC は全ドキュメントを再スキャンするためドキュメント削除・移動にも対応するが、大規模 KB では Embedding コストが増加する。INCREMENTAL は S3 の ETag・更新タイムスタンプで差分検出するため取込コストを抑えられる。更新頻度の高いデータソースには INCREMENTAL の使用を推奨する。

2-3. S3 データソース設計

S3 データソースは最も汎用的かつ対応ファイル形式が豊富なため、初めて Knowledge Base を構築する際の第一選択肢となる。設計上の重要ポイントを以下に示す。

バケット構造の推奨例:

s3://my-kb-bucket/
  docs/
 product-manuals/
v1.0/
  product-a.pdf
  product-a.pdf.metadata.json  ← メタデータサイドカー
v2.0/
  product-a.pdf
 faq/
support-faq.html
 legal/
contract-templates/
  nda-template.pdf

prefix を用途別に分けることで、Data Source の inclusionPrefixes / exclusionPrefixes フィルターを使って取込範囲を精緻に制御できる。例えば docs/legal/ のみを対象とした法務専用 Data Source を作ることも可能だ。

各ドキュメントと同名 + .metadata.json 拡張子のサイドカーファイルを S3 に配置することで、チャンクに department / version / language などのカスタムメタデータを付与できる。Retrieve 時のメタデータフィルタリングに活用する。

Terraform — S3 バケット:

resource "aws_s3_bucket" "kb_bucket" {
  bucket = "${local.project_name}-kb-docs"
  tags= local.common_tags
}

resource "aws_s3_bucket_versioning" "kb_bucket" {
  bucket = aws_s3_bucket.kb_bucket.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_public_access_block" "kb_bucket" {
  bucket= aws_s3_bucket.kb_bucket.id
  block_public_acls = true
  block_public_policy  = true
  ignore_public_acls= true
  restrict_public_buckets = true
}

2-4. Web Crawler データソース設計

Web Crawler データソースは 2024 年 GA となった機能で、指定した seed URL を起点にページを再帰的にクロールし、HTML コンテンツを Knowledge Base に取り込む (2026 年 4 月時点)。

設計のポイント:

• seed URL — クロールの起点 URL を最大 10 件まで指定できる。サイトのトップページを指定すると配下のページを自動探索する
• crawl scope — HOST_ONLY はシードと同じホスト内のみ、SUBDOMAINS はサブドメインも含めてクロールする。外部 URL へのリンクは常に除外される
• rate limit — デフォルトは 300 ミリ秒間隔。対象サイトの robots.txt に Crawl-delay が設定されている場合はその値を優先すること
• 法務確認 — 社外の公開サイトをクロールする場合、そのサイトの利用規約・robots.txt を確認し、法務部門のレビューを必ず経ること。User-Agent: Bedrock-Knowledge-Base-Crawler として識別される (2026 年 4 月時点)

Terraform — Web Crawler Data Source HCL スケルトン:

resource "aws_bedrockagent_data_source" "web_crawler" {
  knowledge_base_id = aws_bedrockagent_knowledge_base.main.id
  name  = "corporate-site-crawler"

  data_source_configuration {
 type = "WEB"
 web_configuration {
source_configuration {
  url_configuration {
 seed_urls {
url = "https://docs.example.com/"
 }
  }
}
crawler_configuration {
  crawler_limits {
 rate_limit = 300
  }
  scope = "HOST_ONLY"
}
 }
  }

  vector_ingestion_configuration {
 chunking_configuration {
chunking_strategy = "DEFAULT"
 }
  }
}

2-5. IAM ロール設計

Knowledge Base が AWS サービスを操作するための KB service role を適切に設計することが、Ingestion Job の成功と最小権限原則の両立に不可欠だ。

KB service role に必要な権限:

trust policy の principal は bedrock.amazonaws.com を指定する。sts:AssumeRole の Condition で aws:SourceAccount を設定することで、他 AWS アカウントからの不正利用を防ぐことができる。

Terraform — IAM ロール + 最小権限ポリシー:

data "aws_caller_identity" "current" {}

resource "aws_iam_role" "kb_service_role" {
  name = "${local.project_name}-kb-service-role"
  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect = "Allow"
Principal = { Service = "bedrock.amazonaws.com" }
Action = "sts:AssumeRole"
Condition = { StringEquals = {
  "aws:SourceAccount" = data.aws_caller_identity.current.account_id
}}
 }]
  })
  tags = local.common_tags
}

resource "aws_iam_role_policy" "kb_service_policy" {
  name= "kb-service-policy"
  role= aws_iam_role.kb_service_role.id
  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Sid= "BedrockEmbedding"
  Effect= "Allow"
  Action= ["bedrock:InvokeModel"]
  Resource = [
 "arn:aws:bedrock:${local.region}::foundation-model/amazon.titan-embed-text-v2:0",
 "arn:aws:bedrock:${local.region}::foundation-model/cohere.embed-multilingual-v3",
  ]
},
{
  Sid= "S3Access"
  Effect= "Allow"
  Action= ["s3:GetObject", "s3:ListBucket"]
  Resource = [aws_s3_bucket.kb_bucket.arn, "${aws_s3_bucket.kb_bucket.arn}/*"]
},
{
  Sid= "AOSSAccess"
  Effect= "Allow"
  Action= ["aoss:APIAccessAll"]
  Resource = aws_opensearchserverless_collection.vector_store.arn
}
 ]
  })
}

2-6. Chunking 戦略の概論

Knowledge Base へのデータ取込時、ドキュメントは チャンク (chunk) と呼ばれる小単位に分割されてから Embedding される。チャンクの粒度と方式が Retrieve 精度に直結するため、データの性質に合わせた選択が重要だ。

4 つの Chunking 方式 (2026 年 4 月時点):

HIERARCHICAL は 2024 年 Q3・SEMANTIC は 2025 年 Q4 にそれぞれ GA となった (2026 年 4 月時点)。最新の対応状況は Knowledge Bases 公式ドキュメント で確認してください。Chunking 方式の選定フローと Terraform での設定方法は §4 で詳しく解説する。§3 では Knowledge Base の Embedding ベクトルを格納する OpenSearch Serverless vector index の構築を行う。

3. OpenSearch Serverless で vector index を構築する

3-1. OpenSearch Serverless 概観 — OCU と料金構造

Amazon OpenSearch Serverless はクラスター管理が不要なフルマネージド OpenSearch サービスです。Bedrock Knowledge Bases のベクトルストアとして最も簡単に統合できる選択肢です。プロビジョンドの OpenSearch Service と比較すると、容量計画が不要な代わりに OCU (OpenSearch Compute Unit) 単位で時間課金されます。

OCU は vCPU 2 コアと RAM 8 GB に相当するリソース単位で、indexing 専用と search 専用の 2 種類があります。Bedrock Knowledge Bases では最小 2 OCU (indexing 1 + search 1) が必要です。2024 年以前は 1 OCU 最小が可能でしたが廃止されているため注意してください。OCU 単価は $0.24/OCU/時間 (2026 年 4 月時点 / us-east-1)。月額最低コスト: 2 OCU × 730 時間 × $0.24 = $350.40/月。OCU は 24/7 で課金されるため、検証環境では作業後に collection を削除することを強く推奨します。最新料金は AWS OpenSearch Service Pricing でご確認ください。

3-2. Collection 作成 — Terraform 定義

aws_opensearchserverless_collection で VECTORSEARCH タイプの collection を作成します。encryption_policy と network_policy は collection より先に作成が必要なため depends_on で順序制御します。

resource "aws_opensearchserverless_security_policy" "encryption" {
  name = "${local.project_name}-enc"
  type = "encryption"

  policy = jsonencode({
 Rules = [{ ResourceType = "collection", Resource = ["collection/${local.project_name}-vector"] }]
 AWSOwnedKey = true
  })
}

resource "aws_opensearchserverless_security_policy" "network" {
  name = "${local.project_name}-net"
  type = "network"

  policy = jsonencode([{
 Rules = [
{ ResourceType = "collection", Resource = ["collection/${local.project_name}-vector"] },
{ ResourceType = "dashboard",  Resource = ["collection/${local.project_name}-vector"] }
 ]
 AllowFromPublic = true
  }])
}

resource "aws_opensearchserverless_collection" "kb_vector" {
  name = "${local.project_name}-vector"
  type = "VECTORSEARCH"
  tags = local.common_tags

  depends_on = [
 aws_opensearchserverless_security_policy.encryption,
 aws_opensearchserverless_security_policy.network,
  ]
}

AWSOwnedKey = true は AWS 所有 KMS キー、AllowFromPublic = true は開発用パブリックアクセスです。本番環境では CMK (KmsARN 指定) と VPC エンドポイント経由のプライベートアクセスへの切り替えを推奨します。

3-3. Access Policy 設計 — KB service role への権限付与

Bedrock KB は専用の service role で OpenSearch Serverless にアクセスします。aws_opensearchserverless_access_policy でそのロールに aoss:* 権限を付与します。

resource "aws_opensearchserverless_access_policy" "kb_access" {
  name = "${local.project_name}-kb-access"
  type = "data"

  policy = jsonencode([{
 Rules = [
{
  ResourceType = "index"
  Resource  = ["index/${local.project_name}-vector/*"]
  Permission= ["aoss:*"]
},
{
  ResourceType = "collection"
  Resource  = ["collection/${local.project_name}-vector"]
  Permission= ["aoss:*"]
}
 ]
 Principal = [aws_iam_role.bedrock_kb_role.arn]
  }])
}

Principal には §2 で作成した Bedrock KB service role の ARN を指定します。index と collection の両レベルへの権限が必要です。aws_bedrockagent_knowledge_base の apply 前に access policy が完成していることを確認してください。

3-4. Vector Index 構築 — Terraform 未対応のため curl で作成する

vector index の作成は hashicorp/aws provider では未対応 (2026 年 4 月時点) です。curl または Python で OpenSearch REST API を直接呼び出して作成します。

KB 用必須フィールド (3 点)

ENDPOINT=$(terraform output -raw opensearch_collection_endpoint)
INDEX_NAME="bedrock-kb-index"

curl -XPUT "https://${ENDPOINT}/${INDEX_NAME}" \
  --aws-sigv4 "aws:amz:us-east-1:aoss" \
  --user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
  -H "Content-Type: application/json" \
  -H "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
  -d '{
 "settings": { "index": { "knn": true } },
 "mappings": {
"properties": {
  "bedrock-knowledge-base-default-vector": {
 "type": "knn_vector",
 "dimension": 1024,
 "method": { "name": "hnsw", "engine": "faiss" }
  },
  "AMAZON_BEDROCK_TEXT_CHUNK": { "type": "text" },
  "AMAZON_BEDROCK_METADATA":{ "type": "keyword" }
}
 }
  }'

engine は faiss (高速・大規模向け) と nmslib (精度重視) から選択できます。Knowledge Bases の推奨は faiss です。dimension は Titan v2 / Cohere v3 の標準次元数 1024 に合わせます。Cohere 384 次元モデルを使う場合は "dimension": 384 に変更してください。

Python 版は requests-aws4auth で SigV4 署名を付与します。

import boto3, requests
from requests_aws4auth import AWS4Auth

def create_kb_index(endpoint: str, index_name: str, dimension: int = 1024, region: str = "us-east-1"):
 creds = boto3.Session().get_credentials().get_frozen_credentials()
 auth = AWS4Auth(creds.access_key, creds.secret_key, region, "aoss", session_token=creds.token)
 body = {
  "settings": {"index": {"knn": True}},
  "mappings": {
"properties": {
 "bedrock-knowledge-base-default-vector": {
  "type": "knn_vector", "dimension": dimension,
  "method": {"name": "hnsw", "engine": "faiss"},
 },
 "AMAZON_BEDROCK_TEXT_CHUNK": {"type": "text"},
 "AMAZON_BEDROCK_METADATA":{"type": "keyword"},
}
  },
 }
 resp = requests.put(f"https://{endpoint}/{index_name}", auth=auth, json=body)
 resp.raise_for_status()
 return resp.json()

3-5. コンソール代替手順 — Quick create でフォールバックする

Terraform での vector index 作成に問題が発生した場合、Bedrock コンソールの “Quick create” で OpenSearch Serverless を自動構成できます。

1. AWS マネジメントコンソール → Amazon Bedrock → Knowledge Bases → Create knowledge base
2. Vector store セクションで “Quick create a new vector store” を選択
3. collection と vector index が自動作成される (index フィールド設定も自動)
4. KB 作成後、collection ID をコンソールで確認し terraform import で Terraform 管理に取り込む

Quick create は IaC としての管理性が失われます。security_policy・network_policy・access_policy もそれぞれ個別に import が必要なため、最初から Terraform で構築する方がトータルコストは低くなります。

3-6. コールドスタートとレイテンシ — 本番運用で必ず考慮する

OpenSearch Serverless は一定時間リクエストがない場合に休眠状態になり、初回リクエストで 30〜60 秒のレイテンシ が発生する場合があります (AWS 公式ドキュメント記載・2026 年 4 月時点)。

import boto3

def warmup_knowledge_base(kb_id: str, region: str = "us-east-1") -> None:
 """OpenSearch Serverless のコールドスタートを防ぐ warmup 関数"""
 client = boto3.client("bedrock-agent-runtime", region_name=region)
 try:
  client.retrieve(
knowledgeBaseId=kb_id,
retrievalQuery={"text": "warmup"},
retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 1}},
  )
 except Exception:
  pass  # warmup のため結果は無視

4. Knowledge Base 作成 + Embeddings model 選択 + Chunking 戦略

4-1. Knowledge Base Terraform 定義

aws_bedrockagent_knowledge_base が正式リソース名です（aws_bedrock_knowledge_base は誤り）。locals でモデル ARN と次元数を変数化しておくと、Embeddings model の切り替えが容易になります。

locals {
  region = "us-east-1"

  embedding_models = {
 titan_v2 = {
arn = "arn:aws:bedrock:${local.region}::foundation-model/amazon.titan-embed-text-v2:0"
dimension = 1024
 }
 cohere_multilingual_v3 = {
arn = "arn:aws:bedrock:${local.region}::foundation-model/cohere.embed-multilingual-v3"
dimension = 1024
 }
  }
  selected_model = local.embedding_models["titan_v2"]
}

resource "aws_bedrockagent_knowledge_base" "this" {
  name  = "my-rag-kb"
  role_arn = aws_iam_role.kb_role.arn

  knowledge_base_configuration {
 type = "VECTOR"
 vector_knowledge_base_configuration {
embedding_model_arn = local.selected_model.arn
 }
  }

  storage_configuration {
 type = "OPENSEARCH_SERVERLESS"
 opensearch_serverless_configuration {
collection_arn = aws_opensearchserverless_collection.this.arn
vector_index_name = "bedrock-kb-index"
field_mapping {
  vector_field= "bedrock-knowledge-base-default-vector"
  text_field  = "AMAZON_BEDROCK_TEXT_CHUNK"
  metadata_field = "AMAZON_BEDROCK_METADATA"
}
 }
  }

  tags = { Project = "bedrock-rag-handson", ManagedBy = "Terraform" }
}

field_mapping の 3 フィールド名（bedrock-knowledge-base-default-vector / AMAZON_BEDROCK_TEXT_CHUNK / AMAZON_BEDROCK_METADATA）は Bedrock KB のデフォルト値です。§3 で作成した OpenSearch Serverless index の mapping と完全一致させてください。

4-2. Embeddings model 2 択

2026 年 4 月時点で選ぶべき Embeddings model は主に 2 種類です。

4-3. Chunking 戦略 4 方式

2026 年 4 月時点で 4 方式が利用可能です。

HIERARCHICAL は親 chunk（文脈保持）と子 chunk（検索精度）の 2 層構造で長文 PDF に有効です。SEMANTIC は文章の意味境界で自動分割するため、FAQ や Q&A 形式のドキュメントに特に有効です（2025 年 Q4 GA・2026 年 4 月時点）。

resource "aws_bedrockagent_data_source" "this" {
  knowledge_base_id = aws_bedrockagent_knowledge_base.this.id
  name  = "product-manuals"

  data_source_configuration {
 type = "S3"
 s3_configuration {
bucket_arn= aws_s3_bucket.kb_docs.arn
inclusion_prefixes = ["docs/"]
 }
  }

  vector_ingestion_configuration {
 chunking_configuration {
chunking_strategy = "HIERARCHICAL"
hierarchical_chunking_configuration {
  level_configuration { max_tokens = 1500 }
  level_configuration { max_tokens = 300 }
  overlap_tokens = 60
}
 }
  }
}

4-4. Data Source 登録 + Ingestion job

terraform apply でデータソースを登録後、手動で ingestion job を起動する必要があります（terraform apply だけでは自動取り込みされません）。

# Knowledge Base ID と Data Source ID を取得
KB_ID=$(terraform output -raw knowledge_base_id)
DS_ID=$(terraform output -raw data_source_id)

# Ingestion job を起動
aws bedrock-agent start-ingestion-job \
  --knowledge-base-id "$KB_ID" \
  --data-source-id "$DS_ID" \
  --region us-east-1

4-5. Ingestion job ステータス監視

get-ingestion-job でステータスを確認します。ステータス遷移: STARTING → IN_PROGRESS → COMPLETE または FAILED。

# ポーリングスクリプト例
while true; do
  STATUS=$(aws bedrock-agent get-ingestion-job \
 --knowledge-base-id "$KB_ID" \
 --data-source-id "$DS_ID" \
 --ingestion-job-id "$JOB_ID" \
 --region us-east-1 \
 --query 'ingestionJob.status' \
 --output text)
  echo "Status: $STATUS"
  if [ "$STATUS" = "COMPLETE" ] || [ "$STATUS" = "FAILED" ]; then break; fi
  sleep 30
done

# 失敗時は詳細を確認
aws bedrock-agent get-ingestion-job \
  --knowledge-base-id "$KB_ID" \
  --data-source-id "$DS_ID" \
  --ingestion-job-id "$JOB_ID" \
  --region us-east-1 \
  --query 'ingestionJob.{status: status, stats: statistics, reasons: failureReasons}'

100 ドキュメント（平均 10K tokens）の場合、取り込みには 3〜5 分程度かかります（2026 年 4 月時点の目安。ドキュメント数・サイズ・chunking 方式により変動します）。

ingestion job が COMPLETE になったら、次の §5 で retrieve_and_generate API を使って実際にクエリを投げていきましょう。

5. RetrieveAndGenerate API ハンズオン (Python boto3)

5-1. boto3 クライアント初期化

Bedrock の Python SDK には 2 種類のクライアントがあります。混同するとエラーになるため最初に整理します。

import boto3
from botocore.config import Config

def make_runtime_client(region: str = "us-east-1"):
 return boto3.client(
  "bedrock-agent-runtime",
  region_name=region,
  config=Config(
retries={"max_attempts": 5, "mode": "adaptive"},
read_timeout=60,
connect_timeout=10,
  ),
 )

retries={"mode": "adaptive"} により ThrottlingException 発生時は SDK が自動リトライします。read_timeout=60 は LLM 生成が長引く場合のタイムアウト防止です。

5-2. RetrieveAndGenerate API 基本呼び出し

retrieve_and_generate は「ベクトル検索 + LLM 生成」を 1 API コールで完結させる最もシンプルな RAG パターンです。

KB_ID = "XXXXXXXXXX"
MODEL_ARN = "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0"

def retrieve_and_generate(client, query: str, kb_id=KB_ID, model_arn=MODEL_ARN, session_id=None):
 req = {
  "input": {"text": query},
  "retrieveAndGenerateConfiguration": {
"type": "KNOWLEDGE_BASE",
"knowledgeBaseConfiguration": {"knowledgeBaseId": kb_id, "modelArn": model_arn},
  },
 }
 if session_id:
  req["sessionId"] = session_id
 return client.retrieve_and_generate(**req)


client = make_runtime_client()
resp = retrieve_and_generate(client, "ECS Blue/Green デプロイの手順を教えてください")
print(resp["output"]["text"])
for c in resp.get("citations", []):
 for ref in c.get("retrievedReferences", []):
  print(ref.get("location", {}).get("s3Location", {}).get("uri", "N/A"))
print(f"sessionId: {resp.get('sessionId')}")

主なレスポンスフィールド（2026年4月時点）: output.text（回答テキスト）/ citations[].retrievedReferences[].content.text（根拠 chunk）/ citations[].retrievedReferences[].location.s3Location.uri（出典 URI）/ sessionId（マルチターン継続用）。

5-3. Retrieve 単体 API

LLM を自前で選びたい場合や、プロンプトを細かく制御したい場合は retrieve 単体 API を使います。

import json

def retrieve_and_invoke(client, bedrock_rt, query: str, kb_id: str) -> str:
 # Step 1: ベクトル検索で関連 chunk を取得
 chunks = client.retrieve(
  knowledgeBaseId=kb_id,
  retrievalQuery={"text": query},
  retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 5}},
 )["retrievalResults"]

 # Step 2: chunk をコンテキストに組み込んで自前 invoke_model
 context = "\n\n".join(
  f"[出典: {c.get('location', {}).get('s3Location', {}).get('uri', 'N/A')}]\n{c['content']['text']}"
  for c in chunks
 )
 body = json.dumps({
  "anthropic_version": "bedrock-2023-05-31",
  "max_tokens": 1024,
  "messages": [{"role": "user", "content": f"<context>\n{context}\n</context>\n\n質問: {query}"}],
 })
 resp = bedrock_rt.invoke_model(
  modelId="anthropic.claude-3-5-sonnet-20241022-v2:0", body=body
 )
 return json.loads(resp["body"].read())["content"][0]["text"]

5-4. セッション継続

初回応答の sessionId を次回リクエストに渡すことで、前の質問の文脈を保ちながらマルチターン会話が可能です。

session_id = None
for question in ["ユースケースを教えて", "コストが高いのはどれ？", "削減策は？"]:
 resp = retrieve_and_generate(client, query=question, kb_id=KB_ID,
model_arn=MODEL_ARN, session_id=session_id)
 session_id = resp.get("sessionId")
 print(f"Q: {question}\nA: {resp['output']['text']}\n")

セッション TTL は 24 時間（2026 年 4 月時点）。TTL 超過後に同じ sessionId を使うとエラーになるため、長期運用では有効期限管理が必要です。

5-5. エラーハンドリング

主な例外: ThrottlingException（TPS 超過・backoff でリトライ）/ ResourceNotFoundException（KB ID 誤り）/ ValidationException（入力長超過）/ AccessDeniedException（IAM / モデルアクセス未許可）。

import functools, random, time, logging
from botocore.exceptions import ClientError

log = logging.getLogger(__name__)
RETRYABLE = {"ThrottlingException", "ServiceUnavailableException", "InternalServerException"}

def with_retry(max_attempts: int = 5):
 def decorator(fn):
  @functools.wraps(fn)
  def wrapper(*args, **kwargs):
for attempt in range(max_attempts):
 try:
  return fn(*args, **kwargs)
 except ClientError as e:
  code = e.response["Error"]["Code"]
  if code not in RETRYABLE or attempt == max_attempts - 1:
raise
  delay = min(2 ** attempt + random.random(), 30)
  log.warning("retry %d after %.1fs: %s", attempt + 1, delay, code)
  time.sleep(delay)
  return wrapper
 return decorator


@with_retry(max_attempts=5)
def safe_retrieve_and_generate(client, query: str, kb_id: str, model_arn: str):
 return client.retrieve_and_generate(
  input={"text": query},
  retrieveAndGenerateConfiguration={
"type": "KNOWLEDGE_BASE",
"knowledgeBaseConfiguration": {"knowledgeBaseId": kb_id, "modelArn": model_arn},
  },
 )

5-6. 回答精度の評価観点

retrieve_and_generate の精度は citations の内容を元ドキュメントと照合して評価します。3 つの観点で人手確認するのが基本です。

• Answer Relevance（回答が質問に答えているか）: 質問と output.text を読み比べる
• Context Relevance（検索 chunk が質問に関連しているか）: citations[].retrievedReferences[].content.text を確認
• Groundedness（幻覚がないか）: output.text と chunk テキストを照合

for i, c in enumerate(resp.get("citations", []), 1):
 for ref in c.get("retrievedReferences", []):
  print(f"[chunk {i}] {ref['content']['text'][:100]}...")
  print(f"  出典: {ref.get('location',{}).get('s3Location',{}).get('uri','N/A')}")

精度が低い場合は、Chunking を HIERARCHICAL / SEMANTIC に変更して再 ingestion、または numberOfResults を増やして検索幅を拡大してください。§5 で動作確認ができたら、次の §6 では Bedrock Agents を使って外部 API 呼び出しも組み合わせた発展構成を構築します。

6. Bedrock Agents + Action Groups + Lambda 連携

6-1. Bedrock Agents とは

§5 の retrieve_and_generate は「KB 検索 → LLM 1 回」という単方向フローでした。Bedrock Agents はこれを拡張し、ReAct (Reasoning + Acting) パターンで「推論 → ツール呼び出し → 観察 → 再推論」のループを繰り返します。外部 API (Action Group = Lambda) と Knowledge Base 検索を組み合わせた複合アクションを実現できます。

GA タイムライン (2026 年 4 月時点):
– 2024 年 Q3: Bedrock Agents GA
– 2025 年 Q4: multi-agent collaboration GA

本記事の範囲: aws_bedrockagent_agent_collaborator を使う multi-agent collaboration は Terraform provider 側の追従がバージョンによって差があります。本記事は single agent 構成のみを扱い、multi-agent collaboration は範囲外とします。

6-2. Agent Terraform 定義

Agent の IAM ロールには bedrock:InvokeModel と lambda:InvokeFunction の両権限が必要です。trust policy の principal は bedrock.amazonaws.com です。

resource "aws_iam_role" "bedrock_agent" {
  name= "${local.project_name}-agent-role"
  assume_role_policy = jsonencode({
 Version= "2012-10-17"
 Statement = [{ Effect = "Allow", Principal = { Service = "bedrock.amazonaws.com" }, Action = "sts:AssumeRole" }]
  })
}

resource "aws_iam_role_policy" "bedrock_agent" {
  name= "${local.project_name}-agent-policy"
  role= aws_iam_role.bedrock_agent.id
  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{ Effect = "Allow", Action = ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
  Resource = "arn:aws:bedrock:${local.region}::foundation-model/*" },
{ Effect = "Allow", Action = "lambda:InvokeFunction",
  Resource = aws_lambda_function.action_handler.arn }
 ]
  })
}

resource "aws_bedrockagent_agent" "main" {
  agent_name  = "${local.project_name}-agent"
  agent_resource_role_arn = aws_iam_role.bedrock_agent.arn
  foundation_model  = "anthropic.claude-3-5-sonnet-20241022-v2:0"
  idle_session_ttl_in_seconds = 600

  instruction = <<-EOT
 まず Knowledge Base を使って関連情報を検索してから回答してください。
 Knowledge Base に情報がない場合のみ、在庫確認ツールを使って補完してください。
 回答は簡潔かつ正確に、日本語で返してください。
  EOT
  tags = local.common_tags
}

instruction に「KB を使ってから回答」と明記することで、Agent が KB-first な動作をするよう誘導できます。この指示が ReAct ループの推論品質に直結します。

6-3. Action Group + Lambda

OpenAPI 3.0 schema で Action Group のエンドポイント仕様を宣言し、Lambda で実処理します。

resource "aws_s3_object" "openapi_schema" {
  bucket = aws_s3_bucket.kb_bucket.id
  key = "agent/openapi-schema.yaml"
  content= file("${path.module}/openapi-schema.yaml")
  content_type = "application/x-yaml"
}

resource "aws_bedrockagent_agent_action_group" "inventory" {
  agent_id = aws_bedrockagent_agent.main.agent_id
  agent_version  = "DRAFT"
  action_group_name = "InventoryActionGroup"
  description = "在庫確認を行うアクショングループ"

  action_group_executor {
 lambda = aws_lambda_function.action_handler.arn
  }
  api_schema {
 s3 {
s3_bucket_name = aws_s3_bucket.kb_bucket.id
s3_object_key  = aws_s3_object.openapi_schema.key
 }
  }
  depends_on = [aws_bedrockagent_agent.main]
}

Lambda handler は OpenAPI 準拠のレスポンス構造 を返す必要があります:

import json, logging

logger = logging.getLogger()
INVENTORY = {
 "PROD-001": {"quantity": 42, "warehouse": "東京DC"},
 "PROD-002": {"quantity": 0,  "warehouse": "大阪DC"},
}

def lambda_handler(event: dict, context) -> dict:
 logger.info("event: %s", json.dumps(event))
 action_group = event.get("actionGroup", "")
 api_path  = event.get("apiPath", "")
 http_method  = event.get("httpMethod", "GET")
 # parameters は [{"name": "product_id", "type": "string", "value": "PROD-001"}] 形式
 params = {p["name"]: p["value"] for p in event.get("parameters", [])}

 if api_path == "/check-inventory" and http_method == "GET":
  product_id = params.get("product_id", "")
  data = INVENTORY.get(product_id, {"error": f"商品 '{product_id}' は見つかりません"})
  status = 200
 else:
  data = {"error": f"Unknown path: {api_path}"}
  status = 400

 return {
  "actionGroup": action_group,
  "apiPath":  api_path,
  "httpMethod":  http_method,
  "httpStatusCode": status,
  # responseBody."application/json".body には json.dumps() で文字列化した値を入れる
  "responseBody": {
"application/json": {
 "body": json.dumps(data, ensure_ascii=False)
}
  },
 }

レスポンス構造の注意点: responseBody."application/json".body には JSON オブジェクトをそのまま入れるのではなく、json.dumps() で文字列化した値を入れます (二重エンコードが正しい仕様です)。

6-4. Knowledge Base の Attach

§4 で作成した KB を Agent に紐付けます:

resource "aws_bedrockagent_agent_knowledge_base_association" "main" {
  agent_id = aws_bedrockagent_agent.main.agent_id
  agent_version  = "DRAFT"
  knowledge_base_id = aws_bedrockagent_knowledge_base.main.id
  knowledge_base_state = "ENABLED"
  description = "社内ナレッジベース。製品マニュアル・FAQ・社内規程を格納"
}

knowledge_base_state = "DISABLED" に変えると KB を参照せず Action Group のみで応答します。instruction に「まず Knowledge Base を検索してから」と明記することで KB-first な ReAct ループを促進できます。

6-5. Agent Alias と prepare

Agent の設定変更後は prepare が必要です。prepare は内部で DRAFT をコンパイルして呼び出し可能な状態にします。2026 年 4 月時点の prepare 所要時間は 1〜2 分 です。terraform apply 直後に invoke すると ConflictException が返ることがあるため、ステータスが PREPARED になるのを待ってから呼び出してください。

resource "aws_bedrockagent_agent_alias" "dev" {
  agent_id= aws_bedrockagent_agent.main.agent_id
  agent_alias_name = "dev"
  routing_configuration {
 agent_version = "DRAFT"
  }
  tags = local.common_tags
}

# prepare 実行
aws bedrock-agent prepare-agent --agent-id <AGENT_ID> --region us-east-1

# PREPARED になるまで確認 (1〜2 分待つ)
aws bedrock-agent get-agent --agent-id <AGENT_ID> --query "agent.agentStatus"
# → "PREPARED" で呼び出し可能

本番環境では DRAFT ではなく数値バージョン ("1" / "2") のエイリアスを使い、バージョン切り替えでダウンタイムなし更新を行います。

6-6. InvokeAgent による実行

bedrock-agent-runtime クライアントで Agent を呼び出します。レスポンスは EventStream 形式のストリーミングです。

import boto3, json, uuid, logging
from botocore.config import Config

logger = logging.getLogger(__name__)

def make_agent_client(region: str = "us-east-1"):
 return boto3.client(
  "bedrock-agent-runtime",
  region_name=region,
  config=Config(
retries={"max_attempts": 3, "mode": "adaptive"},
read_timeout=120,  # ReAct ループで複数回 LLM を呼ぶため長めに設定
  ),
 )

def invoke_agent(client, agent_id: str, alias_id: str,
  session_id: str, message: str) -> str:
 response = client.invoke_agent(
  agentId=agent_id,
  agentAliasId=alias_id,
  sessionId=session_id,
  inputText=message,
  enableTrace=True,# ReAct ログを有効化
 )
 chunks = []
 for event in response["completion"]:
  if "chunk" in event:
chunks.append(event["chunk"]["bytes"].decode("utf-8"))
  elif "trace" in event:
_log_react_trace(event["trace"])
 return "".join(chunks)

def _log_react_trace(trace: dict) -> None:
 orch = trace.get("trace", {}).get("orchestrationTrace", {})
 if "rationale" in orch:
  logger.info("[推論] %s", orch["rationale"].get("text", "")[:200])
 if "invocationInput" in orch:
  logger.info("[ツール呼び出し] %s", json.dumps(orch["invocationInput"]))
 if "observation" in orch:
  logger.info("[結果] type=%s", orch["observation"].get("type", ""))

7. 運用: Guardrails + CloudWatch Metrics + コスト最適化

7-1. Guardrails 概論

Amazon Bedrock Guardrails は 2024 年に GA し、LLM の入出力を複数フィルタで自動検査・ブロックできます (2026 年 4 月時点)。Knowledge Base / Agent / InvokeModel に guardrail_id + guardrail_version を指定するだけで紐付けられ、追加コードは不要です。

4 つのフィルタ概要:

Guardrails を Knowledge Base に紐付けると retrieve_and_generate の input/output 両方に自動適用されます。Agent に紐付けると ReAct ループ内の全 LLM 呼び出しに適用されます。まず Agent で動作確認し、問題なければ KB にも展開するフローを推奨します。

7-2. Guardrail Terraform 定義

resource "aws_bedrock_guardrail" "main" {
  name = "${local.project_name}-guardrail"
  blocked_inputs_messaging  = "この質問にはお答えできません。"
  blocked_outputs_messaging = "回答を生成できませんでした。"

  content_policy_config {
 filters_config {
type= "SEXUAL"
input_strength  = "HIGH"
output_strength = "HIGH"
 }
 filters_config {
type= "HATE"
input_strength  = "HIGH"
output_strength = "HIGH"
 }
  }

  topic_policy_config {
 topics_config {
name = "CompetitorComparison"
definition = "競合他社のサービスと自社サービスを比較する質問"
examples= ["AWSとGCPを比較して", "他社のRAGサービスとの違いは？"]
type = "DENY"
 }
  }

  sensitive_information_policy_config {
 pii_entities_config {
type= "EMAIL"
action = "ANONYMIZE"
 }
 pii_entities_config {
type= "PHONE"
action = "ANONYMIZE"
 }
  }

  tags = local.common_tags
}

resource "aws_bedrock_guardrail_version" "main" {
  guardrail_id = aws_bedrock_guardrail.main.guardrail_id
  description  = "production v1"
}

DRAFT バージョンは開発時のみ使用し、本番では必ず aws_bedrock_guardrail_version でバージョンを固定してください。

7-3. Guardrail 料金注記

7-4. CloudWatch Metrics

Bedrock は AWS/Bedrock namespace にメトリクスを自動送信します (追加設定不要)。主要 8 種類を把握しておきましょう。

CloudWatch Alarm の Terraform 定義 (スロットリング監視):

resource "aws_cloudwatch_metric_alarm" "bedrock_throttle" {
  alarm_name = "${local.project_name}-bedrock-throttle"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name= "InvocationThrottles"
  namespace  = "AWS/Bedrock"
  period  = 300
  statistic  = "Sum"
  threshold  = 10
  alarm_description= "Bedrock スロットリングが5分間で10件超"
  alarm_actions = [aws_sns_topic.alerts.arn]

  dimensions = {
 ModelId = "anthropic.claude-3-5-sonnet-20241022-v2:0"
  }
}

Dashboard JSON 断片 (スロットリング + p99 レイテンシ監視):

{
  "widgets": [
 {
"type": "metric",
"properties": {
  "title": "Bedrock InvocationThrottles",
  "metrics": [["AWS/Bedrock", "InvocationThrottles",
 "ModelId", "anthropic.claude-3-5-sonnet-20241022-v2:0"]],
  "period": 300, "stat": "Sum", "region": "us-east-1"
}
 },
 {
"type": "metric",
"properties": {
  "title": "InvocationLatency p99",
  "metrics": [["AWS/Bedrock", "InvocationLatency",
 "ModelId", "anthropic.claude-3-5-sonnet-20241022-v2:0"]],
  "period": 300, "stat": "p99", "region": "us-east-1"
}
 }
  ]
}

7-5. コスト最適化

コスト見積もり表 (2026 年 4 月時点・概算)

重要: 下表は 2026 年 4 月時点の公式料金に基づく概算です。必ず AWS Pricing Calculator で最新料金を確認してください。

前提: 1,000 クエリ/月・100 docs (1 doc = 10K tokens)・Claude 3.5 Sonnet v2・Titan v2・us-east-1。OpenSearch Serverless (2 OCU) がコスト全体の 96% を占めます。

7-6. 運用チェックリスト

[ ] Guardrail が KB / Agent に正しく紐付いているか確認
 aws bedrock-agent get-knowledge-base --knowledge-base-id <ID>
 → guardrailConfiguration フィールドを確認

[ ] CloudWatch アラームが設定済みか
 → InvocationThrottles (5分間 > 10件)
 → InvocationServerErrors (5分間 > 1件)
 → InvocationLatency p99 (> 30,000ms)

[ ] AWS Cost Anomaly Detection が設定済みか
 → 前月比 20% 増加で通知する Monitor を作成

[ ] KB sync が定期実行されているか
 → EventBridge Scheduler → Lambda → start-ingestion-job
 → aws bedrock-agent list-ingestion-jobs で最終成功日時を確認

[ ] Bedrock model access が有効か
 → Bedrock コンソール > Model access > 使用モデルが "Access granted"

8. まとめ・次回予告

8-1. 到達点サマリ

本記事 (§1〜§7) を完走することで、以下が実現できるようになります。

1. RAG の 3 段構造 (Retrieve → Augment → Generate) と Bedrock Knowledge Bases の位置付けを説明できる
2. S3 / Web Crawler / Confluence の 3 種データソースを使い分けられる
3. aws_opensearchserverless_collection + vector index を Terraform で構築できる
4. aws_bedrockagent_knowledge_base + aws_bedrockagent_data_source を Terraform で定義できる
5. Titan v2 / Cohere Embed v3 の特性を理解し、ユースケースに合わせた Embeddings model を選択できる
6. FIXED_SIZE / HIERARCHICAL / SEMANTIC の Chunking 戦略を使い分けられる
7. bedrock-agent-runtime.retrieve_and_generate で質問→回答+citation を取得できる
8. aws_bedrockagent_agent + Action Group + Lambda で外部 API を呼び出す Agent を構築できる
9. Guardrails の 4 フィルタを Terraform で設定し KB / Agent に紐付けられる
10. CloudWatch AWS/Bedrock namespace のメトリクスでコストとレイテンシを監視できる

8-2. 落とし穴集

ハンズオン中に詰まりやすいポイント 8 選です。

8-3. 次回予告

本記事で構築した Bedrock RAG 基盤をベースに、以下を Vol2 候補として検討しています。

• Bedrock multi-agent collaboration — 複数 Agent が協調するオーケストレーション (2025 年 Q4 GA・2026 年 4 月時点)
• Bedrock Prompt Flow — GUI でプロンプトパイプラインを設計するビジュアルビルダー
• Bedrock Model Distillation — 大型モデルの出力を小型モデルに転移してコスト削減
• Bedrock Batch Inference + S3 — 非同期の大量推論ジョブで 50% コスト削減

公開予定は未定ですが、本記事にコメントいただければ優先度を上げます。

8-4. terraform destroy 完全手順

依存関係に従った削除順序:

# 1. Agent と KB の関連付けを先に削除
aws bedrock-agent disassociate-agent-knowledge-base \
  --agent-id <AGENT_ID> \
  --agent-version DRAFT \
  --knowledge-base-id <KB_ID>

# 2. Agent Alias を削除
aws bedrock-agent delete-agent-alias \
  --agent-id <AGENT_ID> \
  --agent-alias-id <ALIAS_ID>

# 3. Agent 本体を削除
aws bedrock-agent delete-agent \
  --agent-id <AGENT_ID>

# 4. Data Source → Knowledge Base を削除
aws bedrock-agent delete-data-source \
  --knowledge-base-id <KB_ID> \
  --data-source-id <DS_ID>

aws bedrock-agent delete-knowledge-base \
  --knowledge-base-id <KB_ID>

# 5. terraform destroy で残りのリソースを削除
# (OpenSearch Serverless collection + policies / IAM roles / S3 等)
terraform destroy

フォールバック手動削除 (Terraform が state conflict でエラーになった場合):

# OpenSearch Serverless collection 削除
aws opensearchserverless delete-collection \
  --id <COLLECTION_ID>

# IAM role のポリシーデタッチ → ロール削除
aws iam detach-role-policy \
  --role-name bedrock-rag-kb-role \
  --policy-arn <POLICY_ARN>
aws iam delete-role --role-name bedrock-rag-kb-role

# S3 バケット内オブジェクトを空にしてから削除
aws s3 rm s3://<BUCKET_NAME> --recursive
aws s3api delete-bucket --bucket <BUCKET_NAME>

Bedrock 公式ドキュメントへ