Amazon Bedrock 発表日 2026.07.23

Amazon Bedrock Agentic Retrievalとは？Retrieveとの違い

Amazon Bedrock Agentic Retrievalとは

Amazon Bedrock Agentic Retrievalは、複雑な質問を複数の検索意図へ分解し、Managed Knowledge Baseから必要な情報を反復検索して回答する機能です。AgenticRetrieveStream APIを使い、検索結果が十分かを評価しながら計画と検索を繰り返します。

通常のRetrieveは1回の検索に向きます。一方、「製品AとBの仕様、価格条件、導入手順を比較して」のように複数の論点を含む質問では、1回のベクトル検索だけでは必要な断片が揃わないことがあります。Agentic Retrievalはこの不足を検索計画で補います。ただし、すべての質問で精度が上がるわけではなく、遅延と料金も増え得るため使い分けが必要です。

Retrieveとの違い

比較軸	Retrieve	Agentic Retrieval
向く質問	単一論点・直接的な検索	比較、複数論点、multi-hop調査
検索方法	1リクエストで検索	質問を分解し、充足度を評価して反復
Knowledge Base	1件	最大5件のManaged Knowledge Base retriever
出力	関連チャンク	回答と引用、または重複排除したチャンク
途中経過	最終検索結果	計画・検索・文書展開などのtrace event
遅延・料金	比較的小さい	反復検索とモデル利用により増えやすい
対象KB	標準・Managed KB	Managed Knowledge Baseのみ
Guardrails	利用APIの仕様に従う	BLOCKのみ。MASKは未対応

短いFAQやID検索まで常にAgentic Retrievalへ送ると、応答時間とコストの増加が便益を上回る場合があります。質問分類で直接的な問い合わせはRetrieve、比較・調査・複数KB横断はAgenticRetrieveStreamへ振り分ける構成が現実的です。

検索から回答までの5段階

先行検索：元の質問から候補を素早く取得する。これはagent iterationの上限に含まれない
計画：質問を比較対象や条件などの検索意図へ分解し、retrieverの説明を使って対象KBを選ぶ
検索・文書展開：意図ごとに検索し、必要に応じて元文書の内容を展開する
充足度評価：回答に十分かを判定し、不足があれば計画と検索を繰り返す
統合：重複を除いた検索結果とtraceを返し、既定では根拠付き回答と引用も生成する

generateResponse=falseにすると、生成回答を作らず検索チャンクを受け取れます。独自の回答生成、再ランキング、監査フローを持つ場合に使えます。AgentCore Memoryを組み合わせる構成では会話履歴や長期メモリも参照できますが、検索権限と会話メモリの境界は別々に設計します。

どちらを選ぶかの判断表

Retrieve：製品コードの仕様、1件の手順、単純なFAQ、低遅延を優先する問い合わせ
Agentic Retrieval：複数製品の比較、規程と手順の突合、原因から対応までのmulti-hop調査
段階的に併用：最初に質問分類し、複雑な質問だけAgentic Retrievalへ送る
独自生成と併用：generateResponse=falseで根拠チャンクを受け、既存の回答・承認フローへ渡す

実務例：製品資料とサポート情報を横断する

製品マニュアル、サポートチケット、社内ランブックを別々のManaged Knowledge Baseへ保存しているとします。「障害Xが製品AとBに与える影響を比較し、過去の解決例と復旧手順を示して」という質問には、少なくとも仕様差、過去事例、復旧手順の3つの検索意図があります。

検索意図	主な参照先	確認する結果
製品A/Bへの影響	製品マニュアルKB	対象バージョンと制約
過去の解決例	サポートKB	類似条件と再現性
復旧手順	ランブックKB	順序、権限、ロールバック

各retrieverの説明は、どの質問をどのKBへ送るかの判断材料です。「社内文書」のような曖昧な説明ではなく、対象業務、データ範囲、更新周期を簡潔に書きます。それでも検索結果の引用が正しい回答を保証するわけではないため、重要操作は原文確認や人の承認へ接続します。

導入の7ステップ

質問を分類する：単一検索、比較、複数KB、調査の代表例を集める
Managed Knowledge Baseを整える：文書の重複、更新日、metadata、アクセス範囲を確認する
retrieverを定義する：最大5件まで登録し、ルーティングに使える説明を付ける
モデルとIAMを準備する：モデルアクセスと必要APIだけを許可する
小規模評価する：同じ質問群をRetrieveとAgentic Retrievalで比較する
アプリへ統合する：stream event、引用、タイムアウト、再試行、部分失敗を処理する
ルーティングと監視を調整する：精度、遅延、料金、iteration数から利用範囲を絞る

API実装で押さえる項目

messages：現在のユーザー質問を含む会話メッセージ
retrievers：Knowledge Base IDと説明。最大5件
configuration：利用モデル、最大iterationなどの検索設定
generateResponse：回答生成を行うか。既定はtrue
guardrail／userContext／memory：必要な場合だけ明示し、認証・認可の代替にはしない

ストリーミング応答では、計画、検索、文書展開、最終結果が異なるイベントとして届きます。UIへ途中経過を出す場合も、内部クエリや取得チャンクに個人情報・機密情報が含まれ得るため、そのままログや画面へ表示しません。タイムアウト後の再実行やクライアント切断時の扱いも決めておきます。

本番導入前の注意点

Managed KB限定：Agentic RetrievalはFully Managed Knowledge Baseで利用する
IAM：bedrock:AgenticRetrieveStream、bedrock:Retrieve、bedrock:GetDocumentContent、bedrock:InvokeModelWithResponseStreamなどを用途に応じて最小権限で付与する
アクセス制御：IAM、アプリの認証、metadata filter、user contextをデータ境界に合わせ、権限外文書を検索対象へ入れない
遅延・料金：Agentic Retrievalの呼び出しに加え、検索とモデル利用が発生する。価格を固定値で埋め込まず導入時に公式料金を確認する
最大iteration：小さくすると遅延と料金は抑えやすいが、複雑な質問の情報不足を増やす可能性がある
Guardrails：現在はBLOCKのみ対応し、MASKは未対応。機密情報対策をGuardrailsだけへ任せない
引用：出典の存在と回答の正しさは別問題。高リスク回答は原文確認、評価、人の承認を残す
変動する仕様：対応Region、model、quota、料金は利用時点の公式情報で再確認する

評価と監視で見る指標

指標	確認内容
回答品質	正答率、必要論点の網羅、引用と原文の一致
検索品質	適切なKB選択、不要チャンク、権限外データ0件
体験	初回eventと最終回答までの時間、timeout率
利用量	検索回数、モデル利用、質問別コスト
反復	`TotalIterationCount`と質問の複雑さ
安定性	Invocations、ClientErrors、ServerErrors、Throttles

Managed Knowledge BaseはCloudWatchのAWS/Bedrock/KnowledgeBases namespaceへ指標を送ります。Agentic Retrievalでは成功リクエストのTotalIterationCountを確認できます。X-RayのKnowledge Base traceはRetrieveが対象で、AgenticRetrieveStreamは対象外なので、stream eventとアプリ側telemetryを組み合わせます。

AgentCore GatewayからMCPツールとして使う場合

AgentCore GatewayのManaged Knowledge Base connectorを使うと、RetrieveとAgenticRetrieveStreamをMCPツールとして公開できます。エージェントはtools/listで発見でき、計画・検索の途中経過はMCP notification、最終回答と検索結果はtool resultとして受け取れます。Gateway側でretrieverを管理するため、通常のAPI直呼びと設定責務を混同しないようにします。