TL;DR

同一の Knowledge Base（S3 Vectors バックエンド）に対して、同じ 2 ターンの会話を 3 つの実装方式で実行し、挙動を比較しました。

KB の Retrieve API は「生チャンク」を返しません。ベクトルインデックスに入っているのは 228〜690 字のチャンクなのに、Retrieve は最大 8,120 字に結合されたチャンクを返してきました。入力トークンは直叩き比で 3.3 倍、そのぶん回答は深くなります。
フルマネージドの RetrieveAndGenerate（デフォルト設定）は、本実験では**「〜だけ詳しく」という絞り込みのフォローアップに追従できませんでした**（毎回全体を再説明する）。分かれ目は「会話履歴を誰が持つか」です。
RAG のレイテンシの 98% は生成でした（Q1 の実測ペア: 生成 22.6s vs 検索 0.5s）。検索基盤（S3 Vectors）の速度は個人〜中規模用途ではボトルネックになりません。
検証環境一式（Terraform + boto3 CLI）は GitHub で公開しています: bedrock-lab (phase2 タグ)

この記事で扱うこと・扱わないこと

Knowledge Base + S3 Vectors の構築手順そのものは扱いません。構築は先行記事が充実しています（@zumax さんの統合手順、@hayao_k さんの CloudFormation 実装、@takeyan さんの考慮点整理など。末尾の参考にまとめています）。

本記事が扱うのは**「作った後」の話**です。出来上がった同じベクトルインデックスを

RetrieveAndGenerate API（検索も生成も履歴管理もフルマネージド）
Retrieve API + Converse API（検索だけマネージド、プロンプト合成と履歴は自前）
S3 Vectors 直叩き（埋め込み生成→ベクトル検索→合成まで全部自前）

の 3 方式で叩くと、同じ質問への挙動がどう変わるかを実測します。この 3 択の実測比較は探した範囲で見つからなかったので、一次データとして残します。

実験設定

図1: 3方式のデータフロー（検索・プロンプト合成・会話履歴をどこまで自前でやるか）

項目	内容
ベクトルストア	S3 Vectors（Titan Text Embeddings V2 / 1024 次元 / cosine）
Knowledge Base	チャンキングは KB デフォルト（約 300 トークン・文境界を尊重）
投入データ	筆者の Qiita 全 35 記事 + 検証リポジトリの docs 3 本 = 38 ドキュメント（日本語 Markdown）
メタデータ	サイドカー JSON（title / source_url / published / tags）を各ドキュメントに付与
生成モデル	`jp.anthropic.claude-sonnet-4-6`（3 方式共通）
検索件数	top_k=5（3 方式共通）
リージョン	ap-northeast-1（東京）
時期	2026年7月

ユースケースは「自分が書いた技術記事・運用メモを検索する個人版ナレッジ検索」です。投入データはすべて公開済み記事なので、そのまま記事にできます（再現用の取得スクリプトもリポジトリの scripts/build_kb_docs.py に置いてあります）。

会話は次の 2 ターンで固定しました。

Q1: 「ALB の 502 エラーの切り分け方法は？」（初回質問）
Q2: 「その 3 層のうち Target Group 層だけ詳しく」（絞り込みのフォローアップ）

Q2 が今回の実験の肝です。ナレッジ検索を実際に使うとき、1 問 1 答で終わることはまずなく、「今の回答のここだけ深掘りして」という会話になります。このとき前のターンの文脈を誰がどう保持しているかが、方式によってまったく違います。

3方式の実装

コードは要点のみ抜粋します（全文はリポジトリの client/ 参照）。

方式①: RetrieveAndGenerate（フルマネージド）

1 回の API 呼び出しで検索→プロンプト合成→生成まで完結します。マルチターンは sessionId を渡すだけで、会話文脈は KB 側が管理します。

kwargs = {
    "input": {"text": user_text},
    "retrieveAndGenerateConfiguration": {
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": kb_id,
            "modelArn": model_arn,  # jp. プロファイルの ARN を指定可能
        },
    },
}
if session_id:              # 2ターン目以降はこれだけで文脈維持
    kwargs["sessionId"] = session_id
resp = client.retrieve_and_generate(**kwargs)
session_id = resp.get("sessionId")

方式②: Retrieve + Converse（検索だけマネージド）

検索は KB の Retrieve API に任せ、返ってきたチャンクを自分でプロンプトに組み立てて Converse API に渡します。会話履歴は自前のリストです。

resp = agent_client.retrieve(
    knowledgeBaseId=kb_id,
    retrievalQuery={"text": query},
    retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 5}},
)
chunks = resp["retrievalResults"]  # ← ここで返るものが後述の発見 1

# 履歴 + 今回だけ資料付きメッセージ (資料は履歴に積まない)
messages = list(history)
messages.append({"role": "user", "content": [{"text": build_user_message(query, chunks)}]})
resp = runtime_client.converse_stream(modelId=MODEL_ID, messages=messages,
                                      system=[{"text": RAG_SYSTEM_PROMPT}], ...)

1 点だけ設計上の工夫があります。検索で取得した資料は送信時のプロンプトにだけ注入し、履歴には生の質問と回答だけを積みます。資料ごと履歴に積むと入力トークンが毎ターン数千ずつ膨張していくためです。

方式③: S3 Vectors 直叩き（フル自前）

KB を経由せず、埋め込み生成（Titan V2）→ S3 Vectors の QueryVectors → プロンプト合成まで全部自分でやります。生成と履歴管理は方式②と同じです。

# 1. クエリを埋め込みベクトルに変換
body = json.dumps({"inputText": query, "dimensions": 1024, "normalize": True})
resp = runtime_client.invoke_model(modelId="amazon.titan-embed-text-v2:0", body=body)
vector = json.loads(resp["body"].read())["embedding"]

# 2. ベクトルインデックスを直接検索
resp = s3vectors_client.query_vectors(
    vectorBucketName=bucket, indexName=index,
    queryVector={"float32": vector},
    topK=5, returnDistance=True,
    returnMetadata=True,  # ← QueryVectors に加えて GetVectors 権限が要る (おまけ参照)
)
# チャンク本文はメタデータの AMAZON_BEDROCK_TEXT に入っている

結果

	① RetrieveAndGenerate	② Retrieve + Converse	③ S3 Vectors 直叩き
Q2 の絞り込みに追従できたか	❌ 3 層全体を再説明	✅ Target Group 層のみ深掘り	✅ Target Group 層のみ深掘り
会話履歴の持ち主	KB（sessionId、制御不可）	自前リスト（制御可）	自前リスト（制御可）
返ってきたチャンク	不明（内部処理）	3 件・最大 8,120 字（結合済み）	5 件・228〜690 字（生チャンク）
入力トークン（Q1）	不明（内部処理）	6,081	1,820
検索レイテンシ（Q1）	—（内訳非公開）	514ms	358ms（埋め込み 199 + 検索 158）
生成レイテンシ（Q1）	—（内訳非公開）	22.6s	12.1s
回答の深さ（Q2）	—	◎ 判定の機構まで説明	○ 要点は正確
実装コード量	数十行	中	大（埋め込み・スコア解釈も自前）

発見

1. KB の Retrieve は生チャンクを返さなかった

タイトルの件です。チャンキング設定は KB デフォルト（約 300 トークン）なので、インデックスに格納されているチャンク — S3 Vectors のメタデータ AMAZON_BEDROCK_TEXT に入っている単位で、本記事ではこれを「生チャンク」と呼びます — は、方式③の直叩きで見えるとおり 228〜690 字です。ところが同じインデックスへの同じクエリで、方式②の Retrieve API は最大 8,120 字のチャンクを返してきました。KB が検索ヒット箇所の前後を結合・拡張して返しているようです（階層チャンキングは未設定なので、いわゆる親チャンク返却とも別の挙動。正確な仕組みは公式ドキュメントに記載が見当たらず、追加検証課題です）。

この差は下流に連鎖します。方式②は入力トークンが方式③の 3.3 倍（6,081 vs 1,820）、生成レイテンシ約 2 倍。そのかわり文脈が厚いぶん回答は明確に深くなりました（Q2 で方式②はヘルスチェック判定ラグの機構まで説明、方式③は要点のみ）。

つまり Retrieve API を使うことは、単に「検索をマネージドに任せる」のではなく、「トークンを多めに払って文脈の厚い材料をもらう」という取引です。コスト最適化で方式③に切り替えると、静かに回答品質も変わります。ここを実測で意識できたのが今回一番の収穫でした。

2. 「〜だけ詳しく」に答えられるかは、会話履歴を誰が持つかで決まる

Q2「Target Group 層だけ詳しく」に対して、方式①だけが 3 層全体を律儀に再説明しました。sessionId による文脈維持は効いている（「その 3 層」は解決できている）のに、です。

方式①は毎ターン検索が走り、生成が検索チャンクに支配されます。生成プロンプトのテンプレート差し替え（textPromptTemplate）という調整手段はあるものの、会話履歴そのものは KB 管理で、履歴の中身を前提にした制御はできません（本実験の①はデフォルト設定です）。一方②③は履歴が自前のリストなので、システムプロンプトに「直前の回答と重複する説明は繰り返さない。絞り込みの指示には該当部分のみ深掘りする」と書けて、期待どおりに動きます。

手軽さの①、制御性の②③。1 問 1 答なら①で十分ですが、対話型のナレッジ検索を作るなら、絞り込みフォローアップは最初に試すべきテストケースです。

3. フォローアップ時、検索はほぼ働いていない

Q2 の検索スコアは激減しました（方式③: 0.77→0.37、方式②: 0.88→0.68。無関係な記事もヒット）。「Target Group 層だけ詳しく」のような短い絞り込み文は、検索クエリとしては弱いのです。それでも②③の回答が正確だったのは、会話履歴が回答を支えていたからです。

マルチターン RAG で「毎ターン素朴に再検索」は無駄が多い、という学びです。会話文脈を織り込んだ検索クエリの生成（クエリ書き換え）や、検索スキップ判定に改善余地があります。このあたりは会話型 QA の研究領域としても確立しています（参考に論文リンクを置きました）。

4. レイテンシの 98% は生成

検索は 200〜500ms、生成は 9〜23 秒（方式② Q1 の計測ペアでは生成 22.6s / 検索 0.51s ≒ 97.8%）。RAG の体感速度を決めるのは検索基盤ではなく生成側（モデル選択・出力長・ストリーミング表示の有無）でした。

S3 Vectors は「低頻度アクセス向け・サブ秒クエリ」という位置づけで OpenSearch Serverless より遅いとされますが、この構造なら個人〜中規模用途で検索側の差は誤差です。固定費ゼロ（従量のみ）で KB のバックエンドになる S3 Vectors は、ホームラボ用途では文句なしでした。

5. 自前化するほど IAM が太る

方式①②は bedrock:Retrieve* + 生成モデルの InvokeModel で済みますが、方式③は追加で埋め込みモデルの InvokeModel と s3vectors:QueryVectors が要ります。さらに returnMetadata=True を付けると s3vectors:GetVectors も必要でした（AccessDenied で発見。QueryVectors だけでは足りません）。

マネージドを剥がすことは、権限管理の責任を自分で引き受けることでもあります。

6. スコアの意味が方式で違う

KB Retrieve の score は「大きいほど近い」正規化済みの値、S3 Vectors の distance は cosine 距離で「小さいほど近い」。体系が別物なので、方式②で作った閾値ロジックを方式③に移植するとそのままでは壊れます。

使い分けの結論

用途	方式
単発の質問応答をとにかく速く作る	① RetrieveAndGenerate
マルチターン対話・プロンプトを制御したい	② Retrieve + Converse（バランス型。検索品質は KB に任せて制御を握る）
RAG の内部を理解する・検索を自作したい（クエリ書き換え、リランキング等）	③ S3 Vectors 直叩き

おまけ: 構築時につまずいた 2 点

同期が 38 件中 30 件失敗 — non-filterable キーは「2 つ」必要

初回のデータ同期で 38 ドキュメント中 30 件がこのエラーで失敗しました。

Filterable metadata must have at most 2048 bytes

S3 Vectors のインデックスを自作して KB に接続する場合、AMAZON_BEDROCK_TEXT（チャンク本文）と AMAZON_BEDROCK_METADATA（KB の内部管理 JSON）の両方を non-filterable に指定する必要があります（公式ドキュメント記載の要件）。片方だけだと、もう片方がフィルタ可能メタデータ扱いになり 2,048 バイト制限に当たります。

resource "aws_s3vectors_index" "kb" {
  # ...
  metadata_configuration {
    non_filterable_metadata_keys = ["AMAZON_BEDROCK_TEXT", "AMAZON_BEDROCK_METADATA"]
  }
}

この制約自体は既出です（@hayao_k さんの記事でも「実質必須」と指摘されています）。ここで付け加えたいのは日本語データだと顕在化が早いことです。UTF-8 の日本語は 1 字 3 バイトなので、690 字の生チャンクは本文だけで約 2,070 バイト。300 トークンという小さめのデフォルトチャンクですら制限を超えます。「全部失敗」ではなく 30/38 という中途半端な失敗（短いチャンクだけ成功）になるのも、原因を紛らわしくするポイントでした。

QueryVectors の returnMetadata には GetVectors 権限が要る

発見 5 の再掲ですが、単体でハマりどころなので手順として残します。s3vectors:QueryVectors を許可しても、returnMetadata=True 付きの呼び出しは AccessDenied になります。s3vectors:GetVectors を併せて許可してください。

実はこれ、QueryVectors のリファレンスの Permissions に明記されています（メタデータフィルタまたは returnMetadata には両方の権限が必要、無ければ 403）。エラーを踏んでから読み直して気づきました。API リファレンスは Permissions 欄まで読んでから IAM を書く、という基本の再確認でした。

まとめ

学び	内容
Retrieve の返すもの	生チャンクでなく結合チャンク。トークン 3.3 倍と引き換えに回答が深い
絞り込みフォローアップ	デフォルトの①は追従できず、履歴を自前で持つ②③は追従できた
フォローアップ時の検索	スコア激減。回答を支えるのは履歴
レイテンシ	98% は生成。検索基盤の速度は個人〜中規模では誤差
IAM	自前化するほど太る。returnMetadata には GetVectors も必要
自作インデックス	non-filterable キーは 2 つ必須。日本語データは顕在化が早い

Terraform 一式・3 方式のクライアント実装・計測ログの取り方は GitHub で公開しています。

前回（Phase 1）の記事はこちら: 動いていた Bedrock の Claude が数分で使えなくなった — モデルアクセス有効化を CLI で完結する手順とハマりどころ

参考

AWS 公式

Using S3 Vectors with Amazon Bedrock Knowledge Bases (S3 User Guide) — non-filterable 2 キー要件の一次情報
Metadata filtering / Limitations (S3 Vectors) — フィルタ可能メタデータ 2KB 制限
Query a knowledge base and retrieve data (Amazon Bedrock) — Retrieve / RetrieveAndGenerate API
How content chunking works for knowledge bases (Amazon Bedrock) — チャンキング戦略
S3Vectors.Client.query_vectors (boto3) — returnMetadata に GetVectors 権限が必要な旨の Permissions 記載

先行記事（構築手順はこちらが詳しいです）

S3 VectorsとBedrock Knowledge Basesを統合してみた (@zumax)
Amazon Bedrock Knowledge Bases + S3 Vectors を CloudFormation で実装する (@hayao_k) — 2048B 制約と NonFilterableMetadataKeys の指摘あり
S3 VectorsとKnowledge Baseを組み合わせたRAG構築における考慮点 (@takeyan) — メタデータ設計の考慮点
既存の S3 Vectors を Bedrock Knowledge Bases で利用する方法 (@revsystem)

同事象の報告・関連研究

S3 Vector, big metadata error (AWS re:Post)
S3 Vectors PutVectors fails due to too large default metadata (langchain-aws #693)
Learning When to Retrieve, What to Rewrite, and How to Respond in Conversational QA (arXiv) — 会話型 QA でのクエリ書き換え・検索スキップ判定